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

[John C Klensin <[e-mail]>]

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://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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i18ndir