[rfc-i] Text no longer definitive (was Re: Proposed way forwards on backward compatibility with v2)
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Tue Feb 18 10:34:12 PST 2014
On 2/18/14 9:41 AM, Dave Crocker wrote:
> On 2/18/2014 9:27 AM, Julian Reschke wrote:
>> The ASCII art will be just a fallback and not be normative.
> This points to a fundamental policy change by the RFC Editor that I missed:
> The text version of an RFC will no longer
> be treated as the definitive version.
> It might well have been an implication of the other decisions made an
> stated -- AND I'm not seeking to open a debate about whether it's a good
> Rather, I want to make sure that this is a clear and accurate statement
> of a specific policy change, since it's such a major change.
One of the most challenging aspects of the creation of RFC 6949 was
getting to a common terminology describing the different aspects of
format. Two terms you will not find there are "definitive" and
"normative". I would rather not rehash the terminology debates that led
to us away from those words.
The canonical format will be XML. There will be, to start, 3-4
publication formats rendered from that XML. Text is one of those; it
will not be the canonical version for RFCs published after the format
change. It will remain the canonical format for RFCs published before
the change in format happens.
Other major publishers and some SDOs publish their documents in more
than one format. If we receive a subpoena asking us for an RFC that has
more than one publication format, I expect we will have a conversation
(pre-scripted) that explains what is available. This is not new or
unusual for the publishing industry.
Regarding artwork, ASCII or otherwise, the debate as to whether it
should be normative in an IETF sense is ongoing. The last time I beat
my head against that particular wall, I believe the end result was that
we (the RFC Editor and the IESG) would encourage the use of artwork as
informative only, but recognize that artwork sometimes must be normative
to a spec.
More information about the rfc-interest