‘When I use a word,’ Humpty Dumpty said in rather a scornful tone, ‘it means just what I choose it to mean — neither more nor less.’
’The question is,’ said Alice, ‘whether you can make words mean so many different things.’
’The question is,’ said Humpty Dumpty, ‘which is to be master — that’s all.
Lewis Carroll, Through the Looking Glass
A discussion is currently underway within the IETF about the status of RFCs. This discussion focuses on the integrity of the documents’ meanings, rather than their standing in relation to other documents, rules, or laws. What does it mean when a given RFC changes the words in the specification? Has the specification changed?
This discussion is significant because there has long been a belief that once an RFC is published, it is considered ‘immutable’ and not subject to change. If a substantive change is needed, rather than altering the existing RFC, a new RFC is issued to revise, deprecate, and replace the old one.
In practice, RFCs have been more prone to change than commonly believed. There has always been an editorial function behind the series, allowing for corrections. For instance, if a typo or misspelling that didn’t alter the intent of the document but was considered ‘ugly’ was detected, it could be corrected with a note to the editor.
In later years, the process became much more formalized, involving lodgement, queueing, review, acceptance (or rejection), and an audit trail. This change allowed for more meaningful modifications. If a mistake in drafting compromised the intent of an RFC, the document could be amended to clarify its intent. However, this process was not used recklessly, and for significant changes, a new RFC was usually required. For most RFCs, the literal text on the web or in an archive was often considered ‘the one’ but sometimes, which one was the one was less defined.
The new process reflects ongoing long-standing change in how an RFC is produced, and what is held to be the definitive text behind an RFC. Because the RFC series is now routinely available in multiple forms such as plain text, XML, HTML, and PDF, all of which are now held to derive from the XML, there are possibilities for disagreement from rendering or production issues as well as in-flow semantic mistakes. This means that ‘the one’ concept may not easily apply since people can have different representations of the same underlying document. Which ‘one’ did you fetch? When did you get it?
This draft formalizes the current reality that an RFC cannot be considered immutable as it appears on the web or in some archive. Instead, it should be understood as a structural statement that can change without requiring a new RFC number.
After extensive experience with publishing RFCs in the RFCXML format
[RFC7991], it has been decided that an RFC's XML file can be updated
for narrowly limited purposes. This document changes [RFC7990] in
significant ways:
* It defines four terms that replace the use of the term "canonical"
and clarifies "format":
- The "definitive format", which is RFCXML
- The "definitive version", which is a published RFC in the
definitive format
- A "publication format", which is currently one of PDF, plain
text, or HTML
- A "publication version", which is a published RFC in one of the
publication formats
* It defines a policy governing how the RFCXML format changes.
* It defines a policy for when the definitive version of an RFC can
be updated and older versions archived.
* It defines a policy for when the publication versions of an RFC
can be updated and older versions archived.
The principal change is the replacement of the term ‘canonical’ (an unexpected choice given its origins in religious dogma rather than technical standards) with ‘definitive’. Additionally, a set of definitional terms related to RFC production has been refined and specified for use in this context.
If an RFC needs to change due to an effect it has on the protocol space, or for structural representation of information ‘on the wire’ between communicating entities, then the requirement to publish a new RFC (or a -bis document, from the French for ‘again’ or ‘second’, and -ter for a third revision) is clearer.
Altering the real-world outcomes of an RFC without undermining the concept of an RFC specification isn’t possible. Changes that make it easier to conform to a specification are worth making inside an RFC as it stands (keeping the same number). However, changes that impact the outside world require consensus approval and a new RFC number.
The least useful outcome would be allowing changes to the meaning and intent behind an RFC, to reverse a normative MUST, or to change bit patterns on the wire without notice. ‘Words mean precisely what I want them to mean’ isn’t a good basis for writing standards.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Thanks for drawing attention to this discussion