(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 <steffen@xxxxxxxxxx> 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.
