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

[Pawel Kowalik <[e-mail]>]

Hi,

My comments below.

Am 27.11.22 um 22:49 schrieb Tom Harrison:
> [...]
>> I still think that custom properties are useful for the reasons above.
>>
>> On the other hand, their possible misuse should be ruled somehow.
>>
>> Here in the following a possible statement limiting the scope of custom
>> properties:
>>
>> "A custom reverse search property MUST NOT collide with a registered reverse
>> search property and MUST NOT match an RDAP property, or any of its variants,
>> matched by a registered reverse search property."
[PK] not sure about the second MUST NOT if it's not too hard. What kind 
of harm we are trying to prevent, when 2 reverse search properties match 
the same RDAP property?
I am thinking of a scenario, where the server defines a custom property, 
then it gets registered under a different name - the server may wish to 
keep both for back compatibility.
>>
>> Being JSContact fullName a variant of jCard fn, both S2 and S3 can't define
>> "name" as a custom property.

[PK] Isn't it actually a useful property if "reverse search property" 
may remain the same no matter what the underlying representation is? As 
a client I am interested to get all related objects with an entity 
holding for example certain email address, no matter if jCard or 
JSContact is used by the server. This abstraction layer offers the 
possibility to leave the differences in the data representation and the 
related filtering up to the RDAP server implementation without breaking 
the protocol.

> I still don't see how the document can require that a custom reverse
> search property not collide with registered reverse search properties
> as to its name or the members that it refers to, because the person
> registering a new reverse seach property is not guaranteed to be aware
> of all existing custom reverse search properties.  The fact that a
> given field is a 'variant' of another may not be obvious to
> implementors, either.  If any new reverse search that isn't covered by
> the existing document has to be defined in an extension, then these
> problems go away.

[PK] I think it's a common problem. RFC 6648 Section 3 and 4 offer some 
guidance which we may reference to or adapt into this draft.

Kind Regards,

Pawel