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

[Mathias Bynens <[e-mail]>]

Hi Francesca,

Thanks for those additional comments! Replies inline.

On Thu, Sep 2, 2021 at 8:23 PM Francesca Palombini <
[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]>
> *Date: *Wednesday, 1 September 2021 at 14:03
> *To: *Francesca Palombini <[e-mail]>
> *Cc: *"[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <[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]> 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]>
> *Date: *Monday, 30 August 2021 at 08:47
> *To: *Francesca Palombini <[e-mail]>
> *Cc: *"[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <
> [e-mail]>gt;, "[e-mail]" <[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


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


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

----------

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


>