Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07

John C Klensin <john-ietf@jck.com> Sat, 09 May 2020 17:14 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080B93A0C9B for <i18ndir@ietfa.amsl.com>; Sat, 9 May 2020 10:14:51 -0700 (PDT)
X-Quarantine-ID: <pKOIG0rT9UB0>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 20 hex): References: ...34991439@ietfa.amsl.com> <CALaySJ+CRJu[...]
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 pKOIG0rT9UB0 for <i18ndir@ietfa.amsl.com>; Sat, 9 May 2020 10:14:48 -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 DDEB23A0C5F for <i18ndir@ietf.org>; Sat, 9 May 2020 10:14:47 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jXT3l-0000GS-Ic; Sat, 09 May 2020 13:14:45 -0400
Date: Sat, 09 May 2020 13:14:39 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>
cc: i18ndir@ietf.org
Message-ID: <E2DF7CC33EB6BBE586E95632@PSB>
In-Reply-To: <alpine.OSX.2.22.407.2005091211170.84818@ary.qy>
References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <CALaySJ+CRJumYtDCxvGsSwzanz4y=7icuqd+toc0wMivf-mJGg@mail.gmail.c om> <CAD7Fb3diej1-3fAgqZsS_E9wOs1KC=OwVWbvxV5mVjOdQEQm5g@mail.gmail.com> <791ca602-758e-cb0f-a1a4-8fb6b74a8b61@outer-planes.net> <6F916805FF734CB450A3C724@PSB> <alpine.OSX.2.22.407.2005091211170.84818@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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/i18ndir/pnh9hsdmO39D5bLu6c-OTnzGBF0>
Subject: Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 May 2020 17:14:51 -0000


--On Saturday, May 9, 2020 12:33 -0400 John R Levine
<johnl@taugh.com> wrote:

>> I see nothing in either the body of the document nor in
>> Appendix B that  makes it explicit that support for UTF-32
>> has been dropped.  I think  such a comment should be added
>> and explained, even if the explanation is  that no one
>> significant is accepting it any more and it is therefore NOT 
>> RECOMMENDED and being dropped from the spec.
> 
> I agree that a comment saying that UTF-32 is dead as an
> interchange format would be reasonable.
> 
>> Noting (again) that, absent a BOM (or even with one) UTF-8
>> cannot be reliably distinguished from ISO-8859-X (for any
>> registered or unregistered value of X), ...
> 
> I'm wondering how much this matters in practice.  I see a lot
> of javascript libraries entirely in ASCII, since non-ASCII
> characters only appear in variable names and in string
> literals and comments.

Martin's comments (IMO, helpful but somewhat pedantic relative
to the issues involved) and my (much more pedantic) response
notwithstanding, my guess (like yours) is that it is unlikely to
make much difference in practice, at least as long as the text
is not actually UTF-16 (BE or LE).  However, I think it is
inappropriate for an IETF consensus document [1] to say
something that amounts to "this will work" when the reality is
"this will work most of the time" or, if a formulation closer to
Martin's is preferred, "this will work except in extremely rare
cases" [2].  So, setting aside the issues with "extremely", a
statement somewhere to the effect of "these heuristics are
pretty good, but they are still heuristics and may fail
occasionally, so implementations should be designed to not fail
catastrophically [3] if a failure occurs" seems appropriate.  In
case it has not been clear, statements like that are what I mean
by a "heath warning".

best, 
   john

[1] Noting that is the new requirement.  At the time RFC 4329
was published, it was possible to interpret an Informational
document like that as the opinion of the author.  With the new
requirement for IETF consensus for any document published in the
IETF stream, any ignorance is the IETF's ignorance and is, at
best, a bad idea.

[2] Comments in my previous message about "extremely"
incorporated by reference.

[3] I consider a program halt (or something like it, including
the notorious bloe screens) or a presumed error message with
semantic content equivalent to "you lose" to be a catastrophic
failure, while I consider "I couldn't figure out what the
character encoding was; it certainly wasn't the UTF-8 I
expected" to be a sensible error message.  YMMD.