Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt

[Julian Reschke <[e-mail]>]

On 2012-03-30 23:19, Bill McQuillan wrote:
> In section 3:
>
> ----------
>     In order to improve interoperability with deployed agents, "text/*"
>     media type registrations SHOULD either
>
>     a.  specify that the "charset" parameter is not used for the defined
>         subtype, because the charset information is transported inside
>         the payload (such as in "text/xml"), or
>     b.  require explicit unconditional inclusion of the "charset"
>         parameter eliminating the need for a default value.
>
>     In accordance with option (a), above, registrations for "text/*"
>     media types that can transport charset information inside the
>     corresponding payloads (such as "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.
> ----------
>
> Doesn't option (a) actually mean that a new default charset is
> now defined, perhaps called "embedded-ascii", in which all octets
> with values less than 128 must have the same meaning as the
> correspondding ASCII values and that all octet values greater
> than 127 may be ignored? This would allow naively processing a
> newly specified text/* type by displaying the content first using
> the "embedded-ascii" charset (ignoring non-ascii octets) and,
> hopefully, finding, by eye, the actual charset specified within
> and then re-displaying the content using that discovered charset.
>
> For instance how would a newly specified type similar to
> text/html with a document using the internal charset of "ebcdic"
> be handled? The current specification would deal with this merely
> by ensuring that a "charset=ebcdic" appeared in the Content-Type
> Mime field and also within the document itself.

I'm not sure I understand the question.

Types that transport charset information in-line will need to define how 
to detect it. An example would be the algorithm in

   http://www.w3.org/TR/xml/#sec-guessing

And yes, that works best if the encoding is compatible to US-ASCII (that 
is, octets 0..127 represent the same characters as in the US-ASCII 
encoding).

Do you think there's something we need to clarify here?

Best regards, Julian