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*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
