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?
- 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.)
- '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.
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.
- 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".
- 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.
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
