Re: Send-N draft: draft-bellis-enum-send-n-02 published

On 3 Jul 2008, at 15:44, Edward Lewis wrote:
> The kinds of mail threads I detest most are ones about what  
> something is "supposed" to be.  I can't agree that DDDS is  
> "supposed" to be a generic database, because the DNS upon which it  
> is built is not a database - just a lookup system.
>
> I think of it this way - DNS is a piece of infrastructure.  It  
> should be quick, reliable, and never noticed by the end user.  A  
> database is something more complex.  DDDS, ENUM, DNS - all are  
> lookup mechanisms, not database mechanisms.

When I first started playing with NAPTRs on the .tel project I had  
lots of fun pushing them as far as they could be pushed just to find  
out what's possible and where they break. Once you start playing  
they're addictive :)

But having explored some particularly deep rabbit-holes I've come to  
the conclusion that DNS is not the place for any of them. As you say,  
DNS is infrastructure and it should be quick, reliable and innocuous.  
The NAPTR extends it elegantly to address unconventional resources  
(telephones with ENUM, people with .tel, web services, map grid  
references, whatever) but those resources should always remain  
separate from the DNS tree itself.

What makes send-n interesting is that it's neither a link nor a  
resource, but introspective meta-data. I can see the logic of a  
standard NAPTR that links to this data by generating an appropriate  
URI but using a NAPTR to embody the data itself feels somewhat akin to  
using an HTTP GET resource to update a database. This is the reason I  
feel send-n would be better handled via a different RR type  
specifically geared to tree introspection and validation.

I can't comment on whether or not such a generic solution has uses  
beyond ENUM or how acceptable it will be to the wider DNS community.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net