Re: [regext] rfc7484bis

Marc Blanchet <> Tue, 11 August 2020 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67CAA3A0BC4 for <>; Tue, 11 Aug 2020 11:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dLhoPVQucQkN for <>; Tue, 11 Aug 2020 11:55:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F23B73A0B94 for <>; Tue, 11 Aug 2020 11:55:20 -0700 (PDT)
Received: by with SMTP id 62so968137qkj.7 for <>; Tue, 11 Aug 2020 11:55:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ip76rsN/H/dL6RmNz1prp6Gp7HPl4Zs0AQlM4TSnRWg=; b=DZroxHMzcG0a9pg4wt5BO9Q+uNLpAp/lJlOm3D/QzQfyKFnqQ5BL968sVJRLQ1Ss9H 6F7wFOBuIPpKjs2b8c5QeYOaKBS/SbwH9uOFu+3pdxyAkLh1+07gXJIN0XOq942UppoM xEdera26NTR5O2HqjbltorjAEgl9lR1ctclAbWnWbtSaP8Ym3WDIEG5ylA2ZHKy4u/OL 3zBx2rVjA9eK0Jq0vT6vlnfTxd8xCd6RmgS3BMvNicNrH1f6Se8FRJ5p/dFO6BK0tH62 1ScjqXhItOuBHomhns5ijYwXqsCV5O4DtE03/Z4+BX/vjY0Cuyb5cYrep0Glq/zA1YZv NvuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ip76rsN/H/dL6RmNz1prp6Gp7HPl4Zs0AQlM4TSnRWg=; b=alINN8dFAJ7N1LYypQjn5HTBq9g6IHB1QOGMqfyBSimqsJVdiI+xNqsWKnDm4SOFM5 iH8BozAliCO+R1NU+FZhor6Zo4X0xHkgNtneO0ZAav0RcLrDlemWXWVHFayCGa9S24jA d3rNj6DazhZFlccMADNKYv57KMYXfN0+ZpfmTzDuCYD7y/ozLo4vWwwooA6WCGrE4Zls egr8+mUPD1K2k7zdSN4DHpzoIQyKKdYuOSA/VQV0fDIe4iQSl3ur8Zdg5071uNWLX3eT 1XrG3Czz8Inta3engTjwiaBKhQTaKr/8atFHSH/x4VI1yEwO72+MR7dqdp65bnZyx++l /L4A==
X-Gm-Message-State: AOAM532u2UPMh6/yt31GC2pFPvsBS7HkxanfV1A1fF2JpUVYf46JTtnY E3HCLiV2B7wOsmEzCcypPYe/qg==
X-Google-Smtp-Source: ABdhPJwsBnAflIxdYI4PyhumVPcmnayN1Wb3kE61o9XomR47N+jkaiUratxXUCSN0ZGIhe4FlhCr7g==
X-Received: by 2002:a05:620a:4ec:: with SMTP id b12mr2608783qkh.266.1597172119854; Tue, 11 Aug 2020 11:55:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x67sm18817760qke.136.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 11:55:19 -0700 (PDT)
From: "Marc Blanchet" <>
To: "Patrick Mevzek" <>
Date: Tue, 11 Aug 2020 14:55:17 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
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: Tue, 11 Aug 2020 18:55:22 -0000

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 

> 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).


> -- 
>   Patrick Mevzek