John, with electronic versions the ToC *works* for PDF and HTML. For dead trees versions the ToC does not work efficiently regardless of the original form. Binary searches through a stack of pages is not efficient. The plain text version also has this issue in the electronic version. The point of a ToC is to have list of the sections *and* to be able to get to the relevant section easily. When you can’t click on a link you need page numbers especially as we have unnumbered sections. One shouldn’t have to memorise the section names *and* order in the ToC to find something in a dead tree version. Mark > On 29 Oct 2020, at 06:19, John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --On Wednesday, October 28, 2020 17:40 +0100 Toerless Eckert > <tte@xxxxxxxxx> wrote: > >> On Tue, Oct 27, 2020 at 04:57:38PM -0700, Jim Fenton wrote: >>> but if some >>> people are reading HTML versions, PDF versions, and TXT >>> versions, the pagination is different anyway (and nonexistent >>> for HTML) so trying to reference something by page number is >>> problematic. >> >> The thread is getting long so it is hard to not miss things >> said earlier, so let me repeat: My proposal was to add on IETF >> pages renderings with page numbers (not to remove any of the >> non-paginated renderings), AND make sure the pagination is >> consistent across them. > > And, also to repeat, the expectation of consistent numbering (or > consistent pagination) across different renderings is > impractical and unwise. As a specific and concrete example, > consider the relationship between a PDF document that contains > representations of several graphic images and the associated > text version. The only way I can think of to make the > pagination (and numbering) consistent between them would be to > leave large areas of white space in the text. That could be > done, but would make the text file longer and less useful. > > AFAICT, the arguments against page numbers in the text files are: > > (1) They are not allowed to be used in crossreferences within > the document, therefore they are utterly useless. > Response: See many comments that contradict "utterly useless" > in this set of threads. And we've had that rule for decades and > the RFC Editor and then the RFC Production Center enforce it. > > (2) They are not allowed to be used in references within the RFC > Series to parts of other RFCs. > Response: We've had that rule for decades and the RFC Editor > and then the RFC Production Center enforce it. > > (3) We don't want them used by third parties or their documents > to references parts of RFCs. > Response: As you point out, many other publications already > prohibit page number references to identify particular material > and do so for much the same reason we have. But, as long as we > paginate documents, nothing we do is going to prevent someone > who insists on page numbers from counting and using them. And, > as long as we have at least one paginated form (numbered or not) > that will be possible. However, page numbers that are > inconsistent among renderings actually reinforces the "don't use > page numbers in references" rule because it is then clear that > they are too unstable to make good references, so maybe we > should be promoting their inclusion. > > (4) Page numbers in plain text documents are so inherently evil > and/or the risk to horrible damage being done by anyone using > them so high that we need to suppress them and headers and > footers (and perhaps even pagination) as well. That evilness > and risk of damage is acceptable in the PDF form, just not in > the plain-text one. > Response: In fairness, no one whose comments I have read has > actually said/ claimed that, but it seems to me that it is were > several arguments against page identification (numbered or not) > seem to be heading. YMMD. > > By contrast, there are, it seems to me only two reasons for > retaining the page numbers (and pagination, headers, and > footers) in the plain text rendering: > > (a) They are traditional in the RFC Series and > preserving that rendering in a format consistent with a > significant fraction of the first 7000 or so of RFCs > would seem to have some advantages. Of course, no one > is forced to use them, any more than anyone has been > forced to use the standard text form since HTML and PDF > forms became generally available years ago. > > (b) Of the fraction of the community that still prefers > to use the plain text form (at least sometimes) and for > one purpose or another, some fraction of them prefer to > have the headers and footers and many of those prefer, > or are not disturbed by, the page numbers. Because many > of the arguments against page numbers seem to be coming > from people who do not find the plain text form useful, > probably we should pay attention to that preference ... > or start making the case for getting rid of the plain > text form entirely, perhaps because those who prefer it > (for any purpose) need to be persuaded to join the > modern era and get with the programs. > > Probably I'm missing something important but, if the above > analysis is even nearly correct, I don't understand why we are > still having this conversation. > > john > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
