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

[Francesca Palombini <[e-mail]>]

Hi Mathias,

Looks good! All patches look good to me. Thank you, and thanks for the clarifications about the JS reference, you can leave this as is, and we’ll see if anybody else has more feedback during IETF Last Call.

I am ok with the last patch, but just make sure you reflect that change in Appendix B, so that it is clear that it is only clarifications and it is not doing any major modifications.

Also, I was made aware that the document might need to be more specific about Byte Order Marks (BOM), and clarify if BOMs are allowed, required or acceptable. This would not fall into the “fixing 4329”, but in the “necessary clarification” category. I think we can get more input about this during IETF Last Call.

In the meantime, please go ahead and merge all the PRs, and publish the new version.

Thank you!
Francesca

From: Mathias Bynens <[e-mail]>
Date: Friday, 3 September 2021 at 16:01
To: Francesca Palombini <[e-mail]>
Cc: "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>
Subject: Re: AD review of draft-ietf-dispatch-javascript-mjs-09



On Fri, Sep 3, 2021 at 9:53 AM Mathias Bynens <[e-mail]<mailto:[e-mail]>> wrote:
Hi Francesca,

Thanks for those additional comments! Replies inline.

On Thu, Sep 2, 2021 at 8:23 PM Francesca Palombini <[e-mail]<mailto:[e-mail]>> wrote:
Hi Mathias and authors!

Thank you for all the work, only a couple of replies left. With these clarifications you have answered all my comments (thank you!), and as soon as you have submitted a new version of the draft including all the changes I can go ahead and request the IETF Last Call.

Thanks,
Francesca

From: Mathias Bynens <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 1 September 2021 at 14:03
To: Francesca Palombini <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: AD review of draft-ietf-dispatch-javascript-mjs-09

Hi Francesca,

Thanks again for your patience and detailed comments! I’ve tried to address them below — replies inline.

On Mon, Aug 30, 2021 at 5:12 PM Francesca Palombini <[e-mail]<mailto:[e-mail]>> wrote:
Hi Mathias,

Thank you for the quick reply! I tried to clarify some of my comments. As you can see, I have my opinion for some of the points (3. 4. And 5.), but it would be good to get the media type experts and IANA opinion as well, as they know better. I will reach out to IANA separately and CC you. Let me know if my suggestions make sense or you have additional questions/comments.

Francesca

From: Mathias Bynens <[e-mail]<mailto:[e-mail]>>
Date: Monday, 30 August 2021 at 08:47
To: Francesca Palombini <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: AD review of draft-ietf-dispatch-javascript-mjs-09

Hi Francesca,

We’ve worked through your feedback (italic below). Here are our responses (bold):


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


We believe this has already been addressed by the shepherd earlier in the thread.

FP: Indeed, and to reiterate: I am OK with keeping the BCP 14 terms that come from 4329. Do you think you could add some explanatory text in the introduction about the fact that this document updates existing requirements from 4329 based on existing practice?

I was about to add something but then realized that the draft already says: "This document updates the descriptions and registrations for these media types to reflect existing usage on the Internet. […] This document replaces the media types registrations in {{RFC4329}}, obsoleting that document." It sounds like that covers your request — but if this is not sufficient, please let me know what you had in mind.

FP: Indeed. I think that what I was looking for could be summarized by the following change:

OLD:
This document replaces the media types registrations in {{RFC4329}}, obsoleting that document.
NEW:
This document replaces the media types registrations in {{RFC4329}}, and updates the requirements for implementations using those media types defined in {{RFC4329}} based on current existing practices. As a consequence, this document obsoletes {{RFC4329}}.

Thank you! Patch: https://github.com/linuxwolf/bmeck-ids/pull/48<https://protect2.fireeye.com/v1/url?k=04c4af5a-5b5f9543-04c4efc1-8682aaa22bc0-b116245afe167f96&q=1&e=52da602a-27c9-4e9a-91c2-e50fc824827c&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F48>


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


This was done in response to Media-Type Early Review comments: https://github.com/linuxwolf/bmeck-ids/pull/25<https://protect2.fireeye.com/v1/url?k=2cecfd41-7377c443-2cecbdda-869a14f4b08c-03f5f96a636cd875&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F25>

FP: I take it this is the comment from Murray you are referring to in that issue:
> generally, the templates can't refer to RFC 4329 if you plan to obsolete it; they should refer to this document or something else that won't be obsolete when this is published
I note that Murray pointed out that “Published Specification” should not point to 4329, but should instead point to either this document or “something else”, and I was suggesting that that something else is the published specifications, so for text/javascript JS 1.5 spec, for text/exmascript ECMA spec etc. This is what RFC 4329 did (see for example https://www.iana.org/assignments/media-types/text/javascript ), and from checking RFC 6838 it is not clear to me that was a mistake. I guess it could be fine with pointing to this document since this document references the other specifications, but it seems more convoluted and I wanted to check with you and the media type expert of what’s the best way, if both are ok. I will also send a separate email to ask IANA, since they probably have the answer, and cc you in it.

Thanks! Per Ned Freed’s response on that thread, I’ve sent a patch updating these fields to point to the format specification, which in this case is ECMA-262: https://github.com/linuxwolf/bmeck-ids/pull/45<https://protect2.fireeye.com/v1/url?k=ab21d498-f4baeda9-ab219403-86e2237f51fb-b19606c2ec13fcaf&q=1&e=de61023b-a7e7-471d-ac34-fc875f365b25&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F45>

FP: great, thank you and thanks Ned for his expert opinion. However, I think that it is not correct to change the specification from Javascript to ECMA-262 for all registrations. I think this is a typo, and all javascript registrations should point to the correct Javascript reference, be it https://datatracker.ietf.org/doc/html/rfc4329#ref-JS15 or other (I am sure you have a better pointer than me). And as for 4329, I think it is fine to have those references as informative.

I believe our proposed change is correct: the latest published ECMA-262 spec is the JavaScript spec. In existing implementations, scripts using obsolete file extensions can still make use of modern JavaScript features that aren’t present in JS15<https://datatracker.ietf.org/doc/html/rfc4329#ref-JS15>15>. For example, here’s the list of MIME types web browsers recognize as “JavaScript”: https://mimesniff.spec.whatwg.org/#javascript-mime-type This is referenced from the HTML Standard here: https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages So in practice, those legacy extensions do not map to any specific version of the JavaScript language. They’re all just “JavaScript”, whatever the latest supported version is by the host environment.

Does this change the situation, or did I misunderstand? Please let me know how to proceed.

One possible resolution could be this patch, clarifying this aspect of implementation reality: https://github.com/linuxwolf/bmeck-ids/pull/51/files<https://protect2.fireeye.com/v1/url?k=394d97e7-66d6adfe-394dd77c-8682aaa22bc0-b9f85a8ab06d13ae&q=1&e=52da602a-27c9-4e9a-91c2-e50fc824827c&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F51%2Ffiles> Let me know if this is acceptable to you.





 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.


This does not appear to be common practice. E.g. RFC 54 (by Crocker, Postel, Newkirk, Kraley) was superseded by RFC 57 (by Kraley & Newkirk). We’d prefer proceeding in line with this precedent, given that including the original authors complicates the process further (since it would require their explicit approval of all our changes before moving forward).


FP: Maybe I did not explain myself: I was not asking you to add the authors of RFC 4329 as authors of this document (although I hope they are aware of this work and they have been included in the conversation if they are still active in this space) but I was suggesting to keep them on the registrations themselves, so for example for text/javascript: https://www.iana.org/assignments/media-types/text/javascript on the “Person & email address to contact” and “Author” line, replace your current “See Author's Address section of [this document].“ with “See Author's Address section of [this document] and [RFC 4329]”. This would not require their approval, as they are in practice keeping their contact where they already had it. (Also note, I was suggesting this only for those registrations that RFC 4329 initially did). Again, Murray, other media type experts and IANA can tell me if this is not common practice.

I see, apologies for misunderstanding. That makes total sense. Listing both the original authors + us in the IANA registry sounds good.


FP: Great, thanks. Could you add a patch for that too before submitting the new version? Just to be clear, that would apply only to the registrations already existing, so text/ecmascript (section 6.2.5), text/javascript (section 6.1.1), application/ecmascript (section 6.2.1), application/javascript (section 6.2.2)

Sure thing: https://github.com/linuxwolf/bmeck-ids/pull/49/files<https://protect2.fireeye.com/v1/url?k=00dda3e4-5f4699fd-00dde37f-8682aaa22bc0-03ad6ce28889cbb4&q=1&e=52da602a-27c9-4e9a-91c2-e50fc824827c&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F49%2Ffiles>



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.


I think this refers to the document at https://www.iana.org/assignments/media-types/media-types.xhtml, and not our draft. Am I misunderstanding? What changes would this require to our draft?



FP: Yes, sorry for being unclear: what I was referring to was the “Name” column in the IANA registry at https://www.iana.org/assignments/media-types/media-types.xhtml . Your draft already makes changes to the registrations (so, for example, changes the content of : https://www.iana.org/assignments/media-types/text/javascript ) but does not specify the update to the https://www.iana.org/assignments/media-types/media-types.xhtml page itself. So, going back to our text/javascript example, this is the entry for it in the media-type page right now:
javascript - OBSOLETED in favor of application/javascript
text/javascript<https://www.iana.org/assignments/media-types/text/javascript>
[RFC4329<https://www.iana.org/go/rfc4329>]

I believe this should be changed to:
javascript
text/javascript<https://www.iana.org/assignments/media-types/text/javascript>
[This document]

And similarly all other registration should add the “- OBSOLETED in favor of…” note.

In order for IANA to make this change, this draft should add one more section that describe this change, I assume (I will confirm with IANA in a separate email, cc’ing you). Does that make sense?

Thanks for clarifying. I believe https://github.com/linuxwolf/bmeck-ids/pull/44<https://protect2.fireeye.com/v1/url?k=1d5e2955-42c51064-1d5e69ce-86e2237f51fb-9311de681c5a2254&q=1&e=de61023b-a7e7-471d-ac34-fc875f365b25&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F44> addresses the issue based on the feedback from the IANA folks in the other thread.

FP: Yes, that’s partly what I was looking for. I suggest the following change (the reference should be updated for all registrations, not only for text/javascript):

OLD:
These changes are to be reflected in the IANA Media Types registry in accordance with {{RFC6838}}. The outdated note stating that the "text/javascript" media type has been "OBSOLETED in favor of application/javascript" is to be removed, listing this document as the reference.
NEW:
These changes are to be reflected in the IANA Media Types registry in accordance with {{RFC6838}}. All registrations will point to this document as reference. The outdated note stating that the "text/javascript" media type has been "OBSOLETED in favor of application/javascript" is to be removed. The outdated note stating that the "text/ecmascript" media type has been "OBSOLETED in favor of application/ecmascript" is to be removed.

Additionally, you might want to add the following sentence, if you think that is important to note:

IANA is requested to add the note "OBSOLETED in favor of text/javascript” to all registrations except “text/javascript”.

Amazing, thank you! Patch: https://github.com/linuxwolf/bmeck-ids/pull/50<https://protect2.fireeye.com/v1/url?k=eb696e9c-b4f25485-eb692e07-8682aaa22bc0-e349be9d94355ee2&q=1&e=52da602a-27c9-4e9a-91c2-e50fc824827c&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F50>

----------

One additional patch from an external contributor came in, and it improves the phrasing around the charset parameter (which we inherited from RFC4329): https://github.com/linuxwolf/bmeck-ids/pull/47/files<https://protect2.fireeye.com/v1/url?k=fa9250e4-a5096afd-fa92107f-8682aaa22bc0-707eab3b75677eaf&q=1&e=52da602a-27c9-4e9a-91c2-e50fc824827c&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F47%2Ffiles> This reminded me of your very first piece of feedback about this section. I'm supportive of these minimal changes but would like to avoid requiring another round of full reviews if we were to accept them. Would you recommend accepting this patch?

Thanks,
Mathias