Date: Fri, 26 Apr 1991 12:00:46 -0400 (EDT)
From: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
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.
OK. I'll take a turn at bat :->
To briefly restate what I see as the various positions:
1. people agree that "content-type" is needed, and represents
the type of the body part
2. people agree that there needs to be a "transport-encoding"
transformation to render a body part suitable for seven bit
transports such as SMTP, and that it is reasonable to put
this in the body-part header. People also agree to insisting
that all message recipients understand all the standard transport
encodings, where "all" is some suitably small number like two.
3. there are two camps with respect to doing other, optional
encodings like compression encodings. One camp notes that
this is just another filter to apply like the transport
encoding and should be combined with that header. The other
camp is trying desperately to keep the transport encoding
header simple, and suggests recursively encoding the messages
with each encoding.
4. our esteemed chair suggested a compromise, which separates
the transport encoding header from the "filter" header.
My personal opinion is that I really like the idea of keeping
the transport encoding concept separate from all the other filters.
I even suggest that we change its name to "transport-encoding".
It is really different from the other encodings, because the
"no-encoding" situation is represented by three different
names (8bit, 7bit, and binary); this is different from
all the other filters.
I also want to make sure that it is trival to build a 8 bit or binary
to 7 bit gateway, in case the ietf-smtp group ever reaches consensus
on a new transport.
However, I have a lot of trouble supporting Nathaniel's proposal of
recursive encodings. Here is my biggest problem with it: there is
no way, short of reversing the filter, to see what is on the inside
of the encapsulated message -- instead I have to uncompress the
entire package so I can read the actual type of the body part!
To me, this is a severe disadvantage. I'ld like to be "lazy"
in my decompression of the body part, and not do it until the user
has actually expressed an interest in seeing that body part.
But, I need to know the type upon receipt, in order to do
selective filtering on the message, and when displaying the
message header to the user. Therefore I'ld like all that information
available at the "top level" of the message, instead of encapsuled
"n" levels deep.
I believe that the "concatenated filter" proposal handles this
need admirably...
Neil