Re: [Ietf-and-github] [Ext] GIT WG disposition

Carsten Bormann <cabo@tzi.org> Thu, 24 June 2021 19:04 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf-and-github@ietfa.amsl.com
Delivered-To: ietf-and-github@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6B43A27B9 for <ietf-and-github@ietfa.amsl.com>; Thu, 24 Jun 2021 12:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MaZIW-3bHTdG for <ietf-and-github@ietfa.amsl.com>; Thu, 24 Jun 2021 12:04:48 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEB13A27BA for <ietf-and-github@ietf.org>; Thu, 24 Jun 2021 12:04:48 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G9qM16tL4z2xHV; Thu, 24 Jun 2021 21:04:45 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAKKJt-cd7S-GTTZvs7g5_4cnZ460SiyPXCoKzCinoYU48pOhXg@mail.gmail.com>
Date: Thu, 24 Jun 2021 21:04:45 +0200
Cc: "Salz, Rich" <rsalz@akamai.com>, Tim Wicinski <tjw.ietf@gmail.com>, "ietf-and-github@ietf.org" <ietf-and-github@ietf.org>
X-Mao-Original-Outgoing-Id: 646254285.463773-1c6510deb20bade0ecfcb2cbcceb8e5c
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E0A67AA-AEA2-4FE9-AE3C-26EB752A8DFF@tzi.org>
References: <122FF431-7981-4D29-820F-3C16C7F723AB@icann.org> <FC51AE17-FA9D-483A-8077-E0B78DAD617C@gmail.com> <CAKKJt-cefZzz3m3hcE0Cj99v11BqkBbyeJ7XtQqLoBbVKjUmEQ@mail.gmail.com> <6DF940E4-AAF0-48AA-89FE-0FBAFD2678EA@akamai.com> <CADyWQ+EVzFNmePRmjKxTnrmJTg6fUwThBy6R5buc_8ANM4YdYg@mail.gmail.com> <7AD8F122-5082-4A04-874D-72C5D05AAA9F@akamai.com> <CAKKJt-cd7S-GTTZvs7g5_4cnZ460SiyPXCoKzCinoYU48pOhXg@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-and-github/-neyBKvA24nCKh1r2ELz4taGz7s>
Subject: Re: [Ietf-and-github] [Ext] GIT WG disposition
X-BeenThere: ietf-and-github@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of using GitHub in IETF activities, particularly for Working Groups" <ietf-and-github.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-and-github>, <mailto:ietf-and-github-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-and-github/>
List-Post: <mailto:ietf-and-github@ietf.org>
List-Help: <mailto:ietf-and-github-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-and-github>, <mailto:ietf-and-github-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2021 19:04:53 -0000

On 2021-06-24, at 20:23, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> A day or two before that, I tripped over a bug that kramdown-rfc2629 currently produces v2 rfcxml (aka xml2rfc v2 input),

(That is not the bug.)
Kramdown-rfc2629 actually produces output that is optimized for conversion by xml2rfc into whatever xml2rfc happens to consider to be the v3 of the day.
(Using the --v3 flag on kramdown-rfc2629 enables using all of the v3 features and gives up v2 compatibility for that.)

> but xml2rfc command-line by default assumes --v3. If it sees v2 input, it internally runs the v2->v3 converter,

Exactly, but that is designed to eat v3-in-a-v2-shell as produced by kramdown-rfc.

> so the tools team needs to change the datatracker's submit code (which uses xml2rfc as a library) to run v2v3 when it sees v2 now instead of just running the v2 parser.

Right, *that* is the bug (i.e., trying to stick to pre-transition software when the <rfc> element doesn’t happen to look just right).
(Note that the pre-transition software is *not* being used by the RFC production center, so this approach is not only the wrong one to run a transition, but also produces late surprises when publishing the document as an RFC.)

> This one was discussed in a TRAC ticket, by Robert Sparks' request (at https://trac.ietf.org/trac/ietfdb/ticket/3305).

Indeed, and I look forward to getting that fixed.

I still recommend generating the .v2v3.xml before going to datatracker's submission interface, so there is more control over the generation process; it has not always been clear what version of xml2rfc is running under the submission process (sometimes weird environmental issues such as locale mess this up).

(If the above sounds a bit jaded:  The transition strategy used by xml2rfc works exceedingly well, and I have a lot of respect for Henrik and others getting this right at such an amazing level of precision.  It’s just incredibly frustrating when that great tool then is wedged into a submission process that doesn’t handle the transition as well.)

Grüße, Carsten