IETF Logo Mail Archive

Re: [rfc-i] What are current rules on non-ascii in documents?

Carsten Bormann <cabo@tzi.org> Wed, 14 February 2024 19:46 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4FDC151084 for <rfc-interest@ietfa.amsl.com>; Wed, 14 Feb 2024 11:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 wvG2feuQhxD3 for <rfc-interest@ietfa.amsl.com>; Wed, 14 Feb 2024 11:46:12 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (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 E4F18C151073 for <rfc-interest@rfc-editor.org>; Wed, 14 Feb 2024 11:46:11 -0800 (PST)
Received: from client-0165.vpn.uni-bremen.de (client-0165.vpn.uni-bremen.de [134.102.107.165]) (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 4TZpbN4SGKzDCd1; Wed, 14 Feb 2024 20:46:08 +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: <8d32c491-fff0-4a3e-9a39-d5bb6c3d930e@alum.mit.edu>
Date: Wed, 14 Feb 2024 20:46:08 +0100
Cc: "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>
X-Mao-Original-Outgoing-Id: 729632767.926801-affb2c90a47cced790015ed1995dc167
Content-Transfer-Encoding: quoted-printable
Message-Id: <63F7BA92-2C64-4246-8FB1-5B1489352020@tzi.org>
References: <8d32c491-fff0-4a3e-9a39-d5bb6c3d930e@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/Q6RxW_yjydifmtMVRqioDNEq72c>
Subject: Re: [rfc-i] What are current rules on non-ascii in documents?
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2024 19:46:16 -0000

On 2024-02-14, at 20:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> I'm doing a genart review of draft-ietf-lamps-e2e-mail-guidance-14.
> As usual I checked for nits using https://author-tools.ietf.org/idnits.
> 
> Typically this turns up a few non-ascii warnings due to author names, which I ignore. But this doc has bigger issues. It has many examples containing stuff like:
> 
> └┬╴multipart/signed; protocol="application/pkcs7-signature"
> ├─╴[protected part]
> └─╴application/pkcs7-signature
> 
> It certainly looks prettier than doing something similar with ascii characters, but making that change wouldn't harm the readability of the document.
> 
> Is this sort of usage now allowed?

Non-ASCII has been “allowed” in figures for a long time (I assume these are artwork elements or sourcecode?).

There are also no hard restrictions on non-ascii in running text any more.

The guideline is that the usage must be reasonable.

idnits has no idea of what happened in this decade, so its output is not useful (except as an alert to check reasonableness and then call it a false positive).

Grüße, Carsten

v2.23.0 | Report a Bug | By Email