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

Donald Eastlake <> Thu, 29 October 2020 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A881D3A05D0; Thu, 29 Oct 2020 12:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v8E7djLG6dme; Thu, 29 Oct 2020 12:10:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0C473A044E; Thu, 29 Oct 2020 12:10:28 -0700 (PDT)
Received: by with SMTP id z5so4788267iob.1; Thu, 29 Oct 2020 12:10:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uSCPNKms3sCKWQZRRxRuwuBVU0yYmnKad4Bt9715BMU=; b=AW3F+UJYiqLhbXQnx62yfDGnOdHkupzZ0nKE6PcqE+wL0BSzUjVJnL8khHCMggsIxF q3YvnU3W54uCe8ijKx0Xld7pdltoUoQxpkXSt54Mu9L8D7fwVVrpyjVaNUxXVIXgzGr1 A7Uq/PpMnbcSkyhUuFws9ZHA28F3AQbjh8KXNuGUmMrTLbQtSIgeW0inqOtTruIppDc6 ihp0/YEDjFo+pKwQaQt6spZV/dWN8qOvuyjci1a4vR7HIF+c0TMeJJJ3SARLbiTPHqi1 j+tCKtkPHiGuvAALFSTsn3RUF+UUn9pGRR6FeJHpHi5T/g8QsK0bV5uiGrUK3sJzQxkb qDFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uSCPNKms3sCKWQZRRxRuwuBVU0yYmnKad4Bt9715BMU=; b=OHq13JfiTOCIhcRHLLUBqI+Elu8aAGMh/lTRkb0kG7yT/lpaTFI7ai39ky+Vg6Fp2a 5oKWVMVqGeThTCoMrCubq5MlIJjvTfstHIGMqYHXJoR2v0IWlukWNz4j94Uz9iblnXlC Mv6JQMdiaxbQbxEAD8D+8BMnErw1eKBM+eb1AuqFvRueeILxg0N9/cMsdHXgAEUAFBaZ sTi991fVDU21Fb5H+t66R4tco2cNJHMVKK8uDDBN5BkSD0ytm+So4io6a2SEGQrfQ2h7 A6b6vAi5G3a7+9rRDe8FTX831aFdLmbceYlGU6Bjj4fCTmeillaDwVwq/ROsQZRdIs/U wMuQ==
X-Gm-Message-State: AOAM531tIbsZMs7d7tMiEsBNw0A4DGGnsjcOU2OOIwb77ugEX8qz9777 +6QKzXrQAlK+8Vc8vjiQeiIuUmcKIcU5XkjMXe1CuUpEq+4=
X-Google-Smtp-Source: ABdhPJxYaACI+TOKRkCk30xDSNmgw6Kr60U695J29N5Tq1cO5N82HzGhRRCO6v/jkQ96nY/gBwW36/azRmPl/Cnbvkk=
X-Received: by 2002:a05:6638:f81:: with SMTP id h1mr5029503jal.115.1603998627991; Thu, 29 Oct 2020 12:10:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <263C265C19B24BA97AF48934@PSB> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Thu, 29 Oct 2020 15:10:16 -0400
Message-ID: <>
Subject: Re: Jim: Re: [rfc-i] FIXED: Poll: RFCs with page numbers (pretty please) ? (was: Re: John/rsoc: Re: Page numbers in RFCs questions / preferences)
To: Warren Kumari <>
Cc: John C Klensin <>, Working Group Chairs <>, Phillip Hallam-Baker <>, John Levine <>, IETF Discussion Mailing List <>, Toerless Eckert <>, RFC Interest <>,
Content-Type: multipart/alternative; boundary="0000000000007114b105b2d4083c"
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: Thu, 29 Oct 2020 19:10:31 -0000

I endorse Warren's comments. I use the text versions heavily and I believe
that one of the formats available should preserve the traditional RFC

-- All formats should have a Tables of Content. (Well, I guess I would
agree that if an RFC had less than two sections, it wouldn't need a ToC,
but I don't see how that is possible with the current requirements.)

-- If a format is paginated, it should have page numbers. (A warning could
be added something like "Warning: The page numbers in this document depend
on its presentation format and will differ in other renditions.")

-- If a format has a ToC and pages numbers, those page numbers should
appear in the ToC and just before the ToC would be a good place for the
warning suggested above.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA

On Wed, Oct 28, 2020 at 4:02 PM Warren Kumari <> wrote:

> On Wed, Oct 28, 2020 at 3:20 PM John C Klensin <> wrote:
> >
> [ Massive SNIP ]
> >
> >  (a) They are traditional in the RFC Series and
> >         preserving that rendering in a format consistent with a
> >         significant fraction of the first 7000 or so of RFCs
> >         would seem to have some advantages.  Of course, no one
> >         is forced to use them, any more than anyone has been
> >         forced to use the standard text form since HTML and PDF
> >         forms became generally available years ago.
> >
> >  (b) Of the fraction of the community that still prefers
> >         to use the plain text form (at least sometimes) and for
> >         one purpose or another, some fraction of them prefer to
> >         have the headers and footers and many of those prefer,
> >         or are not disturbed by, the page numbers.  Because many
> >         of the arguments against page numbers seem to be coming
> >         from people who do not find the plain text form useful,
> >         probably we should pay attention to that preference ...
> >         or start making the case for getting rid of the plain
> >         text form entirely, perhaps because those who prefer it
> >         (for any purpose) need to be persuaded to join the
> >         modern era and get with the programs.
> >
> I realize you aren't actually pushing this point, but this seemed like
> the clearest expression of one of my concerns with this entire thread,
> and so I'm choosing to hook onto it...
> Full disclosure:
> I'm one of the people who both believes that there is value in the
> "traditional" aspect of the series, and the fact that RFC17 looks the
> same as RFC42, which looks the same as RFC4217, which looks the same
> as RFC8217 is a good thing.
> I also like and use the text formats - I sometimes print out RFCS, I
> have tooling which greps through documents for things, I generate
> statistics, etc. It's a personal preference.
> I've gotten 2 distinctly negative impressions from this thread:
> 1: "You need to join the modern era and get with the program" sums it
> up well. HTML / flowed output is the new world, liking the text format
> is bad and you should feel bad[0].
> 2: There were extensive discussions around the new format, and the
> lack of page numbers was mentioned. You were not paying attention when
> this happened. Not only do you lose any right to discuss this, but you
> were lazy and should feel bad.
> I'll happily admit that I didn't follow the new format discussions
> closely, and that I do read a lot of things (including books) in
> formats which don't have clear "pages", but the thing that is worrying
> me is the underlying "and you should feel bad" tone in much of this
> discussion.
> Perhaps I'm being overly sensitive (or that I just miss seeing IETFers
> in person), but it feels to me like the "and you should feel bad"
> subtext seems to be cropping up more and more. We used to generally
> assume that someone who had a bad or silly idea just had a bad or
> silly *idea* - but it now we often seem to be implying that the person
> is bad or silly.
> Other than being able to meet in person again, I'm not sure how we get
> back to where our base assumptions are that other IETFers are friends,
> and are also trying to do the right thing...
> W
> [0]: Meme reminder:
> > Probably I'm missing something important but, if the above
> > analysis is even nearly correct, I don't understand why we are
> > still having this conversation.
> >
> >     john
> >
> --
> 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