Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response

Patrick Mevzek <> Mon, 27 April 2020 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 423923A0DB9 for <>; Mon, 27 Apr 2020 08:45:42 -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=NF85L78h; dkim=pass (2048-bit key) header.b=Vn+Ianuq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rcsxyziTSGC9 for <>; Mon, 27 Apr 2020 08:45:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32D7D3A0D52 for <>; Mon, 27 Apr 2020 08:45:40 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 8DBBF5C01AA for <>; Mon, 27 Apr 2020 11:45:38 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 11:45:38 -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:content-transfer-encoding; s=fm2; bh=g/KS7 yU79At/94ELbil+8hmMe0vzQg6Wer4zCpeNZRg=; b=NF85L78hajn3dtGAzp1VG w5p7SgyesIgGKL9uxYQhkg01rav/Av8l+5O49m++ztLYIY6px6JIwaYsO1eCWrn5 0ve0MLIeD0hrIvoMzI3RjbQd3LeBQK0nwNvHo1XXVh8bt9iH54NaHdFblIpIgg+b oIS9grrpp6YGrHBaTFV4TSWhuRqIi9OzL3+8tD5tmvp290ALE/MLquMPIj6m50WI 248uRVjkddYE+k2HB53RXBqZ8g1mUJk6aDkitUflvT26dro6tjc1MQx39Ee167uY h/fwnKzdk1vNIADeTryZ6lDOfuWZ3LMgl50VGnIDcZpayCUG0GXxGj+Q1M6hQbKF g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding: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=g/KS7yU79At/94ELbil+8hmMe0vzQg6Wer4zCpeNZ Rg=; b=Vn+IanuqwTcveCkIFOOo0LNmsP3Ppo6XB+N2WrpN2IRjYRmI5u16ookAd 3aANz4yO3NzkrFvtyYuh/xY1yuwdjpbaaLnb1Dv28QwhEy4QMatGW+rdB5UBn8Mn dNM7eT399kj3kkh5kOlpkLkKS/lxW/ECv2FLelTp5QD5dWKZ+YFceeJ6p5Z865A2 JI+8W0uSSTgTdQ6vu6Xc8J7D+SUnxKLVvUs4z9uHvY/i1Zr/YrXLGvkUZ14zTA0G aUoe/xr24/uDoQGCCic+TlsMZBAGPvq81+lOlIzfXGNzQHLXaeDHtS4K8u8ZMmA7 4SnyiS5NzmSNFndpE9tAztFf1yjGA==
X-ME-Sender: <xms:Iv6mXqlypB85StktOZZwmnE31SnFJdDO54Mk7jb2rX4iwg11oz6Do7xwEXw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheelgdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggt ohdrtghomh
X-ME-Proxy: <xmx:Iv6mXs-Yu_CErcFjvzayUDYCNaS9iocIQzWGY5UGBcHBDgKC0-2Xrw> <xmx:Iv6mXi86ckM-_izHTFChwrZx3t3gIvHm0GfPMus3cKzRrCkrOUeO6Q> <xmx:Iv6mXrL3BVzq5jS63LdHaLxq2U23q4qiLjqTG5aF_l1WvURoJZ19sw> <xmx:Iv6mXt4f0cOD1qjtOLUnwhdhJidMxTIIt5Os5ZMGcVLM_KC4A665eA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EBC446680073; Mon, 27 Apr 2020 11:45:37 -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 10:45:17 -0500
From: Patrick Mevzek <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response
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 15:45:47 -0000

Hello Mario,

A quick follow-up that could be a closure in fact, as your answer fills
the missing points I had.

On Mon, Apr 27, 2020, at 10:30, Mario Loffredo wrote:
> Il 27/04/2020 07:45, Patrick Mevzek ha scritto:
> >
> > On Fri, Feb 28, 2020, at 09:43, Antoin Verschuren wrote:
> >> The following working group document is believed to be ready for
> >> submission to the IESG for publication as a standards track document:
> >>
> >>
> >>
> >> This WG last call will end at close of business, Friday, 13 March 2020.
> > I am too late, I know.
> >
> > But anyway I fear that at least the "brief" case will create interoperability
> > problems, or at least complexity in clients because there is a risk of each
> > RDAP server thinking of it differently.
> I published a draft version, namely 
> draft-loffredo-regext-rdap-partial-response-03, including a definition 
> of the "brief" field set which was based on those WHOIS response fields 
> identified in RFC 7485 as mostly supported (i.e. by more than one third 
> of contacted services). As you can see from the "Change Log", that 
> definition was removed in draft-ietf-regext-rdap-partial-response-01 
> because the WG had clearly recommended to separate the technology, 
> described in the RFC, from its operational aspects, described in an RDAP 
> profile.
> The same feedback was recently provided by Karl Heinz Wolf and now I'm 
> giving you the same answer as I gave him.
> Anyway, if the WG members reconsider their position about this point, I 
> will be happy to refine my old proposal or work on a new one.
> > The "subsetting_metadata" is only a SHOULD not a MUST, so clients could
> > remain completely without real explanations on why "brief" for server A
> > is different from "brief" result for server B.
> It's not a MUST because the available field sets could be defined in a 
> document published elsewhere, for example, in a specific RDAP profile.
> Therefore, in my opinion, it would be recommended but not required.

I agree with all the above, in theory.
My main fear is once the draft being put into active use, I am not sure people
will bother creating other proper IETF documentation on what "brief" is,
and hence the pretty much result I see coming is multiple servers using "brief"
in completely different senses, without always to use the metadata, and hence clients
will need again to hardcode on their side assumptions per server, which is very
bad for interoperability.

I do however profoundly disagree with:

> because the WG had clearly recommended to separate the technology, 
> described in the RFC, from its operational aspects, described in an RDAP 
> profile.

As this argument is used when wanted but not always. At the same time, we (the WG)
see no problem (but I do) to define a BCP on "secure transfers", which is certainly
just operational stuff and not protocol stuff, so sometimes we do hardcode operational
stuff in WG documents. So we should either do it always, or never, but using that
argument only in some case and not others is not something I find good process.
That is just my generic view, nothing specific to the one draft discussed in this thread.

> > It would have been nice to provide a template for "brief", at least a SHOULD,
> > per objects described in the RDAP RFCs.
> See my response above.
> > Specially since the document has this text:
> > "the
> >     name, as well as the list of fields for each field set, should be
> >     shared by most of RDAP providers."
> Obviously, the field set approach is valuable if there is a wide 
> consensus on both the name and the content of a possible field set.

I agree, but I am not sure there is such consensus. Or even if there is here
on the mailing-list how can be sure there will be among all RDAP servers working?

> Three possible field set names have been recommended in the document in 
> order to ease interoperability. For the field sets representing the two 
> extremes, namely "id" and "full", the corresponding content is evident.

Yes, clearly my worries are about "brief". 

> > Written like that, this is not a protocol specification, and does not even
> > give tools at the protocol level to enforce that.
> >
> > Or, and this could be an easy solution, another draft defining rdapConformance
> > subsetting_brief_level_0
> > should define exactly what is brief and then servers are free to properly
> > signal if they adhere to this definition of fields or not.
> > There could be multiple drafts in fact for multiple definitions.
> This is an interesting solution but I dont' see, at least in the case of 
> "brief",  why the WG should approve to define in a separate draft what 
> has been considered unsuitable in this draft :-(

Understood. I am probably once again possibly at odd's with the WG but it is not
something unheard of already :-)
So anyway, I believe we will see problems in the future, but we will have to wait
and see them I guess.

> I would like the other WG members to manifest their opinions so that I 
> could change the document where appropriate.

As you said, the issue I raised was already discussed and settled so probably
no need to rehash it, I was the one being late here, I should have taken
more attention to the previous discussion, but I was not able to reserve
the time I wanted to participate in this WG lately, sorry about that.
So no need to spend energy on my late points.

  Patrick Mevzek