Subject: [provreg] U-labels and draft-obispo-epp-idn-00

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Feb 2012 16:25:05 -0500

Hi,

draft-obispo-epp-idn-00 includes a mechanism for indicating some sort
of code point selector (there called a language tag).  I mentioned
before my reservation about this term "language tag", and suggested
that future developments would likely make something more generic
somewhat more useful (even if we continue to use RFC 5646 to generate
the tags that serve as identifiers, as I think we should).

I noted today, however, another thing that bugs me.  RFC 5731 makes
the <domain:name> data conform to RFC 952 as updated by RFC 1123.
At the risk of oversimplifying, this is the LDH rule.

RFC 5891 section 4.1 suggests that it would be desirable to require
both the A-label and U-label as input, so that the registry side could
valdate whether the A-label actually corresponds to the desired
U-label.  I know that some don't think this is a good policy to have,
but that's not relevant for this discussion; the question is, if
someone were going to implement such a policy, how could they? 

I'm wondering whether we couldn't make an optional element in this
proposed extension that would contain the name in U-label form.  In
other words, in the U-label format, A-labels wouldn't be allowed.

A repository, on receiving this, could validate that the A-label and
U-label matched.  If they did not, it would be an error.

Thoughts?

A

-- 
Andrew Sullivan
[email-masked]

---

From: James Mitchell <[email-masked]>
Date: Wed, 15 Feb 2012 10:43:13 +1100

I agree with Andrew for including an optional "U-label" element. Server policy can dictate how it is used.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andrew Sullivan
> Sent: Wednesday, 15 February 2012 8:25 AM
> To: [email-masked]
> Subject: [provreg] U-labels and draft-obispo-epp-idn-00
> 
> Hi,
> 
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: Luis Muñoz <[email-masked]>
Date: Tue, 14 Feb 2012 18:58:26 -0500

> someone were going to implement such a policy, how could they? 

I agree that this might come in handy in many cases, and probably does not hurt.

Best regards.

-lem

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 04:07:57 +0100

> U-label matched.  If they did not, it would be an error.

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.

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.

Etc. The slope is *extremely* slippery.

The only think I can agree to is that:

- The a-label is what is mandatory and normative in the exchange between epp client and server
- An epp server might optionally accept a u-label, but that is never mandatory
- Wrong u-label (or never sending it) can never block the use of the a-label given it is accepted

That way, epp clients can if they want to pass an optional u-label to the registry and get some signalling back. But it is not part of the mandatory communication when dealing with strings.

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.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 04:09:00 +0100

> I agree with Andrew for including an optional "U-label" element. Server policy can dictate how it is used.

No, this spec should dictate how it is used. It should not be one more feature that can differ between epp implementations.

We should *not* diverge in epp on how we express domain names inside the protocol.

The 'e' is not that much of an 'e'.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 04:09:23 +0100

On 15 feb 2012, at 00:58, Luis Muñoz wrote:

> I agree that this might come in handy in many cases

Mention one.

   paf

---

From: Jay Daley <[email-masked]>
Date: Wed, 15 Feb 2012 16:19:57 +1300

>> I agree that this might come in handy in many cases

In .nz we expect both the U and A labels and that the A label is correctly derived from the U.  The reasoning for this is that registrants are not in their minds registering the A label, they are registering the U label and we want to guard against a processing error that would not provide what the registrant wants.  With only an A label we can't trap this.

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 14 Feb 2012 19:22:48 -0800

.VE also uses a U-Label, and uses the encoding in the XML document to check the code points against a white list.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 04:40:30 +0100

> In .nz we expect both the U and A labels and that the A label is correctly derived from the U.  The reasoning for this is that registrants are not in their minds registering the A label, they are r…

And you have factual errors where a U-label and an A-label does not match? You do not talk about cases where they believe they can register some unicode string that is not a U-label?

Note, the discussion is about U-labels and A-labels, not unicode strings and A-labels.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Feb 2012 22:58:46 -0500

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-masked]

---

From: Jay Daley <[email-masked]>
Date: Wed, 15 Feb 2012 17:56:40 +1300

On 15/02/2012, at 4:40 PM, Patrik Fältström wrote:

> And you have factual errors where a U-label and an A-label does not match?

In testing yes, not in production, but then we have less than 200 IDN registrations.

> You do not talk about cases where they believe they can register some unicode string that is not a U-label?

You only asked for one example, not a canonical ruleset for how we process the U-label data!  Obviously the U-label must be valid and if it is not then we don't process it in the same way we don't process invalid A-labels.

> Note, the discussion is about U-labels and A-labels, not unicode strings and A-labels.

And my point was that for non-IDNs the registrant believes they are registering an A-label which is the same A-label that the registry registers.  But with IDN there is no longer this direct relationship as the registrant believes they are registering the U-label while the registry actually registers the A-label.  

Jay

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 05:58:50 +0100

> line!  But let me respond in detail below.  

:-D

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

> optional, and it only allows LDH.

Good, then we agree here.

> Already true in the RFCs we have.

Exactly!

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

> 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

> 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

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

> 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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 06:01:02 +0100

> You only asked for one example, not a canonical ruleset for how we process the U-label data! Obviously the U-label must be valid and if it is not then we don't process it in the same way we don't p…

Fair.

> And my point was that for non-IDNs the registrant believes they are registering an A-label which is the same A-label that the registry registers.  But with IDN there is no longer this direct relati…

I claim the registrant believe they register a unicode string, while the registry in fact register an A-label.

Thats why I am confused why people are so focused on U-labels. The trouble is in the unicode string -> U-label mapping, not the U-label -> A-label mapping.

   Patrik

---

From: James Mitchell <[email-masked]>
Date: Wed, 15 Feb 2012 16:04:39 +1100

I agree that _technically_ both A-label and U-label are not required. However by requiring both U-label and A-label a registry can guarantee that the registrar knew the corresponding U-label prior to registration. Registrars may choose to generate the U-label from the A-label (that they somehow derived), however it is also their choice to send a create command to the registry where the U-label is not what the registrar or the registrant expected. In this case the registry has done all it possibly can to ensure that the correct name has been registered. You will find that a few ccTLDs will have this hat on.

As an example, consider the U-label of U+03C2 (final sigma) which has a corresponding A-label of xn--3xa. Using IDNA 2003 based processing however the derived ACE-label for U+03C2 is xn--4xa, which is a valid A-label, however for the U-label U+03C3 (non-final sigma). A registrar can send the registry one of these A-labels, and the registry can programmatically determine the corresponding U-label, however is this the same U-label that the registrar was expecting to register?

James

> Behalf Of Patrik Fältström
> Sent: Wednesday, 15 February 2012 2:41 PM
> To: Jay Daley
> Cc: [email-masked]
> Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00
> 
> 
> > In .nz we expect both the U and A labels and that the A label is
> correctly derived from the U.  The reasoning for this is that
> registrants are not in their minds registering the A label, they are
> registering the U label and we want to guard against a processing error
> that would not provide what the registrant wants.  With only an A label
> we can't trap this.
> 
> And you have factual errors where a U-label and an A-label does not
> match? You do not talk about cases where they believe they can register
> some unicode string that is not a U-label?
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Feb 2012 00:13:42 -0500

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

The examples I gave are not U-labels, no.  But they're Unicode forms
of IDNA2003-compliant systems that happen to generate Punycode forms
that are perfectly good A-labels.  If I got a candidate U-label that
didn't match the A-label, I could detect this.  If I just get the
A-label, I can't.

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

If I ran the circus, this would be a fatal error for the
registration.  Moreover, RFC 5891, section 4.2.1, agrees with me:

   If both the U-label and A-label forms are available, the registry
   MUST ensure that the A-label form is in lowercase, perform a
   conversion to a U-label, perform the steps and tests described below
   on that U-label, and then verify that the A-label produced by the
   step in Section 4.4 matches the one provided as input.  In addition,
   the U-label that was provided as input and the one obtained by
   conversion of the A-label MUST match exactly.  If, for some reason,
   these tests fail, the registration MUST be rejected.

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

There's no _bug_ in libidn when it maps ß to ss.  That's what it's
supposed to do.  Moreover, if the input string was (say) üß, then the
result would in fact be a Punycode-form IDNA2003 string that happened
also to be an IDNA2008 A-label.  It just wouldn't be the right one,
because in IDNA2003 üß becomes üss before the Punycode
transformation.  The point of requiring the U-label is to be able to
catch this sort of corner case.

In complicated typographic systems like Arabic this is loads worse,
because not only are ZWNJ and ZWJ mapped away in IDNA2003, but many
people won't be able to see that.  But a machine could spot it and
throw an error.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 15 Feb 2012 10:36:01 +0100

On 15/02/12 05:58, Patrik Fältström wrote:
>> they couldn't possibly do it this way: the<domain:name>  element is not

Hi,

where is this stated, if I may ask? Can't find this in RFC 5730/5731 or in the 
RFC 5891 which was mentioned in a later post.

In my humble opinion, it is a bad idea to spread the use of Punycode into areas 
where there is no technical need for it. While I am still fascinated about the 
mathematical tricks that are used in make the code as small as possible, we 
should not forget that it was a technical crutch to add Unicode to DNS in a 
backward-compatible fashion. I may be good for DNS, but should stay there. XML 
as the basis of EPP, on the other hand, has its own means to deal with Unicode, 
it even works with plain ASCII, using numeric entities. So using Punycode with 
XML is unnecessary and some kind of "double encoding". This is similar as one 
would mandate to use "U+NNNN" or "\uNNNN" notations or using UTF-7 within the 
XML document itself (i.e. not as a document encoding), which would of course 
cause head-shaking.

Of course, it is arguable what kind of Unicode string is expected, i.e. whether 
it is demanded that a normalized, prepared or whatever constrained string has to 
be submitted, or whether the registry accepts any form and does the 
normalization before it further processes the name.

Regards,

Klaus

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 08:57:17 +0100

> didn't match the A-label, I could detect this.  If I just get the

Bingo!

Sending U-labels in addition to A-labels does not make any sense.

> catch this sort of corner case.

But then you do no longer talk about sending U-labels and A-labels!

You send unicode strings and A-labels!

   Patrik

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Feb 2012 12:35:44 +0000

> Sent: Tuesday, February 14, 2012 10:09 PM
> To: [email-masked]
> Cc: [email-masked]
> > I agree with Andrew for including an optional "U-label" element.
> Server policy can dictate how it is used.
> 
> No, this spec should dictate how it is used. It should not be one more
> feature that can differ between epp implementations.
> 

Completely correct. I don't have a strong preference for including U-labels or not (5891 suggests that including both is preferred "because it permits further verification of user intent"), but if they are included the syntax and processing should be consistent.

Scott

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2012 13:38:07 +0100

On 15 feb 2012, at 10:36, Klaus Malorny wrote:

> to add Unicode to DNS in a backward-compatible fashion

No, to add Unicode to domain names, and there are multiple reasons why it ended up like it did. LDH encoding is just one of them. The ability to have a different encoding in the future (different prefix than xn--, i.e. without destroying the full namespace) another.

But that discussion is something we do not have to have here.

Where I agree with you is that it does not matter whether we pass U-label or A-label as there is a 1:1 mapping between them, and that is as I have explained in other email messages not a big deal.

What people seems to ask for is the ability to pass a unicode string together with {A,U}-label so that the registry can say whether what is registered is really what the registrant asked for.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Feb 2012 08:18:39 -0500

Hi,

At the risk of creating a stain on the ground where once there was a
horse that had already been beaten to death, let me try once more.

> Sending U-labels in addition to A-labels does not make any sense.

Of course if we could be sure that every time we had what looked like
an A-label, the party that sent it did in fact have the U-label, then
I agree that there would be no reason whatever to send them both.  The
nice thing about IDNA2008 is that every A-label corresponds to exactly
one U-label.

The nasty thing about IDNA2008, however, is that some A-labels also
correspond to Punycode forms from IDNA2003, and those Punycode forms
do not always match a Unicode form that is the same as the U-label
you'd get under IDNA2008.  See upthread for examples.

This incompatibility is one of the reasons that Unicode pushes UTS 46.
I'm trying to suggest a way to ensure no confusion, by ensuring we
have a (standard) way at registration time of detecting when something
is wrong.  I want to make the element optional precisely so that, at
some brave happy day in the future when we have no reason to suppose
anyone is sending an IDNA2003-based Punycode form, we could turn the
thing off.  Moreover, I'm aware that some registries don't like to do
this sort of additional verification of client-supplied data, and that
therefore it cannot be a required element.  Even RFC 5891 doesn't say
you need to submit both; it just says that it would be better.

> You send unicode strings and A-labels!

Yes, in a case where the U-label and A-label are not products of one
another, then either the U-label or the A-label is wrong.  But in some
of those cases, it is _indeterminate_ which one is wrong.  For
instance, suppose I have a string with a final form sigma in the
middle of it (because it's made up by putting together two strings
that would be words in Greek), an IDNA2003 transformation will not
include Punycode that will get you a final form sigma.  The final form
sigma is mapped away, as you know.  Now, if you have the input of the
candidate U-label and the candidate A-label, you can tell whether they
are in fact the U-label and A-label for one another.  If you only have
the A-label, you can generate a perfectly good U-label, but it isn't
the one the EPP client thought it was requesting.

I maintain -- and I think the plain meaning of RFC 5891 agrees with me
-- that this additional check should result in the rejection of the
registration request.  If it makes you happier to call the element
where we put the candidate U-label "unicodestring", or
"bobsgreatuncle", or "greatpointlesslongnameforelement", instead of
"u-label", I don't care.  My point is merely that it is entirely
reasonable for a registry to have this requirement, and to enforce it.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Michael Young" <[email-masked]>
Date: Wed, 15 Feb 2012 08:44:58 -0500

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-masked] [mailto:[email-masked]] On Behalf
Of Patrik Fältström
Sent: February-14-12 11:59 PM
To: Andrew Sullivan
Cc: [email-masked]
Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00

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

> simple, you were last but one -- the other guy was Klensin -- in line!  
> But let me respond in detail below.

:-D

>> 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.
> 
> they couldn't possibly do it this way: the <domain:name> element is 
> not optional, and it only allows LDH.

Exactly!

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.

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.

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

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 

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.

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

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

---

From: James Mitchell <[email-masked]>
Date: Thu, 16 Feb 2012 01:48:40 +1100

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-masked]> wrote:

>succeeded in the registration.  Just in principle I don¹t like loading up

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Feb 2012 11:56:11 -0500

On Wed, Feb 15, 2012 at 10:36:01AM +0100, Klaus Malorny wrote:
> where is this stated, if I may ask? Can't find this in RFC 5730/5731
> or in the RFC 5891 which was mentioned in a later post.

RFC 5731 says, "The syntax for domain and host names described in
this document MUST conform to [RFC0952] and [RFC1123]."  (See section
2.1.)  952, even as revised by 1123, is where the LDH rule comes
from.  This means that domain names in the EPP domain name mapping
must conform to the LDH rules, which means that if they're IDNs they
have to be A-labels. 

RFC 5891 is about how you handle the A-label and U-label when you get
it at registration time.

> Of course, it is arguable what kind of Unicode string is expected,

The reason I was focussing on U-labels rather than any old Unicode
string is in line with what others have said.  If a registry gets a
Unicode string in NFD, or gets a string with upper case characters, or
a whole host of other possible mistakes under IDNA2008, I wouldn't
expec that to be accepted.  What goes in a slot intended for a U-label
ought to be a real U-label.  The only question is whether the U-label
and the A-label match one another.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 22 Feb 2012 15:27:19 +0100

> must conform to the LDH rules, which means that if they're IDNs they

Ok, accepted, thanks. I should better re-read RFC 5730 et seqq. to see whether 
it still contains more backward-looking rules that have been overcome elsewhere ;-)

> The reason I was focusing on U-labels rather than any old Unicode
> expect that to be accepted.  What goes in a slot intended for a U-label

So you suggest that upper case domain names should be better rejected, 
consequentially? And for both non-IDNs and IDN A-labels? While it makes life 
easier for the registries, I have the feeling that a few registrars would get 
some trouble with this.

Regards,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Feb 2012 10:05:26 -0500

On Wed, Feb 22, 2012 at 03:27:19PM +0100, Klaus Malorny wrote:

> So you suggest that upper case domain names should be better
> rejected, consequentially? And for both non-IDNs and IDN A-labels?
> While it makes life easier for the registries, I have the feeling
> that a few registrars would get some trouble with this.

For LDH-labels, of course, it doesn't matter.  I think for users it
would be nice if we trained people to expect only lower case in domain
names (more on why below), but I wasn't intending to advocate that.

For U-labels, though, of course, an upper case character is
DISALLOWED.  This extends even to ASCII-range code points that would
be accepted in LDH: "CaféCrème" is not a U-label, even though
"CafeCreme" is a perfectly good LDH-label.  Those need to be lower
case for sure.

In the case of A-labels, I _thought_ we issued a clarification about
Appendix A in RFC 3492.  That appendix has some remarks about mixed
case, and the issue is that, since no U-label may have mixed case,
therefore Punycode can't either.  But I can't find the clarification
right now.  It nevertheless seems a consequence, and therefore I think
A-labels should always be in lower case.

Because U-labels can't ever have upper case, RFC 5895 and some other
documents (prominently UTS 46) suggest always mapping upper to lower
case.  I think that's a good idea, but any time there's a mapping step
in between user input and what the application actually uses I get
nervous.  Therefore, I think it would be better for everyone if we
gradually trained people to use lower case for DNS labels everywhere.
Yes, I'm aware that that will suck in places where CamelCase has
helped clarify what ExpertsExchange is really about.  But "the
application knows your intention" has not been, I suggest, a universal
success.  This goal is probably tilting at windmills, however, since
many registries I know of often spell their domain names in capital
letters in running text.

Best,

A

-- 
Andrew Sullivan
[email-masked]