Ned,
The introduction of a Content-charset header line will be a first for the
Internet e-mail standards; to wit, the first time a header was introduced that
is an *error* if it appears in certain circumstances.
This is not a wise precedent, in my view.
More than that, it screws up any attempt to create a structured
representation of the header. I need to represent this data in other (= more
formal and stricter) than an RFC-XXXX manner; one in which all fields are
mandatory. Instead of having a list of attribute and value pairs, I now have
to decide, a priori, which content types reasonably have a character set
element and which ones do not. That means that I have to figure out what it
means to have a character set for certain types, and worry about what happens
if someone conjures up a legitimate use for the types that I exclude.
Putting it in an attribute/value pair is an end run around the problem,
since it becomes a higher level (UA) issue rather than at my level. I could
care less whether type VIDEO has a charset attribute with some value.
What in effect is being done is move charset handling from something
fundamental at the lowest level to a high level.
Finally, if we do standardize on attribute=value for parameters, then
*all* RFC-XXXX implementations will have to handle it, since MULTIPART will
become something like:
Content-type: MULTIPART/SERIAL; boundary=123abc
If we had done this to begin with the present hassle we have with the late
unlamented 1-S and 1-P parameters could have been avoided.
-- Mark --