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

Jim Fenton <> Wed, 28 October 2020 05:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B0DC3A0EF2; Tue, 27 Oct 2020 22:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gDfVfzNccmv3; Tue, 27 Oct 2020 22:47:44 -0700 (PDT)
Received: from ( [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD1C93A0EF0; Tue, 27 Oct 2020 22:47:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SEyD6Y1qAGbwh9ni4eAe4oDtkQnjl2RBoAKHwOmA3/Y=; b=Y0QybQJ4coTEHUK0s7/K6YXkUl pPhbrbx6xgwXum7Qbm6BnZtM0OmNEN7SuX0bljqin40vwegzzjSZC05iMB63Y7V4ploEeK064TIlY 4X5X8nfRCdqPwE8G+FRv9NSjKF6bk+f1L/u82zCYqbod3J+aGFb1EqpX7Fu1e1RPTL6A=;
Received: from [2601:647:4400:1261:ac45:fb1a:7502:2d] (helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kXeJ9-0003lC-HC; Tue, 27 Oct 2020 22:47:41 -0700
From: "Jim Fenton" <>
To: "Andrew G. Malis" <>
Cc: "David Noveck" <>, "Working Group Chairs" <>, "Phillip Hallam-Baker" <>, "John Levine" <>, "IETF Discussion Mailing List" <>, "RFC Interest" <>, RSOC <>
Subject: Re: FIXED: Poll: RFCs with page numbers (pretty please) ? (was: Re: John/rsoc: Re: Page numbers in RFCs questions / preferences)
Date: Tue, 27 Oct 2020 22:47:38 -0700
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2020 05:47:47 -0000

On 27 Oct 2020, at 21:49, Andrew G. Malis wrote:

> Jim,
> Open any recent HTML RFC (such as
> and take a look at the 
> frame
> to the right of the text (on a phone browser, the TOC is a button at 
> the
> top of the screen).

Thanks, John and Andy, for pointing that out. That’s what I get for 
(1) using a narrow browser window and (2) looking for the TOC in exactly 
the same place, so I didn’t see the Table of Contents thing in the 
upper right corner.


> Cheers,
> Andy
> On Tue, Oct 27, 2020 at 7:57 PM Jim Fenton <> 
> 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.
>> 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.
>> 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.
>> -Jim
>>> On Tue, Oct 27, 2020, 6:51 PM Phillip Hallam-Baker
>>> <>
>>> 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?