[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt
John C Klensin
john-ietf at jck.com
Mon Jun 23 09:28:56 PDT 2014
--On Friday, 20 Jun 2014 16:11:44 -0700, "Heather Flanagan (RFC
Series Editor)" <rse at rfc-editor.org> wrote...
> With the changes to the format for RFCs on the horizon, I've
> drafted a short document to describe the changes in the plain
> text output. Of course, the requirements described are not
> final until the community has discussed the proposal.
> Comments welcomed.
Since the IAB gave me a message that I could only interpret as
indicating that my experience and opinions on RFC Editor issues
are not wanted any more (and followed it up with a few similar
messages), I've been intermittently following this list but
staying silent. But the proposed changes to the traditional
ASCII text format seem to call for a comment, and one somewhat
stronger than Paul Kyzivat's Saturday one.
This draft seems to me to represent both a fairly fundamental
mistake and a breach of at least implicit agreements with the
community. I will try to be brief, but there is a great deal
to be concerned about in this document. The most important
issues seem to me to be:
(1) My understanding of the agreement with the community was
that the RFC Plain Text format was to be preserved, both for
historical reasons and to continue to support the members of the
community and other users of the series who are dependent on it.
Incompatible changes seem to call for a very long transition
period in which both traditional and new text formats are
available. This proposed new format is more or less what one
would get if one applied a "copy and paste to text" operation
on the HTML format. That is rather different unless the
assumption of the RSE and supporting committees is that
paginated text formats are so hopelessly obsolete that users of
them should be minimally accommodated and, by eliminating almost
all of the advantages of plain text, strongly encouraged to move
to HTML. That is, as Paul suggests, a big step.
(2) Despite some rumors about punched cards, the 72 character
line limit for RFCs was chosen to allow lines of 10 pitch text
to fit within the width limits of ANSI and ISO standards in
effect at the time for a common image area compatible with US
(8.5 x 11 inch) and A4 (21 x 29.7 cm) paper. 10 pitch was
chosen because it was (and is) available on almost all devices.
12 pitch is less commonly supported and other fixed character
width sizes much less so. I don't know where the proposed 88
character limit comes from, but note that it is wider than the
18.288 cm of the current format and exceeds the 7.2 or 7.25
inches usually recommended (I don't have a copy of ANSI INCITS
117-1984 (R2002), which seems to be the current version, but am
trying to track it down).
(3) As Paul's note suggests, for those of us who, for whatever
reason, work in page image formats, pagination (including page
header and footer information) is very important. It is
especially so for documents with many pages of tables (whether
in-line or in appendices) for which one might want to carry body
text or table text separately (draft-ietf-precis-framework and
RFC 3454 come immediately to mind, but there are many other
examples). As I have suggested before, if pagination is to be
abandoned (even for HTML and HTML-like documents), it is very
important to have a firm rule limiting the amount of text that
can appear in a single subsection or other index-able object.
(4) The many reasons why "text is required to be in UTF-8"
cannot, by itself, be an appropriate substitute for "text is
required to be in ASCII" have been extensively discussed
elsewhere and I will not try to repeat or summarize them here.
But this draft appears, at least in the absence of normative
references to other specifications, to make just that
(5) A significant change in the format of RFCs, especially the
plain text format, interacts with expectations about I-Ds. This
draft seems to me to cry out for an IESG statement about their
intentions wrt I-Ds will continue to track the RFC format with
minor exceptions and flexibility or whether the two formats will
diverge significantly. In particular, "normative XML" or "de
facto normative HTML" has very different implications for RFCs
(and pre-publication processing by the skilled RFC Editor stuff)
than it does for I-Ds and the many tools that have historically
been used to prepare them.
Back to lurking, I hope.
More information about the rfc-interest