Subject: [eppext] review of draft-ietf-eppext-idnmap-01

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Dec 2014 16:15:52 -0500

Dear colleagues,

As I said I would, I poked a colleague at Dyn to help with review of
some of the WG documents.  My colleague Alex Sergeyev, who has worked
on our EPP client code, sent me some comments.  I've included them
here with my own comments on this document, but I'll call out which
ones are his.

I like the goal of this draft, because anything that could bring some
order to the mess that is IDNs and their registration would be
helpful.  I worry, however, that the proposal in the draft is too
specialized to accommodate the range of registration practices.  

One issue is that the reference to the ICANN IDN guidelines is not
entirely up to date.  The linked one is older, and does not refer to
IDNA2008.  The latest (at
https://www.icann.org/resources/pages/idn-guidelines-2011-09-02-en)
points out that IDNA2003 and IDNA2008 are likely to be in operation at
the same time.  This is important, because it probably means that the
extension needs some sort of mechanism to signal "variants" or
"alternatives" or "linked names" or whatever as part of the extension.
This is necessary, I suspect, because any registry coping with both
2003 and 2008 at the same time is going to have to handle both, I
think.  For instance, the U-label "schløß" (yeah, I'm deliberately
mixing language repertoires here; more below) corresponds to A-label
xn--schl-yna3m under IDNA2008 but to Punycode form xn--schlss-eya
under IDNA2003 (and UTS46.  The nice thing about standards …).

The 2003/2008 distinction causes another problem for the text as
written.  Section 3.2.1 requires the server to validate a provide
candidate U-label for conformance with IDNA2008, but if the client is
sending IDNA2003 this will fail under some circumstances.  (I suppose
we could solve this by saying, "If you're using IDNA2003, never send
the uname element," but that seems sort of sucky, because it won't
catch mistakes.)  More generally, my colleague Alex found 3.1 and 3.2
a little confusing as to exactly what is required and so on.  It'd be
helpful to go through this carefully for exactly which 2119 keywords
are needed.

Also in 3.2.1, there's some discussion of the <idn:table> element,
which is an identifier "as provided by the server".  But I don't see
how to get that identifier.  Do you get a list at login?  I wonder
also whether it mightn't be necessary to refer to
https://tools.ietf.org/html/draft-davies-idntables-08.  Alex also
notes that there might be a case where a single repoisitory is doing
more than one registry at a time, and where the policies on the names
could be different.  It seems that there'd need to be some error
handling for that case.

Alex also said that it would be more helpful for him to show, in the
examples, just the part that's added to the <epp:extensions>, with
some fuller examples in appendices.  (In my view, these examples all
follow a pretty normal format.)

I hope these comments are helpful.  I like the draft in general and
think it'd be a good thing to finish up.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 31 Dec 2014 10:04:54 -0800

Hi Andrew,

Thanks for passing the information along, my comments below:

Francisco Obispo
CTO - Registry Operations

2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263

> On Dec 30, 2014, at 1:15 PM, Andrew Sullivan <[email-masked]> wrote:
> 
> Dear colleagues,
> 

There is already an effort for ‘bundling’ domain names, so this requirement was left outside of the scope of the draft. There are many reasons why names could be bundled and we thought that including a separate mechanism within the IDN extension was not necessary.

> helpful to go through this carefully for exactly which 2119 keywords

We are aiming at IDNA2008.

> could be different.  It seems that there'd need to be some error

For this specific purpose James Gould (Verisign), Patrik Fältström, Luis Muñoz and myself are drafting a new proposal to deal with IDN tables and its definition so we can provide an in-band mechanism.

We can’t use “standard” table identifiers, because those are all policy driven.

> think it'd be a good thing to finish up.

Thanks Andrew.

I’ll add some clarifications to the document and upload a new version today, specially since I need to keep it current (it expired already)

Have a happy new year to all.

> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> 
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext