Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

[Mario Loffredo <[e-mail]>]

Hi Jasdip,

thanks for joining the discussion.

I have always been much more in favor of providing self-descriptive REST 
APIs (i.e. the HATOAS approach) rather than using a centralized 
registry. Therefore, I have always preferred metadata discovery over 
registration.

However, I admit that they accomplish two different purposes.

I'll shortly come up with a new proposal that hopefully will gather 
consensus.

Best,

Mario

Il 29/11/2022 01:26, Jasdip Singh ha scritto:
> 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" <[e-mail] on behalf of [e-mail]> 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
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/regext
>
-- 
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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo