Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search

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