I would say "+1" too, except that, from experience, the implicit characterization of paginated (and header and footer-equipped) plain text as being only about printing (especially, as has come up in other notes, printing on ancient, perforated-paper, line printers) misses the point that there are at least three reasons that I can think of to prefer that format (other than idiosyncratic personal taste, but I don't think the IETF gets to say that even the latter is illegitimate). Those are: (1) One really does intend to print the document and has a printer, or printer drivers, that make handling of documents without page breaks difficult. As Paul Hoffman just pointed out (and I pointed out last week), RFC 7994 requires pagination (but just page breaks, not headers or footers) for the RFC output. If RFCs are being produced and put into the archives / available from the RFC Editor's server) that don't have those page breaks in the plain ASCII form (and we seem to have at least one example) that is a bug and it is, at least IMO, reasonable to ask how soon it will be fixed (and maybe why it happened). (2) One has discovered that, regardless of the format in which one prefers to read RFCs, it is easier to work with them in plain text format using public tools like "grep", some highlight-copy-and-paste operations, and so on. Most, perhaps all, of those uses require that plain text files be available; few, if any, require pagination, much less headers, footers, or page numbers [1]. (3) One has private tools (or obscure public ones that there has been no evidence that anyone other than their authors know about) that are actually dependent on the presence of headers and/or footers and/or usable page numbers. So, I think that Keith should have said "only if there's rough consensus that none of the three cases above exist anymore. If they do, there is rough consensus that the IETF is willing to tell users whose work falls into one of those categories that we are just not interested in their problems and that, if the result is that they reduce their participation or willingness to accept RFCs for other purposes, we just don't care." best, john p.s. Some of the comments about A4 paper make questionable assumptions about how line and page lengths for RFCs were chosen. It may well be that we (and I do mean "we" because I was involved in the discussion although I certainly was not the decision-maker) got it wrong, but the assumption that is was not considered is simply incorrect. [1] As I have discussed elsewhere and will not repeat unless asked, the claim that eliminating the ability to reference into an RFC by page number and therefore encourage shorter sections has actually been disproven by years of experience. The only things that encourage or forces shorter sections are author education and the RFC Editor insisting that they will not publish a document with too-long sections without a very specific justification (at least unless the Stream Manager insists and then probably with the appropriate note). --On Sunday, December 1, 2019 12:55 -0500 "Scott O. Bradner" <sob@xxxxxxxxx> wrote: > +1 > >> On Dec 1, 2019, at 12:52 PM, Keith Moore >> <moore@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> >> >> Sent from my iPhone >> >>> On Dec 1, 2019, at 12:28 PM, Nick Hilliard <nick@xxxxxxxxxx> >>> wrote: >>> >>> I'd be happy for pagination to be the default if there were >>> rough consensus that the primary medium for reading RFCs was >>> printed paper. >> >> Seems like this is backwards. Pagination should be removed >> from plain text RFCs only if there's rough consensus that >> nobody prints RFCs anymore - not because a few individuals >> think that nobody should do that, or think that they're in >> a position to dictate how RFCs are used. >> >> Keith >> >> >
