Scott,
This was discussed in this working group on this list by me and others.
I even proposed something similar. However, absent some functional
deficiency or harm, I do not favor re-opening this issue post WGLC. It
may not have been the way I would have done it, but to my knowledge it
works and no reviews found fault.
I am also confused by your suggestion. In another thread you are arguing
against child path segments, yet your proposal below uses them.
-andy
On 10/9/24 07:57, 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: [
]”
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 toregext-le...@ietf.org
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org