Jasdip,
The purpose of the extensions draft was to provide clarification of STD 95 and
not to define new approaches that overlap and/or conflict with the versioning
draft. I have the following questions related to the transition approaches
outlined in the extensions draft:
1. Can an extension follow a different approach from one of the approaches
presented in section 5.4? In other words, will there be compliance discussion
for a new extension that describes a different approach than one included in
section 5.4 of the extensions draft?
2. Can the versioning draft not require a change to the extension identifier
for what is considered a breaking change in the extensions draft? Will there
be a compliance discussion with the extensions draft that when an extension
identifier doesn’t change with a breaking change?
3. Does a breaking change in an extension draft require a change in the
extension identifier as well (example “example1”, “example2”, …, “exampleN”),
where the last extension identifier defined will be included in the RFC?
4. Will the extensions draft look to add additional transition approaches?
* At a minimum, one approach that needs to be added is Server Default
with Client Override (name could be different) that has the server implement a
single default version of an extension with the capability for the client to
choose a different supported version (e.g., new version is onboarded by keeping
the old version the default and enabling early adopters to choose the new
version, then the new version becomes the default with the old version is
available for lagger adopters, and finally the old version is removed).
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/>
From: Jasdip Singh <[email protected]>
Date: Saturday, June 20, 2026 at 8:33 AM
To: James Gould <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
Subject: [EXTERNAL] Re: [regext] Re: Extension Versioning Location Information
and What Changes the Version Options
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,
IMHO, the key evaluation criterion for the WG should be whether the extensions
draft would be useful guidance wrt the current STD 95 for extension authors, in
absence of any new versioning proposal.
I believe that’s what Andy and Pawel have tried suggesting. Also, Scott through
his simple “draft” extension id idea for the draft-authoring use case.
Thanks,
Jasdip
From: Gould, James <[email protected]>
Date: Friday, June 19, 2026 at 6:03 PM
To: [email protected] <[email protected]>;
[email protected] <[email protected]>
Subject: [regext] Re: Extension Versioning Location Information and What
Changes the Version Options
PK> I didn't say draft-ietf-regext-rdap-versioning is not compliant with STD 95
as such. I only say that draft-ietf-regext-rdap-versioning shall not cross
boundaries of what STD 95 tells. At the point where this draft is suggesting
breaking change in the extension without corresponding update to the extension
identifier, then the line would be crossed.
What line are your referring to in STD 95? I don’t see any reference to
breaking changes in STD 95 and draft-ietf-regext-rdap-extensions states the
following, as it relates to the extension identifier:
Section 2.1: “The main purpose of the extension identifier is to act as a
namespace, preventing collisions between elements from different extensions.”
Section 5.4: “As stated in Section
2.1<https://secure-web.cisco.com/1eXAQUTQZrEy88F5blocWNWWF7UCeKpUbkmid_eNroevm5nhFovc-aWznN7CuGwzrZsXEDna_VzYha7VjfbmpijqxVxS6pJDB7GhLjSo_KxaA-Id-gc_wR0HynqoRk4UkYAjLF_0bYh7fB1Bo0sFeIkCJhZhpQhTOzMOHJLi4TuL4vOIusWII8-69uZYNKZ7K6CoUJrMliI_PY7hZ2tLZfWxHlPcbBExHjVb18x-h3Z-8gCtD_RHMdg65OEw1_IsJo6NAXQoPN0S4g2ZrDzXo6ZnBe0ffXEmO2vJ608E_3VA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-extensions%23purpose>,
RDAP extension identifiers and RDAP conformance strings are opaque, and they
possess no explicit version despite the fact that some extension identifiers
include trailing numbers.”
I don’t believe the version signaling should only be related to breaking
changes, since the version defines the interface (query and response) of the
extension. A client should not be required to hunt and peck to determine
whether a server supports a specific interface of an extension that doesn’t
happen to have a breaking change. I don’t have an issue with the RDAP
extensions using Opaque Version to only signal breaking changes, but I do have
an issue requiring RDAP extensions using the Point Versioning to be required to
change the extension identifier for a breaking change when the dependent
versioning extension provides versioning of all interface changes.
The versioning extension supports both Opaque Versioning and Point Versioning,
along with extensibility of future versioning types. If someone feels that
Embedded Versioning is a better form of versioning, then it can be formally
defined in a specification, where new RDAP extensions using the new versioning
type can include a normative reference to it for onboarding, just like what
will be done for the Point Versioning type. Each versioning type will be
registered in the RDAP JSON Values Registry with the “versioning” type for
traceability. This way we have backward compatibility and provide for
extensibility of versioning based on operational experience. There is no
intention to require any existing RDAP extensions to have to be modified
because of the versioning extension, but we have the intention of providing an
option for new RDAP extensions to be capable of signaling all interface changes
and to provide the option for clients to choose which interface they want to
use. This can be used with the deployment of proprietary RDAP extensions, IETF
draft RDAP extensions, and IETF RFC RDAP extensions for interoperability either
by manual means (e.g., many execute the /help of a target server) or by
automated means (e.g., scheduled or executing /help of a target server when the
client notices an versioning issue).
Thanks,
--
JG
[cid87442*[email protected]]
James Gould
Fellow Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://secure-web.cisco.com/101b_HwyYdJLbyZnQjcjhnomKcR21XHGeBeVnuqs2yENyz9bAUsr5Jp_1fLZpDcdz9JdUllNPI39zIEz5UGtKOhcZ5dgAwAnAeC1GJpY-8Ab5K3bESX_m68YL528azCzjs1juxiJLC4n1y2eXOdzHjEdYteU2akPlq646ukiRk3voWrTGL59LXsFLWXacTxsL03CuflevBaEakm8Bo4PN20vu30J-70Gc_nLBhd7lcuMtfV9CdoLjfWuPKOj0qICxSIvM6JP4ANb8L1GD2RptKvvg3e6z2YLjrgNHXKpbJGM/http%3A%2F%2Fverisigninc.com%2F>
From: Pawel Kowalik <[email protected]>
Date: Friday, June 19, 2026 at 2:33 PM
To: James Gould <[email protected]>, "[email protected]" <[email protected]>
Subject: [EXTERNAL] Re: [regext] Re: Extension Versioning Location Information
and What Changes the Version Options
Hi Jim,
On 19.06.26 17:44, Gould, James wrote:
Pawel,
Thank you for your preferences and reasoning. Can others of the working group
weigh in on the options?
I don’t remember you raising an RFC 9083 compliance issue with the extension
approach proposed by draft-ietf-regext-rdap-versioning, which is an optional
extension and any RDAP extension supporting point versioning in
draft-ietf-regext-rdap-versioning will include a normative reference to it.
Can you please clarify what language in RFC 9083 represents a compliance issue
for draft-ietf-regext-rdap-versioning?
PK> I didn't say draft-ietf-regext-rdap-versioning is not compliant with STD 95
as such. I only say that draft-ietf-regext-rdap-versioning shall not cross
boundaries of what STD 95 tells. At the point where this draft is suggesting
breaking change in the extension without corresponding update to the extension
identifier, then the line would be crossed.
As the matter of fact however, once this draft evolved to Point Versioning
there is a clear indication in 4.2 that back compatibility is not of a concern
of this versioning model. In this case I don't even see any conflict or
contradiction with draft-ietf-regext-rdap-extensions. On the flip side the
utility of this method to signal anything about compatibility vanished.
We did agree at IETF 121 that the extensions draft shall go through first, but
that was before the extensions draft expanded the Extension Versioning section
to include concrete proposals that is in scope for
draft-ietf-regext-rdap-versioning. The extensions draft was meant to clarify
the confusion in the base RFCs, which Section 5.4 without the sub-sections
does. This really becomes a scoping question for the working group, where
draft-ietf-regext-rdap-versioning existed first
(draft-gould-regext-rdap-versioning-00 published in November 2022) to add the
missing functionality for RDAP versioning, and then followed
draft-ietf-regext-rdap-extensions (draft-newton-regext-rdap-extensions-00
published in June 2023), and draft-ietf-regext-rdap-x-media-type
(draft-newton-regext-rdap-x-media-type-00 published May 2023). All three
drafts were adopted by the working group in February 2024 with agreement to
support them (Mario Loffredo is the document shepherd of
draft-ietf-regext-rdap-x-media-type and Jasdip Singh is the Document Shepherd
of draft-ietf-regext-rdap-versioning). What has progressed since then is the
draft-ietf-regext-rdap-versioning adding full support for Opaque Versioning and
revising Semantic Versioning to now Point Versioning based on feedback from the
working group. There have been issues raised on the mailing list related to
incompatibilities between the three drafts that has not been addressed. Below
are some messages on the mailing lists for reference:
PK> I don't have anything to add on top of what Andy wrote already.
Kind Regards,
Pawel
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
