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

[Mario Loffredo <[e-mail]>]

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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo