usefor-article-09 February 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 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.
   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-08/Content-Transfer-Encoding.out          August 2002
+++ ../usefor-article-09/Content-Transfer-Encoding.out          February 2003
@@ -22,7 +22,6 @@
         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
@@ -77,7 +76,6 @@
         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.
-
    Injecting and relaying agents MUST NOT change the encoding of
    articles passed to them. Gateways SHOULD NOT change the encoding
    unless absolutely necessary.