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

[Tom Harrison <[e-mail]>]

Hi Mario,

On Mon, Nov 21, 2022 at 04:40:28PM +0100, Mario Loffredo wrote:
> With regard to the registration of the reverse search properties, I
> have opted for adding entries in the RDAP JSON Values registry
> rather than defining an ad-hoc registry.
> 
> That is because servers must include the reverse search properties
> they support in a specific RDAP help response extension.
> 
> Therefore, some JSON values related to the pre-defined properties
> must be included in that registry anyway.

I don't follow this part.  The document as it stands requires that the
supported reverse search properties be included in the
reverse_search_properties member of the help response, but that of
itself doesn't mean those properties need to be registered in the
"RDAP JSON Values" registry.  More relevantly, relying on the "RDAP
JSON Values" registry in this way means that a given field name can be
used for only one reverse search, because the only data in the
registry entry aside from the type is the field name.  I think it
would make more sense to define a separate registry for the reverse
search properties, including the additional fields from the metadata,
and potentially the JSONPath to the field value as well (though
omitting the JSONPath may ease the transition from one underlying data
format to another, such as with jCard and JSContact).

Separately, given that the bar for registering extensions is so low
(turnaround is 1-2 weeks, IME), it doesn't seem as though
"custom"-type reverse search properties are worth the additional
complexity.  Omitting these would also avoid the risk of different
servers implementing support for the same search in inconsistent ways,
which may be an issue when transitioning to JSContact, for example.

-Tom