Re: Why the normative form of IETF Standards is ASCII

[John Levine <[e-mail]>]

>> PDF/A is a deliberately-limited format designed specifically for
>> archival purposes.
>
>And is clearly a non-starter because I have no idea how to produce PDF
>so limited, not idea how to test a PDF to see if its "PDF/A", etc.

There are certainly arguments against PDF/A, but this doesn't strike
me as a very strong one.  You know how to produce an ASCII I-D, which
looks somewhat like an RFC, but I doubt that you know how to produce
an RFC.  (I don't think anyone does other than the handful of people
who have actually done so, since the list of rules and formatting
twiddles for the RFC style is not perfectly documented.)  Were we to
adopt PDF/A as a format for RFCs, what would matter is that the RFC
production house knew how to create PDF/A files.  Document authors
would continue to send in I-Ds in whatever form they send them in,
with some extensions for figures and non-ASCII characters.

Indeed, I know plenty of people these days who have no idea today how
to produce an ASCII file with only tab, CR, and LF formatting
characters.  This does not mean they are morons, it means that the
text processing tools that people use today are different from the
ones we used in 1973.  If someone writes an I-D using xxe to produce
XML which xml2rfc turns into the text form that idnits wants, that
doesn't make him less manly than someone who edits with teco and codes
the nroff commands by hand.  (I had enough of that in my thesis in the
1970s.)

A major reason that the discussion of RFC formats never gets anywhere
is that it is really a discussion of the process more than about
particular formats, and we don't do process very well.  The current
process uses input and output formats that are similar enough that
people wrongly think they're the same, even though of course they are
not.  Many people seem to assume that if we picked a new output
format, we would necessarily change the input format to be "the same"
as the output format, which I think would be a terrible idea.  The
input formats need to be reasonably easy for non-experts to create,
and to be structured enough so that validation tools can work with
them.  The output format basically needs to be displayable, printable
and searchable.  There is no reason they have to be at all similar.

If I were tsar, I would probably leave the input format as xml2rfc,
give or take tweaks for figures and a broader character set, but make
the output format a more rigidly structured XML that can be
mechanically and consistently transformed into a variety of display
formats.  If you want nroff-style RFCs, that's a display format.

R's,
John