I had the pleasure of meeting Henri last year, and he talked about how long it's taken to get this idea off the ground. I like the idea, as I hate phone numbers, and can easily remember something like http://henri.tel/
At the time, I tried to get a quote for tom.tel but they were in their initial "companies only" stage. I believe Google or Facebook could more easily make a service like this successful, but I hope it takes off.
Their main webpage is http://www.telnic.org/ and they're in wide release now. Unfortunately, tom.tel is already taken ;-)
You can remember http://henri.tel, but if this takes off, it's gonna be like the old AOL user ID's or most of the big webmail providrs where the namespace is so crowded that everyone ends up as http://henriloveshiscat182.tel. :-)
Governments could begin programs to create namespaces for citizens who would like a domain. We already have TLDs for countries, and often for smaller divisions as well (i.e. provinces, states, etc), we could just keep adding sub domains for family name, and so on. e.g. I could be sami.samhuri.victoria.bc.ca. Of course, then people will move so we'd have to have everyone involved in a redirect scheme, there are likely other issues with the idea, but I think it's neat.
As you said, that'd be a bit of a pain when you move. Plus to me, the big question is do people (average people, not us HN geeks), actually want or care about something like this?
BTW.. The individual static IPv6 addresses seems unlikely also. Because of the much larger address space provided by IPv6, there's a great deal of concern about the potential of massive increases in the size of the routing tables for Internet backbone routers. Because of this, one of the goals of the IPv6 Allocation and Assignment Policy is "Aggregation". Addressing is going to be assigned strictly on the basis of network topology to maximize the ability to to do route summarization. Relatedly, one of the policy goals for the IPv6 Allocation and Assignment Policy is that IP addresses are not to be considered private property. Unlike IPv4 where many non-ISP organizations "own" a block of IP addresses, in IPv6 the policy will be that IP addresses are only leased, never owned.
Fair question. The short answer is simplicity and practicality:
* Most people don't own a .com (or .whatever) for personal use - and never will - so what are the advantages?
* The suffix indicates the capability. It wouldn't be obvious that andrewtj.com contained your contact records. I'm not sure how you could change public perception of .com/etc, but you at least have a shot at it with a TLD exclusively for this purpose.
* TelHosting providers are obligated to provide standard public APIs, and there are also specs for consuming structured data from DNS. Would you use these, or create your own?
* For people who do own a .com they most likely won't be running their own nameservers, so you'd have to persuade nameserver operators to agree on API specs and run your management software.
* .tel has a system for brokering encryption keys used to encrypt/decrypt records - if you want privacy you'd need a system like this.
* Using a common namespace offers us a publicly accessible zone - convenient!
* Marketing. Hundreds of registrars selling a common branded product gives it the best chance of adoption.
* It's actually pretty hard to do by all accounts.
I have nothing to do with Telnic - I'm just an advocate/fanboy :)
* Most people don't own a .com (or .whatever) for personal use - and never will - so what are the advantages?
Whilst that's true, when someone decides to purchase a domain, why would they buy a .tel when there's other namespaces with more freedoms? I'd be surprised if .tel takes off in preference to .id.au in Australia for instance; — I know which domain I prefer and pay for.
* The suffix indicates the capability. It wouldn't be obvious that andrewtj.com contained your contact records. I'm not sure how you could change public perception of .com/etc, but you at least have a shot at it with a TLD exclusively for this purpose.
I'm not sure that this is as practical a benefit as it sounds. If you were to ask me what my ".tel" is and I responded, just use "andrew.tj.id.au" you'd plug it in and use it. If you were to use andrew.tj.id.au on a computer, you'd likely consume it without even thinking about it.
* TelHosting providers are obligated to provide standard public APIs, and there are also specs for consuming structured data from DNS. Would you use these, or create your own?
* For people who do own a .com they most likely won't be running their own nameservers, so you'd have to persuade nameserver operators to agree on API specs and run your management software.
* .tel has a system for brokering encryption keys used to encrypt/decrypt records - if you want privacy you'd need a system like this.
I've written a DNS server and run a DNS service so it's a bit disingenuous for me to answer these questions. That said, I would and am considering providing the infrastructure for myself and others.
* Using a common namespace offers us a publicly accessible zone - convenient!
I'm not clear on what benefit this outlines?
* Marketing. Hundreds of registrars selling a common branded product gives it the best chance of adoption.
* It's actually pretty hard to do by all accounts.
Agreed on both accounts. The later is part of the reason for my lack of enthusiasm for it.
>why would they buy a .tel when there's other namespaces with more freedoms?
What freedoms are you referring to?
>I'm not sure that this is as practical a benefit as it sounds. If you were to ask me what my ".tel" is and I responded, just use "andrew.tj.id.au" you'd plug it in and use it.
Fair enough, it would be great to reach that point!
>I'm not clear on what benefit this outlines?
Search. That's what I'm working on :)
>Agreed on both accounts. The later is part of the reason for my lack of enthusiasm for it.
But it works :) And from a developers perspective it's easy - there's a bunch of apps you can play with (iPhone, Blackberry, softphones, etc).
>I can point the A records for any other domain anywhere I like but with .tel I'm stuck with the providers choice (or have I misunderstood?).
Ah I see. Yes, the Address record stays pointing at the TelProxy web server (incidentally a major overhaul will be released later this month). Anyway, I don't personally see this as a matter of "freedom" - better to keep the focus on its intended purpose.
>Ah, I can see how that would be problematic. Do you have a blog or something I can follow your progress on?
andy.tel - no blog, but I tweet, mostly rubbish. :-)
means that "E2U" is a protocol (E2U doesn't seem to be defined in the same RFC as NAPTR - it means "E.164 to URI" even though the NAPTR query didn't send an E.164 request), "web:http" is a "resolution service" (they should be used the other way around if you believe the RFC, although wikipedia also uses this order). "u" indicates that the original query should be passed through the regex substitution to get a URI.
Could they make it any more complicated than this?
Misused, because why should the client care about your routing? SIP already provides a way to drop the router from the path after relaying the first packet - why put the same exact capability onto DNS then? There are caching issues, routing delays caused by 3 resolver queries (NAPTR -> SRV -> A), etc. etc. Imho enum should be available only explicitly - not as the base routing mechanism.
Complicated - because of regexes and usage of prefixes such as E2U which don't make sense here. Someone created a service based on a custom TLD and marks the entries as E2U even though they don't use E.164 numbers at all. If they cannot get it right, how can users understand it?
>they should be used the other way around if you believe the RFC, although wikipedia also uses this order
FYI the spec changed between rfc2916 and rfc3761:
The format of the service field has changed. The old format was of the form "example+E2U", while the new format is "E2U+example".
Reason for this change have to with the added subtypes in the enumservice, the ability to support more than one enumservice per NAPTR RR, and a general agreement in the IETF that the main selector between different NAPTR with the same owner (E2U in this case) should be first."
"This is pretty cool because it means that anything that can speak DNS (pretty much everything) could have programmatic access to this data."
That scares me. It then becomes simple for anyone with an internet connection to pull the phone and email addresses of anyone using this. DNS isn't exactly designed to withstand that kind of abuse (You can't block someone, you can't ratelimit someone, etc).
>DNS isn't exactly designed to withstand that kind of abuse (You can't block someone, you can't ratelimit someone, etc).
It's hard to take out somebody's nameservers, since there's no single point of failure (unlike with most web setups). But even then there's still (hopefully) some resolvers with cached records :)
Perhaps this is a dumb question: How does that solve the problem? Either its readable by all or by none.
It's hard to take out somebody's nameservers, since there's no single point of failure (unlike with most web setups). But even then there's still (hopefully) some resolvers with cached records :)
I think you may have missed the point. He's not worried about the data being unavailable, quite the opposite.
>Perhaps this is a dumb question: How does that solve the problem? Either its readable by all or by none.
There's a service called TelFriends that brokers keys between you and your friends.
Ordinary people don't have to care about that - typically their username/password is used in whatever app they're using to transparently decrypt records on the fly.
And since we're talking about privacy, you own your domain and its data - not Telnic, Google, or Facebook.
Facebook/LinkedIn and Google make this DNS trick superfluous, but also each has a vested interest in having people use the web, not a novel DNS-based registry, for such discovery. For those reasons, I pronounce .TEL dead-on-arrival.
(Web hits are even easier than DNS. Why not telnic.org/henri instead of henri.tel? Both could, at Telnic's discretion, imply the exact same thing. One just makes it even clearer you're bought-into a single company's namespace. But that's a bug, not a feature.)
Cute idea, but I don't see it gaining real traction. There's been many attempts at vanity TLDs that were arguably more useful/intuitive (e.g., .jobs, .me) and they've yet to see any real adoption. For that matter, even .net's are hard to sell.
I also think that not allowing you to host a website at .tel is a fatal mistake. The group of people who'd prefer to look up their friend's phone number from console is tragically small. The hope I suppose is that Google indexes my .tel, and people then find my number through Google, but then why do I need the .tel?
Finally, what's with the registrar ballot screen that doesn't list prices? For anyone who's wondering, name.com looks the cheapest ($10).
Wouldn't it be better to tie a phone number to an email address? An email address is still much more memorable than a phone number but the crowded namespace issue has already been solved. You could add something similar to an MX record to your domain's DNS that specifies where your "phone number server" is. The phone number server would be a simple database of username/alias and "real" phone number (although it could be expanded to do redirects, voicemail, 404s etc). The client making the call then consults this server which returns the number that it should dial.
"This is pretty cool because it means that anything that can speak DNS (pretty much everything) could have programmatic access to this data."
I don't think this offers an advantage over my solution, as any application that needs to use this will have to be modified anyway, the protocol I'm proposing would be equally trivial (or not) to implement.
Using an e-mail address as your identifier kind of defeats the purpose.
Google's webfinger takes this approach, using TXT records to map your email address to an XRD document. But this adds a lot more complexity and means doing an extra HTTP request - so now it's much slower than a single DNS query and there's probably a SPoF.
it wouldn't have to be a SPoF, you'd just replicate your server and add an additional record, if the client can't reach the first server it failovers (failsover? fails over?) to the next one.
I don't think it adds to the complexity too much and it's hardly going to be slow - it'd be much faster than the time it takes to send even the smallest email message.
Well, if you're looking up a name, for example from a dialer on a mobile device, or navigating through some kind of directory service; are you going to be happy hanging around for a HTTP request (or several)?
DNS was born to do this; it's lightweight, super fast and wonderfully distributed. :)
A fraction of a second delay probably wouldn't be noticeable to the end user - you'd only ever lookup the number when actually making the call. DNS may be distributed but that's part of the problem - you can't just set your address to redirect to another number when you're out on lunch - it'd take too long for the changes to propagate through the system. You wouldn't put email addresses at the DNS level, so why do this?
>A fraction of a second delay probably wouldn't be noticeable to the end user
It is (try it), and retries/outages would be very noticeable. One of the applications I'm particularly interested in is directory services, and as you can imagine browsing through trees is extremely sensitive to responsiveness. Dialing a name should also be near instantaneous.
>DNS may be distributed but that's part of the problem - you can't just set your address to redirect to another number when you're out on lunch
You can (.tel allows you to switch between "profiles").
>it'd take too long for the changes to propagate through the system.
You can set TTLs to whatever you like (60 by default).
26 comments
[ 0.26 ms ] story [ 65.5 ms ] threadAt the time, I tried to get a quote for tom.tel but they were in their initial "companies only" stage. I believe Google or Facebook could more easily make a service like this successful, but I hope it takes off.
Their main webpage is http://www.telnic.org/ and they're in wide release now. Unfortunately, tom.tel is already taken ;-)
With ipv6 we could each get a static IP as well.
BTW.. The individual static IPv6 addresses seems unlikely also. Because of the much larger address space provided by IPv6, there's a great deal of concern about the potential of massive increases in the size of the routing tables for Internet backbone routers. Because of this, one of the goals of the IPv6 Allocation and Assignment Policy is "Aggregation". Addressing is going to be assigned strictly on the basis of network topology to maximize the ability to to do route summarization. Relatedly, one of the policy goals for the IPv6 Allocation and Assignment Policy is that IP addresses are not to be considered private property. Unlike IPv4 where many non-ISP organizations "own" a block of IP addresses, in IPv6 the policy will be that IP addresses are only leased, never owned.
* Most people don't own a .com (or .whatever) for personal use - and never will - so what are the advantages?
* The suffix indicates the capability. It wouldn't be obvious that andrewtj.com contained your contact records. I'm not sure how you could change public perception of .com/etc, but you at least have a shot at it with a TLD exclusively for this purpose.
* TelHosting providers are obligated to provide standard public APIs, and there are also specs for consuming structured data from DNS. Would you use these, or create your own?
* For people who do own a .com they most likely won't be running their own nameservers, so you'd have to persuade nameserver operators to agree on API specs and run your management software.
* .tel has a system for brokering encryption keys used to encrypt/decrypt records - if you want privacy you'd need a system like this.
* Using a common namespace offers us a publicly accessible zone - convenient!
* Marketing. Hundreds of registrars selling a common branded product gives it the best chance of adoption.
* It's actually pretty hard to do by all accounts.
I have nothing to do with Telnic - I'm just an advocate/fanboy :)
Whilst that's true, when someone decides to purchase a domain, why would they buy a .tel when there's other namespaces with more freedoms? I'd be surprised if .tel takes off in preference to .id.au in Australia for instance; — I know which domain I prefer and pay for.
* The suffix indicates the capability. It wouldn't be obvious that andrewtj.com contained your contact records. I'm not sure how you could change public perception of .com/etc, but you at least have a shot at it with a TLD exclusively for this purpose.
I'm not sure that this is as practical a benefit as it sounds. If you were to ask me what my ".tel" is and I responded, just use "andrew.tj.id.au" you'd plug it in and use it. If you were to use andrew.tj.id.au on a computer, you'd likely consume it without even thinking about it.
* TelHosting providers are obligated to provide standard public APIs, and there are also specs for consuming structured data from DNS. Would you use these, or create your own?
* For people who do own a .com they most likely won't be running their own nameservers, so you'd have to persuade nameserver operators to agree on API specs and run your management software.
* .tel has a system for brokering encryption keys used to encrypt/decrypt records - if you want privacy you'd need a system like this.
I've written a DNS server and run a DNS service so it's a bit disingenuous for me to answer these questions. That said, I would and am considering providing the infrastructure for myself and others.
* Using a common namespace offers us a publicly accessible zone - convenient!
I'm not clear on what benefit this outlines?
* Marketing. Hundreds of registrars selling a common branded product gives it the best chance of adoption.
* It's actually pretty hard to do by all accounts.
Agreed on both accounts. The later is part of the reason for my lack of enthusiasm for it.
What freedoms are you referring to?
>I'm not sure that this is as practical a benefit as it sounds. If you were to ask me what my ".tel" is and I responded, just use "andrew.tj.id.au" you'd plug it in and use it.
Fair enough, it would be great to reach that point!
>I'm not clear on what benefit this outlines?
Search. That's what I'm working on :)
>Agreed on both accounts. The later is part of the reason for my lack of enthusiasm for it.
But it works :) And from a developers perspective it's easy - there's a bunch of apps you can play with (iPhone, Blackberry, softphones, etc).
I can point the A records for any other domain anywhere I like but with .tel I'm stuck with the providers choice (or have I misunderstood?).
> Search. That's what I'm working on :)
Ah, I can see how that would be problematic. Do you have a blog or something I can follow your progress on?
Ah I see. Yes, the Address record stays pointing at the TelProxy web server (incidentally a major overhaul will be released later this month). Anyway, I don't personally see this as a matter of "freedom" - better to keep the focus on its intended purpose.
>Ah, I can see how that would be problematic. Do you have a blog or something I can follow your progress on?
andy.tel - no blog, but I tweet, mostly rubbish. :-)
Could they make it any more complicated than this?
Why?
>Could they make it any more complicated than this?
It may look messy, but complicated? You can write a parser in a few minutes. It's simple and it works.
Complicated - because of regexes and usage of prefixes such as E2U which don't make sense here. Someone created a service based on a custom TLD and marks the entries as E2U even though they don't use E.164 numbers at all. If they cannot get it right, how can users understand it?
FYI the spec changed between rfc2916 and rfc3761:
Also see: http://www.iana.org/assignments/enum-servicesThat scares me. It then becomes simple for anyone with an internet connection to pull the phone and email addresses of anyone using this. DNS isn't exactly designed to withstand that kind of abuse (You can't block someone, you can't ratelimit someone, etc).
>DNS isn't exactly designed to withstand that kind of abuse (You can't block someone, you can't ratelimit someone, etc).
It's hard to take out somebody's nameservers, since there's no single point of failure (unlike with most web setups). But even then there's still (hopefully) some resolvers with cached records :)
Perhaps this is a dumb question: How does that solve the problem? Either its readable by all or by none.
It's hard to take out somebody's nameservers, since there's no single point of failure (unlike with most web setups). But even then there's still (hopefully) some resolvers with cached records :)
I think you may have missed the point. He's not worried about the data being unavailable, quite the opposite.
There's a service called TelFriends that brokers keys between you and your friends.
Ordinary people don't have to care about that - typically their username/password is used in whatever app they're using to transparently decrypt records on the fly.
And since we're talking about privacy, you own your domain and its data - not Telnic, Google, or Facebook.
(Web hits are even easier than DNS. Why not telnic.org/henri instead of henri.tel? Both could, at Telnic's discretion, imply the exact same thing. One just makes it even clearer you're bought-into a single company's namespace. But that's a bug, not a feature.)
I also think that not allowing you to host a website at .tel is a fatal mistake. The group of people who'd prefer to look up their friend's phone number from console is tragically small. The hope I suppose is that Google indexes my .tel, and people then find my number through Google, but then why do I need the .tel?
Finally, what's with the registrar ballot screen that doesn't list prices? For anyone who's wondering, name.com looks the cheapest ($10).
"This is pretty cool because it means that anything that can speak DNS (pretty much everything) could have programmatic access to this data."
I don't think this offers an advantage over my solution, as any application that needs to use this will have to be modified anyway, the protocol I'm proposing would be equally trivial (or not) to implement.
Google's webfinger takes this approach, using TXT records to map your email address to an XRD document. But this adds a lot more complexity and means doing an extra HTTP request - so now it's much slower than a single DNS query and there's probably a SPoF.
Simplicity wins.
DNS was born to do this; it's lightweight, super fast and wonderfully distributed. :)
It is (try it), and retries/outages would be very noticeable. One of the applications I'm particularly interested in is directory services, and as you can imagine browsing through trees is extremely sensitive to responsiveness. Dialing a name should also be near instantaneous.
>DNS may be distributed but that's part of the problem - you can't just set your address to redirect to another number when you're out on lunch
You can (.tel allows you to switch between "profiles").
>it'd take too long for the changes to propagate through the system.
You can set TTLs to whatever you like (60 by default).