Mario, all,
i'm currently implementing a prototype RDAP server that uses sorting and
paging features. I've gotten so far to implement the basic parameters
(cursor in the limit/offset variant, and sort), and now i'm trying to
implement the "paging_metadata" elements. I have a few comments on that
(you know, some of theses things, you only notice once you start with an
implementation, so - sorry for being late to the game).
Ok, here we go:
The "paging_metadata" element contains the following fields:
o "totalCount": "Numeric" (OPTIONAL) a numeric value representing
the total number of objects found. It MUST be provided if and
only if the query string contains the "count" parameter;
I don't understand why a server is disallowed to include the
totalCount unless the client has requested it. I'd change that to
"MUST be provided if the query string contains the 'count' parameter,
but MAY be provided in other cases", unless there's good reasons for
disallowing it!
o "pageSize": "Numeric" (OPTIONAL) a numeric value representing the
number of objects that should have been returned in the current
page. It MUST be provided if and only if the total number of
objects exceeds the page size. This property is redundant for
RDAP clients because the page size can be derived from the length
of the search results array but, it can be helpful if the end user
interacts with the server through a web browser;
I find that one useless for the limit/offset case. I understand it
might be useful for the keyset variant, but it took me a long time
understanding that. For the limit/offset case, it can only be exactly
the given "limit" parameter anyway, as it must not be provided when
the total number of results is less than the page size. I won't
implement it in my case.
o "pageNumber": "Numeric" (OPTIONAL) a numeric value representing
the number of the current page in the result set. It MUST be
provided if and only if the total number of objects found exceeds
the page size;
I won't implement that one either, as there's no way calculating the number
of pages in the limit/offset case (since the client can always change the
"limit"). Also, it *would* be possible for the client to calculate that by
itself, *if* you'd allow the server to return the total number of items in
cases where the client didn't request it (see above).
o "links": "Link[]" (OPTIONAL) an array of links as described in
[RFC8288 <https://tools.ietf.org/html/rfc8288>] containing the
reference to the next page. In this
specification, only forward pagination is described because it is
all that is necessary to traverse the result set.
Why is only forward pagination described here? Is that because of the
"keyset" case? And does that mean that we MUST NOT encode a reference
to the previous page in those links? I'd like to see a more normative
language here, in the light of interopability.
I'd recommend to allow inclusion of at least "next" and "previous"
page (and, as i have just discovered, you are actually listing
"first", "last" and "prev" in section 2.4.1 as what a server MAY
implement..
Plus i'd like to see a more specific reference than just whole RFC
8288... It's quite a bit to read - i did the "RFC noob" thing of going
to the examples to understand it..
So far for the paging metadata.... I might find more as i work through the
rest of the specs.
best,
Alex
On Mon, Nov 30, 2020 at 9:45 AM Mario Loffredo <mario.loffr...@iit.cnr.it>
wrote:
> Hi all,
>
> Just to make the document more comprehensive, I added a final paragraph to
> Appendix A to reference the comparison between JSONPath operators and
> IETF JSONPath WG web site.
>
> Best,
>
> Mario
>
>
> -------- Messaggio Inoltrato --------
> Oggetto: New Version Notification for
> draft-ietf-regext-rdap-sorting-and-paging-20.txt
> Data: Mon, 30 Nov 2020 00:40:41 -0800
> Mittente: internet-dra...@ietf.org
> A: Maurizio Martinelli <maurizio.martine...@iit.cnr.it>
> <maurizio.martine...@iit.cnr.it>, Mario Loffredo
> <mario.loffr...@iit.cnr.it> <mario.loffr...@iit.cnr.it>, Scott Hollenbeck
> <shollenb...@verisign.com> <shollenb...@verisign.com>
>
>
> A new version of I-D, draft-ietf-regext-rdap-sorting-and-paging-20.txt
> has been successfully submitted by Mario Loffredo and posted to the
> IETF repository.
>
> Name: draft-ietf-regext-rdap-sorting-and-paging
> Revision: 20
> Title: Registration Data Access Protocol (RDAP) Query Parameters for
> Result Sorting and Paging
> Document date: 2020-11-30
> Group: regext
> Pages: 31
> URL:
> https://www.ietf.org/archive/id/draft-ietf-regext-rdap-sorting-and-paging-20.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-sorting-and-paging
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-regext-rdap-sorting-and-paging-20
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-sorting-and-paging-20
>
> 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.
>
> The IETF Secretariat
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
