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

[Mathias Bynens <[e-mail]>]

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.

*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