From: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> Sent: Friday, October 11, 2024 2:44 AM To: Hollenbeck, Scott <shollenb...@verisign.com>; jasd...@arin.net; 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. Hi Scott, sorry but didn't undenstand your example about collisions. From a conceptual perspective, any path "/domains/...." is a subpath (we can consider it as an extension) of "/domains" but, programmatically, they are different as AFAIK a full path is parsed and processed altogheter. For example, in .it RDAP server, I have leveraged the feauture provided by a Java framework to specify paths and their subpaths in order to easily map an incoming request onto but, at the end of the parsing phase, only one full path is selected. [SAH] Mario, my concern about a possible collision arose because “domains” (from RFC 9082) === “domains” (from the draft). I’m not sure if the draft is specifying a new “domains” path segment (in which case the names do collide), or if the draft is extending the 9082 path segment by adding additional elements to the path. My confusion exists because the draft isn’t using prefixed extension identifiers. The situation would be unambiguous if the draft used something like “rs_domains”, or “domains/rs_rirSearch1”. The prefix is a clear indicator of what’s being extended. In my exchange with Jasdip I did note that there’s no operational issue here even if there is a collision because a properly formed query will contain other information that enables a server to correctly process both 9082 queries and RIR search queries, though I’d prefer that the information included an extension identifier prefix. I also noted that I’d like to for the shepherd writeup include text noting that the proposed extension identifiers don’t comply with Standard 95, and we don’t have consensus on whether or not that’s an issue. Scott
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
