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

[Patrick Mevzek <[e-mail]>]

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