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

From: Tom Harrison <[email-masked]>
Date: Wed, 24 Jul 2019 14:28:51 +0000

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

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

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

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

 - 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 / "/" / "=" / "-" / "_" )

 - 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"?

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 24 Jul 2019 17:32:21 +0200

Hi Tom,

thank you for the feedbacks. My comments are below.

Best,

mario

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

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

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

>     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.
>      "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
Right. It is a typo.
>     just by any field because the sorting criterion must contain a

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
> [email-masked]
> 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: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo