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

From: "Gould, James" <[email-masked]>
Date: Tue, 3 Jun 2014 21:20:41 +0000

It has been a while since we’ve discussed this thread.  Have the draft-ietf-eppext-idnmap authors considered the feedback to include in a new version of the draft?  Is there a plan for an EPPEXT meeting at the next IETF meeting in Toronto, where this can be worked out?  In review, I included a proposal to support two models in draft-ietf-eppext-idnmap that offer the choice of language or table.  The text for the create could specify the use of either the <idn:language> or <idn:table> element based on server policy.   Ideally an <idn:create> element would be defined in the XML schema that made <idn:language> and <idn:table> a choice.   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.

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: Friday, April 25, 2014 at 9:23 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>, 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

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]<mailto:[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

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 3 Jun 2014 15:00:47 -0700

On Jun 3, 2014, at 2:20 PM, Gould, James <[email-masked]> wrote:

> It has been a while since we’ve discussed this thread.  Have the draft-ietf-eppext-idnmap authors considered the feedback to include in a new version of the draft?  Is there a plan for an EPPEXT meeting at the next IETF meeting in Toronto, where this can be worked out?  

I don’t have plans to be at that meeting, but I can certainly participate remotely if we need an in-depth discussion.

> In review, I included a proposal to support two models in draft-ietf-eppext-idnmap that offer the choice of language or table.  The text for the create could specify the use of either the <idn:language> or <idn:table> element based on server policy.   Ideally an <idn:create> element would be defined in the XML schema that made <idn:language> and <idn:table> a choice.   

We had a discussion a long time ago whether we should use <idn:language> or <idn:table>, and we decided to go for the latter, because of the complications of calling “scripts” as languages, etc. the term “table” was neutral so we went for that instead.

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

This is another complicated issue, table identifiers are registry specific, and usually match some sort of registry policy. I don’t believe that this extension should aim at standardizing the table identifiers, but instead, we should just let registries define them as part of their local policies.

If standardization ever happens, all we need to do is update registries IDN policies, but not the IETF standard.

The other piece has to do with the automatic language detection that you talked about last time. I’m not sure if that is better than having the RAR pass it along every time. A registry could have overlapping unicode code point tables associated with different policies, so letting the server choose one could introduce some uncertainty to the RAR and registrant, while passing the <idn:table> all the time does not.

I’ll try to push a change to the text by end of the week, and we can review it from there.

[email-masked]
PGP Key ID: 0xB38DB1BE

---

From: "Gould, James" <[email-masked]>
Date: Fri, 6 Jun 2014 19:30:38 +0000

Francisco,

I will not be able to make the IETF in person, but will attend remotely if there is a meeting.

As stated previously on the list, <idn:table> is too generic and implies some level of pre-coordination between the clients with each server to be able to register IDN domain names.  I have the following questions:

  1.  In the examples provided on the list, how would the client know to pass “com_latn_1.1” for the .com domain name?   Can you describe the steps that the client can or should make?
  2.  Is there some implied relationship between the table / script tables loaded to the IANA site to the <idn:table> values, or is the <idn:table> scheme completely up to server policy?
  3.  Should the server provide some mechanism for clients to query for the correct set of <idn:table> values?  If so, do you have a proposal for the mechanism?
  4.  Is the client required to auto-detect the appropriate <idn:table> value based on pre-loading the tables on a per-TLD basis from the IANA site?
  5.  Do you believe that use of language codes per ISO 639-2 can be used for the <idn:table> values?

Thanks,

--

JG

James Gould

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

On 6/3/14, 6:00 PM, "Francisco Obispo" <[email-masked]<mailto:[email-masked]>> wrote:

On Jun 3, 2014, at 2:20 PM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote: