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

Patrick Mevzek <> Mon, 27 April 2020 08:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CDA33A11DE for <>; Mon, 27 Apr 2020 01:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=aAw+Md3T; dkim=pass (2048-bit key) header.b=tJTC6TLq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7I0TmFRjPvN2 for <>; Mon, 27 Apr 2020 01:08:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A85F3A0F51 for <>; Mon, 27 Apr 2020 01:08:06 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id D334B6CD for <>; Mon, 27 Apr 2020 04:08:04 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 04:08:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=ITdKpXLXbUBbd+rItueE600NdbS6j+2 CiUNXgEuf9x4=; b=aAw+Md3ThgANN0M+sbJS6BUbHrD233s+SZ+ABuAlIo3e2kK do15f40Dt1VnSImop6qqYgLdP0hLjgdExIGV0Zz55vhfqHXHI5W9v8C3K6G4E0aa aU1lptqn2tj2eZjscc1HDu7nVL5bHjsqzZATHb8GbrrJ7aAlYeEAUpg9M4SoWHbE maqV54ODExmdD32w9RtscdQkjo5uXWb4wJXId9zkPGTUxtUQvEOV20HgKBRlZGOY bWRghORKrqXuuNjz1gzBba5g/y4lDjgPF24d+wco54Q4rXrEu8PzcdGW3nAxSqdD nCA6ZKEVLwVP8dBuaywz+sphBudzNmUNd+PmkuA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=fm2; bh=ITdKpX LXbUBbd+rItueE600NdbS6j+2CiUNXgEuf9x4=; b=tJTC6TLqhIcJsVOyDG+HB9 2pS3x0jjSq3eVTQpVjrxLo5kK6vX4kvcFaK2Fw3s2mH0UJwtxZOdmei17A+hetNC sbIiT82jl9Bikv1+w/Fx03KiuCO7G47W9hda9hsG+V89LGjxQEsY5aHXc8YiguGD Qj8LTiA0hM7VC3d6Gq5IgnSUHUf+cZlng/QY5+YUQBHpYwIh723botlf4aQYaX6U oRRwcflcjnOCpSlXo78j8PsHZ/o+WH4sxgRe/lglqRsDt9wxRa58aGJsrL8MyshB uEEmF7cEZTyMiNDaukW8tBPCF67bfM/sMPZYFHnfkcAqPnGp3XgXuYyKOueR1clA ==
X-ME-Sender: <xms:5JKmXstB2PqBYjCnYzEV9_ZBLcI46L8S_Flz8sheh_AtGjJjGUJlEGVRJ7g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgdduvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucffohhmrghinhepuhgtihdrvgguuhdpihgvthhfrdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhm seguohhtrghnuggtohdrtghomh
X-ME-Proxy: <xmx:5JKmXnBBmLVMEUb0opFZRH0gCkXAv7dggAKe44VKOJTeNEXpUUwmQQ> <xmx:5JKmXuPqjR7xkl37WRMZddM3brYLCLnITa8rnuTiVi7YjeeP4f4Duw> <xmx:5JKmXgzJbS722YrMTXjHFd5mSPvndaAOdmq_YsL2L3cdesiIifJdOQ> <xmx:5JKmXvdxoodY9hW70wGIDEs6JoGwYuFXFrzmhr8viAQTAHF9SqWUGg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EAF496680073; Mon, 27 Apr 2020 04:08:03 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 27 Apr 2020 03:06:24 -0500
From: "Patrick Mevzek" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [regext] =?utf-8?q?FW=3A_I-D_Action=3A_draft-hollenbeck-regext-r?= =?utf-8?q?fc7482bis-00=2Etxt?=
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, 27 Apr 2020 08:08:10 -0000

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.


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

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?

9.2 Nitpick

Use https:// for

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?

PS: there is currently a problem in the tracker,
a version 03 is shown as existing but you can't view the content.

  Patrick Mevzek