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

From: "Gould, James" <[email-masked]>
Date: Fri, 7 Mar 2014 22:31:33 +0000

Hi,

I want to provide some feedback to draft-ietf-eppext-idnmap.  We have created a similar extension, that we call IDN Language Tag ( http://www.verisigninc.com/assets/idn-language-tag.pdf ), where there is only an extension to the domain create for passing the language tag for the IDN domain name.

  1.  I recommend support for an extension to the info command (e.g. empty <idn:info> element) to have the client explicitly specify the desire to get the additional IDN information in the response.  I’m not sure if implicitly returning the extension in all IDN domain info responses based on the login services is necessary.

  2.

I recommend adding support for a separate client specified language or lexicon element along with the server determined table element.  A client may specify a language that does not actually match the actual IDN table or script table detected by the server.  The table element should be fully defined in the draft and hopefully would map to the tables posted to IANA by the registry.

  3.

If there is a client specified language / lexicon, then the command extension could have a specific element like <idn:create> that takes the language and optionally the uname.  An extension to the domain create response could then include the language, server determined table, and optionally the uname.  The mapping of the client specified language / lexicon to the language / script table is up to server policy, but it does not need to be one-to-one.

  4.  Why is the uname required in the info response?  My recommendation is to make it optional and returned based on server policy.

in summary, I recommend having an extension to the info command (empty <idn:info>) element, an extension to the info response (<idn:infData> containing the client-specified language / script, server-determiend table, and optionally the uname), an extension to create (<idn:create> containing the client-specified language / script and optionally the uname), and an extension to the create response (<idn:creData> containing the client-specified language / script, server-determined table, and optionally the uname).

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com
“This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 10 Mar 2014 13:21:58 -0700

Hi James,

My response below:

On Mar 7, 2014, at 2:31 PM, Gould, James <[email-masked]> wrote:

> 	• I recommend support for an extension to the info command (e.g. empty <idn:info> element) to have the client explicitly specify the desire to get the additional IDN information in the response.  I’m not sure if implicitly returning the extension in all IDN domain info responses based on the login services is necessary.  

Since the amount of data that the extension carries is very small, we opted to just pass it along as other extensions do (RGP).

Having a separate <info> command, in my opinion will add unnecessary complications.

> 	• I recommend adding support for a separate client specified language or lexicon element along with the server determined table element.  A client may specify a language that does not actually match the actual IDN table or script table detected by the server.  The table element should be fully defined in the draft and hopefully would map to the tables posted to IANA by the registry.

We had this discussion (or similar), in the provreg mailing list a while ago, and we decided to move away from the term ‘language’ in the extension to avoid any complications on what is or what is not a language. Instead, we are taking an IDN table identifier, that contains set of unicode code points that are allowed. The server checks whether the code points contained in the label are a subset of the table, and permits or rejects based on that.

> 	• If there is a client specified language / lexicon, then the command extension could have a specific element like <idn:create> that takes the language and optionally the uname.  An extension to the domain create response could then include the language, server determined table, and optionally the uname.  The mapping of the client specified language / lexicon to the language / script table is up to server policy, but it does not need to be one-to-one. 

I’m not sure if the server should be determining the IDN table. The idea behind this was to capture the registrant’s intent to register a name that was written in a specific script or language, avoiding ambiguity and unnecessary server processing.

> 	• Why is the uname required in the info response?  My recommendation is to make it optional and returned based on server policy.    

I personally thought that it would be useful to always have it present, because it provides the client with a mean to verify that the server processed it correctly.

> in summary, I recommend having an extension to the info command (empty <idn:info>) element, an extension to the info response (<idn:infData> containing the client-specified language / script, serve…

Summary of my response: 

* I personally prefer the approach that the RGP extension has, which is to 
  carry it based on the extensions selected on the <login> command. The main 
  reason is to avoid complexity, specially since the payload is very small. 

* I would stick to the IDN table identifier, and would simply avoid brining
  the “language” term in the extension to avoid complications on what it is
  or what is not a language, at the end of the day, it is of no use within
  the extension, because all we want to achieve is a registration based on
  a limited set of unicode code points that are coming from a registry-specified
  table. This was discussed in the PROVREG mailing list and triggered a change
  in our draft to reflect it, in fact, the field was originally being validated
  with the XML Schema ‘language’ type.

Thanks for the feedback,

Francisco

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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 10 Mar 2014 21:26:24 +0000

Francisco,

My feedback to your feedback is below.

-- 
 
JG

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

On 3/10/14, 4:21 PM, "Francisco Obispo" <[email-masked]> wrote:

>> I want to provide some feedback to draft-ietf-eppext-idnmap.  We have
>>created a similar extension, that we call IDN Language Tag (
>>http://www.verisigninc.com/assets/idn-language-tag.pdf ), where there is
>>only an extension to the domain create for passing the language tag for
>>the IDN domain name.
>> 	€ I recommend support for an extension to the info command (e.g. empty
>><idn:info> element) to have the client explicitly specify the desire to
>>get the additional IDN information in the response.  I¹m not sure if
>>implicitly returning the extension in all IDN domain info responses
>>based on the login services is necessary.
>
>
>Since the amount of data that the extension carries is very small, we
>opted to just pass it along as other extensions do (RGP).
>

My thought was to make returning this information optional and for the
client to explicitly request in an extension to the info command, but I
guess that your choice is to implicitly return the extension for all IDN
domain names.  I would prefer for the uname to be optional in the response
so not to require the server to act as an implicit converter for every
info command of an IDN domain name.

>
>
>> 	€ I recommend adding support for a separate client specified language
>>or lexicon element along with the server determined table element.  A
>>client may specify a language that does not actually match the actual
>>IDN table or script table detected by the server.  The table element
>>should be fully defined in the draft and hopefully would map to the
>>tables posted to IANA by the registry.
>
>We had this discussion (or similar), in the provreg mailing list a while
>ago, and we decided to move away from the term Œlanguage¹ in the
>extension to avoid any complications on what is or what is not a
>language. Instead, we are taking an IDN table identifier, that contains
>set of unicode code points that are allowed. The server checks whether
>the code points contained in the label are a subset of the table, and
>permits or rejects based on that.

Does the table identifier have to match the identifier posted to IANA by
the server?  If so, there is no standard used for these identifiers, which
means that clients will have to determine what to pass with each and every
server.     Even if it doesn¹t need to match, the identifiers are server
specific.  For example, our server could choose language as the table
identifier scheme and another server could decide to use numeric values
for the table identifier scheme.  How does the client know what to pass?
In our system we have 14 language tables and 86 script tables, where if a
language does not match a language table, the code points of the domain
name must fall into a single script table (commingle filter).  The server
can easily determine the scripts that a domain name represents, so the
client passing the script table identifier does not add value but adds
complexity for the client.  The passing of the language does add value
since the language is not implicit in the domain name.

>
>
>> 	€ If there is a client specified language / lexicon, then the command
>>extension could have a specific element like <idn:create> that takes the
>>language and optionally the uname.  An extension to the domain create
>>response could then include the language, server determined table, and
>>optionally the uname.  The mapping of the client specified language /
>>lexicon to the language / script table is up to server policy, but it
>>does not need to be one-to-one.
>
>I¹m not sure if the server should be determining the IDN table. The idea
>behind this was to capture the registrant¹s intent to register a name
>that was written in a specific script or language, avoiding ambiguity and
>unnecessary server processing.

This is covered in the previous feedback.

>
>
>> 	€ Why is the uname required in the info response?  My recommendation
>>is to make it optional and returned based on server policy.
>
>I personally thought that it would be useful to always have it present,
>because it provides the client with a mean to verify that the server
>processed it correctly.

I can see this in an extension to the create response, but not as a
requirement for the info response.  In the ladder case, the server is
acting as a punycode to unicode converter.

>
>> in summary, I recommend having an extension to the info command (empty
>><idn:info>) element, an extension to the info response (<idn:infData>
>>containing the client-specified language / script, server-determiend
>>table, and optionally the uname), an extension to create (<idn:create>
>>containing the client-specified language / script and optionally the
>>uname), and an extension to the create response (<idn:creData>
>>containing the client-specified language / script, server-determined
>>table, and optionally the uname).
>> 
>
>
>Summary of my response:
>

This is more of a personal preference for this extension, so I¹m fine with
keying off of the <login> services.

>  the ³language² term in the extension to avoid complications on what it
>is
>  with the XML Schema Œlanguage¹ type.

My main concern requiring the client to specify server specific table
identifiers that are not standardized.  I prefer sticking with a standard
identifier like language and leave the mapping to language or script
tables up to the server.

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 10 Mar 2014 21:04:48 -0700

This is a complicated problem to solve. It was one of the reasons why we switched to “table” from “language”.

Defining what can be registered or not is a server policy issue that the only way we could solve it is by passing an identifier. In fact in our registry we have created a set of identifiers to match certain language “tags”, but the component that we wrote for our database can support multiple tables with a specific name, so we can support things like “com-es”, “com-it”, etc. if needed.

I would really like to standardize it, but it’s beyond the purpose of this extension.

Also on the server language/table discovery issue, what if a name matches multiple tables? what if multiple tables had different registration policies? We decided to keep it simple, and the table must be passed along by the registrar which at the end, shows the intent of the registration and its associated policy to be applied.

Thanks for feedback again!

---

From: "Gould, James" <[email-masked]>
Date: Tue, 11 Mar 2014 17:02:54 +0000

Francisco,

I have the following issues with draft-ietf-eppext-idnmap that I would like addressed:

  1.  The <idn:uname> should be optional in the info response.
  2.  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?

--

JG

James Gould

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

On 3/11/14, 12:04 AM, "Francisco Obispo" <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 10, 2014, at 2:26 PM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 12 Mar 2014 19:51:48 -0700

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

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

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Mar 2014 14:16:24 +0000

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

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,

Francisco