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

[JF Tremblay <[e-mail]>]

Thanks for the feedback, Patrick. 

Comments inline. 


> On May 25, 2015, at 10:45 AM, Patrick Mevzek <[e-mail]> wrote:
> 
> - 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. 


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

Agreed, naming them XML elements would probably be better. 


> [...] 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.

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. 

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

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

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? 

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

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

> 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…

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


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

Noted. 

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

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

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

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

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

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. 

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

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

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

Agree, a better description would help. 

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

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

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

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

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

JF