Subject: Re: [eppext] New Version Notification for draft-wilcox-cira-idn-eppext-00.txt

From: Patrick Mevzek <[email-masked]>
Date: Tue, 2 Jun 2015 00:47:36 +0200

JF Tremblay <[email-masked]> 2015-05-28 21:00
> > - you use the term 'repertoire' where most other documents speak about
> >  'IDN table'.
> > I understand there are multiple extensions dealing with IDNs right
> > now.
> > It seems to me however that 'IDN table' is the dominant term, so maybe
> > you should try to switch over it too?
> 
> Remember this first version of the draft is meant to document the current implementation at CIRA, and therefore uses their vocabulary. This implementation was done a few years back, before most eppext drafts. 
 
Yes, my comments are just coming as a developer having to implement
many extensions at the same time, seeing how they could
interact/overlap/work together/etc…
So it is not a reflection of the past, but maybe ideas for the future,
if some work happens on a given extension.
 
> > So maybe the repertoire type should be changed to allow such values,
> > and not be restricted to 2 characters long strings.
> 
> My point exactly. Let’s not restrict it to 2 characters only. 
 
I completely agree.

> The larger question here is: are there elements in this draft that are interesting for standardisation as separated extensions and not covered by other drafts? 
 
There are *many* drafts about IDNs. There could be a workshop/working
group only for this subcase, with easily enough work.

> > "If the queried domain is an IDN domain in A-label format,"
> > 
> > Why restrict the response only when queried with an IDN?
> > (also by the way note that IDN domain is redundant, so maybe rephrase
> > it?)
> > Even if you have only the pure ascii domain name it could be
> > interesting to have the bundle info, so we should get the reply in all
> > cases, no?
> 
> Interesting point. But wouldn’t that cause confusion or errors for registrars not supporting IDN? At CIRA, only a small subset of registrars implement IDN (did Jacques mention 15 out or 150 at the last ROW?). 
 
If a registrar does not support IDN, it does not present the
cira-idn/cira-idn-bundle EPP extension at login time, and hence later
in the same exchange you do not send him this information.
Except if you make these extensions mandatory at login.

> > - §5.2.1
> > "The server answer is not
> >   modified by this extension except for return codes."
> > The core EPP RFCs however do not allow to extend the list of return
> > codes.
> > Same problem at the end of §5.1.1
> 
> Must have missed that. Is that explicitly stated somewhere (that the return codes can’t be modified)? 
 
It is a common need of many registries. Some put these extra error
codes in their own extension, which would be protocol-correct but
cumbersome. Others do extend the list of error codes, however RFC5930
has this schema:

       <attribute name="code" type="epp:resultCodeType"
        use="required"/>

<simpleType name="resultCodeType">
       <restriction base="unsignedShort">
         <enumeration value="1000"/>
         <enumeration value="1001"/>

etc…

         <enumeration value="2502"/>
       </restriction>
     </simpleType>

hence, no way to add some new ones…

> How could an extension manage to return meaningful errors when it introduces new behaviors, then? A generic error might be returned, but it’s not really helpful. 

That is indeed a current problem without good solutions.

> For example, in this case, some errors codes were introduced to cover an invalid IDN-table, mismatching domain registrant an bundle registrant, etc. 

An updte of RFC5930 could maybe add items to the list, as it would be
forward-compatible schema-wise. But without coordination among all
participants this would go nowhere.

-- 
Patrick Mevzek

---

From: Stuart Olmstead-Wilcox <[email-masked]>
Date: Thu, 11 Jun 2015 18:11:29 +0000

Hi Patrick,

Apologies for the delayed reply.    Great to hear that you are implementing our draft and thanks for the great feedback!

I have taken a quick read and will provide a more detailed response in the next couple of days.   Regarding your comment on IDN table vs repertoire - can you point me at some of the documents you are referencing?   Draft's such as draft-obispo-epp-idn-04 use IDN table but I am not aware of other references.   

Thanks,
Stu

-----Original Message-----
From: Patrick Mevzek [mailto:[email-masked]] 
Sent: May-25-15 10:45 AM
To: [email-masked]
Cc: Stuart Olmstead-Wilcox; Jacques Latour; [email-masked]
Subject: Re: [eppext] Fwd: New Version Notification for draft-wilcox-cira-idn-eppext-00.txt

Hello Jean-François, Jacques and Stuart,

JF Tremblay <[email-masked]> 2015-03-06 17:16
> As discussed in Honolulu, a draft has now been published describing the EPP extension(s) used at CIRA to support French IDN in the .ca domain. 
> 
> Of course, a number of the objects described in the draft overlap with other drafts, for example draft-kong and idnmap. Comments are welcome. 
 
I'm implementing your draft in my Net::DRI EPP client.

Here is my feedback:

- you use the term 'repertoire' where most other documents speak about
  'IDN table'.
I understand there are multiple extensions dealing with IDNs right now.
It seems to me however that 'IDN table' is the dominant term, so maybe you should try to switch over it too?

- "The CIRA IDN EPP extension defines three objects named createType,
   infDataType and checkType, respectively used in <create>, <info> and
   <check> EPP commands."

These are not EPP objects, so I think you should rephrase that sentence. The same problem appears later on with titles of sections 4.1, 4.2 and 4.3

- "The string used to identify a repertoire may be similar in content
  to a language tag, but shouldn't be confused with a language, as the
   character set approved by policy by a registry may represent a subset of an official language's character set. "

I disagree with this for at least 2 reason
1) a language as defined by BCP47 can specify a country to say "this language as spoken in this country", hence fr-CA would be a valid language tag
2) the own reference you cite (section 1.3 of RFC4290) says "In this context, a "language" is
   defined by the combination of a code (see Section 1.4.1) and an
   authority that has chosen to use that code and establish a
   character-listing for it."

Hence a registry can completely choose to use a subset of an official language's character set notwithstanding however, like explained in the above RFC, that it may create confusion for the whole ecosystem when there is no consensus/common view among all actors using the same languages.

So maybe the repertoire type should be changed to allow such values, and not be restricted to 2 characters long strings.

- as a general comment I feel the draft difficult to read because it
  mixes up operation in the cira-idn namespace and in the cira-idn-bundle namespace. I believe they should be better separated, even if not in two separate drafts.

- §5.1.2.1

Why restrict the response only when queried with an IDN?
(also by the way note that IDN domain is redundant, so maybe rephrase
it?)
Even if you have only the pure ascii domain name it could be interesting to have the bundle info, so we should get the reply in all cases, no?

Also in your example you have:
   S:     <cira-idn:ciraIdnInfo
             xmlns:cira-idn="urn:ietf:params:xml:ns:cira-idn-
   S:       <cira-idn:domainVariants>

So there seems to be things missing in the cira-idn namespace declaration…

- in §5.1.2.2 I believe you should remove the
   S:     <resData>
   S:       </resData>

No need to have an empty resData node for a purely extended reply.

Also you have:
   C:     <cira-idn-bundle:info
   C:      xmlns:cira-idnbundle=
           "urn:ietf:params:xml:ns:cira-idn-bundle-1.0">
   C:       <cira-idn-bundle:name>
   C:         xn--valuation-93a.ca
   C:       </cira-idn-bundle:name>
   C:
<cira-idn-bundle:repertoire>fr</cira-idn-bundle:repertoire>
   C:     </cira-idn-bundle:info>

So you defined the cira-idnbundle namespace but then use the cira-idn-bundle namespace, with an extra hyphen.

Also, why have the names of domains in the cira-idn namespace where everything else is in the cira-idn-bundle namespace?

- §5.2.1
"The server answer is not
   modified by this extension except for return codes."
The core EPP RFCs however do not allow to extend the list of return codes.

- as you stated yourself in the specification, domainVariants and
  bundleDomains are very close, and in fact synonyms. Why not just one name for elements, even in distinct namespaces, instead of two?

- §5.2.4
The whole block is strange:
   The EPP <transfer> command is not modified by this extension.  The
   domain:name element may contain an IDN domain in A-label format.
New
   new error codes and error values may be returned based on IDN
   processing.

Maybe you should keep only the first sentence?
Same problem for §5.2.5 and same problem for result codes as explained above.

- specifically for the cira-idn-bundle:infData there is no explanation
  of each node value, even if they are straightforward.
For example is upDate the date of last modification for any domain name in the bundle? Something else?
Wouldn't be useful to have an exDate too for the bundle, being the max of all exDate of domain name variants in the bundle?

- in reply of the domain:create, wouldn't be useful to add also the
  same content as in cira-idn:ciraIdnInfo or even the full bundle data?
So that the registrar knows right at that time the list of domain names in the bundle, with all the other data.

HTH,

--
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 21 Jun 2015 19:15:09 +0200

Stuart Olmstead-Wilcox <[email-masked]> 2015-06-11 20:11
> Regarding your comment on IDN table vs repertoire - can you point me at some of the documents you are referencing?   Draft's such as draft-obispo-epp-idn-04 use IDN table but I am not aware of other references.   

I believe that this use case comes from the fact that in the IDNA2003
protocol you had a lot of tables to decide if a character is allowed
or not and various translations rules (see nameprep),
where the newer version of IDNA
switched to a procedure/algorithm-based working way.

Some documents speaking about "IDN tables", in no particular order:

* "The IDN Variant Issues Project A Study of Issues Related to the Management of IDN Variant TLDs (Integrated Issues Report)"
https://www.icann.org/en/system/files/files/idn-vip-integrated-issues-final-clean-20feb12-en.pdf

* "Guidelines for the Implementation of Internationalized Domain Names | Version 3.0"
https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en
=> "unless a corresponding policy and character table is clearly defined."

* IANA repository
http://www.iana.org/domains/idn-tables
=> IANA maintains a collection of “IDN tables”,

and
"Repository of IDN Practices — Procedures"
http://www.iana.org/help/idn-repository-procedure
=> The IANA Repository of TLD IDN Practices, also known as the ”IDN Language Table Registry“, was created to support the development of the IDN technology.

In the same way see Kim Davies draft:
http://datatracker.ietf.org/doc/draft-davies-idntables/
and specifically:
   Administrators of the zones for top-level domain registries have
   historically published their LGRs using ASCII text or HTML.  The
   formatting of these documents has been loosely based on the format
   used for the Language Variant Table described in [RFC3743].
   [RFC4290] also provides a "model table format" that describes a
   similar set of functionality.  Common to these formats is that the
   algorithms used to evaluate the data therein are implicit or
   specified elsewhere.

(of course, if this goes further, semantically those objects would not
be flat tables anymore as they encode various algorightms and rules,
but this another debate).

* Joint Engineering Team (JET) Guidelines for
         Internationalized Domain Names (IDN) Registration and
            Administration for Chinese, Japanese, and Korean
(more than 10 years ago)
http://tools.ietf.org/html/rfc3743
=> The Language Variant
   Table mechanisms described here allow JET to enforce language-based
   character variant preferences, and they set an example for those
who
   might want to use variant tables for their own policy enforcement.

and http://tools.ietf.org/html/rfc4290
=> Each registry is expected to construct (or obtain) a table for each
   language it considers relevant and appropriate.  These tables list,
   for the particular zone, the characters permitted for that
language.
   If a character does not appear as a base character (called a "valid
   code point" in the JET document) in that table, then a name
   containing it cannot be registered.  If multiple languages are
listed
   for the registration, then the character must appear in the tables
   for each of those languages.

* https://www.rfc-editor.org/rfc/rfc5992.txt
"Internationalized Domain Names Registration and Administration
            Guidelines for European Languages Using Cyrillic"
=> The registration strategy described in this document uses a table
   that lists all characters allowed for input and any variants of
those
   characters.  Note that the table lists all characters allowed, not
   only the ones that have variants.

* http://www.rfc-editor.org/rfc/rfc5894.txt
"Internationalized Domain Names for Applications (IDNA):
                 Background, Explanation, and Rationale"

=> The character rules in IDNA2008 are based on the realization that
   there is no single magic bullet for any of the security,
   confusability, or other issues associated with IDNs.  Instead, the
   specifications define a variety of approaches.  The character
tables
   are the first mechanism, protocol rules about how those characters
   are applied or restricted in context are the second, and those two
in
   combination constitute the limits of what can be done in the
   protocol.  As discussed in the previous section (Section 3.2),
   registries are expected to restrict what they permit to be
   registered, devising and using rules that are designed to optimize
   the balance between confusion and risk on the one hand and maximum
   expressiveness in mnemonics on the other.
[…]
   Under this model, registry tables will need to be updated (both the
   Unicode-associated tables and the tables of permitted IDN
characters)
   to enable a new script or other set of new characters.

HTH,

-- 
Patrick Mevzek