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

Patrik Fältström <patrik@frobbit.se> Thu, 10 September 2020 20:30 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988C73A09AD for <i18ndir@ietfa.amsl.com>; Thu, 10 Sep 2020 13:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-Kum5zzK6Kq for <i18ndir@ietfa.amsl.com>; Thu, 10 Sep 2020 13:30:57 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA303A09A8 for <i18ndir@ietf.org>; Thu, 10 Sep 2020 13:30:57 -0700 (PDT)
Received: from [192.165.72.128] (unknown [IPv6:2a02:80:3ffc:0:a004:611:de1:1598]) by mail.frobbit.se (Postfix) with ESMTPSA id 4157027259; Thu, 10 Sep 2020 22:30:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1599769855; bh=C+ONI3fXX2rpAs099TLRl5KJfkP9PG1KpdqafbIlWsw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Iznu+npFmXPtQXW2wbB5IXIIhjdUqIJtmNcij/o2+ehVTFKhE1OYNDXiBkGbjDo8r jtrK1qTfgiVJ0AkauRUjH0heSV3Q6u3vxnFb+bhV9zKwZglfO1r354o6nQ3WBfzPMa 23aPYfBXaMH7LpQ9F/RHCbYLMJxbSXZ6pFtKdsVw=
From: Patrik Fältström <patrik@frobbit.se>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: i18ndir@ietf.org
Date: Thu, 10 Sep 2020 22:30:54 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <0864F4FF-A615-451E-8828-433F3098A599@frobbit.se>
In-Reply-To: <326c954da33646f79a4e3bc4f27b7cb7@verisign.com>
References: <326c954da33646f79a4e3bc4f27b7cb7@verisign.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_3BCEC35C-38B3-4C55-B76A-C77304215D89_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/bKGPDC-5lt7N2onE9UG--123PTo>
Subject: Re: [I18ndir] Guidance on Return of A-Labels in a URL?
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 20:31:00 -0000

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-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
>
> -- 
> I18ndir mailing list
> I18ndir@ietf.org
> https://www.ietf.org/mailman/listinfo/i18ndir