Re: U-labels and draft-obispo-epp-idn-00

On Wed, Feb 15, 2012 at 04:07:57AM +0100, Patrik Fältström wrote:
> 
> FWIW, I am against passing U-label to the registry. Specifically
> having it "optional" as some registries will make it mandatory, and
> some will not. This will once again create a requirement in
> difference in implementation on the epp client side how to pass such
> a simple thing as a domain name from the epp client to the epp
> server.

Of all the people I'd ever imagined would suggest that IDNs were
simple, you were last but one -- the other guy was Klensin -- in
line!  But let me respond in detail below.  

> Further, if we go down this path of sending a U-label, then we might
> in the next step have epp servers that give the ability for the
> client to send unicode strings that are non-normalized and because
> of that not 1:1 mappings to the A-label as this piece of the data,
> and then validation whether the A-label matches or not -- according
> to the algorithm chosen by the registry.

If those registries plan to use the EPP standard domain name mapping,
they couldn't possibly do it this way: the <domain:name> element is not
optional, and it only allows LDH.

> - The a-label is what is mandatory and normative in the exchange between epp client and server

Already true in the RFCs we have.

> - An epp server might optionally accept a u-label, but that is never mandatory

This is just registry policy, and there is no way you (or anyone else)
is going to be able to legislate it.  To begin with, there are many
ccTLDs that are not subject to ICANN contract. 

> - Wrong u-label (or never sending it) can never block the use of the a-label given it is accepted
> 

The entire _point_ of the extension would be to block such an
A-label.  The idea is exactly to make sure that the EPP client is
sending you data that is correct.  The idea here is exactly to make
sure that the client and server in the EPP transaction agree on
exactly what's being exchanged.

Some registries check to make sure name servers are properly
delegated.  That mode of operation appears to be supported by some
text in RFCs 1034 and 1035, but many gTLDs don't do it.  By the same
token, RFC 5891 says that collecting both the U-label and the A-label,
or only the A-label, are preferable; and of these, the former is
preferred over the latter.  If you think that verify the name
server data that a client hands you is acceptable, then why isn't it
acceptable to verify the transformation -- probably performed by an
intermediate party ("the registrar") rather than the person who wants
the name ("the registrant") -- in the case of A-labels and U-labels?

> I.e. I ask myself, if you as an epp client do have a U-label, what is the chance the A-label is calculated wrongly? Adding that as a "feature" is just silly.

In the case where the U-label contained "ß", the chances are at the
very least non-zero, at least today and for the near future: last I
checked (about 30 seconds ago) libidn2 isn't in the Debian stable
distribution, just for instance.  Similarly with ZWNJ and ZWJ.

Best,

A

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