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