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

Hi,

[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,

Yes.

 >  albeit one that has its origins in ENUM.

No.

Uniform Resource Names.

 >  The only implementation
> of DDDS that I'm aware of is RFC3403, and *that* is what specifies NAPTR 
> records, not the ENUM RFCs.

Yes.

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

Yes.  The interesting question is whether that would (or should) allow 
differences of use of ENUM (i.e., different dialing plans), which seems 
to be part of the hearburn here.


Leslie.

>  
> 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.
> 
> Ray
> 
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email protected]
-------------------------------------------------------------------