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

Mario Loffredo <> Mon, 27 April 2020 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F76E3A10BD for <>; Mon, 27 Apr 2020 09:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VCgJRRQRAMG1 for <>; Mon, 27 Apr 2020 09:48:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 281483A1122 for <>; Mon, 27 Apr 2020 09:48:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FAA7B80504; Mon, 27 Apr 2020 18:48:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OX31T5K6LG87; Mon, 27 Apr 2020 18:48:35 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A1A3DB804A1; Mon, 27 Apr 2020 18:48:35 +0200 (CEST)
To: Patrick Mevzek <>,
References: <> <> <>
From: Mario Loffredo <>
Message-ID: <>
Date: Mon, 27 Apr 2020 18:46:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: it
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 16:48:53 -0000

Hi Patrick,

Il 27/04/2020 08:04, Patrick Mevzek ha scritto:
> Also:
> couldn't each fieldset have a list of jsonPath elements (similar to what is done in
> draft-ietf-regext-rdap-sorting-and-paging)
> to properly list the fields concerned?
I dropped this solution because it seemed to me conceptually valid but 
very inefficient.
> TBH, I am not sure to understand:
> - why there are multiple links elements (the example given shows only one, what would be other ones?)
The figure is uncorrect. I missed to fix this issue in the last version. 
There are multiple field sets but each field set includes a single link 
because each field set is an alternative view of the results provided 
according to the current field set.
> - 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. "

The use of both the "value" and the "href" JSON values is compliant to 
what is shown in RFC7483. The context is the URI of the current view of 
a resource (i.e. the collection of objects returned according to the 
current fiel set) while the target is the URI of an alternative view of 
the same resource (i.e. the collection of objects provided according 
another field set).

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

I think that we need to agree about the meaning of "context" in RDAP. It 
seems to me that in RDAP the context is the JSON content provided as the 
result to the current query.

I wait for additional comments by the WG.



> 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
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240