IETF Logo Mail Archive

Re: [xml2rfc] [Tools-discuss] [Rfc-markdown] New xml2rfc release: v3.16.0

Carsten Bormann <cabo@tzi.org> Fri, 20 January 2023 13:48 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402B9C152576; Fri, 20 Jan 2023 05:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYv6wPewfOe8; Fri, 20 Jan 2023 05:48:17 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6428FC14EB18; Fri, 20 Jan 2023 05:48:00 -0800 (PST)
Received: from [192.168.217.124] (p548dc9a4.dip0.t-ipconnect.de [84.141.201.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Nz1670whyzDCc1; Fri, 20 Jan 2023 14:47:59 +0100 (CET)
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: <147fb362-e522-8ad4-51e2-2363a6e0eeb8@petit-huguenin.org>
Date: Fri, 20 Jan 2023 14:47:58 +0100
Cc: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, Jay Daley <exec-director@ietf.org>, xml2rfc@ietf.org, tools-discuss <tools-discuss@ietf.org>
X-Mao-Original-Outgoing-Id: 695915278.4711421-06f389d3fcf720e15e082aea94adead0
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EFC7B9D-05B7-4B33-8BC6-760E080E0B4F@tzi.org>
References: <CAD2=Z87EMetcpv66YY_b2+X1-yFy4cTpKMjPoJL=cH99c7P_Uw@mail.gmail.com> <9d719176-a4eb-7cce-e706-10325700531c@petit-huguenin.org> <F1A5624B-16D0-4463-AC5F-B0A03F3B94B6@ietf.org> <8f5a497e-4135-7c0c-46cb-c3fe4791e9f3@petit-huguenin.org> <c3b3064f-e505-f504-f258-06f0d824ed4b@it.aoyama.ac.jp> <147fb362-e522-8ad4-51e2-2363a6e0eeb8@petit-huguenin.org>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/uUBcGwwhHxF67-wFQ10KB0vsgzg>
Subject: Re: [xml2rfc] [Tools-discuss] [Rfc-markdown] New xml2rfc release: v3.16.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: XML2RFC discussion list <xml2rfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xml2rfc/>
List-Post: <mailto:xml2rfc@ietf.org>
List-Help: <mailto:xml2rfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xml2rfc>, <mailto:xml2rfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2023 13:48:19 -0000

On 2023-01-20, at 14:16, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
> 
> <artwork> is one of the ways an example can be inserted in an xml2rfc document, so it could be used to clearly mark in a document examples that contain unlimited Unicode.

The fact that artwork is completely exempted from the shunned character checking of xml2rfc is a nice example why the RFC7997 handling in xml2rfc is completely misguided.

There is no indication whether artwork is normative or just supplies an example.

What we did in RFC 9290 was to move text about the example that would have been fine within a normal paragraph of text into an artwork element.  That “solved” the problem (but created others, due to some complexity of doing RTL-only artwork).

What other I-Ds are doing now is putting all their equations in artwork.
The problem is that the text around those can’t really refer to α and β etc. that occurs in the equations.

The logical, and fully absurd, conclusion is to move the rest of the text into artwork elements as well.  Hey, we could use nroff to generate word-wrapped artwork elements...

Grüße, Carsten

v2.29.0 | Report a Bug | By Email | System Status