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

Hi Tom,

Il 25/04/2022 00:55, Tom Harrison ha scritto:
> 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.

[ML] According to the response extension example in RFC9083 (see 
"lunarNIC"), the prefix does not include the version info (in that case 
"_level_0").

Therefore, it seems better to call the metadata field 
"reverse_search_properties".

The same rule has been followed for the "redcated" extension.

>
> 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.)

[ML] No rule has been defined so far to tie the new path segments 
eventually defined to the rdapConformance tags so I'll keep the two 
reverse search endpoints as in the following:

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

{searchable-resource-type}/reverse/{related-resource-type}/metadata

Best,

Mario

>
> -Tom
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. 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