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

[Mathias Bynens <[e-mail]>]

On Fri, Sep 3, 2021 at 9:53 AM Mathias Bynens <[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]> 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.
>

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.


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