Re: [regext] New version of rdap-reverse-search

[Mario Loffredo <[e-mail]>]

Hi Tom,

please find my comments below.

Il 30/01/2023 01:58, Tom Harrison ha scritto:
> On Mon, Dec 19, 2022 at 03:27:17PM +0100, Antoin Verschuren wrote:
>> Hi all, can all people that commented on
>> draft-ietf-regext-rdap-reverse-search since the start of the
>> previous last call (Tom, Pawel, Jasdip) confirm that all their
>> issues are now addressed in version 17, so that the document
>> shepherd can confirm there are no new changes to be expected during
>> WGLC?
>>
>> Once we have confirmation, we will issue a 3th WGLC when the
>> document is stable.
> Sorry about the delay here.  After discussion with Mario, I have a
> general concern with how this document is structured, which can be
> solved in a couple of different ways.
>
> Each search property in the document uses a name that is the same as
> the name of the object member that is the subject of the search (e.g.
> "fn").  Also, some parts of the document imply that a specific object
> member will be used when evaluating the search results.  For example,
> section 2 has:
>
>      *  search-condition: a sequence of "property=search pattern"
>         predicates separated by the ampersand character ('&', US-ASCII
>         value 0x0026).  Each "property" represents a JSON object
>         property of the RDAP object class corresponding to
>         "related-resource-type".
>
> and section 4 has (among others):
>
>      Reverse search property: fn
>      RDAP property path: $..entities[*].vcardArray[1][?(@[0]=='fn')][3]
>      Reference:  Section 6.2.1 of [RFC6350]
>
> But other parts of the document note that the object member used for
> evaluating the predicate for a given reverse search name may change
> over time.  For example, also in section 4:
>
>      Documents that deprecate or restructure RDAP responses such that
>      one or more of the properties listed above becomes invalid MUST
>      either note that the relevant reverse search is no longer
>      available (in the case of deprecation) or describe how to continue
>      supporting the relevant search by way of some new RDAP property
>      (in the case of restructuring).
>
> Similarly, the new IANA registry does not include an RDAP property
> path, and the description of the property there is abstract as well
> (e.g. "the server supports the domain/nameserver/entity search based
> on the full name (a.k.a formatted name) of an associated entity").
>
> One way to address this is to have a clear 1:1 mapping between search
> property names and object members.  This makes the behaviour
> unambiguous and stable: in particular, a client carrying out an "fn"
> search will always get back an object containing an "fn" member,
> whereas if the behaviour of an "fn" search changes over time, that may
> not necessarily be the case (e.g. once a server has fully transitioned
> to using JSContact instead of jCard).  However, it does mean that new
> fields will require new search properties, even when they contain the
> same data as an existing field (as is the case with "fn" and JSContact
> "fullName").
>
> Another way to deal with this is to make the search properties more
> abstract.  This is the route taken by e.g. the redacted document,
> where member names are explicitly logical names (e.g. "Registrant
> Name"), and there are no guarantees about the object properties that
> exist or that will be returned.
>
> I think the second option is the way to go here, but will wait on
> input from the list before making any suggestions as to text.

I agree with you on the second option. In addition to your 
considerations, would like to point out that most of the query parameter 
names  described in RFC 9082 logically refer to more than one response 
property such as the domain/nameserver name that is related to either 
ldhName  or unicodeName, and the ip address that can correspond to 
either v4 or v6 addresses.

Definitively, up to now we have used query parameter names that aren't 
1:1 mapped to the response fields.

With regard to the "fn" reverse search property, have nothing to object 
to rename it to further clarify the above concept.

Best,

Mario

> -Tom
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web: http://www.iit.cnr.it/mario.loffredo