Re: [xml2rfc] Insufficiency of txt format

Carsten Bormann <> Mon, 01 February 2021 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A3163A1326 for <>; Mon, 1 Feb 2021 09:21:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1EQoHj2J2GZm for <>; Mon, 1 Feb 2021 09:21:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1C4E3A131C for <>; Mon, 1 Feb 2021 09:21:23 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DTvqj5V0bzyVL; Mon, 1 Feb 2021 18:21:21 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Mon, 1 Feb 2021 18:21:21 +0100
X-Mao-Original-Outgoing-Id: 633892881.2364531-8a3bd9a6a9520d2018429d13157db0d9
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20210130190821.7504E6D02AD4@ary.qy> <> <rv7pcs$fv0$> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [xml2rfc] Insufficiency of txt format
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Feb 2021 17:21:26 -0000

On 2021-02-01, at 17:34, Paul Kyzivat <> wrote:
> I'll be dead before v2 xml is.

I hope not, but this is an indication of the timelines we have to think in here.

Also, our documents have drawn-out timelines, during which the authoring-format-du-jour will change (as will even the “canonical” format).

So txt-level comparison needs to be part of any sustainable long-term strategy.

The interesting part here is normalization.  Rfcdiff has been normalizing the txt all along by removing footers and headers.  It could add normalization steps such as turning box-drawing characters into legacy ASCII.  If thinking about the comparison story is part of the strategy, such a presentation change could become invisible to long-timespan diffs.

Doing XML-level comparison could be aided by converting to a format such as Pyx (line-based ESIS representation) first.  Again, further normalization is crucial (as we have seen in the example of random attribute order already). The most ugly part here is likely to be white-space handling, which is a very sorry story for XML in general, but could be handled in a schema-driven way for RFCXML.  Also, preptool-generated attributes could be removed in the normalization (but they also can carry useful information).

Grüße, Carsten