[Cellar] non-ascii characters
Dave Rice <dave@dericed.com> Tue, 27 August 2019 14:24 UTC
Return-Path: <dave@dericed.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 2220B120236
for <cellar@ietfa.amsl.com>; Tue, 27 Aug 2019 07:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001]
autolearn=no autolearn_force=no
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 Qqge-hNwot9Y for <cellar@ietfa.amsl.com>;
Tue, 27 Aug 2019 07:24:51 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com
[68.65.122.111])
(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 ED037120220
for <cellar@ietf.org>; Tue, 27 Aug 2019 07:24:47 -0700 (PDT)
Received: from [146.96.19.240] (port=25319 helo=[10.10.201.23])
by server172.web-hosting.com with esmtpsa
(TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92)
(envelope-from <dave@dericed.com>) id 1i2cOp-003X8J-4c
for cellar@ietf.org; Tue, 27 Aug 2019 10:24:47 -0400
From: Dave Rice <dave@dericed.com>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_1AE895C0-B164-47E7-88CD-7AAB52148251"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <9B0701D1-79B5-40E0-8701-BC711282093B@dericed.com>
Date: Tue, 27 Aug 2019 10:24:41 -0400
To: Codec Encoding for LossLess Archiving and Realtime transmission
<cellar@ietf.org>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id:
dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/noQ6X-9GPJ3yB3jSeLeHHMwOgh8>
Subject: [Cellar] non-ascii characters
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission
<cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>,
<mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>,
<mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2019 14:24:53 -0000
Hi cellar, I’m doing an idnits review on the latest ffv1 draft and am confused about the IETF rules for non-ascii characters in txt rfc drafts. The update at https://tools.ietf.org/html/rfc7997 <https://tools.ietf.org/html/rfc7997> seems to allow the RFC Editor to use some discretion in using non-ascii characters, but idnits <https://tools.ietf.org/tools/idnits/> still complains about that. One instance is using a Unicode minus sign to be more semantically clear than an ascii hyphen. Also since the Unicode minus sign uses more bytes than the ascii hyphen, idnits will say the line is too long, even though in appearance the line displays within the correct width. In the RFC for ffv1, we’ve used unicode symbols for floor and ceiling functions, such as ⌊a⌋ and ⌈a⌉, but rfc2xml transforms these into their hexadecimal expressions such as ⌊a⌋ and ⌈a⌉. Any advice, should we listen to idnits and avoid non-ascii characters or listen to rfc7997 and use them when it makes the content more clear? Kind Regards, Dave Rice
- [Cellar] non-ascii characters Dave Rice