Re: [regext] Fwd: I-D Action: draft-ietf-regext-rdap-sorting-and-paging-03.txt

[Mario Loffredo <[e-mail]>]

Hi Tom,

thank you for the feedbacks. My comments are below.

Best,

mario

Il 24/07/2019 16:28, Tom Harrison ha scritto:
> Hi Mario,
>
> On Wed, Jun 12, 2019 at 12:20:40PM +0200, Mario Loffredo wrote:
>> in this new version "cc" has been added to the list of sorting properties
>> and RFC8605 has been added to the Normative References.
> Thanks for putting this together.  Some comments/feedback:
>
>   - Is there a need to be prescriptive about the 'cursor' parameter?
>     The draft could simply have text along the lines of "a server that
>     implements paging will include at least a 'next' link for fetching
>     the next page, and optionally 'first'/'prev'/'last' links for
>     accessing other pages in the set of search results".  That way, a
>     server can use whatever suits it best, whether that be limit/offset
>     parameters or a more generic cursor parameter (or something else).
Yes, it's true and it is the reason why the cursor value has been 
modelled as an opaque string. A server can implement pagination as it 
sees fit.

However, offset and keyset are currently the most popular pagination 
methods. In addition, as I have outlined in the "Implementation 
Consideration" section, they don't require the server to handle the 
result set in a storage area across the requests . For such reasons, the 
draft mentions them as probable backend methods.

I will furtherly clarify the concept that the implementation of the 
cursor parameter is not limited to the use of those methods.

>   - This draft takes a different approach to country/cc values than
>     that taken by the reverse search draft.  Why are these values
>     treated separately here?  Should servers that don't currently use the
>     'cc' parameter, but which do have country name values in their
>     jCards, be prevented from sorting based on the country name if a
>     client requests that sorting be done by cc?

It's not clear to me what you mean when you say the two approaches are 
different. In the reverse search poposal, "cc" is an an address property 
and can be used individually or together with another address property 
to submit a reverse query based on an address rather then on a single 
property each time. I'm not sure this is the right approach. I mean, is 
it better to allow a reverse search based on the entire address or on 
one of its properties and leave AND joined predicates to a future 
capability? This is a question I'm going to make to the WG tomorrow.

In the sorting-and-paging draft, "cc" can be a sorting property like 
some other properties. It can be used joined with other sorting 
properties to compose a complex sort criterion.

I think it isn't a good idea to let a server to sort the results based 
on the country name when the client requests for a sort based on cc. In 
the "Negative Answer" section it is stated that the server SHOULD return 
an error in that case.

>   - I think it would be useful to document explicitly what happens when
>     sorting is carried out on a field for which a record can have
>     multiple values.  For example, with jCard properties, the draft
>     currently has text about using the value that is most preferred
>     (per the 'pref' parameter), but there could be instances of
>     multiple values for a property where no 'pref' parameter has been
>     set.  This may be as simple as saying "the server will sort based
>     on the first value for a given field that appears in the object".

I agree. I have already planned to update the draft in that sense. I was 
waiting for more feedbacks coming from tomorrow's meeting. In fact, I'm 
going to talk about the SORT-AS parameter as well.

If the server returns more values for a field and the pref parameter is 
missing, the first value must be taken by the server as the basis to 
sort the results.

>   - Along similar lines, I think it would be useful to go into more
>     detail about the exact logic for sorting.  For example, clients
>     will typically want IP addresses to be sorted based on their
>     numeric value, rather than on their string value, but the current
>     text isn't prescriptive about this.
Good quaestion. I think the sort ordering should be consistent with the 
field JSON type. If the field is a JSON string, the lexicographic 
ordering should go. If the field is a JSON number, the numeric ordering 
should go.
>   - The ABNF for 'cursor' is:
>
>      "cursor=" ( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
>
>     which appears to limit it to a single character.  It looks like it
>     should instead be:
>
>      "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
Right. It is a typo.
>   - I don't understand the text in section 2.4 about the problems with
>     cursor pagination.  What is a "key field" in "it needs at least one
>     key field"?  Also, what is a "key" in "it does not allow to sort
>     just by any field because the sorting criterion must contain a
>     key"?

In that sentence, "cursor" means "keyset". To avoid ambiguities, I will 
change the term "cursor" with the term "keyset". Keyset pagination needs 
a key field to work properly.

>
> -Tom
>
> _______________________________________________
> regext mailing list
> [e-mail]
> 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: [e-mail]
Phone: [phone]
Web: http://www.iit.cnr.it/mario.loffredo