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

Hello Francisco and all

Francisco Obispo <[email protected]> 2013-04-05 17:14
> Fixed the issued pointed out by Keith Gaughan:
> 
> 1) TXT Document contained both the short version (preview) and the 
>    full in the same doc. 
> 
> 2) Removed references to an old (placeholder) namespace being used
>    for testing.

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

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

- 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)
* "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.

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

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

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

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)


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?
I do not believe the IDN domain space to be complex enough to merit 6
separate implementations.

HTH,

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