Do we need to pre-define every possible combination that people will use?
Not if we define things as "building blocks". Thus, for example, we
don't need to define anything special about compression headers if we
have a compressed-message content-type, because all the other mechanisms
can then work on it recursively. Similarly for encrypted messages. It
seems to me that this is a simple and elegant solution that avoids
making the headers even more complex than they already are..
But if we take this mechanism to extremes, we really don't need
Content-Encoding at all, as we can keep on recursively applying decoding
mechanisms. I feel that "compressed" should be another
Content-Encoding, rather than part of the Content-Type.
But what if we want to compress *and* base64 it? Are you suggesting:
Content-Encoding: base64, compress
I agree with Nathaniel that it might be more elegant to recursively
apply RFC-XXXX rules. E.g. at the outermost level you might have:
Body-Type: base64
Then, when you decode the *body*, you end up with another RFC-XXXX
format message, whose header might include:
Body-Type: compress
Next, when you uncompress the *body* of this message, you end up with
yet another RFC-XXXX format message, whose header might include:
Body-Type: tar
I would think that it is not necessary to have two separate headers
like Content-Type and Content-Encoding. We can do this with one header
called Body-Type. I gave it a new name so that it doesn't collide with
existing implementations of Content-Type such as Erik Fair's and
AT&T's. Maybe we don't need to give it a new name...
Another way of doing this would be something like:
Body-Type: base64, compress, tar
but then we would need a way of combining certain orthogonal types
such as TeX and Latin-1:
Body-Type: base64, compress, TeX/Latin-1
If we use the recursive method, we can separate the orthogonal types:
Body-Type: TeX
Codeset: Latin-1
Comments?
Erik