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

[Ned Freed <[e-mail]>]

> On Thu, Feb 23, 2012 at 5:59 AM, Ned Freed <[e-mail]> wrote:
> >> Additionally, media types should be able to define circumstances where
> >> in-band indicators override the charset parameter even if the charset
> >> parameter is present.
> >
> > That's a terrible way to do it

> It's reality in WebKit and IE for text/html.

You continue to confuse what implementations are allowed to do with what
registrations are allowed to contain. This is the fundamental error you make
repeatedly.

Again, if the labelling is wrong, the object is incompliant and
*implementations* are free to handle that case however they wish. But this
doesn't mean we should codify specific implementation practice in our
registratration process. In fact, as I said previously, this has the effect of
*limiting* implemetaitons options, so when the world changes, as it always
does, we end up with inflexible standards incapable of handling that new
reality.

If you want a specific example of why this sort of thing is a bad idea, you
need look no further than the original HTTP specifications. Those
specifications changed the default charset for text/plain from us-ascii to
iso-8859-1 for HTTP. It may have been a good idea at the time (or not), but how
about now?

> So far, evidence suggests
> that Gecko would serve users better if it changed to treat the BOM as
> having higher precedence than the HTTP-level charset parameter for
> text/html and text/javascript.

You're missing a critical qualifier here: *current* evidence. It may be true
now. What happens if when practices change and we end up stuck with a bunch of
advice that doesn't match whatever practices show up in the future?

> (text/plain is loaded using the HTML
> parser per the HTML spec and per reality, so it makes sense to do the
> same for text/plain even though I don't have evidence to show about
> compatibility issues either way.)

> > - if the type is self-identifying in terms of
> > charset, a charset parameter should simply not be defined for the type -
> > exactly what the current specification says to do.

> Logically, yes, but that's not how text/html, text/xml and text/css work.

> >> In particular, media types should be allowed to override the charset
> >> parameter if the first two or three bytes of the payload look like an
> >> UTF-16 or UTF-8 BOM.
> >
> > There are quite a few charsets in existence where it is perfectly permissible
> > for the first few bytes to match a BOM, except that it means something entirely
> > different.

> Seems to work for IE and WebKit in practice.

It doesn't work well at all in my experience, but even if you're generally
right at present, what guarantees can you offer for tomorrow?

Anyway, I see no point in continuing to argue this further. I've registered my
strong objections to all but one of your proposed changes, and that's
sufficient. I'm done.

				Ned