"u" "E2U+web:http" "!^.*$!http://www.windley.com!"
Could they make it any more complicated than this?
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."
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?
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.
"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.
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 ;-)
With ipv6 we could each get a static IP as well.
* 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.
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).
(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.)