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

[John R Levine <[e-mail]>]

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

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