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

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

Hi.

Given that I felt a bit attacked for stepping in earlier
(although I'm obviously pleased that John incorporated some of
my comments in his review), a few comments that can be passed
along or not as people prefer....

--On Friday, May 8, 2020 18:00 -0600 "Matthew A. Miller"
<[e-mail]> wrote:

> Thank you very much for the review, John.  This is very
> helpful, and will work on changes to resolve the concerns.
> 
> Regarding the encoding:
> 
> UTF-8 is strongly encouraged, and required for a source to be
> a module.  Preferring BOM sniffing over a charset declaration
> is the result of general purpose browsers having to deal with
> a myriad of misconfigured servers; this being the defense
> mechanism that permitted the best interoperability.
> 
> The part about "longest matching octet sequence" is a missed
> remnant from the original document which included UTF-32BE/LE
> entries.  As UTF-32BE/LE is no longer found in the wild*,
> those entries were removed but I missed cleaning up that
> sentence.

An observation with the understanding that I'm not advocating
for UTF-32, in either ordering, and especially not on the wire.
First, until Unicode deprecates it (which, AFAIK, they haven't
done), "no longer found in the wild" is a rather bold statement
(analogies to the recent IETF list discussion about POP2 come to
mind) and rather different from "no current or recent version of
any browser with which the authors are familiar accepts and
supports UTF-32 encodings" (which is what "Web browsers haven't
accepted UTF-32 encodings of JavaScript for quite a long while"
almost certainly means).   I have no information about
Javascript specifically, but I'm aware of several systems that
still use UTF-32 for internal processing because, if one does
not have storage space limitations, there are significant
advantages of having exactly the same number of octets (four)
for each code point regardless of where it falls in the Unicode
tables and hence without the need to pack and unpack UTF-8 or be
aware of and process surrogates.   

More important, my understanding of the general practices in the
IETF for many years is that we don't deprecate features that may
once have been accepted and used, even if not "for quite a long
while") by simply removing them and assuming that readers will
observe their absence and make the appropriate inferences,
whatever those might be.  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.


 
> Implementations today do ignore the BOM once the character
> encoding is worked out, so this was portion from Section 4.2
> was kept to reflect that.  I'm not sure what changes to make
> here regarding that, although the ending "to source text" is
> another missed remnant from my editing that will be removed.
> 
> Section 4.2 still includes step #3 to deal with the (in
> practice quite common) case of a missing BOM and the media
> type missing a charset parameter.  There are also too many
> servers that set this to "ISO-8859-1" without otherwise
> examining the sources being served. We'll make it clearer this
> is a default/fallback case.

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 don't know what the
default/fallback case actually is or, more generally, what  the
above paragraph means.  Unless I have misunderstood something
important, the reality is that, if there is anywhere on the
Internet that a web browser or server (including decades-old
embedded servers) treat ISO/IEC 8859-1 as either the default or
legitimate, then there are two possibilities: accurate labeling
of the charset in use or use of heuristics that, by their nature
and the nature of possible CCSs (not just encoding schemes), may
fail.   That calls for at least a health warning in the
document, not proceeding as if the heuristics are foolproof.

best,
   john

p.s. Noting a recent unpleasant discussion on the IETF list and
that the review is being handled as an individual one rather
than as a conclusion by the directorate, if any ideas or text
are taken from this or my prior comments on the draft, I expect
that, consistent with BCP 78, those comments will be attributed
so they can be properly acknowledged in the I-D.