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: [ ]" Please note that the domain relation search function described in the draft is apparently extending the core "domains" search described in RFC 9082. Both currently use "domains" in the path segment. That isn't optimal. 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". 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. Sorry that this feedback is coming so late. Scott
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
