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

[Tom Harrison <[e-mail]>]

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