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 18:18, Ned Freed wrote:
> >> 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.

> Sure, I just meant that I missed it.

> >> I'm a bit confused by the specification.
> >
> > You need to keep in mind that this only applies to subtypes of text.

> Ack.

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

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

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

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

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

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

> 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