Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
John C Klensin <john-ietf@jck.com> Mon, 11 May 2020 19:16 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 A64B03A0C5A; Mon, 11 May 2020 12:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 Vy9IBytOMc9x; Mon, 11 May 2020 12:16:36 -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 414F13A0C55; Mon, 11 May 2020 12:16:31 -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 1jYDuc-000HBH-GH; Mon, 11 May 2020 15:16:26 -0400
Date: Mon, 11 May 2020 15:16:18 -0400
From: John C Klensin <john-ietf@jck.com>
To: John R Levine <johnl@taugh.com>, Mathias Bynens <mths@google.com>
cc: DISPATCH WG <dispatch@ietf.org>, draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org
Message-ID: <841F372D6CFE1C52B07D0A25@PSB>
In-Reply-To: <alpine.OSX.2.22.407.2005111250001.4953@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> <alpine.OSX.2.22.407.2005081926580.81728@ary.qy> <C6B94276-EB9F-4A5B-9E1B-0DE170A05EBC@frobbit.se> <alpine.OSX.2.22.407.2005091233350.84818@ary.qy> <CADizRgbDAYBEarwSippGrL3VYzM=n4aH0OSWMWvRUFTaGVmvVg@mail.gmail.com> <alpine.OSX.2.22.407.2005111250001.4953@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/H735WdzITNMpEY3BE42eWsJuBU8>
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: Mon, 11 May 2020 19:16:39 -0000
--On Monday, May 11, 2020 12:55 -0400 John R Levine <johnl@taugh.com> wrote: >> At this point, I'm afraid the ship has sailed. Introducing >> yet another MIME type *now* is unlikely to gain adoption in >> the HTML Standard, browsers, or on the web (because it >> wouldn't be backwards compatible). Let's not publish >> specs that intentionally conflict with both the HTML Standard >> and web reality. > > It actually would be backward compatible because of the advice > to use Accept media types to tell when to send which media > type, but if browsers aren't going to do it, I guess we put a > warning in the security section and give up. Well, just a minute. Despite approval by DISPATCH for further discussion and processing, this is basically an individual submission, not a draft developed by a WG. With the understanding that what I'm about to say is not I18n-specific and therefore should perhaps go on the agenda of the next DISPATCH meeting or wait for IETF Last Call, the IETF has, as Patrik has pointed out, both a collection of standards-track and BCP specifications in these areas and experience with what happens when other approaches (like reliance on name suffixes) are used instead. Recommending something else is not just a matter of Security Considerations and, fwiw, I note that at least one document has been stuck after IETF Last Call completed in September because the IESG had DISCUSS-level concerns about telling implementers what they should do if they chose to not conform to the IETF's normative recommendations. If this is really just a description of what browser vendors are doing or will do now and in the future, then we have a long history of publishing "for the information of the community, this is what some vendor or cluster of vendors are doing" descriptive Informational documents. They are not standards track, they do not use normative language (2119/8174 terminology included), they just describe what is being done and are quite explicit about that. So, if the decision criteria for what belongs in this I-D is "whatever the browser vendors are going to do whether the IETF thinks it is a good idea or not", then let's see it recast as a "what is being done in practice" description, with the normative language removed or transformed into "if you want to do what the vendors are doing, then this is what you need to do" (or even "should" do - noting lower case). If that means updating the registration for text/javascript (which, I note, is in the registry at https://www.iana.org/assignments/media-types/media-types.xhtml#text as "OBSOLETED in favor of application/javascript" -- exactly the opposite of which this I-D proposes) and application/javascript to treat them as vendor registrations (applying the exception for non-faceted names allowed by Appendix A of RFC 6838) then so be it... because that is, apparently, the truth of the matter. Sorry, but it seems to me that this document is trying to have it both (or all three) ways: to be a normative document without meeting the higher bar the IETF usually applies for standards track documents, to be a vendor specification without making that clear in the text (and noting that vendor specifications are still expected to have accurate Security Considerations sections), and to make requirements that are at variances with significant community experience about bad results when similar things have been done in only slightly different areas and still expect IETF consensus for the document. I don't think that works. YMMD. And... >> It's not entirely harmless. The following JS program >> behaves differently if it's preceded by a BOM: >> >> # !/usr/bin/env bash > > I really don't want to know when self-running shell scripts > became part of Ecmascript. Presumably, by an extension of the comments that caused the rant above, whatever "part of ECMAscript" means, they are a consideration because some or all browser vendors decided to treat them as if they were. john
- [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