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

Hi Pawel,

please find my comments below.

Il 28/11/2022 07:54, Pawel Kowalik ha scritto:
> 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.
[ML] Just the opposite harm. A registered property having the same name 
of a custom property but they refer to different RDAP properties.
>>>
>>> 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.

[ML] Agree on keeping the same "reverse search property" when it refers 
to the same information represented in different formats.

I'm going to write a proposal about a separate registry for the reverse 
search properties on the maillist so we can hopefully come to consensus 
on this point.

>
>> 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.

[ML] Sure, thanks. The recommendations in section 3 look like very 
fitting to me.

Best,

Mario

>
> Kind Regards,
>
> Pawel
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> 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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo