Re: [media-types] [dispatch] AD review of draft-ietf-dispatch-javascript-mjs-09

[Ben Campbell <[e-mail]>]

(as shepherd)

Hi Francesca,

I have a comment on point 1, below. I will leave the other points to the authors. 

Thanks!

Ben.


> On Aug 24, 2021, at 10:49 AM, Francesca Palombini <francesca.palombini=[e-mail]> wrote:
> 
> Thank you for the work on this document. This is my AD review.
> 
> I have divided comments into "main", "minor" and "nits". I'd like to have a discussion on my main comments before requesting the IETF Last Call. On the other hand, you can address the minors and nits together with any additional Last Call comments you will get. As I am coming in late to the process, please understand that I don't mean to re-hash existing discussions that I am not aware of, and I appreciate your patience: feel free to point me to previous discussion (and conclusions) I might have missed, if relevant.
> 
> For the minor comments - some of these are suggestions or questions which I hope will help improve readability, which you can decide to take or leave as you please.
> 
> Francesca
> 
> ## Main
> 
> 1. ----
> 
> FP: This document is presented in the Abstract, Introduction and Compatibility section as aiming to update some IANA registrations for the media types mentioned, as well as documenting current usage of these media types. Because of that, I am not convinced about the use of BCP 14 language: if the intent is documenting current practices, most of these BCP 14 terms should be replaced by explanations on how implementations behave. To give an example of my concern, for the following paragraph in Section 4:
> 
>   Implementations that support binary source text MUST support binary
>   source text encoded using the UTF-8 [RFC3629] character encoding
>   scheme.  Module goal sources MUST be encoded as UTF-8, all other
>   encodings will fail.  Source goal sources SHOULD be encoded as UTF-8;
>   other character encoding schemes MAY be supported, but are
>   discouraged.
> 
> FP: Are these requirements that should have been there in RFC 4329 and are being added now? Are these how most implementations already behave? Would it not make more sense to reformulate this paragraph to describe implementations behaviour, rather than mandate and recommend? Why using BCP 14 terms?
> This comment applies to all new occurrences of BCP 14 terms (it does not to apply to sections taken from RFC 4329, such as the first paragraph of section 4.1).

Most of the upper-case normative terms are leftovers from RFC 4329. The text you quote adds a MUST and SHOULD to a paragraph that already had BCP 14 language in order to match the existing style. I think the use of BCP 14 was a mistake for RFC 4329, but this draft did not undertake fixing every flaw in the RFC. 

Rewriting all the previously existing BCP 14 language would be a pretty big undertaking at this stage. Would it be reasonable to leave that as is, and add some explanatory text about it to the introduction?

> 
> 2. ----
> 
> FP: Maybe more of a question: why is the "Encoding considerations" field in all subsections of section 6.1 "binary"? RFC 4329 did have more text about the encoding, is that obsoleted? Did I miss in which part of the draft this is discussed?
> 
> 3. ----
> 
> FP: "Published specification" field of each subsection of section 6.1 is "this document". I don't believe that is correct, and it should instead point to the correct specification (so JS 1.5, ECMAScript etc).
> 
> 4. ----
> 
> FP: I would also add RFC 4329 authors as "Person & email address to contact", as well as "Author" for those media types that 4329 registered. Please let me know if this is not common practice, but it seems logical to me to have both you authors and previous authors.
> 
> 5. ----
> 
> FP: I believe it would make sense to modify the IANA media type registry to add an "OBSOLETED in favor of ..." note in the name column of all those media types obsoleted. I think this requires a new IANA section.
> 
> 6. ----
> 
> FP: There are 4 occurrences of media types where Intended usage is OBSOLETE, but the Restriction on usage does not have the same sentence as all the other obsolete ones:
> 
>  This media type is obsolete; current
>      implementations should use text/javascript as the only JavaScript/
>      ECMAScript media type.
> 
> I think this is an overlook, is that correct?
> 
> ## Minor
> 
> 7. -----
> 
> FP: Please consider adding some text in the introduction mentioning that this document expands on the security considerations. I appreciate this work on the Security Considerations section was done, and believe the BCP 14 terms make sense there. It should just be highlighted better in the introductory part of the document.
> 
> 8. -----
> 
> FP: I am not sure RFC3986 and RFC3987 need to be a normative reference, given the only place they appear is a paragraph stating how this document does not define processing of fragment identifiers.
> 
> 9. -----
> 
> FP: I'd suggest adding section numbers when referring to [ECMA-262] sections, instead of just names.
> 
> 10. -----
> 
>   javascript.  Differences in ECMAScript versions have been better
>   dealt with in the processors.
> 
> FP: "in the processors" - I am not sure what is meant here, might be worth considering rephrasing for clarity.
> 
> 11. -----
> 
>   Refer to [RFC6265] for a discussion of terminology used in this
>   section.  Source text (as defined in [ECMA-262], section "Source
> 
> FP: I am confused by what part of 6265 is relevant regarding terminology used in this section. Maybe adding a section pointer would help.
> 
> 12. -----
> 
>   separately for purposes of external storage and retrieval.  An
>   implementation's internal representation of source text and source
>   text are not considered binary source text.
> 
> FP: I have a hard time parsing "and source text", in the context of the sentence. What's the difference with "an implementation's internal representation of source text"? (this might be me not understanding the phrasing)
> 
> 13. -----
> 
> FP: Section 6 - IANA Considerations: please consider adding a link to the media type registry.
> 
> ## Nit
> 
> 14. ----
> 
>   of additional scripts, called importing.  Implementations that
>   support modules need to process imported sources in the same way
>   scripts.  Further, there may be additional privacy and security
> 
> FP: "in the same way script" - is it missing an "as"?
> 
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch