Hi All,

I would like to raise an issue with this draft which is currently in "Last 
Call" in regards to the storage of the <e164:natpr> extension element:

Currently:

        3.1.2  EPP <info> Command

        .
        .


        The <e164:infData> element contains one or more <e164:naptr> elements
        that contain the following child elements:

        .
        .

        3.2.1  EPP <create> Command

        .
        .

        The <e164:create> element contains one or more <e164:naptr> 
        elements that contain the following child elements:

        .
        .

        3.2.5  EPP <update> Command

        .
        .

        The <e164:update> element contains one or more <e164:add> or 
        <e164:rem> elements.  Each <e164:add> and <e164:rem> element  
        contains an <e164:naptr> element that contains the following 
        child elements:
        
        .
        .

Objection:

        The mandatory inclusion of one or more <e164:naptr> elements is 
the major point of contension.  By way of using the current epp schema for 
domain mapping, <ns> elements may be used to point to external DNS servers 
which will host the owning NAPTR records.  Thus creating a "thin" enum 
registry while still accepting and generating "referral" e164 domains.  
This allows the registry to host the native NAPTR records and all the  
personal details that come along with that data or allow an external name  
service to host these dynamic NAPTR records.

        As a further extension to the current support for <e164:naptr> is 
the ability to allow <e164:cname> or <e164:dname> support.  These would 
work much like the above <ns> approach, in that the zone generated 
by the registry would point to an external DNS that would then resolve  
the actual NAPTR records for public use.  While these are more experimental 
additions, they are a valuable addition to the draft, while enum trials 
are taking place to see how usability case studies perform in the real world.  

        To ensure the integrity of the e164 domain, only one of the four 
types may be associated with an e164 domain at a time.  The four types are 
<ns>, <e164:naptr>, <e164:cname> and <e164:dname>.  This way the zone 
generated for the e164 domain names will have a deterministic output each 
and every time.  

frank thompson
Afilias Canada Inc. 


_______________________________________________
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Reply via email to