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
regext@ietf.org
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: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
