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
