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

[Mathias Bynens <[e-mail]>]

Comment inline

On Tue, May 18, 2021 at 12:18 PM Graham Klyne <[e-mail]>
wrote:

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


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

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.


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

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?



> On 17/05/2021 10:21, Mathias Bynens wrote:
> > Sharing with [e-mail] <mailto:[e-mail]> as
> requested.
> > Please review and voice your support or concerns!
> >
> > On Tue, Apr 27, 2021 at 7:26 PM Myles Borins <[e-mail]
> > <mailto:[e-mail]>> 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 <[e-mail]
> >     <mailto:[e-mail]>> 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 <[e-mail]
> >         <mailto:[e-mail]>> wrote:
> >          > ________________________________
> >          > From: Kirsty P
> >          > Sent: 26 April 2021 16:25
> >          > To: [e-mail] <mailto:[e-mail]> <
> [e-mail]
> >         <mailto:[e-mail]>>
> >          > 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/
> >         <
> 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/
> >         <
> https://mailarchive.ietf.org/arch/msg/dispatch/MOp48vAf_K4cjoS9XoFgxBUqXg0/
> >
> >          > [2]
> >
> https://mailarchive.ietf.org/arch/msg/dispatch/TmuVIJS6Umh37oOhiIHv-5Mzkis/
> >         <
> 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 [e-mail]
> >         <mailto:[e-mail]>. All material is UK Crown
> Copyright ©
> >
> >
> > _______________________________________________
> > media-types mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/media-types
> >
>
> --
> Graham Klyne
> mailto:[e-mail]
> Skype/Twitter: @gklyne
>