Re: [Rfc-markdown] [Tools-discuss] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon

Henrik Levkowetz <henrik@levkowetz.com> Tue, 08 October 2019 23:15 UTC

Return-Path: <henrik@levkowetz.com>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05091200BA; Tue, 8 Oct 2019 16:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 c6rXmhntYFRK; Tue, 8 Oct 2019 16:15:55 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCA61200B6; Tue, 8 Oct 2019 16:15:55 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52687 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <henrik@levkowetz.com>) id 1iHyhu-000111-Te; Tue, 08 Oct 2019 16:15:55 -0700
To: Carsten Bormann <cabo@tzi.org>
References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <02046145-9455-4C01-9F6E-246D3940C86E@tzi.org> <96647ed8-2627-4434-ad51-b373eadfade6@levkowetz.com> <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org>
Cc: Tools Team Discussion <tools-discuss@ietf.org>, RFC Markdown <rfc-markdown@ietf.org>, XML2RFC Interest Group <xml2rfc@ietf.org>, xml2rfc-dev@ietf.org, IETF <ietf@ietf.org>
From: Henrik Levkowetz <henrik@levkowetz.com>
Message-ID: <b3cb1561-2809-b3b5-8cf3-67ef2b7334d3@levkowetz.com>
Date: Wed, 09 Oct 2019 01:15:46 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <347055CD-74C9-479B-B7FC-BA78580C37B5@tzi.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="kTm59LbtfeSD89s3WWgNSO4nqnBxkoGQP"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: ietf@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, tools-discuss@ietf.org, cabo@tzi.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/HopMx34pGBgwEfcqiZ7_HyQ_Snk>
Subject: Re: [Rfc-markdown] [Tools-discuss] [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon
X-BeenThere: rfc-markdown@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2019 23:15:57 -0000

Hi Carsten,

On 2019-10-09 00:46, Carsten Bormann wrote:
> On Oct 9, 2019, at 00:18, Henrik Levkowetz <henrik@levkowetz.com> wrote:
>> 
>> Signed PGP part
>> Hi Carsten,
>> 
>> On 2019-10-08 23:48, Carsten Bormann wrote:
>>> On Oct 8, 2019, at 23:23, Russ Housley <housley@vigilsec.com> wrote:
>>>> 
>>>> (2) The default output formatters will change to v3.  The v2 formatters
>>>>   will still be available by using a --legacy switch.
>>> 
>>> Please do this in a way that will not randomly break scripts and
>>> other programs that need to run xml2rfc. (A calling script/program
>>> has no idea what version of xml2rfc is installed locally.) [Actually,
>>> that is also true of people calling xml2rfc…]
>> 
>> Does it work for you if we say 'if you want v2 output, please add --legacy
>> to your scripts already now’?
> 
> It sure works for me, but I don’t know all the other users of my software.

Ack.

>> The --legacy switch to force v2 output (for compatible input) has been
>> available for around 6 months, so even if you don't have the bleeding
>> edge version installed, this should work as a compatibility path, I think?
> 
> 6 months is very short in the grand scheme of things.
> 
> Generally people will upgrade tools like kramdown-rfc and xml2rfc on
> different timelines. (And there are also a few hundred makefiles in
> some repositories somewhere that call xml2rfc.)
> 
> With that out of the way, I must admit I don’t even understand what
> this means:
> 
> Format Options:
>     --v3                                with --text and --html: use the v3
>                                         formatter, rather than the legacy one.
>     --legacy                            with --text and --html: use the legacy
>                                         text formatter, rather than the v3
>                                         one.
> 
> Does the choice of “legacy” and “v3” formatter have an influence on
> the accepted XML vocabulary?

Only indirectly.  If you use --v3, the new formatters will be used.
xml2rfc will accept both v2 and v3, and run the v2v3 converter internally
in order to not present any deprecated elements to the v3 formatters.

If you use --legacy, the old formatters will be used.  Since there is
no internal v3v2 converter, only v2 input will work.  

> On the output format?

Yes, that's the primary effect intended with these switches.

> Both? How?

Maybe a processing diagram will help:

http://tools.ietf.org/src/xml2rfc/trunk/cli/doc/xml2rfc3.html#processing-flow


Regards,

	Henrik