Subject: [provreg] Fwd: New Version Notification for draft-obispo-epp-idn-02.txt

From: Francisco Obispo <[email-masked]>
Date: Fri, 5 Apr 2013 08:13:06 -0700

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.

Kind regards,

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-obispo-epp-idn-02.txt
> Date: April 5, 2013 8:10:46 AM PDT
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> A new version of I-D, draft-obispo-epp-idn-02.txt
> has been successfully submitted by Francisco Obispo and posted to the
> IETF repository.
> 
> Filename:	 draft-obispo-epp-idn
> Revision:	 02
> Title:		 Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)
> Creation date:	 2013-04-05
> Group:		 Individual Submission
> Number of pages: 5
> URL:             http://www.ietf.org/internet-drafts/draft-obispo-epp-idn-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-obispo-epp-idn
> Htmlized:        http://tools.ietf.org/html/draft-obispo-epp-idn-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-obispo-epp-idn-02
> 
> Abstract:
>   This document describes an Extensible Provisioning Protocol (EPP)
>   extension mapping for the provisioning of Internationalized Domain
>   Names (IDN) stored in a shared central repository.  This mapping
>   extends the EPP domain name mapping to provide additional features
>   required to implement registrations of domain names in characters
>   sets other than ASCII.
> 
> 
> 
> 
> The IETF Secretariat

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

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 21 Apr 2013 01:27:41 +0200

Hello Francisco and all

Francisco Obispo <[email-masked]> 2013-04-05 17:14
> 2) Removed references to an old (placeholder) namespace being used

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

---

From: Francisco Obispo <[email-masked]>
Date: Sun, 21 Apr 2013 11:56:42 -0700

Hi Patrick,

Thanks for your comments, here are some thoughts:

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

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

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

> (and the previous paragraph explains one of them, so them reordering

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

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

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

> Or, things should be there in both info & create, in all cases (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

Will be fixed.

> error codes in all those cases.

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

> Script or Language Designator (Language Designators are defined in BCP

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.

> table and design one extension that could replace all those ones?

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

> separate implementations.

+1

Francisco Obispo

---

From: Ben Levac <[email-masked]>
Date: Sun, 28 Apr 2013 11:19:25 -0700

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-masked] [mailto:[email-masked]] On Behalf Of Francisco Obispo
Sent: Sunday, April 21, 2013 11:57 AM
To: Patrick Mevzek
Cc: [email-masked]
Subject: Re: [provreg] New Version Notification for draft-obispo-epp-idn-02.txt

Hi Patrick,

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

Will be fixed.

> Also you might need to speak about cases where there are more than one
> idn table.
>

+1

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

_______________________________________________
provreg mailing list
[email-masked]
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.

---

From: Francisco Obispo <[email-masked]>
Date: Sun, 28 Apr 2013 11:25:08 -0700

Hi Ben,

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

I guess we could do that, since the validation of the name and uname, is a recommendation as appears on:

  http://tools.ietf.org/html/rfc5891#section-4.1

I'll add this to my list of changes.

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

OK, I think this is good compromise.

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

Will do.!

Francisco Obispo