Re: RFC 934 for multipart encoding

[Nathaniel Borenstein <nsb@xxxxxxxxxxxxxxxxxxxx>]

I think that body parts should be totally recursive in this scheme; the
worst thing is the quoting situation, where an N-level encapsulation
might have lines that look like this:

- - - - - - - - -at last the real line starting with "-"

This kind of nesting/recursion only applies, of course, when the
encapsulated body part is also of type "multipart" or whatever we call
it.  That is, the message has several parts, one of which is a multipart
message of several parts, etc.   I think that it is important that we
support this kind of nesting if we want forwarding and excerpting to
work gracefully.

I think it is indeed safe to assume that we could define a body-part
(RFC 1049 Content-type) for each of the character sets of interest. 
Each of them could, in fact, devise their own 7 bit encoding -- that is,
they wouldn't have to use the same scheme used by the encapsulation body
part, but could use a scheme that is more efficient for the particular
character set.  The general scheme for representing 8 bit data only
needs to be applied when the object being encapsulated is not yet in a 7
bit representation.

Excerpts from mail: 24-Feb-91 Re: RFC 934 for multipart e.. Einar
Stefferud@ics.uci. (1169)

> I expect we should also define one for each X.400 defined BodyPart, and
> make provision to handle ASN.1 objects as ASN.1 BodyParts which use ISO
> Object Identifiers to secify the content types.  What is the right way
> to do this?

I can't really comment much on this -- I agree that we probably want to
match all the X.400 BodyParts, but I'm not the person to define the 7
bit encodings, etc. for each of them.

> It seems to me that if we can do all this mapping, then we will have
> really done comething truly important toward moving the whole global
> situation toward a multi-media future, without breaking what we have.

Yes, and the really important thing is that absolutely nobody, as far as
I can tell, needs to be "dragged along kicking and screaming" -- MTA's
don't need to change, and users are free to use existing unmodified UA's
for as long as they're satisfied with the functionality they're getting
(i.e. as long as they don't feel an urge to send or receive multipart
multimedia mail).  I think this backward compatibility is what makes the
scheme plausible.  -- Nathaniel