Re: New Version Notification for draft-leiba-rfc2119-update-00.txt

John C Klensin <john-ietf@jck.com> Sat, 13 August 2016 21:20 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3380A12D0CF for <ietf@ietfa.amsl.com>; Sat, 13 Aug 2016 14:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham 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 DQmm77MXgFwZ for <ietf@ietfa.amsl.com>; Sat, 13 Aug 2016 14:20:24 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD65312B068 for <ietf@ietf.org>; Sat, 13 Aug 2016 14:20:24 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bYgLq-00095f-Jt; Sat, 13 Aug 2016 17:20:18 -0400
Date: Sat, 13 Aug 2016 17:20:13 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>, Dave Crocker <dcrocker@bbiw.net>
Subject: Re: New Version Notification for draft-leiba-rfc2119-update-00.txt
Message-ID: <1099895878F663B9CEE4F9D8@JcK-HP8200>
In-Reply-To: <alpine.OSX.2.11.1608131132570.12562@ary.local>
References: <20160813151956.6117.qmail@ary.lan> <7ffaaa30-8c75-0e12-c68d-b0df85b58bcd@dcrocker.net> <alpine.OSX.2.11.1608131132570.12562@ary.local>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VeUME-VtpJ_An8koMuP6sODARD8>
Cc: IETF general list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Aug 2016 21:20:26 -0000


--On Saturday, August 13, 2016 11:43 -0400 John R Levine
<johnl@taugh.com> wrote:

> With the new UTF-8 friendly XML formats approved, it occurs to
> me that this is the ideal time to add 必 and 能 along with
> MUST and MAY.
> 
> Note that 必 and 能 only have the 2119bis meaning when
> written in simplified characters, not when written in
> traditional characters.

This suggests an even better, and far more precise, alternative,
which is to deprecate all of the English (coded in ASCII) terms
of RFC 2119 and, instead, use "Sie müssen" or "es muss", "Sie
können" or "es kann", etc. (or in Jari's honor, sen täytyy,
sinun täytyy, se saattaa, sinä voit, etc.) any of which is
required to be written in boldface Fraktur if the special
meaning were intended.  If the rule remains that the language of
RFCs is US English, no one would have any trouble determining
when the special meanings were intended.  Because of the change
of language, even fairly dumb screen readers would be clear on
the matter (or so hopelessly confused as to make it clear that a
special meaning or phrasing is involved).  Unfortunately, it
would not be possible to use Chinese characters, not only
because of absence of case, but because an obviously-different
type style (considered a separate script in some quarters) is
not readily available.  On the other hand, I suppose one could
consider a member of the Seal script (style) family, which might
not be much more difficult for a typical reader of Chinese to
read and understand than Fraktur is for a typical reader of more
typical Latin script.

:-)

   john