Has this been proposed? It seems a parameter to the
content-transfer-encoding
would be handy. I'm sure I'm not the only one who has wondered why we
have to call things application/pick-your-compression-format instead
of application/tar, as it should be.
It was proposed over a decade ago. It was rejected then because it was felt
to be too complex.
Really? There seems to be much more complex parts of MIME. Oh well.
I have to disagree. The complexity implied by a parameterized CTE is
in practice pretty large; there is nothing in the core MIME capabilities
that is comparable.
But it would also change the syntax of the header, as CTE (the header)
currently doesn't allow parameters.
What about a list of cte's (then better dubbed
"content-transfer-transformations") to be applied in the format
innermostCTE+...+outermostCTE
(or vice versa), so you could say
C.-T.-E: gzip+base64
meaning "first remove base64 encoding, then gunzip". The + here is chosen
for
being not tspecial (the cte identifier is a "token") and suggestive of "and"
and of the "+xml" convention (rfc3023).
A legacy agent would parse the cte name to be the full "gzip+base64" and get
an unknown cte, much like when plain "gzip" would be used.
Right, so most agents in existence would just choke, since they "know"
all the possible CTEs. So, this is syntactically backwards compatible,
but won't degrade gracefully.
The MIME specifications specifically says how to deal with an unknown CTE. They
degrade as gracefully as anything like this could. A syntactically incompatible
change, on the other hand, is by definition outside the scope of the standard.
Implementations could potentially handle this is all sorts of ways, some of
them pretty horrendous operationally.
Not that I think this will go anywhere, but what about adding a parameter
to Content-Type. It accepts parameters already, and I hope that most
implementations would just ignore any parameters it didn't support.
But that's precisely the problem: You don't want something that completely
alters the way the content is interpreted to be ignored. The possible
operational results are nothing short of grotesque.
This is the same reason you cannot just define a content-compression field,
or content-disposition parameter, or anything else, to do this.
Doing:
content-type: application/tar; compression=gzip
would be fairly accurate, but if a MUA didn't support the compression
parameter it would think that the part was application/tar, but tar
would choke on it.
Exactly.
On the other hand, you could do:
content-type: application/x-gunzip; encapsulates=application/tar
or:
application-type: application/x-zip-compressed; encapsulates=application/pdf
And now you've violated the MIME concept that the content type and subtype
actually describe the content in some useful way. That's not acceptable
either; in fact it is quite specifically prohibited; see RFC 2048 section
2.2.1.
Look, this stuff was all thought out in detail more than a decade back. For
various reasons that we need not get into defining a compressed CTE wasn't a
viable option at the time. But we all knew it needed to be something that MIME
could accomodate. But a multiplicity of ways of doing it was felt to be a bad
idea. So MIME was designed so that there is one, and only one, place this fits:
One or more CTEs.
Now, we could retroactivaly impose some structure on CTE names that fit within
the current syntax, but it seems somewhat pointless to do so: Combinations like
gzip-quoted-printable, or worse gzip-8bit, aren't useful. All this does is
raise the bar for implementations. Let's just define a couple of compressed
CTEs and be done with it.
Hopefully, a MUA could handle it as a zip file, and be right, or
it could lookup how to unwrap it in mailcap, then handle it as PDF,
which would be more right.
Dream on.
Ned