Re: [art] New RFCs text formatting

John C Klensin <john-ietf@jck.com> Sun, 01 December 2019 20:24 UTC

Return-Path: <john-ietf@jck.com>
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 780FA12004D for <ietf@ietfa.amsl.com>; Sun, 1 Dec 2019 12:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 woMBracIHM-u for <ietf@ietfa.amsl.com>; Sun, 1 Dec 2019 12:24:12 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D26D120106 for <ietf@ietf.org>; Sun, 1 Dec 2019 12:24:12 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ibVlB-000NlE-28; Sun, 01 Dec 2019 15:24:01 -0500
Date: Sun, 01 Dec 2019 15:23:55 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Scott O. Bradner" <sob@sobco.com>, Keith Moore <moore@network-heretics.com>
cc: Carsten Bormann <cabo@tzi.org>, ietf@ietf.org
Subject: Re: [art] New RFCs text formatting
Message-ID: <8634525F24CDFF738A82BD83@PSB>
In-Reply-To: <DE061B13-E6BB-43E5-B814-F44868A23CFF@sobco.com>
References: <86428447-b3d5-92b0-b404-2b94a5915385@foobar.org> <6EA0235C-BC0F-466D-8222-9F1C557421E1@network-heretics.com> <DE061B13-E6BB-43E5-B814-F44868A23CFF@sobco.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zvkGHwS198AoTYGJ7qASNPRBugU>
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: Sun, 01 Dec 2019 20:24:14 -0000

I would say "+1" too, except that, from experience, the implicit
characterization of paginated (and header and footer-equipped)
plain text as being only about printing (especially, as has come
up in other notes, printing on ancient, perforated-paper, line
printers) misses the point that there are at least three reasons
that I can think of to prefer that format (other than
idiosyncratic personal taste, but I don't think the IETF gets to
say that even the latter is illegitimate).  Those are:

(1) One really does intend to print the document and has a
printer, or printer drivers, that make handling of documents
without page breaks difficult.  As Paul Hoffman just pointed out
(and I pointed out last week), RFC 7994 requires pagination (but
just page breaks, not headers or footers) for the RFC output.
If RFCs are being produced and put into the archives / available
from the RFC Editor's server) that don't have those page breaks
in the plain ASCII form (and we seem to have at least one
example) that is a bug and it is, at least IMO, reasonable to
ask how soon it will be fixed (and maybe why it happened).

(2) One has discovered that, regardless of the format in which
one prefers to read RFCs, it is easier to work with them in
plain text format using public tools like "grep", some
highlight-copy-and-paste operations, and so on.  Most, perhaps
all, of those uses require that plain text files be available;
few, if any, require pagination, much less headers, footers, or
page numbers [1].

(3) One has private tools (or obscure public ones that there has
been no evidence that anyone other than their authors know
about) that are actually dependent on the presence of headers
and/or footers and/or usable page numbers.

So, I think that Keith should have said "only if there's rough
consensus that
none of the three cases above exist anymore.  If they do, there
is rough consensus that the IETF is willing to tell users whose
work falls into one of those categories that we are just not
interested in their problems and that, if the result is that
they reduce their participation or willingness to accept RFCs
for other purposes, we just don't care."

best,
   john

p.s. Some of the comments about A4 paper make questionable
assumptions about how line and page lengths for RFCs were
chosen.  It may well be that we (and I do mean "we" because I
was involved in the discussion although I certainly was not the
decision-maker) got it wrong, but the assumption that is was not
considered is simply incorrect.

[1] As I have discussed elsewhere and will not repeat unless
asked, the claim that eliminating the ability to reference into
an RFC by page number and therefore encourage shorter sections
has actually been disproven by years of experience.  The only
things that encourage or forces shorter sections are author
education and the RFC Editor insisting that they will not
publish a document with too-long sections without a very
specific justification (at least unless the Stream Manager
insists and then probably with the appropriate note).


--On Sunday, December 1, 2019 12:55 -0500 "Scott O. Bradner"
<sob@sobco.com> wrote:

> +1
> 
>> On Dec 1, 2019, at 12:52 PM, Keith Moore
>> <moore@network-heretics.com> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Dec 1, 2019, at 12:28 PM, Nick Hilliard <nick@foobar.org>
>>> wrote:
>>> 
>>> I'd be happy for pagination to be the default if there were
>>> rough consensus that the primary medium for reading RFCs was
>>> printed paper.
>> 
>> Seems like this is backwards.  Pagination should be removed
>> from plain text RFCs only if there's rough consensus that
>> nobody prints RFCs anymore - not because a few individuals
>> think that nobody should do that, or think that they're in
>> a position to dictate how RFCs are used. 
>> 
>> Keith
>> 
>> 
>