Re: [dispatch] Éric Vyncke's No Objection on draft-ietf-dispatch-javascript-mjs-12: (with COMMENT)

[Mathias Bynens <[e-mail]>]

Thanks for taking a look, Éric. On behalf of the authors, I’ll respond to
your comments inline:

On Mon, Jan 3, 2022 at 1:16 PM Éric Vyncke via Datatracker <[e-mail]>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-dispatch-javascript-mjs-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document.
>
> Please find below ssome non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Ben Campbell for the shepherd's write-up including the
> section about the WG consensus for this update and on RFC 4329.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> -- Section 3 --
>
> Is TC39 so well-known by the IETF community that no expansion/explanation
> is
> required?
>

TC39 is the standards body in charge of ECMAScript, a.k.a. the JavaScript
language. The only mention of “TC39” in the draft gives the following
context:

```
   The TC39 standards body for ECMAScript has determined that media
   types are outside of their scope of work [TC39-MIME-ISSUE].
```

What would you consider to be missing? Happy to expand on this.


> -- Section 5 --
> This security section is pretty extensive (good thing) and I wonder
> whether it
> is relevant to this document as it is not related to the media types
> themselves
> but more on the scripting language itself.
>

Two notes:

1. The security section builds upon the one from RFC4329 (
https://datatracker.ietf.org/doc/html/rfc4329#section-5) which our draft
aims to supersede. Removing it would be a regression.
2. I see your point — the security risks are *mostly* related to the
language. IMHO the security section is still worth including, as for e.g.
browser implementations, the MIME type is what determines whether a given
resource is processed as a script or not. Thus, failing to respect the
media types as stated (e.g. accepting additional, non-standard media types
as if they were JavaScript) would constitute a security risk.

== NITS ==
>
> -- Section 4.2 --
> Suggestion, add "else" on steps 2 and 3 to be clear.
>

This section was inherited from RFC4329 as-is, and we’ve been hesitant to
make changes to it. However, this change seems small and harmless enough,
so I’ve prepared a patch here:
https://github.com/linuxwolf/bmeck-ids/pull/59