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 >> >> >
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Carsten Bormann
- Re: [art] New RFCs text formatting John Levine
- Re: [art] New RFCs text formatting Claudio Allocchio
- Re: [art] New RFCs text formatting Paul Hoffman
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting Jeffrey Yasskin
- Re: [art] New RFCs text formatting Brian E Carpenter
- Re: [art] New RFCs text formatting Marc Petit-Huguenin
- Re: [art] New RFCs text formatting Paul Hoffman
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Brian E Carpenter
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting Bob Hinden
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting Carsten Bormann
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Carsten Bormann
- Re: [art] New RFCs text formatting John Levine
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting Henrik Levkowetz
- Re: [art] New RFCs text formatting Carsten Bormann
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting Joel M. Halpern
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting Henrik Levkowetz
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Joel Halpern Direct
- Re: [art] New RFCs text formatting Phillip Hallam-Baker
- Re: [art] New RFCs text formatting Nick Hilliard
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting Scott O. Bradner
- Re: [art] New RFCs text formatting Eric Heflin
- Re: [art] New RFCs text formatting Paul Hoffman
- Re: [art] New RFCs text formatting Keith Moore
- Re: [art] New RFCs text formatting John Levine
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Scott O. Bradner
- Re: [art] New RFCs text formatting Scott O. Bradner
- Re: [art] New RFCs text formatting Brian E Carpenter
- Re: [art] New RFCs text formatting Scott O. Bradner
- Re: [art] New RFCs text formatting Julian Reschke
- Re: [art] New RFCs text formatting Brian Carpenter
- Re: [art] New RFCs text formatting Salz, Rich
- Re: [art] New RFCs text formatting John C Klensin
- Re: [art] New RFCs text formatting Carsten Bormann
- Re: [art] New RFCs text formatting Salz, Rich
- Handling HTAB in artwork/sourcecode, was: [art] N… Julian Reschke
- Re: Handling HTAB in artwork/sourcecode, was: [ar… John C Klensin
- Re: Handling HTAB in artwork/sourcecode, was: [ar… Carsten Bormann
- Re: Handling HTAB in artwork/sourcecode, was: [ar… John C Klensin
- Re: Handling HTAB in artwork/sourcecode, was: [ar… Julian Reschke
- Re: [art] New RFCs text formatting John C Klensin