Hi Scott, On Wed, Oct 09, 2024 at 11:57:09AM +0000, Hollenbeck, Scott wrote: > In another thread focused on the extensions draft, I was asked > "Would you like regext to revisit Reverse Search?" That prompted me > to take another look at the draft. It currently defines five > extension identifiers (two for path segments, two for result data > structures, and one for something else) for this single extension, > none of which are used as described in Standard 95. > > I don't understand why it's insufficient to register a single > extension identifier, such as "rs", that can be used as a prefix for > the path segment and result data structures. Using examples from the > draft, that single identifier could be used like this: > > rs_ips?name=XXXX > rs_autnums?handle=XXXX > rs_autnums?name=XXXX > rs_ips/rirSearch1/<relation>/<IP address> > rs_autnums/rirSearch1/<relation>/<autonomous system number or range> > rs_domains/rirSearch1/<relation>/<domain name> > "rs_ipSearchResults: []" > "rs_autnumSearchResults: []"
It's true that the draft could take this approach instead. There are several reasons why we went with the multiple-identifier approach: - Basic IP and ASN searches are a unique category of functionality, because the core documents define the object classes, but without the searches. Prefixing the basic searches with "rs_" (or similar) may be confusing for users who would expect consistency with the other core object types in this respect. - Reverse search registrations (https://www.iana.org/assignments/rdap-reverse-search/rdap-reverse-search.xhtml) contain two resource types: "searchable-resource-type": It MUST be one of the resource types for search defined in Section 3.2 of [RFC9082] (i.e., "domains", "nameservers", and "entities") or a resource type extension. "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") or a resource type extension. Because these two values are used as path segments, an extension defining a new resource type (object class) for use with reverse search must register singular and plural forms as extension identifiers. This is fine for a completely new object type, but for IP objects and ASNs, the singular form is already defined without a prefix. If a prefixed form (e.g. "rs_ips") has to be used for the searchable resource type, that could be confusing for users. (This is very similar to the previous point.) - If the document defines a single extension identifier, and uses that as a path prefix, a user could accidentally infer that the extension itself defines or has some control over the core object type, even though that's not the case. Although this approach goes against some of the text from 9082 and 9083, there are a couple of reasons why we thought that that would be OK in this situation: - Per earlier comments, RFC 9536 (reverse search) uses its bare identifier as a path segment, and RFC 9537 (redacted) uses its bare identifier as a response member, so there was some precedent for the usage here. - Also per earlier comments, it's difficult to see how bare extension identifiers in paths or responses could cause problems in practice. It's true (e.g.) that there could be a client that, in reliance on section 6 of RFC 9082, rejects a user's attempted RDAP requests where the request path is non-standard and does not begin with an extension identifier followed by an underscore, but that would be an exceptionally strict approach to take, given that the client can simply send the request to the server and see what happens. With the response members, the constraints are SHOULDs, and clients are to ignore unrecognised JSON members in any event, so it doesn't seem like bare identifiers would cause any issues there either. On the server side, as you noted, as long as requests can be handled unambiguously, there shouldn't be any (operational/practical) problems. > There is no collision with the "ip" and "autnum" path segments from > 9082 because those values are singular. This draft uses the plural > forms "ips" and "autnums". Just in case others are reading this and wondering why plurals are used, it's because they give consistency with the core specifications, which use "domains", "nameservers", and "entities" for the paths for the basic searches for those object types. > If there's some reason that the above is invalid, please explain > why. The "rirSearch1" identifier appears in path segments and the > rdapConformance data structure, but I don't see how it actually > identifies an extension element unless it's intended to disambiguate > the "domains" search collision I noted above. If that's the case, > use of the extension prefix to create "rs_domains" would avoid the > collision entirely. That's right, but in that case we would probably still use the extension identifier under the basic search paths anyway, to simplify the registration of subsequent extensions under those basic searches. (Assuming that this document progresses past WGLC with the current approach, we'll include details about this issue in the shepherd writeup, per your request.) -Tom _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
