Updates to ECMAScript Media Types
draft-ietf-dispatch-javascript-mjs-17

The MUST in Section 2 is kind of peculiar.  Is it a reminder to implementers today that they need to keep an eye out for possible updates in the future?  If so, I think it's unnecessary.  If something else is meant, then I'm quite confused.

In several of the subsections of Section 6.2, there are some errant punctuation characters hanging around.

This document is registering media subtypes starting with "x-" even though BCP 178 says not to do that.  If the working group intends to do this for historical reasons, I suggest including a sentence explaining that this is being done intentionally, perhaps under Appendix A of RFC 6838.  (See, for example, Section 6 of RFC 8894.)

Thank you to Radia Perlman for the SECDIR review.

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?

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


== NITS ==

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

Section 3

   This document does not define how fragment identifiers in resource
   identifiers ([RFC3986], [RFC3987]) for documents labeled with one of
   the media types defined in this document are resolved.  An update of
   this document may define processing of fragment identifiers.

This section is the "modules" section; the disclaimer of specification of
fragment handling seems to apply to both script and module content, and thus
to be misplaced in this section.

Section 5

   Module scripts in ECMAScript can request the fetching and processing
   of additional scripts, called importing.  Implementations that
   support modules need to process imported sources in the same way as
   scripts.  Further, there may be additional privacy and security
   concerns depending on the location(s) the original script and its
   imported modules are obtained from.  For instance, a script obtained
   from "host-a.example" could request to import a script from "host-
   b.example", which could expose information about the executing
   environment (e.g., IP address) to "host-b.example".  See the section
   "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details.

Is the referenced "ECMAScript Language: Scripts and Modules" section
supposed to be providing more details on the importing process, or the
potential privacy and security concerns?  I skimmed through it and found
nothing noteworthy on the latter, which suggests that perhaps the former was
intended.  If that's the case, then reordering the sentences within the
paragraph might be helpful.

   This circumstance can further be used to make information, that is
   normally only available to the script, available to a web server by
   encoding the information in the resource identifier of the resource,
   which can further enable eavesdropping attacks.  Implementation of
   such facilities is subject to the security considerations of the host
   environment, as discussed above.

What does "the resource" refer to, here?  I don't see a previous mention of
a resource that it would be referring to.  Is it perhaps a resource that's
the target of a request to the web server that is receiving the information
in question?

Section 7.1

It's pretty surprising to see a normative dependency on RFC 4329 when we
claim to obsolete that document.

Appendix B

Looking at the diff from RFC 4329, I also see some text about handling
application/ecmascript content that has a "version" parameter to the media
type, that seems to have been removed entirely for this document.  Is that
sufficiently noteworthy to be included in this change listing?


NITS

Section 5

   The programming language defined in [ECMA-262] is not intended to be
   computationally self-sufficient, rather it is expected that the
   computational environment provides facilities to programs to enable
   specific functionality.  [...]

The comma usage seems off here.  I'm not sure if the sentence overall
contains a comma splice or not, but probably there should be a comma after
"rather" regardless of whether the first comma is converted to
semicolon/full-stop or otherwise.

Section 6

   application/ecmascript" is to be removed.  IANA is requested to add
   the note "OBSOLETED in favor of text/javascript" to all registrations
   except "text/javascript".

Presumably this is "all registrations listed in this document", not "all
registrations in the registry"...

Section 6.2.x

I extracted the various subsections and used diff to compare them.
Aside from the expected variation in type/subtype name and file extension
(.es vs .js), there is also variation in:

- whether there is a full stop at the end of the "Change controller" line

- the "See also [sections] of [this document]" sentence in the
  interoperability considerations -- some say "various sections", others
  "section 4.1"; some have a "regarding the charset parameter" clause and
  others don't.  I'm not sure whether these variations are intentional or
  not.

- some have the "Person & email address to contact for further information"
  listing both this document and RFC 4329, but most just list this document.

- text/livescript does not have a note about this registration applying to
  later editions of [ECMA-262]; perhaps that's appropriate for the
  livescript media type.

Thanks to Robert Sparks for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/FyX4Y9g6TCBUB4t2GtsRyjrRWTQ).

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