Subject: Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-01.txt

From: Tom Harrison <[email-masked]>
Date: Wed, 24 Jul 2019 14:29:16 +0000

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

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

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 24 Jul 2019 22:56:02 +0200

Hi Tom,

thank you for the feedbacks. My comments are below.

Best,

mario

Il 24/07/2019 16:29, Tom Harrison ha scritto:
>     (fn/email/adr).
Neither RFC7482 does, at least with regards to the fn property.
> I think the only sensible option here is to

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.
>     other values that can be searched for via the entityAddr

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-masked]
> 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-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo