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

At 13:47 +0100 7/3/08, [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?

(Not speaking for Peter...)

For one, the send-n draft.  For two a draft I wrote last year.

The draft I wrote was presented at the ENUM WG meeting in spring '07 
(Prague). I sought to record the E.212 information for a telephone 
number.  After "fleshing it out" and some discussions, it was 
withdrawn - well, left to expire.

It is tempting to define more and more schemes and (ENUM) services. 
There's no clean set of criteria to judge this, but there's a point 
at which "one more feature" is "mission creep."  The former is 
desirable, the latter a cancer.

>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.

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.