Greg,
It seems to me that one can agree with your history and agree with 99%
of your analysis, and reach a slightly different conclusion with
different implications. What follows should be taken as a
counterexample, not a proposal.
Let's assume the following from your discussion and the logic that leads
to them: (i) Content-transfer-encoding is the right place to put
"this". (ii) A MIME reader, given an unrecognized C-T-E, is going to
lose mail [I think that is a slight overstatement, see below].
Then
C-T-E: Unrecognized-string
is a bogon until we define it. When we define it, we can impose almost
any rules about its interpretation that make engineering-sense, without
doing violence to the MIME architecture.
That means that, independent of other issues, nothing in your history or
logic provides an appreciably stronger case for
C-T-E: Compressed-base64 and, presumably,
C-T-E: Compressed-binary
than for
C-T-E: Compressed; algorithm=foo; representation=bar
since we can require that "Compressed" not be supplied or interpreted
without "algorithm" and "representation", and we can, if desirable, make
the same "standards-track" and "RFC" rules about new instances of
"algorithm" and/or "representation" that we do about new C-T-Es.
Now there is an argument for the first. It has been made before, but,
to summarize, "the second just opens us up to temptations for
expandability, options, and profiles that we won't/ shouldn't use". And
therefore we had better not go down that path unless we have some clear
examples and a clear model. I contend that we may have both (!). I
also contend that it is very much in IETF's interest to provide standard
ways of doing some local-environment things: even if they are perceived
of as stupid in the general case, the ability to understand what they
are aids in interoperability.
In particular, if the C-T-E, Content-type, or whatever aren't
recognized, we don't expect mail to be lost. We expect things to be
dumped on the user with "here, you try to understand this
incomprehensible stuff". Users who are sufficiently motivated will
cope, by only if we provide them with sufficient clues. A
clue-structure aids interoperability, even if "no options" is lots
better.
Sketch of model (again, above assumptions):
We've heard exactly two stories for transporting compressed "stuff": an
SMTP-like mail story and a "true binary transport one". The first of
these appears to be a base64 story: the "8bitMIME" extension doesn't
change that, since we still have line length issues and the "special
encodings for binary over 8bitMIME" proposals seem to have died. And we
have two kinds of algorithm-candidates: something universal and good
enough (what it should be is part of a different discussion) and "other
things".
Flimsy-plastic-proposal: Define, e.g.,
Content-transfer-encoding: Compressed-mail; compressed-with=lz77
and
Content-transfer-encoding: Compressed-binary; compressed-with=lz77;
presentation=???
Rules: Compressed-mail implies presentation=base64. There are no other
standard cases. To interpret C-T-E = Compressed- anything, you must be
able to interpret, understand, and process, all parameters. For
conformant use in Internet mail, new compression methods require
standards track RFCs, as do new presentations. For the moment,
Compressed-binary is not defined over SMTP (821 or extended): it is just
a stub. It is worth defining because we really don't want Neil to hang
his "internal" arrangements off an arbitrary construct--we want to agree
on enough framework with him that, when things leak, we have hope of
tracking down the problem. I'd rather talk him out of doing it at all,
but that is a lost cause (for good and sufficient reasons).
Note that, with these definitions, your strawman and Encoded-mail are
semantically identical until someone defines and standardizes a new
compression method. The difference is that, when that happens, I'd much
rather hear from a user that there is a problem with an unknown
compression method called "bozo" than that there is a message with C-T-E
"foobar". The former tells me what keywords to use when I go try to
find an expander/decoder, anyway.
And, if we are going to have x-comprsssion-method -- as I'm sure we will
-- I think the community is better served by having it identified as a
compression method, rather than as a general obscurity.
john