Thanks Scott. Looks like most folks have interpreted it the way you have. :)
We'd clarify (not redefine) section 4.1 of RFC 9083 vis-a-vis the a-spec-with-multiple-extension-identifiers scenario in the next version of the RDAP Extensions draft. Though such a scenario should be rare but could happen again. Jasdip On 1/30/24, 2:40 PM, "Hollenbeck, Scott" <shollenb...@verisign.com <mailto:shollenb...@verisign.com>> wrote: Yes, the former, Jasdip. As in, the client should know which extensions it needs to process _in a specific response_. Scott > -----Original Message----- > From: Jasdip Singh <jasd...@arin.net <mailto:jasd...@arin.net>> > Sent: Tuesday, January 30, 2024 10:20 AM > To: Hollenbeck, Scott <shollenb...@verisign.com > <mailto:shollenb...@verisign.com>>; gal...@elistx.com > <mailto:gal...@elistx.com>; > t...@apnic.net <mailto:t...@apnic.net> > Cc: mario.loffredo=40iit.cnr...@dmarc.ietf.org > <mailto:40iit.cnr...@dmarc.ietf.org> <mario.loffr...@iit.cnr.it > <mailto:mario.loffr...@iit.cnr.it>>; > ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org> > <i...@antoin.nl <mailto:i...@antoin.nl>>; regext@ietf.org > <mailto:regext@ietf.org> > Subject: [EXTERNAL] Re: [regext] WG LAST CALL 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, > > Just to clarify, when a specification defines multiple extension identifiers > (like > the RIR Search does), would you interpret what's in RFC 9083 (section 4.1) to > only include those identifiers for a response that were relevant for the > construction of the response (e.g., not including "autnums" and > "autnumSearchResults" for an IP search result, and vice-versa), versus > including all the identifiers for every response type from that specification? > IIUC, you are pointing to the former (only relevant identifiers), right? > > Jasdip > > On 1/29/24, 10:05 AM, "regext on behalf of Hollenbeck, Scott" <regext- > boun...@ietf.org <mailto:boun...@ietf.org> <mailto:regext-boun...@ietf.org > <mailto:regext-boun...@ietf.org>> on behalf of > shollenbeck=40verisign....@dmarc.ietf.org > <mailto:40verisign....@dmarc.ietf.org> > <mailto:40verisign....@dmarc.ietf.org > <mailto:40verisign....@dmarc.ietf.org>>> wrote: > > I'd very much prefer to stay with a literal reading of what's in RFC 9083: > > "A response to a "help" request will include identifiers for all of the > specifications supported by the server. A response to any other request will > include only identifiers for the specifications used in the construction of > the > response. The set of returned identifiers MAY vary depending on the > authorization level of the client." > > Scott > > > -----Original Message----- > > From: regext <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> > > <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>>> On > > Behalf Of James Galvin > > Sent: Monday, January 29, 2024 9:59 AM > > To: Tom Harrison <t...@apnic.net <mailto:t...@apnic.net> > > <mailto:t...@apnic.net <mailto:t...@apnic.net>>> > > Cc: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org > > <mailto:40iit.cnr...@dmarc.ietf.org> > > <mailto:40iit.cnr...@dmarc.ietf.org <mailto:40iit.cnr...@dmarc.ietf.org>>>; > > Antoin Verschuren > > <ietf=40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org> > > <mailto:40antoin...@dmarc.ietf.org <mailto:40antoin...@dmarc.ietf.org>>>; > > regext <regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org > > <mailto:regext@ietf.org>>> > > Subject: [EXTERNAL] Re: [regext] WG LAST CALL > > 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. > > > > Speaking as your Chairs: > > > > Mario brings up an interesting question for which the Chairs need to > > hear some other opinions. > > > > On the one hand, there does seem to be some ambiguity regarding the > > proper use of the rdapConformance array. If this is a concern, then > > the Chairs believe that the WG needs to decide which way they would > > like to resolve this question. More importantly, the question is > > substantive and we will need to close the WG Last Call, resolve the > > issue, and then proceed with another WG Last Call. > > > > On the other hand, this ambiguity does not seem to be of broad > > concern. If that’s true, then the document as currently written could > > be left as is, the WG Last Call could be closed, and if the remaining > > changes are confirmed to be editorial then the document can be submitted > to the IESG. > > > > Do WG members believe this issue is of concern and needs to be resolved? > > > > Please respond on the list. If there are no concerns then the document > > will be left as is and the WG Last Call will be closed on Sunday, 4 February > 2024. > > > > Antoin and Jim > > > > > > > > On 28 Jan 2024, at 19:36, Tom Harrison wrote: > > > > > Hi Mario, > > > > > > On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote: > > >> Il 26/01/2024 04:29, Tom Harrison ha scritto: > > >>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote: > > >>>> 2) Per what is stated in section 4.1 0f RFC9083, the > > >>>> rdapConformance array in the examples Section 4 should include > > >>>> only the extensions used in the response. > > >>>> For sure the response including the ipSearchResults array will > > >>>> never include the autnumSearchResults array and viceversa ;-) The > > >>>> same goes for the responses including the links about ips or > > >>>> autnums. Instead, the help response should include all the > > >>>> extensions implemented. As a result of this, the first two > > >>>> paragraphs of Section 6 should be modified as well. > > >>> > > >>> We think that the existing text/behaviour should be left as-is in > > >>> this respect. Section 4.1 of 9083 says: > > >>> > > >>> A response to a "help" request will include identifiers for all of > > >>> the specifications supported by the server. A response to any > > >>> other request will include only identifiers for the specifications > > >>> used in the construction of the response. > > >>> > > >>> and that any response which makes use of any part of the RIR > > >>> search specification should therefore include all of the > > >>> identifiers defined by the RIR search specification, since each of > > >>> those identifiers will be "for [one of] the specifications used in > > >>> the construction of the response". An alternative reading along > > >>> the lines of your suggestion would require associating identifiers > > >>> with specific functionality in the document. While that's > > >>> relatively straightforward in this case, it would require extra, > > >>> possibly unintuitive guidance in the document as to when > > >>> identifiers should be included. It's also not clear that it yields > > >>> much benefit for the client, either: while it would be possible in > > >>> theory for a client to implement/understand only part of an > > >>> extension, such that a response with a subset of the available > > >>> identifiers could be processed without having to go to the trouble > > >>> of implementing/understanding the whole extension, that doesn't > > >>> seem like something that would come up much in practice, given > > >>> that most > > extensions are quite short/straightforward. What do you think? > > >> > > >> Think it would be good to involve the WG in the diiscussion. > > >> Literally RFC 9083 states that only the identifiers of those > > >> extensions used in building a response can be included in the > > >> rdapConformance array. > > >> > > >> Have always thought that its purpose was to inform clients about > > >> the extension prefixes they should be ready to recognize when > > >> deserializing the response. > > > > > > I'm not sure that it's limited to extension prefixes for the > > > purposes of deserialisation only. For example, the core extension > > > identifier for the NRO RDAP profile (i.e. nro_rdap_profile_0) is not > > > used as a prefix for any response fields, but is still included in > > > most responses from a server that implements that profile, since the > > > behaviour defined there affects how the response is > > > constructed/interpreted. > > > > > >> For this reason, including in the rdapConformance array an > > >> extension identifier that is not used in the response could be > > >> misleading for clients. > > >> > > >> Besides, mentioning in rdapConformance only the extensions used in > > >> the response doesn't mean that either the server or the client can > > >> have a partial knowledge of the specification defining them. > > > > > > It's at least possible to imagine a scenario where this is the case, > > > even if it may be unlikely to happen in practice. Under the approach > > > you have set out, a specification that defines two or more extension > > > identifiers needs to describe when those extension identifiers > > > should be included in responses. If one identifier is used for > > > behaviour that is specific to that identifier and isolated from the > > > behaviour for the other identifiers, then the server may opt to > > > support only that behaviour, and a client may similarly be written > > > such that it understands only that behaviour from the specification. > > > (This is not a problem of itself, it's just that it's the only > > > benefit that I can see that comes from using that approach.) > > > > > >> Otherwise wouldn't understand the need to distinguish between the > > >> rdapConformance value in the help response and that in the other > > >> responses. > > > > > > To avoid any doubt here, under our approach a response would not > > > include the identifiers for an extension if that extension was > > > unrelated to the response. For example, in the RIR search case, a > > > server that (e.g.) did not include relation links in IP responses > > > would omit the identifiers for the RIR search extension from those > > > responses. The help response still serves the same purpose as before > > > when using this approach. > > > > > > -Tom > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
