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

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 15:42:32 +0200

On 2012-04-01 06:44, Ned Freed wrote:
>
>> RFC 2397 defaults media type of "data:" URIs to text/plain;charset=US-ASCII.
>
>> Should this be updated to default to utf8?
>
> I'm not entirely sure of all the ramifications, but they are minimal this
> sound like a really good idea to me.

There is one (IMHO) important erratum for 2397, and also it should be 
updated to be based on RFC 3986.

With respect to the encoding default, it would make sense to check what 
current implementations do; if they indeed agree on UTF-8, it might make 
sense to make that modification. (Does anybody happen to have a test case?)

I volunteer to work on a 2397bis if Larry is ok with this.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Apr 2012 18:34:53 +0200

On 2012-04-10 15:42, Julian Reschke wrote:
> ...

<http://greenbytes.de/tech/tc/datauri/#defaultencoding1>

So it appears that those UAs that do support text/plain data URIs all 
default to ISO-8859-1. Specifying UTF-8 instead probably wouldn't be 
helpful.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Apr 2012 18:54:40 +0200

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

---

From: Bill McQuillan <[email-masked]>
Date: Thu, 19 Apr 2012 00:59:23 -0700

> 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 <[email-masked]>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Apr 2012 10:07:51 +0200

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

> 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