Subject: [apps-discuss] RFC 6657 on Update to MIME regarding "charset" Parameter Handling in Textual Media Types

From: [email-masked]
Date: Mon, 9 Jul 2012 17:07:54 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 6657

        Title:      Update to MIME regarding "charset" 
                    Parameter Handling in Textual Media Types 
        Author:     A. Melnikov, J. Reschke
        Status:     Standards Track
        Stream:     IETF
        Date:       July 2012
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      6
        Characters: 10111
        Updates:    RFC2046

        I-D Tag:    draft-ietf-appsawg-mime-default-charset-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6657.txt

This document changes RFC 2046 rules regarding default "charset"
parameter values for "text/*" media types to better align with common
usage by existing clients and servers.  [STANDARDS-TRACK]

This document is a product of the Applications Area Working Group Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Graham Klyne <[email-masked]>
Date: Tue, 10 Jul 2012 09:14:12 +0100

>                      Parameter Handling in Textual Media Types

I didn't see this one coming.  I'm a bit confused by the specification.

If we define a media type that is *always* UTF-8, does this count as 
transporting its own charset information?  Should we say that the media type 
SHOULD NOT be included, or that it SHOULD be included with value UTF-8?  Section 
3 implies the latter, but it also talks about media types defining their own 
default encoding.

(This is not an academic question - a W3C group I'm involved with is about to 
submit a registration for a UTF-8 only text/... media type)

#g
--

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Jul 2012 17:19:43 +0100

Hi Graham,

> transporting its own charset information?  Should we say that the 

I think you meant the "charset" parameter.

> SHOULD NOT be included, or that it SHOULD be included with value 
> UTF-8?  Section 3 implies the latter, but it also talks about media 
> types defining their own default encoding.

For backward compatibility with RFC 2045 it would be better to require 
explicit 'charset="utf-8"', but not allowing the charset parameter and 
saying that the payload for your text/foo media type is always in UTF-8 
is fine.

> (This is not an academic question - a W3C group I'm involved with is 
> about to submit a registration for a UTF-8 only text/... media type)
>
> #g
> -- 
>
>> For searching the RFC series, see 
>> http://www.rfc-editor.org/rfcsearch.html.

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Jul 2012 10:18:38 -0700 (PDT)

> I didn't see this one coming.

It was discussed at considerable length both here and on the IETF list.

>  I'm a bit confused by the specification.

You need to keep in mind that this only applies to subtypes of text.

> transporting its own charset information?

That's one approach you can use. The alternatives are to allow or require
a charset parameter, always with the value utf-8. The best approach depends
on the specifics of the type.

>  Should we say that the media type
> SHOULD NOT be included, or that it SHOULD be included with value UTF-8?

Included where? Within the content? If so, that's up to the registration to
say. There are plenty of utf-8 based formats that don't provide for inclusion
of media type information - and that includes some that use XML syntax.

> Section

Relying on defaults is discouraged for historical reasons - they don't work
very well. As such, if it's possible for the type to explicitly say what the
charset is, that's probably the best way to do it. If the type isn't capable of
that for whatever reason, your options are to simply say it's always utf-8 or
alternately allow or require a charset parameter with utf-8 as the only value.
The best approach depends on the situation, which is why the document is full
of SHOULDs, not MUSTs.

> submit a registration for a UTF-8 only text/... media type)

Does this type actually meet the criteria for text specified in RFC 2046
section 4.1? I rather suspect it doesn't. If not, it really has no business
being a text subtype, and all of this is moot.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Jul 2012 22:44:54 -0700 (PDT)

> On 10/07/2012 18:18, Ned Freed wrote:

> Sure, I just meant that I missed it.

> Ack.

> Doh... I meant media type "charset" parameter.

> There's no character encoding information in the content.

> Yeah, one of those.  I expect it will come up for review very soon, so you can
> comment if we've made the wrong call.

> I believe it does.  We're not talking XML or anything like that.  It's a textual
> notation for provenance information, intended for human and occasional machine
> consumption.

Then my suggestion would be to make the charset parameter mandatory, with 
the only legal value being utf-8. The alternative would be to omit
it and specify utf-8 as the default, but as I said, that's not likely
to interoperate well.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Tue, 10 Jul 2012 18:12:15 +0100

Alexey, thanks.

#g
--

On 10/07/2012 17:19, Alexey Melnikov wrote:
>> Section 3 implies the latter, but it also talks about media types defining
>> their own default encoding.
>
> For backward compatibility with RFC 2045 it would be better to require explicit
> 'charset="utf-8"', but not allowing the charset parameter and saying that the
> payload for your text/foo media type is always in UTF-8 is fine.
>

---

From: Graham Klyne <[email-masked]>
Date: Tue, 10 Jul 2012 23:58:29 +0100

Ack.

#g
--