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

On 3 Jul 2008, at 13:47, [email protected] wrote:
> Peter - following up this comment again:
>
>> Apologies.  NAPTR is becoming the TXT RR for enum; everything can  
>> be put
>> in there so conveniently, especially using "data" type URIs.   
>> That's not
>> what NAPTR was designed for.
>
> I wonder where this concern about NAPTR becoming a dumping ground  
> for data
> has come from?
>
> The whole DDDS architecture is *supposed* to be a generic database  
> lookup
> system, albeit one that has its origins in ENUM.  The only  
> implementation
> of DDDS that I'm aware of is RFC3403, and *that* is what specifies  
> NAPTR
> records, not the ENUM RFCs.
>
> One *could* write a Send-N U-NAPTR Application that sits in its own  
> DNS
> tree that happens to represent the structure of some other DNS  
> tree.  That
> might not be so controversial, but it would *still* be using NAPTR
> records.
>
> As it happens, though, it's actually possible to put the data in the
> *same* DNS tree, albeit there are a couple of special edge cases  
> that have
> to be taken into consideration.

This probably isn't the time or place to mention it (and apologies to  
those of you who've sat through discussion of these in the company of  
beer) but NAPTRs can be used for all kinds of fun purposes once you  
start thinking of them as generic production rules or s-expressions:  
URI validation; cross-service API translation and aggregation;  
relational data stores; multi-directional hyperlinks; all kinds of fun  
stuff.

I wouldn't necessarily advocate any of these as real world  
applications mind as they're outside the scope of DNS's core purpose,  
but it is amazing just how flexible a tool the U-NAPTR can be.


Ellie

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