Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

[Tom Harrison <[e-mail]>]

Hi Mario,

On Fri, Apr 22, 2022 at 03:37:56PM +0200, Mario Loffredo wrote:
> Il 22/04/2022 06:16, Tom Harrison ha scritto:
>> On Thu, Apr 21, 2022 at 04:51:15PM +0200, Mario Loffredo wrote:
>>> Il 18/04/2022 13:10, Tom Harrison ha scritto:
>>>>       - Define inline metadata, so that the relevant JSONPaths are
>>>>         available to the client, and can be changed to work for
>>>>         JSContact when a server switches to use JSContact (similarly to
>>>>         how things work with RFC 8977).
>>> 
>>> [ML] I have already proposed to extend the response with an inline metadata
>>> about the supported reverse search properties but I'm not sure when it
>>> should be returned.
>>> 
>>> The metadata described in both RFC8977 and RFC 8982 include information
>>> about server features that can be applied to every search response,
>>> including reverse search.
>>> 
>>> On the contrary, it wouldn't make sense to me to return the reverse search
>>> metadata in every search response.
>> 
>> To avoid any doubt, I'm not advocating for including metadata in this
>> document, but I think having a separate/standalone URL path for
>> retrieving the reverse search metadata would be a reasonable way to
>> handle this.
> 
> I have no objection to add in this document the following optional path
> 
> {searchable-resource-type}/reverse/{related-resource-type}/metadata
> 
> 
>      {
>        "rdapConformance": [
>          "reverse_search_0"
>        ],
>        "reverse_search_properties": [
>          {
>            "name": <reverse search property name>,
>            "rdapProperty": <RDAP property path>
>          }
>        ]
>      }
> 
> Do you agree?

The structure looks fine to me, but assuming that the
"reverse_search_properties" field name is prefixed with
"reverse_search" because of the "reverse_search_0" rdapConformance
value, then either the field name should be
"reverse_search_0_properties", or the rdapConformance value should
become "reverse_search", so that the field is prefixed with the entire
rdapConformance value.

(Semi-related: on looking at the relevant rdapConformance content in,
7480 has (section 8.1):

    The extension identifier is used as a prefix in JSON names and as
    a prefix of path segments in RDAP URLs.

which points towards the search URLs in this document becoming:

    {searchable-resource-type}/reverse_search_0/{related-resource-type}

though having said that, I can't find an example of a new path segment
being defined in an extension, so it's not 100% clear that it would be
required in this context (possibly it's only intended for the case
where a new object class is defined, for example).  This is just an
FYI, I don't have any concerns about the current document text in this
respect.)

-Tom