[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

Dave Crocker dhc at dcrocker.net
Tue Jun 24 11:59:07 PDT 2014

On 6/20/2014 4:11 PM, Heather Flanagan (RFC Series Editor) 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.

The best thing about this draft specification of changes for
plaintext is that it provides a clear vehicle for considering the future
role of plaintext RFCs.

The worst thing about the draft is that it does not really
explain/justify its choices, other than citing the pain of pagination.

While I've no doubt that consideration was given to preserving utility,
it's not at all clear that the consideration was careful enough.  As
shown by some of the comments posted so far, it appears that some rather
basic points of utility are now in question.

I strongly encourage formulated an issue tracker for the concerns being
raised and then working to resolve them through community discussion.
(Note the lack of suggesting 'consensus', since this is an RFC Editor
process.)  Resolution well (or poorly) might include something along the
lines of "concern heard and understood but cannot be resolved
comfortably, because..."

With 45 years of established  practice, even a simple mechanism will
tend to have developed subtle or complex usage patterns.

Enthusiasm for rich encoding and display formats can make the simplistic
text format seem pretty unappealing.  This essentially serves to
disenfranchises serious users of plaintext. Consequently it requires
some effort to develop clarity about the nature of the need for it.

If I've read the draft correctly, the changes are:

   *  Characters set changed from ASCII to UTF-8

   *  Line length increased to 85 (or is that only for art?)

   *  Page boundaries removed; hence Section numbers only.

   *  ASCII art essentially deprecated, in favor of external,
      graphics-based art.

I suggest that the abstract should summarize these changes, so there is
some useful information in the Abstract.


Character set /has/ had extensive discussion and the change is to use a
superset of the established usage, with the general view that support
for UTF-8 has become essentially universal. Hence, this seems a
lower-risk change, notably permitting continuation of current
ascii-based practice by any author wishing to stay there.

It's just plain(text) odd to specify a linelength for art that is
different from that for text. In addition it appears to be an arbitrary
number. Worse, it is likely to cause problems, for any display that has
text tailored so that a maximum text line consumes the screen (as, for
example, I do on my 7" tablet, to make things comfortably readable for
my older eyes.) So artwork will wrap and be unreadable.

A separate note commented on the problem created by removal of page
numbers, in truly text-based environments (where URLs cannot be used to
create a jump-to mechanism.)  This isn't a small point.  The draft needs
to attend to it.

One part of the attention probably should go do discussion of section
numbering and size of sections. Another part needs to attend to
text-based direct access in the absence of page numbers.

The ASCII-Art vs. graphics art situation is the more challenging, but I
suggest that it needs direct attention.

Having done the combination for RFC 5598 -- including a figure that is
complex enough to overwhelm the ascii art but look reasonable (IMO) as a
graphic, here's specific guidance I suggest:

   1. ASCII Art is required for all drafts that have artwork. In other
words, the base tool remains.

   2. Graphic art is optional and must be a finer-grained version of the
ascii art. That is, the information in graphic art must be a superset of
the information in the ascii art.

   3. Where there are two forms of art, the Ascii art must include a
citation to the external graphic art and include a statement that the
ascii art is offered as a 'summary' of the artwork (or similar language.)

Problems with #3 have been posted by others.  But I don't have a
suggestion for resolving it.


Dave Crocker
Brandenburg InternetWorking

More information about the rfc-interest mailing list