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

6.21.2.4. Multipart types

6.21.2.4.  Multipart types
   The Content-Types "multipart/mixed", "multipart/parallel" and
   "multipart/signed" may be used freely in news articles.  However,
   except where policy or custom so allows, the Content-Type:
   "multipart/alternative" SHOULD NOT be used, on account of the extra
   bandwidth consumed and the difficulty of quoting in followups, but
   reading agents MUST accept it.

   The Content-Type: "multipart/digest" is commended for any article
   composed of multiple messages more conveniently viewed as separate
   entities, thus enabling reading agents to move rapidly between them.
   The "boundary" should be composed of 28 hyphens (US-ASCII 45) (which
   makes each boundary delimiter 30 hyphens, or 32 for the final one) so
   as to enable reading agents which currently support the digest usage
   described in [RFC 1153] to continue to operate correctly.
[Actually, this conflicts with some present digest usage (such as the
news.answers rules), but should still be the right way to go. There
remains the possibility that future MIME-compliant readers could enable
one to proceed directly to some particular message by clicking on it in
a table of contents, but that feature is not yet supported by the
current MIME standards.]

        NOTE: The various recomendations given above regarding the usage
        of particular Content-Types apply also to the individual parts
        of these multiparts.

Diffs to previous draft

--- {draft-04}	Wed Jul 11 21:55:55 2001
+++ {draft-05}	Wed Jul 11 21:55:55 2001
@@ -1,4 +1,4 @@
-
6.21.3.4.  Multipart types
+
6.21.2.4.  Multipart types
    The Content-Types "multipart/mixed", "multipart/parallel" and
    "multipart/signed" may be used freely in news articles.  However,
    except where policy or custom so allows, the Content-Type:
@@ -15,10 +15,10 @@
    described in [RFC 1153] to continue to operate correctly.
 [Actually, this conflicts with some present digest usage (such as the
 news.answers rules), but should still be the right way to go. There
-remains the possibility that future Mime-compliant readers could enable
+remains the possibility that future MIME-compliant readers could enable
 one to proceed directly to some particular message by clicking on it in
 a table of contents, but that feature is not yet supported by the
-curremt Mime standards.]
+current MIME standards.]
 
         NOTE: The various recomendations given above regarding the usage
         of particular Content-Types apply also to the individual parts