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

On 15 feb 2012, at 04:58, Andrew Sullivan wrote:

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

:-D

The whole reason for my answer is because IDN _is_ complicated.

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

Good, then we agree here.

>> - The a-label is what is mandatory and normative in the exchange between epp client and server
> 
> Already true in the RFCs we have.

Exactly!

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

No, it has to do whether a registry that claims to use epp is doing.

We already have far too many "private extensions" to epp where registries claims they implement epp when in fact they have private extensions, or interpretations of extensions that forces registrars to make all different kind of hacks to be able to interoperate.

I do not want that to be possible. I want to limit the number of extensions to epp to an absolute minimum and I want registries that implement them to do it the same way.

If a registry choose to NOT use epp, fine. I will not force them. But as a registrar it is very good to know. Specifically for the registries that do claim today they use epp, but you can not see the specification of their protocol unless you sign an NDA, pay a check, and THEN you see the epp version they have is so broken it is...well, I do not really have words for some of the things I have seen here.

Once again, I am not against them doing whatever they want. I am against calling that epp.

We *MUST* be better on saying what is epp and what is not epp.

And, sure, an extension that a registry have that is not mandatory for the registrar, that is fine, as the registrar does not have to implement that feature.

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

In this case, what the client should send is _not_ a U-label. You know better than anyone else what an A-label and U-label is, and you give examples below on unicode strings that are passed around that are not U-labels. Remember that there is by definition a 1:1 mapping between A-labels and U-labels.

What I hear you say now is that the client should be able to pass an A-label for registration, and also a unicode string that the client do claim is what the registrant wanted to register.

And the question is then what to do if it is the case that:

1. That unicode string is passed to the registry

2. The registry do not believe that unicode string can be represented by the A-label that is also sent

> Some registries check to make sure name servers are properly
> delegated.

Checking that a domain name is delegated before it can be registered I think is a big mistake, as they do not accept domain names to be registered without being delegated. That increases the interest in their zone file as the zone file in this case do disclose what domain names are registered and not.

My point is that yes, validation of various kinds is good of course (I have been pushing for more validations myself), but tying it to _registration_policy_ is a pain.

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

There is a big difference between validating A-label and U-label conformance and A-label and unicode string matchings.

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

So, the reason why we want to do this is to ensure there is no bug in the libraries used by various parties?

What is the library is wrong in the registry, but not registrar?

Once again, having the registry exposing an optional function where a _unicode_string_ can be passed together with an A-label to have that validated together with whatever policies the registry has, fine, but not be able to (according to epp) register a domain name with only an A-label is what I am against.

   Patrik

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