Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)

[Andrew Newton <[e-mail]>]

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
<[e-mail]> 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
> > <[e-mail]>  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
> > [e-mail]
> > 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: [phone]
> Web:http://www.iit.cnr.it/mario.loffredo
>