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

[Bill McQuillan <[e-mail]>]

On Wed, 2012-04-18, Julian Reschke wrote:
> 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?

As I understand it, the reason, originally, for having a major
type of "text" is that if the minor type is unknown to the end
user, it can be treated as "text/plain" and examined by a simple
text editor to perhaps discover the content or a hint as to the
appropriate application to process it. If the proposal here
doesn't have this characteristic, it shouldn't be called "text",
IMHO. It should be labeled "application/octet-stream".

Now the most straight-forward way to accomplish this capability
seems to be that one could examine the content with a text
processor that displays octets below 128 as ASCII and, at
least, does not self-destruct when it encounters octets above 127.

This is different from the previous guarantee of only 7-bit ASCII
as the default, but should be handled by many modern text
handling programs. Thus my conclusion of the defacto default
charset "embedded-ascii" alluded to above.

-- 
Bill McQuillan <[e-mail]>