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

[Tom Harrison <[e-mail]>]

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.

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

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

-Tom