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

[Stuart Olmstead-Wilcox <[e-mail]>]

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:[e-mail]] 
Sent: May-25-15 10:45 AM
To: [e-mail]
Cc: Stuart Olmstead-Wilcox; Jacques Latour; [e-mail]
Subject: Re: [eppext] Fwd: New Version Notification for draft-wilcox-cira-idn-eppext-00.txt

Hello Jean-François, Jacques and Stuart,

JF Tremblay <[e-mail]> 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

"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?

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.

Same problem at the end of §5.1.1

- 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