Andy,
Thank you for posting draft-ietf-regext-rdap-extensions-15 that incorporates my
feedback. I include my feedback to draft-ietf-regext-rdap-extensions-14 below
with comments prefixed with "JG15-" to indicate what has been addressed in
draft-ietf-regext-rdap-extensions-15 to help the document shepherd.
All the feedback has been addressed except for the strategies in the section
5.4.3 "Considerations for Superseders" that need to be defined as
non-exhaustive at a minimum and what makes a strategy compatible with STD95
needs to be documented. Both strategies in the draft are new and have no
operational experience to reference for inclusion in the extensions draft. I
consider the "Overlapping Superseders" strategy as bad design for extension
authors by creating a hard inheritance dependency from an extension successor
to its predecessor.
Section 2.2 “Syntax”:
OLD
Similarly, RDAP extensions MUST NOT define an extension identifier starting
with a substring being an existing extension identifier appended with an
underscore.
NEW
Similarly, RDAP extensions MUST NOT define an extension identifier starting
with a substring of an existing extension identifier appended with an
underscore.
JG15-Addressed
I recommend injecting some of Section 2.3 “Bare Extension Identifiers” into
Section 2.2 and formally defining the ABNF for an RDAP extension identifier,
which revises the “name” ABNF rule defined in Section 6 of [RFC 7480] and
formally defines the RDAP extension (variable / element / parameter) ABNF. A
good name needs to be given to the RDAP extension elements that use the RDAP
extension identifier as a prefix.
OLD
For this reason, this document updates the guidance of [RFC7480] regarding
underscore characters: RDAP extensions MUST NOT use an underscore character in
their RDAP extension identifier. Implementers should be aware that many
existing extension identifiers do contain underscore characters.
NEW
This document updates the ABNF “name” rule in [RFC7480] to not allow the use of
an underscore character in the RDAP extension identifier. The revised ABNF
[RFC5234] “name” rule is:
name = ALPHA *( ALPHA / DIGIT )
Implementers should be aware that existing extension identifiers do contain
underscore characters.
JG15-Addressed
Added at the end of section 2.2 that following to replace Section 2.3 “Bare
Extension Identifiers”:
NEW (Replaces Section 2.3 “Bare Extension Identifiers”)
The [RFC 7480] ABNF “name” rule referenced JSON Names, where there was no
requirement to include the suffix for JSON members, and Section 2.1 of [RFC
9083] included the language “JSON responses SHOULD have member names prefixed
with a short identifier followed by an underscore followed by a meaningful
name”. This contradiction led to the use of a Bare Extension Identifier, where
a JSON member uses the extension identifier without the use of an underscore
followed by a meaningful name. That is, the extension identifier is used
"bare" and not appended with an underscore character and subsequent names.
Consider the example in Section 2.5.2. Using the bare extension identifier
pattern, that example could be written as:
{
"rdapConformance": [
"rdap_level_0",
"exampleExt"
],
"objectClassName": "domain",
"ldhName": "example.com",
"remarks":
[
{
"description":
[
"Query the database."
"JSON replaces the Whois."
"Structured data flows."
]
}
],
"exampleExt":
{
"firstInitial": "R",
"lastName": "SomePerson"
}
}
While [RFC9083] is specific to JSON, the use of a bare extension identifier
also applies to other identifiers of RDAP extensions, such as query parameters
and object class names. Identifiers of an RDAP extension which need a prefix to
avoid name collision with identifiers of other RDAP extensions or RDAP as
specified in [RFC7480], [RFC9082], and [RFC9083] are referred to as namespaced
identifiers. prefixed identifiers are clearly syntactically distinguishable
from identifiers defined by the core RDAP specifications, which provides more
flexibility to implementers and helps with debugging and similar.
The syntax for extension elements (JSON member, query parameters, object class
name, HTTP headers, path segments, media type parameter, etc.) is defined by
the “extension-element” ABNF rule:
extension-element = name “_” ALPHA *( ALPHA / DIGIT / “_” )
Implementers should be aware that existing extension elements use Bare
Extension Identifiers.
JG15-Addressed
Section 2.3 “Bare Extension Identifiers”:
I recommend moving into Section 2.2 “Syntax” as described above, since the
formal definition of the extension-element ABNF rule cleanly defines what
designers need to use going forward in place of defining what designers must
not do.
JG15-Addressed
Section 2.5.1 “Basic Requirements”
I don’t recommend mirroring the “harshMistressNotes” with the “In space,”,
“nobody can hear you scream” example from RFC 9083 in
draft-ietf-regext-rdap-extensions, even though I believe it’s a reference to
the book “The Moon is a Harsh Mistress”. I recommend neutralizing the example
in draft-ietf-regext-rdap-extensions. Replicating the RFC 9083 is not needed
and providing the required use of the “rdapConformance” could be provided alone
with a neutralized example:
OLD
[RFC9083] states: Clients of these JSON responses SHOULD ignore unrecognized
JSON members in responses.
This document updates this guidance…
NEW
[RFC9083] states: Clients of these JSON responses SHOULD ignore unrecognized
JSON members in responses.
As Section 4.1 of [RFC9083] requires the use of the "rdapConformance" data
structure, and the "objectClassName" string is required of all object class
instances, the complete example from [RFC9083] would be with a change the last
“lunarNIC” member:
{
"rdapConformance": [
"rdap_level_0",
"lunarNIC"
],
"objectClassName": "domain",
"handle": "ABC123",
"ldhName": "example.com",
"lunarNIC_beforeOneSmallStep": "TRUE THAT!",
"remarks":
[
{
"description":
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"lunarNIC_spaceNotes":
[
"In space,",
"nobody can hear you."
]
JG15-Addressed
Section 2.5.5 “rdapConformance Population”
Nit – I recommend naming the Section 2.1.1 extension identifiers for clarity,
so readers don’t need to follow the reference to determine the type of
extension being referenced. It’s not perfectly clear whether the
OLD
A strict interpretation of this wording where “construction of the response”
refers only to the JSON structure would rule out the use of Section 2.1.1
extension identifiers
NEW
A strict interpretation of this wording where “construction of the response”
refers only to the JSON structure would rule out the use of profile extension
identifiers [Section 2.1.1]
JG15-Addressed
It’s not clear from the guidance whether the profile extension identifiers are
expected to be returned in the response, which I believe they should based on
“understand the semantic meaning of the content within the JSON”. I recommend
making this explicit, since the profile extension identifiers were raised as an
interpretation issue with:
OLD
…a response MUST include in the "rdapConformance" array only those extension
identifiers necessary for a client to deserialize the JSON and understand the
semantic meaning of the content within the JSON, and each extension identifier
MUST be free from conflict with the other identifiers with respect to their
syntax and semantics.
NEW
…a response MUST include in the "rdapConformance" array only those extension
identifiers necessary for a client to deserialize the JSON and understand the
semantic meaning of the content within the JSON, which includes the profile
extension identifiers. Each extension identifier MUST be free from conflict
with the other identifiers with respect to their syntax and semantics.
JG15-Addressed
Section 5.3 “Extensions Referencing Other Extensions”
Nit – I recommend naming the Section 2.1.1 extension identifiers for clarity.
OLD
As stated in Section 2.1.1, ….
NEW
As stated for profile extensions [Section 2.1.1], …
JG15-Addressed
Should there be guidance to include a normative reference in a dependent
extension to the other extension for clarity to the client and server that
there is a dependent relationship between the two extensions? This could go
further by including language in the extension defining the dependent
relationship explicitly.
OLD
…extensions may rely on other extensions by stipulating the usage of those
other extensions.
NEW
…extensions may rely on other extensions by stipulating the usage of those
other extensions. Dependencies between extensions MUST be defined using a
normative reference in the dependent extension and SHOULD include an explicit
description of the dependency.
JG15-Addressed and we agreed to change the SHOULD to a MUST.
Section 5.4 “Extension Versioning”
I like the formal definition of the terms “revision” and “replacement”. This
helps a great deal in clarifying the guidance.
The last paragraph references a 2011 blog post, MNOT-VERSIONING. This could be
perceived as a normative reference. As far as I can tell, the guidance from the
post was never included in an RFC, so I recommend removing the reference
entirely, to reduce confusion. The extensions draft should provide guidance
based on RDAP extension definition experience and operational experience. I
agree with “Backwards-compatible changes should be favored over incompatible
ones.”, but I don’t believe that “Newer versions of extensions are not to break
existing clients” is realistic based on the progression of RDAP extensions in
the working group. This would also require protocol designers to reliably
predict what client implementers will do, which is not possible.
RDAP is a stateless protocol and doesn’t have a predefined set of clients,
which may expect different versions of an RDAP extensions (old or new). RDAP
is defined to ensure that clients are resilient to change by requiring clients
to ignore unknown JSON names. Extension designers need to consider versioning
throughout the maturity of the extension, which includes determining when to
change the extension identifier and whether to use a versioning extension, or
its own versioning technique. Clients need to be aware of the extension
interface supported by the server, which can include breaking and non-breaking
changes. Below is my recommendation for the language in the draft.
OLD
Versioning of RDAP extensions is expected to follow the general principles
described in [MNOT-VERSIONING]:
* Newer versions of extensions are not to break existing clients.
* Backwards-compatible changes should be favored over incompatible ones
NEW
Versioning of RDAP extensions needs to be considered with the following goals:
* Backwards-compatible changes should be favored over incompatible ones
* Changes to the extension interface should be transparent to the client by
changing of the extension identifier (replacement above), use of a versioning
extension such as draft-ietf-regext-rdap-versioning, or defining versioning
directly into the extension.
JG15-Addressed by replacing the MNOT-VERSIONING reference with a paragraph
associated with interoperability and not policy. I'm good with the new
language.
Section 5.4.1 “Breaking Changes in Revisions”
In reviewing the list of breaking changes, I have the following feedback to the
list items:
“Contracting a set of values when that set is not defined in an IANA registry
to be found in a protocol element in a request” – Wouldn’t this be considered a
non-breaking change unless it was a value provided by the client in the query?
The client would support a superset of values, so the removal of one of the
values should not break a client expecting the old interface.
JG15-Not an issue.
Section 5.4.3 “Compatibility of Replacements”
I view this section as providing guidance or considerations to extension
implementers and designers for replacements (e.g., when an extension identifier
changes). I recommend using the term “Considerations” in the title to make it
clear the goal of the section.
OLD
Title: Compatibility of Replacements
NEW
Title: Extension Replacement Considerations
JG15-Addressed, by changing Compatibility of Replacements to Considerations for
Superseders
I like scoping the sub-sections of Section 5.4.3 with “replacements”, which as
when the extension identifier changes. We need to ensure that the strategies
are explicitly not considered. Considering that designers and implementers may
take different approaches that listed in the sub-sections, to clarify this I
would add the word “non-exhaustive” to the last sentence.
OLD
Strategies for using a replacement in a transition are described below.
NEW
The non-exhaustive list of considerations for using a replacement in a
transition are described below:
JG15-Not addressed, " Strategies for using a replacement in a transition are
described" was replaced with "Known strategies compatible with [RFC7480],
[RFC9082], and [RFC9083] below." It's unclear how these strategies are
"compatible" with STD95. The draft should define what makes a strategy
compatible with STD95 that we can match other strategies against. I requested
in our mailing list thread to add the strategy " Standalone Superseders with
Versioning", which I'm willing to provide the content for.
Section 5.4.3.1 “Non-overlapping Replacements”
This is certainly an option, but I haven’t seen an instance where this has been
implemented in new versions of an RDAP extension. I don’t have an issue
included this consideration if the sub-sections of 5.4.3 are defined as a
non-exhaustive list of considerations.
JG15-May have been addressed. The non-exhaustive language was not added to the
draft for the list of strategies, but the section does include the term
considerations. I want to confirm that if a strategy is used that does not
include one of these two strategies will be it considered non-compliant, since
I wouldn't recommend using these strategies based on my operational experience
of transitioning between EPP extension versions.
Section 5.4.3.2 “Overlapping Replacements”
I don’t support this consideration for the extension authors, since extension
replacements can have overlapping structures, but defining an inheritance
hierarchy between extension replacements does not allow for the extension
replacements to stand on their own. This will add a permanent inheritance
dependency between RDAP extensions that should be avoided.
The versioning extension did add relationship (“predecessor” and “successor”)
support between the extensions, where the server can define the supported set
of opaque extensions, their relationship, and when the extension will start and
end being supported. If the concept of “Overlapping Replacements” is supported
by the working group, then a relationship type will need to be added, such as
“inherited” in this case.
JG15-Not addressed. I don't support the "Overlapping Replacements" as a
strategy for extension authors. I have never seen an example of this for the
definition of a successor RDAP extension and I believe creating an inheritance
dependency between extension versions to be a bad design. Can other working
group members weigh in on this prior to including the strategy in the draft.
--
JG
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/>
On 8/13/26, 3:09 PM, "Andy Newton" <[email protected] <mailto:[email protected]>> wrote:
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.
Hi all,
This latest version take into account the conversations concerning this draft
before IETF 126,
the instructions from the chairs during the meeting at IETF 126,
and the most recent list discussions.
In those most recent discussions, I pushed back on the issue of the
MNOT-VERSIONING reference but in the end removed it anyway.
-andy, no hats
On 8/13/26 2:57 PM, [email protected] <mailto:[email protected]>
wrote:
> Internet-Draft draft-ietf-regext-rdap-extensions-15.txt is now available. It
> is a work item of the Registration Protocols Extensions (REGEXT) WG of the
> IETF.
>
> Title: RDAP Extensions
> Authors: Andy Newton
> Jasdip Singh
> Tom Harrison
> Name: draft-ietf-regext-rdap-extensions-15.txt
> Pages: 32
> Dates: 2026-08-13
>
> Abstract:
>
> This document describes and clarifies the usage of extensions in
> RDAP.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://secure-web.cisco.com/1ZESAWGT_97OMjca58tItvkXI8s3EDDab5ZWRrqRC9pIBRgjJym4IS10HFNEdEoAPg7uJhzB2ffyX7UiOoz89wVpCUZZqn_wxficUtXHrNW5-VXAo27wGvCw6auoqwCfJPMQdvTKZAMFOdWzb0QvQ4mtfmLqD8PGPHcSE3bpZJPM0x1hRzc6CmNAFjsxppnbc4jDI7J5ZVKDU-8KzpXfj6WrFXp7iWzwjY67t1jy8KdkWGDunMv4mGj4V-cn5DGvDvgBUf3CT3mDjy4AdiaCJSQkkdV9VResq38jE7TAxfG-7gclARUNuQHCk8JdsCQ2L/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F
>
> <https://secure-web.cisco.com/1ZESAWGT_97OMjca58tItvkXI8s3EDDab5ZWRrqRC9pIBRgjJym4IS10HFNEdEoAPg7uJhzB2ffyX7UiOoz89wVpCUZZqn_wxficUtXHrNW5-VXAo27wGvCw6auoqwCfJPMQdvTKZAMFOdWzb0QvQ4mtfmLqD8PGPHcSE3bpZJPM0x1hRzc6CmNAFjsxppnbc4jDI7J5ZVKDU-8KzpXfj6WrFXp7iWzwjY67t1jy8KdkWGDunMv4mGj4V-cn5DGvDvgBUf3CT3mDjy4AdiaCJSQkkdV9VResq38jE7TAxfG-7gclARUNuQHCk8JdsCQ2L/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F>
>
> There is also an HTML version available at:
> https://secure-web.cisco.com/1ebEM9onEz-Eqx4XIHm2pOwkRfNkjc4TgTcSWR1n_1vsZXBvVAU7L96yviKA-U2K4AZ2dUlnXWmqpej2xjUw72U01iANFO8Md7YD5ph4Ey6QhlFbM1PCULRkkC9WWcHEyb2MvIot35L3LcdzDAWrx1jWdLLmBFtzOQ0zTtsKRAezeex5CV8f3f5GvFKc_-dh4ZkaKayl5_8Rn5zdTZbi7W47IKC_71T6JPpCm5aNS4M-gQpb6G7grdH_UpIvD3ggyz0npakSbDSVeU4cpEgidE6zGS5Hlp2CCzu13P9LarSeKQNbl2pTjz-uYAGfICaGE/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-15.html
>
> <https://secure-web.cisco.com/1ebEM9onEz-Eqx4XIHm2pOwkRfNkjc4TgTcSWR1n_1vsZXBvVAU7L96yviKA-U2K4AZ2dUlnXWmqpej2xjUw72U01iANFO8Md7YD5ph4Ey6QhlFbM1PCULRkkC9WWcHEyb2MvIot35L3LcdzDAWrx1jWdLLmBFtzOQ0zTtsKRAezeex5CV8f3f5GvFKc_-dh4ZkaKayl5_8Rn5zdTZbi7W47IKC_71T6JPpCm5aNS4M-gQpb6G7grdH_UpIvD3ggyz0npakSbDSVeU4cpEgidE6zGS5Hlp2CCzu13P9LarSeKQNbl2pTjz-uYAGfICaGE/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-15.html>
>
> A diff from the previous version is available at:
> https://secure-web.cisco.com/19q6THm6kavl-oeMaKEG4edj6FBUY6A-6aX31zhLz23IFw1L32Opj0r7UMociT437Tuew1DtOELadfI_IXoKngbN3PVT-P-bF5DBaphCzL9UFuRgdhcBq6e7ZuubFtan-arWOPU9B3lJsYxHoBgzG9QqsV3qRaDeS_oeBDyoKJ62FC8xCgO-H5XErDRHHLHaodWaCE_KFOWC0ysTqClRxh_0grLVM_euFcjzzITIMpXW2YRtMuguFVTwbTeTn78Ajxgulnxnk0TY6ZQODunZCDUkAyFGxt8zlT38u9EhnK8KAX3U295DeBSiOy_PzxLLL/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-regext-rdap-extensions-15
>
> <https://secure-web.cisco.com/19q6THm6kavl-oeMaKEG4edj6FBUY6A-6aX31zhLz23IFw1L32Opj0r7UMociT437Tuew1DtOELadfI_IXoKngbN3PVT-P-bF5DBaphCzL9UFuRgdhcBq6e7ZuubFtan-arWOPU9B3lJsYxHoBgzG9QqsV3qRaDeS_oeBDyoKJ62FC8xCgO-H5XErDRHHLHaodWaCE_KFOWC0ysTqClRxh_0grLVM_euFcjzzITIMpXW2YRtMuguFVTwbTeTn78Ajxgulnxnk0TY6ZQODunZCDUkAyFGxt8zlT38u9EhnK8KAX3U295DeBSiOy_PzxLLL/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-regext-rdap-extensions-15>
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> regext mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
_______________________________________________
regext mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
