Subject: Re: [rfc-i] [irsg] Resending: Page numbers in RFCs questions / preferences

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 13:55:40 +0100

On 2020-10-26, at 11:51, David Noveck <[email-masked]> wrote:
> 
> I think it happened with the conversion to v3 xml.  At that time, the 72-character-ragged-right .txt format ceased to be considered canonical (long overdue in my opinion).  As a result, in accord with some RFC that I was pointed to, a decision was made (by whom it wasn't clear) to make all TOCs the same, so that the pdf and text TOCs lost theirs since there was no way to add them to html which doesn't have them.  The logic is impeccable if you grant the premises and nobody ever considered rethinking the premises when it resulted in nearly useless printed documents. Sigh!

Obviously, with canonical XML, there is no good solution to this problem: Different renditions will have different concepts of pages, so the TOC’s won’t align.

(That is not a good argument for then finally choosing what is probably the worst possible solution to this problem.  I think what happened is that nobody thought about PDF where we continue to have pages, so there never really was a problem specific to retaining pages and thus page numbers in the TXT.)

Grüße, Carsten

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Oct 2020 14:16:11 +0100

Am 26.10.2020 um 13:55 schrieb Carsten Bormann:
> ...

Fun fact: RFC 7994 ("Requirements for Plain-Text RFCs") says in
<https://greenbytes.de/tech/webdav/rfc7994.html#rfc.section.4.2>:

"In order to retain similar content wherever possible between the
various publication formats, the table of contents will list section and
subsection numbers and titles but will not include page numbers."

But RFC 7995 ("PDF Format for RFCs") say in
<https://greenbytes.de/tech/webdav/rfc7995.html#n-similarity-to-other-outputs>:

"The table of contents (generated if the XML's <rfc> element's
tocInclude attribute has the value "true") [RFC7991] will have the
section number linked to the section start but will also include a page
number that is linked to the corresponding page. The section title and
the page number will be separated by a visually appropriate separator,
and the page numbers will be aligned with each other."

And, FWIW, RFC 7992 ("HTML Format for RFCs") says nothing about page
numbering. And that is the case not because it's not possible in HTML,
but just a CSS/output format issue. Given the right CSS (as produced by
rfc2629.xslt) and the right HTML-to-PDF converter (such as PrinceXML),
you will indeed get page numbers.

Best regards, Julian

PS: and yes, page numbers should not be used to refer to parts of the
RFC, because page breaks vary with output formats
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 14:29:20 +0100

> RFC, because page breaks vary with output formats

BTW, that can be defused a bit by qualifying the assigned page numbers with the formats, e.g., page 6T (.TXT) or 9P (.PDF).  These will change when the rendition changes, but then there are 26 ASCII letters we can rotate through.

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 09:28:14 -0700

On Mon, Oct 26, 2020 at 04:02:41PM +0100, Toerless Eckert wrote:
> Is there any reason why the tools team would not be able to produce
> a rendered version that does incude page numbers ? PDF and txt ?
> Call it RFC classic format ?

IIRC the xml2rfc tool already supports the pagination functionality with a
command-line argument, so you can make your own right now.
Unfortunately, I was unable to find the exact incatation in the mail
archives within the time I allotted for searching.

-Ben

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 26 Oct 2020 18:11:12 +0100

Hi,

xml2rfc currently supports pagination of .txt output for drafts, but not
for RFCs.  This is a limitation originally requested by the RFC editor, in
the specification for the v3 text formatter work for RFCs.

A couple of months ago, prompted by multiple requests for the ability to
produce paginated .txt output for RFCs, I asked for permission to enable
pagination also for RFCs, but in the end the RSOC answered that they did
not want to make it possible to generate paginated .txt output for RFCs.

John Levine should be able to give further information.

I'd be perfectly happy to add the ability; given that it's available for
drafts it's trivial from a technical viewpoint.

Best regards,

	Henrik

On 2020-10-26 17:40, Toerless Eckert wrote:
> Thanks, Ben. 
> 
> Then i guess it shouldn't be too hard for the tools team to
> offer at least on tools.ietf.org beside the existing formats one
> with e.g.: text with pagination...
> 
> I guess i'll have to ask Henrik how best to proceed.
> 
> Cheers
>     Toerless
> 
> On Mon, Oct 26, 2020 at 09:28:14AM -0700, Benjamin Kaduk wrote:

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 13:35:43 -0400

> 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 12:44:04 -0500

John - you've answered why RFCs are not published with page numbers and 
where/when the community discussion that took place for that decision.

You haven't answered whether/how the RSOC engaged the community on the 
question of whether the tools should let someone produce an RFC locally 
that has page numbers in it for themselves if they want to. The 
reasoning for not letting the tools produce such a thing is certainly 
not explicitly captured in the series of RFCs you point to.

Julian has alluded to the principle behind the pressure already, but I'm 
still at a small loss for why RSOC, or the RSE, should care about what 
people make for themselves?

RjS

On 10/26/20 12:35 PM, John R. Levine wrote:
> archives.  Henrik knows all of this and I cannot imagine why he did 
> not tell you the same thing.
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 18:45:31 +0100

On 2020-10-26, at 16:04, David Noveck <[email-masked]> wrote:
> 
> Obviously, with canonical XML, there is no good solution to this problem: 
> 
> It's not clear what problem you are referring to.

The problem will become very evident once you get an RFP asking that your product implement the procedure on page 68 of RFC 9815.

You cannot really argue this based on whether people SHOULD be using section numbers etc.  This is a real downside in the real world.

Now whether that downside is overriding all the other upsides of having page numbers, can be a subject of discussion.

Grüße, Carsten

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 13:47:39 -0400

> question of whether the tools should let someone produce an RFC locally that 
> has page numbers in it for themselves if they want to. The reasoning for not 
> letting the tools produce such a thing is certainly not explicitly captured 
> in the series of RFCs you point to.

I am not Heather and I do not remember all the details, but I cannot 
imagine why you would want to reopen this can of worms.

People can write whatever they want for their own use, but the tools we 
are paying for produce the output formats that our consensus documents 
describe.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Oct 2020 12:53:33 -0500

On 10/26/20 12:47 PM, John R. Levine wrote:
>> John - you've answered why RFCs are not published with page numbers 
>> and where/when the community discussion that took place for that 
>> decision.
>>
>> You haven't answered whether/how the RSOC engaged the community on 
>> the question of whether the tools should let someone produce an RFC 
>> locally that has page numbers in it for themselves if they want to. 
>> The reasoning for not letting the tools produce such a thing is 
>> certainly not explicitly captured in the series of RFCs you point to.
>
> People can write whatever they want for their own use, but the tools 
> we are paying for produce the output formats that our consensus 
> documents describe.

mmm. Again, I dont think you're quite seeing this aspect of the question.

I (at least) am not trying to reopen any cans about what gets published.

But when the community asks that the tools produce something different 
for their local use, and it's easy and inexpensive to add and maintain, 
it doesn't seem like it's the right thing to do to deny it by policy.

The RFC editor does not publish an epub format, for example. If someone 
were to contribute an epub formatter that was reasonable to merge and 
maintain, we should merge that. Allowing the tools to produce page 
numbers for local use falls pretty close to that doesn't it?

RjS

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Oct 2020 18:55:08 +0100

Without taking a position about what happened in the past, if people want to have a say about how decisions are made in the future, there’s an open, community-driven program for that.[1]

Eliot

[1] https://www.iab.org/activities/programs/rfc-editor-future-development-program/

> On 26 Oct 2020, at 18:47, John R. Levine <[email-masked]> wrote:
> 
>> John - you've answered why RFCs are not published with page numbers and where/when the community discussion that took place for that decision.
>> 
>> You haven't answered whether/how the RSOC engaged the community on the question of whether the tools should let someone produce an RFC locally that has page numbers in it for themselves if they want to. The reasoning for not letting the tools produce such a thing is certainly not explicitly captured in the series of RFCs you point to.
> 
> I am not Heather and I do not remember all the details, but I cannot imagine why you would want to reopen this can of worms.
> 
> People can write whatever they want for their own use, but the tools we are paying for produce the output formats that our consensus documents describe.
> 
> Regards,

---

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

On 10/26/20 1:01 PM, Toerless Eckert wrote:
> 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:
>> archives.  Henrik knows all of this and I cannot imagine why he did not tell
>> you the same thing.
>>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Oct 2020 14:19:27 -0400

On Oct 26, 2020, at 1:53 PM, Robert Sparks <[email-masked]> wrote:
> But when the community asks that the tools produce something different for their local use, and it's easy and inexpensive to add and maintain, it doesn't seem like it's the right thing to do to deny it by policy.

My memory of this discussion is vague at this far remove, but I believe the reason not to support page numbers in the tools is that they will be used as reference points, and this will create interop problems. This would be true even if the official copy doesn’t have page numbers: if there is a tool that produces page numbers, and it’s popular, people will use it and reference the page numbers. Worse, the page numbers will be different not only between PDF and text, but also between different page sizes—8 1/2x11 vs. A4, for instance.

I’m not defending this decision, but I think this was the thinking.

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 14:24:20 -0400

> But when the community asks that the tools produce something different for 
> their local use, and it's easy and inexpensive to add and maintain, it 
> doesn't seem like it's the right thing to do to deny it by policy.

I see one grumpy author who wants page numbers.  If we're going to add 
every tweak that one person wants, it's going to get awfully expensive.

> The RFC editor does not publish an epub format, for example. If someone were 
> to contribute an epub formatter that was reasonable to merge and maintain, we 
> should merge that. Allowing the tools to produce page numbers for local use 
> falls pretty close to that doesn't it?

No, it's something the IETF explicitly considered and rejected when it 
designed the new format.

Regards,

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Oct 2020 14:25:21 -0400

> The problem will become very evident once you get an RFP asking that your product implement the procedure on page 68 of RFC 9815.

Yup -- I've already run into this sort of thing when talking with
authors and others -- I used to be able to say things like "Erm,
section 3, um... just above the bottom of the page..." and now it
involves much more quoting, etc.
I also liked to collect stats on documents that I review -- e.g:
(7,635 pages, ~31" / 79cm / 15 reams of single-sided paper).
Gamifying reviews makes them easier...

I really like the concept / history / continuity of RFCs being the
same over these many years; I didn't really participate in the v3
discussions, and am sad that the page numbers and similar have
changed...
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Oct 2020 19:39:16 +0100

> involves much more quoting, etc.

In the HTML version, every block-level item (paragraph etc...) has an
anchor that you can link to.

Best regards, Julian

---

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

On 10/26/20 1:24 PM, John R. Levine wrote:
>> But when the community asks that the tools produce something 
>> different for their local use, and it's easy and inexpensive to add 
>> and maintain, it doesn't seem like it's the right thing to do to deny 
>> it by policy.
>
> I see one grumpy author who wants page numbers.

Well, again, its important to  "to be published" to be clear what you're 
talking about. I've heard more, and achieving the consensus in the 
documents for what would be published was not easy. I expect it will 
continue to be a topic of consideration, but acknowledge that for the 
published formats, changing it will require going through the full 
consensus process again.

>   If we're going to add every tweak that one person wants, it's going 
> to get awfully expensive.

That's a terrible generalization to bring to the question I was pointing 
at. _This_ tweak is extremely cheap - the code already has to produce 
these numbers for internet-drafts, so the cost is a flag.

The cost of a well-known published set of documents that look like RFCs 
but have had some changes made is different and should be addressed 
separately. (I'll point here to the inline errata for pre-v3 format rfcs.)

>
>> The RFC editor does not publish an epub format, for example. If 
>> someone were to contribute an epub formatter that was reasonable to 
>> merge and maintain, we should merge that. Allowing the tools to 
>> produce page numbers for local use falls pretty close to that doesn't 
>> it?
>

Which "it"? If you meant epub, RFC7990 says

> 7.4.  Potential Future Publication Formats
>
> 7.4.1.  EPUB
>
>     This format is intended for use by ebook readers and will be
>     available for RFCs after the requirements have been defined.  No
>     document on this topic is currently available.
That certainly isn't rejection - certainly not of creating epub, and not 
even of publishing things in epub in the long run. We had to choose what 
was feasible with the initial tooling effort, and epub didn't make 
_that_ cut.

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 14:55:16 -0400

> Which "it"? If you meant epub, RFC7990 says

No, I meant paginated text RFCs.  The arguments against them, that people 
will misunderstand what they are and use the page numbers as references, 
still seem persuasive to me.  Indeed, what else would they use them for?

Regards,

---

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

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: Ted Lemon <[email-masked]>
Date: Mon, 26 Oct 2020 14:56:43 -0400

On Oct 26, 2020, at 14:55, John R. Levine <[email-masked]> wrote:
> 
> Indeed, what else would they use them for?

Finding something that’s listed in the TOC.

---

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

On 10/26/20 1:55 PM, John R. Levine wrote:
>>> No, it's something the IETF explicitly considered and rejected when 
>>> it designed the new format.
>>
> No, I meant paginated text RFCs.  The arguments against them, that 
> people will misunderstand what they are and use the page numbers as 
> references, still seem persuasive to me.
Good. Given that this question has come up, again, perhaps we should 
document this in a reference-able format? A short draft documenting why 
the ietf infrastucture isn't providing such a thing, with a 
recommendation that nobody else does either perhaps?

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Oct 2020 19:00:14 -0000

Are we having this discussion again?
It seems that all the arguments against are being put forward, but that the
people who like the idea are being told to not reopen the debate.
Best,
Adrian

-----Original Message-----
From: rfc-interest <[email-masked]> On Behalf Of John
R. Levine
Sent: 26 October 2020 18:55
To: Robert Sparks <[email-masked]>; [email-masked];
Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [rfc-i] John/rsoc: Re: Page numbers in RFCs questions /
preferences

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for
Dummies",

---

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Oct 2020 14:09:59 -0500

On 10/26/20 2:03 PM, Toerless Eckert wrote:
> On Mon, Oct 26, 2020 at 01:43:33PM -0500, Robert Sparks wrote:
>> talking about. I've heard more, and achieving the consensus in the documents
>> for what would be published was not easy. I expect it will continue to be a
>> topic of consideration, but acknowledge that for the published formats,
>> changing it will require going through the full consensus process again.
> Who could point me to an RFC and a page# in that RFC (;-) that does
> actually include the magical words like "THERE SHALL BE NO RFC
> REPRESENTATION WITH PAGE NUMERS" ? Would really appreciate not having
> to read through the whole list of the RFC.

7990 section 7.3

7994 section 4.1 (doesn't mention page numbers explicitly, but their 
absence is a direct consequence of this section's requirements).

>
> Technically, a small RFC doing an update on this with e.g.: a text format
> with the traditional pre-reorg formatting and any derived renderings that
> do not change the pagination - would be quick to write. But if this
> has to be driven by IAB,
It would.
>   then we're probably out of luck anyhow. If
> this could be driven by the community, i wonder what WG it would need to
> go to to have ough consensus applied to it.
>
> Cheers
>      Toerless
>
>>>    If we're going to add every tweak that one person wants, it's going to
>>> get awfully expensive.
>> That's a terrible generalization to bring to the question I was pointing at.
>> _This_ tweak is extremely cheap - the code already has to produce these
>> numbers for internet-drafts, so the cost is a flag.
>>
>> The cost of a well-known published set of documents that look like RFCs but
>> have had some changes made is different and should be addressed separately.
>> (I'll point here to the inline errata for pre-v3 format rfcs.)
>>
>>>> produce page numbers for local use falls pretty close to that
>>>> doesn't it?
>> even of publishing things in epub in the long run. We had to choose what was
>> feasible with the initial tooling effort, and epub didn't make _that_ cut.
>>
>>> Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 20:23:08 +0100

> Are we having this discussion again?

Yes.

> people who like the idea are being told to not reopen the debate.

There is no point in discussing this as an operational concern for RPC or the tools team.
RFC 799x is clear (maybe inconsistent, broken, I-don’t-like-it; but clear).

However, many people who have to use RFCXMLv3 sense that it is time for an RFCXMLv4 (or 3.1, or 3 post-beta, ...) discussion.
That would indeed be the time to look at the experience with v3 as documented in 799x and learn from it.

Grüße, Carsten

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 15:25:46 -0400

> Good. Given that this question has come up, again, perhaps we should document 
> this in a reference-able format? A short draft documenting why the ietf 
> infrastucture isn't providing such a thing, with a recommendation that nobody 
> else does either perhaps?

I suppose.  I took another look at RFC 7994 which is not as clear as it 
might be, although RFC 7990 says just above the bit about epub

    o  An unpaginated plain-text file will be created.

    o  Running headers and footers will not be used.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 15:42:40 -0400

> That would indeed be the time to look at the experience with v3 as documented in 799x and learn from it.

I wouldn't disagree but we still need to catch up with the differences 
between v3 as documented and v3 as implemented.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Oct 2020 20:46:38 +0100

Am 26.10.2020 um 20:42 schrieb John R. Levine:
>> However, many people who have to use RFCXMLv3 sense that it is time
>> for an RFCXMLv4 (or 3.1, or 3 post-beta, ...) discussion.

Not to mentopion the differences between these two and "v3-as-it-should
be"...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 20:47:44 +0100

On 2020-10-26, at 20:46, Julian Reschke <[email-masked]> wrote:
> be"…

Well, that is the v3 post-beta discussion, and I’m not clear that this is (should be) different from the v4 discussion.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Oct 2020 20:54:46 +0100

> On 2020-10-26, at 20:53, Toerless Eckert <[email-masked]> wrote:
> 
>> Well, that is the v3 post-beta discussion, and I???m not clear that this is (should be) different from the v4 discussion.
> 
> "v4" is probably the key word to push off undesired ideas.

OK, so make it 3.1.
3.0.1, if need be :-)

Grüße, Carsten

---

From: Jay Daley <[email-masked]>
Date: Tue, 27 Oct 2020 08:56:22 +1300

> On 27/10/2020, at 8:51 AM, Toerless Eckert <[email-masked]> wrote:
> 
> On Mon, Oct 26, 2020 at 02:09:59PM -0500, Robert Sparks wrote:
>> 7994 section 4.1 (doesn't mention page numbers explicitly, but their absence
>> is a direct consequence of this section's requirements).
> 
> Thank, Robert
> 
> Section 4. of 7994 mentions a paginated text format (58 lines/page at most).
> Where are those text files ?

On the canonical site.  e.g. https://www.rfc-editor.org/info/rfc7994 <https://www.rfc-editor.org/info/rfc7994>

Jay

> ---
> [email-masked] <mailto:[email-masked]>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 16:16:44 -0400

>>> Where are those text files ?

In the Internet Draft repository.  That's the text in 7994 that I said 
wasn't as clear as it could be -- if you want the text version of your I-D 
paginated, xml2rfc can do that.

Again, we had a long process leading to these policies and I really do not 
think it is a good use of our time to reargue the details four years 
later.

Regards,

---

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

On 27-Oct-20 08:10, Toerless Eckert wrote:
> Brian:
> 
> RFC editor can easily check that new RFC will not have references to
> other RFCs with page numbers.

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

> 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.

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

> 
> Cheers
>     Toerless
> 
> On Tue, Oct 27, 2020 at 07:56:36AM +1300, Brian E Carpenter wrote:

---

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

https://www.rfc-editor.org/info/rfc8798 is a current example. To make the point clear, if I refer to "Table 2 in RFC 8798" that is unambiguous, but if I refer to "the table on page 6 of RFC 8798" that only works if the reader happens to find the PDF version, and it would probably be wrong for a paginated txt version.

Regards
   Brian Carpenter

On 27-Oct-20 08:56, Jay Daley wrote:
> 
> 
>> On 27/10/2020, at 8:51 AM, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>>
> On the canonical site.  e.g. https://www.rfc-editor.org/info/rfc7994
> 
> Jay
> 
>>
>> Cheers
>>    Toerless
>>
>>>>>> John Levine, [email-masked] <mailto:[email-masked]>, Primary Perpetrator of "The Internet for
>>>>>> Dummies",
> [email-masked] <mailto:[email-masked]>
> 
>

---

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:
>>
> 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.

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: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Oct 2020 21:38:27 -0000

Hey Jay,

7990 section 7.3

While the RFC you point to has exactly the format that Toerless might want
to see, it (perhaps naturally) pre-dates the changes that it describes.

So, if you go to (for example) https://www.rfc-editor.org/info/rfc8905
you'll find a link to a text file that lacks the pagination.

Now, that might be moot given the later discussion of what 7994 was trying
to talk about.

Cheers,

Adrian

---

From: Jay Daley <[email-masked]>
Date: Tue, 27 Oct 2020 10:43:13 +1300

> On 27/10/2020, at 10:38 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hey Jay,
> 
> While the RFC you point to has exactly the format that Toerless might want to see, it (perhaps naturally) pre-dates the changes that it describes.
>  
> So, if you go to (for example) https://www.rfc-editor.org/info/rfc8905 <https://www.rfc-editor.org/info/rfc8905> you’ll find a link to a text file that lacks the pagination.
>  
> Now, that might be moot given the later discussion of what 7994 was trying to talk about.

Yes I assumed that 7994 would apply to itself.  My love of recursion getting the better of me.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 14:51:17 -0700

On Mon, Oct 26, 2020 at 05:48:15PM -0400, Jeffrey Haas wrote:
> On Mon, Oct 26, 2020 at 06:36:19PM +0000, Acee Lindem (acee) wrote:
> > I wasn't involved in the RFC format discussion either but can't see how
> > removing the pagination could have been seen as an advantage.
> > Additionally, it is annoying that the htmlized version don't provide links
> > to sections/sub-sections from TOC. 
> 
> I understand why the page numbers were removed.  I think you're getting to
> the more core issue: There is a need to provide a way to refer to portions
> of documents easily.
> 
> For individual sections, the TOC absolutely should provide linkage to
> sections, especially in formats like HTML.

The native HTML format does.  I have no idea why the htmlization script
can't or does not do so for new-format RFCs.

> The input XML already provides blocks.  It should be fairly reasonable for
> the tool to provide you something like "this is section X.Y, ¶5".

Like https://www.rfc-editor.org/rfc/rfc8815.html#section-3.1-5 ?

-Ben

> How such a thing would eventually manifest in our old school email
> discussions is likely to be the ugly discussion.
> 
> -- Jeff
>

---

From: "John R. Levine" <[email-masked]>
Date: 26 Oct 2020 17:52:25 -0400

>> 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…

This whole argument seems to miss a large part of the motivation for the 
new RFC format.  These days, most people read RFCs on screens, not on 
paper.  I can't remember the last time I printed out an RFC, but I look at 
them on my computer screen or my tablet all the time.  That's why we have 
the HTML and PDF formats that display well on screens, and the HTML even 
adjusts dynamically to the window size.  It's also why they have a table 
of contents that links to document sections. When looking at either the 
HTML or the PDF, you can click on a TOC entry and go directly to that part 
of the document.  As Julian mentioned, every section header has an anchor 
so you can share the links with other people.

While I can believe that some people still print out RFCs to read, it is 
surely shrinking as those of us old enough to remember the smell of ditto 
fluid are supplanted by people who've grown up with laptops and tablets.

Regards,

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 26 Oct 2020 14:53:46 -0700

> Gamifying reviews makes them easier...

I suggest a new metric instead to measure length: the "PoN".

1 PoN = the length of our largest RFC to date (where today becomes the
equivalent of Jan 1, 1970 is for seconds): RFC8881 (NFS version 4 minor
version 1 protocol) in txt format.  Thus, 1 PoN = 1593486 octets or
31832 lines.

Then we can measure the length of any other document based on this
length.  Thus, RFC3514 ("The Security Flag in the IPv4
Header."), which is 11211 octets or 339 lines becomes ".0070:.0106 PoN".
-- 
Wes Hardaker
USC/ISI
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

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 10/26/20 5:14 PM, John Scudder 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
>
> 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: 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: Wes Hardaker <[email-masked]>
Date: Mon, 26 Oct 2020 15:49:48 -0700

Toerless Eckert <[email-masked]> writes:

> Obviouosly the point of reference needs to be a universal constants
> of the IETF universe. Hence the size of documents needs to be measured
> relative to rfc8200.

Are you telling me that all operators had to do in order to switch
versions was multiple IPv4 by 1.0185 to upgrade to IPv6?  Nice.
-- 
Wes Hardaker
USC/ISI
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

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: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 16:53:41 -0700

On Mon, Oct 26, 2020 at 06:24:27PM -0400, John Levine wrote:
> In article <[email-masked]> you write:
> There is no htmlization script for new-format RFCs. The HTML format is
> produced directly from the XML and has all the links you'd expect, as
> does the PDF. The text format loses a lot of info visible in the other
> formats so it is a third-best option.
> 
> I suppose you could render to text and try to htmlize that but it's
> hard to imagine a reason to do so.

I don't know what https://tools.ietf.org/html/rfc8815 is (conveniently
linked from https://datatracker.ietf.org/doc/rfc8815/ as "htmlized") if not
trying to htmlize the text copy.  I am well aware that the new format
produces direct ("native") HTML output, and indeed was attempting to point
Jeff towards the native HTML output.

-Ben

---

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: 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: 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: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2020 18:11:25 +1300

> Jeff towards the native HTML output.

Right. I think we should debate whether it's a good or a bad idea to run
the htmlization script on v3 format documents. I'd say "bad" because all
it does is create confusion.

Running rfcdiff on the plain text version is very useful, however.

    Brian

---

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: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Oct 2020 11:00:14 -0400

> Running rfcdiff on the plain text version is very useful, however.

I prefer to use the htmlized version when reviewing documents, for a 
variety of reasons:

- it has all those handly links at the top, notably for the diffs, 
tracker, etc. So with one click I can bring up the diff showing the most 
recent changes.

- it has hot links from the TOC to the sections so that is easily navigated

- it is laid out just like the text version. I can cut out sections that 
I want to comment on and paste them into an email while retaining the 
formatting. (I prefer to use the side by side diffs when reviewing 
changes, but often then need to consult the full version for more 
context. Having the full version match what the diff used is important 
for this.)

Hence I would definitely like to have the htmlized format continue to be 
available for v3 documents. Since it is created from the txt format I 
don't see why it is harder to produce than for v2 documents.

OTOH, I do now prefer the native html version when reading/consulting a 
document.

	Thanks,
	Paul

---

From: David Noveck <[email-masked]>
Date: Mon, 26 Oct 2020 06:51:36 -0400

On Sun, Oct 25, 2020, 10:04 PM Toerless Eckert <[email-masked]> wrote:

> Sent this question originally only to rfc-interest mailing list,

I suppose that, officially speaking, that is the right mailing list.

but never
> received a reply.

I used to feel bad that I didn't pursue this on rfc-interest, but I now see
this would have been a waste.  Thanks for trying.

Resending now also to wgchairs.

You'll get at least one response.

>
> Thanks for any replies to my questions or suggestions what i could try to
> do to get more page numbres back into the non-PDF output formats.
>
> Cheers
>     Toerless
>
> On Thu, Sep 24, 2020 at 08:57:33AM +0200, Toerless Eckert wrote:
> > Sorry for being asleep at the wheel,

I think it is OK relying on a self-driving process in this case, since
there was no possibility of death or physical injury.

but i am just recognizing that newer
> > RFCs on tools, datatracker and even in PDF formats do not have page
> numbers
> > in their TOC, and that the original RFCs on rfc-editor do not even
> > have any TOC. Nor is there any pagination in any of the text or html
> > renderings and hence no notion of size/pages. One has to click to the
> > pdf rendering, and scroll to the bottom to know the size of a document.
> >
> > When did this change happen, where was it discussed ?
>

I think it happened with the conversion to v3 xml.  At that time, the
72-character-ragged-right .txt format ceased to be considered canonical
(long overdue in my opinion).  As a result, in accord with some RFC that I
was pointed to, a decision was made (by whom it wasn't clear) to make all
TOCs the same, so that the pdf and text TOCs lost theirs since there was no
way to add them to html which doesn't have them.  The logic is impeccable
if you grant the premises and nobody ever considered rethinking the
premises when it resulted in nearly useless printed documents. Sigh!

> > In my defense,

Why would you need a defense? Do you feel under attack?

even though i just had an rfc recently (rfc8815), this
> > whole formatting change totally flew by me even when reviewing changes
> with
> > RFC editor, because all the diffs from RFC editor we discussed still had
> > the old and probably current formatting with
> pagination/TOC-with-page-numbers
> > to the best of my memory, and somehow i didn't read recently any new RFCs
> > since when this change seems to have happened

I bet it happened, when, as the last stage of the RFC editing process, a
conversion was made to v3 xml and then there was no way back.

(yes i know, shame on me).

Since this was the first time, I think "Fool me once, shame on them"
applies, even if it is hard to identify "them".

> > Curious...

I think "insane" is a more appropriate adjective but it needs to be
understood that this is a statement of opinion and should not be understood
as a clinical judgment.

>
> > I actually would very much appreciate a rendering with pagination and
> > page numbers in TOC. What would be the right place to ask for this ?
>

I've asked the xml2rfc people who didn't really respond.

> (probably not rfc editor...)
>

The RFC editor was sympathetic and helpful but has no power to change
things.  Unfortunately, I'm not sure who does.

Currently, the only way to get a newer RFC with page numbers is to edit the
RFC xml to turn it into an I-D. That has problems but is the only way I
know to get a printed document with a useful TOC.

I would expect that the IETF plenary might be an appropriate venue to
discuss this.  If you do pursue this, let people know so they can be up at
4AM EST or 1AM PST and purchase a one-day pass.

---

From: David Noveck <[email-masked]>
Date: Mon, 26 Oct 2020 11:04:49 -0400

> Different renditions will have different concepts of pages, so the TOC’s
> won’t align.
>

There's no reason for them to align with each other.   The paperback and
hardcover editions of books have different TOCs but there is no need for
them to be the same, as long as each matches the document it is a TOC for.

(That is not a good argument for then finally choosing what is probably the
> worst possible solution to this problem.

Actually it's a non-solution to a non-problem.

> I think what happened is that nobody thought about PDF where we continue
> to have pages,

 I think that's probably true.

so there never really was a problem specific to retaining pages and thus
> page numbers in the TXT.)
>
>  I guess this is because nobody thought about TXT files being printed
either.

Grüße, Carsten

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 26 Oct 2020 18:36:19 +0000

On 10/26/20, 2:26 PM, "WGChairs on behalf of Warren Kumari" <[email-masked] on behalf of [email-masked]> wrote:

I wasn't involved in the RFC format discussion either but can't see how removing the pagination could have been seen as an advantage. Additionally, it is annoying that the htmlized version don't provide links to sections/sub-sections from TOC. 

Thanks,
Acee

    W

---

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:

—John

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Oct 2020 17:48:15 -0400

-- Jeff

---

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

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

> throw weight is a valid one. I previously suggested associating a 
> BogoPages metric with each non paginated RFC for this purpose.)
>
> —John

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 26 Oct 2020 23:00:31 +0100

Hi all,

TL;DR
Gave up on looking up rfc-interest WGLC results from years ago; plenty 
use of the term surprise.

I admit, I was surprised by the notion that "there will be no more page 
numbers" over a year ago. I was not involved in any way in WGLCs that 
happened in rfc-interest in... 2015?

I can understand that people are now puzzled by these decisions back 
then, to be honest. Typically, I fault myself for not spending enough 
attention, so.. my bad. I spent some attention right now - and it 
yielded this:

> https://www.rfc-editor.org/pipermail/rfc-interest/

and I am certainly not going to do this right now:

> https://trac.tools.ietf.org/group/tools/trac/wiki/Imap#Overview

So yes, there probably was some discussion on something that resulted in 
consensus in some scope. I cannot easily check that right now (attention 
span and kids bedtime and such), but I can state that I am not surprised 
that this somehow violates the principle of least surprise, today.

Oh... and why was I trying to skim the archive? To find out why a TOC in 
HTML is harmful in a way that page numbers are harmful :o)

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 26 Oct 2020 23:07:22 +0100

I also think that the Header in the tools' HTML version provides tons of 
convenience functions. So many in fact that the current status quo 
actually conditioned me to look for a "tools" annotation in a button on 
the datatracker. Maybe that's just me, though.

---

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: Fred Baker <[email-masked]>
Date: Mon, 26 Oct 2020 17:50:50 -0700

> On Oct 25, 2020, at 7:04 PM, Toerless Eckert <[email-masked]> wrote:
> 

It seems to me like the first thing you have to have is the concept of a "page", and that "page" needs to have a predictable "size". With ASCII documents, we defined those terms, in terms of a "line" and a number of them. Personally, that's what I use paragraph numbers for.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Oct 2020 18:00:22 +0100

> happened in rfc-interest in... 2015?

There was no WG nor an LC. The discussions about this have happened many
years before (I *think* on this list), and then the former RSE made
decisions based on these discussions.

Best regards, Julian

---

From: Robert Sparks <[email-masked]>
Date: Tue, 27 Oct 2020 12:05:46 -0500

> decisions based on these discussions.

There was more to it than that:

https://mailarchive.ietf.org/arch/msg/ietf-announce/IGnzylKKPhSvjjOsM-Lme8GdEfo/

for example

---

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: 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: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Oct 2020 15:38:08 -0400

Ben,

> Like https://www.rfc-editor.org/rfc/rfc8815.html#section-3.1-5 ?

You seem to have missed the paragraph 5 symbol I added.

I regularly use the html anchor notation above. :-)

If it wasn't for the fact that our XML is of highly variable quality
I'd simply note that XPath provides sufficient addressability.  But it's
less easy to interact with it in plain text emails and still awkward in
richer formats.

/section[@title='Security Considerations']/t[5]  as an example of the fifth
text block of the security considerations section.

-- Jeff

---

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

Hi Jeff,

> I regularly use the html anchor notation above. :-)

I am not sure which of us is confused -- the link I provided is directly to
the fifth paragraph of the section (the "-5" suffix effectuates that
functionality).  So, if I assume that you knew that, I'm left with the
conclusion that the "paragraph" part of the reference/link needs to be more
prominent to someone that does not understand the URL fragment's structure.
Which is perhaps a valid position to hold, but I'm not entirely confident
if that is the position you are holding.

> If it wasn't for the fact that our XML is of highly variable quality

Indeed.  And there does not seem to be much appetite for fixing that -- I
had asked about even something as simple as consistent indentation for
nested XML elements and got a response along the lines of "if authors care,
they can put in the work to make the XML look pretty".  Which is
unsatisfying to me, but I apparently failed to make a persuasive case for
it.

-Ben

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Oct 2020 15:42:52 -0400

Ben,

> On Oct 27, 2020, at 3:32 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> functionality).  

No, I missed the distinction of the -5 vs. .5.  If so, certainly my primary use cases for such citations are covered.

Is there a guide that has any other such things I may have missed?

> unsatisfying to me, but I apparently failed to make a persuasive case for

This is a battle I'd have no stomach for.  Much like code indentation, it's a fight that only generates sore losers.  And much like code indentation, if you care - run it through your favorite indenter.  

That said, a tool that can generate such citations might still be of use if we continue further down this hole.  But I think if we have the ability to generate paragraph and section citations, we're probably covering the majority of the common use cases.

-- Jeff

---

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

> No, I missed the distinction of the -5 vs. .5.  If so, certainly my primary use cases for such citations are covered.

Ah, happy to help.

> Is there a guide that has any other such things I may have missed?

I don't remember a specific guide; I think I have just picked up on some
things by exploring and clicking on random stuff.  (Well, and perhaps
spending way too much time on the datatracker.)  But it's possible that one
of Heather's plenary talks had a summary of new and exciting features and
I've just forgotten about it.

> That said, a tool that can generate such citations might still be of use if we continue further down this hole.  But I think if we have the ability to generate paragraph and section citations, we'r…

I suspect you are correct.

Thanks,

Ben

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Oct 2020 21:03:48 +0100

> Is there a guide that has any other such things I may have missed?

All anchors in HTML are supposed to be discoverable, either by clicking
on titles, section numbers, or paragraph symbols that show up after the
last characters of a paragraph.

> That said, a tool that can generate such citations might still be of use if we continue further down this hole.  But I think if we have the ability to generate paragraph and section citations, we'r…

Not sure how XML source code indentation is relevant. That said, the
"canonical" XML is supposed to be the output of a pretty printing step.
See <https://greenbytes.de/tech/webdav/rfc7998.html#pretty>.

Best regards, Julian

Best regards, Julian

---

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

> tracker, etc. So with one click I can bring up the diff showing the most 

Yes, very useful. Is there any reason that a tool could not prepend
that info to the new-normal HTML version?

> - it has hot links from the TOC to the sections so that is easily navigated

That's built into the new-normal HTML.

> 
> - it is laid out just like the text version. 

But the text version is now not a reference point any more, like it or not.

> I can cut out sections that 
> formatting. 

True. But if your reader is looking at the HTML version, that doesn't really work any more.

(I prefer to use the side by side diffs when reviewing 
> context. Having the full version match what the diff used is important 

True. But this is a property we lose when line-wrapped HTML is the presentation format.

> don't see why it is harder to produce than for v2 documents.

It isn't. But since the txt version is no longer canonical, e.g. no SVG diagrams, the value is less than it used to be.

> OTOH, I do now prefer the native html version when reading/consulting a 

Me too. It also prints nicely if you want.

    Brian

---

From: "John R. Levine" <[email-masked]>
Date: 27 Oct 2020 19:33:47 -0400

> 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.

I remember back when the IETF was full of engineers who looked at a 
problem and wrote software to solve it.

It took about an hour to write this:

 	https://github.com/jrlevine/pagerfc

It takes an unpaginated text RFC, adds page breaks, headers, and footers, 
splices the page numbers into the TOC, and since someone said it would be 
useful, puts the current section header into each page footer.  Sheesh.

For demonstration only, your mileage and page numbers may vary.

Regards,

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 27 Oct 2020 23:44:13 +0000

You beat me to it, John! I was thinking of writing the same thing. :)

	Tony

    Regards,

---

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

As I recall the original discussions, a bit more work is needed to avoid widowed
lines and split artwork and tables.

Regards
   Brian

---

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: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2020 05:50:44 +0100

Am 28.10.2020 um 04:16 schrieb Michael StJohns:
>>   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.
>

Yes. It is done already.

> between the sections and text and page numbers can be useful for

Yes. Which version do you print? HTML? PDF? TXT?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2020 12:07:06 +0100

Hi there.

So the RPC currently produces three output formats:

1) Plain text

Plain text is not paginated, and that's intentional.

Paginated output in xml2rfc is supported, but turned off by default when
producing RFCs.

2) PDF

PDF is paginated, but currently lacks page numbers in the ToC. I
consider this a defect, and opened
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/558>.

3) HTML

HTML can be paginated, for instance when printed. There is CSS support
for controlling headers and footers, and generating page numbers.
Unfortunately, this is not supported by browsers (when printing HTML),
but there *are* tools implementing this.

rfc2629.xslt has supported this for ages, and I believe xml2rfc should
do so as well. Enhancement request:
<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/559>.

I believe there is consensus that page numbers can not be used to refer
to parts of an RFC. xml2rfc generates stable paragraph/table/figure
anchors both in HTML and PDF (see, for instance
<https://www.rfc-editor.org/rfc/rfc8905.pdf#section-6-2> and
<https://www.rfc-editor.org/rfc/rfc8905.html#section-6-2>).

Page numbers are indeed useful when something *is* printed. Given the
fact that plain text does not support SVG, I would argue that PDF (or
HTML, with the improvement above) are better suited for printing, so
there really is no compelling reason to change the publishing default
for plain text (well, maybe except to prove that page numbers are
unstable, because they would differ between plain text and PDF).

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Oct 2020 12:18:00 +0100

> useful, puts the current section header into each page footer.  Sheesh.

Umm.  So why is it OK to provide this functionality as a script, but not OK
to make xml2rfc able to do it?  I'm not talking about the RFC Editor publishing
paginated text, I'm talking about permitting xml2rfc to do what you've just
provided a tool to do.

Regards,

	Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2020 12:59:59 +0100

> paginated text, I'm talking about permitting xml2rfc to do what you've just

That's indeed a good question.

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Oct 2020 06:03:07 -0700

> That's indeed a good question.

Indeed. Obviously, whenever we add little-used features to software
(assuming ad arguendo that this will be little-used) there is a risk of
them being a source of defects, but as Henrik says, this seems like a very
small change with a code path that is mostly already used.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Oct 2020 09:22:25 -0400

If the functionality you are referring to here is putting section and paragraph numbers in the header, I don’t think there’s any reason not to do it since these are the internal pointers that had consensus. 

If the functionality you are referring to is page numbers, we already discussed why that is not in the IETF-provided tool. 

> On Oct 28, 2020, at 07:18, Henrik Levkowetz <[email-masked]> wrote:
> 
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Oct 2020 14:31:46 +0100

Hi Ted,

On 2020-10-28 14:22, Ted Lemon wrote:
> If the functionality you are referring to here is putting section and
> paragraph numbers in the header, I don’t think there’s any reason not
> to do it since these are the internal pointers that had consensus.
> 
> If the functionality you are referring to is page numbers, we already
> discussed why that is not in the IETF-provided tool.

No, I don't think so.  I believe all the arguments were germane with
respect to publishing RFCs with / without page numbers, but not with
respect to letting the tool have a switch to produce a format with
page numbers.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Oct 2020 14:38:03 +0100

> respect to letting the tool have a switch to produce a format with

I think we have a lot of confusion what our tools are good for.

The argument that non IETF-defined process uses a feature in an IETF-provided tool does not mean that the IETF-provided tool should not provide that feature for author use in the process (or even outside the process).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Oct 2020 14:39:08 +0100

Fixed (DYAC):

> On 2020-10-28, at 14:38, Carsten Bormann <[email-masked]> wrote:
> 
> The argument that no IETF-defined process uses a feature in an IETF-provided tool does not mean that the IETF-provided tool should not provide that feature for author use in the process (or even outside the process).

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Oct 2020 10:36:59 -0400

> respect to letting the tool have a switch to produce a format with

The argument for not having the tool do it is that the tool is provided by the IETF, and if the IETF-provided tool does it, its output will be (incorrectly) assumed to be canonical and used in non-IETF references to IETF documents. If the tool is not provided by the IETF, this won’t be an issue.

But let me ask you: why is it not a good solution to put the section number and paragraph number in the header? Doesn’t that accomplish the same purpose in a way that can’t be mistakenly used?  You still have strictly increasing numbering, the TOC is still useful, and it makes the canonical reference format that we actually decided to use easier to use.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 28 Oct 2020 14:38:54 +0000

*   The argument for not having the tool do it is that the tool is provided by the IETF, and if the IETF-provided tool does it, its output will be (incorrectly) assumed to be canonical and used in non-IETF references to IETF documents. If the tool is not provided by the IETF, this won’t be an issue.

Do we think that organizations using RFC’s and doing “canonical references” to them are running xml2rfc?  I’m skeptical.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Oct 2020 10:51:56 -0400

> Do we think that organizations using RFC’s and doing “canonical references” to them are running xml2rfc?  I’m skeptical.

We have no data, and I don’t know how we would collect it. But organizations are made up of individuals, and I’ve certainly seen things that are just as perverse happen in the past, so I think if there’s a way to address peoples’ needs that doesn’t have that as a potential outcome, that’s what we should do.

---

From: John Scudder <[email-masked]>
Date: Wed, 28 Oct 2020 14:55:29 +0000

> But let me ask you: why is it not a good solution to put the section number and paragraph number in the header? Doesn’t that accomplish the same purpose in a way that can’t be mistakenly used?  You…

Pages are of fixed size. Paragraphs and especially sections, are not. Page numbers will be better for random access. Also, people have decades of practice randomly accessing documents using page numbers. 

I mean, paragraph or section is better than a sharp stick in the eye, but that’s a low bar. 

—John

---

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Oct 2020 10:00:53 -0500

On 10/28/20 9:36 AM, Ted Lemon wrote:
> On Oct 28, 2020, at 9:31 AM, Henrik Levkowetz <[email-masked] 
> <mailto:[email-masked]>> wrote:
> The argument for not having the tool do it is that the tool is 
> provided by the IETF, and if the IETF-provided tool does it, its 
> output will be (incorrectly) assumed to be canonical and used in 
> non-IETF references to IETF documents. If the tool is not provided by 
> the IETF, this won’t be an issue.

With no hats on (but I clearly have a hat to wear wrt this question) - I 
understand, but am not personally persuaded by that argument.

xml2rfc is used in other fora already, and someone may choose to 
contribute something that the IETF would choose not to use. IETF 
endorsement isn't relevant.

I am more sensitive to the variant of this argument when applied to the 
IETF publishing a puddle of documents that could be seen as official and 
are confusing.

RjS

>
> But let me ask you: why is it not a good solution to put the section 
> number and paragraph number in the header? Doesn’t that accomplish the 
> same purpose in a way that can’t be mistakenly used?  You still have 
> strictly increasing numbering, the TOC is still useful, and it makes 
> the canonical reference format that we actually decided to use easier 
> to use.
>
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Oct 2020 16:01:45 +0100

Hi Ted,

> the IETF, this won’t be an issue.

I don't see any non-IETF organizations generating their own copies of
RFCs in order to refer to page numbers.  They will use and refer to the
versions published by the RFC Editor, and I don't think we're asking for
the published text version to be paginated.

> number and paragraph number in the header?

I haven't expressed any position on this.  

> Doesn’t that accomplish
> the same purpose in a way that can’t be mistakenly used?

So the reason why the authors of draft-ietf-nfsv4-rfc5661sesqui-msns
asked for page numbers for their work with the RPC staff was summed up to
me as follows (the last draft before the RFC was 673 pages long),
paraphrased by me:

  Their document is huge, and the document may have a community that refers
  to page numbers rather than sections (the document has very deep section
  numbering, e.g., 6.2.1.3.1).

Putting the section numbers in the header would not address their issue
at all.

> You still
> have strictly increasing numbering, the TOC is still useful, and it
> makes the canonical reference format that we actually decided to use
> easier to use.

True as far as it goes, but in my view not so relevant if it doesn't
address a problem that users of the tool are experiencing.

Regards,

	Henrik

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Oct 2020 11:17:01 -0400

> Putting the section numbers in the header would not address their issue

It seems like this use case can’t be addressed without a different IETF consensus, since presumably the canonical version of the RFC would need page numbers in the TOC in order for this to be useful.

At the same time, this seems like an example of a document that really should never be printed. 673 pages? Why not use HTML anchors?

I don’t mean to be dismissive of peoples’ needs—I’ve been known to print a document so I could mark it up on paper. But this is largely because the tools for marking up canonical forms of documents not on paper don’t exist. If I had to review a document this long, I definitely wouldn’t feel good about printing it and reviewing it on paper.

Perhaps our time would be better spent improving our document markup process rather than arguing about the TOC.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Oct 2020 11:20:10 -0400

Brian,

[Top posting because this is a general observation provoked by your 
comments, not pertaining to any particular comment. Also changing the 
subject to relate to the content.]

I realize all the points I am making are rooted in a perceived need to 
continue using txt format (or something akin to it) for some purposes. 
And I know how archaic it seems. I would be happy to migrate to using a 
richer format for all purposes *if* there was a clear way to make the 
whole process of creating / evolving / reviewing / discussing / editing 
/ publishing documents work smoothly. IMO we are far from that state.

I spent a bit of time participating in 3GPP where they do everything 
with MSWord documents. I found that to be incredibly cumbersome.

I have *not* been involved in W3C document development. I don't know how 
that works. I'd be interested in hearing if they have something that 
works well.

In the IETF process documents are primarily discussed via email. Email 
threads often end up evolving text that goes in documents. I 
intentionally use plain text email with quoting for this purpose because 
it makes the threading clear. (Not everybody does this. When some use MS 
html email and indicate their contribution via initials things get very 
hard to follow.)

When discussing a particular part of a document it is convenient to 
simply copy/paste a few lines of the txt format into the email. The txt 
format means that the formatting is preserved and isn't reflowed. So it 
is easy to relate this to the whole document.

I can vaguely imagine working from an html form of a document and 
copying bits of text into an html email, but I am dubious that it will 
work as well.

A key part of working with documents is reviewing changes via diffs. For 
now the diff tools only work on txt documents. Relating that back to the 
txt form of the whole document is easy. Relating back to html or pdf can 
work, but isn't as straightforward. Perhaps the situation would be 
different if we had a diff that worked on the html or pdf formats.

A further complication is the evolving use of github in the management 
of ietf drafts. It has different tools for commenting and revising. How 
this interacts with the "traditional" ietf draft management is a bit 
obscure.

Bottom line: it is possible, and perhaps desirable, for the ietf to move 
to a system totally detached from plain text. But doing so will require 
many more tool and process changes than are currently planned. And it 
will require everybody involved to move to new ways of doing things. It 
is a heavy lift!

	Thanks,
	Paul

---

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: Carsten Bormann <[email-masked]>
Date: Wed, 28 Oct 2020 23:41:17 +0100

On 2020-10-28, at 16:20, Paul Kyzivat <[email-masked]> wrote:
> 
> it is possible, and perhaps desirable, for the ietf to move to a system totally detached from plain text.

I have been working with and on (writing, using, educating, researching) various text processing systems for about four decades now.

The one development that I couldn’t have predicted was when, shortly after 2000, structured document formats such as those based on XML or HTML were supplanted again on the authoring side by plain text formats (“humane markup”) such as asciidoc and markdown.
Of course, these are structured documents as well, but there is finally attention to being able to work with them as an authoring format.
(Those of us that were living in nroff/troff or LaTeX can sympathize, but these formats were too intricately tied up with their formatters.)

Having embraced this move to humane markup in a number of markdown- and asciidoc-based authoring formats for I-Ds and RFCs in the last decade, I don’t think we will move away from that.  The main reason is that it is really easy to collaborate on humane markup using tools like git and github, and the IETF document generation process is fundamentally collaborative, much more so than in other SDOs.

W3C is maybe an exception, and they have an amazing tool called respec that is based on HTML authoring and a ton of Javascript.  This is an interesting alternative direction, but not one that I think would work so well with the diversity of authors we have in the IETF(*).

So I think plain text (with humane markup) will be our preferred authoring side for some time to be.  A plaintext formatted rendition fits well with many ancillary processes we use during authoring and reviewing.  Even if the occasional SVG figure drops in only on the HTML/PDF side.

Grüße, Carsten

(*) respec is profoundly an ART-area tool, and I’m not even sure about the RAI part of ART.  That fits W3C, but not the IETF.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 29 Oct 2020 12:07:25 +1100

On Thu, Oct 29, 2020, at 09:41, Carsten Bormann wrote:
> Having embraced this move to humane markup in a number of markdown- and 
> asciidoc-based authoring formats for I-Ds and RFCs in the last decade, 
> I don’t think we will move away from that.  The main reason is that it 
> is really easy to collaborate on humane markup using tools like git and 
> github, and the IETF document generation process is fundamentally 
> collaborative, much more so than in other SDOs.

This I agree with.

However, I still find that people routinely refer to the rendered versions.  Many outside reviews refer to text by section numbers (which is not in the source, ouch).  For people working on QUIC, we've mostly moved to direct references to the editor's copy.  The addition of pilcrows on paragraphs has been a huge help in improving our ability to reference text.  I wish that we could teach more people to do that.

There's a gap there that I'm not completely comfortable with, but I believe that the fundamental direction here is broadly right.  That's why I too have been very happy with use of markdown as it broadly meets these goals.

Collaborating on a Word document is great when you have either a small, tightly-knit group who can use the tool effectively.  That is, when the online tools are used, which support commenting and suggestions.  But that process doesn't scale well and I don't see it as suitable in the working group setting.

I guess if you are comfortable with process that is slow and formal, and you can rely on extensive clerical support, the submission of a changeset in the form of a Word document is workable.  Or at least not the most urgent process problem you need to concentrate on.

> W3C is maybe an exception, and they have an amazing tool called respec 

There is also bikeshed, which I'm having trouble distinguishing from respec as the two evolve.  But your observation holds: they too create a text artifact that is the focus of collaboration.  They provide more features than I think are needed in this context, but they are still fundamentally an embodiment of the same principles: collaboration is what makes the work we do valuable.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Oct 2020 07:41:18 -0400

Martin Thomson <[email-masked]> wrote:
    > However, I still find that people routinely refer to the rendered
    > versions.  Many outside reviews refer to text by section numbers (which
    > is not in the source, ouch).  For people working on QUIC, we've mostly

Yes. That's really an annoyance.  In XML land how many of us have:

   <!-- section 4.5.6 -->
   <section title="FOO" ..>

I don't know how to do this in markdown, as there isn't really a useable
comment system, except using XML.

    > moved to direct references to the editor's copy.  The addition of
    > pilcrows on paragraphs has been a huge help in improving our ability to
    > reference text.  I wish that we could teach more people to do that.

I'm confused: what is it that we need to teach?

    > Collaborating on a Word document is great when you have either a small,
    > tightly-knit group who can use the tool effectively.  That is, when the
    > online tools are used, which support commenting and suggestions.  But
    > that process doesn't scale well and I don't see it as suitable in the
    > working group setting.

I find that even among monoculture of lifelong Word users, few actually know
how to use the mechanism properly.  Google Docs/Office365 has taught more
people how to do it right by eliminating the "merge" step.

    > I guess if you are comfortable with process that is slow and formal,
    > and you can rely on extensive clerical support, the submission of a
    > changeset in the form of a Word document is workable.  Or at least not
    > the most urgent process problem you need to concentrate on.

Receiving comments in the form of a marked up word (or PDF) is, very
bittersweet as an author.  Yes, so nice to get smart, extensive, review, but
basically triples the effort to apply the changes.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Oct 2020 12:53:49 +0100

On 2020-10-29, at 12:41, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

But using XML is the markdown comment system.
(Except that it inherits the inability to have double-hyphens in comments; kramdown therefore has {::comment}…{:/} as well.)

More interesting is the question whether we can get editors (such as markdown-mode in Emacs) to display the current section number or visit a given one.  SMOP (*); highlighting already knows the section headers, so it’s a matter of counting them.

> I'm confused: what is it that we need to teach?

Sending precise links instead of phrasing the reference in English.

It would be nice if there were a less contorted way to actually open the HTML for a document so you can link to places inside it; right now that is 3 or 4 klicks, most of which have a 6-second wait for datatracker.

Grüße, Carsten

(*) Yeah, I know.  Probably a day.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Oct 2020 10:47:21 -0400

> basically triples the effort to apply the changes.

More than triples. The problem is that, at least in ietf process, the 
comments in each such review themselves should be discussed by the group 
before being accepted or rejected.

In theory this should be handled by adding additional comments to the 
marked up document. But AFAIK there aren't good ways to thread those 
comments. (You can try to follow the timestamps, but it is difficult 
especially when comments are scattered across the document.

	Thanks,
	Paul