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

[Mario Loffredo <[e-mail]>]

Hi Tom,

thanks a lot for your feedback. Please find my comments below.

Il 05/08/2019 02:28, Tom Harrison ha scritto:
> Hi Mario,
>
> On Wed, Jul 24, 2019 at 05:32:21PM +0200, Mario Loffredo wrote:
>> Il 24/07/2019 16:28, Tom Harrison ha scritto:
>>>    - 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.
> What I mean is that the reverse search document has this concept of a
> mapping from an external model (EPP) to an internal model (jCard),
> whereas the sorting and paging document uses jCard directly as part of
> its public interface and is very explicit as to where certain values
> will appear.  The example I gave in the original email wasn't good: a
> better example is one where the server does publish the country code,
> but in a non-standard location (e.g. the "ISO-3166-1-alpha-2"
> parameter that some servers use).  This inconsistency could be
> confusing for users: with such a server, a reverse search by country
> code would work, but an attempt to sort by country code would fail
> with an error message.  I think dropping the mapping from the reverse
> search document is the simplest way to address this consistency issue,
> since it seems that the only reason to have the mapping is to deal
> with divergent approaches to country codes that came up pre-RFC 8605,
> but now that that document exists servers should be updated to be
> compliant with it.

The server is free to map the "cc" sorting property (as well as any 
other) onto any field provided in the response. The jsonPath property 
should be helpful in that sense.

If the server will map the "cc" sorting property onto a non-standard 
location, the server will sort the results according to the value of 
that location.

In the case of your example, the jsonPath value will be 
"$.entitySearchResults[*].vcardArray[1][?(@[0]="ISO-3166-1-alpha-2")][3]"

Maybe, I need to clarifiy better this concept in the sorting-and-paging 
draft.

The only error the client can obtain is when it requests for an 
unsupported sorting property which means that either it doesn't appear 
in the sorting_metadata field and it doesn't correspond to the current sort.

The search model defined in the reverse-search draft follows the same 
concept. The basic idea is letting the RDAP provider to map a field of 
the reverse search pattern to whatever it sees fit in order to avoid the 
lost of relevant results.

The following is a clarifying example.

The RDAP response doesn't contain the "cc" parameter as described in 
RFC8605 but only the country name as defined in RFC6350. The server will 
allow the reverse search based on "cc" because it will be able to 
trasform the country code into the country name and will allow to sort 
on the "country" property as defined in the sorting-and-paging draft.

No relevant results will be lost and no sorting error will be possible.

>> 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.
> I think it would be better to limit reverse search to single
> attributes and leave AND-joined predicates for later.
ok. Let's wait a while for other possible opinions.
>
>>>    - 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.
> But IP addresses are represented as JSON strings, so this won't work
> for them.  It may be that IP addresses would be the only exception to
> a prospective 'JSON strings are sorted lexicographically, JSON numbers
> are sorted numerically' rule, but it still seems like something worth
> documenting.

I agree with you that treating ips as numbers instead of strings would 
result in a much more efficient sorting policy but, honestly, I have 
never explored this possibility by using the traditional DBMS operators 
so I can't evaluate the effort required to implement it. I know there 
are some experiences available on the web but I would like to make some 
tests and then give you my opinion as soon as possible.

Best,

mario

>
> -Tom

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