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

[Alexey Melnikov <[e-mail]>]

Hi Francesca,

Just commenting on a few things:

On 24/08/2021 16:49, Francesca Palombini wrote:
> Thank you for the work on this document. This is my AD review.
>
> I have divided comments into "main", "minor" and "nits". I'd like to have a discussion on my main comments before requesting the IETF Last Call. On the other hand, you can address the minors and nits together with any additional Last Call comments you will get. As I am coming in late to the process, please understand that I don't mean to re-hash existing discussions that I am not aware of, and I appreciate your patience: feel free to point me to previous discussion (and conclusions) I might have missed, if relevant.
>
> For the minor comments - some of these are suggestions or questions which I hope will help improve readability, which you can decide to take or leave as you please.
>
> Francesca
>
> ## 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?
I am not an editor of this document, but I am speculating that the above 
is more restrictive than originally specified in RFC 4329.
> 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).
>
> 2. ----
>
> FP: Maybe more of a question: why is the "Encoding considerations" field in all subsections of section 6.1 "binary"? RFC 4329 did have more text about the encoding, is that obsoleted? Did I miss in which part of the draft this is discussed?

Actually text in RFC 4329 is pointing to RFC 3023 and the description in 
the latter is actually wrong. This field should be one of 4 values: 
7bit, 8bit, binary or framed. UTF-8 encoded JSON can be have CRLF 
terminated lines longer than 1000 octets, which makes the encoding field 
"binary".

Best Regards,

Alexey