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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
