Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7482bis-00.txt

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 05 May 2020 16:59 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D96B3A094C for <regext@ietfa.amsl.com>; Tue, 5 May 2020 09:59:13 -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 (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 5WdaLjPDxJ2G for <regext@ietfa.amsl.com>; Tue, 5 May 2020 09:59:11 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 4C34D3A08FC for <regext@ietf.org>; Tue, 5 May 2020 09:59:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4793; q=dns/txt; s=VRSN; t=1588697952; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=hnwehXtTqROnffLJB32rSktDHGGVXsSo0hGrCfc+5lc=; b=Q8f6jseCJl8cjveDfz23mbjZXLqRXgvUQWSH1tiVu24VeWMUUHILSQ2B 4NX0MOdz1L+2yG6WiLH7vonTPIowlNoQGOK31iPgvgkzw0Ao4yuZ3BfD9 cFB0lLfnWhWqKC21VhrD8zfQTMBr3hQNgP6JK2SfHLkQd6DQNyzLOke0v 4TDrnw7aGURKjG+JYr77afuYAq4vdYWa6B3UN6NfFp9/rwWe97d3xfixQ ZSH4X9pztJ8yXY1wdiUbnpGwnSGJutfS3VLPf7dP6SUIK1bnNjxWdGAid FgynS3j79c5TawVGfmqR4OAVfffL57X5+TvbOriL8ihTKRce+MZN7Zt3h A==;
IronPort-SDR: 5tm2Mtf7DeuzkAyYtayX1iGwHypOk2nnQPzwbzIiQ18UyicyD/pcJFTIReCddBwchkXVvEvIHE Gtqwag96W/5IKswTnXzq2MZgAwvMhsICzb524SkQeBELDObFQsdaJmorhJXFdPaDaW2UEAA2wq 8d8nEm1N7NBXe90EvU+kxq+rkOqOXTzGurOb/OjRR43JQ/p3DgUNnXwwKtj1TtD8141SJGfknZ VRGbhWnROiLnO0KNXHi6Qm8Ewrr1fasrc3OrQ3NXebv1XuLOH8dqVYWTF9OAGEgMHyS6hnWFgG lgk=
X-IronPort-AV: E=Sophos;i="5.73,356,1583193600"; d="scan'208";a="1472913"
IronPort-PHdr: 9a23:Z2vVth+MG30yLf9uRHKM819IXTAuvvDOBiVQ1KB+0+8fIJqq85mqBkHD//Il1AaPAdyGra0awLOO6+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglVhDexe7F/IRS5oQnMqsUanZZpJ7osxBfOvnZGYfldy3lyJVKUkRb858Ow84Bm/i9Npf8v9NNOXLvjcaggQrNWEDopM2Yu5M32rhbDVheA5mEdUmoNjBVFBRXO4QzgUZfwtiv6sfd92DWfMMbrQ704RSiu4qF2QxLulSwJNSM28HvPh8JwkqxVvQ6hqRJ8zY7aYo6VNeZxcKzSct4BWWpBR8RRWzBdDo+gcYcCCfcKM+ZCr4n6olsDtRWyCwurBOPrzj9HmHn20rYk3Os9EgHKxBErEc8Sv3TTsNX1KKkeWv2ywanTzTXDaPdW2TPj54jOaR8uv+2DXbFrfMrP10YvDQLFjk6RqYzqOTOZzPgCs2+e7+d5U++klmEopR1rrDe12scslpfGhpgTyl3c9St13og7KN+5RUN4fdKpEIVduzyeOoV2Qs4uXWBltDs6xLAYuZC2cisHxZUjyhDRdfGKfZWF7xzjWeuMITl1h3Roc6+xiRa19Eiv0Oz8Vs+s3VlWrypFicXDtncX2xPP7ciHT+Nx/lq91jaOzQzc9PxLIV0smaraNZEh3rAwmoAUsUTZES/7nlj9gqyOdkg85+Sk9/7rbqjkq5KSLYN4lwHzP6o0lsGwBek0KhUCU3SB9eih1rDv4Vf1TKhFg/A1iKXVrZPXKMIGraCjGQBVyJws6xOnAjej19QXgGcIIUpeeBKCk4jpI1bOIO3kDfung1SjjjNrx/feM7D8HpvDNmXPn7f5c7hy6kFQ1BQ/wcpB551IDbEBOurzVlXru9PFFBM5LRa0w/3hCNlnyoweXmePDreYMKPUr1CI+voiL/SQaIMPpTrwKfYo6+TzgXI5l1IRZ6ak0J8PZHC9BPtmIkGZYXT2gtcGFGcHphE+TOztiF2GVT5ceXCyULki6T4nC4KrFpnDSZ63gLyAxye7H5JWZmZcBl+QFnfocp2IW+0QZyKKPs9hjjsEWKC5S48kzhyhqQj6y6Z9IerS5yIXqZXj2MJp6O3UkBE47SZ0ANiF02GRU2F0mXsFRyUo06Bwv0N8xUuD3LN5g/NGCdxT6elFUgAgNZ7TnKRGDIW4QgfpctCVQVCqSdLgCjY0BJpl29omb0FhEtOuhReF1C2vVftd3aaGC5Ek7ord0mT/YcFnxDyOgLMsgFQ2XuNOOHGowKll+F6AKZTOlhDTt6Gucaka1iPG9yPL9mGJoF0SGFprUaLBWX0ZbEbdrvzn61nDVL6hD/IsNQ4Xmp3KEbdDdtC81QYOf/zkItmLO28=
X-IPAS-Result: A2EsBACmmrFe/zGZrQpmHQEBAQEJARIBBQUBQIFHgxiBMQqVKJl3gSs8CwEBAQEBAQEBAQcBIwwEAQEChEICgiM4EwIDAQELAQEBBQEBAQEBBQMBAQEChj8MgjsidzwJOQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEEAg1USQEBHQEBAQECATo4DAcEAgEIEQQBAQEeEDIdCAIEARIIgx+CXC+yfHSBNIQ5AYEWhHmBOIxegUI+gRGDED6CJ0ACgTABEgEJhgoEmAOaTgMHgkiIGI92JYJbiGGBGJBMkBeJVJNIAgQCBAUCFYFpgQlwcIM5CUcYDZB6gzqKVnQNKgIGCAEBAwmRNoEQAQE
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.1913.5; Tue, 5 May 2020 12:59:09 -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.1913.005; Tue, 5 May 2020 12:59:09 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "pm@dotandco.com" <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7482bis-00.txt
Thread-Index: AQHWHGsGGHjfbpmwCki/isMdX/o2qaiZvzsw
Date: Tue, 05 May 2020 16:59:09 +0000
Message-ID: <5500dccc351449c287a4baa006929136@verisign.com>
References: <157978263830.22814.10753224081346165172@ietfa.amsl.com> <1a23b173513a40568e5fa6da66df9686@verisign.com> <a51395d3-137f-40b9-bab0-a6f636188a10@www.fastmail.com>
In-Reply-To: <a51395d3-137f-40b9-bab0-a6f636188a10@www.fastmail.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/regext/LsE50uWlJrIJnM2BkqwGYuzObHQ>
Subject: Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7482bis-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 16:59:13 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Patrick Mevzek
> Sent: Monday, April 27, 2020 4:06 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rfc7482bis-00.txt
> 
> 
> 
> On Thu, Jan 23, 2020, at 07:35, Hollenbeck, Scott wrote:
> > FYI, folks. I just submitted the first version of 7482bis. I've
> > addressed the known errata, but I also have some clarification
> > suggestions queued up for discussion. I'll start a thread for each of
> > those shortly.
> 
> 
> See my previous email on RFC7483bis the same caveat (on the breadth of
> changes called for) applies here.
> 
> 3.1.3
> 
> This part comes directly from direct observations of what exists out there.
> There is at least one RDAP server that generates URL for the "next" RDAP
> server (to query the registrar) with the domain name in full uppercase.
> For ASCII domains, this makes no difference.
> However, I have seen multiple registrar RDAP servers that then fail to
> process this URL. Just changing the domain name in the URL from uppercase
> to lowercase makes the registrar RDAP server work.
> 
> One can say that this second server is broken, but another can say that
> lowercase should be preferred, because if the name is in U-label form, you
> do not uppercase it anyway, you leave it as is.
> 
> So while maybe we could keep accepting as input when doing the query the
> name in any mixed case, maybe server should be expected to generate URLs
> in specific letter case?
> 
> RFC5890 says:
> Therefore, since a valid A-label is the result of
>    Punycode encoding of a U-label, A-labels should be produced only in
>    lowercase, despite matching other (mixed-case or uppercase) potential
>    labels in the DNS.
> 
> 
> So maybe rfc7482bis should give more guidance either explicitly allowing
> both forms, or mandating only one, etc.
> 
> Of course, potentially, same applies for 3.1.4 and 3.2.*

5890 is already a normative reference, so RDAP implementations SHOULD be following the guidance it provides. I'd rather not repeat that guidance in 7482 because it's already included in a normative reference. This could, however, be captured somewhere in a document that provides implementation guidance like ICANN's gTLD profile. This is, however, more of an issue for RDAP responses, isn't it? The DNS specifications also allow labels in both upper and lower case, so any RDAP server that chokes on a query containing one form or the other is most certainly broken.

> 5. Extensibility
> 
> See my discussion about the prefix for attributes and the rdapConformance
> token name in the thread on 7483bis But same here for path elements, do
> we want the prefix to have any relationship with the token in
> rdapConformance?

Where do any of the path elements touch on rdapConformance values? I don't see "rdapConformance" anywhere in the text.


> 9.2 Nitpick
> 
> Use https:// for
> http://secure-web.cisco.com/1nISAjXBpKL_XIglWvOW0Z69bNYuU7P-
> Vyn7KAwEKh9j-ac54KiLWzTR-krTSDR34ISI1-
> 8aDLHBYBILKyhQ_rg4aBDSDwDNMrP2Pj3n85oemJCDRCXjTJIu_WkYQ7EPA58
> sdEGR_5MYw9HaS4JSHuOKOm4uxA1tN8BZEtnVJCF0XeVbKl8S3D_oaeIfc6zZF
> dwIi3UGRWbxscxTIJKU-
> tADzhfDXPjZmzLVfUCGr42xabBKvi_Ti1Nd0FGNEgY9nb2NM66SWeQhzdzpsn
> 9jP3g/http%3A%2F%2Fwww.ics.uci.edu%2F%7Efielding%2Fpubs%2Fdisserta
> tion%2Ffielding_dissertation.pdf

When I try to open that URL using HTTPS, I'm redirected to an HTTP connection. I think this needs to stay as-is until UCI fixes things on their end.

> Also in general for all bis drafts, and please excuse my ignorance there, but
> shouldn't they reference themselves on the bis version instead of previous
> one?
> Example, this text:
> "   This document does not describe the results or entities returned from
>    issuing the described URLs with an HTTP GET.  The specification of
>    these entities is described in [RFC7483].
> 
> "
> 
> Shouldn't RFC7483 be replaced by the draft rfc7483bis?

Yes, will fix.

> PS: there is currently a problem in the tracker, on https://secure-
> web.cisco.com/1YVDVzKtTJoaVCJqtJ6jmMmAyc385Fif2d0IPdsKbQacOIRJ9tz
> wxVPM6iHxe-
> tME45ThxCqPMpgqvLRESYsoLO3EPcEviZXznuxJ_7_F14IVxBgXNS1JbXBLbNcp
> URZbAUr0D2NmfBDZ3AhFzawHjlF8HL6CxP1iuoUpcjNzRrMJTEJMoZnRpwSFH
> FMpWoxmdC25G1L8pCcubvIP7zhGiuKgY0rZ3CrNwmWPJLy1oi99AMhSz3aC7
> psPsGBli8Zixvi-_Sj4rWIN-
> bL82fITwA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-
> hollenbeck-regext-rfc7482bis%2F
> a version 03 is shown as existing but you can't view the content.

I noticed that, too, but it looks like it's there now that I've published -04.

Scott