Hi Tom,
thank you for the feedbacks. My comments are below.
Best,
mario
Il 24/07/2019 16:29, Tom Harrison ha scritto:
Hi Mario,
On Thu, Apr 11, 2019 at 10:06:32AM +0200, Mario Loffredo wrote:
I have reviewed the "Privacy Considerations" section to outline even more
that reverse search must be provided only to authenticated and authorized
users legitimated by a legal basis.
I hope from now on the WG can focus on the technical aspects.
I look forward to further reviews.
Thanks for putting this together. Some comments/feedback:
- The draft does not explicitly state how matching works when an
entity has multiple values for a given jCard property
(fn/email/adr).
Neither RFC7482 does, at least with regards to the fn property.
I think the only sensible option here is to
consider the entity as a whole as matching if it has one or more
values that match the search criteria.
I agree. However, such option can lead to possible inconsistencies when
used in combination with sorting.
Let us suppose to have an emal property with two values: one matching
the search pattern and the other not matching but usable for sorting
(either labeled as preferred or corresponding to the first value
appearing in the array).
If the client requests the sort by email, the user could find the
related object in an unexpected position.
The alternative would be applying the same rule for sorting and matching
only one value but in this way some relevant results could never be
returned.
I guess that everybody in the WG would opt for the first solution so I
will update the draft in that sense.
- The draft does not define a mapping from EPP contact field (e.g.
street, city, etc.) to jCard address field. Although the value to
use is obvious in all cases apart from 'cc', I think defining the
mapping explicitly would be worthwhile.
- With 'cc', and putting aside RFC 8605, a standard jCard will not
contain this value, since the structured address must contain the
full name of the country. I think it would be worth noting that
standard jCards don't contain a 'cc' value, and it's up to server
implementations to handle the conversion from 'cc' value to full
country name.
- Related to the previous point: there is the 'cc' parameter (RFC
8605) that can be used to define the country code for an address.
Other ways of defining country codes that I've seen include using a
non-standard 'ISO-3166-1-alpha-2' parameter, and using the country
code in lieu of the full country name in the jCard. Another option
with 'cc' would be to document that different servers do different
things, and the precise way in which a 'cc' value search is carried
out is an implementation detail for the server (unlike each of the
other values that can be searched for via the entityAddr
parameter).
My opinon about the last three points is that it might be more
appropriate to describe a semantic equivalence rather than an explicit
mapping. On one side, as you have pointed out, the address information
is represented in RDAP in different ways, including the unstructured
format. On the other side, the EPP address model is well known, fixed,
structured and compact. Therefore, each value of such a model should be
matched by an information included in a RDAP result as an element value
or as a part of an element value.
I'll try to describe such equivalence in the next version.
-Tom
_______________________________________________
regext mailing list
[email protected]
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 protected]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
