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

[John C Klensin <[e-mail]>]

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
<[e-mail]> wrote:

> On Wed, Jan 12, 2022 at 5:49 AM John C Klensin
> <[e-mail]> 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
>> [e-mail] 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#scriptin
> gLanguages
> 
> 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-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.
> 
> 
>> 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
>> 
>> 
>> 
>> 
>> 
>>