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