Subject: Poll: RFCs with page numbers (pretty please) ? (was: Re: John/rsoc: Re: Page numbers in RFCs questions / preferences)

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 19:01:05 +0100

Since about RFC8650, newer RFC will not have any renderings with
page numbers on {datatracker,tools}.ietf.org. See explanation from
John Levine below.

Not having followed the details of the RFC/XMLv3 standardization process,
i was surprised by this because i think there is no reason to
have additional renderings, maybe even only on tools.ietf.org that
do include page numbers (and technically it does not seem to be a problem
either). 

If you care to express your position,
i have created a poll for this, please chime in there:

https://www.poll-maker.com/results3188562x294441dA-98

Cheers
    toerless

On Mon, Oct 26, 2020 at 01:35:43PM -0400, John R. Levine wrote:
> > Could you please explain why RSOC does not want to permit the ability
> > to have paginated RFC output options ? Also, where and when was this
> > discussed with the community ?
> 
> It was discussed in the multi-year process leading to the IAB
> publishing RFCs 7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and
> 7998 in 2016. I'm sure you know how to find the discussions in the
> archives.  Henrik knows all of this and I cannot imagine why he did not tell
> you the same thing.
> 
> I am aware there is one recent RFC author who did not participate in
> the process at all and has been complaining that the text version of
> his RFC doesn't have page numbers. I've explained this to him more
> than once, and see no reason to waste more time on it.
> 
> R's,
> John

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Oct 2020 13:11:36 -0500

Hi Toerless -

Just to be clear about my other thread on the subject - having xml2rfc 
produce things that look like RFCs that have page numbers in them for 
someone's local use is one thing. Publishing such things is entirely 
different. Confusion about different versions of published things is a 
real consideration. To get to that point, I think you really are talking 
about changing a community consensus set of documents - the output of 
such a poll will be input into some drafts, not just "stand up this 
separate service".

RjS

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Oct 2020 18:16:26 +0000

Hiya,

> i have created a poll for this, please chime in there:

FWIW, I think such polls are antithetical to how we want the
IETF to work. Bad idea to pile on that way IMO regardless of
what one things of pagination.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 07:56:36 +1300

As Julian Reschke observed on the rfc-interest list, since the
new RFC format was implemented:

>  page numbers should not be used to refer to parts of the
>  RFC, because page breaks vary with output formats

So I can only see confusion if people use page numbers for
any purpose whatever. So it doesn't matter if people want
page numbers; they're now useless. So I won't be answering
a poll, and I don't think the results are interesting.

Regards
   Brian 

Regards
   Brian Carpenter

On 27-Oct-20 07:01, Toerless Eckert wrote:
> .

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 26 Oct 2020 20:00:17 +0100

On Mon 26/Oct/2020 19:01:05 +0100 Toerless Eckert wrote:
> page numbers on {datatracker,tools}.ietf.org.

That's not exact.  Although pdf format —which has page numbers— is hosted on 
the rfc-editor site, it is accessible from the relevant datatracker page.

Best
Ale
--

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 20:10:42 +0100

Brian:

RFC editor can easily check that new RFC will not have references to
other RFCs with page numbers.

Its also perfectly easy to have only one rendering of page numbers, so
therre won't be inconsistencies of page numbers on official IETF pages.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 20:13:06 +0100

> what one things of pagination.

https://en.wiktionary.org/wiki/piling_on

"The process by which additional combatants join an ongoing fight or
 argument when they think they know who will win so that they will be on the winning side.

Thanks for giving me hope that there will be page numbers again.

Cheers
    Toerless

> S.

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <[email-masked]>
> sub   RSA 4096/36CB8BB6 2017-12-22

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2020 16:24:57 -0400

>what one things of pagination.

It is certainly very far from my understanding of how the IETF works.

R's,
John

Pro tip: if you adjust your cookie settings, you can vote as many times as you want.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 21:30:53 +0100

> It is certainly very far from my understanding of how the IETF works.

Or from RFC 7282:

      We reject: kings, presidents and voting.

(Famous line from Dave Clark, 1992, of course.)

Then it goes on quoting Dave Clark:

      We believe in: rough consensus and running code.

It is apparent that, with running code now installed and operating, the consensus appears to be rather rough.  (New data, new discussion, I’d say, but I’m not the chair here.)

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Oct 2020 20:36:31 +0000

r

> Thanks for giving me hope that there will be page numbers again.
I made no statement about pagination.

I intended to try help take away your hope that a poll
such as the one you suggested could be a valid part of
this or any IETF discussion.

S.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 21:55:48 +0100

> It is certainly very far from my understanding of how the IETF works.

I was doing it this way thinking that it would be better not to swamp the IETF
mailing list with opinions about something that the leadership seems to want to put a lid on.
If that's not a good thing, then please: chime into this discuss with your opinion
directly everybody.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 26 Oct 2020 21:57:41 +0100

> this or any IETF discussion.

Oh, sorry. I should of course have called it "hum" instead of "poll".

Cheers
    Toerless

---

From: John Scudder <[email-masked]>
Date: Mon, 26 Oct 2020 21:14:37 +0000

On Oct 26, 2020, at 2:56 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

The argument that page numbers are harmful as a way of referring to a section of the RFC is reasonable.

The argument that page numbers are harmful for *any* *purpose* *whatever* is not reasonable. To offer one glaringly obvious counterexample, people (I, for one) sometimes print RFCs for the purpose of reading them. Sometimes we want to make use of some kind of facility for indexing from a list of headings to facilitate direct access to the right section of the pile of printout. A table of contents, in short. This is literally what tables of contents were invented for. They remain useful for this purpose… unless some bright spark chooses to remove the page numbers from them, because they forgot what tables of contents are FOR.

(Also, I think the use of the ToC for quickly estimating a document’s throw weight is a valid one. I previously suggested associating a BogoPages metric with each non paginated RFC for this purpose.)

—John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 10:16:01 +1300

> other RFCs with page numbers.

That is only one of the many ways in which ambiguous page numbers could be harmful.

> therre won't be inconsistencies of page numbers on official IETF pages.

I don't get it. Web sites don't have page numbers. We agreed during the whole process of designing the new RFC format that HTML is the most desirable presentation format. Page numbers make no sense and have no value in HTML.
So why bother with them in txt, which is now a legacy format and not very useful for new RFCs? (PDF is an oddity, since it's basically page images, so its page numbers will always be a source of confusion.)

You may have noticed that rfcdiff removes page breaks as its first step, and there's a reason for that: pages are irrelevant even when comparing plain text. As soon as you go to flowed rich text, they are even more irrelevant.

Maybe it's because I was brought up on paper tape rather than punch cards, but I can't see why anybody cares about pagination in 2020.

Regards
    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 22:33:10 +0100

On 2020-10-26, at 22:16, Brian E Carpenter <[email-masked]> wrote:
> 
> Maybe it's because I was brought up on paper tape rather than punch cards,

Ah!  I used both in the 1970s, but more punch cards, and even my paper tape was mostly Z-folded not rolled…  That explains it.

> but I can't see why anybody cares about pagination in 2020.

Proof by lack of imagination :-)

Apparently these people do exist, and they have been speaking up with their use cases.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 10:37:39 +1300

On 27-Oct-20 10:14, John Scudder wrote:
> On Oct 26, 2020, at 2:56 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>

Well yes... but iirc the input to the new format discussion was that most people read RFCs and drafts on-screen and mostly with the htmlized versions. So the needs of the occasional eccentrics who print them for off-line reading were set aside. (I can say that because I am such an eccentric.)
 
> (Also, I think the use of the ToC for quickly estimating a document’s throw weight is a valid one. I previously suggested associating a BogoPages metric with each non paginated RFC for this purpose…

Well, the byte count serves fairly well for that too.

Regards
   Brian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 26 Oct 2020 17:53:39 -0400

Toerless,

It's less that anyone wants to "put a lid on" this, and more that no-one
wants to rehash decisions that were openly discussed over a period of
years. Heather reported on this work at EVERY plenary meeting while it was
ongoing, and there was plenty of discussion on the main IETF list, so if
you completely missed it, it's not because it took place behind closed
doors at the time. The work, and the result, were very well publicized.

To your point that you need a printable version with page numbers, that's
provided by the RFC Editor for every RFC, for example
https://www.rfc-editor.org/rfc/rfc8905.pdf (to cite a recent example). If
you quickly need the last page number, just click in your browser or PDF
reader on the last entry in the TOC.

The expectation with the new RFC formats is that the HTML version will be
the one that most people read and refer to, and as that version obviously
cannot have page numbers, section numbers are used instead if you need to
cite text in a discussion or comments.

The txt version is now the worst choice to use for your work, because you
miss any SVG drawings in the RFC. I know, old habits die hard.

Cheers,
Andy

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Oct 2020 18:00:14 -0400

On 10/26/20 5:14 PM, John Scudder wrote:
> On Oct 26, 2020, at 2:56 PM, Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>>
> The argument that page numbers are harmful for *any* *purpose* 
> *whatever* is not reasonable. To offer one glaringly obvious 
> counterexample, people (I, for one) sometimes print RFCs for the 
> purpose of reading them. Sometimes we want to make use of some kind of 
> facility for indexing from a list of headings to facilitate direct 
> access to the right section of the pile of printout. A table of 
> contents, in short. This is literally what tables of contents were 
> invented for. They remain useful for this purpose… unless some bright 
> spark chooses to remove the page numbers from them, because they 
> forgot what tables of contents are FOR.
>
+1

Page numbers are also quite helpful to keep the pages in the right order 
after you have printed them, and in a ToC it helps giving you an idea of 
how much material is in each section.

I confess that while most of my reading is on-line, I still buy physical 
books, use highlighters and occasionally print out an RFC either in part 
or in full. It sounds like I'm not the only one, and I have a hard time 
understanding why I am not allowed to get page numbers to help in that 
process.

Thanks

-- Flemming

> (Also, I think the use of the ToC for quickly estimating a document’s 
> throw weight is a valid one. I previously suggested associating a 
> BogoPages metric with each non paginated RFC for this purpose.)
>
> —John

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 26 Oct 2020 18:02:16 -0400

Flemming,

If you need a printable version with page numbers, that's provided by the
RFC Editor for every RFC, for example
https://www.rfc-editor.org/rfc/rfc8905.pdf (to cite a recent example). If
you quickly need the last page number, just click in your browser or PDF
reader on the last entry in the TOC.

Cheers,
Andy

On Mon, Oct 26, 2020 at 6:01 PM Flemming Andreasen <fandreas=
[email-masked]> wrote:

> On Oct 26, 2020, at 2:56 PM, Brian E Carpenter <
> [email-masked]> wrote:
>
>
> The argument that page numbers are harmful for *any* *purpose* *whatever*
> is not reasonable. To offer one glaringly obvious counterexample, people
> (I, for one) sometimes print RFCs for the purpose of reading them.
> Sometimes we want to make use of some kind of facility for indexing from a
> list of headings to facilitate direct access to the right section of the
> pile of printout. A table of contents, in short. This is literally what
> tables of contents were invented for. They remain useful for this purpose…
> unless some bright spark chooses to remove the page numbers from them,
> because they forgot what tables of contents are FOR.
>
> +1
>
> books, use highlighters and occasionally print out an RFC either in part or
> in full. It sounds like I'm not the only one, and I have a hard time
> throw weight is a valid one. I previously suggested associating a BogoPages
> metric with each non paginated RFC for this purpose.)
>
> —John
>
>
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2020 18:06:36 -0400

Brian,

I look at the same information and come to a different
conclusion (quite independent of the question of whether a poll
at this point is a useful exercise)...

>>  RFC, because page breaks vary with output formats

Cross references (and other references) to page numbers have
been discouraged since at least RFC 1543 (in 1993) and banned
soon after that, to the point that the RFC Editor from the last
half of the 1990s would simply remove such references, replace
them with references to section numbers, and complain when
sections got too long for convenient referencing.  Nothing about
restricting references to page numbers is new with the new
format.   

> a poll, and I don't think the results are interesting.

However, getting from "references to information by page numbers
have always been a bad idea, prohibited for a quarter-century,
and even more obviously a bad idea as we move to multiple
formats" to "any purpose whatsoever" is a big jump.  At least
some of us have tools and macros floating around that are
dependent on pagination and, as an exception to the
"referencing" rules, it is still not clear (at least to me) how
to build and format a document index using anything else (at
least without a lot of effort).  There are even simple and
obvious reasons: If one is going to print an RFC from the text
form (or render it into printable form), something is going to
do the pagination and being able to easily estimate the page
count may affect how printing is to be set up.

FWIW, the questions of "should documents be paginated" and
"should the pages be numbered" are also separate ones.

Moreover, the argument that pagination (and page numbers) are
obsolete and useless for RFCs would be much stronger if the PDF
form for new RFCs were not paginated (or at least not numbered)
... but it is both paginated and numbered.   And, if the issue
is having things lay out well on many different types of
devices, eliminating pagination (and headers and footers) to
facilitate that is bogus: it would be equally or more reasonable
to eliminate (or rethink) line breaks in running text, etc.   If
one really wants things optimally formatted for a variety of
different devices, then the right thing to do is to start from
the HTML form and a well-designed style sheet or to go back all
the way to the XML, not to try fussing with the ASCII text form. 

Conclusion: The main arguments that have been given for
eliminating pagination, headers and footers, and page numbering
--at least those based on different devices and references-- are
mostly bogus.

So, from my point of view as a fan of pagination in the ASCII
form of RFCs, one who has never willingly referenced part of an
RFC by page number, this seems to come down to something else
entirely: if there is a goal to eliminate (or strongly
discourage) the use of ASCII format RFCs in favor of the HTML or
PDF forms (or building directly on the XML), then "no page
numbers" and "no pagination" are among the first few cuts of a
death by 1000 of them.    If not, this has all of the hallmarks
of a gratuitous change to a format that has been useful to many
people for a very long time.

    john

p.s. Just in case I'm the anonymous person John Levine's note
referred to, I didn't just "not participate" in the discussion.
It was made extremely clear that my input was not welcome, so
clear that, after a discussion or two with Heather that I should
spend my time in other ways.  If there were a significant number
of others like me (and I have no way to tell, or even to guess)
then claims that the no-pagination form represents community
consensus lie somewhere on the scale between "dubious" and
"bogus".

---

From: Matty K <[email-masked]>
Date: Tue, 27 Oct 2020 08:12:48 +1000

One thing that occurs to me, when someone asks for a hard copy document to
have custom markup: people still own pens, right?

Cheers
Matthew Kerwin

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Oct 2020 00:31:38 +0100

Brian:

Given how it seemingly would be quite easy for tooling to ALSO
provide a paginated rendered version of the document, the basis
of the decision process to explicitly reject to support that
option looks unfortunately like a slim mayority not only getting
their way, but also wanting to force the minority NOT to get its
way too, quite unnecessarily. Not very inclusive.

Of course, i know: slippery slope argument:

"If everybody who had a 40 year beloved and successful document
format would step forward and request that a tiny bit of effort would
be spent to provide an easily done rendering for it, where would we
as the IETF end up then..."

Cheers
   Toerless

-- 
---
[email-masked]

---

From: David Noveck <[email-masked]>
Date: Mon, 26 Oct 2020 19:40:58 -0400

> consensus lie somewhere on the scale between "dubious" and

Disagree.  It is far past bogus.   How about "somewhere between 'false' and
'disingenuous'"?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 12:51:39 +1300

John,

Let me retract "useless". What really bothers me is that page numbers are actively misleading in the new format. I think that became true the moment a consensus appeared that the preferred presentation format was HTML with flowed text.

Regards
   Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2020 19:56:30 -0400

--On Tuesday, October 27, 2020 10:37 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> The argument that page numbers are harmful for *any*
>> *purpose* *whatever* is not reasonable. To offer one
>> glaringly obvious counterexample, people (I, for one)
>> sometimes print RFCs for the purpose of reading them.
>> Sometimes we want to make use of some kind of facility for
>> indexing from a list of headings to facilitate direct access
>> to the right section of the pile of printout. A table of
>> contents, in short. This is literally what tables of contents
>> were invented for. They remain useful for this purpose…
>> unless some bright spark chooses to remove the page numbers
>> from them, because they forgot what tables of contents are
>> FOR.

> Well yes... but iirc the input to the new format discussion
> was that most people read RFCs and drafts on-screen and mostly
> with the htmlized versions. So the needs of the occasional
> eccentrics who print them for off-line reading were set aside.
> (I can say that because I am such an eccentric.)  

But, first of all, if the only need is to print (eccentric or
not) for off-line reading were the only issue, then that is an
argument in favor of PDF and perhaps abolishing the text form,
not crippling it, unless one happens to like the fixed-pitch
font (definitely eccentric).   The people whose needs were set
aside were those of us who routinely use text editors (of the
emacs or vi species and their clones), and personal RFC-specific
macros in those editors, to work with RFCs, many of whom have
been working that way for a long time (a few since before there
was an IETF). 

As to "set aside", there were at least some IETF participants
with those needs (or, if you prefer, habits), along with those
who argued for keeping the xml2rfc v3 specification rather
closer to generic markup (reducing rather than increasing the
amount of format markup) and inclusion of markup that would make
it straightforward to specify references to book chapters and
journal articles in relatively standard form. It was made clear
to at least a subset of that group that they were (to paraphrase
somewhat) a bunch of old farts who, regardless of their prior
experience, just did not understand the modern Internet and
publishing and therefore would not be listened to no matter what
they had to say.  That message was rather clear and, since the
process was not an IETF one, appeals and the like felt rather
hopeless.  So, some people just moved on to other things and
others concluded that the IETF was on enough of a downhill slide
that issues like publication formats made little difference.

The good news is that there apparently weren't very many of us.

>> (Also, I think the use of the ToC for quickly estimating a
>> document's throw weight is a valid one. I previously
>> suggested associating a BogoPages metric with each non
>> paginated RFC for this purpose.)
> 

Sure.  So does a line count given a format.  But, while I'm
reconciled to do it, time I spend re-understanding and then
rebuilding macros that are a couple of decades old is time that
isn't spent on IETF substantive work.  The question is whether
whatever benefits are gained by eliminating pagination from RFCs
-- presumably gains to those who continue to use the text form
rather than HTML or PDF because the latter two groups are
irrelevant -- are sufficient to justify that.

   john

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Oct 2020 00:59:08 +0100

> Let me retract "useless". What really bothers me is that page numbers are actively misleading in the new format. I think that became true the moment a consensus appeared that the preferred presenta…

I do not understand: Who is mislead about what ?

Also: Given how there are so many possible presentation methods and consumption use-cases,
why do you think that prohibiting a particular format is helpful to the community ?

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Ronald Tse <[email-masked]>
Date: Tue, 27 Oct 2020 00:32:10 +0000

My two cents: why don’t we just run a poll to see what the “consensus” is?

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.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Oct 27, 2020, at 7:56 AM, John C Klensin <[email-masked]<mailto:[email-masked]>> wrote:

--On Tuesday, October 27, 2020 10:37 +1300 Brian E Carpenter
<[email-masked]<mailto:[email-masked]>> wrote:

  john

Regards
  Brian

_______________________________________________
rfc-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2020 20:49:33 -0400

--On Tuesday, October 27, 2020 12:51 +1300 Brian E Carpenter
<[email-masked]> wrote:

> Let me retract "useless". What really bothers me is that page
> numbers are actively misleading in the new format. I think
> that became true the moment a consensus appeared that the
> preferred presentation format was HTML with flowed text.

Brian,

Assume, temporarily and for purposes of discussion, that we
agree about that "actively misleading" part.  Then either:

* We should remove the page numbers from the PDF file (if they
are "actively misleading" in the text, then they are at least as
actively misleading in the PDF and put the pagination plus
headers and footers back into the text form.   

or

* We should remove the page numbers and headers and footers from
the PDF and than paginate the text form.  

Otherwise, I find it very difficult to argue that there is any
sort of principle  here other than "punish those who insist on
being dependent on the text form" and maybe even "punish them
sufficiently that they repent of their sins and switch over to
HTML".

FWIW, I assume that everyone who prefers the paginated text form
has their own set of priorities.  For me, it would be
pagination; headers and footers with title, author, and date;
and only then page numbering (which I tend to use only for
document lengths and the occasional indexed document).   So, if
the goal was to suppress page numbers in the text form as
useless or worse, from my personal standpoint the baby went out
with the bathwater.

Apologies, but because of how those long-ago discussions were
handled -- and then claimed to represent community consensus --
I've got a really bad attitude on this issue.

best,
    john

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Oct 2020 02:00:55 +0100

On Tue, Oct 27, 2020 at 12:32:10AM +0000, Ronald Tse wrote:
> My two cents: why don???t we just run a poll to see what the ???consensus??? is?
> 
> 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.

Btw: i very much like to have unpaginated document versions, even as primary
reference. I just think it would be easy and useful to have datatracker/tools
provide both. Of course the page numbers wouldn't go into the XML!

Its just another case of "there is no one single right answer" (at least IMHO).

Cheers
    Toerless

> were invented for. They remain useful for this purpose???

> [email-masked]

-- 
---
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2020 21:15:13 -0400

--On Tuesday, October 27, 2020 00:32 +0000 Ronald Tse
<[email-masked]> 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

---

From: Ronald Tse <[email-masked]>
Date: Tue, 27 Oct 2020 01:30:47 +0000

Thanks John for the clarification. There is some confusion to me whether the intention is just about the TXT output having page numbers, or for the PDF to also have the same page numbers, and whether to use page numbers inside cross references. There was a also discussion about a ToC and page numbers, but perhaps that was a diversion.

If the discussion is only about the ASCII output having page numbers, I have no objection because it is (nearly) purely cosmetic (in publication and in usage of the text, being done by xml2rfc).

If having page numbers will require the PDF output to also have page numbers, this inevitably leads to some shared spec between the TXT and PDF outputs on the topic of pagination, which is less ideal, but since I assume that is the work of xml2rfc, it’s not a concern to us as tool maintainers.

Adding page numbers to cross references can make reading confusing — since the cross references between the paginated and flowed versions will render these references differently. It’s doable, but again this requirement ties the paginated versions (TXT and PDF) together for consistency.

Of course, if the PDF output is simply an enhanced PDF-ized TXT version, these aren’t really issues.

Ronald Tse
Ribose Inc.

On Oct 27, 2020, at 9:15 AM, John C Klensin <[email-masked]<mailto:[email-masked]>> wrote:

--On Tuesday, October 27, 2020 00:32 +0000 Ronald Tse
<[email-masked]<mailto:[email-masked]>> wrote:

  john

---

From: Ronald Tse <[email-masked]>
Date: Tue, 27 Oct 2020 01:41:29 +0000

I did mean to say that it is very useful to have page numbers, headers and footers on paginated output, eg. PDF. If the TXT version is also intended for printing (I only read them on a computer, but I digress), it should retain them.

Ronald Tse
Ribose Inc.

On Oct 27, 2020, at 9:31 AM, Ronald Tse <[email-masked]> wrote:

Ronald Tse
Ribose Inc.

  john

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2020 21:53:11 -0400

--On Tuesday, October 27, 2020 01:30 +0000 Ronald Tse
<[email-masked]> wrote:

> Thanks John for the clarification. There is some confusion to
> me whether the intention is just about the TXT output having
> page numbers, or for the PDF to also have the same page
> numbers, and whether to use page numbers inside cross
> references. There was a also discussion about a ToC and page
> numbers, but perhaps that was a diversion.
> 
> If the discussion is only about the ASCII output having page
> numbers, I have no objection because it is (nearly) purely
> cosmetic (in publication and in usage of the text, being done
> by xml2rfc).
> 
> If having page numbers will require the PDF output to also
> have page numbers, this inevitably leads to some shared spec
> between the TXT and PDF outputs on the topic of pagination,
> which is less ideal, but since I assume that is the work of
> xml2rfc, it's not a concern to us as tool maintainers.

Actually, I think you have it a bit backward.  The PDF has page
numbers today.  More to the point, PDF is (almost) inherently a
page image format so there is no way to escape pagination.  One
could decide to not number those pages in the footers, or one
could eliminate the headers and footers entirely, but the page
boundaries are going to be there regardless.

However, as long as a strict discipline is maintained that
references (within an RFC, between RFCs, and whatever we can
do/encourage about external references to RFCs use are to
section numbers and not pages (and there Brian and I agree)
_and_ as long as we don't allow sections to become so long that
people seek other mechanisms, then whether the page numbers in a
text format agree with those in the PDF format or not is largely
irrelevant.  That issue is centuries old: if I reference a
chapter by number in a book, that reference is typically stable
for different printings and formats (and often but not always
between editions).  But the page numbers often are not, so,
unless the people doing the layout are _really_ careful, using
the index from, e.g., a hardbound copy and trying to apply its
numbers to a paperback that uses different size type and page
layouts is, to use a technical term, just plain dumb.  And
external references that use page numbers need to be very
careful to specify exactly what form is being referred to.

> Adding page numbers to cross references can make reading
> confusing — since the cross references between the paginated
> and flowed versions will render these references differently.
> It's doable, but again this requirement ties the paginated
> versions (TXT and PDF) together for consistency.

And, again, this is why there has been a long-term prohibition
in the RFC Series against using page numbers in cross references.

> Of course, if the PDF output is simply an enhanced PDF-ized
> TXT version, these aren't really issues.

But two of several advantages of the contemporary (xml2rfc v3)
PDF version is that it can contain and render pictures easily
and that, if characters are used outside the ASCII repertoire,
they are rendered correctly as well.

best,
    john

---

From: Ronald Tse <[email-masked]>
Date: Tue, 27 Oct 2020 01:58:09 +0000

Thanks for the message. I do agree with most of your points, and may have had trouble expressing that.

In the last example you also described why the page numbers between PDF and TXT output will not sync:

It’s not easy synchronizing page numbers between two paginated outputs if rendered objects are allowed to have different dimensions (e.g. ASCII art in TXT vs SVG in PDF).

Ronald Tse
Ribose Inc.

---

From: Larry Masinter <[email-masked]>
Date: Mon, 26 Oct 2020 19:02:22 -0700

Ideally, from an RFC Future point of view, the Editor should aim for
support of work that would reduce the confusion surrounding the use of XML
+ SVG and a custom toolset that makes network engineers also become
document engineers.

I had hoped at one time that the WPACK working group (if it is one) might
solve the problem of opening up ebook by being reliable enough to compete
with PDF/A, and simple enough to author and render to displace XML and SVG
(and to extract text from well enough to make people with unmaintainable
downstream processing elements to not be upset.

It might be hard to fit all those requirements in, but it seems feasible
enough to hope for.
I say ebook because when i last looked, it was closer to the starting point
and in the right direction (I imagine because of 'book' requirements it has
a better choice of SVG allowed vocabulary). But do you agree with the end
point goal?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 19:20:17 +1300

> It’s not easy synchronizing page numbers between two paginated outputs if rendered objects are allowed to have different dimensions (e.g. ASCII art in TXT vs SVG in PDF).

Exactly. That's why any reference to page numbers is potentially misleading, because the page number depends on the presentation mechanism.

(For archaeologists, this issue came up in mid-2014 on the rfc-interest list and the relevant text in RFC7994 goes back to draft-flanagan-plaintext-03 in September 2014. Of course, we could relitigate this now that there is finally running code.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 19:35:54 +1300

Hi John,
On 27-Oct-20 13:49, John C Klensin wrote:
> and only then page numbering

And if you were to seek out my comments in June 2014, you'd see that
my view was that all I really wanted was pagination using Form Feed
characters.

Where it got tricky, IMHO, is when PDF was added in as a supported
presentation format, because PDF is intrinsically paginated (OK,
somebody may tell me that isn't strictly true, but it seems to be
true in practice). So whether the page numbers are printed or not,
they are *there* in PDF.

> (which I tend to use only for

If running code shows that there are problems with the current
format as defined in RFC7994, then we should certainly revisit
the claimed consensus. Unlike the canonical XML of an RFC, the
presentation format isn't frozen, afaik.

Regards
   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 Oct 2020 10:37:58 -0700

> *whatever* is not reasonable. ... A table of contents, in short.

<doh>  no can do.  might make document more useful. </snark>

and if you drop it on the floor, you can put it in the card sorter.  oh
wait.  :)

what i find shocking here is the "we know best, and you will not be
allowed attitude," an authoritarianism which seems to have become
more and more popular.

randy, going back under my rock

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 13:42:15 -0400

You’re perfectly allowed. Use enscript, or whatever pagination tool you want. The issue is not that you aren’t allowed—it’s that if the IETF provides a pagination tool, we will be perceived as having provided page numbers, and those page numbers may then be used when referencing documents. By making you take the step of paginating, we avoid that worry.

Of course, if your goal is just to be annoyed at dem kids, please continue… :)

> On Oct 27, 2020, at 1:37 PM, Randy Bush <[email-masked]> wrote:
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Oct 2020 13:43:42 -0400

References to RFC text should be in terms of section numbers rather than 
page numbers.   However, that the current RFC page formatting (for PDF 
RFCs) isn't well designed for reading on paper, because page footers 
don't include section numbers.   Without such footers, it's harder to 
flip pages looking for the desired section.    So I would welcome 
changes to the RFC footers of paginated RFCs to include section numbers.

Section numbers aren't sufficient, however, if one needs to reorder 
pages from a printed RFC, because a section may span multiple pages.  So 
there is still a need for page numbers in paginated RFCs.

Also, not all sections in recent RFCs are numbered, and this is a 
problem if one wishes to reference an unnumbered section.   I suspect 
the fix here is to explicitly number/label every section, even 
Acknowledgments, appendices, etc.

One problem with having page numbers is that different paginated 
renderings of the same RFC will likely result in different pagination.   
But if there's only one paginated rendering of any RFC, as seems to be 
the case for newer RFCs at least, this is not a problem.

The currently official "plain text" RFCs are not paginated, but the PDF 
versions are paginated with page numbers.     This seems like a good 
compromise (even if it breaks some old scripts), because Windows systems 
have historically been too broken to properly print paginated plain text 
with formfeeds anyway, and because one of the uses of plain text RFCs 
has always been for automated free-text searching in which page breaks 
are a nuisance.

I would like it if HTML versions of RFCs were paginated when printed 
(with footers containing section numbers and page numbers, and with 
those page breaks and numbers aligned with other paginated versions of 
the same RFC.)    But I recognize that this would require significant 
tooling effort, and could occasionally produce very unsatisfactory 
results despite that effort.   It seems like the PDF version is 
sufficient for printing purposes, though it is not as easily found from 
the HTML version as it might be.   Adding a link to the PDF version at 
the top of the HTML version would IMO be a good idea.

Keith

---

From: John Scudder <[email-masked]>
Date: Tue, 27 Oct 2020 17:54:33 +0000

As a reminder for those who have lost track, this thread was kicked off by Toerless saying he would like to be able to render his own copies to include a useful table of contents, for his own use, at home, probably with the blinds drawn to keep the world from witnessing his shame. A little while later Henrik said in no uncertain terms that adding the capability to xml2rfc would be trivial, and that he’d be happy to do it, but that he was specifically directed not to do so.

So far, nobody has even attempted to justify this directive, although a zoo of straw men has been paraded through the subsequent follow ups. 

—John

> On Oct 27, 2020, at 1:42 PM, Ted Lemon <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
>> https://urldefense.com/v3/__https://www.rfc-editor.org/mailman/listinfo/rfc-interest__;!!NEt6yMaO-gk!VIhQWQApr4DvECYK83EOx4p68Kxuixee5QgwjzWjYc2kt0IuDGK6SspEWifMgQ$

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 13:59:39 -0400

> So far, nobody has even attempted to justify this directive, although a zoo of straw men has been paraded through the subsequent follow ups. 

Actually, John, I have explained the reasoning behind this twice, as have several other people. If the IETF provides a pagination tool, then people will use it and assume that the page numbers rendered in their version of the document are good to use in referencing the document.

Whether this is a valid concern or not, I can’t say, but that is the justification.

---

From: John Scudder <[email-masked]>
Date: Tue, 27 Oct 2020 18:09:22 +0000

On Oct 27, 2020, at 1:59 PM, Ted Lemon <[email-masked]> wrote:

On Oct 27, 2020, at 1:54 PM, John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
So far, nobody has even attempted to justify this directive, although a zoo of straw men has been paraded through the subsequent follow ups.

Fair enough. I think this was lost on me for two reasons. The first is the use of the term “pagination”, which means something different from “creation of a table of contents” (I just looked it up to be sure), although admittedly you can’t make a usable ToC unless the document is paginated first. The second is that I didn’t actually imagine it could be seen as a plausible reason to prevent people from producing their own unofficial versions in the privacy of their homes. I stand corrected.

Needless to say, the concern does not seem valid to me.

—John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 14:16:01 -0400

> Needless to say, the concern does not seem valid to me. 

I think there’s legitimate cause for debate on this question; I’m not sure what the correct venue would be, however.

One solution would be for Henrik to simply document how to patch xml2rfc to enable pagination and page numbers in the TOC. At that point, anybody paginating a document would have to read the instructions for how to modify xml2rfc, which could include clear instructions on how to treat the output in terms of referencing it.

I think the main argument for doing this and not simply asking Henrik to fix the primary source is that there really aren’t that many people who rely on this feature, and so even though those people would benefit significantly from a fix, the overall risk really does outweigh the benefit. Of course, there’s no way to quantify the risk, so this can never go beyond conjecture, which means that ultimately the decision is a judgment call, not math.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Oct 2020 12:26:50 -0700

> changes to the RFC footers of paginated RFCs to include section numbers.

That is an interesting idea!  I want to say that I would find it useful,
but I am actually having a hard time imaginging what it would feel like to
have them present -- I might need to see it in action to know how I would
react.

> there is still a need for page numbers in paginated RFCs.

The act of pagination induces numberings, and not recording those numbers
in-band seems risky, yes.

> The currently official "plain text" RFCs are not paginated, but the PDF 

I do want to check in what sense you use the term "official", here -- my
understanding is that the party line is that the XML source is the
authoritative version and that the rendered versions can be regenerated
arbitrarily if there is new tooling deemed to produce "better" output.
(IIRC this was even supposed to happen or did happen for the PDF output,
which due to an error was not actually using the PDF/A stuff that it was
supposed to.) So there can be an "official" plain text version in that it
is on the RFC Editor's website, but it is not authoritative or immutable.

Thanks,

Ben

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Oct 2020 15:40:01 -0400

> is on the RFC Editor's website, but it is not authoritative or immutable.

I would consider that an unfortunate departure from the longstanding 
useful tradition that RFCs, once published, aren't revised in place.

The XML version should be irrelevant for most purposes.   Nobody looks 
at it.

Keith

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Oct 2020 15:48:07 -0400

Ben,

So there can be an "official" plain text version in that it
> is on the RFC Editor's website, but it is not authoritative or immutable.

There already is an official plain text rendering on the RFC
Editor's website. See, for example,
https://www.rfc-editor.org/rfc/rfc8905.txt, and
https://www.rfc-editor.org/info/rfc8905, which has the button to press to
get it.

That said, the plain text version is the least useful rendering for
reading, since it can't include any SVG drawings. It's really only useful
as input to rfcdiff. If you want to read on a screen, use the HTML
rendering, and if you want to print it, use the PDF rendering.

Cheers,
Andy

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Oct 2020 13:07:03 -0700

> https://www.rfc-editor.org/info/rfc8905, which has the button to press to

Right.  My point is that it is only "official" in scare quotes, since it's
not the immutable archival artifact representing the RFC.

> rendering, and if you want to print it, use the PDF rendering.

Of course.

-Ben

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2020 20:18:11 -0000

In article <[email-masked]>,
>not the immutable archival artifact representing the RFC.

There's a whole separate can of worms about how and if we would
recreate the rendered versions of RFCs if, say. we made a change to
xml2rfc that improved the results, or we found a bug that messed up
one of the outputs.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Andrew Campling <[email-masked]>
Date: Tue, 27 Oct 2020 22:09:30 +0000

As general comment on the topic, I have to say that I'd never thought of either page numbers nor indeed pagination to be remotely controversial topics.  Clearly this debate is proving otherwise!  

For those of us that might prefer to read printed documents, especially documents of more than a few pages in length, page numbers are particularly help to ensure that the order of the documents does not become jumbled.  Those that appear to be taking a position that pagination is obsolete might want to reflect on the importance of making IETF materials readily accessible to a wider audience, many of whom may be accustomed to printable documents with tables of contents inclusive of page numbers, pages with footers incorporating page numbers etc.  

Andrew

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: 26 October 2020 21:33
To: Brian E Carpenter <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Poll: RFCs with page numbers (pretty please) ?

Grüße, Carsten

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Oct 2020 10:13:49 +1100

There are several over lapping issues here.  There is PFD for different
media involved here.  Screen really is different to print.  The current
PDF is laid out for screen, the same as the HTML version is laid out for
screen.  There are internal linkages in the TOC to get to the right section
in the TOC without page numbers.  That is fine for screen.

PDF for print the TOC needs page numbers to optimally navigate to the
correct page.  Navigating by section on page headers, footers is
sub-optimal.

There really is no reason more forms can’t be produced.  Disk space is
cheap as is creating links to multiple forms [PDF screen] [PDF A4] [PDF
Letter].

For referencing we actually should consider adding paragraph numbers as
that should eliminate the perceived need for page numbers by providing
finer grained referencing.

e.g. Section [Number] Title [Paragraph <number>]

If people say page X, just push back with “section (number and title) and
paragraph please”.  People do learn.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Oct 2020 15:27:15 +1300

> As a reminder for those who have lost track, this thread was kicked off by Toerless saying he would like to be able to render his own copies to include a useful table of contents, for his own use,…

Not speaking for anybody except myself, I'll simply observe that the tools people were asked to go and implement the RFCs that were published after a public comment period (as Robert pointed out), and one of those RFCs specified a txt format without page numbers. So that's what got done. Not everybody agreed with that choice at the time, and evidently not everyone agrees with it now, but it wasn't decided in secret.

> So far, nobody has even attempted to justify this directive, although a zoo of straw men has been paraded through the subsequent follow ups. 

The directive was "please implement the RFCs". If I understand correctly, that was budgetted and paid for. As far as I can see there's nothing in those RFCs that even purports to forbid other formats being generated, but there *is* a rational argument against page numbers that's been made here, and the same argument applies against line numbers. If you want something more precise than section numbers, the only portable one I can envisage is paragraph numbers. That has a good chance of working across all formats.

   Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 27 Oct 2020 23:16:53 -0400

On 10/27/2020 10:27 PM, Brian E Carpenter wrote:
>   If you want something more precise than section numbers, the only portable one I can envisage is paragraph numbers. That has a good chance of working across all formats.

I like that as a permanent reference value - its obviously a stable 
number for any given document and easily tracked or created from the 
source/canonical document.

Maybe we provide that as a fixed reference in a TOC for a particular 
paginated version along with the option to have a second value 
indicating the local page number for that version (Cake and eat it 
too...?)  E.g.:

2.3. Arguments Against Page Numbers ........... L25 (pg 4)
2.3.1 Stare Decisis ........................... L28 (pg 4)

I guess you could also automatically generate a per-paragraph anchor for 
HTML documents.

Note:  I'm actually fine with no page numbers, but I do see the 
arguments for them.  I kill a lot of trees marking up documents, just 
because its easier to spread out the pages and see the relationships 
between the sections and text and page numbers can be useful for 
collation at least.

Later, Mike

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 28 Oct 2020 05:41:57 +0100

On Wed, Oct 28, 2020 at 03:27:15PM +1300, Brian E Carpenter wrote:
> > As a reminder for those who have lost track, this thread was kicked off by Toerless saying he would like to be able to render his own copies to include a useful table of contents, for his own use, at home, probably with the blinds drawn to keep the world from witnessing his shame. A little while later Henrik said in no uncertain terms that adding the capability to xml2rfc would be trivial, and that he???d be happy to do it, but that he was specifically directed not to do so.

Actually, my original question was what it would take for IETF
(tools/datatracker) to provide such renderings.

> Not speaking for anybody except myself, I'll simply observe that the tools people were asked to go and implement the RFCs that were published after a public comment period (as Robert pointed out),…

This is probably true but does not cover what i think is the problematic
part of what seems to have happened: Not the choice of initial renderings
to be supported on IETF web pages, but a strong belief that renderings
with specific other renderings (such as page numbers) must be prohibited
because they supposedly create problems. Whereas the arguments for those
problems where seemingly debunked repeatedly. As well as "mayority should
prefer our choosen rendering (no pagination)", so why do another rendering
for a minority. Which does not seem to be very inclusive.
> The directive was "please implement the RFCs". If I understand correctly, that was budgetted and paid for. As far as I can see there's nothing in those RFCs that even purports to forbid other forma…

I agree that those RFCs would not prohibit additional renderings,
but John Levines, your and other participants reactions makes it sound
very likely that there would be resistance against any (RFC) level ask
for such additional rendering (including your prior paragraph: you don't
like it, so you will fight against it - it being page numbers). Including
the fact that any such RFC would have to be driven by IAB, and IAB might
also simply go on whatever they feel is required by the community instead 
of consulting with it in this instance.

Cheers
    Toerless

> > ???John
> >> ???[External Email. Be cautious of content]
> >>
> >>
> >> You???re perfectly allowed. Use enscript, or whatever pagination tool you want. The issue is not that you aren???t allowed???it???s that if the IETF provides a pagination tool, we will be perceived as having provided page numbers, and those page numbers may then be used when referencing documents. By making you take the step of paginating, we avoid that worry.
> >>
> >> Of course, if your goal is just to be annoyed at dem kids, please continue??? :)
> >>

-- 
---
[email-masked]

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 28 Oct 2020 09:20:52 +1000

On Wed., 28 Oct. 2020, 08:10 Andrew Campling,
<[email-masked]> wrote:

>
> For those of us that might prefer to read printed documents, especially
> documents of more than a few pages in length, page numbers are particularly
> help to ensure that the order of the documents does not become jumbled.
> Those that appear to be taking a position that pagination is obsolete might
> want to reflect on the importance of making IETF materials readily
> accessible to a wider audience, many of whom may be accustomed to printable
> documents with tables of contents inclusive of page numbers, pages with
> footers incorporating page numbers etc.
>
>
When I print a text document from Notepad I have to jump through hoops to
get it to _not_ include magic page headers and footers (incl. page
numbers). It does this consistently whether I set my font to 8pt courier or
18pt open-sans. It would probably work for other fonts too. Trying to
include that kind of layout information in the document itself is only ever
a cause for conflict.

For a tool-generated format that includes layout metadata in a portable and
printable way (that, incidentally, also includes any pretty pictures in the
document) there is the PDF version, which seems like a much better fit for
the use case you're describing.

Aside: PDF can also be coerced to support the hot new "hyperlinking"
mechanism, if we ever decide to pursue that. (Probably not in printed
media, though.)

Page numbers are obsolete -- or were never relevant -- in HTML, and have
been questionable in plain text since we moved from fixed-grid console and
print machines.

Cheers
Matthew Kerwin