usefor-article-13 May 2004

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-12/Content-Transfer-Encoding.out          November 2003
+++ ../usefor-article-13/Content-Transfer-Encoding.out          May 2004