Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
Bradley Farias <bradley.meck@gmail.com> Mon, 11 May 2020 22:21 UTC
Return-Path: <bradley.meck@gmail.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 98F273A0D67; Mon, 11 May 2020 15:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.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 5hrAeO6dZ83N; Mon, 11 May 2020 15:21:40 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C963A0D66; Mon, 11 May 2020 15:21:40 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id d207so4978172wmd.0; Mon, 11 May 2020 15:21:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aFD10kEu4pWn23/diGlU8+6Fz90g+oMSK/DOmun9lPA=; b=AHKYnpD/o+IeVqhviE6N6Y7uZUSlYttANTESKkl9gHQRMIr5O6EJulptUaq0+n3Fxc 4vMtv5sMHysbJV+WayyWKk/YLVNHYiQfyGAgjVlX0HPZ4NCf1RHw217Awrrqdh+J8P7b y3fyawF2wDneY1SedJIwqa7omzzS6C/0lOfhs1Y2rdMWDO9eIwy42a2+XesXJicU3n5g M9BA8NNYHAmuOLeeW9JaVhhFmV5vqpUzh0P+Y9GnbUo9GEi7OvPoSKSTzwfihHt/JBp6 SM3E1jmdmhe6Swj23oLCBAVc69iXF6MN4so8CoAVv96QUXO0CmP9cn1T5fYuRIwy7hXz JMKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aFD10kEu4pWn23/diGlU8+6Fz90g+oMSK/DOmun9lPA=; b=So/pPfYJBWNpPQwPmMsON85sYACxyH9fLxC5G/dZfP9LGV4bQ71Du89SMtGePmbCJJ tc58tPkvhF8Rmr3QI9sF+nzLbeteWEjQBPn0LEJVIwpqvwYjFyyPX/2D6Uozr3JYjnxf atZKbyAw9nyqN1SeyhzKKjDuXqlwRX26PMZsQPGYMTvyPFL44TY6KFMgD3iEtVfqccI2 hiXYXTissrhDTbHI8t5FMdCE/38lNP2c4/I+5CC00nJqPYJAvmZzaevtEZ4/nXq4z2nS gDco8WBG+jzTS0VWIHC1aYMnwNJrpUtrSdRSLvnQIR2zrfhx2ogKTnQhVEC+58Y5dEFm rofw==
X-Gm-Message-State: AGi0PuZ7ulsifv6AkudWhvYKviVPerWEdHYzZ8vM1smk5c+yTFPBB9S3 W5LSSt9/K+Hp4ViqQHv2+UL5ptgKGhUPdZTN7F8=
X-Google-Smtp-Source: APiQypKB44pikM+SQAgBPJzql32vW0ed1MpztJ8SRR/zXxW+ucGPoZDvy2xwKLsxOdpb7Oe5Wim4wmwHUOa1Iszu+H8=
X-Received: by 2002:a1c:5419:: with SMTP id i25mr30201816wmb.156.1589235698275; Mon, 11 May 2020 15:21:38 -0700 (PDT)
MIME-Version: 1.0
References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <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> <841F372D6CFE1C52B07D0A25@PSB>
In-Reply-To: <841F372D6CFE1C52B07D0A25@PSB>
From: Bradley Farias <bradley.meck@gmail.com>
Date: Mon, 11 May 2020 17:21:27 -0500
Message-ID: <CANnEKUY0aN=hoQg0BVoV3i5op5MJQJpH2GU6j7PYVp-4zv0mxQ@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: John R Levine <johnl@taugh.com>, Mathias Bynens <mths@google.com>, DISPATCH WG <dispatch@ietf.org>, draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org
Content-Type: multipart/alternative; boundary="00000000000042991305a566c53a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/Rqg6RUMPuoyO2ddNjfv7z8_xCHY>
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 22:21:44 -0000
Forgive me, but the tone appears to be rather harsh against people who have spent quite a few years waiting on this document to even get to a visibility that we can discuss things. Per Adam Roach's recommendation we did not go through a WG when I made this document years ago. The past few emails seem rather derisive against such decisions, but I am still new to IETF workings and would love help through the process; there seems to be issues that cause me some personal confusion on the intent of a review. Is there a way we can follow or be aided such that we can reach the "higher bar" that we are unaware we were missing here such that we can go for a normative change? I'm unclear but it seems like there is a desire to design some solution for concerns about ECMA262 in host environments but I'm unclear on this being the venue to do so and would be appreciative of guidance on how to proceed. Additionally, I have concerns with shipping things like MIMEs that are not supported in any environment and are not discussed in the host venues they intend to be used in and without any buy in from a host. This document is trying to be normative to match the environment scenarios of not just browsers but other environments that run ECMAScript such as server side environments like Node.js are using text/javascript as the preferred non-obsoleted form in order to coalesce around a standard that matches the browser recommendations. The reversal of the application/javascript as the preferred MIME was intentionally discussed in those environments. I'm unclear on how creation of a new MIME would help here given we cannot remove support for the status quo; creation of a new MIME seems like it would require implementer interest to be a viable replacement. Per things like hash bang comments and concerns about the language being different from when older RFCs existed; I would view this document as being a way to catch up to at least the status quo; creation of unrelated evolution of standards paths that are not intended to match the status quo likely won't be useful without other standards groups buy in. In the future I'm sure people with such varied interests in the evolution of ECMAScript certainly could participate in the evolution of the language if they want to, but that was not the intent of this document. It seems like an additional RFC might be desirable for other issues we are seeing brought up here? Once again, I'm less familiar with IETF process and am unclear if all possible design decisions need to be made in this document. On Mon, May 11, 2020 at 2:16 PM John C Klensin <john-ietf@jck.com> wrote: > > > --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