Subject: [dispatch] Robert Wilton's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 05 Jan 2022 05:57:14 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-dispatch-javascript-mjs-13: 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:
----------------------------------------------------------------------

Hi,

Thanks for cleaning up the use of these media types.

I've no significant comments, with only a nit level comment that I found the
following paragraph in the introduction to be slightly strange because I read
it as implying (i) to be compliant with this RFC, implementations must also
read/consider any future RFCs that update it, and (ii) future 'optional'
updates may break implementation conformance to this RFC, which makes those
updates seem less optional.  I would propose just deleting this paragraph, but
happy to leave it to the authors discretion.

   This document may be updated to take other content into account.
   Updates of this document may introduce new optional parameters;
   implementations MUST consider the impact of such an update.

Regards,
Rob

---

From: Mathias Bynens <[email-masked]>
Date: Thu, 6 Jan 2022 11:50:50 +0100

Hi Rob,

Happy to elaborate on this on behalf of the authors.

This paragraph refers to exactly what happened with RFC4329, which this new
draft aims to supersede.

There was no way RFC4329 could have predicted that .mjs / JavaScript
modules would be a thing in the future. But now that this has happened,
it’s important that an RFC exists that captures this implementation
reality, so that the media types are not just a de facto standard but an
actual IETF standard. That’s what we hope to accomplish with this new draft.

It is possible that this process repeats itself in the future. In addition
to “classic scripts” and “modules”, ECMAScript could introduce an
additional script goal in the future. At that point, we might need an
additional media type registration, which would then ideally be
accomplished by updating our draft and superseding it.

I hope this clarifies things. Thanks for your review!

Mathias Bynens