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

I agree with Patrick here but please read my whole response before reacting,


So we are suggesting that we set the expectation ( and I say setting
expectation only because it was suggested as optional) that the registry
will do the work of validating whether or not the registrar successfully
translated their U-label to the right A-label.

The problems I see here is that you end up with more overhead in the inline
transaction OR you have to go asynch and inform them later on if they
succeeded in the registration.  Just in principle I don’t like loading up
the synchronous transaction further and asynch does not tend to make
registrars happy.  They like to tell their customers whether or not they got
the registration while they wait at their web portals.

Having said all that I am now going to turn my line of argument 180 degrees.
Since we know some registries are actually already doing this, and the
PRIORITY goal is to have one IDN extension to rule them all, then I think we
need to include it as optional.  It's out there, it's happening for various
reasons, and we need to accommodate it.


Michael Young

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Patrik Fältström
Sent: February-14-12 11:59 PM
To: Andrew Sullivan
Cc: [email protected]
Subject: Re: [provreg] 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

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