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

Patrick Mevzek <pm@dotandco.com> Mon, 27 April 2020 05:46 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 C721D3A0C98 for <regext@ietfa.amsl.com>; Sun, 26 Apr 2020 22:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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_DNSWL_LOW=-0.7, 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=aXHF0Liz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1K1ZJYVX
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 Dq5n2E_xx9MO for <regext@ietfa.amsl.com>; Sun, 26 Apr 2020 22:46:05 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BD23A0C9A for <regext@ietf.org>; Sun, 26 Apr 2020 22:46:05 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 6F7F6640 for <regext@ietf.org>; Mon, 27 Apr 2020 01:46:04 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 01:46:04 -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=fm2; bh=nHJUamxFUoLOU8Vhnolfc2uq+nVoFCK 59RAjfuo5mJs=; b=aXHF0LiztzKH8XXsKMNSYoaex07ybpvBWYlaKWArN4mtIKN t+i8jA9bm8QfgJKgl77QCitwyzaAsz6cJfUpa7IOrgBE350lKJeroqpzeFPcNOcE x2rzlGtezw2AlnQ8IIL/n4zSiA2Ck5RTHxY+ydhCoWvAMZWjvGZWpD4veNYQ8h55 6/qIrxbItbhhENbxmmsUc8Hev/hwqQKEghiolaFluHmlxZRC9PQZHizPo9+FiOPg cdq11Sf8hAL6z+OwfB3kmHif0+grnVDc76wHAwQjvBHnPUSuzx3vB4FaaMo3SX8V Go+F3qoeBKeB3S4T7z3cUoZGrjRfVajCjHG6WqA==
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=fm2; bh=nHJUam xFUoLOU8Vhnolfc2uq+nVoFCK59RAjfuo5mJs=; b=1K1ZJYVX1rQm1DPxbvqbIe 1pJUa8nptzoe+bFe7P8o8upQCzGT90PycnJhlVjgoCZ1BGmlOnis5x7df8aPD3Fl ePT6BSGNd1GJffsftV0osnFSImvt0gklXbmD3HocCpjEXmRufLb6qL8eTB2ycc/K FGIiij0wC0qEFHGjkuUdbYzWaxcuEodHi1ltMkcYIK02+8BItadQ2UvpjcMGsfNt 6bwa3qkjB+MHmGLaDCWKZ6hSedBZ9o7YE4ySzXkPiBioyav0ChDj6hWcDQa5B4wo I0Ykkf8/7fgWYelIKSN5N3wqBbvdfqrqL0qzdz7zX3SBJ2IIZtjb5DeZlzGONVkA ==
X-ME-Sender: <xms:m3GmXtT8oCK0m3Jr7VndTf0Isdz_K4kNYK0Z29YkhNMhuYmklUeT-DMihuA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggt ohdrtghomh
X-ME-Proxy: <xmx:m3GmXqfYwOPU__Pe5-5gUJTy9WARUFN7l5oxh-Fz5c8wCiq0IQ5YrQ> <xmx:m3GmXt5WCL754b8hjTlBjna9A30KeAy64w6UdfY_Q_s2ISWc-drE6w> <xmx:m3GmXidQuburA9jxwV70xc_FBAG5vpmMOyDCrJZDu06GUxaXct1vsQ> <xmx:nHGmXgurUtKED8xC6sKIaZpr0cQY4XYZhsLmhhlbvuI1ukmBFTd5Qw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A72A26680073; Mon, 27 Apr 2020 01:46:03 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <b79a4641-bade-4901-b3f0-bb7decbdb41e@www.fastmail.com>
In-Reply-To: <CF2EE8CE-DB07-4AFF-84D0-B80BA5E76D39@antoin.nl>
References: <CF2EE8CE-DB07-4AFF-84D0-B80BA5E76D39@antoin.nl>
Date: Mon, 27 Apr 2020 00:45:42 -0500
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/OpV0eBYLSkPSG_3TyrSUacvcoIY>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response
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: Mon, 27 Apr 2020 05:46:08 -0000


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:
> 
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
> 
> 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.
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 would have been nice to provide a template for "brief", at least a SHOULD,
per objects described in the RDAP RFCs.

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

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.

PS: the argument in A.1 about the complexity arising out of jCard can "soon"
become obsolete if draft-loffredo-regext-rdap-jcard-deprecation goes through,
so maybe some text should have addressed other non jCard cases (or explaining why
even if jCard is dropped then problems remain)

-- 
  Patrick Mevzek
  pm@dotandco.com