+1000. Outside of some Skynet scenarios, I'm highly skeptical about clients evolving behaviors on their own.
-andy On Mon, Nov 28, 2022 at 7:26 PM Jasdip Singh <jasd...@arin.net> wrote: > > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
