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

From: Mathias Bynens <[email-masked]>
Date: Wed, 1 Sep 2021 14:03:19 +0200

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 <
[email-masked]> 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 <[email-masked]>
> *Date: *Monday, 30 August 2021 at 08:47
> *To: *Francesca Palombini <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *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.

*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

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

>
>
> *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*
> <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 addresses the issue based on
the feedback from the IANA folks in the other thread.

> *9. -----*
>
>
>
> *FP: I'd suggest adding section numbers when referring to [ECMA-262]
> sections, instead of just names.*
>
>
>
> *The ECMAScript specification is a “living standard”, and the section
> numbers change frequently as new chapters are introduced or sections are
> moved around. Using the section names is a more stable, future-proof way to
> refer to specific parts of the spec. Given that, would you be okay with
> keeping this as-is?*
>
>
>
> *Alternatively, we could add links to the specific sections in the latest
> draft spec, e.g. **https://tc39.es/ecma262/#sec-source-text*
> <https://protect2.fireeye.com/v1/url?k=a860a650-f7fb9f52-a860e6cb-869a14f4b08c-423d42d73db683c7&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Ftc39.es%2Fecma262%2F%23sec-source-text>*
> — these URLs are stable, too, but I don’t think there is precedent for this
> in any existing RFC.*
>
>
>
> FP: Ok, thanks for this explanation, and no, I don’t necessarily need the
> section numbers. However, this worries me: normative references cannot be
> “living standard” (or as
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> says: “work in progress”) – could we reference a stable published version
> of the ECMA standard? I can see for example RFC 8785 referenced the 10th
> edition of it: https://datatracker.ietf.org/doc/html/rfc8785#ref-ECMA-262
>

Patch to pin to the latest published version (ES2021, i.e. the 12th
edition): https://github.com/linuxwolf/bmeck-ids/pull/46/files

Please let us know if the suggested patches adequately address the concerns.

Thanks,
Mathias Bynens on behalf of the draft-ietf-dispatch-javascript-mjs authors

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 2 Sep 2021 18:23:41 +0000

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 <[email-masked]>
Date: Wednesday, 1 September 2021 at 14:03
To: Francesca Palombini <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Date: Monday, 30 August 2021 at 08:47
To: Francesca Palombini <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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}}.

Or something on these lines.

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.

 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)

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

9. -----

FP: I'd suggest adding section numbers when referring to [ECMA-262] sections, instead of just names.

The ECMAScript specification is a “living standard”, and the section numbers change frequently as new chapters are introduced or sections are moved around. Using the section names is a more stable, future-proof way to refer to specific parts of the spec. Given that, would you be okay with keeping this as-is?

Alternatively, we could add links to the specific sections in the latest draft spec, e.g. https://tc39.es/ecma262/#sec-source-text<https://protect2.fireeye.com/v1/url?k=a860a650-f7fb9f52-a860e6cb-869a14f4b08c-423d42d73db683c7&q=1&e=bd06a8bd-b4a2-4969-8bac-0dc82582f91e&u=https%3A%2F%2Ftc39.es%2Fecma262%2F%23sec-source-text> — these URLs are stable, too, but I don’t think there is precedent for this in any existing RFC.

FP: Ok, thanks for this explanation, and no, I don’t necessarily need the section numbers. However, this worries me: normative references cannot be “living standard” (or as https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ says: “work in progress”) – could we reference a stable published version of the ECMA standard? I can see for example RFC 8785 referenced the 10th edition of it: https://datatracker.ietf.org/doc/html/rfc8785#ref-ECMA-262

Patch to pin to the latest published version (ES2021, i.e. the 12th edition): https://github.com/linuxwolf/bmeck-ids/pull/46/files<https://protect2.fireeye.com/v1/url?k=f4584718-abc37e29-f4580783-86e2237f51fb-6dd16cd8c2681e14&q=1&e=de61023b-a7e7-471d-ac34-fc875f365b25&u=https%3A%2F%2Fgithub.com%2Flinuxwolf%2Fbmeck-ids%2Fpull%2F46%2Ffiles>

Thanks,

---

From: Mathias Bynens <[email-masked]>
Date: Fri, 3 Sep 2021 09:53:30 +0200

Hi Francesca,

Thanks for those additional comments! Replies inline.

On Thu, Sep 2, 2021 at 8:23 PM Francesca Palombini <
[email-masked]> 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
>
>
>
> *Date: *Wednesday, 1 September 2021 at 14:03
> 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.
>
>
>
> 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

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

> * 4. ----*
> 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://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.
>
>
>
> 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

----------

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

---

From: Mathias Bynens <[email-masked]>
Date: Fri, 3 Sep 2021 16:00:55 +0200

On Fri, Sep 3, 2021 at 9:53 AM Mathias Bynens <[email-masked]> wrote:

>> *We believe this has already been addressed by the shepherd earlier in
>> the thread.*
>>
>>
>>
>> > 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
>>
> 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.
>

One possible resolution could be this patch, clarifying this aspect of
implementation reality: https://github.com/linuxwolf/bmeck-ids/pull/51/files
Let me know if this is acceptable to you.

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 3 Sep 2021 14:41:28 +0000

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

Date: Friday, 3 September 2021 at 16:01

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

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

Thanks,
Francesca

Hi Francesca,

Francesca

Hi Francesca,

## Main

1. ----

   discouraged.

OLD:

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

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

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

OLD:

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