enough of the contents of the article to enable  a  reader
to  make  a  decision whether to read the article based on
the  subject  alone.   If  the  article  is  submitted  in
response  to another article (e.g., is a  "followup")  the
default subject should  begin  with  the  four  characters
"Re: "   and the References line is required.    (The user
might wish to edit the subject of the  followup,  but  the
default should begin with  "Re: ".)

2.1.7  Message-ID  The Message-ID line gives the article a
unique  identifier.  The same message ID may not be reused
during the lifetime of any article with the  same  message
ID.   (It  is recommended that no message ID be reused for
at least two years.) Message ID's have the syntax

     "<" "string not containing blank or >" ">"

In order to conform to RFC 822, the Message-ID  must  have
the format

     "<" "unique" "@" "full domain name" ">"

where  "full domain name"  is the full name of the host at
which  the article entered the network, including a domain
that host is in, and unique  is  any  string  of  printing
ASCII  characters,  not  including  "<", ">", or "@".  For
example,  the  "unique"   part   could   be   an   integer
representing  a  sequence number for articles submitted to
the network, or a short string derived from the  date  and
time  the article was created.  For example, valid message
ID for an article submitted from  site  ucbvax  in  domain
Berkeley.ARPA   would   be  "<4123@ucbvax.Berkeley.ARPA>".
Programmers are urged not to make  assumptions  about  the
content  of  message  ID  fields  from other hosts, but to
treat them as unknown character strings.  It is not  safe,
for  example, to assume that a message ID will be under 14
characters,  nor  that  it  is  unique  in  the  first  14
characters.

The angle brackets are considered part of the message  ID.
Thus,  in  references  to  the  message  ID,  such  as the
ihave/sendme  and  cancel  control  messages,  the   angle
brackets  are  included.   White  space  characters (e.g.,
blank and tab) are not  allowed  in  a  message  ID.   All
characters  between  the  angle  brackets must be printing
ASCII characters.

2.1.8  Path  This line shows the path the article 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,      thus

                          - 6 -
 


"cbosgd!mhuxj!mhuxt",    "cbosgd,  mhuxj,  mhuxt",     and
"@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp"      and       even
"teklabs,   zehntel,   sri-unix@cca!decvax"    are   valid
entries.  (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
third example was  "teklabs".   Letters,  digits,  periods
and  hyphens  are  considered  part  of  site 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
system.

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  travelled  to  reach  the  local  site.
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 sites.  Perhaps the
most important is to cut down on redundant USENET  traffic
by failing to forward a message to a site that is known to
have already received it.   In  particular,  when  site  A
sends  an article to site B, the Path line includes   "A",
so that site B will not immediately send the article  back
to  site  A.   The  site  name  each site 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 site adds its own name to the front of a  path  when  it
receives  a message from another site.  Thus, if a message
with path A!X!Y!Z is passed from site A to site 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,