Re: [regext] rfc7484bis

Patrick Mevzek <pm@dotandco.com> Tue, 04 August 2020 19:48 UTC

Return-Path: <pm@dotandco.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 B1DFF3A10F5 for <regext@ietfa.amsl.com>; Tue, 4 Aug 2020 12:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=dotandco.com header.b=Sfa2buW1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dh4MDojV
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 sa2ZdR575-X9 for <regext@ietfa.amsl.com>; Tue, 4 Aug 2020 12:48:11 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFA83A106E for <regext@ietf.org>; Tue, 4 Aug 2020 12:48:09 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1207E5C017F for <regext@ietf.org>; Tue, 4 Aug 2020 15:48:09 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Tue, 04 Aug 2020 15:48:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=v+vPMCLqB3Bzb3S7nvL/EWX3yzTZA9s fH3pX0w0mpy4=; b=Sfa2buW1LOmhJJVrJhzSWRxGcbpXVKyN7OsG0aLL8vV4f+C UrUpnHof8ofhK/6E8kLjOJZGAUNk/8Llv4xooXCAA65uPoE/ExRZ+K+p2GcijEWf z2mBo7jGb33MIi3BLNBfjktnaQ7azyr8gTh7uGZtJm9gq6SCBxSZmEBALceKNS5e P5V6RopV8bHbUJLE8IvD+oyQkMd6cBi17bdTtovh+s4PiGdI8+2ZBk9qld1OJfuv 0qQK8IigpyE3ZjBEFQuAz0dlFIVbGsewCC8AgZ+aDy+eRx7Rp2Bkvk9lXytjWz2J DNR1Lmci71btO+L/HVHJRJcjB1f7ENY05Ne+zpw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=v+vPMC LqB3Bzb3S7nvL/EWX3yzTZA9sfH3pX0w0mpy4=; b=Dh4MDojVaNYM/f42BdBPGI HXpwW3cp1zquE0mEnmOqL8p5ef7kTE7AXX8NZqHAg+QYE2+O/ew9tTwDz9780WHN B9Lus8i0lAF27g3yLtMBuzIQz1uWRg5shM+cvuPEtVbBEL0xay8feM086shVMvrz dB7uf397Q7I/cf2L5IGehq1exniDJVFvoFXtGQFOpVR+aphWIWF8CtdGQ/XkoIqx CQJ3Vw3TaviBW/k1Pm2UYygcLp1zecCz0W/eJTjsncmVZdSw5HTI4I/OCew/gC/2 lqwkxR06/TcjEU3jv11ftT1qce5wZEqWpf/j/FmFB1+f8S6dP2Qd1dB6v2YWKRFw ==
X-ME-Sender: <xms:eLspX8iaZMa90CxZQov1eKtOumZSibAsXPyQboKCiM19Z1Mtr7we2h-h_Nw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrjeeigddugeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedugfffieehffejkeduhfdvke evffdufeeuieekheeuffejfeejieetieehudfgkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:eLspX1CzO0TSq7d9SPG86qhgbVoeLDUUCd49zcWI69m8C81NYSXSaQ> <xmx:eLspX0GRpVU7hqzt0vixHsBFUGwtr0SipoGwEN0xw9vxbAeRxIJMug> <xmx:eLspX9SqzsIETRAwX5sDFpdcTuiMCIjXPW6VhNpjYwri6xsslnNtkA> <xmx:ebspX9iuupQ2ZR7MjoVFL7xMf2u5qAbdTjoVCzRcpYlEkpsOXs58VA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 86730668007C; Tue, 4 Aug 2020 15:48:07 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-136-gc39b634-fm-20200803.001-gc39b6340
Mime-Version: 1.0
Message-Id: <00ae8cca-fc44-4279-b6f7-3f57d86474b1@www.fastmail.com>
In-Reply-To: <801B9484-0F94-4CB4-ABBC-AAC495361E80@centralnic.com>
References: <801B9484-0F94-4CB4-ABBC-AAC495361E80@centralnic.com>
Date: Tue, 04 Aug 2020 14:47:31 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/ioYQC7_Hlsv_P0524N_5a8MbaGE>
Subject: Re: [regext] rfc7484bis
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, 04 Aug 2020 19:48:13 -0000


On Tue, Aug 4, 2020, at 14:32, Gavin Brown wrote:
> 1. client implementers should be advised to prefer https:// base URLs 
> over http:// base URLs.

I think this is already addressed by this text in the current RFC:
"
   Per [RFC7258], in each array of base RDAP URLs, the secure versions
   of the transport protocol SHOULD be preferred and tried first.  For
   example, if the base RDAP URLs array contains both HTTPS and HTTP
   URLs, the bootstrap client SHOULD try the HTTPS version first.
"
 
> 2. server operators should be advised that if multiple base URLs with 
> the same scheme are present in an entry, then all the RDAP endpoints 
> referenced by these base URLs must return identical responses (for the 
> same RDAP query).

Why "with the same scheme" here? If there is both `http://` and `https://`,
even if that is not advised, shouldn't both cases respond the same way?

PS: related but not directly, at least for domain registries, it would be
nice to have an `SRV` record on `_rdap._tcp` or something to point to relevant
RDAP server, even if that does not allow to encode the path (but maybe a solution with .well-known/ and URI template could be found), it allows at least
for nice failover and load balancing. It may be a problem for gTLDs as they have
restrictions in content of their zone.
Maybe the newly expected SCVB record could help...

A setup like that would allow for discoverability without centralization of data,
which also removes IANA from the hot operational path when RDAP clients do queries.

-- 
  Patrick Mevzek
  pm@dotandco.com