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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 27 October 2020 18:54 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 E5E8B3A15C7 for <wgchairs@ietfa.amsl.com>; Tue, 27 Oct 2020 11:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 TbfvKAT5opJf for <wgchairs@ietfa.amsl.com>; Tue, 27 Oct 2020 11:54:34 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2057.outbound.protection.outlook.com [40.107.243.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639013A14A2 for <wgchairs@ietf.org>; Tue, 27 Oct 2020 11:54:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kmv5CZjoivAFSpQwWBm14Z2r8AhlJIfqxZcLHw4CLV1Iilm66bwUPVOPp6bucwTTPLGyZCgnfwI1o2BJEZ7QBJfsKb0K4TRUh8M5rtmtSxYqRKsIlr+fOSXmfEjxF8VTsqMwLK0SCk7jOI/KUppYLrPQDsHWi/zKfkSPOcMuXsJZ2TKQn1c/XhI+l+E+rGxYMTUbLRbuxn4tEfNRWAXk+RDr80ov9e7y6a20MoTbm1e42GliFjaLyJNck3Mm/h4ninUhP0Of3K08kZfyM9vvWN/4HgeglPoyZ1cDv63ph+r4Ow6mTwXj75TZ+i22LHch50t4JFHxFHrJaqCkqsVUqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZB/5mvm9fQne08eHsdo7iWSAzDVz7sh2lUO4s941biY=; b=gFEN7vILnelwg1+SOJySe9l260Xz2Iu4BnfqSDNJp6R/DoC81yyw5MUUYb8OUtlvlgImfbKqPpo2TyrI5K0E/uHdJW2R6lVPozFkkS2FDsZKkapswPyzyQZ6LxyRZQHVwAmn1QjTgWsuL34BJ3m85QQYfeJiA6Ix0W38PVvcbFAHME4fLC4M97n/tcbR/ExxqrsfpkGMyFJnSit4G0B7nORcD6JI3eQT5kBEx1/wsAtXfrRobmc0ilnCdNZXpJrEQwe+yl5GszX1W5pml3mffuSAL30xFao6Y+//+k6fFVdyeyTBiphtX4LZEY6x2IbkbefNsp7xQbLqLhlgrtv3Cg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=att.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZB/5mvm9fQne08eHsdo7iWSAzDVz7sh2lUO4s941biY=; b=btJKMLjOpgyWi1/NDHL/t0trOTjl3odRyZ0qJdSftoe/kbSVuyu5YZGE3b39S5St5WN3bbGPvIYXaIlffAZLcTtp5TZvVZZuFC/vIS1gGQJiu9ICk9oT+4myeju8+Kh0VK/3t9fKEyxZdOpgYetwdP5ZLb6l3MF+SZ+LfWXMtNA=
Received: from BL0PR01CA0024.prod.exchangelabs.com (2603:10b6:208:71::37) by CY4PR12MB1141.namprd12.prod.outlook.com (2603:10b6:903:44::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.23; Tue, 27 Oct 2020 18:54:14 +0000
Received: from BL2NAM02FT041.eop-nam02.prod.protection.outlook.com (2603:10b6:208:71:cafe::99) by BL0PR01CA0024.outlook.office365.com (2603:10b6:208:71::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Tue, 27 Oct 2020 18:54:13 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT041.mail.protection.outlook.com (10.152.77.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.20 via Frontend Transport; Tue, 27 Oct 2020 18:54:13 +0000
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09RIsCAS014706 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 27 Oct 2020 14:54:12 -0400
Subject: Re: [rfc-i] Poll: RFCs with page numbers (pretty please) ?
To: "HANSEN, TONY L" <tony@att.com>, "wgchairs@ietf.org" <wgchairs@ietf.org>
References: <20201026020433.GA19475@faui48f.informatik.uni-erlangen.de> <35EFE952-7786-4E24-B228-9BEE51D3C876@tzi.org> <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> <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> <3125A9F3-B2F5-43FE-B7B6-B4D58FD48308@att.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <812d8443-089e-d2d6-a14e-52c125fc954f@alum.mit.edu>
Date: Tue, 27 Oct 2020 14:54:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <3125A9F3-B2F5-43FE-B7B6-B4D58FD48308@att.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: de5091c8-18f1-485a-19ad-08d87aa9b269
X-MS-TrafficTypeDiagnostic: CY4PR12MB1141:
X-Microsoft-Antispam-PRVS: <CY4PR12MB114138424C34548BD65DCCCBF9160@CY4PR12MB1141.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: BAT7jFKWiCbjKvG7FBXe4JjYdyFyzCIBXRLIuFjYl3kYlq1lBrBCz/doXQGZ1cgSStdkfCnY+jfbu3b9Mfy5CFCiioPtfyCxfVBgxiS8ZEjrgrPWow8icTvMA0IkNbfnqXq8HN4nYz2Uz2h7klFQszKMFX97wVeeUxQdzeLhAz+zFdxOcge8YK3DA3k7UE30ePs8SPl1jvqmySbVniyevCVTdS5fFBZdRxxqYK6tkkmPjfpnXWpwM5fkgLx8aRh7YI++VttRS6ib6o+AaCRqTvYABrk1kqANefeLYzXIv1pvkNwp5RTGfLwII8xfx/dlW1vicTkJ8P8w8Iz+faB1oy7Wc7L/Yaps/JLR4L3DDAdQlXAs71RdDWn+0ix1BA5rrY9BH/wJ47/huyHDPGVsUyJ2Yd1jHapGNMZPq0U2LRY=
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(39860400002)(136003)(376002)(346002)(396003)(46966005)(75432002)(2906002)(31696002)(2616005)(86362001)(31686004)(36906005)(47076004)(316002)(786003)(26005)(186003)(110136005)(82310400003)(7596003)(82740400003)(53546011)(336012)(5660300002)(956004)(83380400001)(70586007)(8676002)(8936002)(70206006)(478600001)(356005)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2020 18:54:13.3649 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: de5091c8-18f1-485a-19ad-08d87aa9b269
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT041.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1141
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/XdjXZROvZKKxg9mpZKXJCvHkUW4>
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 18:54:44 -0000

If paragraph numbering were added to the txt format, and didn't break 
the diff tools) IMO it would solve the problem of making references into 
long sections.

Note that there is already sometimes a problem in going from the side by 
side diff format to the corresponding place in the full document, 
regardless of format. Paragraph numbers would help solve that too.

	Thanks,
	Paul

On 10/27/20 2:25 PM, HANSEN, TONY L wrote:
> Typical placement for paragraph numbers is within the right margin.
> 
> RFC 7995 (RFC PDF format) has this recommendation:
> 
>     Recommendation:  When the XML "editing=yes" option has been chosen,
>        show paragraph numbers in the right margin, typeset in a way so as
>        to be unobtrusive.  (The right margin instead of the left margin
>        prevents the paragraph numbers from being confused with the
>        section numbers.)  If possible, the paragraph numbers should be
>        coded in such a way that they do not interfere with screen
>        readers.
> 
> RFC 7994 (RFC text format) has this to say about paragraph numbering:
> 
>     Where practical, the original guidance for the structure of a
>     plain-text RFC has been kept (e.g., with line lengths, with lines
>     per page [INS2AUTH]).  Other publication formats, such as HTML and
>     PDF, will include additional features that will not be present in the
>     plain text (e.g., paragraph numbering, typographical emphasis).
> 
>     The details described in this document are expected to change based
>     on experience gained in implementing the new publication toolsets.
> 
> The HTML format generates paragraph numbering with pilcrows. However, you have to hover over the pilcrows to see those numbers.
> 
> Personally, I would support extending support for paragraph numbers to the text format as well, possibly even enabled using the same "editing=yes" option.
> 
> Note: I haven't tried this option to see if it actually works with the PDF format.
> 
> 	Tony Hansen
> 
> On 10/27/20, 11:23 AM, "WGChairs on behalf of Paul Kyzivat" <wgchairs-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> 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
>      >>
>      >
> 
>