Hi Andy,
could it work for you and Scott if I changed the text in Section 12.2.1
as in the following ?
OLD
Creators of either new RDAP reverse searches or new mappings for
registered reverse searches SHOULD NOT replicate functionality
already available by way of other documents referenced in these
registries.
NEW
Creators of either new RDAP reverse searches or new mappings for
registered reverse searches SHOULD NOT replicate functionality
already available by way of other documents referenced in these
registries. Likewise, they SHOULD NOT map a registered reverse search
property
to a response field with a meaning other than that of the response fields
referenced by the mappings already registered for that property.
In other words, all the mappings for a reverse search property MUST
point to response fields with the same meaning.
Best,
Mario
Il 16/08/2023 17:17, Andrew Newton ha scritto:
Thanks Mario. I understand the intent and had assumed that multiple
mappings were allowed.
While Scott and I understand, do we feel that future DE's might need
better guidance? Is the term "collisions" clear enough for a future DE
that may not have the benefit of having read this email thread?
-andy
On Mon, Aug 14, 2023 at 3:34 AM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
Hi Andy,
please find my comments inline.
Il 11/08/2023 14:16, Andrew Newton ha scritto:
I wish I had asked this during the WG discussion, but I do have a question.
Section 12.2.1 paragraph 3 states:
"The designated expert should prevent collisions and confirm that
suitable documentation, as described in Section 4.6 of [RFC8126], is
available to ensure interoperability. References are not limited only
to RFCs and simple definitions could be described in the registries
themselves."
Does this mean that no duplicates in the RDAP Reverse Search Mapping
(section 12.2.4) are allowed?
[ML] What do you mean with "duplicates" ?
Under the conditions of sections 12.2.3.1. and 12.2.4.1. about the
uniqueness of the registries entries , duplicated entries are clearly
not possible.
Instead it's allowed that a single reverse property maps to more than
one response fields.
In this case one entry in the "Reverse Search" registry will split into
more entries in the "Reverse Search Mapping" registry depending on the
varipus values of the "Property Path" field.
The classical example is the "fn" reverse search property that maps to
multiple response fields based on the given contact format. But each of
those response fields has the same meaning namely the contact full name.
The term "collisions" is used in that sentence to refer to the case
where the DEs receive two registration requests for the same reverse
search property that maps to two response fields having different meaning.
It's unliely to happen but we can't exclude it.
If this is the case, that means a reverse search of "fn" will only
apply to jCard and cannot be applied to JSContact or SimpleContact
since the registration for "fn" is jCard specific. Is this
intentional?
[ML] As pointed out above, the "fn" reverse search property will also
apply to other contact representations as the value of the "Property
Path" field will be different according to the contact representation used.
The name of the reverse search property is just a conventional name that
doesn't need to exactly match that of the response field it maps to. For
example, "fn" can map to the jCard "fn" as well as to the property
representing the contact full name in any other contact representation.
The same goes for "email".
The name "fn" has been used for compatibility with the corresponding
query parameter defined in RFC 9082 to search for entities.
I see this in section 5:
"Documents that deprecate or restructure RDAP responses such that a
registered reverse search is no longer able to be used MUST either
note that the relevant reverse search is no longer available (in the
case of deprecation) or describe how to continue supporting the
relevant search by adding another mapping for the reverse search
property (in the case of restructuring)."
It implies that duplicates are allowed, at least to me.
[ML] See my previous comments.
Mario
-andy
On Thu, Aug 10, 2023 at 6:41 PM David Dong via RT
<drafts-expert-review-comm...@iana.org> wrote:
Dear Andy and Scott (cc: regext WG),
As the designated experts for the RDAP Extensions registry, can you review the
proposed registration in draft-ietf-regext-rdap-reverse-search-23 for us?
Please see:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
The due date is August 24th.
If this is OK, when the IESG approves the document for publication, we'll make
the registration at:
https://www.iana.org/assignments/rdap-extensions/
Unless you ask us to wait for the other reviewer, we’ll act on the first
response we receive.
With thanks,
David Dong
IANA Services Sr. Specialist
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Senior Technologist
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
--
Dott. Mario Loffredo
Senior Technologist
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
