Hi Tom,
thinking back to my last message, I need some clarifications before
updating the document.
Please find my comments inline.
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.
[ML] Note a different feeling about it between you and Scott. I mostly
agree with you on this point but I'm open to any solution that is shared
by the WG, especially if it comes from those having long experience in
writing IETF documents.
According to what is stated in
https://www.ietf.org/id/draft-kucherawy-bcp97bis-01.html:
*...., a normative reference specifies a document that must be read to
fully understand or implement the subject matter in the RFC, or whose
contents are effectively part of the RFC, as its omission would leave
the RFC incompletely specified. **
*
*An informative reference is not normative; rather, it provides only
additional background information.*
That being said, don't think JSContact related documents must be read to
fully understand the reverse search document. For this reason, I put
them among the informative references.
However, I would like to know Scott's and other members'opinions.
- 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).
[ML] I have already proposed to extend the response with an inline
metadata about the supported reverse search properties but I'm not sure
when it should be returned.
The metadata described in both RFC8977 and RFC 8982 include information
about server features that can be applied to every search response,
including reverse search.
On the contrary, it wouldn't make sense to me to return the reverse
search metadata in every search response.
- 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.
[ML] Most probably I didn't make myself clear. I meant that servers may
implement additional reverse search properties, including those mapped
to RDAP response extensions.
Just to give you an example, some ccTLDs, including .it, have extended
the registrant information with the tax code.
Being such a code a unique identifier, it could be eligible as reverse
search property.
Don't think servers should specify a specific RDAP conformance tag in
that case. It would be enough for them to provide the reverse search
properties they implement in the /help response.
Are you OK with changing the sentence as in the following?
Servers MAY implement other properties in addition to those defined in this
section.
Totally agree on the other points without comment.
Best,
Mario
-Tom
_______________________________________________
regext mailing list
[email protected]
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
