[rfc-i] Problems and requirements for RFC Format

[SM]

At 14:13 17-04-2012, Heather Flanagan (RFC Series Editor) wrote:
>whether or not I've captured consensus on the problem space.  Note that
>I'm avoiding formal use of MUST and SHOULD right now, though I have
>tried to indicate level of requirement as I understand it so far.

MUST and SHOULD are only relevant for the stream that uses the 
Standards Track.  Should the RFC Editor elect to be on the Stinkards 
Track, it side-steps such a level of formality.

 From some old RFC:

   There is a tendency to view a written statement as ipso facto
   authoritative, and we hope to promote the exchange and discussion of
   considerably less than authoritative ideas.  Second, there is a natural
   hesitancy to publish something unpolished, and we hope to ease this
   inhibition."

Nowadays, there is what some people refer to as the RFC Format.  Here 
are some nits:

    1.  Document should match .txt file as closely as possible in
        structure, format, and content.

    2.  Standard page size is 8 1/2 by 11 inches.

    3.  Leave a margin of 1 inch on all sides (top, bottom, left, and
        right).

    4.  Text should have a point size 10 points with a line spacing
        of 12 points.

    5.  Three fonts are acceptable: Helvetica, Times Roman, and Courier,
        plus their bold-face and italic versions.

    6.  Prepare diagrams and images based on lowest common denominator.

The average reader may be able to understand how to do the 
above.  Nit 2 has been an issue since a long time.  I don't recall 
anyone complaining about it.

The following is the checklist:

  1. No text beyond the 72nd column of a line. This is especially important
     for diagrams and code, which the RFC Editor may not be able to trivially
     reformat to fall within the margins.

  2. Must be ragged right

  3. No hyphenation for line-breaks. However, hyphenated words (e.g.,
    "Internet-Draft") may be split at the hyphen across successive lines.

  4. No footnotes

  5. ASCII-only, no control characters (other than CR, NL and FF).

  6. Do not number the "Status of Memo" or "Abstract" sections

  7. Reasonably well formatted for readibility and clarity

People complain about point 1 and point 5.  My guess is that most 
people complaining about point 1 are not accessing the authoritative 
version of the document.  A quick look at 
http://www.ietf.org/about/standards-process.html does not contradict that.

Some of the categories of activity of the RFC Editor are:

   (a) Editing, processing, and publication of documents.

   (b) Archiving and indexing the documents and making them accessible.

   (c) Series rules and guideline

Document Lifecycle falls item (a).  There are valid concerns about 
that and it is fine to offer people the space to talk about it.  "It 
is not from the benevolence of the butcher, the brewer, or the baker, 
that we expect our dinner, but from their regard to their own 
interest". Is it in the interest of the RFC Editor to tackle (a) now 
instead of (b) and (c)?  Item (a) has more visibility.

Regards,
-sm