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> On Behalf Of James Galvin > Sent: Monday, January 29, 2024 9:59 AM > To: Tom Harrison <t...@apnic.net> > Cc: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org>; Antoin > Verschuren <ietf=40antoin...@dmarc.ietf.org>; regext <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://secure-web.cisco.com/10- > 50BBfU_6h4F4VS33kVYUEquEL0XNPyXAS0d7Mj > > jZl62LnDp0T4NQlRiqq2wBF9XPBlleCRep6gmRjyfw4- > O9ZK7bWmLxoyOSKXVnTWoWq2UI > > > 9sQZLliW17goEqJ1ycOMZjnxi3aNhwoRINRkNWYelbs2v3Bw22Hn_5RdMzw6 > pOXthfWOPt > > > t_DS2Ux9qxx5fZ7gLO29slNTY_tfvnp8b88iQoQu1ChtLKP7ZiAWCUIrLZnHgACP > l77J_i > > > 41YqdX_2R284f3xGls2NNQ3Bnb4IU0zfHxo1PJglqPDjrvUHY/https%3A%2F% > 2Fwww.ie > > tf.org%2Fmailman%2Flistinfo%2Fregext > > _______________________________________________ > regext mailing list > regext@ietf.org > https://secure-web.cisco.com/10- > 50BBfU_6h4F4VS33kVYUEquEL0XNPyXAS0d7MjjZl62LnDp0T4NQlRiqq2wBF > 9XPBlleCRep6gmRjyfw4- > O9ZK7bWmLxoyOSKXVnTWoWq2UI9sQZLliW17goEqJ1ycOMZjnxi3aNhwoRI > NRkNWYelbs2v3Bw22Hn_5RdMzw6pOXthfWOPtt_DS2Ux9qxx5fZ7gLO29slN > TY_tfvnp8b88iQoQu1ChtLKP7ZiAWCUIrLZnHgACPl77J_i41YqdX_2R284f3xGls > 2NNQ3Bnb4IU0zfHxo1PJglqPDjrvUHY/https%3A%2F%2Fwww.ietf.org%2Fm > ailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
