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

[Julian Reschke <[e-mail]>]

On 2012-04-19 09:59, Bill McQuillan wrote:
>
> 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".

The proposal isn't called "text" :-). It just modifies the rules for 
text/* defaults in new registrations.

Also, I do agree that this characteristic is desirable. The proposal 
IMHO doesn't change anything with respect to that.

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

It would be helpful if you could make a concrete change proposal.

Your concern seems to be about

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

Do you have a specific change proposal?

...also keep in mind that ASCII-ness of octets 0..127 may be desirable 
it's not the case today already (think UTF-16).

Best regards, Julian