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

[Francesca Palombini <[e-mail]>]

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]>rg>, "[e-mail]" <[e-mail]>rg>, "[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]<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}}.

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>

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