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.
No they are not. There is currently no practice where a content-type
is sent saying something is of some type or other but a parameter happens
to add that oh by the way the content is compressed. The results of doing
this would likely include crashing applications all over the place.
Now, you may claim that applications should be robust against this sort
of thing. I agree. But they aren't. And this isn't likely to change.
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.
That's an entirely different proposition. Sending something that happens
to be compressed with an unregistered content type nobody understands
is not the same as tacking on a compression parameter. And you yourself
have just described the problem with this approach.
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.
People violate the standards all the time. Just because they do so doesn't
mean it works well, is a good idea, or is commonplace. In this case it is
none of the three.
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.
Sorry. You'll have to find someone else to try and summarize many megabytes
of mail sent over a decade ago. I have better things to do with my time.
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.).
Then why are you arguing that it must be done some other way? It is exactly
this sort of thing that leads to nothing being done every time this comes
up -- arguments like this one exhaust everyone so no documents get produced.
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.
Well, the one obvious thing to do is define an efficient 8bit encoding. This
has been discussed in another thread. But yes, I agree a 7bit one is probably
also useful. However, we could make some progress in that space by moving to
base85. I believe the EBCDIC transport issues that drove the base64 choice are
well and truly gone by now.
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.
That's not what the standards say must be done. Anything with an unrecognized
CTE has to be treated as data of an unknown type. Any implementation that fails
to do so is seriously incompliant with the MIME specification.
I'm more convinced that an "encapsualates" parameter is nice, it degrades
to the current situation, as opposed to degrading to useless.
I've already explained why this is a nonstarter. I won't bother to repeat it.
And I'm going to heed my own often-given advice now and stop discussing this
over-discussed issue now.
Ned