Ned writes:
That having been said, I have a suggestion for a syntax that I'd like to
propose. I'm a little leery of putting magic cookies into the subtype
itself to distinguish it. Instead, how about simply repeating the / before
a character set specification? You'd then have something like:
Content-Type: text//us-ascii
Content-Type: text-plus/TeX//us-ascii
Simply convert the double // to / to treat the character set as part of the
type/subtype string (if that's the view you have of the world, which may
indeed be valid for some applications). Extract the //whatever completely
if you want to remove character set information completely.
We could also insist that the character set appear last, although this is
by no means mandatory.
Comments?
well, I would prefer that the charset info always was specified
in the contenet-charset header. Having it more places complicates
things, what if it is specified both places? Which takes precedence?
And then I prefer the simple syntactical solution, excatly for the
reasons Ned also has given: it simplifies things that you do not have
to make new parsing code.
Allowing charset only in the content-charset header eliminates the need
for specialities like // meaning just / - or giving up the fixed
positions and saying charset is the last field on the first parameter
of the content-type header.
And the Atlanta decision was to move the charset specification from
the content-type header to the content-charset header.
Let's stick to that, folks!
Keld