usefor-article-11 June 2003

6.21.3.  Content-Transfer-Encoding

   "Content-Transfer-Encoding: 7bit" is sufficient for article bodies
   (or parts of multiparts) written in pure US-ASCII (or most other
   material representable in 7 bits).  Posting agents SHOULD specify
   "Content-Transfer-Encoding: 8bit" for all other cases except where
   the content is (or might be) "8bit-unsafe", or where some protocol
   explicitly disallows it. They MAY use "8bit" encoding even when
   "7bit" encoding would have sufficed.

   Content is "8bit-unsafe" if it contains octets equivalent to the US-
   ASCII characters CR or LF (other than in the combination CRLF) or
   NUL. This is often the case with application types (though in many
   cases application types are intended to be human readable, in which
   case they will usually be 8bit-safe). It also arises with certain
   charsets (as indicated in the Content-Type-header), particularly in
   the case of 16-bit charsets such as UTF-16 ([UNICODE 3.2] or [ISO/IEC
   10646]).

   Examples of protocols REQUIRING particular Content-Transfer-Encodings
   include the Content-Type "application/pgp-signature" [RFC 3156], and
   the Content-Type "message/partial" which itself MUST use "Content-
   Transfer-Encoding: 7bit" (though the encapsulated complete message
   may itself use encoding "quoted-printable" or "base64", but that
   information is only conveyed along with the first of the partial
   parts).

   Encoding "binary" MUST NOT be used (except in cooperating subnets
   with alternative transport arrangements) because this standard does
   not mandate a transport mechanism that could support it.

   Injecting and relaying agents MUST NOT change the encoding of
   articles passed to them. Gateways SHOULD NOT change the encoding
   unless absolutely necessary.

--- ../usefor-article-10/Content-Transfer-Encoding.out          April 2003
+++ ../usefor-article-11/Content-Transfer-Encoding.out          June 2003
@@ -3,80 +3,31 @@
    "Content-Transfer-Encoding: 7bit" is sufficient for article bodies
    (or parts of multiparts) written in pure US-ASCII (or most other
    material representable in 7 bits).  Posting agents SHOULD specify
-   "Content-Transfer-Encoding: 8bit" for all other cases unless there
-   are pressing reasons to do otherwise. They MAY use "8bit" encoding
-   even when "7bit" encoding would have sufficed. Examples of such
-   pressing reasons are the following:
-
-   1. The content type implies that the content is (or may be) "8bit-
-      unsafe"; i.e.  it may contain octets equivalent to the US-ASCII
-      characters CR or LF (other than in the combination CRLF) or NUL.
-      In that case one of the Content-Transfer-Encodings "base64" or
-      "quoted-printable" MUST be used, and reading agents MUST be able
-      to handle both of them. Encoding "binary" MUST NOT be used (except
-      in cooperating subnets with alternative transport arrangements)
-      because this standard does not mandate a transport mechanism that
-      could support it.
-
-        NOTE: If a future extension to the MIME standards were to
-        provide a more compact encoding of binary suited to transport
-        over an 8bit channel, it could be considered as an alternative
-        to base64 once it had gained widespread acceptance.
-
-   2. It is often the case that "application" Content-Types are textual
-      in nature, and intelligible to humans as well as to machines, and
-      where this state can be recognized by the posting agent (either
-      through knowledge of the particular application type or by
-      testing) the material SHOULD NOT be treated as 8bit-unsafe; this
-      has the added benefit, where the posting agent uses other than
-      CRLF for line endings internally, of automatically ensuring that
-      line endings are processed correctly during transport.
-
-      If, on the other hand, the posting agent recognizes that the
-      material is not textual, or cannot reasonably determine it to be
-      so, then the material MUST be encoded as for 8bit-unsafe (however,
-      in that case, it is the responsibility of the agent generating the
-      material to ensure that lines endings, if any, are represented
-      correctly).
-
-        NOTE: All the application types defined by this standard, namely
-        "application/news-transmission", "application/news-groupinfo"
-        and "application/news-checkgroups" are textual, and indeed
-        designed for human reading.
-
-   3. Although the "text" Content-Types should normally be encoded as
-      8bit (or 7bit), if the character set specified by the "charset="
-      parameter can include the 3 disallowed octets, then the material
-      MUST be encoded as for 8bit-unsafe.  This is most likely to arise
-      in the case of 16-bit character sets such as UTF-16 ([UNICODE 3.2]
-      or [ISO/IEC 10646]).  In addition, where it is known that the
-      material is subsequently to be gatewayed from Netnews to Email
-      (8.8), the encoding "quoted-printable" MAY be used (otherwise the
-      gateway might have to re-encode it itself).
-
-   4. Some protocols REQUIRE the use of a particular Content-Transfer-
-      Encoding. In particular, the authentication protocol based on
-      OpenPGP defined in [RFC 3156] mandates the use of one of the
-      encodings "quoted-printable" or "base64".  Whilst posters might be
-      tempted to risk the use of "8bit" or "7bit" encodings (and indeed
-      the referenced standard recommends that signed messages using
-      those encodings be accepted and interpreted), they should be
-      warned that differences in the treatment of trailing whitespace
-      between OpenPGP [RFC 2440] and earlier versions of PGP may render
-      signatures written with the one unverifiable by the other; and,
-      moreover, Usenet articles are very likely to include trailing
-      whitespace in the form of a personal signature (4.3.2).
-
-   5. The Content-Type message/partial [RFC 2046] is required to use
-      encoding "7bit" (the encapsulated complete message may itself use
-      encoding "quoted-printable" or "base64", but that information is
-      only conveyed along with the first of the partial parts).
-
-        NOTE: Although there would actually be no problem using encoding
-        "8bit" in a pure Netnews (as opposed to Email) environment, this
-        standard discourages (see 6.21.2.1) the use of "message/partial"
-        except for binary material, which will likely be encoded to pass
-        through "7bit" in any case.
+   "Content-Transfer-Encoding: 8bit" for all other cases except where
+   the content is (or might be) "8bit-unsafe", or where some protocol
+   explicitly disallows it. They MAY use "8bit" encoding even when
+   "7bit" encoding would have sufficed.
+
+   Content is "8bit-unsafe" if it contains octets equivalent to the US-
+   ASCII characters CR or LF (other than in the combination CRLF) or
+   NUL. This is often the case with application types (though in many
+   cases application types are intended to be human readable, in which
+   case they will usually be 8bit-safe). It also arises with certain
+   charsets (as indicated in the Content-Type-header), particularly in
+   the case of 16-bit charsets such as UTF-16 ([UNICODE 3.2] or [ISO/IEC
+   10646]).
+
+   Examples of protocols REQUIRING particular Content-Transfer-Encodings
+   include the Content-Type "application/pgp-signature" [RFC 3156], and
+   the Content-Type "message/partial" which itself MUST use "Content-
+   Transfer-Encoding: 7bit" (though the encapsulated complete message
+   may itself use encoding "quoted-printable" or "base64", but that
+   information is only conveyed along with the first of the partial
+   parts).
+
+   Encoding "binary" MUST NOT be used (except in cooperating subnets
+   with alternative transport arrangements) because this standard does
+   not mandate a transport mechanism that could support it.
 
    Injecting and relaying agents MUST NOT change the encoding of
    articles passed to them. Gateways SHOULD NOT change the encoding