Re: New Version Notification for draft-obispo-epp-idn-02.txt

Hi Patrick,

Thanks for your comments, here are some thoughts:

On Apr 20, 2013, at 4:27 PM, Patrick Mevzek <[email protected]> wrote:

> Next version of Net::DRI will implement version 2 of your draft.
> 

Great!, I'll look at it as soon as it's published.


> However some questions/nitpicks:
> 
> - I'm not sure it is a good idea to use a third level domain name in
>  examples; it is ok per se and has no consequences on the extension, but for the
> same reason, it does not create useful differences, especially when
> hostnames used are at the same level
> 

We had a similar discussion on the WEIRDS working group, is there a reserved TLD that we can use for example purposes ?


> - I believe the end of §1 should be rewritten for various reasons:
> * "This extension adds one additional data element"
> in fact it adds two elements
> (and the previous paragraph explains one of them, so them reordering
> might be needed)


Thanks for catching this, this had to do with the original version which only added 1.

> * "However, this extension itself can be extended to incorporate more,
> as required by registry policy."
> There is nothing currently in this extension that allows any kind of
> extension, so anything like that would need a schema change and a new
> version or another schema altogether.
> 

I had originally intended to add an optional extension section, thinking that if someone wanted to include variants, could do that, I'll review the Schema and the appropriate text around it.




> - §3.1.1 says that data is given when "the domain name is an IDN"
> so that means it will not be available in all cases?

It will only be returned if:

1) the domain name is an IDN
2) The IDN extension was selected during the <login> command.


> If so, in §3.2.1 there should probably be an added sentence saying the
> same thing: the extension data is needed only for IDNs domain names.
> 
> Or, things should be there in both info & create, in all cases (IDNs &
> non IDNs)
> 

Well the advantage of using it only when needed, is that if yo have not implemented this extension, or don't care about IDNs, you don't need to do anything.


> Also the example has a problem: the starting <idn:uname> is closed by
> a <idn:table>
> 

Will be fixed.


> - it could be worthwile to delve more into error cases, when the uname
>  given does not correspond to the ACE, and when the idn table
> identifier does not correspond to characters found in the uname given.
> The specification should give some indication on the expected EPP
> error codes in all those cases.
> 

Good idea, I'll put some thought around that.


> Also you might need to speak about cases where there are more than one idn
> table.
> 
> - Since the extension speaks about "IDN tables", a link somewhere in
>  the document to http://www.iana.org/domains/idn-tables might be useful
> And in that way, add more control on the IDN table label used, since
> IANA website says:
> Script or Language Designator (Language Designators are defined in BCP
> 47)
> 

Well we originally had "language" designator, but decided to go through the IDN-table route better, since this is registry agnostic and all we need to do is to identify the target policy for validation.

> 
> Also, it may be a worthwile goal or not, but my current client has 5
> other IDNs/IDN tables/IDN languages EPP implementations (from Afilias,
> AusRegistry, NeuLevel, EURid and VeriSign). So the big question: has
> anyone enough interest and energy to try putting everyone around the
> table and design one extension that could replace all those ones?

This is why we decided to write this extension ;-)

> I do not believe the IDN domain space to be complex enough to merit 6
> separate implementations.
> 

+1


> HTH,

Francisco Obispo 
Director of Applications and Services - ISC
email: [email protected]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg