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

[Bill McQuillan <[e-mail]>]

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.


-- 
Bill McQuillan <[e-mail]>