Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-16.txt

[Mario Loffredo <[e-mail]>]

Hi Tom,

please find my comments below prefixed with ML3.

Il 27/11/2022 22:49, Tom Harrison ha scritto:
> Hi Mario,
>
> On Fri, Nov 25, 2022 at 02:18:35PM +0100, Mario Loffredo wrote:
>> Il 24/11/2022 13:46, Tom Harrison ha scritto:
>>> This is the part I (still) don't follow, sorry.  The fact that the
>>> label is a JSON value in the "reverse_search_properties" member of
>>> the help response does not mean that the label needs to be
>>> registered in the "RDAP JSON Values" registry, as best I can tell.
>> [ML2] Per my understanding of the introduction of RFC8126, any
>> constant defined in a protocol should be registered.
>>
>> Since the "reverse_search_properties" member includes some
>> pre-defined JSON values, they can be added to the "RDAP JSON Values"
>> registry.
>>
>>     Many protocols make use of points of extensibility that use
>>     constants to identify various protocol parameters.  To ensure
>>     that the values in these fields do not have conflicting uses and
>>     to promote interoperability, their allocations are often
>>     coordinated by a central record keeper.
> Thanks, this was the part I was missing.
>
>>>> The content of  "reverse_search_properties" member disambiguates
>>>> the meaning of that labels in the context of the reverse search
>>>> queries a server supports, e.g. an RDAP server could provide
>>>>
>>>> "domains/reverse_search/entity?handle" rather than
>>>> "nameservers/reverse_search/entity?handle" or both of them.
>>>>
>>>> That said, I admit that the description of the "handle" entry as
>>>> presented in the document is tailored on the "entity" as related
>>>> resource type so, if there is consensus on this way to go, I'll
>>>> make it more generic.
>>> I don't see how the entry could be made more generic with respect
>>> to the related resource type.  Even the current descriptions are
>>> arguably too broad, since they do not limit the searchable object
>>> type to one of domains, nameservers, or entities (being the three
>>> searchable object types mentioned in section 2) but could e.g. be
>>> read as applying to IP networks and ASNs as well.  A separate
>>> registry would fix this problem.

[ML3] I don't have any objection to opt for a separate registry.

Provided that there is no concern on using a separate registry from 
other WG members, I'll come up with a new proposal on the mailing list 
shortly.

>> [ML2] I would simply remove the reference to the "entity" object
>> class as in the following:
>>
>> OLD
>>
>> When the related resource type in a reverse search query is
>> "entity", it signals that the RDAP server supports the reverse
>> search based on the "fn"property of an entity associated with the
>> selected searchable resource type
>>
>> NEW
>>
>> It signals that the RDAP server supports the reverse search based on
>> the "fn"property of the given resource type associated with the
>> given searchable resource type
>>
>> As I wrote in my previous mail, the reverse search property maps a
>> property of the related resource type in a reverse search query. The
>> searchable resource type is just needed to specify which reverse
>> query an RDAP operator is willing to support but this information is
>> included in the "reverse_search_properties" help response extension.
>>
>> This approach would minimize the number entries compared to those
>> required for a registry including all the variables in the reverse
>> search query model.
>>
>> In fact, having defined four reverse search properties and based on
>> the fact that the object class entity is associated to any RFC9083
>> object class, the pre-defined entries of a possible "Reverse Search
>> Properties" registry should be the following:
>>
>> (domains|nameservers|entities) - entity - handle
>>
>> (domains|nameservers|entities) - entity - fn
>>
>> (domains|nameservers|entities) - entity - email
>>
>> (domains|nameservers|entities) - entity - role
>>
>> domains - nameserver - handle
>>
>> Applying reverse search to ips and autnums searchable resource types
>> without declaring  additional properties would add no entry to "RDAP
>> JSON Values" registry instead of eight additional entries in the
>> "Reverse Search Properties"  registry.
> My main concern here is that the reverse search document defines
> behaviour for searchable object types that contain an 'entities'
> member which is a list of entity-type objects, with the further
> requirement that the 'fn' and 'email' searches only work correctly for
> entity-type objects containing vCards (i.e. they won't work for
> entity-type objects containing JSContact records).  Defining the
> registry property generically runs the risk of server implementors
> adding reverse search properties for other object types (searchable or
> related), without properly defining the behaviour for those searches.
> Using the existing registry is fine (IMHO) if the text limits the
> search to the cases considered by this document.  (That does mean that
> it's not possible to register more than one reverse search for a given
> name, but maybe that's not a serious problem in practice, given that
> implementors can just choose another name if necessary.)
>
>>> But there's no way to prevent collisions from happening, if custom
>>> reverse search properties are supported.  If server S1 uses a
>>> custom reverse search property named P, and server S2 then
>>> registers with IANA a property with the same name, then there will
>>> be a collision between the two names.  It won't necessarily be
>>> possible for S2 to confirm that P hasn't previously been used.
>> [ML2] Even now there is no real way to prevent collisions since
>> extension identifiers and JSON values are normally used for long
>> before they are registered.
>>
>> Currently, only when an extension is considered stable, the related
>> identifier is registered.
>>
>> Think that preventing RDAP operators to provide temporary reverse
>> search properties is incompatible with registries'policy of
>> releasing features on test platforms for a limited period before
>> running them in the live environment.
> I can see the argument here, but the document doesn't say e.g. "custom
> properties may only be used temporarily, or for testing purposes", so
> it doesn't prevent two servers from having two custom properties with
> the same name and different behaviour, each of which is intended to be
> used long-term (i.e. neither server intends to register the property,
> for whatever reason).  If support for custom properties is omitted
> from the document, then a server wanting to support a new reverse
> search property temporarily or for testing can still do that, but the
> lack of in-protocol support for that makes it clear that it's not
> meant to be a long-term solution.

[ML3] Would like to reach the largest consensus on this point too.

Therefore, my proposal is to rearrange the "reverse_search_properties" 
extension by removing "type" and keeping "links" anyway.

The "links" member could be used to provide additional information about 
unregistered properties.

Would it work for you?


Best,

Mario

>>>> With regard to the meaning of your last sentence, I need a
>>>> clarification.  Are you meaning that inconsistencies come up
>>>> because, for example, the "email" reverse search property maps the
>>>> same JSON value but identified through two different JSONPaths in
>>>> the RDAP response ?
>>> I don't think it would be open to a server to do this under the
>>> current document, because the JSONPath to "email" is defined in the
>>> document itself.  An example scenario where inconsistency could occur:
>>>
>>>    - S1, S2, and S3 implement support for JSContact.
>>>    - S1 decides to add a custom reverse search property called "name",
>>>      for matching a JSContact "name" (per 2.2.1 of that document), by
>>>      looking at the "given" and "surname" name components for the
>>>      JSContact "name".
>>>    - S2 also adds a custom reverse search property called "name", but
>>>      instead matches against the JSContact "fullName".
>>>    - S3 also adds a custom reverse search property called "name", in the
>>>      same manner as S2, but if a jCard is retrieved, it falls back to
>>>      using the same logic as that for an "fn" reverse search per the
>>>      current document.
>> 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."
>>
>> Being JSContact fullName a variant of jCard fn, both S2 and S3 can't define
>> "name" as a custom property.
> 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.
>
> -Tom
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dott. Mario Loffredo
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