usefor-article-04 April 2001

6.21.3.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
curremt Mime standards.]

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

--- ../usefor-article-03/Multipart_types.out          February 2000
+++ ../usefor-article-04/Multipart_types.out          April 2001
@@ -1,4 +1,4 @@
-6.17.3.4.  Multipart types
+6.21.3.4.  Multipart types
 
    The Content-Types "multipart/mixed", "multipart/parallel" and
    "multipart/signed" may be used freely in news articles.  However,
@@ -9,12 +9,19 @@
 
    The Content-Type: "multipart/digest" is commended for any article
    composed of multiple messages more conveniently viewed as separate
-   entities. 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 accord with current practice for digests [RFC
-   1153].
+   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. I suggest
-this is left in for now (just to stake a claim), while we discuss the
-matter with the news.answers moderators and the faq-maintainers.]
+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
+curremt Mime standards.]
+
+        NOTE: The various recomendations given above regarding the usage
+        of particular Content-Types apply also to the individual parts
+        of these multiparts.