[dispatch] Benjamin Kaduk's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

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.