Il 03/10/2024 14:39, Gould, James ha scritto:
Andy & Mario,
As far as how to handle “rdap_level_0”, this is applicable to both
draft-ietf-regext-rdap-x-media-type and
draft-ietf-regext-rdap-versioning, where we should be consistent.
Based on the possibility of draft-ietf-regext-rdap-extensions having
to update RFC 7480, RFC 9082, and RFC 9083, this raises the
possibility of needing “rdap_level_1” and supporting the signaling
capability. I believe it makes sense to register “rdap_level_0” in
the RDAP Extensions Registry as a special extension identifier, which
really represents the default namespace for all the objects and
members defined in RFC 9083. There is no implied relationship between
opaque versioning identifiers, so that may be something that can be
considered in draft-ietf-regext-rdap-versioning, since “rdap_level_0”
and “rdap_level_1” are mutually exclusive and there needs to be a
default defined by the server that can be reflected in the versioning
extension. The help response with the
draft-ietf-regext-rdap-versioning extension does include information
associated with the default version, but that currently applies to the
“semantic” versioning and not the “opaque” versioning. Should
draft-ietf-regext-rdap-versioning support the concept of relationships
between opaque version identifiers with the ability to specific the
default opaque version identifier?
Sounds reasonable to me.
Mario
Thanks,
--
JG
cid87442*image001.png@01D960C5.C631DA40
*James Gould
*Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *"Andrew Newton (andy)" <a...@hxr.us>
*Date: *Thursday, October 3, 2024 at 6:49 AM
*To: *Mario Loffredo <mario.loffr...@iit.cnr.it>
*Cc: *Jasdip Singh <jasd...@arin.net>, "regext@ietf.org" <regext@ietf.org>
*Subject: *[EXTERNAL] [regext] Re: Questions about
draft-ietf-regext-rdap-x-media-type
*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.
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<mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it> 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
<https://secure-web.cisco.com/1Biz3y9d1L0MtBhR7x7VcPgOvi3xCOoSiCLCdUOBKAzznPxg03clNCXaBUqG4ETnekLEz6dIbrtXybtKJgsNa1h6d2eg9s-Ndr6NVj6IE2pV4DcleAKKuLtWs1ARZuSrgcP-ECPEM4QarlauSe1NbOLUnrUzsTcZSnp9b-A2RTbjVX00keplBfqzZkPMJAM_9UK7OriTSEFFki2BrNbqIJ9NXlZheGMofTebNtqrYA7KCTQ6hoIfERDmRCKO3qE8Lpsia9gVijfnavTwT22zqvaH8Ee5UajEdEdQlj5Ybdwc/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-ext-json-media-type%2Fissues%2F34>
[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.
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://secure-web.cisco.com/1Ksfok_U8L0V-qyrDnny0kt_R6FgFFh07q0P7rlEI4fBTOHweQZMdhWDDdN6l_YC6Js11KlbY6qqBtnhqNZvQd70GavbGqKFV26-BGQkLvZUzYj3B7_NBKbvdsGmpvrMJFRjFhhMN9jwdQPTcLbNOThUkk_UMR4mwCGI38kGUI9zGI2XMk7tLdCThp3gqZ2vCYdJJcTYAyCoP_uxcZ4POOQ3b5Tls6ZB1yW4lhnyyh1TSUQ6E6nIKL3k1_xBRbvV8X1wnstrvWYqxguemmD3DeDPqgEdBLeOP2HTTRBiEeK0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-04%23name-usage-in-query-parameters>
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#redirects_author
<https://secure-web.cisco.com/168GbDqas59dJjMIfk8sV62tXklstFvxOhdAFENgAWARVZtYAWDmV4kJFebTLT7O7WaTdt4ZuYklBiTdGOFJ5hqdYX7lDP7vv4yUYKgB7K3gtpOkgWttUo6WYmYuHlf9wejhYhPUf2_bgL_5Ipn50MIZY3fvUUmr3CzCHts46SsRs4JiG25B5_w9Ucla2yQiqj6vsDRx0tCI4lZugeCggk8EjK1mFwDMHviPWEN4JnF0B1tBT7MitQlGgxY_F_WB3K1b6qJsYSr2cEiX3GMMkAzXAd987Y_OC0xnUAbxdjgw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-04%23redirects_author>
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#referrals
<https://secure-web.cisco.com/1hDagMA8Pu80u2509Tv5lvubP8DNLtqpJONTCcFzXsI0KnkfIkFvqw9ANahoSM_nIxlSqK7QsyMY0mXJ3mmjMJA0s5jMnG4gT8hKIl3jBC75Wu5PVahKMV3Yi0Otc-kxc2fk8lkT5VcCqrYi09Y2odIrBbr1uEUuZQwjWKUw8dgO0NF0cCtQCTSGAnkVybp9Z0YVY-E6qmPyMae8AoGjW7eyOO73Z1UU-Q9R1Ntp9s3oEUEqS2ZzyeRcEXoOBz9vvW9L0DQVQanWfhxLY2zlbGXNJ0bAwEpux23lhVFffMuQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-04%23referrals>
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#security_considerations
<https://secure-web.cisco.com/1iALX3UEgJfUK9FmyEJTBKQVSzqoJ2JS5XwSx4PaRQbmkNsB6m0ZjKEHT6KWLUz1Tp2XIREEGsjILsn_bPBljg44FdnVF76sisrB2XUviuTvkfkPxMV9bj_fj0f3uoXus_q4J7YBa6SGlqi4eG8oNiS7iMZi1S4cCvUzoo7vdLqjlqboL-TiWbjkNDEzXLK-EnueZ2Tyx_0Uj5F5_km5f7e07S4rw2ZhWo8Zm3S_ISeigICYihN9v_vnfoC0WJLv3zdE5XmbgiMfSe54yk1KtrrATUNWZ5GmsRekCE58nmus/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-04%23security_considerations>
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#privacy_considerations
<https://secure-web.cisco.com/1aSFlWcK_cjZhhOLxQLJXHyUlOiQrZaL4S1jQ1ujl_QhvvoAA5fBWn7IVP90kWwEebvo0oZkDjVIh112jdWqOJ9kr3a4aaQC7YYgqX0hwEDofee2w1eKF6CzMlj6D1skXlP2T32tzz1hm7fChhRXDaBSUJWoh9bLp44bK90gsMIJpHHTw1qW6MDYuSc1l2qK3cV2_FfchaDm4wCZ1Ls-ACEJvhkbRRpmqbSp5iJFikDR02Nx7LITTMbutl5yuhc3IVL_Djrgi4lHvjRnCOCNx3syEj4lgPVsmDgfmblKlzRs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions-04%23privacy_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
<https://secure-web.cisco.com/1kXaUQGAgUFxwIx8Ifcmh6DLsviX70IEV7HT5J3Ab2GuvlTHc58-jmQ-4fbvXVl5oe2B0GLv42z6O4-RHNy7gf7gkrnBL4ugvWKzN4GNaOPgtXwfioiyW2JNh5tkL3LfH2jD_2doNFtyojo0-p3tQK-YKGHywKKsUgR-psn3Seo02S6O8WtCSaECs1RSzlzKWPWd7UTBsZVwGimdR8JGfUd0QPURzQ_nS6HkZ9O_2z4RZLaTFy3ReILcx_NfDyBHULhEDrfn18NksyI1alPo-bRvgUnobBRf_bIeIsbkDTQs/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-ext-json-media-type%2Fissues%2F30>
However, the text should stand as it notes the issues of using query
parameters in some situations.
-andy
--
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
