Speaking as co-Chair:
Thank you Jim for these detailed comments.
For the working group, the question that will be before us in the
discussion on Wednesday, which was also before us at IETF119, is what
problem are we trying to solve? The second order question, which was
also before us at IETF119, is what is the relationship between these
documents. Jim’s note is a pretty deep consideration of that second
question.
Please come prepared on Wednesday to discuss the first question. There
will be Chair slides later today with more details.
Thanks,
Jim
co-Chair REGEXT
On 22 Jul 2024, at 7:59, Gould, James wrote:
Hi,
I did a detailed review of the three drafts
draft-ietf-regext-rdap-versioning,
draft-ietf-regext-rdap-x-media-type, and
draft-ietf-regext-rdap-extensions for alignment. The following are my
findings:
1. draft-ietf-regext-rdap-versioning includes support for
draft-ietf-regext-rdap-x-media-type and the “versioning” query
parameter for the client to provide a hint of the extension versions
to include in the RDAP query and RDAP response. The server MUST
support both methods and the client MUST include a single method in
the RDAP query to ensure that there are no conflicts. This ensures
that clients can specify the extension versions via a query parameter
and via an HTTP header per draft-ietf-regext-rdap-x-media-type.
2. draft-ietf-regext-rdap-x-media-type could be merged into
draft-ietf-regext-rdap-versioning, since it now represents one method
of an Extension Versioning Request.
* An alternative is for draft-ietf-regext-rdap-x-media-type to
support a more generic form of query parameters for use in any RDAP
extension.
* The extension can stay separate if there is some advantage.
3. draft-ietf-regext-rdap-versioning defines a Extension Version
Identifier in section 3.1
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning#name-extension-version-identifie
as:
* ABNF
i.
extension-version-identifier = identifier versioning
ii.
identifier = ALPHA *( ALPHA / DIGIT / "_") ; Extension Identifer
iii.
versioning = ["-" 1*VCHAR]
* draft-ietf-regext-rdap-x-media-type needs to also support the
extension-version-identifier to use it with
draft-ietf-regext-rdap-versioning, which currently uses the language:
i.
“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.”
* How about making this more generic to support
additional types of extension versioning schemes, such as the
language:
* “This media type has a parameter of "extensions"
which is a whitespace-separated list of RDAP extensions, such as
defined in the IANA RDAP Extensions registry.”
i.
Use of the IANA RDAP Extensions registry will support Opaque
Versioning in draft-ietf-regext-rdap-versioning, where use of “such
as” will allow for additional RDAP extensions schemes.
ii.
“the values in the media type's extension parameter SHOULD match the
values in the rdapConformance array in the return JSON.”
* The Extension Version Identifier does include the
extension identifier, so the question is whether inclusion of the
versioning suffix will meet the “match the values in the
rdapConformance array”.
* How about making this more specific to directly
reference the version identifiers, which would work better with
draft-ietf-regext-rdap-versioning:
* “the extension identifier values in the media
type's extension parameter SHOULD match the values in the
rdapConformance array in the return JSON.”
* “though clients SHOULD list the extension identifier
in the extensions parameter when using other protocol elements of
those extensions. Servers SHOULD NOT require the usage of extension
identifiers in the extensions paramater when other extension protocol
elements are used.
* To support draft-ietf-regext-rdap-versioning, this
could be modified as:
i.
“though clients SHOULD list the extension identifier in the
extensions parameter when using other protocol elements of those
extensions. Servers SHOULD NOT require the usage of extensions
identifiers in the extensions parameter when other extension protocol
elements are used”
ii.
Referencing extension instead of extension identifier would be
more generic to support the Extension Version Identifier.
iii.
Nit – replace “paramater” with “parameter”
1. draft-ietf-regext-rdap-x-media-type Security Considerations
parameter below may be best to address in
draft-ietf-regext-rdap-versioning and even more generically in
draft-ietf-regext-rdap-extensions
* “This specification does contrast with solutions using
query parameters in that those solutions require servers to blindly
copy query parameters into redirect URLs in situations where such
copying could cause harm, such as copying an API key intended for one
server into the redirect URL of another server.”
2. draft-ietf-regext-rdap-x-media-type B.2 “Query Parameters
Considered Harmful” could be moved to
draft-ietf-regext-rdap-extensions, since query parameters are used in
many places in RDAP, so providing clear guidance when a query
parameter should or should not be used would be useful in
draft-ietf-regext-rdap-extensions. I don’t believe query parameters
are “harmful” but has a disadvantage in the use cases presented.
The query parameter has the advantage of being a simple approach for
clients to provide their hint when directly interfacing with the
server. In re-reviewing draft-ietf-regext-rdap-extensions it does
look like section 12 “Redirects” includes some guidance related to
query parameters, where I believe it would be beneficial to have a
separate query parameter section in draft-ietf-regext-rdap-extensions.
3. draft-ietf-regext-rdap-x-media-type B.2.4 “Architectural
Violations” and B.3 “RDAP Extension Versioning” could be
removed, since I don’t see how the use of a query parameter in RDAP
would be considered an architectural violation and RDAP Extension
Versioning will be worked on in parallel in
draft-ietf-regext-rdap-versioning.
4. draft-ietf-regext-rdap-versioning
* In section 8 “Extension Versioning”, I just want to
confirm that draft-ietf-regext-rdap-versioning address the normative
language and if not what needs to be added:
i.
“If a future RFC defines a versioning scheme (such as using the
mechanims defined in section Section
2<https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions#extension_identifier>
), an RDAP extension definition MUST explicitly denote this
compliance.”
* Section 8.1 “Backwards-Compatible Changes”
i.
This section may not be needed with draft-ietf-regext-rdap-versioning,
since the set of supported extension versions are explicitly
specified, where in the case of Opaque Versioning the server could
support many versions of the extension.
* Section 8.2 “Backwards-Incompatible Changes”
i.
IT would be helpful to include the reference to
draft-ietf-regext-rdap-versioning as an option to consider in
signaling support for more than one version of an extension.
* Section 9 “Extension Identifiers in a Response”
i.
You can update the reference of [I-D.gould-regext-rdap-versioning] to
be [I-D.draft-ietf-regext-rdap-versioning].
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/>
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
