Hi.
Very interesting discussion. :) Couple of inputs regarding the proposed
discovery and IANA registration of reverse search properties:
In the spirit of what-not-to-do, is it really necessary to evolve reverse
search this way? As long as each registered extension identifier (current and
future) for reverse search clearly defines in its spec the
searchable-resource-type/related-resource-type/search property combinations,
should that not suffice? Especially if keeping the RDAP client implementations
simpler is a foremost goal for us, and since such metadata would seemingly tax
RDAP clients (and servers) with more complex implementations. For the existing,
implemented search scenarios in RDAP (RFCs 9082 and 9083), we have managed to
avoid introducing such metadata so far. It would be good to be certain if the
proposed discovery and IANA registration of reverse search properties is truly
a need for the RDAP clients.
However, if we were to proceed with the reverse search metadata discovery, then
looks like a new IANA registry for this purpose would be better than
overloading the current RDAP JSON Values registry, given the proposed metadata
has a richer data structure than what the latter offers.
Thanks,
Jasdip
On 11/28/22, 5:36 PM, "regext on behalf of Tom Harrison"
<regext-boun...@ietf.org on behalf of t...@apnic.net> wrote:
Hi Mario,
On Mon, Nov 28, 2022 at 07:19:20PM +0100, Mario Loffredo wrote:
> Il 27/11/2022 22:49, Tom Harrison ha scritto:
>> On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
>>> Even now there is no real way to prevent collisions since
>>> extension identifiers and JSON values are normally used for long
>>> before they are registered.
>>>
>>> Currently, only when an extension is considered stable, the
>>> related identifier is registered.
>>>
>>> Think that preventing RDAP operators to provide temporary reverse
>>> search properties is incompatible with registries'policy of
>>> releasing features on test platforms for a limited period before
>>> running them in the live environment.
>>
>> I can see the argument here, but the document doesn't say e.g.
>> "custom properties may only be used temporarily, or for testing
>> purposes", so it doesn't prevent two servers from having two custom
>> properties with the same name and different behaviour, each of
>> which is intended to be used long-term (i.e. neither server intends
>> to register the property, for whatever reason). If support for
>> custom properties is omitted from the document, then a server
>> wanting to support a new reverse search property temporarily or for
>> testing can still do that, but the lack of in-protocol support for
>> that makes it clear that it's not meant to be a long-term solution.
>
> Would like to reach the largest consensus on this point too.
>
> Therefore, my proposal is to rearrange the
> "reverse_search_properties" extension by removing "type" and keeping
> "links" anyway.
>
> The "links" member could be used to provide additional information
> about unregistered properties.
>
> Would it work for you?
If a server has implemented a custom reverse search property
temporarily, or for testing, then there will (should) be a defined
audience for that property, and that audience should be aware of the
behaviour of that property due to documentation provided out of band.
Providing documentation about unregistered properties by way of a
'links' member facilitates discovery/use of those properties by any
RDAP client, which works against the aim of the registry, so I'd
prefer that 'links' be omitted for that reason. I think
'rdapPropertyPath' should be omitted for similar reasons.
(Although providing reverse_search_properties in-band at all
"facilitates discovery/use of properties" that might be unregistered,
each of the other elements is necessary even in the case of registered
properties, because servers are not required to implement every
possible combination of reverse search that is defined in the
document.)
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
