Subject: [apps-discuss] APPSDIR review of draft-ietf-appsawg-mime-default-charset-03

From: Larry Masinter <[email-masked]>
Date: Thu, 10 May 2012 00:51:17 -0700

Sorry for the delay, hope this is in time.
==========
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-appsawg-mime-default-charset-03
Title: Update to MIME regarding Charset Parameter Handling in  Textual Media Types
Reviewer: Larry Masinter	
Review Date: 5/10/2012
IETF Last Call Date: (unknown)
IESG Telechat Date: 5/10/2012

Summary:  This draft is ready for publication as a Best Current Practice, although I have concerns, I don't feel strongly.

The document is being offered as Standards Track. But the document's effect is just to change the guidance for future media type registrations, which requirement should have an immediate effect, and which don't have a way of noting "independent interoperable implementations".  I know there is some fashion to have fewer BCPs and more "standards track", but I don't see how that applies here. 

Major Issues:  none

Minor Issues: 
I wish there were more analysis of the impact of confusion over default character set for new vs. old media types, e.g., old types which happen to not be registered.
I am concerned about whether there are pipelines that expect ASCII text if the content/type is text/something without any charset parameter.
I am concerned that people will take this as a license to change the default charset for text/plain to UTF8 in their implementations, yielding interoperability problems.

Nits: none noted

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 May 2012 14:30:24 +0200

> Sorry for the delay, hope this is in time.

It updates RFC 2046 which is on the Standards Track.

> I wish there were more analysis of the impact of confusion over default character set for new vs. old media types, e.g., old types which happen to not be registered.

I'm not sure what we could possibly say about unregistered types here.

> I am concerned about whether there are pipelines that expect ASCII text if the content/type is text/something without any charset parameter.

Are there any?

> I am concerned that people will take this as a license to change the default charset for text/plain to UTF8 in their implementations, yielding interoperability problems.

Right now text/plain without charset means US-ASCII (except over HTTP 
per RFC 2616). Thus the presence of octets outside 0..127 makes the 
content invalid, so we're talking about error handling.

Draconian error handling would reject the content (for some value of 
"reject"), permissive error handling might sniff or default to a 
US-ASCII-compatible encoding such as ISO-8859-1 or UTF-8. In the latter 
case, a default of "UTF-8" seems to be the right thing.

On the other hand, the text/plain default is defined in RFC 2046, and we 
are not changing this right now. Do you think we should state that 
explicitly? I have my doubts -- do we really think that people who *do* 
read *this* document come to the wrong conclusion?

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 May 2012 09:11:31 -0400

> On the other hand, the text/plain default is defined in RFC 2046, and we are
> not changing this right now. Do you think we should state that explicitly?

We do state it explicitly: it's the entirety of Section 4:

   4.  Default charset parameter value for text/plain media type

   The default charset parameter value for text/plain is unchanged from
   [RFC2046] and remains as "US-ASCII".

Barry