Domain check in draft-obispo-epp-idn-00.txt

BTW on language versus script I agree fully, it should be language not
script,

On another note:

Francisco I am looking again at the old IDN I-D
http://tools.ietf.org/id/draft-sienkiewicz-epp-idn-00.txt and note that
your draft excludes the check command.

An operational nit:

So the reason it was included in the sienkiewicz draft is to reduce
operational overhead.  If the registrar is unsure whether a character is
included in the relevant language table (or a combination of characters)
they can perform a domain check with the questionable punycode. If its not
included in the implementation's language table or the combination is not
permitted, the domaincheck comes back as not available with a specified
reason.

Note that the term script is used interchangeably with the concept of
language.  It was a poor choice at the time to not clear make the
distinction but it was intended in implementation that the idn:script
element value was really a "language tag". It probably should read
something like idn:langtag instead.  These examples are all from the .Info
implementation for german "de"


C:    </create>
   C:    <clTRID>CLI-1097602657409</clTRID>
   C:    <extension>
   C:      <idn:create xmlns:idn='urn:iana:xml:ns:idn'
   C:                  xsi:schemaLocation='urn:iana:xml:ns:idn idn.xsd'>
   C:        <idn:script>de</idn:script>
   C:      </idn:create>
   C:    </extension>
   C:  </command>
   C:</epp>





When a <check> request contains an IDN whose translated punycode
   <domain:name> value contains character(s) that are not in the script
   table specified in the <idn:script> element value, the <domain:cd>
   element MUST indicate that the IDN is NOT available.

   Example <check> response when <domain:name> value has conflict with
   the value of <idn:script> element:

   S:<epp xmlns='urn:ietf:params:xml:ns:epp-1.0'
   S:     xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   S:     xsi:schemaLocation='urn:ietf:params:xml:ns:epp-1.0
   S:     epp-1.0.xsd'>
   S:  <response>
   S:    <result code='1000'>
   S:      <msg lang='en-US'>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:      <domain:chkData
   S:              xmlns:domain='urn:ietf:params:xml:ns:domain-1.0'
   S:              xsi:schemaLocation='urn:ietf:params:xml:ns:domain-1.0
   S:              domain-1.0.xsd'>
   S:        <domain:cd>
   S:          <domain:name avail='0'>xn--dn-mja.info</domain:name>
   S:          <domain:reason>Character from an invalid script
   S:          </domain:reason>
   S:        </domain:cd>
   S:      </domain:chkData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>CLI-1065207438144</clTRID>
   S:      <svTRID>SRO-1097599157873</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

 


This saves having to fail a domain create discover the same thing, a more
expensive transaction for the registry. Now of course with the excessive
add grace policy with GTLDs, you also probably don't want to generate
creates experimentally, even if you delete them in the five day add grace
period - you might end up getting charged.

Best Regards,

Michael Young
M:647-289-1220



>


_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg