Re: [media-types] [dispatch] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May

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

--On Wednesday, May 19, 2021 15:10 -0400 John R Levine
<[e-mail]> wrote:

>> While I mostly agree -- Martin is right, but it is not clear
>> whether making this correct would cause more harm by creating
>> confusion than it would be worth -- there is a third (and more
>> drastic) way to look at this.  Content-sniffing and
>> heuristics, rather than properly marking up text and strict
>> observance of media types, ultimately just lead to other
>> problems down the line. ...
> 
> We went through all these arguments a couple of months ago and
> the Javscript crowd made it crystal clear that the current
> awful behavior is built into vast amounts of software,
> starting with all of the web browsers on your phone and your
> computers, and it's not going to change.

Understood and no disagreement.  Nor am I suggesting that the
IETF should say "change it anyway" or anything equally unlikely
to result in changed behavior.

> While I am no happier than you are that we got to this point,
> I don't think that a pissing contest would do anyone any good.
> I suppose we could add a note saying something like the media
> sniffing is a concession to widespread existing practice and
> isn't intended to be a precedent for any new media types.

Nor was I suggesting a pissing contest.  I am suggesting that
whether to publish a document in the IETF Stream is an IETF
decision, made at the IETF's discretion, and that the IESG has
told us that any such documents must represent IETF consensus.  

I am also suggesting that if we, the IETF, say that someone MUST
do something in a particular way, and do so with the full
knowledge that the community to whom that is being addressed has
ignored us before and may ignore us again, it is bad for the
IETF's reputation... and just silly.

So I am not suggesting any changes in what the document
describes and recommends.  While I suggest that cleaning up the
language to make it more precise from a technical standpoint, I
don't feel very strongly about that, especially if you and
others are convinced that no one outside the current javascript
implementation community will ever read it.   But I do think it
is important to remove the BCP 14 normative language and to
improve the quality of explanation of changes, even if to more
clearly say "we said to do X, the consensus of common practice
has chosen Y instead, so, because this is an Informational and
descriptive document, we are now specifying Y without expressing
any opinion of which choice would be better in some different
reality."

If "the javascript crowd" is opposed to our doing that much,
then this ought to be a document that they publish in some
appropriate place where IETF consensus is not needed, and that
the IETF, if appropriate, should just reference it.

best,
   john