Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-sorting-and-paging

Mario Loffredo <mario.loffredo@iit.cnr.it> Mon, 02 March 2020 12:32 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
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 A9AFD3A0A38 for <regext@ietfa.amsl.com>; Mon, 2 Mar 2020 04:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwFwpEA8ejMz for <regext@ietfa.amsl.com>; Mon, 2 Mar 2020 04:32:52 -0800 (PST)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78FC3A0A2F for <regext@ietf.org>; Mon, 2 Mar 2020 04:32:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 5F2F1B802B7; Mon, 2 Mar 2020 13:32:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THhgqf1eh6zQ; Mon, 2 Mar 2020 13:32:46 +0100 (CET)
Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id A27E6B802B4; Mon, 2 Mar 2020 13:32:46 +0100 (CET)
To: Tom Harrison <tomh@apnic.net>
Cc: regext <regext@ietf.org>
References: <CF97D334-4E2B-4411-AA68-A92F42A70732@antoin.nl> <20200301234929.GG5595@tomh-laptop>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <12131388-d7dc-a953-8aa1-3381b6134ac4@iit.cnr.it>
Date: Mon, 2 Mar 2020 13:30:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
MIME-Version: 1.0
In-Reply-To: <20200301234929.GG5595@tomh-laptop>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/sKDFlnA11hdDOLHi4o_F60depAw>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-sorting-and-paging
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, 02 Mar 2020 12:32:55 -0000

Hi Tom,

thanks a lot for your further review.

My responses are included below.

Il 02/03/2020 00:49, Tom Harrison ha scritto:
> Hi Mario,
>
> On Fri, Feb 28, 2020 at 03:43:39PM +0100, 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-sorting-and-paging/
>>
>> This WG last call will end at close of business, Friday, 13 March
>> 2020.
>>
>> Please review this document and indicate your support (a simple “+1”
>> is sufficient) or concerns with the publication of this document by
>> replying to this message on the list.
> Some questions/comments on section 2.4.2 ("Paging Responses to POST
> Requests"):
>
>   - 'Therefore, an RDAP response element which is meant to represent
>     the pagination information should also consider the POST method':
>     does this mean that even for requests submitted using the GET
>     method, server implementers may respond with the "cursors" element
>     in the "paging_metadata" section?
>
>   - 'As a consequence, the "paging_metadata" element MUST include an
>     additional property, alternate to "links", that contains the cursor
>     values used for pagination': does this mean that the response MUST
>     include either "links" or "cursors", but not both?

I think the two points above are related.

The basic concept is that "links" must be provided when GET is used 
while "cursors" must be provided when POST is used instead and both 
"links" and "cursors" must not be included in the response.

I will rearrange the sentence to clarify it.

>
>   - The "cursors" element provides a POST parameter, but it does not
>     specify the URL to use for the request.  What URL should the client
>     use?  (It may also be worth documenting explicitly how the cursor
>     parameter is used when constructing that request.)
My opinion is that the endpoint a client should use for POST requests is 
out of the scope of this document.

It may be either one of the those supporting the GET method or a 
different one.

Similarly, since the cursor parameter as well as other POST parameters 
must be delivered by the client in the request body, we don't need to 
know the structure of the request body.

A client may put one of the values included in the "cursors" map in the 
body of a subsequent request in order to navigate the result set.

>
>   - 'The map keys MUST contain the "rel" values used for generating the
>     paging links (Figure 7)': a reference to RFC 8288 may be needed
>     here.
Agreed.
>
> Some other minor issues, in section 2.3.1:
>
>   - Each of the JSON paths for the events is like
>     'events[?(@.eventAction=="{name}")].eventDate'.  If there are
>     multiple events with a given action, this will map to multiple
>     event date values.  As with the nameserver IPv4/IPv6 parts, it
>     looks like an '[0]' at the end will fix this.
OK.
>
>   - The JSON path for the lastChanged sorting property is given as
>     '$.domainSearchResults[*].events[?(@.eventAction=="lastChanged")].eventDate',
>     but the eventAction value is actually "last changed", rather than
>     "lastChanged".
OK.
>
>   - None of the JSON paths take account of jCard 'pref' values (it
>     doesn't look like there's a way for this to be handled using a JSON
>     path).  Adding some text about this may help to avoid confusion for
>     people who just use the JSON paths as-is.

Agreed. I will include an example of JSON path considering the pref 
parameter.


Please let me know if all the responses sound good for you so I can go 
ahead and post the new version.

Best,

Mario

>
> -Tom
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
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
Web: http://www.iit.cnr.it/mario.loffredo