headers
Andrew Sullivan | 14 Feb 2012 22:25

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

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
(Continue reading)

Permalink | Reply |
headers
James Mitchell | 15 Feb 2012 00:43
Picon

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

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

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Andrew Sullivan
> Sent: Wednesday, 15 February 2012 8:25 AM
> To: provreg <at> ietf.org
> Subject: [provreg] U-labels and draft-obispo-epp-idn-00
> 
> 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
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 04:09
Picon

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


On 15 feb 2012, at 00:43, James Mitchell wrote:

> 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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Hollenbeck, Scott | 15 Feb 2012 13:35
Picon
Favicon

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

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Patrik Fältström
> Sent: Tuesday, February 14, 2012 10:09 PM
> To: james.mitchell <at> ausregistry.com.au
> Cc: provreg <at> ietf.org
> Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00
> 
> 
> On 15 feb 2012, at 00:43, James Mitchell wrote:
> 
> > 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'.

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
_______________________________________________
provreg mailing list
provreg <at> ietf.org
(Continue reading)

Permalink | Reply |
headers
Luis Muñoz | 15 Feb 2012 00:58

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


On Feb 14, 2012, at 4:25 PM, Andrew Sullivan wrote:

> 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 agree that this might come in handy in many cases, and probably does not hurt.

Best regards.

-lem

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 04:09
Picon

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


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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Jay Daley | 15 Feb 2012 04:19
Picon
Favicon

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


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

>> I agree that this might come in handy in many cases
> 
> Mention one.

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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Francisco Obispo | 15 Feb 2012 04:22

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

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

On Feb 14, 2012, at 7:19 PM, Jay Daley wrote:

> 
> On 15/02/2012, at 4:09 PM, Patrik Fältström wrote:
> 
>>> I agree that this might come in handy in many cases
>> 
>> Mention one.
> 
> 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
> 
> _______________________________________________
> provreg mailing list
> provreg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 04:40
Picon

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


On 15 feb 2012, at 04:19, Jay Daley wrote:

> On 15/02/2012, at 4:09 PM, Patrik Fältström wrote:
> 
>>> I agree that this might come in handy in many cases
>> 
>> Mention one.
> 
> 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?

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

   Patrik

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Jay Daley | 15 Feb 2012 05:56
Picon
Favicon

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


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

--

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

_______________________________________________
provreg mailing list
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 06:01
Picon

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

On 15 feb 2012, at 05:56, Jay Daley wrote:

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

Fair.

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

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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
James Mitchell | 15 Feb 2012 06:04
Picon

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

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

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Patrik Fältström
> Sent: Wednesday, 15 February 2012 2:41 PM
> To: Jay Daley
> Cc: provreg <at> ietf.org
> Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00
> 
> 
> On 15 feb 2012, at 04:19, Jay Daley wrote:
> 
> > On 15/02/2012, at 4:09 PM, Patrik Fältström wrote:
> >
> >>> I agree that this might come in handy in many cases
> >>
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 04:07
Picon

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

On 14 feb 2012, at 22:25, Andrew Sullivan wrote:

> A repository, on receiving this, could validate that the A-label and
> 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
(Continue reading)

Permalink | Reply |
headers
Andrew Sullivan | 15 Feb 2012 04:58

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
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 05:58
Picon

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
(Continue reading)

Permalink | Reply |
headers
Andrew Sullivan | 15 Feb 2012 06:13

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

On Wed, Feb 15, 2012 at 05:58:50AM +0100, Patrik Fältström wrote:
> 
> 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.
> 

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.

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

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,
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 08:57
Picon

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

On 15 feb 2012, at 06:13, Andrew Sullivan wrote:

> On Wed, Feb 15, 2012 at 05:58:50AM +0100, Patrik Fältström wrote:
>> 
>> 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.
> 
> 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.

Bingo!

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

>>> 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?
> 
> 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,
(Continue reading)

Permalink | Reply |
headers
Andrew Sullivan | 15 Feb 2012 14:18

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

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.

On Wed, Feb 15, 2012 at 08:57:17AM +0100, Patrik Fältström wrote:

> > 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.
> 
> Bingo!
> 
> 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
(Continue reading)

Permalink | Reply |
headers
Klaus Malorny | 15 Feb 2012 10:36
Picon
Favicon

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

On 15/02/12 05:58, Patrik Fältström wrote:
> On 15 feb 2012, at 04:58, Andrew Sullivan wrote:
>>
>> 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!
>
>

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
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 15 Feb 2012 13:38
Picon

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


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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
Permalink | Reply |
headers
Andrew Sullivan | 15 Feb 2012 17:56

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

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
(Continue reading)

Permalink | Reply |
headers
Klaus Malorny | 22 Feb 2012 15:27
Picon
Favicon

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

On 15/02/12 17:56, Andrew Sullivan wrote:
> 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.
>

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 ;-)

> 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 focusing 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
> expect 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,
(Continue reading)

Permalink | Reply |
headers
Andrew Sullivan | 22 Feb 2012 16:05

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

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.
(Continue reading)

Permalink | Reply |
headers
Michael Young | 15 Feb 2012 14:44
Picon

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: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On Behalf
Of Patrik Fältström
Sent: February-14-12 11:59 PM
To: Andrew Sullivan
Cc: provreg <at> ietf.org
Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00
(Continue reading)

Permalink | Reply |
headers
James Mitchell | 15 Feb 2012 15:48
Picon

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" <michael <at> mwyoung.ca> 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.
(Continue reading)

Permalink | Reply |

Gmane