Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-sorting-and-paging-07.txt

[Mario Loffredo <[e-mail]>]

Hi Karl Heinz,

thanks a lot for your review and feedback. My comments are inline.

Il 22/01/2020 09:30, Karl Heinz Wolf ha scritto:
>
> Mario,
>
> here is my feedback on this draft:
>
> general comment:
>
> I think it would be easier to understand the document if the actual 
> specification and the reasoning would switch places (or even go into a 
> kind of appendix).
>
ML: OK.
>
> Section 1:
>
> Just as a side note: you talk about users interacting with a web 
> browser, but I’m afraid by adding this extension to the RDAP response 
> it is also not easy to read in the browser…
>
ML: I guess you mean "paging" when you say "this extension".

It is undoubtful that putting the links for result set scrolling into 
the HTTP header rather than into the query string means that they can't 
be specified in a GET request, unless using a REST plugin, and can't be 
included among the links of an RDAP response. Therefore, according to 
the first solution described, a user interacting through a web browser 
would be unable to use the paging capability.

With regards to "pageSize" and "pageNumber" infomation, they avoid such 
a user to feel disoriented in the result set. Especially together with 
the "totalCount" information, they achieve the same goal as a progress 
bar for a process taking some steps.

> Section 2.1:
>
> Where it says “SHOULD provide additional information in their 
> responses” you could probably add which responses in particular.
>
ML: I have a different opinion from you about this sentence. Let's wait 
for other reviews to decide whether it is clear enough or not.

The basic concept is that the additional information in the response 
should contribute to make an RDAP server more self-descriptive. I mean, 
a server could allow to specify a sorting crterion in its requests 
without providing the "sorting_metadata" information in its responses 
but, in this case, the consumer must know a priori that a sorting 
capability is available and which sorting properties are implemented. 
The same goes for "paging_metadata". In this case, the consumer doesn't 
need to know anything in advance.  Anyway, the "paging_metadata" element 
conveys more information and is more traceable by a client (i.e. a 
software agent) than a mere link in a notice.

> Not sure if “At least one between” is the right term (2 occurrences).
>
ML: Removed the sentence because it is redundant.
>
> For “totalCount” “It is provided if the query string contains the 
> "count" parameter;” suggestion: “It MUST be provided if the query 
> string contains the "count" parameter with a value of true”
>
ML: OK
>
> Section 2.3.1: sorting of multiple IP addresses is underspecified.
>
ML: the sorting properties "ipV4" and "ipV6" cover the case related to 
the most common DNS configuration (i.e. one IPV4 and one IPV6 
addresses). The case of multiple IPV4 and IPV6 addresses can be treated 
in the same way as the sorting properties for entity objects, I mean,  
sorting MUST be applied to the first value returned in the response. 
Anyway, I'll furtherly clarify this concept in the next version.
>
> What is not clear to me is if the client is allowed to send a limit in 
> its initial request (not knowing if the server even supports 
> limit/offset)? Or is it intended that the client does not send any 
> preferences on the first request and the response is done based on 
> server policy and metadata is added?
>
ML: The latter. The user cannot select a result set portion in its 
initial request. The cursor value is an opaque string whose meaning is 
completely unknown to the consumer. It's only a link to another portion 
of the result set (e.g. the next one). Usually, the consumer doesn't 
know in advance the page size that might even be different according to 
the user access level. Therefore, the consumer might request a number of 
results exceeding the server limit which basically means more complexity 
to deal with by server implementers.

If the consumer wishes the first N results, two things can happen when 
cursor pagination is implemented:

1) if N is greater than the page size, the consumer will simply receive 
more results than required.

2) if N is lower than the page size, the consumer will scroll the result 
set until the desired number of results is reached.

In both cases, each request is correct and each response is sustainable 
by the server.

Offset is generally used together with limit to traverse a result set. 
It makes little sense to specify an offset value at the initial request. 
The cursor pagination achieves the same goal as offset/limit pagination 
with the only difference that the page size is set by the server. 
Anyway, since the cursor is an opaque string, the server is free to 
implement pagination based either on key values or on record position.

> Anyway, having sorting and paging for RADP is certainly a good idea.
>
Happy you agree about it :-)

Feel free to contact me for any additional Information.


Cheers,

Mario

> Best,
>
> Karl Heinz
>
>
> On Fri, Dec 20, 2019 at 12:30 PM Mario Loffredo 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi folks,
>
>     I just published a new version including a section about paging
>     responses to POST requests.
>
>
>     Best,
>
>     mario
>
>
>
>     -------- Messaggio Inoltrato --------
>     Oggetto: 	New Version Notification for
>     draft-ietf-regext-rdap-sorting-and-paging-07.txt
>     Data: 	Fri, 20 Dec 2019 03:26:47 -0800
>     Mittente: 	[e-mail] <mailto:[e-mail]>
>     A: 	Maurizio Martinelli <[e-mail]>
>     <mailto:[e-mail]>, Scott Hollenbeck
>     <[e-mail]> <mailto:[e-mail]>,
>     Mario Loffredo <[e-mail]>
>     <mailto:[e-mail]>
>
>
>
>
>     A new version of I-D, draft-ietf-regext-rdap-sorting-and-paging-07.txt
>     has been successfully submitted by Mario Loffredo and posted to the
>     IETF repository.
>
>     Name: draft-ietf-regext-rdap-sorting-and-paging
>     Revision: 07
>     Title: Registration Data Access Protocol (RDAP) Query Parameters
>     for Result Sorting and Paging
>     Document date: 2019-12-20
>     Group: regext
>     Pages: 25
>     URL:
>     https://www.ietf.org/internet-drafts/draft-ietf-regext-rdap-sorting-and-paging-07.txt
>     Status:
>     https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
>     Htmlized:
>     https://tools.ietf.org/html/draft-ietf-regext-rdap-sorting-and-paging-07
>     Htmlized:
>     https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-sorting-and-paging
>     Diff:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-sorting-and-paging-07
>
>     Abstract:
>     The Registration Data Access Protocol (RDAP) does not include core
>     functionality for clients to provide sorting and paging parameters
>     for control of large result sets. This omission can lead to
>     unpredictable server processing of queries and client processing of
>     responses. This unpredictability can be greatly reduced if clients
>     can provide servers with their preferences for managing large
>     responses. This document describes RDAP query extensions that allow
>     clients to specify their preferences for sorting and paging result
>     sets.
>
>
>
>     Please note that it may take a couple of minutes from the time of
>     submission
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>     _______________________________________________
>     regext mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/regext
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [e-mail]
Phone: [phone]
Mobile: [phone]
Web: http://www.iit.cnr.it/mario.loffredo