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

[Patrick Mevzek <[e-mail]>]

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