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

[Bradley Farias <[e-mail]>]

I also would like to speak somewhat directly.

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

I would state that given the sheer denialism and duration of this review
for this particular RFC the reputation is already been soured for both
parts of the Node.js community and ECMA TC39 members. I've become fairly
used to 6 months of silence, followed by a brief comment period resetting
the 6 month time for comments that is both derisive and often demanding
re-explanation of how the browsers and the current state of web works. This
is not a good look and it does feel that the IETF largely does already
ignore other ecosystems, so it is understandable that they reciprocate in
kind even if that is undesirable for all parties involved.

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

I think such is possible, but given the lack of communication after such
changes we have done in the past I do not see it as a fruitful exercise
except to gain a new 6 month comment period followed by silence and a last
minute issues on what I personally regard somewhat as repetitive nature
that mostly are resolved by non-significant changes and or relying on
explanation of how other standards have evolved outside of the IETF
process, likely in part due to this friction.

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

This is the kind of derision I was referencing earlier.

On Wed, May 19, 2021 at 5:38 PM Myles Borins <mylesborins=
[e-mail]> wrote:

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