Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback

From: "Gould, James" <[email-masked]>
Date: Fri, 25 Apr 2014 13:23:02 +0000

I have not received any feedback publicly or privately on this proposal.  Any thoughts on this?

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: <Gould>, James Gould <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 13, 2014 at 10:16 AM
To: Francisco Obispo <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Luis Muñoz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eppext] draft-ietf-eppext-idnmap Feedback

Francisco,

How about supporting two models in draft-ietf-eppext-idnmap that matches the current and desired models supported by the servers, which is to support a choice of language or table?  The table element is intended to be a 1-to-1 match with the language or script tables posted to IANA and language is the language code per ISO 639-2.  Ideally the choice would be explicitly defined in the XML schema, but to minimize the changes, it could look like below:

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
 xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
 xmlns:idn="urn:ietf:params:xml:ns:idn-1.0"
 targetNamespace="urn:ietf:params:xml:ns:idn-1.0"
 elementFormDefault="qualified">
  <annotation>
<documentation>
Extensible Provisioning Protocol v1.0 domain name extension
schema for IDN Table selection.
</documentation>
  </annotation>
  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
  <!-- Child elements found in IDN -->
<element name="data" type="idn:idnDataType"/>
<complexType name="idnDataType">
 <sequence>
<element name="language" type="language"
    minOccurs="0"/>
<element name="table" type="eppcom:minTokenType"
    minOccurs="0"/>
<element name="uname" type="eppcom:labelType"
     minOccurs="0"/>
 </sequence>
</complexType>
  <!-- End of schema. -->
</schema>

The text for the create could specify the use of either <idn:language> or <idn:table> element based on server policy.   Ideally a <idn:create> element would be defined in the XML schema that made <idn:language> and <idn:table> a choice.

Below is an example of the create with the language:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
 <command>
   <create>
     <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
     <domain:name>xn--espaol-zwa.example.com</domain:name>
     <domain:period unit="y">2</domain:period>
     <domain:ns>
       <domain:hostObj>ns1.example.net</domain:hostObj>
       <domain:hostObj>ns2.example.net</domain:hostObj>
     </domain:ns>
     <domain:registrant>jd1234</domain:registrant>
     <domain:contact type="admin">sh8013</domain:contact>
     <domain:contact type="tech">sh8013</domain:contact>
     <domain:authInfo>
       <domain:pw>2fooBAR</domain:pw>
     </domain:authInfo>
     </domain:create>
   </create>
   <extension>
   <idn:data xmlns:idn="urn:ietf:params:xml:ns:idn-1.0">
      <idn:language>SPA</idn:language>
      <idn:uname>espa&#xF1;ol.example.com</idn:uname>
   </idn:data>
   </extension>
   <clTRID>123456</clTRID>
 </command>
</epp>

Below is an example of the create with the table (script table in this instance that can be prefixed with http://www.iana.org/domains/idn-tables/ and postfixed with .txt):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
 <command>
   <create>
     <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
     <domain:name>xn--espaol-zwa.example.com</domain:name>
     <domain:period unit="y">2</domain:period>
     <domain:ns>
       <domain:hostObj>ns1.example.net</domain:hostObj>
       <domain:hostObj>ns2.example.net</domain:hostObj>
     </domain:ns>
     <domain:registrant>jd1234</domain:registrant>
     <domain:contact type="admin">sh8013</domain:contact>
     <domain:contact type="tech">sh8013</domain:contact>
     <domain:authInfo>
       <domain:pw>2fooBAR</domain:pw>
     </domain:authInfo>
     </domain:create>
   </create>
   <extension>
   <idn:data xmlns:idn="urn:ietf:params:xml:ns:idn-1.0">
      <idn:table>com_latn_1.1</idn:table>
      <idn:uname>espa&#xF1;ol.example.com</idn:uname>
   </idn:data>
   </extension>
   <clTRID>123456</clTRID>
 </command>
</epp>

For servers that support the language model, the info response should return both the language sent as well as the resulting table that can be mapped to the IANA language or script table:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:infData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>xn--espaol-zwa.example.com</domain:name>
        <domain:roid>EXAMPLE1-REP</domain:roid>
        <domain:status s="ok"/>
        <domain:registrant>jd1234</domain:registrant>
        <domain:contact type="admin">sh8013</domain:contact>
        <domain:contact type="tech">sh8013</domain:contact>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns1.example.net</domain:hostObj>
        </domain:ns>
        <domain:clID>ClientX</domain:clID>
        <domain:crID>ClientY</domain:crID>
        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
        <domain:upID>ClientX</domain:upID>
        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
        <domain:authInfo>
          <domain:pw>2fooBAR</domain:pw>
        </domain:authInfo>
      </domain:infData>
    </resData>
    <extension>
      <idn:data xmlns:idn="urn:ietf:params:xml:ns:idn-1.0">
        <idn:language>SPA</idn:language>
        <idn:table>com_latn_1.1</idn:table>
        <idn:uname>espa&#xF1;ol.example.com</idn:uname>
      </idn:data>
    </extension>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/12/14, 10:51 PM, "Francisco Obispo" <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 11, 2014, at 10:02 AM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

Francisco,
I have the following issues with draft-ietf-eppext-idnmap that I would like addressed:
• The <idn:uname> should be optional in the info response.

We can make it optional. I’ll add that to the next draft.

• The <idn:table> is too flexible at this point.  Based on draft-ietf-eppext-idnmap the registrars have no way of knowing what table values are required for any one server.  This is a opportunity for the eppext WG to define a standard model.
My concern is related to clients having to deal with an infinite number of server policies and schemes for the <idn:table> values.  Are there any registrars out there that have the same concern?

Well registrars currently don’t have a way of knowing a lot of things, and even though I agree with you on the identifiers, there is no guarantee that the same identifier will result in the same code points, because that’s a registry policy decision.

I don’t want to create the impression that if you pass “es” as the table identifier, you’ll get the same results across all registries, in fact if you look at the tables on the IANA website, multiple registries have different identifiers, and in some cases the code points don’t even match.

So even though I agree with you in concept, I think that it is unpractical to try to standardize it.

Francisco

--
Francisco Obispo
CTO - Registry Operations
[email-masked]<mailto:[email-masked]>
PGP Key ID: 0xB38DB1BE