John Klensin writes:
...
It seems that there are two positions:
* Build a separate header so that you absolutely and for certain know
where to find the character set info because, when it is meaningful, you
need to pull it out without understanding how to parse subtypes.
* Keep the information in the subtypes to avoid a number of odd and/or
nasty and/or meaningless situations.
Now, this may be naive, but couldn't *both* goals be accomplished by
being a tad more clever about the content-type syntax? What we have
now, more or less, is
...
Well, no. You cannot split this down the middle in any way that is meaningful.
What you've done is invent a distinguished syntax that can be used to put
character set information into the content-type header. More important, you can
now attach this information to any content-type header; it is now recognizable
as such, can be removed from any content-type before other parts are used; it
can be attached willy-nilly to any content-type regardless of its validity in
association with that type.
In other words, you've invented syntax for putting one header inside of
another. (Look at it this way -- you can map the separate header syntax into
your new syntax and back with no loss of information. This means that they are
semantically equivalent.)
You have taken the semantic goal that I (and some of the other people
in Atlanta) wanted and you have forced it into the syntax that people on the
list want. But the underlying change in semantics remains, and that is not
going to make the people who object to this change happy.
On the basis of preferred syntax alone, I would argue that this violates the
simplicity principle. We have a way to represent distinguished semantic
entities -- it is called a header line. Inventing another syntax just to hide a
header line makes things more complex syntactically and that's all -- and while
syntactic complexity is much better than semantic complexity, it is still a
non-goal to have more of it than we need.
No, I think we need to come to grips with the semantic problem here, and not
worry about the syntax until later. I don't really care what the syntax ends up
being -- what I want is the ability to be able to distinguish character set
information for subtypes that I've never heard of (subject to having a
reasonable top-level type, of course).
Ned