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