There has been a lot of discussion related to extension versioning on the
mailing list. To help define a path forward, I’ve provided a set of options
for the Location of Versioning Information (Opaque Versioning, Embedded
Versioning, Point Versioning) and What Changes the Version (Breaking Change,
Interface Change, Any Change) below for the working group to weigh in.
1. Location of Versioning Information
a. Entire Extension Identifier supported by Opaque Versioning – The only signal
of a change in interface is a change to the entire Extension Identifier with no
pre-defined embedded versioning scheme.
b.Embedded in Extension Identifier (New versioning type, such as Embedded
Versioning) – This type of versioning would formally define a versioning scheme
in the format of the Extension Identifier, where the ‘_’ can only be used as a
separator for the extension elements, so the scheme needs to leverage a
predefined alphanumeric format using snake case for word separators. One
option is to embed the major and minor values used in the Point Versioning into
the Extension Identifier, such as the following Extension Versioning
Identifier. An example would be “exampleExtV01V12”.
i.
embedded-version-identifier = name “V” major “V” minor ; Complies with "name"
ABNF rule from RFC 7480
ii. name =
ALPHA *( ALPHA / DIGIT) ; Subset of “name” ABNF rule from RFC 7480
iii. major
= 2DIGIT ; Numerically increasing value with a leading “0” when < 10
iv. minor =
2DIGIT ; Numerically increasing value with a leading “0” when < 10
c. Point Versioning (any versioning type that doesn’t include the versioning
directly in the Extension Identifier) – The versioning is additive to the
Extension Identifier, where the Extension Identifier acts as a namespace.
Extensions that support Point Versioning includes a dependency on the
implementation of the Versioning Extension for clients to be capable of knowing
the extension versions supported by the server and to indicate what extension
version it desires to use. The server supports a default version of each Point
Versioning Extension implemented with the capability for the client to override
the default using a query parameter or a media type parameter.
2. What Changes the Version
a. Breaking Change – The only requirement for changing the version is when the
successor extension makes a breaking change to the predecessor extension.
Learning new optional features in an implemented successor extension would need
to be communicated out-of-band.
b.Interface Change – Any interface change (breaking or non-breaking) changes
the version of the successor extension. A non-interface change in the
extension specification does not change the version, so therefore the mapping
of the extension specification to the version is embedded in the specification,
such as the use of the Extension Version Identifier section for Point
Versioning.
c. Any Change – Any change to the specification changes the version of the
successor extension. The scheme for the versioning can be based on the draft
versions, while considering the possible change in the extension names as well
as draft version numbers (e.g., proprietary example-ext changes to individual
draft draft-author-example-ext-01 changes to working group draft
draft-ietf-example-ext-00). Nit changes to a specification will result in a
version change.
Are there additional options that should be considered?
In thinking about the options, my preference continues to be “Point Versioning”
for the “Location of Versioning Information” and “Interface Change” for “What
Changes the Version”. This keeps the versioning information outside of the
Extension Identifier, since there are too many use cases for embedding the
versioning inside the Extension Identifier that is not well suited for the
“name” ABNF rule from RFC 7480. The versioning needs to support defining the
full interface of an extension so that clients don’t break when expecting an
older interface or when expecting a newer interface. The mapping of the
specification to the interface can be included directly in the specification,
such as including an “Extension Version Identifier” section, as done in
draft-ietf-regext-rdap-versioning (Section 6), draft-ietf-regext-rdap-jscontact
(Section 3.1.2), and draft-loffredo-regext-rdap-verified-contacts (Section 7).
There can be proprietary extensions, individual IETF draft extensions, working
group IETF drafts, and finally RFCs that don’t provide for a consistent naming
scheme that can be used in the Extension Identifier.
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]
