usefor-article-08 August 2002

8.8.1.  Duties of an Outgoing Gateway

   From the perspective of Netnews, an outgoing gateway is just a
   special type of reading agent. The exact nature of what the outgoing
   gateway will need to do to articles depends on the medium to which
   the articles are being gated. The operation of the outgoing gateway
   is only subject to additional constraints in the presence of one or
   more corresponding incoming gateways back from that medium to
   Netnews, since this opens the possibility of loops.

   Where the format of the news article is incompatible with that of the
   target medium, it may be necessary to apply transformations.

   It is not the purpose of this standard to set requirements to be
   followed by implementors of outgoing gateways. Those implementors are
   in the best position to know the capabilities of the systems to which
   the article is to be sent, the purposes for which it is being sent,
   and the extent to which those purposes will be vitiated if the
   content of some header is mutilated en route, or fails to display
   correctly upon arrival; this is a matter for their judgement.
   Nevertheless, it is useful to draw attention to a few transformations
   which such implementors might find useful.

    o Transporting headers containing non-ASCII characters without first
      encoding them is contrary to the current Email standards [RFC
      2821] and [RFC 2822].  This applies both to the top-level headers
      of the email, and also to headers contained within any embedded
      message or multipart Content-Types (and so recursively). However,
      it is well known that most mail transport agents will in fact
      convey these characters intact, especially for non-top-level
      headers in the case of transports which support the 8BITMIME
      extension, and it is to be expected that the prevalence of this
      ability will increase in the future (and may even be compliant
      with future versions of the Email standards).  Moreover, many mail
      user agents will also display such characters correctly, or at
      least adequately. Therefore, some implementors of gateways may
      consider it an acceptable risk not to transform these headers in
      any way, especially in the case of the lower-level ones.

        NOTE: It is not the purpose of this standard either to condemn
        or to condone behaviours which may be non-compliant with other
        standards. That is a matter for those implementors.

    o Where an implementor considers the risk too high for the top-level
      headers, encapsulating the whole article as a message/rfc822
      (6.21.2.2) may make it less likely to be mutilated during
      transport, especially where 8BITMIME is supported. Alternatively,
      encapsulating as an application/news-transmission (6.21.6.1) will
      guarantee correct transmission in all cases and is the method of
      choice where the intent is to gateway it back into Netnews later
      on.
    o To ensure full compliance with the Email standards it is necessary
      to encode words containing UTF8-xtra-chars according to [RFC 2047]
      (but only where permitted by that standard, i.e. within phrases
      and unstructured headers, although many user agents will display
      this encoding correctly in other contexts also). Likewise, within
      parameters the proper encoding is that defined in [RFC 2231].  In
      both cases, it is preferable to encode using the charset UTF-8,
      although it might be wise first to confirm that that is indeed the
      charset which had been used (see 4.4.1).
    o In the case of newsgroup-names, as found in Newsgroups-headers,
      Followup-To-headers and some Control-headers, [RFC 2047] is not
      applicable (even though some mail reading agents might
      nevertheless display it correctly). Therefore, it is necessary to
      use the encoding described in section 5.5.2.  Even if it is not
      decoded at the far end, it is preferable to display such an
      encoded form than to display nothing at all. Note, however, that
      such encoded newsgroup-names MUST be restored to their canonical
      form before reinjection into any Netnews system.

   In general, the following practices are recommended for all outgoing
   gateways, regardless of whether there is known to be a related
   incoming gateway, both as a precautionary measure and as a guideline
   to quality of implementation.
   1. The message identifier of the news article should be preserved if
      at all possible, preferably as or within the corresponding unique
      identifier of the other medium, but if not at least as a comment
      in the message. This helps greatly with preventing loops.

   2. The Date of the news article should also be preserved if possible,
      for similar reasons.

   3. The message should be tagged in some way so as to prevent its
      reinjection into Netnews. This may be impossible to do without
      knowledge of potential incoming gateways, but it is better to try
      to provide some indication even if not successful; at the least, a
      human-readable indication that the article should not be gated
      back to Netnews can help locate a human problem.

   4. Netnews control messages should not be gated to another medium
      unless they would somehow be meaningful in that medium.

--- ../usefor-article-07/Duties_of_an_Outgoing_Gateway.out          May 2002
+++ ../usefor-article-08/Duties_of_an_Outgoing_Gateway.out          August 2002
@@ -7,13 +7,9 @@
    is only subject to additional constraints in the presence of one or
    more corresponding incoming gateways back from that medium to
    Netnews, since this opens the possibility of loops.
+
    Where the format of the news article is incompatible with that of the
-   target medium, it may be necessary to apply transformations. In
-   particular, the presence of UTF8-xtra-chars in headers may be a
-   source of such incompatibility when gatewaying into Email. On the
-   other hand, some email systems (especially those supporting the
-   8BITMIME extensions [RFC 2821]) may well transport such material
-   correctly, and some user agents may even display it.
+   target medium, it may be necessary to apply transformations.
 
    It is not the purpose of this standard to set requirements to be
    followed by implementors of outgoing gateways. Those implementors are
@@ -25,33 +21,57 @@
    Nevertheless, it is useful to draw attention to a few transformations
    which such implementors might find useful.
 
-    o Encapsulating the whole article as a message/rfc822 (6.21.2.2) may
-      make it less likely to be mutilated during transport, especially
-      where 8BITMIME is supported. Alternatively, encapsulating as an
-      application/news-transmission (6.21.6.1) will guarantee correct
-      transmission and is the method of choice where the intent is to
-      gateway it back into Netnews later on.
-    o Encoding words containing UTF8-xtra-chars according to [RFC 2047],
-      where permitted by that standard (i.e. within phrases and
-      unstructured headers), and preferably using the charset utf-8,
-      should ensure their correct display upon arrival. Indeed, many
-      user agents will display this encoding correctly in contexts not
-      allowed by [RFC 2047].
-    o In particular, treating a newsgroup-name as an encoded word
-      according to [RFC 2047] is recommended (see also 5.5).  Even if it
-      is not decoded at the far end, it is preferable to display the
+    o Transporting headers containing non-ASCII characters without first
+      encoding them is contrary to the current Email standards [RFC
+      2821] and [RFC 2822].  This applies both to the top-level headers
+      of the email, and also to headers contained within any embedded
+      message or multipart Content-Types (and so recursively). However,
+      it is well known that most mail transport agents will in fact
+      convey these characters intact, especially for non-top-level
+      headers in the case of transports which support the 8BITMIME
+      extension, and it is to be expected that the prevalence of this
+      ability will increase in the future (and may even be compliant
+      with future versions of the Email standards).  Moreover, many mail
+      user agents will also display such characters correctly, or at
+      least adequately. Therefore, some implementors of gateways may
+      consider it an acceptable risk not to transform these headers in
+      any way, especially in the case of the lower-level ones.
+
+        NOTE: It is not the purpose of this standard either to condemn
+        or to condone behaviours which may be non-compliant with other
+        standards. That is a matter for those implementors.
+
+    o Where an implementor considers the risk too high for the top-level
+      headers, encapsulating the whole article as a message/rfc822
+      (6.21.2.2) may make it less likely to be mutilated during
+      transport, especially where 8BITMIME is supported. Alternatively,
+      encapsulating as an application/news-transmission (6.21.6.1) will
+      guarantee correct transmission in all cases and is the method of
+      choice where the intent is to gateway it back into Netnews later
+      on.
+    o To ensure full compliance with the Email standards it is necessary
+      to encode words containing UTF8-xtra-chars according to [RFC 2047]
+      (but only where permitted by that standard, i.e. within phrases
+      and unstructured headers, although many user agents will display
+      this encoding correctly in other contexts also). Likewise, within
+      parameters the proper encoding is that defined in [RFC 2231].  In
+      both cases, it is preferable to encode using the charset UTF-8,
+      although it might be wise first to confirm that that is indeed the
+      charset which had been used (see 4.4.1).
+    o In the case of newsgroup-names, as found in Newsgroups-headers,
+      Followup-To-headers and some Control-headers, [RFC 2047] is not
+      applicable (even though some mail reading agents might
+      nevertheless display it correctly). Therefore, it is necessary to
+      use the encoding described in section 5.5.2.  Even if it is not
+      decoded at the far end, it is preferable to display such an
       encoded form than to display nothing at all. Note, however, that
       such encoded newsgroup-names MUST be restored to their canonical
       form before reinjection into any Netnews system.
-    o Parameters whose values contain UTF8-xtra-chars may use the
-      encoding defined in [RFC 2231], again preferably using the charset
-      utf-8.
 
    In general, the following practices are recommended for all outgoing
    gateways, regardless of whether there is known to be a related
    incoming gateway, both as a precautionary measure and as a guideline
    to quality of implementation.
-
    1. The message identifier of the news article should be preserved if
       at all possible, preferably as or within the corresponding unique
       identifier of the other medium, but if not at least as a comment
@@ -59,6 +79,7 @@
 
    2. The Date of the news article should also be preserved if possible,
       for similar reasons.
+
    3. The message should be tagged in some way so as to prevent its
       reinjection into Netnews. This may be impossible to do without
       knowledge of potential incoming gateways, but it is better to try