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
<mario.loffr...@iit.cnr.it <mailto:mario..loffr...@iit.cnr.it>> 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: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
A: Maurizio Martinelli <maurizio.martine...@iit.cnr.it>
<mailto:maurizio.martine...@iit.cnr.it>, Scott Hollenbeck
<shollenb...@verisign.com> <mailto:shollenb...@verisign.com>,
Mario Loffredo <mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>
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
regext@ietf.org <mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
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: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
