s-o-1036 June 1994
[< Prev]
[TOC] [ Next >]
5.6. Path
The Path header's content indicates which relayers the arti-
cle has already visited, so that unnecessary redundant
transmission can be avoided:
Path-content = [ path-list path-delimiter ] local-part
path-list = relayer-name *( path-delimiter relayer-name )
relayer-name = 1*rn-char
rn-char = letter / digit / "." / "-" / "_"
path-delimiter = "!"
The Path content is a list of relayer names, separated by
path delimiters, followed (after a final delimiter) by the
local part of a mailing address. Each relayer MUST prepend
its name, and a delimiter, to the Path content in all arti-
cles it processes. A relayer MUST not pass an article to a
neighboring relayer whose name is already mentioned in an
article's path list, unless this is explicitly requested by
the neighbor in some way. The Path content is case-
sensitive.
NOTE: The Path header supplied by a posting agent
should normally contain only the local part. The
relayer that the posting agent passes the article
to for posting will prepend its relayer name to
get the path list started.
NOTE: Observe that the trailing local part is NOT
part of the path list. This Path header:
Path: fee!fie!foe!fum
contains three relayer names: "fee", "fie", and
"foe". A relayer named "fum" is still eligible to
be sent this article.
NOTE: This syntax has the disadvantage of contain-
ing no white space, making it impossible to con-
tinue a Path header across several lines. Imple-
mentors of relayers and reading agents are warned
that it is intended that the successor to this
Draft will change the definition of path delimiter
to:
path-delimiter = "!" [ space ]
and are urged to fix their software to handle
(i.e., ignore) white space following the exclama-
tion points. They are urged to hurry; some ill-
behaved systems reportedly already feel free to
add such white space.
INTERNET DRAFT to be NEWS sec. 5.6
NOTE: RFC 1036 allows considerably more flexibil-
ity in choice of delimiter, in theory, but this
flexibility has never been used and most news
software does not implement it properly. The
grammar reflects the current reality. Note, in
particular, that RFC 1036 treats "_" as a delim-
iter, but in fact it is known to appear in relayer
names occasionally.
Because an article will not propagate to a relayer already
mentioned in its path list, the path list MUST not contain
any names other than those of relayers the article has
passed through AS NEWS. This is trivially obvious for nor-
mal news articles, but requires attention from the modera-
tors of moderated newsgroups and the implementors and main-
tainers of gateways.
NOTE: For the same reason, a relayer and its
neighbors need to agree on the choice of relayer
name, and names should not be changed without
notifying neighbors.
Relayer names need to be unique among all relayers which
will ever see the articles using them. A relayer name is
normally either an "official" name for the host the relayer
runs on, or some other "official" name controlled by the
same organization. Except in cooperating subnets that agree
to some other convention, and don't let articles using it
escape beyond the subnet, a relayer name MUST be either a
UUCP name registered in the UUCP maps (without any domain
suffix such as ".UUCP"), or a complete Internet domain name.
Use of a (registered) UUCP name is recommended, where prac-
tical, to keep the length of the path list down.
The use of Internet domain names in the path list presents
one problem: domain names are case-insensitive, but the path
list is case-sensitive. Relayers using domain names as
their relayer names MUST pick a standard form for the name,
and use that form consistently to the exclusion of all oth-
ers. The preferred form for this purpose, which relayers
SHOULD use, is the all-lowercase form.
NOTE: It is arguably unfortunate that the path
list is case-sensitive, but it is much too late to
change this. Most Internet sites do, in any
event, use one standardized form of their name
almost everywhere.
In the ordinary case, where the poster is the author of the
article, the local part following the path list SHOULD be
the local part of the poster's full Internet domain mailing
address.
INTERNET DRAFT to be NEWS sec. 5.6
NOTE: It should be just the local part, not the
full address. The character "@" does not appear
in a Path header.
The Path content somewhat resembles a mailing address, par-
ticularly in the UUCP world with its manual routing and "!"
address syntax. Historically, this resemblance was impor-
tant, and the Path content was often used as a reply
address. This practice has always been somewhat unreliable,
since news paths are not always mail paths and news relayer
names are not always recognized by mail handlers, and its
reliability has generally worsened in recent times. The
widespread use of and recognition of Internet domain
addresses, even outside the actual Internet, has largely
eliminated the problem. Readers SHOULD not use the Path
content as a reply address. On the other hand, relayer
administrators are urged not to break this usage without
good reason; where practical, paths followed by news SHOULD
be traversable by mail, and mail handlers SHOULD recognize
relayer names as host names.
It will typically be difficult or impractical for gateways
and moderators to supply a Path content that is useful as a
reply address for the author, bearing in mind that the path
list they supply will normally be empty. (To reiterate: the
path list MUST not contain any names other than those of
relayers the article has passed through AS NEWS.) They
SHOULD supply a local part that will result in replies to a
Path-derived address being returned to the sender with a
brief explanation. Software permitting, the local part
"not-for-mail" is recommended.
NOTE: A moderator or gateway administrator who
supplies a local part that delivers such mail to
an administrative mailbox will quickly discover
why it should be bounced automatically! It is
best, however, for the returned message to include
an explanation of what has probably happened,
rather than just a mysterious "undeliverable mail"
complaint, since the sender may not be aware that
his/her software is unwisely using the Path con-
tent as a reply address. Reply software might
wish to question attempts to reply to a Path-
derived address ending in "not-for-mail" (which is
why a specific name is being recommended here).
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../rfc1036/Path.out December 1987
+++ ../s-o-1036/Path.out June 1994
@@ -1,59 +1,158 @@
-2.1.6. Path
+5.6. Path
- This line shows the path the message took to reach the current
- system. When a system forwards the message, it should add its own
- name to the list of systems in the "Path" line. The names may be
- separated by any punctuation character or characters (except "."
- which is considered part of the hostname). Thus, the following are
- valid entries:
-
- cbosgd!mhuxj!mhuxt
- cbosgd, mhuxj, mhuxt
- @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
- teklabs, zehntel, sri-unix@cca!decvax
-
- (The latter path indicates a message that passed through decvax,
- cca, sri-unix, zehntel, and teklabs, in that order.) Additional
- names should be added from the left. For example, the most recently
- added name in the fourth example was teklabs. Letters, digits,
- periods and hyphens are considered part of host names; other
- punctuation, including blanks, are considered separators.
-
- Normally, the rightmost name will be the name of the originating
- system. However, it is also permissible to include an extra entry
- on the right, which is the name of the sender. This is for upward
- compatibility with older systems.
-
- The "Path" line is not used for replies, and should not be taken as
- a mailing address. It is intended to show the route the message
- traveled to reach the local host. There are several uses for this
- information. One is to monitor USENET routing for performance
- reasons. Another is to establish a path to reach new hosts.
- Perhaps the most important use is to cut down on redundant USENET
- traffic by failing to forward a message to a host that is known to
- have already received it. In particular, when host A sends a
- message to host B, the "Path" line includes A, so that host B will
- not immediately send the message back to host A. The name each host
- uses to identify itself should be the same as the name by which its
- neighbors know it, in order to make this optimization possible.
-
- A host adds its own name to the front of a path when it receives a
- message from another host. Thus, if a message with path "A!X!Y!Z"
- is passed from host A to host B, B will add its own name to the path
- when it receives the message from A, e.g., "B!A!X!Y!Z". If B then
- passes the message on to C, the message sent to C will contain the
- path "B!A!X!Y!Z", and when C receives it, C will change it to
- "C!B!A!X!Y!Z".
-
- Special upward compatibility note: Since the "From", "Sender", and
- "Reply-To" lines are in Internet format, and since many USENET hosts
- do not yet have mailers capable of understanding Internet format, it
- would break the reply capability to completely sever the connection
- between the "Path" header and the reply function. It is recognized
- that the path is not always a valid reply string in older
- implementations, and no requirement to fix this problem is placed on
- implementations. However, the existing convention of placing the
- host name and an "!" at the front of the path, and of starting the
- path with the host name, an "!", and the user name, should be
- maintained when possible.
+The Path header's content indicates which relayers the arti-
+cle has already visited, so that unnecessary redundant
+transmission can be avoided:
+
+ Path-content = [ path-list path-delimiter ] local-part
+ path-list = relayer-name *( path-delimiter relayer-name )
+ relayer-name = 1*rn-char
+ rn-char = letter / digit / "." / "-" / "_"
+ path-delimiter = "!"
+
+The Path content is a list of relayer names, separated by
+path delimiters, followed (after a final delimiter) by the
+local part of a mailing address. Each relayer MUST prepend
+its name, and a delimiter, to the Path content in all arti-
+cles it processes. A relayer MUST not pass an article to a
+neighboring relayer whose name is already mentioned in an
+article's path list, unless this is explicitly requested by
+the neighbor in some way. The Path content is case-
+sensitive.
+
+ NOTE: The Path header supplied by a posting agent
+ should normally contain only the local part. The
+ relayer that the posting agent passes the article
+ to for posting will prepend its relayer name to
+ get the path list started.
+
+ NOTE: Observe that the trailing local part is NOT
+ part of the path list. This Path header:
+
+ Path: fee!fie!foe!fum
+
+ contains three relayer names: "fee", "fie", and
+ "foe". A relayer named "fum" is still eligible to
+ be sent this article.
+
+ NOTE: This syntax has the disadvantage of contain-
+ ing no white space, making it impossible to con-
+ tinue a Path header across several lines. Imple-
+ mentors of relayers and reading agents are warned
+ that it is intended that the successor to this
+ Draft will change the definition of path delimiter
+ to:
+
+ path-delimiter = "!" [ space ]
+
+ and are urged to fix their software to handle
+ (i.e., ignore) white space following the exclama-
+ tion points. They are urged to hurry; some ill-
+ behaved systems reportedly already feel free to
+ add such white space.
+
+INTERNET DRAFT to be NEWS sec. 5.6
+
+
+ NOTE: RFC 1036 allows considerably more flexibil-
+ ity in choice of delimiter, in theory, but this
+ flexibility has never been used and most news
+ software does not implement it properly. The
+ grammar reflects the current reality. Note, in
+ particular, that RFC 1036 treats "_" as a delim-
+ iter, but in fact it is known to appear in relayer
+ names occasionally.
+
+Because an article will not propagate to a relayer already
+mentioned in its path list, the path list MUST not contain
+any names other than those of relayers the article has
+passed through AS NEWS. This is trivially obvious for nor-
+mal news articles, but requires attention from the modera-
+tors of moderated newsgroups and the implementors and main-
+tainers of gateways.
+
+ NOTE: For the same reason, a relayer and its
+ neighbors need to agree on the choice of relayer
+ name, and names should not be changed without
+ notifying neighbors.
+
+Relayer names need to be unique among all relayers which
+will ever see the articles using them. A relayer name is
+normally either an "official" name for the host the relayer
+runs on, or some other "official" name controlled by the
+same organization. Except in cooperating subnets that agree
+to some other convention, and don't let articles using it
+escape beyond the subnet, a relayer name MUST be either a
+UUCP name registered in the UUCP maps (without any domain
+suffix such as ".UUCP"), or a complete Internet domain name.
+Use of a (registered) UUCP name is recommended, where prac-
+tical, to keep the length of the path list down.
+
+The use of Internet domain names in the path list presents
+one problem: domain names are case-insensitive, but the path
+list is case-sensitive. Relayers using domain names as
+their relayer names MUST pick a standard form for the name,
+and use that form consistently to the exclusion of all oth-
+ers. The preferred form for this purpose, which relayers
+SHOULD use, is the all-lowercase form.
+
+ NOTE: It is arguably unfortunate that the path
+ list is case-sensitive, but it is much too late to
+ change this. Most Internet sites do, in any
+ event, use one standardized form of their name
+ almost everywhere.
+
+In the ordinary case, where the poster is the author of the
+article, the local part following the path list SHOULD be
+the local part of the poster's full Internet domain mailing
+address.
+
+INTERNET DRAFT to be NEWS sec. 5.6
+
+
+ NOTE: It should be just the local part, not the
+ full address. The character "@" does not appear
+ in a Path header.
+
+The Path content somewhat resembles a mailing address, par-
+ticularly in the UUCP world with its manual routing and "!"
+address syntax. Historically, this resemblance was impor-
+tant, and the Path content was often used as a reply
+address. This practice has always been somewhat unreliable,
+since news paths are not always mail paths and news relayer
+names are not always recognized by mail handlers, and its
+reliability has generally worsened in recent times. The
+widespread use of and recognition of Internet domain
+addresses, even outside the actual Internet, has largely
+eliminated the problem. Readers SHOULD not use the Path
+content as a reply address. On the other hand, relayer
+administrators are urged not to break this usage without
+good reason; where practical, paths followed by news SHOULD
+be traversable by mail, and mail handlers SHOULD recognize
+relayer names as host names.
+
+It will typically be difficult or impractical for gateways
+and moderators to supply a Path content that is useful as a
+reply address for the author, bearing in mind that the path
+list they supply will normally be empty. (To reiterate: the
+path list MUST not contain any names other than those of
+relayers the article has passed through AS NEWS.) They
+SHOULD supply a local part that will result in replies to a
+Path-derived address being returned to the sender with a
+brief explanation. Software permitting, the local part
+"not-for-mail" is recommended.
+
+ NOTE: A moderator or gateway administrator who
+ supplies a local part that delivers such mail to
+ an administrative mailbox will quickly discover
+ why it should be bounced automatically! It is
+ best, however, for the returned message to include
+ an explanation of what has probably happened,
+ rather than just a mysterious "undeliverable mail"
+ complaint, since the sender may not be aware that
+ his/her software is unwisely using the Path con-
+ tent as a reply address. Reply software might
+ wish to question attempts to reply to a Path-
+ derived address ending in "not-for-mail" (which is
+ why a specific name is being recommended here).