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

[Patrik Fältström <[e-mail]>]

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