[regext] Re: Questions about draft-ietf-regext-rdap-x-media-type

[Mario Loffredo <[e-mail]>]

Hi Andy,

again my comments below.

Il 03/10/2024 12:49, Andrew Newton (andy) ha scritto:
>
>
> On 10/2/24 12:33, Mario Loffredo wrote:
>>
>> Hi Andy,
>>
>> please find my comments below.
>>
>> Il 02/10/2024 16:24, Andrew Newton (andy) ha scritto:
>>> On Tue, Oct 1, 2024 at 3:53 AM Mario Loffredo<[e-mail]> wrote:
>>>> Hi Andy and Jasdip,
>>>>
>>>>
>>>> have some questions about draft-ietf-regext-rdap-x-media-type:
>>>>
>>>> 1) rdap_level_0 is included in "extensions" parameter, but it's not an extension, i.e. it's not included in the RDAP Extensions registry. Should it be removed?
>>>>
>>>> 2) If rdap_level_0 is an extension, is it required to be provided?
>>> It's not an extension but is RDAP's own versioning mechanism. It's
>>> included for symmetry with the rdapConformance array and can be used
>>> for the same purpose.
>>
>> [ML] In that case I recommend to change the following sentence to 
>> consider rdap_level_0  as a "special" extension as it's not included 
>> in the RDAP Extensions registry:
>>
>>     The media type defined by this document is 'application/rdap-x+json'.
>>     This media type has a parameter of "extensions" which is a
>>     whitespace-separated list of RDAP extensions as defined in the IANA
>>     RDAP Extensions registry.
>>
>> The alternative is to add rdap_level_0 to the registry.
>>>> 3) If rdap_level_0 is required, what should be the server response when the client doesn't include it or any required extension in the extension parameter?
>>> A very good question. It should be required and a server should
>>> continue to serve information in conformance to rdap_level_0 (or
>>> return a 415 if it cannot conform to rdap_level_0 in a futuristic
>>> scenario where ther is an rdap_level_1 or whatever).
>
>
> Well, its not an extension so it shouldn't go in the extensions 
> registry. I have added an issue in the tracker to add text noting that 
> rdap_level_0 is not an extension and is "special" in this scenario: 
> https://github.com/anewton1998/draft-regext-ext-json-media-type/issues/34
>
>
>> [ML] See my responses below.
>>>> 4) Should the server distinguish the optional and required extensions supported?
>>> What are the definitions of an optional and required extension?
>>
>> [ML] Based on your response to the previous question:
>>
>> - required extensions are those returned by default, i.e. regardless 
>> they are included in the extensions parameter. rdap_level_0 is an 
>> example but an RDAP server might always include a custom extension in 
>> its responses;
>>
>> - optional extensions are those returned only upon request.
>>
>> If there will ever be rdap_level_1, only one between rdap_level_0 and 
>> rdap_level_1 will be returned by default.
>>
>> How is
>> that meaningful to a client?
>>
>> [ML] It's  not meaningful to a client as it can't influence the 
>> server about returning the required extensions because they are 
>> returned anyway, but I think it would be good to address the 
>> difference between the two kind of extensions to make the server 
>> response consistent with the client request. A client would interpret 
>> the return of an unrequested extension as a server bug.
>>
>
> That is not how RDAP works. Clients are suppose to ignore unknown 
> extensions.
>

[ML] I was talking about "unrequested extensions" which can be different 
from "unknown extensions". I remind you that:

1) some custom extensions reported in the RDAP Extensions registry are 
returned by default, most likely to make the RDAP response consistent 
with the WHOIS response. After all, up to now, clients haven't been 
allowed to specify their preferences about response extensions hence 
servers have been free to extend their responses as needed;

2) based on what is stated by some RFCs, the server may autonomously 
return response extensions when certain conditions occurred (see the 
redacted property in RFC9537 and the paging_metadata property in 
RFC8977) or to provide clients with additional information about its 
capabilities (see the properties added to the "/help"response in RFC9536 
and RFC9560).

All of the response extensions above may be returned by servers without 
being requested by clients.

What do you propose to address this topic ?


In addition to it, I see a potential issue with a "/help" request 
including the extensions parameter and the related response.

Quoting Section 4.1 of RFC9083, Section 2.1 of 
draft-ietf-regext-rdap-extensions states that:

The "/help" response returns an
    "rdapConformance" member containing the identifiers for all
    extensions used by the server.

Section 3 of draft-ietf-regext-rdap-x-media-type states that:

    When there is a mismatch between extension parameters and the rdapConformance
    array, clients SHOULD give preference to the rdapConformance array

So, in general, whatever could be the extensions parameter of a "/help" 
request (most likely only  "rdap_level_0"), the server would ignore it 
to build the response.

Don't you think the client could response could misunderstand that 
response ?


Best,

Mario

>
>>>> 5) With regard to your concern about the usage of query parameters, what should be used instead in order to specify values in RDAP queries?
>>>> I mean, I could be good with using content negotiation to request for response extensions but it looks to me unfit to convey values in a query and we have already used that kind of query parameters in some RFCs.
>>>> Indeed, apart from the query parameters used in search queries (e.g. those defined by RFC8977 and RFC8982) which can hardly be redirected, section 4.2 of RFC9560 includes query parameters that don't aim to request for a response extension and can be used in lookup queries.
>>> James Gould has already noted the hyperbolic heading in the rdap-x
>>> document, and we plan to change it.
>>>
>>> However, what you are looking for is in the rdap-extensions draft:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#name-usage-in-query-parameters
>>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#redirects_author
>>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#referrals
>>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#security_considerations
>>> https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#privacy_considerations
>>
>> [ML] If we agree that query parameters are useful in some cases as 
>> the rdap-extensions draft itself seems to admit, I would suggest to 
>> remove or rearrange section B.2 of rdap-x draft.
>>
>
> We already have this issue noted: 
> https://github.com/anewton1998/draft-regext-ext-json-media-type/issues/30
>
> However, the text should stand as it notes the issues of using query 
> parameters in some situations.
>
>
> -andy
>
>
>
> _______________________________________________
> regext mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo