Excerpts from mail: 26-Apr-91 Re: multiple Content-Encodi.. Greg
Vaudreuil(_at_)NRI(_dot_)Resto (647)
I think I understand, After all these notes.....
Content-type: What this thing is...
Yes...
Content-Encoding: What you did to it to get it here....
Yes... ("here" = "in this format")
Content-conversion: What I did to make the transport conveniet.
No... :-)
I proposed the Third header as a compromise between those who want to
load up the content-encoding (I oppose because it make automated UA's
hard) and recursive content-types (I'm not sure this solves the problem,
and it is a real pain for old fashioned users).
Now you've managed to press ALL my buttons :-) I'm pretty darned sure
that recursive content-types do solve the problem: I have yet to hear
any examples of how they don't. And I can't even *begin* to understand
the "old-fashioned users" comment. I mean, if what you're talking about
is what happens with existing UA's, let's face it, NONE of these schemes
are going to produce something readable. If you compress the message,
it doesn't matter whether the compression is done by
1. Content-type: compressed-encapsulated-message
2. Content-Encoding: compressed
3. Content-Encoding: base64, compressed
4. Content-conversion: compressed
It just doesn't matter -- NO UA will be able to make it look nice unless
it understands the standard we're defining.
If recursive content-types don't solve the problem, tell me what they
don't solve. If they cause a problem for people who still like
listening to Beatles' albums (a reasonable definition of "old-fashioned
people"), tell me why. I just don't see the problem!
I have no particular objection to Content-Conversion beyond the fact
that it strikes me as totally unnecessary! That's what I need to be
convinced about.
Feeling Just a Tad Frustrated,
A Still Old-Fashioned Nathaniel
with the "Help" CD playing at this moment