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

[Ned Freed <[e-mail]>]

> On 10/07/2012 01:07, [e-mail] wrote:
> >
> > 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

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

> If we define a media type that is *always* UTF-8, does this count as
> 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
> 3 implies the latter, but it also talks about media types defining their own
> default encoding.

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.

> (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)

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