I agree that the SYNTAX of a cascaded content-encoding header is not
problematic. The semantics are even pretty clear, too. The
implementation, though more complex than the simple content-encoding
field, is also not beyond most programmers' abilities.
Ok, good.. ;-)
What I don't
see, however, is why the cascading is necessary. If it isn't necessary,
the fact that it isn't too terribly complex is irrelevant -- it's still
unnecessary!
My general policy is to not cause things to be limited. But you
have to be careful to keep things from being complicated, or
hard to implement, etc.
As for *needing* the multiple encodings .. I admit to not having
any particular plan (right now) for use of multiple encodings.
It may well be the sort of thing like "Nobody will ever need
more than 64K of memory". That is, it may burn us later on.
There is a convention used for file naming where things like
file.tar
file.tar.Z
file.tar.Z.uu
file.tar.Z.uu.xaa
file.tar.Z.uu.xab
file.tar.Z.uu.xac
all make sense. This is what I intend to do with multiple
content-encodings.
I did come up with a couple after a few moments thought. First,
of course, is
Content-Type: audio u-law
Content-Encoding: uuencode, compress
Proposal: List the most recent encoding first in the list and
the first encoding last in the list.
Suppose you're on a system with record-oriented files. Since I'm at
TWG that means: VMS. RMS files aren't streams of bytes. The draft-RFC
talks about encodings as if they are encoding byte-streams. So to
successfully encode an RMS file the record attributes, and all sorts
of what-not which I don't care to understand, must be turned
into a byte stream.
Content-Type: X-DEC-RMS
Content-Encoding: uuencode, compress, X-DEC-RMS-TO-STREAM
Suppose I'm a nervous nelly and don't trust that the MTA's will
in fact reliably deliver bytes.
Content-Type: text/MAILASCII
Content-Encoding: uuencode, compress, X-Checksum-Encapsulation
Or
Content-Type: X-DEC-RMS
Content-Encoding: uuencode, compress, X-Checksum-Encapsulate,
X-DEC-RMS-TO-STREAM
Suppose the file is larger than is convenient or conventional
to send through mail. (Sendmail tends to bounce >100,000 byte msgs)
Content-Type: X-shar
Content-Encoding: split part-001, uuencode, compress
Content-Type: X-shar
Content-Encoding: split part-002, uuencode, compress
Content-Type: X-shar
Content-Encoding: split part-003, uuencode, compress
(X-shar meaning "shell archive") The UA could ask
This message is a bit large, would you like to
split it between multiple messages?
And on reception
Hmm.. we seem to be missing part-002 of this message.
David