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