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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 05 Jan 2022 20:53:32 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-dispatch-javascript-mjs-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The MUST in Section 2 is kind of peculiar.  Is it a reminder to implementers
today that they need to keep an eye out for possible updates in the future?  If
so, I think it's unnecessary.  If something else is meant, then I'm quite
confused.

In several of the subsections of Section 6.2, there are some errant punctuation
characters hanging around.

This document is registering media subtypes starting with "x-" even though BCP
178 says not to do that.  If the working group intends to do this for
historical reasons, I suggest including a sentence explaining that this is
being done intentionally, perhaps under Appendix A of RFC 6838.  (See, for
example, Section 6 of RFC 8894.)

---

From: Mathias Bynens <[email-masked]>
Date: Fri, 7 Jan 2022 10:20:39 +0100

Thanks for the review. Replies inline:

> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

It captures the fact that ECMAScript is a living standard that keeps
evolving, with new versions being published annually. It is possible that a
new script goal (other than "classic script" and "module") is added in the
future, and at that point, we might need a new RFC with updated media type
registrations.

In several of the subsections of Section 6.2, there are some errant
> punctuation

Thanks. I believe we cleaned up at least some of those in
https://github.com/linuxwolf/bmeck-ids/pull/62. Let me know if there’s any
others.

> example, Section 6 of RFC 8894.)

This is not new content / a new registration, but rather content inherited
from RFC4329, which our draft iaims to supersede. The draft already
explains that it updates RFC4329. Is that sufficient?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 8 Jan 2022 17:37:23 -0800

> future, and at that point, we might need a new RFC with updated media type

I think what you've written here is much more clear language than what's in
the document presently.

When I see a MUST or SHOULD, I'm expecting to see requirements related to
interoperability or security of the protocol itself, or operational
configuration of a component that implements it.  Thus, I don't think this
use of MUST is appropriate.

> explains that it updates RFC4329. Is that sufficient?

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.

-MSK

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jan 2022 21:00:31 -0500

--On Saturday, January 8, 2022 17:37 -0800 "Murray S. Kucherawy"
<[email-masked]> wrote:

>>> 178 says not to do that.  If the working group intends to do
>>> this for historical reasons, I suggest including a sentence
>>> explaining that this is being done intentionally, perhaps
>>> under Appendix A of RFC 6838.  (See, for example, Section 6
>>> of RFC 8894.)
>>> 
>> 
>> This is not new content / a new registration, but rather
>> content inherited from RFC4329, which our draft iaims to
>> supersede. The draft already explains that it updates
>> RFC4329. Is that sufficient?
>> 
> 
> 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.

Mathias,

Let me say that a little more strongly.  BCP 178, which probably
should have been written a decade earlier (in retrospect, we
probably should have prohibited them in RFC 4288/BCP 13),
reflects many years of experience, pain, and suffering.  If you
want to make a new registration now that uses one of those "X-"
prefixes, you need to explain why they should be an exception --
not only in terms of why BCP 178 is not applicable (as Murray
suggests) but even why it is not possible to change the media
types now and going forward to ones without the "X-".

Murray, consider this early warning of an appeal is this
document is approved without that text appearing in some
reasonable form.

best,
  john

---

From: Mathias Bynens <[email-masked]>
Date: Mon, 10 Jan 2022 14:20:27 +0100

On Sun, Jan 9, 2022 at 2:37 AM Murray S. Kucherawy <[email-masked]>
wrote:

> I think what you've written here is much more clear language than what's
> in the document presently.
>
>> This is not new content / a new registration, but rather content
>> inherited from RFC4329, which our draft iaims to supersede. The draft
>> already explains that it updates RFC4329. Is that sufficient?
>>
>

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Jan 2022 19:35:44 -0800

On Mon, Jan 10, 2022 at 5:20 AM Mathias Bynens <[email-masked]> wrote:

> 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.
>

I think that's an improvement.  I'd be curious to hear what John thinks.

If as you commented in github you don't like the word "grandfathered", you
could instead work the word "legacy" into the prose and still say the same
thing.

Any further comment on the MUST issue I raised?

-MSK

---

From: Mathias Bynens <[email-masked]>
Date: Tue, 11 Jan 2022 08:13:19 +0100

> Any further comment on the MUST issue I raised?

This refers to the following paragraph:

```
This document may be updated to take other content into account. Updates of
this document may introduce new optional parameters; implementations MUST
consider the impact of such an update.
```

This MUST is not new; this text is inherited from RFC4329 (section 3). For
our draft, we’ve been hesitant to make changes other than the ones that
were needed to match implementation reality & ensure compat.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Jan 2022 09:02:36 -0800

On Mon, Jan 10, 2022 at 11:13 PM Mathias Bynens <[email-masked]> wrote:

> This document may be updated to take other content into account. Updates
> of this document may introduce new optional parameters; implementations
> MUST consider the impact of such an update.
> ```
>

"The sins of the father" and all that.  :-)

I do appreciate the desire for minimal change from an already-approved
document.  I also think that propagating text that was improper to begin
with should be given due consideration.

As she's the responsible AD here, at this point I'll defer to Francesca on
the MUST question.

-MSK

---

From: [email-masked]
Date: Tue, 11 Jan 2022 07:53:18 -0800 (PST)

In regards to all these obsolete registrations and x- registrtions
in particular...

> 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.

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?

				Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 Jan 2022 23:48:46 -0500

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
[email-masked] wrote:

> In regards to all these obsolete registrations and x-
> registrtions in particular...
> 
>> > does not at present contain any of the "x-" media types
>> > this document is registering. I believe that makes them new

>> 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.

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).   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 don't have the energy to go back and study RFC 4329 carefully
but a quick review of parts of it suggests that many of these
problems are the legacy of originally using application/* types,
which are far more flexible about these things.  That implies
that a switch (back) from application/* to text/javascript
without considerable additional explanation leaves a few too
many document deficiencies and loose ends.  

Coming back to Murray's MUST question, this document and its
authors should not be able to say, in essence, that 4239 is so
broken that it is necessary to un-deprecate things that it
claimed were obsolete and turn them into requirements and then
turn around and say that things that are incorrectly represented
as  requirements should be preserved just because this document
does not change them.  

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).

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.
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

---

From: Mathias Bynens <[email-masked]>
Date: Wed, 12 Jan 2022 08:36:32 +0100

Francesca, could you please advise on how to proceed w.r.t. the MUST
question? Thank you.

On Tue, Jan 11, 2022 at 6:02 PM Murray S. Kucherawy <[email-masked]>
wrote:

>> This MUST is not new; this text is inherited from RFC4329 (section 3).
>> For our draft, we’ve been hesitant to make changes other than the ones that

---

From: Mathias Bynens <[email-masked]>
Date: Wed, 12 Jan 2022 08:41:45 +0100

On Tue, Jan 11, 2022 at 11:32 PM Ned Freed <[email-masked]> wrote:

> they

Thanks for the pointer to RFC 6838 section 4.2.9, and for suggesting such
an elegant solution. I’ve prepared a patch at
https://github.com/linuxwolf/bmeck-ids/pull/66 that reduces the draft down
to just two registrations, each with a set of aliases:

   - Under “Common JavaScript Media Types”: text/javascript and its aliases
   with file extensions .js and .mjs
   - Under “Historic JavaScript Media Types”: text/ecmascript and its
   aliases with file extensions .es and .mjs

To make it just one registration and remove section 6.2 entirely, we’d need
to list something like “Deprecated file extension(s): .es” alongside “File
extension(s)”, but I don’t see anything in RFC 6838 that would allow this,
and then we’d also be incorrectly listing .es as a legacy extension for the
common types which never had that extension in their registration. Given
that, I think the current patch is as good as it can get. Please take a
look.

---

From: Mathias Bynens <[email-masked]>
Date: Wed, 12 Jan 2022 09:38:24 +0100

> unlikely to be the case, only a preference for the text/ form

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

> 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
> 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.

> 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.

> 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.

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Jan 2022 09:43:35 -0500

Mathias

Top post -- I need to run to a (f2f) meeting and might have more
to say about some of your comments below later, but I think it
is important for me to stress a few things right now.

First, I see this document getting as far as IESG review as a
system failure, not an author failure.  I hope we can dissect
that failure at some point, not to cast blame but to figure out
how we can do better, with other documents, in the future.  And
my note erred in attributing the problem to AD sponsorship
rather than to DISPATCH but, again, system failure.

Second, if I were to make a one-phrase summary of all of the
substantive comments starting from Murray's "No Objection" and
certainly including my long analyses and Ned's note about how
Media Type registrations are handled, it would be "need to
explain and justify this better in the document" and not "this
is necessarily wrong".  Again, all of those issues should have
been caught much earlier, but, for better or worse, that is how
the IETF system works.   And, as one substantive comment on your
note the IETF's criteria for review and approval go far beyond
"well, all the browsers do this".   I think there are good
reasons for that.  You may reasonably disagree and I know WHATWG
does, but that is a far broader issue than this particular
document.

   best,
     john

--On Wednesday, January 12, 2022 09:38 +0100 Mathias Bynens
<[email-masked]> 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".
>> 
>> >> > 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.
>> 
>> > rules regarding obsolete type names, unfaceted types, and
>> > type names beginning with "X-".
>> > 
>> > 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.
>> 
>> > 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.
>> 
>> > bunch of similar things, you need to explain why you're
>> > doing things this way, and more importantly, why they
>> > warrant having different names.
>> > 
>> > 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?
>> 
>> 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.
>> 
>> There are then a few other problems which I didn't catch
>> until I studied the document and the registry over the
>> weekend.
>> 
>> 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:
> 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.
> 
> 
> 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.
> 
> 
> updates the requirements for implementations using those media
> types defined in [RFC4329] based on current existing practices
> 
> 
> 
>> 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).
>> 
>>         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.'
>> 
>> parameter to be optional" strongly implies that there should
>> be an explanation in the relevant document (in retrospect, we
> 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.
>> the I-D says that the value of the charset parameter "SHOULD
>> be a registered charset" while the second paragraph of Section
> 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.
> 
>> 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.
> 
>> 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.
>> 
>> 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-introd
> uce-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.
> 
> 
>> 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
>> 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.
>> 
>> 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.
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>>