Re: [art] New RFCs text formatting

[John C Klensin <[e-mail]>]

(copying the IETF list -- this is not an ART matter alone)

TL;DL warning: while not terribly long, this is a rant.

--On Thursday, November 28, 2019 01:50 +0100 Steffen Nurpmeso
<[e-mail]> wrote:

>...
> Yah, hm, hm.  It surely has merits, both HTML as well as PDF.
> I have a local RFC pool since, pooh, maybe 2003 or so.  The
> german computer magazine c't once put all (?) of them on one
> of their CDs by then, and i am only throwing onto that stock
> ever since. I personally am almost perfectly served with plain
> grep(1) on plain text.  Actually i do not even really care
> about missing form feeds, i was only surprised.

Hi.  I realize it is very late, probably too late, to be
complaining about this, but my clear recollection was that, when
the v3 project was started, the community was promised that,
while the authoritative/ canonical/ archival format would shift
to the XML and fully-functional HTML and PDF format (not just
HTML and PDF produced from plain text forms) would become
available, the plain text format would be preserved sufficiently
that tools [1] that were designed for, and used with, RFCs for
the last 40-odd years would continue to work and work equally
well [2].  If page breaks, running headers and footers, and TOCs
and indices with page references have disappeared, some of those
tools will cease working (even if grep still does) and that
violates that particular commitment.  If there were an xml2rfc
v3 option that was guaranteed to be supported and that would
generate the older format, even if that format were never stored
on IETF servers, I think that would be sufficient to let us (and
our tools) keep working, but that does not seem to be the case
at present (nor does it address any TOC or index issues).[3]

This is especially important because at least some of us who
prefer the text form when working with RFCs (even if some of us
might prefer something else for reading them), after losing the
argument about whether XML (or any other generic or formatting
markup arrangement) was appropriate as the canonical/archival
form essentially tuned out of the discussions of xml2rfc v3
details and decided to devote our available IETF time to
technical standards and other work that we felt had impact on
the Internet rather than just on the IETF and how it operated.
The tuning out was reinforced as it became clear that xml2rfc v3
was evolving into a odd hybrid between generic and formatting
markup, one that was as or more likely to share the disadvantage
of each rather than the advantages and that, in terms we use
when talking about networking, raises all of the issues of layer
violations.  So we didn't read the reports and documents
carefully; we just assumed that, as long as the plain text
format was stable (pagination and all), we would continue to be
able to work without having to spend time converting habits and
tools.

Perhaps what all of this means is that I (and a few others) are
just old and stuck in our ways and that the IETF would be better
off if we just retired or otherwise moved on.   The "old" part
is certainly true for some of us but I'm not convinced about the
"better off" part.  However, by requiring us to develop new
tools or learn new tricks, this change may have the effect of
raising the bar for effective participation in the IETF enough
to push us out.   That is especially likely when we need to
review and revise older documents.  Personally, I think that
pushing anyone out who is willing to do work and might have
useful contributions to make is a bad idea.

So, even if it is too late to reconsider these decisions, I hope
we can at least be aware of possible negative side effects.

best,
   john


[1] The concern is about user-developed tools, used by one
person or a cluster of people who have shared them, not ones
developed or maintained under IETF auspices.

[2] Reading RFC 7994 only after these changes were identified, I
find that Sections 4.1ff remove headers and footers and the page
numbers from the TOC.  But the introductory paragraph of Section
4 does say 

	"One plain-text output will be created during the
	publication process with basic pagination that includes
	a form feed instruction every 58 lines at most,
	including blank lines."

So perhaps that omission is a bug.


[3] The last argument for removing pagination in Section 2.1.3
of RFC 6949 is almost completely bogus.   The problems with
unbroken sections that span several pages, including
difficulties with references to material in those sections, was
noticed not long after RFC 1543 was published with its specific
comments about cross-references to sections and not pages, IIR
much earlier.  There was discussion even before then about
insisting on numbered paragraphs, an idea that was abandoned in
large measure because of difficulties with document preparation
and tooling.  For some years, the RFC Editor pushed back
aggressively or (or simply modified) such very long sections,
especially when there were cross-references to them (by either
section number or page number).  Later, for reasons unrelated to
this rant, the pushback became much less frequent.  The problem
is over-long sections; the solution is to manage RFC Style
decisions (during final editing if not earlier) so that they
don't happen, not to pretend that eliminating page numbers will
eliminate those sections by precluding the possibility of using
page number for more granular references.