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

From: Tom Harrison <[email-masked]>
Date: Sun, 1 Mar 2020 23:49:35 +0000

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

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 2 Mar 2020 13:30:41 +0100

Hi Tom,

thanks a lot for your further review.

My responses are included below.

>     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.

>     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.

>     paging links (Figure 7)': a reference to RFC 8288 may be needed
Agreed.
>     looks like an '[0]' at the end will fix this.
OK.
>     but the eventAction value is actually "last changed", rather than
OK.
>     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
> [email-masked]
> 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

---

From: Tom Harrison <[email-masked]>
Date: Tue, 3 Mar 2020 04:37:57 +0000

Hi Mario,

> I will rearrange the sentence to clarify it.

If it's not open to a server that receives a GET request to return the
'cursors' element, and no POST search requests are defined in any
current RDAP documents, then I think it would be better to omit
section 2.4.2 from the document.  This is mainly because the lack of
any current POST search requests makes it difficult to evaluate the
approach.  If a later document defines a POST search request, then the
appropriate sorting/paging changes could be defined there.  Having
said that, if this section is retained, your suggested changes sound
good.

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

Putting aside the issue of whether to omit section 2.4.2, all of the
responses sound good to me, thanks.

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 4 Mar 2020 11:23:28 +0100

Hi Tom,

sorry for the slow reply but I needed to furtherly investigate about 
JSONPath features.

My responses to your comments are below.

> said that, if this section is retained, your suggested changes sound

I added that section because, in my opinion, the specification would 
have been more comprehensive.

However, I admit that it is probably too early if compared to both the 
capabilities described in RFC7482 and current RDAP implementation 
experiences.

That said, I will remove that section unless someone disagrees.

> responses sound good to me, thanks.

With regards to the specification of JSON Paths for the events, I found 
out that picking the Nth element of a filtered JSON Path is still an 
open issue.

See for example here: https://github.com/json-path/JsonPath/issues/272 
and https://github.com/json-path/JsonPath/issues/375

In addition, I think it makes more sense to talk about the 
earliest/latest event rather than the first one. If we take into account 
the first event, we are implicitly thinking about a pre-ordered list of 
events.

To fix this issue, I report here in the following the possible solutions:

1) Leaving Table 2 as-is

Even if some events might potentially  appear more than once, we can 
imagine that in most of cases only the latest will be included in the 
response. See for example trDate information in RFC5731 and RFC5733.

Anyway, to disambiguate the case of multiple events of the same action, 
I could add the following text:

".. Multiple events with a given action on an object might be returned. 
When it occurs, sorting MUST be applied to the latest event.."

2) Removing the sorting properties related to the events which, in 
theory, might appear more than once.

According to RFC7483, the "registration", "last changed" and 
"expiration" events can't be multiple and, at the same time, are most 
likely to be returned in RDAP responses and, consequently, more likely 
to be considered for result set sorting.  Therefore, only  
"registrationDate", "lastChangedDate" and "expirationDate" should be 
included among the sorting properties derived from RDAP events.

3) Any other?

I look forward for WG comments.

Personally, I have no preference.

Mario

Web:http://www.iit.cnr.it/mario.loffredo