Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

[Mario Loffredo <[e-mail]>]

Hi Tom,

thanks so much for your careful review.

I'll publish the new version incorporating the changes as soon as 
possible ;-)

Mario

Il 18/04/2022 13:10, Tom Harrison ha scritto:
> On Mon, Apr 04, 2022 at 03:18:33PM +0200, Antoin Verschuren wrote:
>> Dear Working Group,
>>
>> The authors of the following working group document have indicated
>> that it is believed to be ready for submission to the IESG for
>> publication as a standards track document:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
> I think this document is in good shape as it is.  Some minor
> points/suggestions:
>
>   - Section 2 has "All the predicates are joined by the AND logical
>     operator".  For the multivalued predicate properties ('role', 'fn',
>     and 'email'), the behaviour as required by the text here may be
>     slightly unintuitive.  For example, if two 'fn' predicates are
>     included, then an object will only be included in the results if
>     one of its related entities matches against both of those
>     predicates, which would be unusual given that most entities have a
>     single 'fn' property.  Making this requirement clearer may help to
>     avoid confusion:
>
>      All the predicates are joined by the AND logical operator.  This
>      includes predicates that are for the same property: it is
>      necessary in such a case for the related object to match against
>      each of those predicates.
>
>   - Section 2 has "Based on their policy, servers MAY restrict the
>     usage of predicates to make a valid search condition".  It may be
>     useful to clarify how this will happen.  For example:
>
>      Based on their policy, servers MAY restrict the usage of
>      predicates to make a valid search condition, by returning a 400
>      (Bad Request) response when a problematic request is received.
>
>     (Possibly there's a more appropriate response code than 400 that
>     can be used.)
>
>   - Section 2 has:
>
>      related-resource-type: it MUST be one of the resource types for
>      lookup defined in Section 3.1 of [RFC9082], i.e. "domain",
>      "nameserver", "entity", "ip" and "autnum";
>
>     But the document defines semantics only for "entity" in this
>     context.  Some additional text (after the bullet points) that makes
>     it clear that this is intentional may be useful:
>
>      While related-resource-type is defined as having one of a number
>      of different values, the only searches defined in this document
>      are for a related-resource-type of "entity".  Searches for the
>      other mentioned types may be defined by future documents.
>
>   - There is no text that specifies the response format for the
>     searches.  Although this is arguably implicit based on RFC 9082, it
>     may be useful to be explicit about it, by adding another section
>     between 2 and 2.1:
>
>      2.1 RDAP Response Specification
>
>      Reverse search responses use the formats defined in section 8 of
>      RFC 9082, which correspond to the searchable resource types
>      defined in section 2.
>
>   - I-D.ietf-calext-jscontact is listed as an informative reference,
>     but it appears to be a normative reference, given that the
>     JSONPaths for 'fn' and 'email' are taken from that document.
>     Assuming that it is a normative reference, then it may be that the
>     reverse search document will be approved notwithstanding the
>     downref.  However, there are a couple of options for avoiding that
>     in the first place:
>      - Define the document in terms of jCard only, and note that
>        documents defining successor formats to jCard will describe how
>        to handle the conversion from 'fn'/'email' to the corresponding
>        fields in the new format.
>      - Define inline metadata, so that the relevant JSONPaths are
>        available to the client, and can be changed to work for
>        JSContact when a server switches to use JSContact (similarly to
>        how things work with RFC 8977).
>
>   - Section 2.1 has "Servers MAY implement other properties than those
>     defined in this section".  A server that supports other properties
>     for the purposes of reverse search has no way to indicate that
>     support except by way of a standards-track specification that
>     defines a new rdapConformance value, which would be the case
>     regardless of this additional text in the document, so it seems
>     like this text could be omitted.
>
> -Tom
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. 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