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

[John C Klensin <[e-mail]>]

--On Saturday, May 9, 2020 12:33 -0400 John R Levine
<[e-mail]> 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.