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

From: Mathias Bynens <[email-masked]>
Date: Mon, 17 May 2021 11:21:35 +0200

Sharing with [email-masked] as requested. Please review and voice
your support or concerns!

On Tue, Apr 27, 2021 at 7:26 PM Myles Borins <[email-masked]> wrote:

> Disclaimer: I am one of the authors of the draft.
>
> I would like to also express my support for this draft. It imho reflects
> ecosystem usage, for example there are currently over 6 million files
> with the .mjs extension on GitHub
> <https://github.com/search?l=&q=extension%3Amjs&type=code>.
>
> The extension is supported in some mimetype collections and DBs, such as
> that of the python programming language
> <https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L416>,
> but still hasn't been adopted by industry standard tools such as apache
> <http://apache-http-server.18135.x6.nabble.com/Bug-61383-New-mjs-files-should-be-part-of-mime-application-javascript-td5038697.html>.
> The lack of consistency here makes for poor developer experiences and
> inconsistent experiences across platforms + tools. This draft being
> accepted would be an extremely strong signal to let folks know that they
> can implement support for .mjs.
>
> Separate from the new extension that will be supported the updated draft
> includes a number of additional improvements that reflect the current
> reality of the web. This includes making "text/javascript" COMMON rather
> than OBSOLETE and an update to the security considerations.
>
> Thank you everyone for your time and considerations regarding this matter.
>
> On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens <[email-masked]> wrote:
>
>> Disclaimer: I am one of the authors of this draft. Nevertheless, I
>> would like to express my support and speak to the importance of its
>> standardization.
>>
>> The draft supersedes the earlier RFC4329, providing updated
>> definitions to align with what has quickly become implementation
>> reality, both in web browsers as well as other popular JavaScript
>> environments such as Node.js.
>>
>> Thanks,
>> Mathias
>>
>> On Tue, Apr 27, 2021 at 3:49 PM Kirsty P <[email-masked]> wrote:
>> > ________________________________
>> > From: Kirsty P
>> > Sent: 26 April 2021 16:25
>> > To: [email-masked] <[email-masked]>
>> > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th
>> May
>> >
>> > Hi DISPATCH,
>> >
>> > Summary: draft-ietf-dispatch-javascript-mjs is now ready for its 3rd
>> WGLC (Working Group Last Call). Please send your comments and/or
>> expressions of support to the DISPATCH list.
>> >
>> > Longer: the draft was recently updated to address feedback from a
>> review and from the 2nd WGLC [1]. The authors posted an update to the list
>> with more information [2]. We (DISPATCH chairs) feel like all the comments
>> have been addressed, so it's time for 3rd WGLC.
>> >
>> > We need to hear positive noises and support for this draft from the WG
>> before progressing the -08 draft, so please email to signal your
>> endorsement, even if you have no comments to make. The draft can be found
>> on datatracker here:
>> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/
>> >
>> > WGLC is open for 2 weeks - so will finish close-of-play on Monday 10th
>> May.
>> >
>> > Kirsty
>> > (DISPATCH co-chair)
>> >
>> > [1]
>> https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/
>> > [2]
>> https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/
>> >
>> >
>> >
>> > This information is exempt under the Freedom of Information Act 2000
>> (FOIA) and may be exempt under other UK information legislation. Refer any
>> FOIA queries to [email-masked]. All material is UK Crown
>> Copyright ©
>>
>

---

From: Mathias Bynens <[email-masked]>
Date: Tue, 18 May 2021 08:32:30 +0200

Looping in media type expert Murray Kucherawy, whose feedback on earlier
versions of this draft helped shape the proposal. Murray, what do you think
of the latest version?

---

From: Graham Klyne <[email-masked]>
Date: Tue, 18 May 2021 11:18:30 +0100

I'm responding without knowledge of the history of this proposal, but recent 
experience with the node ecosystem leads me to a view that a common mechanism 
for distinguishing javascript modules is a Good Thing.  A couple of concerns 
occur to me:

1. I think that depending on the file extension to make the distinction between 
scrips and modules doesn't really sit well with usage on the Web if they are 
expected to be parsed differently.  I would have thought a different media type 
would be useful too (though it may be late to stop that horse from bolting).

I note the draft is about much more than the .js/.mjs distinction... a couple of 
other thoughts that struck me...

2. I couldn't understand the section on character encoding detection (sect 4.2), 
in particular this paragraph:

[[
        Implementations of this step MUST use these octet sequences to
        determine the character encoding scheme, even if the determined
        scheme is not supported.  If this step determines the character
        encoding scheme, the octet sequence representing the Unicode
        encoding form signature MUST be ignored when decoding the binary
        source text.
]]

I'm probably misunderstanding something here, but it seemed self-contradictory 
to me (if the unicode encoding signature is used to determine the encoding, it 
must be ignored...?)

3. Security considerations for Javascript (or any scripting language on the web) 
is clearly a massive topic, which I don't think a "security considerations" 
section alone can adequately address.  I think many useful points are covered 
there, but I would have liked to also see references to other documents that 
discuss security models for scripting on the web (e.g. 
https://datatracker.ietf.org/doc/html/rfc2046#section-4.5.2, 
https://www.w3.org/Security/wiki/Cross_Site_Attacks, 
https://www.w3.org/TR/CSP2/, etc -- this list isn't intended to be exhaustive or 
even representative - just examples of other work in the area that might be 
cited), or at least a nod to the existence of other work that should be noted.

#g
--

On 17/05/2021 10:21, Mathias Bynens wrote:
> Sharing with [email-masked] <mailto:[email-masked]> as requested. 
> Please review and voice your support or concerns!
> 
> On Tue, Apr 27, 2021 at 7:26 PM Myles Borins <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     ecosystem usage, for example there are currently over 6 million files with
>     the .mjs extension on GitHub
>     <https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L416>, but
>     still hasn't been adopted by industry standard tools such as apache
>     inconsistent experiences across platforms + tools. This draft being accepted
>     would be an extremely strong signal to let folks know that they can
>     implement support for .mjs.
> 
>     On Tue, Apr 27, 2021 at 10:17 AM Mathias Bynens <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         On Tue, Apr 27, 2021 at 3:49 PM Kirsty P <[email-masked]
>         <mailto:[email-masked]>> wrote:
>          > To: [email-masked] <mailto:[email-masked]> <[email-masked]
>         <mailto:[email-masked]>>
>          > Subject: 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline
>         10th May
>          >
>          > Hi DISPATCH,
>          >
>         review and from the 2nd WGLC [1]. The authors posted an update to the
>         list with more information [2]. We (DISPATCH chairs) feel like all the
>         comments have been addressed, so it's time for 3rd WGLC.
>          >
>          > We need to hear positive noises and support for this draft from the
>         WG before progressing the -08 draft, so please email to signal your
>         endorsement, even if you have no comments to make. The draft can be
>         found on datatracker here:
>         <https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/>
>          >
>          > WGLC is open for 2 weeks - so will finish close-of-play on Monday
>         10th May.
>          >
>          > Kirsty
>          > (DISPATCH co-chair)
>          >
>          > [1]
>         <https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/>
>          > [2]
>         <https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/>
>          >
>          >
>          >
>         (FOIA) and may be exempt under other UK information legislation. Refer
>         any FOIA queries to [email-masked]
>         <mailto:[email-masked]>. All material is UK Crown Copyright ©
> 
> 
> _______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types
> 

-- 
Graham Klyne
mailto:[email-masked]
Skype/Twitter: @gklyne

---

From: Mathias Bynens <[email-masked]>
Date: Tue, 18 May 2021 13:39:48 +0200

Comment inline

> would be useful too (though it may be late to stop that horse from

I agree it would have been much nicer to have a separate media type for
modules, but I’m afraid that ship has sailed, as you suspected.

JavaScript modules being served as text/javascript is already Web Reality,
and we cannot change browsers to become more strict about which modules
they load/execute at this point without Breaking The Web, so it cannot
happen.

FWIW, your comments echo feedback we’ve received on the previous version,
and which we’ve tried to address in this revision by including specific
language around how this draft matches implementation reality:

```
   The definitions in this document reflect the current state of
   implementation across the JavaScript ecosystem, in web browsers and
   other environments such as Node.js alike, in order to guarantee
   backwards compatibility with existing applications as much as
   possible.
```

Does this address your concerns?

> to me (if the unicode encoding signature is used to determine the

Happy to clarify. This is about the Unicode Byte Order Mark (BOM), which
should be stripped from the file's contents before processing it. More info
here: https://en.wikipedia.org/wiki/Byte_order_mark (This is not specific
to this draft, or even to ECMAScript — it’s a general Unicode concept.)

Note that this language is not new to this draft; it's inherited
from RFC4329 which this document supersedes.

> cited), or at least a nod to the existence of other work that should be

https://datatracker.ietf.org/doc/html/rfc2046#section-4.5.2 does not apply
to ECMAScript and seems out of scope for this draft.

Both https://www.w3.org/Security/wiki/Cross_Site_Attacks and
https://www.w3.org/TR/CSP2/ are specific to usage of ECMAScript *in web
browsers*, and are covered by:

```
   Uncontrolled execution of scripts can be exceedingly dangerous.
   Implementations that execute scripts MUST give consideration to their
   application's threat models and those of the individual features they
   implement; in particular, they MUST ensure that untrusted content is
   not executed in an unprotected environment.

   […]

   Specifications for host environment facilities and for derived
   programming languages should include security considerations.  If an
   implementation supports such facilities, the respective security
   considerations apply.  In particular, if scripts can be referenced
   from or included in specific document formats, the considerations for
   the embedding or referencing document format apply.
```

Furthermore, the “security considerations” section is explicitly “to be
understood as non-exhaustive and of a purely illustrative nature.”

Given the above, I'd prefer not resetting the process by creating another
draft revision just to add one or two non-normative example links.

What do you think?

> but
> >     <
> http://apache-http-server.18135.x6.nabble.com/Bug-61383-New-mjs-files-should-be-part-of-mime-application-javascript-td5038697.html
> >.
> accepted
> >         <
> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/>
> >          >
> >         <
> >         <

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 19 May 2021 16:21:40 +0900

> from RFC4329 which this document supersedes.

It is indeed somewhat difficult to understand for people who are not 
familiar with the BOM, and autodetection proceedures.

I'd suggest changing:

If this step determines the character
encoding scheme, the octet sequence representing the Unicode
encoding form signature MUST be ignored when decoding the binary
source text.

to something such as:

If this step determines the character
encoding scheme, the octet sequence representing the Unicode
encoding form signature is not part of the actually decoded binary
source text.

Regards,   Martin.

---

From: "John Levine" <[email-masked]>
Date: 19 May 2021 12:44:47 -0400

>encoding form signature is not part of the actually decoded binary

While I agree with your concern, and have given up trying to figure
out how the Javascript world got so broken that it cannot keep its
encodings straight without having to sniff the contents of every
message, I don't think we should change the language. It's been there
for a long time, everyone wno needs to understand it knows what it
means, and if we change it, we'll be in for a round of "why did they
change it and what do I have to do different."

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 May 2021 14:40:21 -0400

--On Wednesday, May 19, 2021 12:44 -0400 John Levine
<[email-masked]> wrote:

>>> Note that this language is not new to this draft; it's
>>> inherited from RFC4329 which this document supersedes.
>> 
>> It is indeed somewhat difficult to understand for people who
>> are not  familiar with the BOM, and autodetection proceedures.
>> 
>> I'd suggest changing:
>> 
>> encoding form signature MUST be ignored when decoding the
>> binary source text.
>> 
>> to something such as:
>> 
>> encoding form signature is not part of the actually decoded
>> binary source text.
> 
> While I agree with your concern, and have given up trying to
> figure out how the Javascript world got so broken that it
> cannot keep its encodings straight without having to sniff the
> contents of every message, I don't think we should change the
> language. It's been there for a long time, everyone wno needs
> to understand it knows what it means, and if we change it,
> we'll be in for a round of "why did they change it and what do
> I have to do different."

John,

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.  The specifics are different, but a review of why we wrote
RFC 6082, deprecating the Unicode language tagging of RFC 2482,
is relevant here.  Sniffing, simplistic tagging, and so on do
not work reliably unless assumptions are made about assorted
external details and those assumptions are actually correct.
The crude example in this case is that sniffing for Unicode
encoding types works if the underlying CCS is guaranteed to be
Unicode.  If it is something else, all bets are off.

I could make comments about brokenness even stronger than yours
about the choice of file name extensions to determine details of
data types.  I thought the Internet community gave up on that
decades ago.

I've been trying to ignore this thread, but this exchange is
sort of a last straw and it seems it is time to raise more basic
questions.

So some suggestions wrt this document if it is really to go
forward in the IETF:

(1) Martin's suggestion or something like it is an improvement,
but the reason for the change should be clearly explained.  The
style of explanations in Appendix B, many of which are of the
form "We changed X" or "Updated Y to make it better" are
inadequate in that regard without an explanation as to why
and/or the implications of the change.  Otherwise, while some
are more obvious than others, many of them have the potential to
create the type of confusion you identify.

(2) To be clear, similar comments apply to almost every bullet
point in Appendix B: the changes require explanation.

(3) If this document, as suggested by both discussions in this
thread and the "... updates ... to reflect existing usage on the
Internet" introductory text is apparently the result of IETF's
opinion of actual practice in the javascript community, practice
that has diverged enough from what RFC 4329 specified to justify
such a revision.  As an Informational spec expressing our
summary of what is happening elsewhere and clearly not under our
control, the use of normative BCP 14 language is entirely
inappropriate both conceptually and because the very need for
the document is evidence that the relevant implementation and
operational communities are not paying attention.  Phrases like
"MUST foo" should be replaced by ones more like (relying on RFC
8174) "you must do X because anything else will lead to <bad
thing>".

And, if that is too much work or this is the opinion of the
authors or the javascript community about common practdice and
not the IETF, then I recommend either of two other options:

(i) Rewrite the introductory material to indicate that it is the
opinion of the authors and anything they cite.  Then Dispatch
this to the tender mercies of the ISE because, if the IETF can
merely report on actions of others rather than influencing
results, that is not a useful business for us to be in.  If the
IESG then wants to obsolete 4329 and point to the new document
for explanation, nothing prevents that, especially given that
both would be Informational rather than standards track.

or

(ii) Let ECMA/TC39 adopt this document, review, and publish it
as part of the ECMAScript collection.  Then produce a very short
RFC that obsoletes 4329, points to the ECMA document, and adds
whatever information about the reasons for the change seem
helpful.

Grump.
    john

---

From: "John R Levine" <[email-masked]>
Date: 19 May 2021 15:10:14 -0400

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

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.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Bradley Farias <[email-masked]>
Date: Wed, 19 May 2021 16:10:09 -0500

To be clear, no media sniffing is done; the mode switch on how things are
determined to be a Module or Script is determined by method of consumption
not the content served.

On Wed, May 19, 2021 at 2:10 PM John R Levine <[email-masked]> wrote:

> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 May 2021 18:19:48 -0400

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

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

---

From: Bradley Farias <[email-masked]>
Date: Wed, 19 May 2021 18:06:41 -0500

I also would like to speak somewhat directly.

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

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.

This is the kind of derision I was referencing earlier.

On Wed, May 19, 2021 at 5:38 PM Myles Borins <mylesborins=
[email-masked]> 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 <[email-masked]> wrote:
>
>>
>>

---

From: "John R Levine" <[email-masked]>
Date: 19 May 2021 20:06:49 -0400

> wrote as well as the fundamental existence of the document to begin with.

If it wasn't clear. while I am not thrilled that one has to look for the 
BOM to tell how a Javascript item is encoded, I also realize that it's 
baked into every browser in the world, so I agree that we should document 
the reality.

In the future it would be nice to make the types and content match better, 
but that's something to address when new types appear.

Regards,

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 20 May 2021 09:21:18 +0900

Hello Bradley,

> kind even if that is undesirable for all parties involved.

Just one point that looks like a potential very deep and decisive 
misunderstanding. There is absolutely no "6 month comment period" in the 
IETF. In my 25 years of being involved in the IETF, this is the first 
time I have head of a "6 month comment period". The longest comment 
period that I can remember having heard of up to now is 6 weeks (4 weeks 
IETF-wide non-WG last call + two weeks extra over Christmas). If you 
could tell us how/where you learned about such a (nonexisting!) concept, 
that might help us find and fix a problem.

My (wild?) guess is that the six months might come from the sentence
"Internet-Drafts are draft documents valid for a maximum of six months"
which is included in every Internet draft. But please note the word 
"maximum". These six months are there to make sure people don't feel 
satisfied at leaving something as an Internet Draft forever; the only 
choices are 1) abandon, 2) resubmit an update, and 3) move on to RFC.

But it's perfectly fine (indeed, highly desirable and recommended) to 
move at a faster pace. It's not unseen that somebody submits a draft and 
then a few minutes later submits a new version just because they have 
found another typo. For an extreme example of "submit early and often", 
please see 
https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76 (76 
drafts over 17 months).

So in order to push your work forward, I recommend you wait until the 
discussion has died down, incorporate the necessary changes, and 
resubmit a draft. Then you ask people to check the changes, and repeat 
as necessary. Once things have cooled down, you contact the responsible 
WG chair (or AD) and tell them that you think the document may be ready 
for the next step such as WG last call (which may include more comments 
and more drafts).

Finally, some comments closer to the subject matter. I think John Levine 
is correct that the wording change I proposed may be misinterpreted as a 
material change. John Klensin showed how that can be dealt with.

With regards to claims that the JavaScript community didn't follow the 
first RFC to the letter: I think everybody who has been doing standards 
work, and that should include most people in the IETF, know an example 
or two (or many more) where well-intended specification language didn't 
work out in practice, and the language (and not the practice) were 
fixed. The formal explanation is "dynamic interaction of diverse players 
in a complex ecosystem" or some such. Stuff happens. There is no 
protocol police, but there's paper (or electrons) to document things and 
bring everybody on the same page.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 May 2021 20:32:48 -0400

Bradley, Myles,

No derision was intended.  I could explain further what I was
saying, but I don't think it would be helpful.  Nor do I see
this as an "us versus them" situation, only as one in which we
try to figure out what each organizational structure does best,
what we are really trying to accomplish, and what the best modes
and styles of presentation are to accomplish that.

That said, I do not want to contribute further to a discussion
in which I was attempting to be constructive but obviously
intervened in the wrong way at the wrong time.  So I apologize
and am dropping back out.

   john

--On Wednesday, May 19, 2021 18:06 -0500 Bradley Farias
<[email-masked]> wrote:

> 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.
> 
> 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.
> 
>> 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
>>> >> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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."
>>> 
>>> appropriate place where IETF consensus is not needed, and
>>> that the IETF, if appropriate, should just reference it.
>>> 
>>> best,
>>>    john
>>>

---

From: Myles Borins <[email-masked]>
Date: Wed, 19 May 2021 18:37:30 -0400

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.