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

[Julian Reschke <[e-mail]>]

On 2012-05-10 09:51, Larry Masinter wrote:
> 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.

It updates RFC 2046 which is on the Standards Track.

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