usefor-article-09 February 2003

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 (see
   8.8.1.1 for the particular case when the target is Email).

   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-08/Duties_of_an_Outgoing_Gateway.out          August 2002
+++ ../usefor-article-09/Duties_of_an_Outgoing_Gateway.out          February 2003
@@ -9,69 +9,14 @@
    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.
+   target medium, it may be necessary to apply transformations (see
+   8.8.1.1 for the particular case when the target is Email).
 
    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