Hi Tom,
my comments below.
Il 28/11/2022 23:36, Tom Harrison ha scritto:
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.)
OK. Have understood your point of view. I'm writing a new proposal which
hopefully we'll converge to.
Best,
Mario
-Tom
--
Dott. 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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
