Re: [rfc-i] Poll: RFCs with page numbers (pretty please) ?

Toerless Eckert <tte@cs.fau.de> Tue, 27 October 2020 16:03 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166FB3A0FC5 for <wgchairs@ietfa.amsl.com>; Tue, 27 Oct 2020 09:03:12 -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 8EHoeIaQ_xCR for <wgchairs@ietfa.amsl.com>; Tue, 27 Oct 2020 09:03:09 -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 6641D3A0A47 for <wgchairs@ietf.org>; Tue, 27 Oct 2020 09:03:08 -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 A8880548066; Tue, 27 Oct 2020 17:03:01 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9FBC2440059; Tue, 27 Oct 2020 17:03:01 +0100 (CET)
Date: Tue, 27 Oct 2020 17:03:01 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: wgchairs@ietf.org
Subject: Re: [rfc-i] Poll: RFCs with page numbers (pretty please) ?
Message-ID: <20201027160301.GN48111@faui48f.informatik.uni-erlangen.de>
References: <03976f9f-7f49-7bf7-ce29-ee989232a44d@gmail.com> <7FA8EF59-5CDE-42B9-A487-520531EEA1F0@juniper.net> <65374aef-e018-7bc8-ce50-d5c0a3982bf7@gmail.com> <DE3C9D6AE8EF94D87936DAE7@PSB> <75918E93-96A2-4C9A-9D60-570E7A0E1B22@ribose.com> <C393B7270B2043C75B6CA7B8@PSB> <EB282B9A-8562-43B5-AC65-31FD2CF64C5D@ribose.com> <3F09EF2A87B102C8666C72D0@PSB> <baa56cf3-bf4b-fbb7-321c-80d3af92373f@ntlworld.com> <9ab56d82-854a-9b33-a3e9-acd537bc1e70@alum.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <9ab56d82-854a-9b33-a3e9-acd537bc1e70@alum.mit.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/pZem3uhs0bbdBMy4ufEiTXwWGKM>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 16:03:12 -0000

Whot! Ae you saying IETF has no comprehensive and detailled written down
citation guidelines ? How could we have survived for so long without it ?
No proud academic publishing house can live without one!  ;-))

On Tue, Oct 27, 2020 at 11:22:46AM -0400, Paul Kyzivat wrote:
> On 10/27/20 7:33 AM, Keith Drage wrote:
> > I do agree that referencing by section numbering is the appropriate method.
> > 
> > However, as you say, it gets difficult with overly long sections, and
> > this is something on which no guidance or checking is currently given.
> > Perhaps it should be?
> > 
> > Further there are difficulties with section references if you allow text
> > between x.y.z and x.y.z.1. Does a reference to x.y.z mean the entirety
> > of the text including x.y.z.1, or merely the text before x.y.z. Other
> > organisations restrict such usage in order to make section references
> > unambiguous.
> 
> +1
> 
> Sections that contain subsections are commonly long. And not only can x.y.z
> contain text prior to x.y.z.1, it can also contain text after subsections
> that is not part of a subsection.
> 
> Perhaps the solution is paragraph numbers. But I don't know how you would
> include them in the txt format.
> 
> 	Thanks,
> 	Paul
> 
> > I also note people are referring to the XML version as the definitive
> > version, but surely the section numbers do not appear until the
> > presentation version is created?
> > 
> > Keith
> > 
> > On 27/10/2020 01:53, John C Klensin wrote:
> > > 
> > > --On Tuesday, October 27, 2020 01:30 +0000 Ronald Tse
> > > <tse@ribose.com> 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
> > > 
> > 

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