Re: Evolving document sources over a long time (Re: Comments on draft-roach-bis-documents-00)
John C Klensin <john-ietf@jck.com> Mon, 20 May 2019 15:36 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 4D44F120160 for <ietf@ietfa.amsl.com>; Mon, 20 May 2019 08:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 FOksbA82tfWb for <ietf@ietfa.amsl.com>; Mon, 20 May 2019 08:36:53 -0700 (PDT)
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 99FE2120075 for <ietf@ietf.org>; Mon, 20 May 2019 08:36:53 -0700 (PDT)
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 1hSkLK-000HV2-TR; Mon, 20 May 2019 11:36:50 -0400
Date: Mon, 20 May 2019 11:36:44 -0400
From: John C Klensin <john-ietf@jck.com>
To: David Noveck <davenoveck@gmail.com>, Adam Roach <adam@nostrum.com>
cc: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Evolving document sources over a long time (Re: Comments on draft-roach-bis-documents-00)
Message-ID: <767BD1A8EDC3020C089C5BDF@PSB>
In-Reply-To: <CADaq8jciU-yC1KDmXfYc7rqc9vtS0c3D_fWeFN=GEw4bxchMkA@mail.gmail.com>
References: <CADaq8jdRMUZAN3rRXoActXqvGpkgx_-kW67uwzGLtVPoh7LfAQ@mail.gmail.com> <6E787E2A-18F2-4EFE-BFBA-61B1B4300930@tzi.org> <CADaq8jc1KJwC=Ypoo9a+-=Me=GP5tgX=2kcfUd56o53Mcu05kw@mail.gmail.com> <9179590B-C513-44DC-906C-16534DA8EC51@tzi.org> <1852d84b-48cc-0129-3564-6ec9b92c4315@gmx.de> <8A7B4E94-DBCD-4EE3-8FEA-EA642F1071BF@tzi.org> <CADaq8jeLwELxGM_zWG_OhiZ3nkm_F_a7A71B7aEv+xDdBmhYqg@mail.gmail.com> <CADaq8jciU-yC1KDmXfYc7rqc9vtS0c3D_fWeFN=GEw4bxchMkA@mail.gmail.c om>
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/TpKdV0sCgtW0bSuvWOc9O23Au8w>
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: Mon, 20 May 2019 15:36:55 -0000
David, Like Adam, I appreciate the detailed feedback. However, let me make a small appeal on the part of those of us who see (and would like to see discussion of) issues in Adam's document that have more to do with strategy (and alternative strategies) than with particular text and that of people who follow the IETF list but who have little interest in this particular topic. There are mail systems out there that, at least in the absence of prior arrangements, treat large, multiple-body-part, messages (yours was more than eight megabytes in size) as an attack and/or as requiring special per-message approval. Even for those of us with mail systems that are friendlier to larger messages (at least from IETF lists), multi-megabyte messages may discourage reading. Could you please try to figure out a way to go easy on this, possibly putting files up somewhere and supplying links to them and/or aggressively trimming previous messages? By the way, at least some of the issues with xml2rfc versions of documents and regenerating equivalent text from them result from the design of generic text markup systems: that approach was never intended to produce closely-controlled page formatting and, while the degree has changed over time, the RFC Editor has done a certain amount of page layout formatting after final approval of documents by authors and what we now call the relevant stream. rfcdiff can compensate for some of those changes but not others; "fixing" to to adjust for all such changes would probably require heuristics that, not being perfect, would then lead us to complain about incorrect results. More important, as the RFC Editor moves toward xml2rfc v3 and treating those source documents as the authoritative/archival form, the problems you describe are either going to get worse (more differences between older documents and documents in the source form preferred by the authors and the published xml2rfc v3 form) or better (because xml2rfc v3 seems to drift significantly in the direction of formatting markup, once documents are published in that form, they should be more stable and questions about matching output should become irrelevant). Some of don't consider those trends desirable, but we are fairly clearly in the rough. If you decide to take on that topic, please start a separate thread. In the interim, if Adam's document is going anywhere, he (and you) should be quite careful about changes that get down to the xml2rfc level without carefully considering both v3 and the RFC evolution (including "authoritative XML") plan and their implications. thanks, john --On Sunday, May 19, 2019 10:54 -0400 David Noveck <davenoveck@gmail.com> wrote: > Thanks to everyone for their suggestions. Now that I've > followed up on many of them, I'd like to tell everybody what > I've found so that people can consider the implicationss for > Adam's document and for the processing of upcoming updates to > RFC5661. In particular, use of the existing v1 tools has > proved quite helpful although it is not a panacea. > > So what I've found is that: > > - Even with the v1 xml2rfc, the .xml that I have gotten for > RFC5661 from the RFC editor cannot be successfully > processed. Whether you use the existing v2 xml2rfc or > the v1 xml2rfc available on the web, considerable effort is > required to get to an xml that can be processed successfully. >...
- Comments on draft-roach-bis-documents-00 David Noveck
- Evolving document sources over a long time (Re: C… Carsten Bormann
- Re: Evolving document sources over a long time (R… David Noveck
- Re: Evolving document sources over a long time (R… Carsten Bormann
- Re: [rfc-i] Evolving document sources over a long… Julian Reschke
- Re: [rfc-i] Evolving document sources over a long… Carsten Bormann
- Re: [rfc-i] Evolving document sources over a long… David Noveck
- Re: Comments on draft-roach-bis-documents-00 John C Klensin
- Re: Comments on draft-roach-bis-documents-00 David Noveck
- Re: Comments on draft-roach-bis-documents-00 John C Klensin
- Re: [rfc-i] Evolving document sources over a long… David Noveck
- Re: [rfc-i] Evolving document sources over a long… Adam Roach
- Re: Evolving document sources over a long time (R… John C Klensin
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Michelle Cotton
- Re: [Ext] Re: [rfc-i] Evolving document sources o… David Noveck
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Andrew G. Malis
- Re: [Ext] Re: [rfc-i] Evolving document sources o… tom petch
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Andrew G. Malis
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Julian Reschke
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Andrew G. Malis
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Julian Reschke
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Carsten Bormann
- Re: [Ext] Re: [rfc-i] Evolving document sources o… Salz, Rich
- Re: [Ext] Re: [rfc-i] Evolving document sources o… tom petch