Quoteing ned+ietf-822(_at_)mrochek(_dot_)com, on Sat, Apr 06, 2002 at
06:13:17PM -0800:
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.
Well, I have to disagree. Given that you must pass content through a content
decoder (base64,qp,etc.), passing content through a decompression library as
well is pretty trivial.
Correctly transmitting non-ascii text in headers is harder, IMO.
What was supposed to be hard?
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.
Describe them. These "grotesque" operational results are current practice.
Ignoring this information is the same as not sending it, and right now it
isn't sent. Instead, compressed data is sent as application/compression-algo,
it is decompressed on the other side, and people then try and guess what the
stuff is.
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.
Huh? I described existing practice.
The content IS x-zip-compressed, as required by 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
Perhaps getting into them might describe why the ball was dropped.
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.
Well, it looks like two, and only two, to me.
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.
Sure, I could live with a compressed CTE. I could even live with your
favorite algorithm (hopefully, so can everybody else, or do we need
one CTE per algorithm? yuck.).
Btw, that compressed data, how is it encoded? base64, likely. It seems we'll
be wrapping two encodings into a single token. Weird, but if it gets
the job done, fine.
Of course, this means that a CTE which is base64 gzipped data will get
treated as binary by MUAs that don't understand this CTE. So it'll
either get passed to the application that handles that content-type,
which will choke, or it will get saved as a b64 blob, and they won't
be able to do anything with it. Seems grotesque to me.
I'm more convinced that an "encapsualates" parameter is nice, it degrades
to the current situation, as opposed to degrading to useless.
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.
Well, your kind words aside, MUAs already handle zip and pdf, I fail to
see why handling them sequentially would be such a problem for us.
I'm beginning to wonder if this wasn't dealt with in MIME because
nobody could agree where to put it.
Sam
--
Sam Roberts <sroberts(_at_)uniserve(_dot_)com> (Vivez sans temps mort!)