--On Tuesday, October 27, 2020 00:32 +0000 Ronald Tse <tse@xxxxxxxxxx> wrote: > My two cents: why don't we just run a poll to see what the > "consensus" is? There are some other issues with polls that people have addressed so I won't repeat here, but... > To me, standardizing page numbers is the wrong direction — > one of the features of XML RFC is to allow rendering content > into different formats. Having page numbers for the ASCII > version is fine (it's only being done by xml2rfc anyway), > but requiring these numbers inside the XML is putting the cart > before the horse. Unless I have missed something important as I have skimmed this thread, no one has advocated anything that could be described as "requiring ... numbers inside the XML". We had paginated and numbered RFCs all through the lives of xml2rfc v1 and v2 and still have paginated and numbered I-Ds, none of them requiring numbering within the XML source. The issue here, at least as I understand it, is that we have three output forms for RFCs: PDF (inherently page-image and paginated), HTML (inherently producing output that is line-flowed and unpaginated although it can certainly produce other forms as rendered results), and text. The latter was originally supposed to be preserved in as close to the historical ASCII text pages as possible but the powers that be decided that the conversion from the XML should retain the fixed-length lines but drop pagination and headers and footers with line numbers. AFAICT, it is only that last decision that is under review / discussion here. And, again, if the PDF form did not have those headers and footers with page numbers on the latter, I'd be much more sympathetic to arguments that page numbers were harmful (or confusing, etc.) and should hence be suppressed in RFCs. And even if one accepts page numbers as evil, that doesn't make a case against paginating and retaining headers and footers in the text format. But I think I'm repeating myself so should stop. john
