Sigh. Mark, while you are very vocal in your opinions, you are
not the only one out there.
I was one of the people who raised the content-charset issue
at Atlanta, after having sent comments to the list and heard
nothing back.
We've gone over this territory many times; I suspect that consensus
will not appear via email, since the loudest people tend to drown
out everyone else.
Basically, there are two issues here: how should character sets
be represented? how should we make the syntax to show this
representation.
I think that the list has admitted that character sets are needed for
more than just type "text". So we need a header somewhere to represent
this. Given that point, I am against representing the character set
both as an optional parameter and as a subtype. Since it cannot
always be a subtype (for application types, for instance), I strongly
fell that character sets should be represented via a parameter.
Now there are two proposals on the floor for how to represent
parameters:
Content-type: Type/Subtype; charset=character-set
and:
Content-type: Type/Subtype
Content-charset: character-set
No matter how much people flame about this, it seems clear that there
is no semantic difference between the two proposals; one proposal
uses the existing header name space; the other creates a new namespace
under content-type.
This is fundamentally a religious difference. Personally, I hate
the idea of creating yet another level of header parsing -- there is
no gain to doing it and I therefore I don't think it is worth doing.
We have heard from others that they prefer the idea.
But to me, the most major concern is to get the idea of the "type"
of a body separated from its character encoding; they are two
different concepts and should not be forced together.
----- Begin Included Message -----