Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

Mathias Bynens <mths@google.com> Wed, 12 January 2022 08:38 UTC

Return-Path: <mathiasb@google.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5533A0BD9 for <dispatch@ietfa.amsl.com>; Wed, 12 Jan 2022 00:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.099
X-Spam-Level:
X-Spam-Status: No, score=-17.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 R9GcITjYkBIw for <dispatch@ietfa.amsl.com>; Wed, 12 Jan 2022 00:38:37 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 D22C53A0BE0 for <dispatch@ietf.org>; Wed, 12 Jan 2022 00:38:37 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id w7so3044837plp.13 for <dispatch@ietf.org>; Wed, 12 Jan 2022 00:38:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y2nWT/iPkg2PGGVvm8SCOSvtxSdhwCJScRTTxs4frDE=; b=KSQSd8rPP1ZO0zCoBIXS4NWOmVMx7FLfD5cxRd3/TBpEZl9F/tpC29kQKVJQTWe3yu 0tpkW0IrHXk/7Zocc4uu3CmAY+enWehwoq6lNu0LSw4N3bBp3dsEiTnxdhT/Mnb6ig70 3hvFMs2yIgpgfko4NcN5igVY13RXy1/Fakt5osvHmr6AVJhq60nohInHWftq5kBForP7 kyQq6C0u4S/ea1xlwAJK/HYIH/YAJkHGzDoD3+bUUc6iGiSZuhloDlb6CyHyjgkggxiV 5eVg1IlYAh3f4PFxUN+izmENcaIUBnuveDJrodxYjqqDX6vHuNTAX9YK0JBIRcu/sZjH SDvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y2nWT/iPkg2PGGVvm8SCOSvtxSdhwCJScRTTxs4frDE=; b=JOH8JCz+7gXpoF9r+E5+YwUEe51qM0Ms4srnyxf+4ppMI3PxGzsHAQzzLFMCc6IVcG 4RO6KHcJHrL83+ClXHTiwAGuat/rZgVHJTAFny8WmY4/mHIqmnkuPWBrt/gee3ZLrk/q uHs36SQMuhZFfvWIFMNAZGbqGrundo7uN14B/HKHwjvf/4hewAqO6MshReCw4gWpq7p/ TO92qxRqZMYNbkOxcgWvCqe+JJNPRy1Ze+PyNbp41/Cv5jiKpJcIq8lGxdL84gVcEVvX b+05bPShIKczPeH9eIo+91ONgROABg6aPCVTKFvjrXJL2ykHXmDUD0kcBWmg4KL1z0vh /IcQ==
X-Gm-Message-State: AOAM531MjbpydeUKVtoIgRpz+I40xZwNWkrssQk+5t72GT5FLZT2v9AB g8tY2PFVWaW82eTS3Op/Yzo1FMQ1M1Yyx1Z36eeZxg==
X-Google-Smtp-Source: ABdhPJyr1miMozQlnvAZNhNWCkoHD+kEr4MExkhgf7fpy4mLU2hNi/FUJqmo/zTwU8zLjMH4II/P0di7/ta3RZfn11o=
X-Received: by 2002:a17:902:d484:b0:14a:59cc:308e with SMTP id c4-20020a170902d48400b0014a59cc308emr5468546plg.137.1641976715893; Wed, 12 Jan 2022 00:38:35 -0800 (PST)
MIME-Version: 1.0
References: <164144481153.28700.9521326921012553920@ietfa.amsl.com> <CAL0qLwYgc13KXriZNPcB-XqC7i_ORDw01C5h2x93U22R3VCnSg@mail.gmail.com> <01S8F3X371ZE00D1OX@mauve.mrochek.com> <DD746E43498BFF74BAF61C97@PSB>
In-Reply-To: <DD746E43498BFF74BAF61C97@PSB>
From: Mathias Bynens <mths@google.com>
Date: Wed, 12 Jan 2022 09:38:24 +0100
Message-ID: <CADizRgaSUs6KR3u4g=bbu=sR3A0rooNA572Nzu8EqqgvZryHDQ@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: ned+dispatch@mrochek.com, Mathias Bynens <mths=40google.com@dmarc.ietf.org>, Ben Campbell <ben@nostrum.com>, DISPATCH WG <dispatch@ietf.org>, dispatch chairs <dispatch-chairs@ietf.org>, draft-ietf-dispatch-javascript-mjs@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1ac8e05d55e7e6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/IKqJV8ZfICQJaO9FeFEOQop6_BM>
Subject: Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jan 2022 08:38:44 -0000

On Wed, Jan 12, 2022 at 5:49 AM John C Klensin <john-ietf@jck.com> wrote:

> Warning: this note is long.  Those who are not interested in the
> details can safely skip to the least three paragraphs, beginning
> with the one that starts "bottom line".
>
> --On Tuesday, January 11, 2022 07:53 -0800
> ned+dispatch@mrochek.com wrote:
>
> > In regards to all these obsolete registrations and x-
> > registrtions in particular...
> >
> >> > What I've observed is that the current media type registry
> >> > does not at present contain any of the "x-" media types
> >> > this document is registering. I believe that makes them new
> >> > registrations, and so I suggest that there should be text
> >> > explaining why BCP 178 doesn't apply here.
>
> >> Thank you. Please take a look at this patch:
> >> https://github.com/linuxwolf/bmeck-ids/pull/65/files
> >
> >> For context, these are historical legacy types that are
> >> supported in practice:
> >> https://mathiasbynens.be/demo/javascript-mime-type Although
> >> they are OBSOLETED, it's important that the document
> >> specifies them because they are required for Web
> >> compatibility.
> >
> > There seems to be considerable misunderstanding about the
> > rules regarding obsolete type names, unfaceted types, and type
> > names beginning with "X-".
> >
> > First, RFC 6838 eliminated the special status of type names
> > beginning with "X-". So nothing prevents you from registering
> > type names beginning with "X-" as long as the registration is
> > in the standards tree. Appendix A of RFC 6838 only applies if
> > the type is being registered in, say, the vendor tree, which
> > AFAICT is not the case here.
> >
> > Of course the fact that you can register names beginning with
> > "X-" doesn't mean you should. So if you're doing this, a note
> > explaining why ths makes sense would be a good idea.
>
> Let me go a half-step further than Ned.  Given the language in
> RFC 6648/ BCP 178, not explaining why it makes sense would
> create a situation in which an Informational specification in
> the IETF Stream was violating an IETF BCP.  Without a clear
> explanation in the document, one which I believe should have
> been identified in the Last Call, that would create an
> intolerable situation of the IETF ignoring its one "best
> practice" specifications.
>
> > However, the better question is why are all these obsolete
> > type names being registered separately. RFC 6838 section 4.2.9
> > explains the proper way to handle old names for the same media
> > type, and the registration form now contains a field for
> > listing all of these names.
>
> > If you're going to register a bunch of separate types for a
> > bunch of similar things, you need to explain why you're doing
> > things this way, and more importantly, why they warrant having
> > different names.
> >
> > And since in this case all of these additional registrations
> > are marked as obsolete, I fail to see why they aren't being
> > handle as deprecated aliases. Or, to pur this another way, why
> > not simply list all 15 (!) aliases in the registration for
> > text/javascript and get rid of section 6.2 entirely?
>
> Now, as I see it, that is an introduction to several problems.
> First, because ECMA-262 has evolved, some of those types may not
> actually be aliases but pointers to obsolete versions of the
> specifications (see below).  Of course, if that is the case, the
> document should say so.  That relationship is one of the many
> ways in which it is impossible for the I-D to be the claimed
> simple update to RFC 4329 (part of the basis for its progressing
> this far) without _introducing_ errors that 4329 did not have.
>
> Looking for a moment only at the IANA registry, Ned is the lead
> Media type reviewer/ Designated Expert for the registry and
> under RFC 6838, not just for the Vendor and Personal Trees but
> for "requests made by other recognized standards organizations".
> If we have seen a request _From ECMA_, I have not been able to
> find where that is documented.  I would have expected to see it
> in both the Last Call announcement and in the draft IESG
> document action announcement as well as the document itself, and
> it appears in none of those places.   Putting those
> documentation issues aside for the moment, if this was a request
> from ECMA and Ned does not believe the registration request or
> documentation meets the requirements, unless Alexey or Murray
> can convince him otherwise, the document is essentially, as the
> saying goes, dead in the water: while we give great deference to
> requests from other recognized standards organizations, we have
> no rule about overriding the decision of a Designated Expert,
> even by an IETF Stream Informational RFC.  Nor do we have rules
> that say that, when there are multiple Designed Experts, two of
> them can outvote the other one.  And IANA takes direction from
> the Designated Experts.
>
> Now let's assume there was no request from ECMA and that this
> document represents the request and opinion of the authors.
> There are then a few other problems which I didn't catch until I
> studied the document and the registry over the weekend.
>
> First, these registrations started out with the preferred one
> (in the registry) as application/javascript and
> application//ecmascript.  RFC 4329 establishes that preference,
> identifying text/javascript and text/ecmascript as obsolete
> (which is how they are defined in the registry) and asserted
> that 'Use of the "text" top-level type for this kind of content
> is known to be problematic.' (see its Section 3, a section that
> appears to have been dropped from the I-D without comment --
> not, at least IMO, a "fairly simple update").    The current I-D
> apparently proposes to change that, identifying text/javascript
> as the preferred form and marking application/javascript as
> obsolete. But it lacks, at least IMO, a clear explanation as to
> why that change, with the preference reversed a second time, is
> being made.  That also raises the obvious question of whether,
> in another half-dozen years, the decision will not be reversed
> again.  I can find no explanation if the I-D as to why that is
> unlikely to be the case, only a preference for the text/ form
> today.
>

text/javascript is already the de facto preferred MIME type for JavaScript.
Our I-D aims to update RFC4329 to align with this reality. The HTML
Standard, which all browser implementations follow, is explicit about this:
https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages

Servers should use text/javascript for JavaScript resources. Servers should
not use other JavaScript MIME types for JavaScript resources, and must not
use non-JavaScript MIME types.


Our I-D states, in its abstract:

This document obsoletes RFC4329, "Scripting Media Types", replacing the
previous registrations for "text/javascript" and "application/javascript"
with information and requirements aligned with implementation experiences.


…and in its Introduction section:

updates the requirements for implementations using those media types
defined in [RFC4329] based on current existing practices



Equally important, RFC 6838, supplemented by RFC 6657, imposes
> far fewer restrictions on applications/* types than it does on
> text/* types.  For the latter, the discussion in Section 4 of
> the I-D very strongly implies that these media types are not
> "Text Media Types" as defined in Section 4.2.1 of RFC 6838 and
> should therefore be application/* types.   It may be that the
> text in the I-D is just confusing (if Ned is convinced these are
> appropriate text/* types, I defer to his judgment), but that is
> more evidence that this document is not ready for prime time...
> probably to the extent that it never should have been put into
> Last Call.  Or, if that is not the problem, this specification
> does not get to violate RFC 6838's provisions without either a
> clear explanation or updating that document (which would
> presumably require a clear explanation).
>
> Assuming text/javascript is appropriate, this I-D also
> violates Section 4.2.1 of RFC 6838 in another way, where the
> fourth paragraph of that section starts by saying
>
>         'If a "charset" parameter is specified, it SHOULD be a
>         required parameter, eliminating the options of
>         specifying a default value.  If there is a strong reason
>         for the parameter to be optional despite this advice,
>         each subtype MAY specify its own default value, or
>         alternatively, it MAY specify that there is no default
>         value.'
>
> The subsequent text that talks about "strong reason for the
> parameter to be optional" strongly implies that there should be
> an explanation in the relevant document (in retrospect, we
> should have explicitly required that).  I don't see that
> explanation even attempted unless it is the text about the use
> of "charset" with one target and not with others (again,
> confusing at best).


See Section 4:

How implementations determine the character encoding scheme can be subject
to processing rules that are out of the scope of this document. For
example, transport protocols can require that a specific character encoding
scheme is to be assumed if the optional charset parameter is not specified,
or they can require that the charset parameter is used in certain cases.
Such requirements are not defined by this document.


How can we make this more clear?

   Equally or more important, Section 4.1 of
> the I-D says that the value of the charset parameter "SHOULD be
> a registered charset" while the second paragraph of Section
> 4.2.1 of 6838 says "MUST".  That is a clear violation of RFC
> 6838 and as noted above, this I-D does not get to violate or
> change BCP 13, at least without a very clear explanation that
> can be reviewed and evaluated by the IETF, not just waived off
> in passing as repeating the errors of RFC 4329.
>

I’d point to the same passage in section 4. This all depends on the host
environment. MUST does not seem appropriate since there are valid use cases
for omitting the charset parameter from the media type itself, e.g. when
the charset is already specified in HTML directly: <script charset=utf-8
src=foo.js></script>

As a meta-point, I will say that it is frustrating that, while making an
effort to update RFC 4329 to align it with a changed reality, we’re also
burdened with fixing any and all other mistakes made in that original RFC.
And it saddens me that until those unrelated mistakes are addressed, there
continues to be no official media type registration for JavaScript modules,
despite implementations supporting this since 2017 already. Meanwhile, the
JavaScript ecosystem continues to be blocked on module support.

That isn't all.  If the Mozilla piece cited by Mathias at
> https://mathiasbynens.be/demo/javascript-mime-type is relevant
> and the reason for registering these dead/ obsoleted documents
> is because they were in use somewhere, then I don't understand
> why the "FAIL" "javascript+FOO" media types are not on the list
> proposed for registration (or treatment as Ned suggests).
>

I think there’s a misunderstanding. There’s no “Mozilla piece” being cited
here; if you see the string "Mozilla" on that page, it's your browser’s
User-Agent string (
https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.3) being
reflected. This document is a test case attempting to load scripts with all
the JavaScript media types and deprecated aliases in the draft (all of
which PASS in all browsers), as well as some intentionally invalid ones
(e.g. text/fluffscript) that are expected to FAIL. Inspect the HTML source
code to see how it works.

In addition, the proposed registrations, including the one for
> text/javascript that is intended to be the one that survive as
> relevant, invite the user to go on a wild goose chase, sending
> them to look at the RFC that succeeded the I-D and then to ECMA
> 262 (without any section numbers or other hints) and back to the
> present document.  That is not, at least IMO, how the media type
> registry was intended to work, even if the goose is eventually
> captured.
>
> Even more important, but part of the same general problem, the
> "Interoperability considerations" subsection that is part of
> each of the registrations (and is new text that cannot be blamed
> on RFC 4329) appears to say something equivalent to "whatever
> this media type says it is, treat it as if the current version
> of 'text/javascript' as specified in ECMA-262 had been
> specified". If that is the intent, the text should say so _and_
> point to the specific section of ECMA-262 that requires strict
> backward compatibility in the present and all future versions.
>

I don’t think there is such a section, but it is the case that
https://tc39.es/ecma262/ is a “living standard” in practice, with browser
and other implementations updating their JavaScript feature set all the
time. Here’s the list of active proposals for new JavaScript features:
https://github.com/tc39/proposals#readme Browsers and other implementations
start shipping features once they reach “Stage 3”.

Resolving “implementation and ecosystem compatibility issues” is a
requirement for any new features to land in the ECMAScript spec:
https://tc39.es/process-document/#:~:text=implementation%20and%20ecosystem%20compatibility%20issues
There is no strict 100% back/forwards compatibility requirement, however,
and there have been rare cases where we’ve been able to correct
historical mistakes after determining that doing so didn’t “Break The Web”
/ break existing code. These cases are enumerated here:
https://tc39.es/ecma262/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions

The intention is really: “if this media type maps to JavaScript, then treat
it using whatever currently available JavaScript implementation you have”,
keeping in mind that the JS implementation is changing frequently, with new
features being added all the time. I’d welcome any suggestions of how we
could capture this more clearly in the I-D.


> The material in Section 2 of the I-D (with or without the
> strange MUST to which Murray objected) does not do that.  When I
> look at the current version of ECMA-262 itself, I find Appendix
> E ("Corrections and Clarifications in ECMAScript 2015 with
> Possible Compatibility Impact") and F ("Additions and Changes
> That Introduce Incompatibilities with Prior Editions").  They
> strongly imply that there are no such backward compatibility
> commitments.  Even a single incompatibility that would cause an
> application to fail or apply a different interpretation of media
> types tied to earlier versions would be a problem (this is in
> the category of things that caused the IAB to launch a study of
> compatibility among versions of a protocol).  We might deprecate
> a once-valid type because there is a newer type with a new
> definition.  But having the definition of a type change out from
> under it and thereby making an application that assumed the
> original definition non-conforming... well, it isn't something
> the IETF should do and, if Ecma International (not just the
> authors) thinks it is ok, we need to hear from them.
>
> That problem with media type stability extends to the RFC Style
> Guide.  References, especially normative references, are
> expected to be very stable.  But, while the reference identified
> as [ECMA-262] itself is very stable, referring to the 2021, 12th
> Edition, of that spec, the "Interoperability considerations"
> text does not actually reference that 2021 version.  What it
> references is, approximately, "whatever the ECMAScript
> specification is when you happen to read this".  Perhaps the
> authors and the RFC Editor could work out how to do that in a
> reference, but the I-D is referencing the 2021 version in some
> places and the current version in others, using the same anchor,
> and that has not been acceptable at any time in the last 51 1/2
> years.  In addition, that dual use of the reference anchor means
> that the statement in Appendix B, "Updated references to
> ECMA-262 to match the version at time of publication" is not
> quite accurate because it is also expected to match the version
> at time of reading.
>
>            ------
>
> Bottom line: In retrospect, this document never should have been
> put into Last Call.   The IESG's having done so is a symptom of
> one of the common problems with AD-sponsored documents,
> especially Informational ones, in today's IETF.  That problem is
> insufficient expert review of potential problems in interactions
> with other specs and, in this case, with existing IANA
> registries and the rules for them.  That lack of in-depth review
> is especially likely if something is presented as "just an
> update" or "just a replacement for an existing document",
> implying that there are no changes that have broad implications.
> Maybe it is something we should think about in terms of how
> DISPATCH works at well: perhaps a document like this should not
> be recommended for AD Sponsorship until it has been carefully
> reviewed by a team separate from the authors and with in-depth
> expertise in both the subject matter and the subtle issues with
> media types.  That is a review that this document received only
> in the last couple of weeks and it might easily have slipped
> through.  I have read the Shepherd's report and, given the
> assumptions it documents, it is probably completely correct.
> However, those assumptions include this "just" being an update
> to 4329 that does not introduce substantive changes other than
> those documented in Appendix B.  That does not turn out to have
> been the case, e.g., with the change of "the intended usage of
> the media type text/javascript from obsolete to common", which
> has broader implications; with the use of one of the references;
> and with other issues identified above.   Among the specific
> problems are that the change from a preferred application/* type
> to a text/* type is not a "simple update of RFC 4329" because it
> interacts with requirements of RFC 6838; the obsolete, then
> un-obsolete, then obsolete again actions (and their reverse)
> require more explanation than simply changing text; and, at
> least IMO, if 4329 messed up the IANA registries, this should
> not make them worse and, if it didn't, this I-D should not mess
> them up, whether intentionally or by being confusing beyond all
> acceptability.
>
> There is, in addition, clearly a more general problem for the
> IESG and IETF, which is whether replacing an old document that
> is known to have serious deficiencies with a new one that shares
> those deficiencies and doing so without even comments about them
> is a good idea.  I note that no errata were filed against those
> deficiencies in 4239 but, given our treatment of errata
> (especially of the "hold for document update species), that
> should not make any difference, especially given that at least
> some of them were identified in review in DISPATCH.  It is my
> personal view that, if we obsolete a previous document, we take
> on the responsibility, ideally, to fix its errors and
> inappropriate or incomprehensible text even if we do not fix
> other glitches.  Even if we don't get to that ideal, we should
> at least insert a section or appendix that identifies the known
> problems that are being inherited.
>
> However, even if the inherited problems are ignored, the media
> type definition ones noted by Ned and the need for explanations
> that several of us have identified (including those in the notes
> above) will result in very significant changes to this document,
> changes significant enough that the IESG should return it to
> DISPATCH and initiate another Last Call when it is actually
> ready.
>
>     john
>
>
>
>
>
>