usefor-article-07 May 2002
[< Prev]
[TOC] [ Next >]
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. 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.
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 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
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
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.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-06/Duties_of_an_Outgoing_Gateway.out November 2001
+++ ../usefor-article-07/Duties_of_an_Outgoing_Gateway.out May 2002
@@ -7,30 +7,65 @@
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.
+
+ 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 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
+ 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.
- It is recommended, however, that the following practices be followed
- by 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. Only the minimal necessary changes should be made, as stated
- above.
-
- 2. The message identifier of the news article should be preserved if
+ 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.
- 3. The Date of the news article should also be preserved if possible,
+ 2. The Date of the news article should also be preserved if possible,
for similar reasons.
-
- 4. The message should be tagged in some way so as to prevent its
+ 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.
- 5. News control messages should not be gated to another medium unless
- they would somehow be meaningful in that medium.
+ 4. Netnews control messages should not be gated to another medium
+ unless they would somehow be meaningful in that medium.