usefor-article-11 June 2003

6.21.2.  Content-Type

   If the contents of an article is something other than plain text in
   the US-ASCII charset (these being the default assumptions), an
   appropriate Content-Type-header MUST be included.

   Reading agents SHOULD NOT, unless explicitly configured otherwise,
   act automatically on Application types which could change the state
   of that agent (e.g. by writing or modifying files), except in the
   case of those prescribed for use in control messages (7.2.1.2 and
   7.2.4.1).

   The Content-Type "message/partial" MAY be used to split a long news
   article into several smaller ones. However, breaking long texts into
   several parts is usually unnecessary, since modern transport agents
   should have no difficulty in handling articles of arbitrary length,
   although it may be useful to break long binaries.

   IF the Content-Type "message/partial" 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).

   The Content-Type "message/rfc822" should be used for the
   encapsulation (whether as part of another news article or, more
   usually, as part of an email message) of complete news articles which
   have already been posted to Netnews and which are for the information
   of the recipient, and do not constitute a request to repost them
   (refer to 6.21.6.2 for the now obsolete "message/news" formerly
   intended for this purpose).

--- ../usefor-article-10/Content-Type.out          April 2003
+++ ../usefor-article-11/Content-Type.out          June 2003
@@ -4,30 +4,33 @@
    the US-ASCII charset (these being the default assumptions), an
    appropriate Content-Type-header MUST be included.
 
-   When the Content-Type is "text/plain", the recommendations and limits
-   on line lengths set out in section 4.5 Ought to be observed.
-
-   The acceptability of other subtypes of Content-Type: "text" (such as
-   "text/html") is a matter of policy (see 1.1), and posters Ought Not
-   to use them unless established policy or custom in the particular
-   hierarchies or groups involved so allows.  Moreover, even in those
-   cases, for the benefit of readers who see it only in its transmitted
-   form, the material SHOULD be "pretty-printed" (for example by
-   restricting its line length as above and by keeping sequences which
-   control its layout or style separate from the meaningful text).
-
-   In the same way, Content-Types requiring special processing for their
-   display, such as "application", "image", "audio", "video" and
-   "multipart/related" are discouraged except in groups specifically
-   intended (by policy or custom) to include them. Exceptionally, those
-   application types defined in [RFC 1847] and [RFC 3156] for use within
-   "multipart/signed" articles, and the type "application/pgp-keys" (or
-   other similar types containing digital certificates) may be used
-   freely.
-
    Reading agents SHOULD NOT, unless explicitly configured otherwise,
    act automatically on Application types which could change the state
    of that agent (e.g. by writing or modifying files), except in the
    case of those prescribed for use in control messages (7.2.1.2 and
    7.2.4.1).
+
+   The Content-Type "message/partial" MAY be used to split a long news
+   article into several smaller ones. However, breaking long texts into
+   several parts is usually unnecessary, since modern transport agents
+   should have no difficulty in handling articles of arbitrary length,
+   although it may be useful to break long binaries.
+
+   IF the Content-Type "message/partial" 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).
+
+   The Content-Type "message/rfc822" should be used for the
+   encapsulation (whether as part of another news article or, more
+   usually, as part of an email message) of complete news articles which
+   have already been posted to Netnews and which are for the information
+   of the recipient, and do not constitute a request to repost them
+   (refer to 6.21.6.2 for the now obsolete "message/news" formerly
+   intended for this purpose).