Re: Poll: RFCs with page numbers (pretty please) ?

Toerless Eckert <tte@cs.fau.de> Mon, 26 October 2020 23:31 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0977C3A10D1; Mon, 26 Oct 2020 16:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlDjFxDG_KPJ; Mon, 26 Oct 2020 16:31:44 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E6E3A10CE; Mon, 26 Oct 2020 16:31:43 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 857D2548659; Tue, 27 Oct 2020 00:31:38 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7EF05440059; Tue, 27 Oct 2020 00:31:38 +0100 (CET)
Date: Tue, 27 Oct 2020 00:31:38 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: ietf@ietf.org, wgchairs@ietf.org, ietf@johnlevine.com, rfc-interest@rfc-editor.org, rsoc@iab.org
Subject: Re: Poll: RFCs with page numbers (pretty please) ?
Message-ID: <20201026233138.GA57039@faui48f.informatik.uni-erlangen.de>
References: <20201026150241.GK48111@faui48f.informatik.uni-erlangen.de> <20201026162814.GP39170@kduck.mit.edu> <20201026164036.GO48111@faui48f.informatik.uni-erlangen.de> <1a56dc3b-56ef-3ffb-a12b-44d5e0d0f835@levkowetz.com> <20201026171931.GP48111@faui48f.informatik.uni-erlangen.de> <b733240-fc78-5a71-8920-ff84fbf64287@iecc.com> <20201026180105.GQ48111@faui48f.informatik.uni-erlangen.de> <03976f9f-7f49-7bf7-ce29-ee989232a44d@gmail.com> <20201026191042.GA59330@faui48f.informatik.uni-erlangen.de> <3fd0fd96-3073-cb4f-86a0-f6ea39bc4797@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3fd0fd96-3073-cb4f-86a0-f6ea39bc4797@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/B7Ymvpl7DbgLisZq5KTQyWa8Fiw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 23:31:47 -0000

Brian:

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

Of course, i know: slippery slope argument:

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

Cheers
   Toerless

On Tue, Oct 27, 2020 at 10:16:01AM +1300, Brian E Carpenter wrote:
> 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:
> >> As Julian Reschke observed on the rfc-interest list, since the
> >> new RFC format was implemented:
> >>
> >>>  page numbers should not be used to refer to parts of the
> >>>  RFC, because page breaks vary with output formats
> >>
> >> So I can only see confusion if people use page numbers for
> >> any purpose whatever. So it doesn't matter if people want
> >> page numbers; they're now useless. So I won't be answering
> >> a poll, and I don't think the results are interesting.
> >>
> >> Regards
> >>    Brian 
> >>
> >> Regards
> >>    Brian Carpenter
> >>
> >> On 27-Oct-20 07:01, Toerless Eckert wrote:
> >>> Since about RFC8650, newer RFC will not have any renderings with
> >>> page numbers on {datatracker,tools}.ietf.org. See explanation from
> >>> John Levine below.
> >>>
> >>> Not having followed the details of the RFC/XMLv3 standardization process,
> >>> i was surprised by this because i think there is no reason to
> >>> have additional renderings, maybe even only on tools.ietf.org that
> >>> do include page numbers (and technically it does not seem to be a problem
> >>> either). 
> >>>
> >>> If you care to express your position,
> >>> i have created a poll for this, please chime in there:
> >>>
> >>> https://www.poll-maker.com/results3188562x294441dA-98
> >>>
> >>> Cheers
> >>>     toerless
> >>>
> >>> On Mon, Oct 26, 2020 at 01:35:43PM -0400, John R. Levine wrote:
> >>>>> Could you please explain why RSOC does not want to permit the ability
> >>>>> to have paginated RFC output options ? Also, where and when was this
> >>>>> discussed with the community ?
> >>>>
> >>>> It was discussed in the multi-year process leading to the IAB
> >>>> publishing RFCs 7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and
> >>>> 7998 in 2016. I'm sure you know how to find the discussions in the
> >>>> archives.  Henrik knows all of this and I cannot imagine why he did not tell
> >>>> you the same thing.
> >>>>
> >>>> I am aware there is one recent RFC author who did not participate in
> >>>> the process at all and has been complaining that the text version of
> >>>> his RFC doesn't have page numbers. I've explained this to him more
> >>>> than once, and see no reason to waste more time on it.
> >>>>
> >>>> R's,
> >>>> John
> >>>
> >>> .
> >>>
> > 

-- 
---
tte@cs.fau.de