[xml2rfc] Evolving RFC 7997 (Re: [Tools-discuss] [Rfc-markdown] Move beyond RFC 7997)

Carsten Bormann <cabo@tzi.org> Sat, 21 January 2023 00:49 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C54FCC1522A1; Fri, 20 Jan 2023 16:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iNlj6lJMre0k; Fri, 20 Jan 2023 16:49:10 -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 4A2B1C15171D; Fri, 20 Jan 2023 16:49:08 -0800 (PST)
Received: from smtpclient.apple (p548dc9a4.dip0.t-ipconnect.de []) (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 4NzHmy2cVJzDCbM; Sat, 21 Jan 2023 01:49:06 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <8e33f89f-d475-b530-c432-da2979d65c6d@it.aoyama.ac.jp>
Date: Sat, 21 Jan 2023 01:49:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9D63F91-2896-4067-B14D-C1CEA6EA168F@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> <5EFC7B9D-05B7-4B33-8BC6-760E080E0B4F@tzi.org> <4e6509a8-4eab-8280-103a-02ab58caafb1@petit-huguenin.org> <E50F7D52-3EC7-4D7F-B061-E5B43F7543A8@tzi.org> <8e33f89f-d475-b530-c432-da2979d65c6d@it.aoyama.ac.jp>
To: xml2rfc@ietf.org, tools-discuss <tools-discuss@ietf.org>
X-Mailer: Apple Mail (2.3696.
Archived-At: <https://mailarchive.ietf.org/arch/msg/xml2rfc/upbqWayg5xelYiwAQ-b0zbozR9w>
Subject: [xml2rfc] Evolving RFC 7997 (Re: [Tools-discuss] [Rfc-markdown] Move beyond RFC 7997)
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: Sat, 21 Jan 2023 00:49:11 -0000

Hi Martin,

I don’t really like to defy Robert’s request for a break in this thread, but you do raise a subject not yet covered, which is how we should evolve RFC 7997.
Ultimately, this discussion needs to run in RSWG, but we can prepare for that with a tools perspective.

> On 21. Jan 2023, at 01:08, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
> […]
> My guess is that Carsten meant that RFC 7997 didn't go far enough.

Well, RFC 7997 was a weird attempt to slice up the new cake while forbidding you to eat most of the slices.
It sure went too far in this forbidding…
It’s really hard for me to look at this document and consider we (collectively) were at this state of mind nearly a decade ago.
Thus can only considered from context: After nearly 50 years of pure ASCII, going Unicode was a radical step.
People though we’d need to cushion the impact.
Which is probably true, but not to that level.
The wording sounds like a poor compromise between the people that did want to enter this century and those who simply wanted to stick with ASCII.

After another decade of device evolution, the argument that people’s devices might not understand Unicode is pretty much moot now.
(Yes, one can do weird things in Unicode, just like one could use backspaces and bare CRs in ASCII.
Let’s disregard weird things for now, and just talk about normal Unicode use.
Some guidance may be needed for what is normal use.
We may want to put up guidance such as “use NFC as much as possible”.
For general weirdness, the rule “I know it when I see it” is much better than putting up some hard boundaries based on lack of imagination.)

> - Formulæ: Using Greek letters, symbols,... in formulæ would make many
>  of them easier to understand. But RFC 7997 currently doesn't allow
>  that. I personally would fully support that.

Yes, this has to be done.
Preferably before some I-Ds that rely on this happening get published as RFCs.

> - High quality quotes, hyphens, and the like. I think this is a
>  worthwhile goal, but it requires quite a bit of thought because this
>  is an area where differences between characters are indeed sometimes
>  minuscule, and not all authors are alert enough to these differences.

That is fine.  Let the authors determine the level of quality they want to achieve.
Some of our RFCs are not much more than office memos, and typewriter look is fine for those :-)

>  Also, we'd need to have (at least a pointer to) a style guide, we
>  don't want different RFCs to use different quotation conventions.

I do not agree with this at all.
Just as with British English: If authors want typewriter quotes, that’s fine.

>  While I think that in general for non-ASCII characters (examples,
>  formulæ,...), the authors/editors/reviewers/approvers will do 95%
>  of the job of making sure they use the right characters, and the
>  RPC will just do an additional check, I fully expect that some
>  authors/editors (including probably myself) will submit rfcs-to-be
>  with ASCII quotes and hyphens, and will rely on the RPC to fix
>  that.

That is another way to approach this that is fine *if authors request that*.
(Tools like kramdown-rfc will do 95 % of the work here.
It is not without irony that we had to disable typography support by default for v3!
v2 allowed using normal quotes and dashes and down-translated this for ASCII plaintext, while rendering the real thing in HTML.)

> Anyway, for the two points above, and possibly others, we need a policy change, and so we need to move the discussion to the RSWG. I hope we can do that soon.

Yes, but maybe we can discuss the tools side of how we would support such a transition here, first, so we are prepared to deal with arguments of the form “the tools can’t do that”.

Grüße, Carsten