Subject: [I18ndir] Guidance on Return of A-Labels in a URL?

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 10 Sep 2020 12:41:55 +0000

Does anyone know of any text in any of the IDN RFCs that would support a recommendation to return A-Labels in RDAP response URLs?

Marc Blanchet wrote an I-D (https://www.ietf.org/archive/id/draft-blanchet-regext-rdap-deployfindings-05.txt) a while ago in which he described RDAP deployment findings. In Section 3.6, he suggests that "All links of any "rel" types should always be returned in the A-Label form for IDNs in the href or value members, independent of if the query was a U-Label or A-Label or a mix". That seems like a good idea since a server doesn't know what a client is capable of consuming, but I was hoping to support this recommendation with a reference to something in IDNA. I didn't see anything obvious.

I sent this same basic question to both Marc and Patrik individually. I haven't heard back from either of them, so I apologize if I'm "jumping the gun" by asking he directorate without waiting to see if they respond.

Scott

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 10 Sep 2020 14:56:52 +0200

> I sent this same basic question to both Marc and Patrik individually. I haven't heard back from either of them, so I apologize if I'm "jumping the gun" by asking he directorate without waiting to s…

You do not! Different time zones, and day full of videoconference meetings...its on the queue. :-)

   paf

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 10 Sep 2020 22:30:54 +0200

Now some time...

Regarding the use of U-Label and A-Label nothing specific is said about RDAP.

What you have is RFC 5890 2.3.2.6. Domain Name Slot and some previous sections that talks about the equivalence between U-Label and A-Label which is a 1:1 mapping (compared to earlier versions of IDNA standard).

Note section 2.3.2.1.  IDNA-valid strings, A-label, and U-label in the same RFC which says:

> A "U-label" is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC)...

My view is that it is up to the protocol that pass around domain names in a Domain Name Slot how to handle the situation, and because of that ensure that if U-Label is in use that the requirements on that protocol element matches the definition of a U-Label, and not just "random Unicode code points in some random encoding and unknown normalisation".

I can see situations where you in RDAP do want to be able to send random Unicode Code Points just with the intention to do some search on the server, but that is then NOT a U-Label. The same way I do see interest in sending A-Labels to be sure the string is stable and as it was supposed to be during the whole transaction.

Does this help?

   Patrik

On 10 Sep 2020, at 14:41, Hollenbeck, Scott wrote:

> -- 
> I18ndir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18ndir

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2020 17:05:50 -0400

In article <[email-masked]> you write:
>I can see situations where you in RDAP do want to be able to send random Unicode Code Points just with the intention
>to do some search on the server, but that is then NOT a U-Label. The same way I do see interest in sending A-Labels
>to be sure the string is stable and as it was supposed to be during the whole transaction.

It also makes sense because RDAP is a host-host protocol and not
host-user. If the client wants to turn A-labels into U-labels for
display, that's easy enough.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Sep 2020 19:19:37 -0400

Scott,

Let me add a slightly different perspective (and a warning) to
what Patrik and John Levine have said without in any way
disagreeing with them.  It will also give you a somewhat deeper
analysis and set of references to refer to if needed.

As long as IDNA2008 is strictly followed, then it really makes
no difference whether U-labels and A-labels are returned and the
choice should be made according to what works best for the
application protocol.  If the URLs you are referring to are
strictly conformant to RFC 3986, there there is a strong case
for using A-labels because the alternative is %-encoding,
presumably of UTF-8 [1].  That form is hard to read, less
optimized for DNS labels, much less compact, etc., than the
A-label form.

_However_ note "strictly" above.  There are communities out
there that consider 3986 (and 3987) obsolete and are developing
their own URL specs.  There are overlapping ones that use or
assume profiles of Unicode UTR#46 which involve some specific
mappings and, for all intents and purposes, rely on IDNA2003.
For IDNA2003 and those profiles of UTR#46, one cannot make an
identity comparison between native character Unicode strings
(UTF-8 or otherwise) without IDNA-specific processing.
Whatever the arguments for and against reliance on UTR#46 rather
than strict conformance to IDNA2008, that is a very strong
argument for RDAP (and other protocols involving registration
data) work in terms of  A-labels rather than anything else.

FWIW and AFAIK, while, as Pstrik indicates, IETF has not taken a
position on this issue for RDAP and similar protocols, ICANN
has.  Long ago, when the Board created two committees chaired by
Katoh-san, there were conclusions that, regardless of what
interfaces registrars chose to present to users and what they
accepted as input, all registration databases and access
protocols [2] should work strictly in terms of already mapped
and processed Punycode-encoded form and that, if native
characters were presented to users from those systems, they
should be the result of 
   ToUnicode(ToASCII(user-supplied-string) 
and not the user supplied string.   Those conclusions and the
reasoning that went into them strongly influenced RFC 4690 and
hence IDNA2008 but, more important from your standpoint, I don't
believe ICANN has ever deprecated or formally abandoned them.

     john

[1] See the rather flexible text in Section 2.5 of 3986.

[2] While WHOIS was the only game in town then, the Whois++
specs had been published a half-dozen years earlier and the
debates about databases and database access permissions and
tools were well underway.

--On Thursday, September 10, 2020 22:30 +0200 Patrik Fältström
<patrik=[email-masked]> wrote:

> What you have is RFC 5890 2.3.2.6. Domain Name Slot and some
> previous sections that talks about the equivalence between
> U-Label and A-Label which is a 1:1 mapping (compared to
> earlier versions of IDNA standard).
> 
> My view is that it is up to the protocol that pass around
> domain names in a Domain Name Slot how to handle the
> situation, and because of that ensure that if U-Label is in
> use that the requirements on that protocol element matches the
> definition of a U-Label, and not just "random Unicode code
> points in some random encoding and unknown normalisation".
> 
> I can see situations where you in RDAP do want to be able to
> send random Unicode Code Points just with the intention to do
> some search on the server, but that is then NOT a U-Label. The
> same way I do see interest in sending A-Labels to be sure the
> string is stable and as it was supposed to be during the whole
> transaction.
> 
> Does this help?
> 
>    Patrik
> 
>> Does anyone know of any text in any of the IDN RFCs that
>> would support a recommendation to return A-Labels in RDAP
>> response URLs?
>> 
>> Marc Blanchet wrote an I-D
>> (https://www.ietf.org/archive/id/draft-blanchet-regext-rdap-d
>> eployfindings-05.txt) a while ago in which he described RDAP
>> deployment findings. In Section 3.6, he suggests that "All
>> links of any "rel" types should always be returned in the
>> A-Label form for IDNs in the href or value members,
>> independent of if the query was a U-Label or A-Label or a
>> mix". That seems like a good idea since a server doesn't know
>> what a client is capable of consuming, but I was hoping to
>> support this recommendation with a reference to something in
>> IDNA. I didn't see anything obvious.
>> 
>> I sent this same basic question to both Marc and Patrik
>> individually. I haven't heard back from either of them, so I
>> apologize if I'm "jumping the gun" by asking he directorate
>> without waiting to see if they respond.
>> 
>> Scott
>> 
>> -- 
>> I18ndir mailing list
>> [email-masked]

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 11 Sep 2020 06:29:50 +0200

Scott: TL;DR of all of our messages are: A-Label and U-Labels are 1:1 mappings to each other. The question is what you want to happen (and who is doing validation) of:

- Strings starting with xn-- that are not A-Labels
- Unicode strings that are not U-Labels
- URLs that do not follow RFC 3986 or 3987

In this mix you absolutely must include (for natural reasons) people that do believe IETF, W3C are nut heads, including for example the ccTLDs registries that do provide domain names not IDNA-2008 conformant. Those following TR#46 and not IETF etc.

Basically, as with all protocol design, the question is not what you do with the ones that do follow the specification, but the ones that do not.

   Patrik

On 11 Sep 2020, at 1:19, John C Klensin wrote:

> Scott,
>
> Let me add a slightly different perspective (and a warning) to what Patrik and John Levine have said without in any way
> disagreeing with them.  It will also give you a somewhat deeper analysis and set of references to refer to if needed.
>
> As long as IDNA2008 is strictly followed, then it really makes no difference whether U-labels and A-labels are returned and the choice should be made according to what works best for the
> strictly conformant to RFC 3986, there there is a strong case for using A-labels because the alternative is %-encoding,
> there that consider 3986 (and 3987) obsolete and are developing their own URL specs.  There are overlapping ones that use or assume profiles of Unicode UTR#46 which involve some specific mappings and, for all intents and purposes, rely on IDNA2003.
> For IDNA2003 and those profiles of UTR#46, one cannot make an identity comparison between native character Unicode strings (UTF-8 or otherwise) without IDNA-specific processing.
> Whatever the arguments for and against reliance on UTR#46 rather than strict conformance to IDNA2008, that is a very strong
> argument for RDAP (and other protocols involving registration data) work in terms of  A-labels rather than anything else.
>
> FWIW and AFAIK, while, as Pstrik indicates, IETF has not taken a position on this issue for RDAP and similar protocols, ICANN has.  Long ago, when the Board created two committees chaired by Katoh-san, there were conclusions that, regardless of what
> interfaces registrars chose to present to users and what they accepted as input, all registration databases and access
> protocols [2] should work strictly in terms of already mapped and processed Punycode-encoded form and that, if native
> and not the user supplied string.   Those conclusions and the reasoning that went into them strongly influenced RFC 4690 and hence IDNA2008 but, more important from your standpoint, I don't believe ICANN has ever deprecated or formally abandoned them.
>
>      john
>
>
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Sep 2020 11:38:22 +0000

Thanks, folks, this was all very helpful. I think I have what I need.

Scott

> -----Original Message-----
> From: I18ndir <[email-masked]> On Behalf Of Patrik Fältström
> Sent: Friday, September 11, 2020 12:30 AM
> To: John C Klensin <[email-masked]>
> Cc: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [I18ndir] Guidance on Return of A-Labels in a URL?
>
> Scott: TL;DR of all of our messages are: A-Label and U-Labels are 1:1
> mappings to each other. The question is what you want to happen (and who
> is doing validation) of:
>
> In this mix you absolutely must include (for natural reasons) people that do
> believe IETF, W3C are nut heads, including for example the ccTLDs registries
> that do provide domain names not IDNA-2008 conformant. Those following
> TR#46 and not IETF etc.
>
> Basically, as with all protocol design, the question is not what you do with the
> ones that do follow the specification, but the ones that do not.
>
>    Patrik
>
> > Let me add a slightly different perspective (and a warning) to what
> > Patrik and John Levine have said without in any way disagreeing with them.
> It will also give you a somewhat deeper analysis and set of references to
> refer to if needed.
> >
> > As long as IDNA2008 is strictly followed, then it really makes no
> > difference whether U-labels and A-labels are returned and the choice
> > should be made according to what works best for the application
> > protocol.  If the URLs you are referring to are strictly conformant to
> > RFC 3986, there there is a strong case for using A-labels because the
> > alternative is %-encoding, presumably of UTF-8 [1].  That form is hard to
> read, less optimized for DNS labels, much less compact, etc., than the A-label
> form.
> >
> > _However_ note "strictly" above.  There are communities out there that
> > consider 3986 (and 3987) obsolete and are developing their own URL specs.
> There are overlapping ones that use or assume profiles of Unicode UTR#46
> which involve some specific mappings and, for all intents and purposes, rely
> on IDNA2003.
> > For IDNA2003 and those profiles of UTR#46, one cannot make an identity
> comparison between native character Unicode strings (UTF-8 or otherwise)
> without IDNA-specific processing.
> > Whatever the arguments for and against reliance on UTR#46 rather than
> > strict conformance to IDNA2008, that is a very strong argument for RDAP
> (and other protocols involving registration data) work in terms of  A-labels
> rather than anything else.
> >
> > position on this issue for RDAP and similar protocols, ICANN has.
> > Long ago, when the Board created two committees chaired by Katoh-san,
> > there were conclusions that, regardless of what interfaces registrars
> > chose to present to users and what they accepted as input, all registration
> databases and access protocols [2] should work strictly in terms of already
> mapped and processed Punycode-encoded form and that, if native
> characters were presented to users from those systems, they should be the
> result of
> > and not the user supplied string.   Those conclusions and the reasoning that
> went into them strongly influenced RFC 4690 and hence IDNA2008 but, more
> important from your standpoint, I don't believe ICANN has ever deprecated
> or formally abandoned them.
> >
> >      john
> >
> >
> >
> > [2] While WHOIS was the only game in town then, the Whois++ specs had
> > been published a half-dozen years earlier and the debates about
> > databases and database access permissions and tools were well
> > underway.
> >
> >
> >
> >> What you have is RFC 5890 2.3.2.6. Domain Name Slot and some previous
> >> sections that talks about the equivalence between U-Label and A-Label
> >> which is a 1:1 mapping (compared to earlier versions of IDNA
> >> standard).
> >>
> >> My view is that it is up to the protocol that pass around domain
> >> names in a Domain Name Slot how to handle the situation, and because
> >> of that ensure that if U-Label is in use that the requirements on
> >> that protocol element matches the definition of a U-Label, and not
> >> just "random Unicode code points in some random encoding and
> unknown
> >> normalisation".
> >>
> >> I can see situations where you in RDAP do want to be able to send
> >> random Unicode Code Points just with the intention to do some search
> >> on the server, but that is then NOT a U-Label. The same way I do see
> >> interest in sending A-Labels to be sure the string is stable and as
> >> it was supposed to be during the whole transaction.
> >>
> >> Does this help?
> >>
> >>    Patrik
> >>
> >>> Does anyone know of any text in any of the IDN RFCs that would
> >>> support a recommendation to return A-Labels in RDAP response URLs?
> >>>
> >>> (https://secure-web.cisco.com/1PK_rOPig5YMI6-
> Qrt1gNz_5CyTTbwNMDx9crt
> >>>
> zA3SB6VurxRB5Ef60dnxyG8iYiput8zffNsdFACm4iiFSgWTF1hOv9kwCSBO84Ts
> yDjS
> >>> dbIhE9w6ncWvlZvicjEkT29zcPEe-
> klPnwK0GqxnZjmVwH1qxl5PQafux34UVebh6qmB
> >>> 0M-
> zrTNAdTcdZ05_OcpO_G2jVq52uQcyZtgBLxPXo1he2ZbuhfZ7gsPG9tX0awAWe
> ZVM
> >>>
> S8eZ48me1v2jB3e3Lzlzic3ba832W4eUDXOmHW3uW3oydCDARwe6D1pF14/h
> ttps%3A%
> >>> 2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-blanchet-regext-rdap-d
> >>> deployment findings. In Section 3.6, he suggests that "All links of
> >>> any "rel" types should always be returned in the A-Label form for
> >>> IDNs in the href or value members, independent of if the query was a
> >>> U-Label or A-Label or a mix". That seems like a good idea since a
> >>> server doesn't know what a client is capable of consuming, but I was
> >>> hoping to support this recommendation with a reference to something
> >>> in IDNA. I didn't see anything obvious.
> >>>
> >>> apologize if I'm "jumping the gun" by asking he directorate without
> >>> waiting to see if they respond.
> >>>
> >>> Scott
> >>>
> >>> --
> >>> I18ndir mailing list
> >>> [email-masked]
> >>> https://secure-
> web.cisco.com/10_phtaKsvsQuH07jrEHgj7uHPlUIi0R4tmzOwX
> >>>
> BgYAvKcIGjSJ1xKu03S87xFRePOw3QY8p4N6qNHeOiVqE1dVDf2BzJShA4JjDcn
> Mz2LN
> >>> BQ_IGd4g_ih0MWa7jdGcS_IUeRqR_2JzIIzgf1-
> oTu0IEyMbKZLOBYoCtc2r83kkio3P
> >>> qZd2s6GfeJfV75tpIUWWXduizU-iXfhAjY-
> G55LK27dEWEQEgCMf2WlhM1IhdTKnXmS3
> >>>
> ebpRpvAwFm6escwmupFsH8DFWGkKsFU2Wh4fVpNbtvCuI51ukotJo7AJE/ht
> tps%3A%2
> >>> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fi18ndir