Re: [art] New RFCs text formatting
John C Klensin <john-ietf@jck.com> Fri, 29 November 2019 14:31 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 110FB1207FD; Fri, 29 Nov 2019 06:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=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 cJ9hswxWWX-R; Fri, 29 Nov 2019 06:31:10 -0800 (PST)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A941D12016E; Fri, 29 Nov 2019 06:31:10 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1iahIX-0004oO-8M; Fri, 29 Nov 2019 09:31:05 -0500
Date: Fri, 29 Nov 2019 09:31:00 -0500
From: John C Klensin <john-ietf@jck.com>
To: Julian Reschke <julian.reschke@gmx.de>, Steffen Nurpmeso <steffen@sdaoden.eu>, ietf@ietf.org
cc: art@ietf.org, rfc-editor@rfc-editor.org
Subject: Re: [art] New RFCs text formatting
Message-ID: <F7107E01971AACB319FA5B2C@JcK-HP5.jck.com>
In-Reply-To: <725e1fd3-5af6-02f1-3a81-763797b8222c@gmx.de>
References: <5A8862BB0F82FECBBF737CC6@JcK-HP5.jck.com> <725e1fd3-5af6-02f1-3a81-763797b8222c@gmx.de>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/PABKkQuNdn0qoHyjfEEo58dTJTI>
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: Fri, 29 Nov 2019 14:31:12 -0000
--On Friday, 29 November, 2019 06:01 +0100 Julian Reschke <julian.reschke@gmx.de> wrote: >... >> Well, causing old tools, even non-public tools, to not work as >> they did before and without changes to those tools is a >> disruptive change. >> ... > > John, with all due respect, there's a reason I asked, so for > me this > question definitively is not the "wrong" question. > When we had these discussions many years ago, the assumption > was that > tools that operate on plain text RFCs would strip pagination > first (or > ignore it altogether) before doing what they need to do next. > I would > like to understand whether this assumption was wrong, and how > *exactly* > tools now break. Ok, that is fair. As can't speak for others but, as I think I said in my earlier note, some of my tools do searches on "[Page". I don't remember why but suspect it may have had to do with skipping over boilerplate or the like when those formats were changing. I don't know if my tools have other sensitivities (see below) and won't know until I try to use them and see what (if anything) breaks or do a careful code search. I'm also not claiming that it would be hard to change those tools --I just don't know without looking -- just that making me (and others) spend time adapting is possibly not in the best interests of the IETF if the total amount of time someone can spend on IETF work is limited and that adaptation time takes away from doing technical work. >... >> That is certainly what 7994 says. To me, the important >> question is whether publication in that (and other) documents >> is sufficient to warn the community about changes that may be >> incompatible with tools or working procedures used by >> contributors. If the answer is "yes", then every one of us is >> responsible for being thoroughly familiar with every RFC or >> announcement that might affect IETF procedures, publications, >> and other ways in which we do things so there is an >> opportunity to raise timely objections. I don't think we >> want to go there but should instead assume that people in the >> community should be warned by explicit questions and requests >> for consensus before incompatible changes are made. YMMD, of >> course, >> ... > > Heather has sent out mails, published FAQs, explained things > at the > plenary, and had a poster at the RFC desk for a long time. I > would say > this was hard to miss. Most of those messages have said that v3 is coming, there are big changes, throughput of the Production Center is likely to slow down. And, fwiw, I've seen the "RFC desk" twice in about three years and, for personal (but IAB/IETF-induced) reasons, have been somewhat tuned out). AFAICT, none of those messages have clearly said "if you are dependent on pagination and/or per-page headers or footer, get over it", at least without having that information buried (however unintentionally) in a lot of material that was basically noise. > PS: I have many other issues with the V3 switch, mainly that > we are now publishing "canonical" versions in a undocumented > and un-reviewed format. In comparison to that, the changes in > the produced text format currently seem to be a minor issue. What seemed to be a high likelihood of something like this happening was one of several reasons why some of us were concerned about, and opposed to, making the XML format the canonical/archival one. In this case, that concern was that, once actual deployment started, the community would discover a need to make adjustments to what was basically an untested specification. The need to debug something that had previously been tested only among the developers and other very interested parties and to make adjustments as the code was developed and evolved should come as a surprise to no one with any experience in programming or product deployment. Having the documentation be somewhat out of synch with that is no surprise either. Whether it is a minor detail or not depends on how the community reacts to the change. As I understand the announcements that have been made, people have the option of submitting text and having the Production Center sort of the details. So, suppose that, either because of the interactions with existing tools or because v3 is a someone-undocumented or under-documented moving target, some of us drop back to preparing documents using nroff (or one of its descendants), MS Word, or text directly and then submit the text files? You may know things that I don't, but I'd assume that would either require much more staff in the Production Center or would slow document throughput to a trickle for a long time. I would consider that a much more major issue that either the tools issue or the undocumented and un-reviewed format ones that feed into it. As usual, YMMD. john
- 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