Hi Tom,
sorry for the slow reply but I needed to furtherly investigate about
JSONPath features.
My responses to your comments are below.
Il 03/03/2020 05:37, Tom Harrison ha scritto:
Hi Mario,
On Mon, Mar 02, 2020 at 01:30:41PM +0100, Mario Loffredo wrote:
Il 02/03/2020 00:49, Tom Harrison ha scritto:
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?
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.
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.
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.
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.
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
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
