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