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

"HANSEN, TONY L" <tony@att.com> Tue, 27 October 2020 19:58 UTC

Return-Path: <tony@att.com>
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 63A923A14A3 for <wgchairs@ietfa.amsl.com>; Tue, 27 Oct 2020 12:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Z8RYV6x-_RBL for <wgchairs@ietfa.amsl.com>; Tue, 27 Oct 2020 12:58:09 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B10153A154F for <wgchairs@ietf.org>; Tue, 27 Oct 2020 12:58:09 -0700 (PDT)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09RJrhVa003846; Tue, 27 Oct 2020 15:57:55 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 34er9ck9j7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Oct 2020 15:57:55 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 09RJvr6h012640; Tue, 27 Oct 2020 15:57:54 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 09RJvmC7012531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Oct 2020 15:57:49 -0400
Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id C97084009E85; Tue, 27 Oct 2020 19:57:48 +0000 (GMT)
Received: from GAALPA1MSGEX1BD.ITServices.sbc.com (unknown [135.50.89.105]) by zlp30486.vci.att.com (Service) with ESMTPS id A7CB94009E74; Tue, 27 Oct 2020 19:57:48 +0000 (GMT)
Received: from GAALPA1MSGEX1BA.ITServices.sbc.com (135.50.89.102) by GAALPA1MSGEX1BD.ITServices.sbc.com (135.50.89.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Tue, 27 Oct 2020 15:57:45 -0400
Received: from GAALPA1MSGEX1BA.ITServices.sbc.com ([135.50.89.102]) by GAALPA1MSGEX1BA.ITServices.sbc.com ([135.50.89.102]) with mapi id 15.01.2044.006; Tue, 27 Oct 2020 15:57:45 -0400
From: "HANSEN, TONY L" <tony@att.com>
To: Toerless Eckert <tte@cs.fau.de>, Paul Kyzivat <pkyzivat@alum.mit.edu>
CC: "wgchairs@ietf.org" <wgchairs@ietf.org>
Subject: Re: [rfc-i] Poll: RFCs with page numbers (pretty please) ?
Thread-Topic: [rfc-i] Poll: RFCs with page numbers (pretty please) ?
Thread-Index: AQHWrHUSCMzGyQ6Yb0GDIOGltnVdtamrxE2AgAARSmGAAAhegA==
Date: Tue, 27 Oct 2020 19:57:45 +0000
Message-ID: <6DE42863-F61D-4B55-B591-45A9CA53BA57@att.com>
References: <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> <812d8443-089e-d2d6-a14e-52c125fc954f@alum.mit.edu> <20201027192733.GP48111@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20201027192733.GP48111@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.210.244.195]
x-tm-snts-smtp: 33EAC32B96FCF0D63F8B8AB4D024D268AC016B3FD1D1CFEB2ABCE7D645B59E6B2
Content-Type: text/plain; charset="utf-8"
Content-ID: <7F69973D41A27E4AA3752309BD620CFD@LOCAL>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-27_15:2020-10-26, 2020-10-27 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 malwarescore=0 bulkscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 spamscore=0 phishscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010270114
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/ac2b42aR_bWDJPoQ_-phIchU9ns>
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 19:58:11 -0000

Another quick test. I changed each pilcrow in the HTML format

like this:
<a href="#section-2-2" class="pilcrow">¶</a>
to this:
<a href="#section- 2-2" class="pilcrow"><span class="pilcrow-text">2-2</span>¶</a>

and added this CSS:

a.pilcrow > .pilcrow-text {
  visibility: visible;
  float: right;
  font-size: xx-small;
}

and a small, unintrusive section number (with paragraph) shows up on the bottom right of each paragraph. I also think it's very obvious that the numbers are not part of the text.

It's almost what I was thinking of when I helped write the text for RFC 7995. :) 

I'd rather have it in the right margin, but it was just a VERY quick test.

	Tony

On 10/27/20, 3:27 PM, "Toerless Eckert" <tte@cs.fau.de> wrote:

    Somehow literature has survived hundreds of years with references to paraprahs
    without having printed paragraph numbers. Always hard to extrapolate from what
    one has known and used forever, but i would bet that paragraph numbrers would
    only be seen as an improvement if they where made extremely unintrusive
    (tiny font, positioned outside of normal text space).

    In a lot of formal text where you know individual points will be
    cited, one should try upfront to givem them explicit number. E.g.:
    section 1.2.4, Q.4, whee you then have e.g.: a list of Q)uestions or
    the like.

    Cheers
        Toerless

    On Tue, Oct 27, 2020 at 02:54:11PM -0400, Paul Kyzivat wrote:
    > 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
    > >      >>
    > >      >
    > > 
    > > 

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