Well,
This is getting messy again.
An obvious simplification would be to say that multipart messages can't
be encoded; only their subparts can be encoded. Kind of elegant,
actually. Because really, if we're talking about a transport-encoding,
it is something you only need to do ONCE, no more.
The whole purpose of multiple transport-encoding types was to
allow the selection of an effecient encoding for each type of data,
ie, text-hex for text-like data, and base 64 for bitmaps and other
evenly distributed binary data. Having a single encoding type for the
message defeates some of this functionality.
Say I am using the current 7 bit SMTP. I send a two part
message. Hey joe, below is the new logo for the internet engineering
task force. What do you think. Now Imagin I wrote the text in a
language (Char set) for which i need to encode the data. Should I
allow this to be in a readable encoding type or should I require that
the text part of the message also be encoded in Base 64.
This problem is not helped by nexted messages. If I forwarded
the message addressed to Joe to Phill, should the entire message be
encoded in base 64?
I'm simply arguing that transport-encoding is still needed on
a per-part basis. Furthermore, if this information is included in the
content-type field, it is more difficult to parse to translate from,
say, a Binary domain to a 7 bit domain.
I think the above proposal should satisfy everyone except the people who
really want nested transformations (the content-conversion school of
thought). I believe, though, that there's nothing here to stop them
doing that via a mechanism external to this RFC. So this proposal might
actually be a way out of some of our wrangling. What do people think?
Pardon my head banging, but I have a few thoughts over this
external-to-the-standard stuff. To start, I want to see this document
be a "complete" specification. It should include all that is needed
to build an implementation. Pushing content-conversion arguments into
a separate "experimental" rfc is tanamout to rejecting the idea.
While this is a valid outcome, the choice should be made explicitly.
Now to a more partisan point. It cannot be said at this point which
is "better", content-conversion or recursive messages for the purpose
of multiple transformations on a particular part. No one has
presented efficiency or ease of programming arguments. As far as I'm
concerned, they both are valid, current engineering choices. If study
is needed to make a good decision, I challenge the proponents of the
options to do some quantitative study, and implementation. Lets not
make an arbitrary decision to push one idea out.
Now some thoughts on the recursive encoding type. This as I
understand is content-type: multi-part imbeded in a multi-part
document. This has all kind of advantages, the greatest one for me is
the forwarding and replying to other multi-part messages. It may also
be useful for grouping like parts together for effeciency, or for
sequencing a serial-parallel message. (show the following in order.
1) intro, 2) the graph and the voice explanation together, and 3) the
conclusion.
The one use of recursive messages I do not see as being useful
is for the compress-tar-uuencode case. Let me argue that encapsulated
message is redundant with the content-type: Multipart, where
Multiparts are nested. Further, recusrsion is not a user-friendly
concept. As it has been stated, and I think finally accepted, that
there is no way to identify the end data type in the recursive
message.
Now, to toot the Content-conversion horn, I argue that
content-type should be as simple as possible. I'd much rather see a
new line in the message than to see something that looks so horrible
as:
content-type: word_perfect /ascii (compress) 5.1, laserwriter
transport-encoding: uuencode
Where ascii is required but implied by the package, and the
conversion scheme is deeply imbeded in the type line such that parsing
is a pain and construction by a gateway is subject to lots of
mangling.
ADMINISTRIVIA
-------------
Has anyone seen a reasonable way to conduct a survey by email? How
can I get a sense of the group in terms of this nested encoding vs
recursion issue?
Greg V.