Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
Asmus Freytag <asmusf@ix.netcom.com> Sat, 09 May 2020 04:21 UTC
Return-Path: <asmusf@ix.netcom.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 946D13A0366 for <i18ndir@ietfa.amsl.com>; Fri, 8 May 2020 21:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com
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 ppFxelF9yjaI for <i18ndir@ietfa.amsl.com>; Fri, 8 May 2020 21:21:40 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (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 508BA3A0365 for <i18ndir@ietf.org>; Fri, 8 May 2020 21:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1588998100; bh=qB9HJ4Cvf4iYQ2YGQevTqSfKuoJK46HUL/s/ cHFLBts=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=F/EjMKUDk78qnXinI278hmOgb5LVqVoWq yFFLjBlxAcETNC5HcCvJkLoBxLWdwgka7NpsGoP1KxRyT8Xx1cxzm5hZpzB4UrOBX71 qJPJ2Uq21P2Q0a5mcsPWZ5PyljtNUa0er9dckhLwiEfEs/ntI0Jnv81oaLuAZI7wGgi s8VBaGvCT2JftZsF++xrbvBo6oxsA67v+Cgak/Rsait1CK5a5OZUJMgLlI0NIDTOafs NX8OD21SqwTyu4Xc8uu46zW0AdPWNULpXMx8VE+ooRRmV3RBCNMXupP5KBbdGEFVLmU SkMQIkDNoh4jpX2MVezp2YS4sv5exyTOQgn/TzSzw==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=MBnvCfEz/QQ4QnsgaKUS4D2pHWe+0/XAaambzfrUZUiGUiYK8nRlJKrfqyZGlp3gt7KoDAaSr+DKZD6WGLfl4/6LBIh02zlEf143wCNcPhVFis9iPYRmxkszGkiez1qUjkNyBd9DcHzArJHohI5g3kqDNtRqESQ7aF2VrpY1e2XOFbShRjqEAnACxPOXTwoDnAzY9vSNsD+waO27g9X72N9wHPBJ9C3zXVQQA0YDhfiyvuzyD89GkPZZn0GlNIALbYsQVC+x91ZD+PvdshJD6OmjWsOjRJ/4womWkaYzCSDrWLv4F4maAa8qj3XWlvr6aCQPx//5rdh+4bi9J0eZog==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [75.172.116.31] (helo=[192.168.1.106]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from <asmusf@ix.netcom.com>) id 1jXGzb-000DeX-9F for i18ndir@ietf.org; Sat, 09 May 2020 00:21:39 -0400
To: i18ndir@ietf.org
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>
From: Asmus Freytag <asmusf@ix.netcom.com>
Message-ID: <780697f5-6d67-8a55-8120-a9c3b99f5cfd@ix.netcom.com>
Date: Fri, 08 May 2020 21:21:38 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <6F916805FF734CB450A3C724@PSB>
Content-Type: multipart/alternative; boundary="------------B7818121A051D5FE02F45165"
Content-Language: en-US
X-ELNK-Trace: 464f085de979d7246f36dc87813833b26976a2cdabd2db7ad54899d183daa1264484e7995359847c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 75.172.116.31
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/kZxCpdWplFwMUcdIEuYHVyxbHhg>
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 04:21:45 -0000
On 5/8/2020 9:01 PM, John C Klensin wrote: > 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" > <linuxwolf+ietf@outer-planes.net> 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). There's no reason for Unicode to deprecate UTF-32. Nobody really advocates it as an encoding form for transmission, but Unicode's definition of UTFs are not file formats. That's an essential misunderstanding. Anytime a per-character API accepts or returns 32-bit value that cover the entire code space, that format is effectively UTF-32. Deprecating this would force all those APIs to work on strings - not necessarily an improvement. Whether it's advisable to have an internal string format that's UTF-32 (rather than the more widely implemented UTF-16) is something that Unicode correctly is agnostic about. It's not Unicode, but things like W3C and IETF standards that are supposed to define transmission / file formats. The Unicode-defined range of UTFs just represents the building blocks. > 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. That's independent of the definition of a programming language. How you implement such a language on top of a "system" that works natively in UTF-32 is a matter for the implementer of that programming language. Javascript has all the rights to define whether UTF-32 is or is not an acceptable source code format (and to deprecate it for that purpose). > > 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. > If that understanding is correct, I agree with the conclusion. > >> 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. A move to the 21st century would imply making UTF-8 the default (in the absence of another declaration). If that can't be done because of pervasive legacy, then that needs to be stated and motivated. If a BOM is present and disagrees with the declaration, that should be an error condition. Hopefully, there isn't pervasive legacy to the contrary. It looks like in source code a proper BOM is always treated as whitspace and ignored, if so, that could be mentioned as a reason why it's not necessary to actively skip it. Another thing: in our discussion we mentioned the need to take the description of the charset handling out of the security consideration section. I don't see that mentioned. > > 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. >
- [I18ndir] I18ndir early review of draft-ietf-disp… John Levine via Datatracker
- Re: [I18ndir] I18ndir early review of draft-ietf-… Barry Leiba
- Re: [I18ndir] I18ndir early review of draft-ietf-… Myles Borins
- Re: [I18ndir] I18ndir early review of draft-ietf-… John R Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… Matthew A. Miller
- Re: [I18ndir] I18ndir early review of draft-ietf-… Asmus Freytag
- Re: [I18ndir] I18ndir early review of draft-ietf-… John C Klensin
- Re: [I18ndir] I18ndir early review of draft-ietf-… Patrik Fältström
- Re: [I18ndir] I18ndir early review of draft-ietf-… Martin J. Dürst
- Re: [I18ndir] I18ndir early review of draft-ietf-… John R Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… John R Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… John R Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… John C Klensin
- Re: [I18ndir] I18ndir early review of draft-ietf-… John C Klensin
- Re: [I18ndir] I18ndir early review of draft-ietf-… John C Klensin
- Re: [I18ndir] I18ndir early review of draft-ietf-… Barry Leiba
- Re: [I18ndir] I18ndir early review of draft-ietf-… John R Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… John C Klensin
- Re: [I18ndir] I18ndir early review of draft-ietf-… Asmus Freytag
- Re: [I18ndir] I18ndir early review of draft-ietf-… John Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… Patrik Fältström
- Re: [I18ndir] I18ndir early review of draft-ietf-… Asmus Freytag
- Re: [I18ndir] I18ndir early review of draft-ietf-… Mathias Bynens
- Re: [I18ndir] I18ndir early review of draft-ietf-… John R Levine
- Re: [I18ndir] I18ndir early review of draft-ietf-… John C Klensin
- Re: [I18ndir] I18ndir early review of draft-ietf-… Bradley Farias
- Re: [I18ndir] I18ndir early review of draft-ietf-… Barry Leiba