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.
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
