INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             July 2001

6.21.2.1. Message/partial

6.21.2.1.  Message/partial
   The Content-Type "message/partial" MAY be used to split a long news
   article into several smaller ones.

        NOTE: This Content-Type is not recommended for textual articles
        because the Content-Type, and in particular the charset, of the
        complete article cannot be determined by examination of the
        second and subsequent parts, and hence it is not possible to
        read them as separate articles (except when they are written in
        pure US-ASCII). Moreover, for full compliance with [RFC 2046] it
        would be necessary to use the "quoted-printable" encoding to
        ensure the material was 7bit-safe.  In any case, breaking such
        long texts into several parts is usually unnecessary, since
        modern transport agents should have no difficulty in handling
        articles of arbitrary length.

        On the other hand, "message/partial" may be useful for binaries
        of excessive length, since reading of the individual parts on
        their own is not required and they would in any case be encoded
        in a manner that was 7bit-safe.

   IF this Content-Type is used, then the "id" parameter SHOULD be in
   the form of a unique message identifier (but different from that in
   the Message-ID header of any of the parts). The second and subsequent
   parts SHOULD contain References headers referring to all the previous
   parts, thus enabling reading agents with threading capabilities to
   present them in the correct order. Reading agents MAY then provide a
   facility to recombine the parts into a single article (but this
   standard does not require them to do so).

Diffs to previous draft

--- {draft-04}	Wed Jul 11 21:55:54 2001
+++ {draft-05}	Wed Jul 11 21:55:54 2001
@@ -1,17 +1,30 @@
-
6.21.3.1.  Message/partial
+
6.21.2.1.  Message/partial
    The Content-Type "message/partial" MAY be used to split a long news
-   article into several smaller ones, but this usage is discouraged on
-   the grounds that modern transport agents should have no difficulty in
-   handling articles of arbitrary length.
+   article into several smaller ones.
 
-   However, IF this feature is used, then the "id" parameter SHOULD be
-   in the form of a unique message identifier (but different from that
-   in the Message-ID header of any of the parts).  Contrary to the
-   requirements specified in [RFC 2046], the Transfer-Encoding SHOULD be
-   set to "8bit" at least in each part that requires it. The second and
-   subsequent parts SHOULD contain References headers referring to all
-   the previous parts, thus enabling reading agents with threading
-   capabilities to present them in the correct order. Reading agents MAY
-   then provide a facility to recombine the parts into a single article
-   (but this standard does not require them to do so).
+        NOTE: This Content-Type is not recommended for textual articles
+        because the Content-Type, and in particular the charset, of the
+        complete article cannot be determined by examination of the
+        second and subsequent parts, and hence it is not possible to
+        read them as separate articles (except when they are written in
+        pure US-ASCII). Moreover, for full compliance with [RFC 2046] it
+        would be necessary to use the "quoted-printable" encoding to
+        ensure the material was 7bit-safe.  In any case, breaking such
+        long texts into several parts is usually unnecessary, since
+        modern transport agents should have no difficulty in handling
+        articles of arbitrary length.
+
+        On the other hand, "message/partial" may be useful for binaries
+        of excessive length, since reading of the individual parts on
+        their own is not required and they would in any case be encoded
+        in a manner that was 7bit-safe.
+
+   IF this Content-Type is used, then the "id" parameter SHOULD be in
+   the form of a unique message identifier (but different from that in
+   the Message-ID header of any of the parts). The second and subsequent
+   parts SHOULD contain References headers referring to all the previous
+   parts, thus enabling reading agents with threading capabilities to
+   present them in the correct order. Reading agents MAY then provide a
+   facility to recombine the parts into a single article (but this
+   standard does not require them to do so).