Hi Jasdip,I think "re-using" wouldn't be the right statement. To me it seem that relation search is actually defining a certain extension functionality of an existing search path segment /domains. This is however only implicit, because rfc9082 is actually not defining if a path segment below /domains hast to be related to /domains or not. From the implementation standpoint it might be an useful property, being able for example to route requests for certain top level paths to specific subsystems responsible for certain resource types. Also 2.3.1 of draft-ietf-regext-rdap-extensions does not offer clarity if path segments are added to existing path segments.
From this perspective whether the path is extended with /rirSearch1 or /rs_rirSearch1 does not really make a difference for interoperability, if this implicit assumption would have been clear in the draft.
The ambiguity seems to be also there because /domains path segment is used the same in both context of RIR and domain name registry. The draft puts however RIR in focus. This poses an interesting question - if a domain name registry would like to define relation type of search as in this draft, is it ok to signal this extension and just support 'domains/rirSearch1/<relation>/<domain name>' path, or would it be expected to support all the paths defined, meaning in practice this extension would not be able to be used at all and an extension would have to be defined separately for this use case?
Section 6 seems to imply that a partial implementation is not an intention of authors (even though I did not find any normative language around that:
"[...] that is not meant to imply that a server can support only a portion of the functionality defined in this document."
Kind Regards, Pawel On 11.10.24 20:55, Jasdip Singh wrote:
Hi Scott,It is the latter. “domains/rirSearch1/<relation>/<domain name>” re-uses the “domains” path segment from RFC 9082 and then adds child path segments.This is also how we do in reverse search (RFC 9536). For example, “/domains/reverse_search/entity?handle=CID-40*&role=technical”.Jasdip *From: *Hollenbeck, Scott <shollenb...@verisign.com> *Date: *Friday, October 11, 2024 at 8:19 AM*To: *mario.loffredo=40iit.cnr...@dmarc.ietf.org <mario.loffredo=40iit.cnr...@dmarc.ietf.org>, Jasdip Singh <jasd...@arin.net>, a...@hxr.us <a...@hxr.us>, regext@ietf.org <regext@ietf.org> *Subject: *RE: Re: [regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search*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 toregext-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
