[xml2rfc] Evolving <u (Re: [Tools-discuss] [Rfc-markdown] New xml2rfc release: v3.16.0)

Carsten Bormann <cabo@tzi.org> Fri, 20 January 2023 09:17 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 A6B7EC14CE55; Fri, 20 Jan 2023 01:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BFuj0wNd7OeT; Fri, 20 Jan 2023 01:17:25 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::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 6E6DFC14EB14; Fri, 20 Jan 2023 01:17:23 -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 4Nyv5s1KwhzDCdc; Fri, 20 Jan 2023 10:17:21 +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: <91C1EBAB771E004FD6EB9761@PSB>
Date: Fri, 20 Jan 2023 10:17:20 +0100
Cc: xml2rfc@ietf.org, tools-discuss <tools-discuss@ietf.org>
X-Mao-Original-Outgoing-Id: 695899040.279474-0363bee2408ef2f945146e2fdcdc9e6a
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2869F48-ABC3-4EF3-96DB-BA3F38C7273E@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> <3B53040D-9B5F-4410-9029-459729ADFDF8@ietf.org> <7d532a76-c750-8cb6-fc86-f6242da2bc77@petit-huguenin.org> <27182BDD-899E-4238-9DF8-7AE3E0F0C18F@akamai.com> <11a20f42-4fe6-8d8d-1d76-54049d0bdb68@petit-huguenin.org> <6179D431-EC33-49B9-A793-805E926C1050@akamai.com> <6d55cf67-1ce2-8094-dda4-ab877ac2a1d7@petit-huguenin.org> <1573D125-B3A9-4839-A1B2-DAD87FBB5DA6@ietf.org> <91C1EBAB771E004FD6EB9761@PSB>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/ZW5s-WLKKCqJ_QMRLPCW8xVDeYQ>
Subject: [xml2rfc] Evolving <u (Re: [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 09:17:29 -0000

On 2023-01-20, at 04:43, John C Klensin <john-ietf@jck.com> wrote:
> 
> (2) Retaining the <u> element,

Obviously.

<u is a great aid for those places where supplying the code point is useful.
It can avoid rather likely clerical errors, and generally just saves work in those cases.

Note that when I’m using α or β as a name for a parameter, hitting the right code point is irrelevant (*).

<u could be improved by removing the need to have -num- in the set of expansions.
Also, an <u just with a -lit- would be an appropriate “[sic]” for reviewers.

Assuming we update 7997 such that this can be done more routinely: for routine use of non-typewriter characters such as „ or “ or — or −, a processing instruction that serves as a global “[sic]” would help linters point out any remaining actual accidents in using these.

Grüße, Carsten

(*) OK, Pete beat me up properly in private for using א and not ℵ in a recent example (involving ℵ₀) — but here it is important for authors and editors to hit the right code point; the reader doesn’t care.