Will that really satisfy the people who want a wider notion for
Content-Encoding?
Hmm.. pretty close but lets see if I understand the proposal right.
Transfer-Encoding: is to take on the meaning which Content-Encoding:
has in your strawman RFC?
This much is good.
Does Content-Encoding: then take on the meaning which I have suggested?
Should I write up a proposed format on that? (If so it will have to
wait at least a week because I have a vacation which starts tomorrow).
Is Transfer-Encoding: exclusive to Content-Encoding:?
As for recursively encoded contents ... I see that it allows for all
which I suggested. I still do not like it, because it is more trouble
to deal with. Not just for crusty old timers who still use `mh' at
command-line (e.g. me) (Well, so I might not be crusty..), but also
for the fancy-schmancy UAs which can automatically decode all that. (As
I understand it) In order to find the ultimate type of the object you
have to dig apart all the Encoding:'s in order to see it. This makes
harder one of my objectives. Namely to display a list of icons below
the message header, one for each body part, and have the icon reflect
explicitly what the object is.
I'd hate to see it become the sticking
point that prevents binary mail from becoming a "standard" part of the
internet infrastructure.
In fact, I agree with this statement. I seriously want to be able to
send complicated messages around with all sorts of funny looking
contents. But my suggestion isn't to add a kazillion different
encodings, but simply a way to synergistically string them together in
fun and interesting combinations. (And to add a couple: compress,
encrypt, and uuencode. "compress" and "encrypt" will need more definition)
-----------------------
Just read your latest note Natheniel (lunch was between the above
and now) and agree that Greg's compromise is a good one. It would
be good if the RFC mentioned which agent (originating UA, or intervening
gateway MTAs) is generally responsible for Content-{Encoding,Conversion}:
but simply punt on defining Content-conversion for now
Not completely.. specify the general form (comma-seperated list
with semantics on the order of presentation). But punt on what
you can put in each member of this list.
David