Re: [rfc-i] FIXED: Poll: RFCs with page numbers (pretty please) ? (was: Re: John/rsoc: Re: Page numbers in RFCs questions / preferences)

On Tue, Oct 27, 2020 at 7:57 PM Jim Fenton <fenton@bluepopcorn.net> wrote:

> [Yikes, this discussion is getting crossposted everywhere, it seems.
> I’ll keep it brief]
>
> On 27 Oct 2020, at 16:36, David Noveck wrote:
>
> > The issue comes up with PDF files.  Currently, you get page numbers
> > together with a TOC that has no page numbers.  I'm OK with a no-TXT
> > option
> > but I have a problem with a not-usefully-printable option for RFCs.
>
> When RFC 8689 was about to be published about a year ago, I had a chat
> with the staff at the RFC Editor table in Singapore about this. It
> seemed a little strange to have a table of contents without page
> numbers, but if some people are reading HTML versions, PDF versions, and
> TXT versions, the pagination is different anyway (and nonexistent for
> HTML) so trying to reference something by page number is problematic.
>

True but the function of page number in a TOC is not to allow references
using page numbers.  That is a bad practice and has always been.

The function is of page numbers in a TOC is to enable the use *of printed *
*documents*.   In any printed document (e.g. books), one has to go from
section number to the text in question, and the TOC, with page numbers,
allows you to do this.  If the TOC doesn't have page numbers, you are
stuck doing an annoying binary search.   This is the reason that all books
are published with TOCs containing page numbers.

> References should be to section numbers, and if sections are so big that
> it’s hard to find some text there, the author should really think
> about structuring the document with smaller subsections.
>

True.

>
> What does seem strange (and maybe it has changed in the past year) is
> that the plain text and PDF versions have tables of contents, and the
> html version does not. I would like for the html version to have a table
> of contents with links to anchors for each section.
>

Seems reasonable.

>
> -Jim
>
> > On Tue, Oct 27, 2020, 6:51 PM Phillip Hallam-Baker
> > <phill@hallambaker.com>
> > wrote:
> >
> >> Whooaah there...
> >>
> >> What is the status of this poll? I am all for moving from the
> >> subjective
> >> consensus model in which certain parties get a veto because their
> >> opinions
> >> are considered weightier than the rest of us. Objective measures of
> >> consensus are good. But is this an official poll? What does it mean?
> >>
> >> But of course, as John K. pointed out, this is not actually an IETF
> >> process. Only of course it is in every meaningful sense except
> >> insofar as
> >> IETF rules of the road apply.
> >>
> >>
> >> Page numbers is not the hill I would choose to die on here. They
> >> don't
> >> work in HTML and the whole point of this process is that the TXT
> >> documents
> >> reflect very badly on the IETF as an organization. It spoke of an
> >> organization that is stuck in the 1960s ranting on about how vinyl is
> >> better than CD.
> >>
> >> There are serious issues with the new format. Not least the fact that
> >> SVG
> >> is not actually supported. The supported format is SVG/Tiny which is
> >> an
> >> obsolete format originally proposed back in the WAP days as a means
> >> of
> >> crippling the spec to fit the capabilities of the devices back before
> >> Steve
> >> Jobs showed us an iPhone for the first time. There are no tools that
> >> produce SVG/Tiny, not even GOAT - I had to modify the source code to
> >> comply.
> >>
> >> I don't mind retooling to support an improved specification. Having
> >> to
> >> retool to support an obsolete one is nonsense.
> >>
> >>
> >> Anyway, how about as a compromise, authors can opt to suppress
> >> generation
> >> of the TXT version so that the page number issue doesn't come up at
> >> all?
>