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

[Myles Borins <[e-mail]>]

To speak candidly... I don't love the us vs. them language being thrown
around here.

There are many people who do work with and on JavaScript that participate
within IETF, and drawing a distinction between the two parties seems
unnecessarily decisive.

Myself and various others have been trying, as good citziens of the
internet, to document a web reality and update the current out of date RFC
in order to make the internet better. I outlined examples above of certain
platforms waiting on a clear signal from IETF / IANA before supporting the
.mjs extension with the appropriate mimetype... The lack of this support
creates developer friction and confusion.

It is extremely demotivating to be trying to work through a process for
many years and to consistently have folks jump in to give minor feedback
that continues to derail progress and burn out the people trying in good
faith to work with the IETF and hopefully become more regular contributors.

An expression comes to mind that "perfect is the enemy of good". This is
not to say that we should lower the quality bar here, but the current RFC
is inaccurate to web reality in ways this new rfc attempts to fix.

We first attempted to amend the existing rfc, but were requested to make a
new rfc due to the level of changes. We are now finally what feels like
close to done and are being challenged on both parts of the RFC we never
wrote as well as the fundamental existence of the document to begin with.

I understand that folks come and go and that there are many steps along the
way... but the way this overall process has played out is extremely
demotivating and disappointing.

I will definitely keep trying to push this forward, put I do wonder if we
could table some of the feedback we are receiving right now to come in an
update to the proposed text... As I genuinely fear that this will never get
published at the rate things have gone for over 3 years now

On Wed, May 19, 2021, 6:20 PM John C Klensin <[e-mail]> wrote:

>
>
> --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
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>