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
regext@ietf.org
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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
