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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
