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

There seems some confusion about what this "unicode domain name"
represents. It is my understanding that it is the _expected_ U-label form.
The deviations between IDNA 2003 and IDNA 2008 (sigma, zwnj etc)
illustrate a potential benefit to this approach. Michael, if this is the
case then there is no additional overhead in logic other than one string
comparison.

This is very different however to a (user supplied?) Unicode string that
somehow maps to the A-label form. I don't see how a registry could make
use of this programatically unless the same registry also defined the
mappings allowed for the translation of the arbitrary Unicode string to an
A-label. A registry may however want this value for non-programatic
reasons including correspondence with the registrant.

This extension should clearly state which of the above it represents if
the intent is to avoid different implementations, of course assuming that
the extension will include this "unicode domain name" element :)

James

On 16/02/12 12:44 AM, "Michael Young" <[email protected]> wrote:

>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

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