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

[Mario Loffredo <[e-mail]>]

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
> <[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
>>
> _______________________________________________
> 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