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

[Graham Klyne <[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.

#g
--