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

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

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.

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