IETF Logo Mail Archive

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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 10 September 2020 12:41 UTC

Return-Path: <shollenbeck@verisign.com>
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 10EDB3A09EC for <i18ndir@ietfa.amsl.com>; Thu, 10 Sep 2020 05:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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, RCVD_IN_DNSWL_MED=-2.3, 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 (2048-bit key) header.d=verisign.com
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 Eg071WA0McGl for <i18ndir@ietfa.amsl.com>; Thu, 10 Sep 2020 05:41:57 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 7FA2A3A09D5 for <i18ndir@ietf.org>; Thu, 10 Sep 2020 05:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=988; q=dns/txt; s=VRSN; t=1599741717; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=R/xToyOoG77/pUg/eoD08RjeJeHtYNTFee3PGby0Eo0=; b=KC8HBWLs+/uw/mfuJatJhtLnhSV4irHKLXhCox7UPkAGtxJyLlD6u9sR cLEgryj4zbIkSQQyU+hpI8y1z/2EA9qinZ7WyVzX1dnKpJuB8TfXj/tet WDb5urIzFxO9iBICaXNRLXQvpl56l56mUOvufymGw+Qvxkp5Gb2vF9y5l BGabWbE8RszdVPc1Rdh/i60A0W+nWy2nnPS4GgL8qJiXURg+5sxusL7ih 0c+VsUfSDklcmduL2NVlC6vZ2m08oA/X/h5msm1VwwtY0NV7hnBa1LL8E Y9M2yH53z0Mju2IpSBvWVHFOGdbYi8PrsesSxU4p6neZN0Ub3GurQ22tf g==;
IronPort-SDR: b0ECxUXd/X/fuYmQkgEge57xcgsiq2k+dloI78Lat9qLm+OBl0n6eASwJtFDGfo1tVOA96mL00 6visAT9hsgpQi+0f7cYcYX/tf6ZpEUy67KmP1/Yj6fvUsbAdfrOYBQv9R4TxPh8MUCmNwot//c OVHkd/mm+Xsg8Yg1uqnVGeS3v4/wqXpCOyf7GUbzcsXFasQ4F413JkUnlCnt/8kA159Xr3Ydjt lOwcil+3+eavk3WvpEyTwh6N/lAhhTzDtK6V9F3MGFG2dhl5opeAfF+HCzzPLA4dKvE3JiDMNn oAI=
X-IronPort-AV: E=Sophos;i="5.76,413,1592884800"; d="scan'208";a="2772630"
IronPort-PHdr: 9a23:F3SdSRehptptxOv0CqqwW0Z9lGMj4u6mDksu8pMizoh2WeGdxcW+ZB7h7PlgxGXEQZ/co6odzbaP7ea5BDNLusjJmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFRrlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRS7oR/MusQWg4ZuJag8xxrUqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXDmp8qlmRAP0hCoBKjU09nzchM5tg6JBuB+vpwJxzZPIYI+bN/R+f7/Sc9wVSmdaQsZRTi5BDp+gY4cTEeYMO/tToYnnp1sJqBuzHQegCuHoyj9Mgn/5w6s63P8/Hg7a3wwsB88FvmnIo9XyKKcSTe65x7TPwDXYb/NW3jP96IzWfRAnuv6DQ65/ccnKxEkxCQzFlFSQqZfkPzOa0OQBqXSU7+1lVe+2jWMstg5+rCS1yMg2lonJmpwaykrC9Shh3Is4JMC0RkF/bNO5DJZetyOXOYVyT84hTW9mtzo3x7wGt5O7fSUHy5UqywPfZfGIc4WE/B3tWfqRLzl3hn9ofLSyjAu8/0inz+3zTMi00FBSoypEjNbMqn4N2wbU6sidRftw+Fqq1zWX1w3L9+1IPVo4mbfZJpMv2LI8i5oevErZEiL5nEj6lLKaelk+9uS16enrfq/qqoKTOoJ3kA3yL6cjl8qiCuoiKAcORXKU+eGk2b3m+k32XatFg+UtkqncrJDaPcMbprOlAwNN0oYs9RK/DzC+3dkFgXcJNE9JdxKfgYbmOl7CPO70Ae2hg1uwlzdr3ejGMqf7DZrQNHTDjq3hfa1760JG1AUzytVf64pVCrEHPv3zRlf8uMHEAhMjLgC5wejqBM9g2o4eV2+DGKCUPafKvV+N/O0vIu2MZIEPuDb6Lvgo/+XujX8+mV8Zeammw50XZ2umEft6IEWUemTsjckbEWcLpQo+TePqiFuYXTFPYHayWrow5isnB4K+EYfDWoetjaSA3CumHZBWYH1JClGWEXrzdoWLResMaCyILs9miDwEWuvpd4h0nxD35An2yqBPL+fI9Gsfr52pnIx0vr3VmRAo3T15E8rb1HuCGTJahGQNEnUW26R7rEp3x1yAleBDiPtECZYbs+hJVQM+OJjWwud5I87/QAPaf9iPDl2hR4P1UnkKUtstzopWMA5GENK4g0Wb0g==
X-IPAS-Result: A2EOBQBxHlpf/zGZrQo2BQEBIh4BAQsSDECEaYE0CrIFCwEBAQEBAQEBAQgBExIKBAEBAoZqJTgTAgMBAQsBAQEFAQEBAQEGAwEBAQKGRQELgjcie4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USYFEBPkImAQQbgx+DC7NpgTSFU4UDBoE4jUeBQj6BEYJig0gCgUeGDwS2dQMHgmUEmioqoFuSVJ9ZAgQCBAUCFYFrgXtwgzlQFwINlySFQnQCNQIGCgEBAwmOPoERAQE
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 10 Sep 2020 08:41:55 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1979.003; Thu, 10 Sep 2020 08:41:55 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "i18ndir@ietf.org" <i18ndir@ietf.org>
Thread-Topic: Guidance on Return of A-Labels in a URL?
Thread-Index: AdaHbyMe55MY1ZKMSpW68jWImAZiOQ==
Date: Thu, 10 Sep 2020 12:41:55 +0000
Message-ID: <326c954da33646f79a4e3bc4f27b7cb7@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/eCgKHWQnMFG25-TvrlU9DumY6jo>
Subject: [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 12:42:06 -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

v2.23.0 | Report a Bug | By Email