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

Patrick Mevzek <> Mon, 27 April 2020 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D6183A0C75 for <>; Sun, 26 Apr 2020 23:04:44 -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=R5M1JovV; dkim=pass (2048-bit key) header.b=TGewl1Ir
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PN3Lhx7aCg7V for <>; Sun, 26 Apr 2020 23:04:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 927D03A0D07 for <>; Sun, 26 Apr 2020 23:04:42 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id CB4EA640 for <>; Mon, 27 Apr 2020 02:04:41 -0400 (EDT)
Received: from imap22 ([]) by compute3.internal (MEProxy); Mon, 27 Apr 2020 02:04:41 -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=Me+j/FOdmhUw6zQoAzWL3vLDUzt4FiF XMsxkbopbhyY=; b=R5M1JovVhUeiU352BXjuUwv4efyjCSItrPa0rgYAlzIvFVh wKbqf11fBvkuMsY/R1bjzKtqm1K5l5b6IWMItVLHBIcPN1Mz3rH02JwZ1K9KtDJ4 LidAJZzORROL8SOk56XvGSNUq2gtodjFlgU/uYLTpkLpyEHx0rtcp930yPBKvVpz /ryCKq0Bdnb8raeAlXwvDLSD+8L5H8px66+MzZJpfS2Oj4JlOfI2U1hq69rSMnvy Sa2yR54/4cKiFWp6rqk6TU7mDo+CVMGSiMFyUImUyxMrvoluC4coSenJCEK6Xg6T a160GWDY0C3d7Iv7EFiUTJmnWZOCtXtv2qk4w9A==
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=Me+j/F OdmhUw6zQoAzWL3vLDUzt4FiFXMsxkbopbhyY=; b=TGewl1Ir8uMIpOH0/ko/5S mEy7EnG1moGPphgJjm5UCgje/ltuEI1MtXcYW58LjaJYP9tDI6mdyWfolx+3h5ZX mY03AaMa/hmvgqNFfw4p9Mx18oS8fq0HHwht8nEUXkAFcr6aLKEUAsRhB4857VpB 1FsHUSM4htjCEzx6BtKUS1KZlyhMpYSy4601E26AbitP4VJmIrbyEbJYxRVg1wXx eIV+Hf50IV5VIkDzybY4seOkiOoKtLAPXZHu72iQAq2kf+u24Pw/GS1Q52iq48SZ E1ZP2cQ105b0n6PIw2xjxC1jp6lu44cM7fIr+i/RlEPOab7nEix7BDF4yAsQJCFw ==
X-ME-Sender: <xms:-XWmXkelr-wlYD9tHPOMCuYDBhTYZKSBYJ7NQd54DdwXDb7jFJsl3YtZIlA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggt ohdrtghomh
X-ME-Proxy: <xmx:-XWmXg42VcXi0lK_cmeKA7T6A8GkxegbBtqRKKtjPluYSl19UhAfWg> <xmx:-XWmXh_5QPo_Bb0dLwDxzv8S8OlW7LK785rgiQwvdMDoaA62MaDJtg> <xmx:-XWmXv--4CGXOv5iXuA_CE7mrvpcxpcVOROhfR7B1UkIsNqBW6O26g> <xmx:-XWmXlDwkwmF0pkBcxAdAEdOH3zSvbhr-JmRmmSI7M7BWz-Ul2Jsvw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id DBAA36680073; Mon, 27 Apr 2020 02:04:39 -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 01:04:12 -0500
From: Patrick Mevzek <>
Content-Type: text/plain
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 06:04:44 -0000

couldn't each fieldset have a list of jsonPath elements (similar to what is done in
to properly list the fields concerned?

TBH, I am not sure to understand:
- why there are multiple links elements (the example given shows only one, what would be other ones?)
- why value there is different from href (and hence why value is needed at all),
why is the current fieldSet the "context URI" of any other fieldset used for same query?

RFC8288 defines the context URI to be, for HTML serialization:
"The context of the
   link is the URI associated with the entire HTML document. "

There is no real explanation of the context for RDAP, but based on that maybe
it should be a link to the same query with fieldSet "full"?

On Mon, Apr 27, 2020, at 00:45, Patrick Mevzek wrote:
> 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.
> 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
> _______________________________________________
> regext mailing list

  Patrick Mevzek