Re: message/partial and rfc-822

[Justin Ziegler <[e-mail]>]

 
> Granted that message/partial isn't going to work very well
> with a gateway.  But maybe this is a limitation of X.400 

> in not being able to convey very large objects. 
> It just
> depends on how you look at it.  (yes I know it's not an
> inherent limitation of X.400...but X.400 MTAs don't 
> necessarily have more disk space, and the transmission 
> lines aren't necessarily any faster, than their Internet
> counterparts.)
> 
> Keith Moore


The limitation you are speaking of applies for all mailing systems, not only
for X400. In any case, before *that* becomes a problem the gatewaying process
is stoped by other problems that would also stop any gatewaying:

	If one decides to wait for all the pieces, and reassemble them,
one can wait for a long time. One can not be sure that all the pieces will
go through the same gateway. in France for instance there are two gateways
from X400 to internet. Depending on what is in the message/partial (imagine
it includes a multipart or a message/rfc822) parsing the various
pieces pieces separatly can be impossible. This occurs of course if one
wants to do total gatewaying, in which case a nested multipart in a
message/partial must be opened up and set into equivalent X400 body parts.
Moreover, if the message/partial is multipart, and one of the body parts
is a message/rfc822, the header and contents of that double nested
message/rfc822 *must* be gatewayed. The header conversion problem also
occurs when gatewaying between similar but identical messaging systems ie
the english back to front addresses.

	Thus the problems of gatewaying message/partial are general and in no
way restricted to X400. Even if message/partial stays in its own world it
creates problems. Quote from RFC1521:

  2281     Note on encoding of MIME entities encapsulated inside message/partial
  2282     entities: Because data of type "message" may never be encoded in
  2283     base64 or quoted-printable, a problem might arise if message/partial
  2284     entities are constructed in an environment that supports binary or
  2285     8-bit transport.  The problem is that the binary data would be split
  2286     into multiple message/partial objects, each of them requiring binary
  2287     transport.  If such objects were encountered at a gateway into a 7-
  2288     bit transport environment, there would be no way to properly encode
  2289     them for the 7-bit world, aside from waiting for all of the parts,
  2290     reassembling the message, and then encoding the reassembled data in
  2291     base64 or quoted-printable.  Since it is possible that different
  2292     parts might go through different gateways, even this is not an
  2293     acceptable solution.  For this reason, it is specified that MIME
  2294     entities of type message/partial must always have a content-
  2303     transfer-encoding of 7-bit (the default).  In particular, even in
  2304     environments that support binary or 8-bit transport, the use of a
  2305     content-transfer-encoding of "8bit" or "binary" is explicitly
  2306     prohibited for entities of type message/partial.

The problem that message/partial (and also content-encoding) solve should
be solved at a much lower level. however, I dare say its not to difficult to
get one's head around gatewaying content-encoding.


Justin