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

Francisco,

We are current planning on leveraging this extension for IDN registrations in our registry, but were wondering if you would consider making the uname element optional (minOccurs = 0)?  Because most of the existing gTLDs currently don't expect the uname as part of the create request, we are worried that this could be a barrier to registrar adoption of our IDNs.  They might not be prepared to send the uname in the create request (because the TLDs they support today don't expect it), and may or may not be willing to do the work required in order to pass that information.

If the UNAME element is provided by the registrar in the CREATE command, then the registry should have to validate that it matches the a-label form in the domain name field.  An error should be returned otherwise.  If the UNAME is not supplied, then the server would only validate that the characters are part of the language table supplied.

We have no problem with the server returning the uname for all info requests for IDN names.

Also, on a minor note, we should fix the indentation of the "idnDataType" complex type in the XSD definition to be at the same level as the "data" element.

Thank you.

Ben Levac

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Francisco Obispo
Sent: Sunday, April 21, 2013 11:57 AM
To: Patrick Mevzek
Cc: [email protected]
Subject: Re: [provreg] 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

Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg