I've always been in favor of specifying what encoding can be applied to
a given content-type. Or perhaps it is better to specify what encodings cannot
be applied... And I've always seen the need for more than one level of encoding
(my original proposal was for the content-encoding field to be a list of the
encodings that get applied, but I got overruled on this).
I also never liked recursive application of encodings, since I want to
be able to know what's in my message before I spend time processing it.
(I debated this at some length with Dave Crocker offline, and I thought
Nathaniel got copies of this, but I may have screwed up on that.)
So all this stuff makes sense to me; I'm for it.
However, I'm a little uncomfortable with the proposed changes to the headers.
I liked the separation of encoding information from content. I want my MTA
to be able to do the decoding on final delivery to the UA. (I realize that this
model is not what UNIX systems would likely use, but I'm not using a UNIX
system.) This seems attractive from the standpoint of writing the decoder
only once while allowing for lots of different UAs with support for various
different content-types.
Sure, there's no problem with having the MTA separate out the encoding
information from the content-type header. But the separation of the
information is sort of a visual cue that says how things are split up.
The user only needs to be concerned with what's in the content-type; the
encoding has already been taken care of. I can also see reasons for having
MTAs do reencoding of messages, but I don't think MTAs should generally
be fooling around with the content-type (unless serious gatewaying work is
being done, and perhaps not even then).
So if everyone else wants to fold the information into the content-type
header, I'll go along. I'm just a little uncomfortable with it, that's
all.
Finally, I'm totally opposed to Nathaniel's new syntax. RFC822 comments _must_
_not_ be used to convey information that's vital to transport and delivery.
According to RFC822, comments may appear anywhere in a structured header
line, and must be ignored. The encoding must be specified in some way other
than a comment field. We'll get into serious trouble if we use comments in
this way. Besides, there are lots of other ways to encapsulate this
information, if it needs to appear on the content-type line.
Ned