That’s fair, Scott. BTW, so would be Reverse Search, until the Extensions draft updates STD 95 vis-à-vis the additional use-extension-id-as-segment-for-child-segments approach.
Jasdip From: Hollenbeck, Scott <shollenb...@verisign.com> Date: Wednesday, October 9, 2024 at 3:30 PM To: Jasdip Singh <jasd...@arin.net>, a...@hxr.us <a...@hxr.us>, regext@ietf.org <regext@ietf.org> Cc: mario.loffr...@iit.cnr.it <mario.loffr...@iit.cnr.it> Subject: RE: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search Yes, we do, but I would still like to request that the shepherd writeup include a description of the situation with respect to the extension identifiers and non-conformance with Standard 95 as noted below. It would be perfectly acceptable to note that only one person raised the concern. My comments might have come in after the last call, but they were sent prior to AD review. They’re not invalid. Scott From: Jasdip Singh <jasd...@arin.net> Sent: Wednesday, October 9, 2024 12:47 PM To: Hollenbeck, Scott <shollenb...@verisign.com>; a...@hxr.us; regext@ietf.org Subject: [EXTERNAL] Re: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. We agree. :) Jasdip From: Hollenbeck, Scott <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> Date: Wednesday, October 9, 2024 at 12:30 PM To: Jasdip Singh <jasd...@arin.net<mailto:jasd...@arin.net>>, a...@hxr.us<mailto:a...@hxr.us> <a...@hxr.us<mailto:a...@hxr.us>>, regext@ietf.org<mailto:regext@ietf.org> <regext@ietf.org<mailto:regext@ietf.org>> Subject: RE: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search From: Jasdip Singh <jasd...@arin.net<mailto:jasd...@arin.net>> Sent: Wednesday, October 9, 2024 11:54 AM To: Hollenbeck, Scott <shollenb...@verisign.com<mailto:shollenb...@verisign.com>>; a...@hxr.us<mailto:a...@hxr.us>; regext@ietf.org<mailto:regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Scott, Glad to know that you are not against the use-extension-id-as-segment-for-child-segments approach, beside the prepend-extension-id-and-underscore approach from STD 95. Re: “The “domains” collision is an issue. We can deal with it now, or during IETF last call.” AFAICT, it is not an issue. One can define new child segments under it. [SAH] I’ve actually written RDAP server code. Let’s walk through how this might work. My server receives a “domains” query. I don’t support this extension, but I do support DNR domain searches. I expect the query to be formatted as described in RFC 9082. Anything else is an error. No problem there. My server receives a “domains” query. I support this extension, but I do not support DNR domain searches. I expect the query to be formatted as described in the draft. Anything else is an error. No problem there. My server receives a “domains” query. I’m a general purpose RDAP server, and I include code to process both DNR and RIR domain searches. I need to figure out which “domains” query I’ve received. I need to parse the query further to figure out what to do next. If there are query parameters, but no child path segments, I may have a valid DNR search. If there are no query parameters, but I have a child path segment that begins with “rirSearch1”, I may have a valid RIR search. Anything else is an error. If this is all correct, OK, I agree that there’s no issue here. Scott
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
