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

[Pawel Kowalik <[e-mail]>]

Hi Mario,

Am 29.11.22 um 07:46 schrieb Mario Loffredo:
>
> Hi Pawel,
>
> Il 28/11/2022 22:02, Pawel Kowalik ha scritto:
>>
>> Hi Mario,
>>
>> My comment inline.
>>
>> Am 28.11.22 um 21:20 schrieb Mario Loffredo:
>>>>>> "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.
>>> [ML] Just the opposite harm. A registered property having the same 
>>> name of a custom property but they refer to different RDAP properties. 
>> [PK2] OK, this one I agree, but this is the first part "A custom 
>> reverse search property MUST NOT collide with a registered reverse 
>> search property", isn't it?
>>
>> My comment was referring to the second part, where, if I read it 
>> right, it would be forbidden to match a custom reverse search 
>> property to same field as any of already registered ones.
>>
> [ML] In my opinion, both the misuses are harmful. For the sake of 
> increasing interoperability, the case of two reverse search properties 
> mapping the same RDAP property must be avoided as well.
>
[PK3] Sure, this must not happen on the level of registered reverse 
search properties, to have duplicated registered names pointing to the 
same property. I think it should be at least allowed (ergo SHOULD NOT 
instead of MUST NOT) to have such duplicates with custom property which 
is local and makes no harm to the interoperability. There is a clear 
use-case behind which is a natural consequence of experimental nature of 
custom reverse search properties. See the scenario I mentioned 2 comment 
earlier.
>
> The only admissible case should be when the same name is used to map 
> two RDAP properties but one is an equivalent representation of the 
> other in another format (i.e. the entity full name can be represented 
> both in jCard and in JSContact but both are used to represent the same 
> information).
>
[PK3] Fully agree here.

Kind Regards,

Pawel