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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
