Re: [regext] rfc7484bis

Rubens Kuhl <> Mon, 17 August 2020 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEC603A12E3 for <>; Sun, 16 Aug 2020 19:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BZ8eN-0ohHyp for <>; Sun, 16 Aug 2020 19:08:19 -0700 (PDT)
Received: from ( [IPv6:2001:12ff:0:4::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8E6C3A12E2 for <>; Sun, 16 Aug 2020 19:08:18 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FA311DEC39 for <>; Sun, 16 Aug 2020 23:08:15 -0300 (-03)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YV2IVDhVan2p for <>; Sun, 16 Aug 2020 23:08:12 -0300 (-03)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 4CB821DDF19 for <>; Sun, 16 Aug 2020 23:08:12 -0300 (-03)
From: Rubens Kuhl <>
Content-Type: multipart/signed; boundary="Apple-Mail=_27449F47-DB60-4321-A1E2-AF971FE565FF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sun, 16 Aug 2020 23:08:10 -0300
References: <> <> <> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
DMARC-Filter: OpenDMARC Filter v1.3.1 4CB821DDF19
Archived-At: <>
Subject: Re: [regext] rfc7484bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2020 02:08:23 -0000

> On 11 Aug 2020, at 16:27, Patrick Mevzek <> wrote:
> Hello Marc,
> On Tue, Aug 11, 2020, at 13:55, Marc Blanchet wrote:
>> On 4 Aug 2020, at 15:47, Patrick Mevzek wrote:
>>> 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.
>> well, this has been debated at length during the WEIRDS working group
>> work. I actually wrote a sentence about this in the RFC (in the
>> acknowledgements section). I’m not sure we want to restart the debate
>> again…
> I am not saying to restart the debate, especially not in the context of a -bis document where protocol changes are not welcome.
> But the RFCs are also 5 years old now and a lot of things change quickly.
> SVCB record in the DNS being one, while not there already.
>>> 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.
>> yes. this is the well-known caveat of this RFC and discussed and debated
>> during WEIRDS. But experience up to now has not shown any issue, at
>> least to my knowledge. (and as a developer of the RDAP Browser mobile
>> app, I haven’t seen any issue fetching that registry. I do have found
>> thousands of issues with the registry/registrars RDAP servers however,
>> but that is another story).
> I am not saying there is a current issue, fetching the JSON file from IANA
> webserver is clearly the smallest problem of any RDAP client.
> But I also think there is currently no issue because basically the world did
> not shift to RDAP in any way yet. Which can easily be witnessed by the amount
> of broken servers so far - even if they are in a regulated space where compliance
> is an issue - and the total lack of ccTLDs in this space, at least in operations.

Of the 822 https:// URLs in <> , and 0 http:// URLs, there are some for ccTLDs:

So, I believe we could remove http:// as a transport option, and that there is no total lack of ccTLDs. Surely there could be more.