Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types"

["Martin J. Dürst" <[e-mail]>]

Hello Henri, Alex,

Some comments to Henri and some to Alex inline.

On 2012/02/22 22:25, Henri Sivonen wrote:
> In reference to
> https://svn.tools.ietf.org/svn/wg/appsawg/draft-ietf-appsawg-mime-default-charset/latest/draft-ietf-appsawg-mime-default-charset.html
>
> First of all, thank you for finally taking on the much-needed update
> to RFC 2046 rules.
>
> Unfortunately, the draft doesn't address the problem the right way in
> my opinion. Quotes from the draft.
>
>> Each subtype of the "text" media type which uses the "charset" parameter can define its own default value for the "charset" parameter, including absence of any default.

I'm not opposed to this in principle, but I'm worried that as written, 
it will lead to more and more unnecessarily different 'algorithms' and 
heuristics. The spec should make clear that where possible, established 
patters should be followed to reduce variety.


>> In order to improve interoperability with deployed agents, "text/*" media type definitions SHOULD either a) specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (as in "text/xml")
>
> This seems wrong. If the charset parameter is present, it has an
> effect for text/xml.

Yes indeed.

>> or b) require explicit unconditional inclusion of the "charset" parameter eliminating the need for a default value.
>
> This seems naïve. Formats need to specify what happens when a charset
> parameter is missing, since no matter how much the format says it's
> "required", the party sending data can omit the charset parameter.
>
>> In accordance with option (a), above, "text/*" media types that can transport charset information inside the corresponding payloads, specifically including "text/html" and "text/xml", SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the charset parameter value and the value specified in the payload disagree.
>
> For backwards compatibility, pretty much every existing text/* type
> will have to violate this "SHOULD NOT".

Yes. I think it's inappropriate to give such advice on existing formats. 
If we agree that changes are needed (which I think in the cases at hand 
would be somewhat wishful thinking), they should be specified directly, 
either in this document or preferably in an update to the spec of the 
format itself.


>> The default charset parameter value for text/plain is unchanged from [RFC2046] and remains as "US-ASCII".
>
> This is incompatible with reality. Web browsers, for instance, assume
> a configuration-dependent default (which correlates with browser
> localization) and may also (depending on configuration which, again,
> correlates with localization by default) perform a heuristic analysis
> on the payload.
>
> I suggest specifying the following instead of sections 3 and 4 of the draft:

> 4. Determining the character encoding for text/plain

This looks like a very long algorithm. It may work pretty well in a Web 
context (definitely better than an US-ASCII default), but what about 
other contexts (e.g. mail)?


[Part of the algorithm cut out to save electrons.]

> If the entity is being loaded into a browsing context and is being
> fetched from a location from which an entity has been loaded before
> and the previous character encoding has been cached, the character
> encoding is the cached encoding. Terminate these steps.
>
> If the entity is being loaded via a non-browsing context mechanism
> (such as XMLHttpRequest) that defines a fallback encoding, use that
> encoding. Terminate these steps.
>
> Otherwise, the character encoding is a configuration-dependent
> encoding. The default configuration SHOULD depend on the locale of the
> user agent according to the table given in step 8 in [5]. Terminate
> these steps.

What is missing here is that there is sometimes a need for user 
intervention if all else fails. While it may be possible to look at this 
as something outside of this algorithm, or as something subsumed under 
"configuration" or whatever, I'm afraid that the current text will give 
many implementers the impression that user overrides are not allowed. So 
I suggest adding something like:

    In an interactive context, the user may occasionally want to
    override the character encoding determined by this algorithm.


Regards,    Martin.

>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#ascii-case-insensitive
> [2] http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#concept-encoding-label
> [3] http://www.whatwg.org/specs/web-apps/current-work/#browsing-context
> [4] http://tools.ietf.org/html/rfc6454
> [5] http://www.whatwg.org/specs/web-apps/current-work/#determining-the-character-encoding
>