Re: [art] New RFCs text formatting

Julian Reschke <julian.reschke@gmx.de> Sat, 30 November 2019 05:38 UTC

Return-Path: <julian.reschke@gmx.de>
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 563B81200A1 for <ietf@ietfa.amsl.com>; Fri, 29 Nov 2019 21:38:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 LpDScm-xwpik for <ietf@ietfa.amsl.com>; Fri, 29 Nov 2019 21:38:34 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B5312001A for <ietf@ietf.org>; Fri, 29 Nov 2019 21:38:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575092301; bh=t+ML2XogBQTHFE0PYiQumkhXTxuUbO6wJKvrriLIy9U=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=HTwv1tknSBHv2WVftQZCGDIwQj9Golsqdgu5cQgT286jPKmw73ASr/ahQXRIk1G4T 9O9e/Hhe2ISbeZmkHU9kQSFYh/IAIWQTmCiQNDhQfbZlXjz/Lb9Hs8He7h2FSsqvxx 8TdCCp+mJOXR0ew6J2E87RZuBboTlE4p9tgFb030=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([217.251.131.2]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N5VD8-1hheFz1zP0-016y0j; Sat, 30 Nov 2019 06:38:21 +0100
Subject: Re: [art] New RFCs text formatting
To: John C Klensin <john-ietf@jck.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, ietf@ietf.org
References: <20191127233129.9829F%steffen@sdaoden.eu> <db882e3c-d3fb-4742-8456-7b400225ecce@www.fastmail.com> <20191128005000.yMa3P%steffen@sdaoden.eu> <08EE9B7B7C15D8F8B5DE6AF5@PSB> <502f830c-973d-cc9d-12b4-0bda40b05c46@gmx.de> <a5f486de-1735-266d-a139-21d46058f348@gmail.com> <9BC98F1944F184A7DC2BA973@JcK-HP5.jck.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <e107a8c3-e978-7db8-90a0-26267a0c772d@gmx.de>
Date: Sat, 30 Nov 2019 06:38:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <9BC98F1944F184A7DC2BA973@JcK-HP5.jck.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:XnwwWt9gAU56qi5L2pK7Fnmr/rFPecmgbWeR5ih7iXbAoqhBdMM KUhMPVXmgGXMGUOe3c9z/ARKrU1boeyH54cCEemmV1uZun5kiKfn0LXDMRn5EJqMTVgrxaO SMXUoN8md8ZbirBsm4BIx/yd+X7RrF7Aw108OU9o8qTjRzl+GxltzfGjNCLtxVErdHUT5F1 U8NhCAtFCBz6ep7yD00jw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:LX0G/deJdbg=:8Md54cEctC5wXJPL4iAmI4 7a0AgDaHYW67eQECMfSNU7jgoKF9ZyEMhTtlVOp6UYHsi/KqE0I7kjrJ2EYlHFX/ojMZzXv4G 52lY+sgw6jbTHGX0RDzhuZJ9uHvNfGzu5FjApZRzx610WSTQu6WpogsVB/tUqyIJPtUdGEJXw fGEiidI/aC9IqoKK1efCMhfiG412OA/mTCxWbdq/syhdjiXY08JIMgKlWMDn6akAnM4/PnOmP 5o2SNRGe9gQSRU9ghfF3B7JCo0/XlzQMzhYzGbbwhyC+nxTtEbh7U+8qLg8kpnyJ7ipBz5VeA FG2fYLffrlJf+MwDPCgvmwumq25RjVaw963We1vtiy905offKUE44bavuVZNSv8x7p0sQTNYD A5Af9XWUtOg8Ch3CniMBT/rFr/SbanaF0rLyYK9al6b4U2l2CTrsEPU8db3i7nFm8QpcWwFDt 4D6rh7WwtAYVIE7gtQkoWrr7YoA0g3S8WOQdcQtT9WbnbLTSeNL2mPZSsxft0OTKE2HTM7MT8 Q7bvOXwMp2njxhGd6GjuWstun+PnZaLWhr4vJ7Kj9zxZ1xUJLKGTOyQ3C/VkV0RTY4jVD2/90 QTqzixGhSN+3EcdVjSD5hgw924chaHXV9pOF0Jm4qSVf34wyOuvsiy5XiyGG4N9f5Ay03egPk CQOxQ6o1Jdw94f2IPpzBy3CTmBxaVVcYeab/ullXbgSrrvEcvoEATY9Ln6E/gm9vSUgGuI699 V8kZ80vpL8Wn7s8841Uyfub8E4bcJscJKKatQDQWEeiIZIqo/y+tBElXkWLwzzDaV29C3oWM4 peMy9tYloFCAfTCQa8jR8l6xB7pais2RLrPBDlydlNlB2xiBY8lqJkOxcXpTN4Ad2NuS748K1 zkAuw3ZSXdjwk26vEtt4xt365mHTHz9GSa7pVnGC/+8kVj1pgkTMrs5nCd7wB3sP3XnwZdf95 qm6ilYZ6tqrIx3DEg8gdxpFUjrfjLKIxxqwJEgMDGCrm05eMzyWEkpZyFoWwl/bZaosLGUJpU pzy0qe6c80a3D+/WyXelUPuTySBv5CKQh1LV2dZKjDVZ4xeVBoqc3vCz+YR2JJLMMsJ7k9Pgf ulHjKsoq18C5Hq/x9ydEJ735Xq1ngtjJ7PXc8EJuZakO+I2kO0PHJH3nQqwtGrjPBnlq2hrQC GOvv8kW+TowsQ88F7pQIZn9IKL4LuWRpXB+HZK3xagjvVr0QCIAssprMEVlwf7dISTu9AvZLc fyE/VTXbo0abGjOgt0XInx//LYcwCeUz/6TJ+EAFHCA1M/8YeOhaUtrtWkkc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/jpGXycplVAZfqub_O9WEPpCqPsc>
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: Sat, 30 Nov 2019 05:38:36 -0000

On 29.11.2019 23:18, John C Klensin wrote:
> ...
> I think others have commented on the assumption that pagination
> is good only if the document is headed for a line printer, but
> it may be worth pointing out that a recent errata submission may
> have identified a weakness in rfcdiff.  An erratum submitted
> last April complained about an extended example in RFC 5321
> being internally inconsistent about leading spaces that turn out
> to be important.  (see https://www.rfc-editor.org/errata/eid5711
> for details, but they aren't important).  The problem is that
> the XML source appears to be correct -- leading spaces in both
> parts of the example -- but the XML output (under v2) isn't.

So what caused the problem in the XML output? (my copy of rfc5321.xml
from AUTH48 seems to be truncated, so I can't tell).

> This wasn't caught caught during AUTH48 or earlier, or
> apparently in the decade between 5321's publication and the
> erratum, at least in because the author was relying on rfcdiff
> and it is apparently insensitive to leading, as well as other
> types of spaces.   I don't think that is a case for an emergency

That's a good reminder. I had a similar issue in the past, which I
detected when doing an *actual* diff instead of rfcdiff. It's easy to
forget though.

> fix to rfcdiff, especially one that might have side-effects I
> haven't thought about, nor a fix to v2 of xml2rfc, but it should
> be another reminder than we two be very careful about what
> xml2rfc produces, especially in a world in which the XML is the
> canonical form but that there is no requirement that the IETF's
> favorite xml2rfc processor be used to process that source (and I
> don't know enough to know whether the IETF-approved Style Sheet
> covers this situation or not).

Well, we'd have to know about the actual cause. If it was an HTAB (as
suggested by Carsten), then the answer is:

- rfc2629.xslt added a warning back in 2014

- RFC 7749 warns about HTAB in
<https://greenbytes.de/tech/webdav/rfc7749.html#element.artwork>: "Note
that processors differ in the handling of horizontal TAB characters
(some expand them, some treat them as single spaces), and thus these
ought to be avoided."

- RFC 7791 makes it an error:
<https://greenbytes.de/tech/webdav/rfc7991.html#element.artwork>: "Tab
characters (U+0009) inside of this element are prohibited."

- I'm not sure what xml2rfc does in the current version, but I reported
a bug back in April
(<https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/403>)

Finally, what do you mean by "IETF-approved Style Sheet"?

Best regards, Julian