Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types"

[Ned Freed <[e-mail]>]

> On 2012/02/29 11:19, Ned Freed wrote:

> >> Another change I want to do is to add to:
> >
> >> "New subtypes of the "text" media type, thus, SHOULD NOT define a
> >> default "charset" value. If there is a strong reason to do so despite
> >> this advice, they SHOULD use the "UTF-8" [RFC3629] charset as the
> >> default."
> >
> >> a sentence that if it's not UTF-8, it MUST be an ASCII-compatible
> >> encoding.
> >
> > I think that's a very good addition to make.

> Do we really, in this day and age, expect a new type to define an ASCII
> compatible encoding that's not UTF-8 as a default?

I have no idea. There's lots of legacy charset usage out there, some extremely
entrenched. Better safe than sorry.

> If the MUST is some basic Mime requirement, then I don't see any reason
> to repeat it here.

It's a requirement for MIME, yes. But speaking as the types reviewer, expecting
people to read even the primary registration documents has proved to be a bit
problematic. Expecting them to dig a detail out of a not-obviously-related
document? Possible, but very unlikely.

It's not like the MIME requirement is going to change, either, so there's no
cost to duplicating it. The benefit is that of possibly saving someone a
reviewer round trip.

> If it's not, then I don't see why it couldn't be
> UTF-16(LE|BE) or some such. In any case, I don't see why we need to be
> that specific, we are already outside a SHOULD NOT and then outside a
> SHOULD, and that isn't supposed to happen very often.

Hopefully not. But it's hard to predict how this stuff will play out.

				Ned