usefor-article-10 April 2003

[< Prev] [TOC] [ Next >]
4.4.  Characters and Character Sets

   Transmission paths for news articles MUST treat news articles as
   uninterpreted sequences of octets, excluding the values 0 (US-ASCII
   NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the
   combination CRLF which denotes a line separator).

        NOTE: this corresponds to the range of octets permitted for MIME
        "8bit data" [RFC 2045].  Thus raw binary data cannot be
        transmitted in an article body except by the use of a Content-
        Transfer-Encoding such as base64.

   In particular, transmission paths MUST convey all headers (including
   body part headers and headers within message/rfc822 objects) intact,
   even if they contain octets representing non-ASCII charsets.  These
   requirements include the transmissiom paths between posting agents,
   injecting agents, relaying agents, serving agents and reading agents,
   but NOT the paths traversed by Netnews articles that have been
   gatewayed into Email (8.8.1).
[At some point it will be necessary for the IMAP standards to catch up
with these requirements.]

   Character data is represented by octets in accordance with some
   encoding scheme (US-ASCII for headers, and determined by the
   Content-Type- and Content-Transfer-Encoding-headers for bodies).

   If it comes to a relaying agent's attention that it is being asked to
   pass an article using the Content-Transfer-Encoding "8bit" to a
   relaying agent that does not support it, it SHOULD report this error
   to its administrator. It MUST refuse to pass the article and MUST NOT
   re-encode it with different MIME encodings.

        NOTE: This strategy will do little harm. The target relaying
        agent is unlikely to be able to make use of the article on its
        own servers, and the usual flooding algorithm will likely find
        some alternative route to get the article to destinations where
        it is needed.
[< Prev] [TOC] [ Next >]
#Diff to first older
NewerOlder
News Article Format June 2003
News Article Format February 2003
News Article Format August 2002
News Article Format May 2002
News Article Format November 2001
News Article Format July 2001
News Article Format April 2001
News Article Format February 2000
Son of 1036 June 1994

--- ../usefor-article-09/Characters_and_Character_Sets.out          February 2003
+++ ../usefor-article-10/Characters_and_Character_Sets.out          April 2003
@@ -10,18 +10,19 @@
         transmitted in an article body except by the use of a Content-
         Transfer-Encoding such as base64.
 
-[Tentative paragraph to deal with IMAP]
-
-   This requirement includes the transmissiom paths between posting
-   agents, injecting agents, relaying agents, serving agents and reading
-   agents, but it does NOT include paths traversed by Netnews articles
-   that have been converted to Email (8.8.1.1).  It SHOULD extend to
-   IMAP4 servers which provide access to Netnews (see the extension
-   described in section 4.4.3).
+   In particular, transmission paths MUST convey all headers (including
+   body part headers and headers within message/rfc822 objects) intact,
+   even if they contain octets representing non-ASCII charsets.  These
+   requirements include the transmissiom paths between posting agents,
+   injecting agents, relaying agents, serving agents and reading agents,
+   but NOT the paths traversed by Netnews articles that have been
+   gatewayed into Email (8.8.1).
+[At some point it will be necessary for the IMAP standards to catch up
+with these requirements.]
 
    Character data is represented by octets in accordance with some
-   encoding scheme (UTF-8 for headers, and determined by the Content-
-   Type- and Content-Transfer-Encoding-headers for bodies).
+   encoding scheme (US-ASCII for headers, and determined by the
+   Content-Type- and Content-Transfer-Encoding-headers for bodies).
 
    If it comes to a relaying agent's attention that it is being asked to
    pass an article using the Content-Transfer-Encoding "8bit" to a


Documents were processed to this format by Forrest J. Cavalier III