Re: [I18ndir] Review volunteer needed (Fwd: [dispatch] WGLC of draft-ietf-dispatch-javascript-mjs-07)

[Asmus Freytag <[e-mail]>]

Just saw this, and think these items should be raised, but I also like 
some of the other John's feedback on document structure. While it's not 
an i18n issue per se, it really impeded the review. I also think the 
other John and some more direct suggestions on how to write the language 
(and there's the point about NFC and what it implies about Unicode - 
although legacy data almost always is in NFC once converted, per design 
of NFC).

A./

On 4/30/2020 10:22 AM, John R Levine wrote:
>> the WG to take some action? If I don't hear from anyone, I'll start 
>> accosting people privately.
>
> Nooo, not the Private Accosting.
>
> Summary:
>
> The i18n directorate has some concerns about character set handling in
> draft-ietf-dispatch-javascript-mjs-07.
>
> We understand it to say that if a javascript MIME element does not 
> have a name that ends with .mjs, a consumer ignores the declared 
> charset and looks at the first few bytes of the content for a byte 
> order mark (BOM.) If it finds one, it uses the charset implied by the 
> BOM, which can be UTF-16BE, UTF-16LE, or UTF-8.  If there's no BOM, it 
> uses the declared charset unless there isn't one, in which case it 
> defaults to UTF-8.
>
> We are unaware of any other MIME type that uses this sort of trick to 
> work around mislabelled content, and are concerned that it leads to 
> failures in general MIME code that doesn't handle this special case.  
> We also don't know how important the workaround is in practice, e.g., 
> how many MIME producers still mislabel UTF-16 as UTF-8 or vice versa.
>
> For better interoperation it could say something like producers MUST 
> put the correct charset on any media (same as any other media type) 
> and that consumers SHOULD use the declared charset but MAY do the BOM 
> trick for backward compatibility in certain cases.
>
> It also says the BOM must be removed from the decoded text. That's 
> confusing since ECMAscript treats a BOM as a space which would be 
> harmless at the start of a block of code.

Good point. In that case, if BOM can happily survive then that removes 
the implicit requirement for BOM sniffing altogether, making a stronger 
case for disallowing it to override anything.

If specific legacy support is required, it should be called out as such.

A./


>
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>