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

["Hollenbeck, Scott" <[e-mail]>]

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

Scott

> -----Original Message-----
> From: I18ndir <[e-mail]> On Behalf Of Patrik Fältström
> Sent: Friday, September 11, 2020 12:30 AM
> To: John C Klensin <[e-mail]>
> Cc: Hollenbeck, Scott <[e-mail]>; [e-mail]
> 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:
>
> - 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 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=[e-mail]> wrote:
> >
> >> 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:
> >>
> >>> 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://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
> >>> 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
> >>> [e-mail]
> >>> 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