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

From: Patrick Mevzek <[email-masked]>
Date: Mon, 25 May 2015 16:45:22 +0200

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

"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

---

From: JF Tremblay <[email-masked]>
Date: Thu, 28 May 2015 14:55:43 -0400

Thanks for the feedback, Patrick. 

Comments inline. 

> On May 25, 2015, at 10:45 AM, Patrick Mevzek <[email-masked]> wrote:
> 

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. 

> sentence. The same problem appears later on with titles of sections

Agreed, naming them XML elements would probably be better. 

> [...] a registry can completely choose to use a subset of an official

This is a very complex topic. While I agree with your statements, a registry might very well decide not to accept all character variants in a language for policy reasons. Therefore it remains “dangerous” to strictly link an IDN-table to a two-letter language code. 

As an example, CIRA accepts all “fr” characters, including U+00FF (y trema). As a French speaker, I’ve never, ever, seen that character used. Another registry allowing French characters might decide that allowing this specific character variant would cause confusion for their user base. 

It’s a balance between possible confusion for users or possible confusion/complexity for registrars implementing the character variant set. Bottom line: the IETF doesn’t have any control on this, it remains a registry policy decision, so I suggest we keep it open for idn-tables that wouldn’t exactly match languages charsets. 

> and not be restricted to 2 characters long strings.

My point exactly. Let’s not restrict it to 2 characters only. 

> even if not in two separate drafts.

Agreed. These are two different schemas and might be separated. But, again, this was the target for a first -00 draft. 

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? 

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

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

Thanks, probably a copy-paste error. It’s missing the 1.0. and the closing. 

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

Noted. 

> cira-idn-bundle namespace, with an extra hyphen.

Typo. They all have the hyphen except one on page 13. Noted. 

> everything else is in the cira-idn-bundle namespace?

That’s legacy, as I understand it. Maybe Stuart could answer on that one. 

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

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. 

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

It’s true though, that if extension introduce new return codes, they would have to be registered somewhere to avoid collisions, maybe as a new field in the IANA registry. 

> name for elements, even in distinct namespaces, instead of two?

Again, legacy. I asked the same question to CIRA people. I’ll let them explain further, if needed. 

> name in the bundle? Something else?

Agree, a better description would help. 

> of all exDate of domain name variants in the bundle?

I suggested this one and I believe CIRA had a reason not put it in. I’ll let Stuart answer on this. 

> names in the bundle, with all the other data.

Might be a good idea if the data set isn’t too large. 

Thanks again for the thorough review Patrick, we really appreciate!

JF