Because data of type "message" may never be encoded in base64 or
   quoted-printable, a problem might arise if "message/partial" entities
   are constructed in an environment that supports binary or 8bit
   transport.  The problem is that the binary data would be split into
   multiple "message/partial" messages, each of them requiring binary
   transport.  If such messages were encountered at a gateway into a
   7bit transport environment, there would be no way to properly encode
   them for the 7bit world, aside from waiting for all of the fragments,
   reassembling the inner message, and then encoding the reassembled
   data in base64 or quoted-printable.  Since it is possible that
   different fragments might go through different gateways, even this is
   not an acceptable solution.  For this reason, it is specified that
   entities of type "message/partial" must always have a content-
   transfer-encoding of 7bit (the default).  In particular, even in
   environments that support binary or 8bit transport, the use of a
   content- transfer-encoding of "8bit" or "binary" is explicitly
   prohibited for MIME entities of type "message/partial". This in turn
   implies that the inner message must not use "8bit" or "binary"
   encoding.







 
RFC 2046                      Media Types                  November 1996


   Because some message transfer agents may choose to automatically
   fragment large messages, and because such agents may use very
   different fragmentation thresholds, it is possible that the pieces of
   a partial message, upon reassembly, may prove themselves to comprise
   a partial message.  This is explicitly permitted.

   Three parameters must be specified in the Content-Type field of type
   "message/partial":  The first, "id", is a unique identifier, as close
   to a world-unique identifier as possible, to be used to match the
   fragments together. (In general, the identifier is essentially a
   message-id; if placed in double quotes, it can be ANY message-id, in
   accordance with the BNF for "parameter" given in RFC 2045.)  The
   second, "number", an integer, is the fragment number, which indicates
   where this fragment fits into the sequence of fragments.  The third,
   "total", another integer, is the total number of fragments.  This
   third subfield is required on the final fragment, and is optional
   (though encouraged) on the earlier fragments.  Note also that these
   parameters may be given in any order.

   Thus, the second piece of a 3-piece message may have either of the
   following header fields:

     Content-Type: Message/Partial; number=2; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

     Content-Type: Message/Partial;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
                   number=2

   But the third piece MUST specify the total number of fragments:

     Content-Type: Message/Partial; number=3; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

   Note that fragment numbering begins with 1, not 0.

   When the fragments of an entity broken up in this manner are put
   together, the result is always a complete MIME entity, which may have
   its own Content-Type header field, and thus may contain any other
   data type.

5.2.2.1.  Message Fragmentation and Reassembly

   The semantics of a reassembled partial message must be those of the
   "inner" message, rather than of a message containing the inner
   message.  This makes it possible, for example, to send a large audio
   message as several partial messages, and still have it appear to the
   recipient as a simple audio message rather than as an encapsulated




 
RFC 2046                      Media Types                  November 1996


   message containing an audio message.  That is, the encapsulation of
   the message is considered to be "transparent".

   When generating and reassembling the pieces of a "message/partial"
   message, the headers of the encapsulated message must be merged with
   the headers of the enclosing entities.  In this process the following
   rules must be observed:

    (1)   Fragmentation agents must split messages at line
          boundaries only. This restriction is imposed because
          splits at points other than the ends of lines in turn
          depends on message transports being able to preserve
          the semantics of messages that don't end with a CRLF
          sequence. Many transports are incapable of preserving