usefor-article-03 February 2000

5.6.  Path

   The Path header shows the route taken by a message since its entry
   into the Netnews system. It is a variant header (4.2.2.4), each agent
   that processes an article being required to add one (or more) entries
   to it. This is primarily to enable relaying agents to avoid sending
   articles to sites already known to have them, in particular the site
   they came from, and additionally to permit tracing the route articles
   take in moving over the network, and for gathering Usenet statistics.
   Finally the presence of a '%' delimiter in the Path header can be
   used to identify an article injected in conformance with this
   standard.

--- ../s-o-1036/Path.out          June 1994
+++ ../usefor-article-03/Path.out          February 2000
@@ -1,158 +1,13 @@
 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).
+   The Path header shows the route taken by a message since its entry
+   into the Netnews system. It is a variant header (4.2.2.4), each agent
+   that processes an article being required to add one (or more) entries
+   to it. This is primarily to enable relaying agents to avoid sending
+   articles to sites already known to have them, in particular the site
+   they came from, and additionally to permit tracing the route articles
+   take in moving over the network, and for gathering Usenet statistics.
+   Finally the presence of a '%' delimiter in the Path header can be
+   used to identify an article injected in conformance with this
+   standard.