[regext] Re: Extension Identifiers in draft-ietf-regext-rdap-rir-search

[[e-mail]]

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 <[e-mail]>
> *Date: *Friday, October 11, 2024 at 8:19 AM
> *To: *mario.loffredo=[e-mail] 
> <mario.loffredo=[e-mail]>, Jasdip Singh 
> <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>
> *Subject: *RE: Re: [regext] Re: Extension Identifiers in 
> draft-ietf-regext-rdap-rir-search
>
> *From:*Mario Loffredo <mario.loffredo=[e-mail]>
> *Sent:* Friday, October 11, 2024 2:44 AM
> *To:* Hollenbeck, Scott <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]
> *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 [e-mail]
> To unsubscribe send an email [e-mail]