rfc850.txt

RFC 相关的技术文档

RFC 850                                         June 1983


       Standard for Interchange of USENET Messages

                      Mark R. Horton


[ This memo is distributed as an RFC  only  to  make  this
information  easily  accessible to researchers in the ARPA
community.  It does not specify  an  Internet  standard. ] 

1.  Introduction

This document defines the standard format for  interchange
of Network News articles among USENET sites.  It describes
the format for  articles  themselves,  and  gives  partial
standards for transmission of news.  The news transmission
is not entirely standardized in order to give a good  deal
of   flexibility   to   the  individual  hosts  to  choose
transmission hardware and software, whether to batch news,
and so on.

There are five sections to  this  document.   Section  two
section  defines  the  format.   Section three defines the
valid control messages.  Section four specifies some valid
transmission  methods.  Section five describes the overall
news propagation algorithm.


2.  Article Format

The primary consideration in choosing an article format is
that  it  fit  in with existing tools as well as possible.
Existing tools include both implementations  of  mail  and
news.   (The  notesfiles  system  from  the  University of
Illinois is considered a news implementation.) A  standard
format for mail messages has existed for many years on the
ARPANET, and this  format  meets  most  of  the  needs  of
USENET.    Since   the   ARPANET   format  is  extensible,
extensions to meet the  additional  needs  of  USENET  are
easily  made  within the ARPANET standard.  Therefore, the
rule is adopted that all  USENET  news  articles  must  be
formatted as valid ARPANET mail messages, according to the
ARPANET  standard  RFC  822.   This   standard   is   more
restrictive  than the ARPANET standard, placing additional
requirements on each article and forbidding use of certain
ARPANET  features.   However, it should always be possible
to use a tool expecting an ARPANET message  to  process  a
news  article.   In  any  situation  where  this  standard
conflicts with the ARPANET standard,  RFC  822  should  be
considered correct and this standard in error.






                          - 1 -


An example message is included to illustrate the fields.

     Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
     Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
     Path: cbosgd!mhuxj!mhuxt!eagle!jerry
     From: [e-mail] (Jerry Schwarz)
     Newsgroups: net.general
     Subject: Usenet Etiquette -- Please Read
     Message-ID: <[e-mail]>
     Date: Friday, 19-Nov-82 16:14:55 EST
     Followup-To: net.news
     Expires: Saturday, 1-Jan-83 00:00:00 EST
     Date-Received: Friday, 19-Nov-82 16:59:30 EST
     Organization: Bell Labs, Murray Hill

     The body of the article comes here, after a blank line.

Here is an example of a message in the old format  (before
the  existence  of this standard).  It is recommended that
implementations also accept articles  in  this  format  to
ease upward conversion.

     From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
     Newsgroups: net.general
     Title: Usenet Etiquette -- Please Read
     Article-I.D.: eagle.642
     Posted: Fri Nov 19 16:14:55 1982
     Received: Fri Nov 19 16:59:30 1982
     Expires: Mon Jan  1 00:00:00 1990

     The body of the article comes here, after a blank line.

Some news systems transmit news in the  "A"  format, which
looks like this:

     Aeagle.642
     net.general
     cbosgd!mhuxj!mhuxt!eagle!jerry
     Fri Nov 19 16:14:55 1982
     Usenet Etiquette - Please Read
     The body of the article comes here, with no blank line.

An article consists of several header lines, followed by a
blank  line,  followed  by  the  body of the message.  The
header lines consist of a keyword, a colon, a  blank,  and
some  additional  information.   This  is  a subset of the
ARPANET standard, simplified to allow simpler software  to
handle  it.   The   "from"   line may optionally include a
full name, in the format above, or use the  ARPANET  angle
bracket syntax.  To keep the implementations simple, other
formats (for example, with part  of  the  machine  address
after the close parenthesis) are not allowed.  The ARPANET
convention of continuation header lines (beginning with  a
blank or tab) is allowed.


                          - 2 -



Certain  headers  are  required,   certain   headers   are
optional.   Any unrecognized headers are allowed, and will
be passed through unchanged.   The  required  headers  are
Relay-Version,  Posting-Version,  From,  Date, Newsgroups,
Subject,  Message-ID,  Path.   The  optional  headers  are
Followup-To,  Date-Received,  Expires,  Reply-To,  Sender,
References, Control, Distribution, Organization.

2.1  Required Headers

2.1.1  Relay-Version  This header line shows  the  version
of  the  program  responsible for the transmission of this
article over the immediate link, that is, the program that
is  relaying the article from the next site.  For example,
suppose site A sends an article to  site  B,  and  site  B
forwards  the  article  to  site  C.   The  message  being
transmitted from A to B would have a Relay-Version  header
identifying  the  program  running  on  A, and the message
transmitted from B to C would identify the program running
on  B.  This header can be used to interpret older headers
in an upward compatible way.  Relay-Version must always be
the  first  in  a message; thus, all articles meeting this
standard will begin with an upper case   "R".    No  other
restrictions are placed on the order of header lines.

The line contains two  fields,  separated  by  semicolons.
The fields are the version and the full domain name of the
site.  The version should identify the system program used
(e.g.,   "B")   as  well  as  a version number and version
date.  For example, the header line might contain

   Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP

This header should not be passed on to  additional  sites.
A  relay  program,  when  passing  an  article  on, should
include only its own Relay-Version, not the  Relay-Version
of  some other site.  (For upward compatibility with older
software, if a Relay-Version is found in a header which is
not the first line, it should be assumed to be moved by an
older version of news and deleted.)

2.1.2  Posting-Version    This   header   identifies   the
software  responsible  for  entering this message into the
network.  It has the same  format  as  Relay-Version.   It
will  normally  identify  the same site as the Message-ID,
unless the posting site is serving  as  a  gateway  for  a
message  that  already  contains a message ID generated by
mail.  (While it is permissible for a gateway  to  use  an
externally  generated message ID, the message ID should be
checked to ensure it conforms to this standard and to  RFC
822.)




                          - 3 -



2.1.3  From  The From line contains the electronic mailing
address  of  the  person who sent the message, in the ARPA
internet syntax.  It may optionally also contain the  full
name  of  the person, in parentheses, after the electronic
address.  The electronic address is the same as the entity
responsible for originating the article, unless the Sender
header is present, in which case the From header might not
be  verified.   Note  that  in  all site and domain names,
upper  and  lower  case  are  considered  the  same,  thus
[e-mail],  [e-mail],  and [e-mail]
are all equivalent.  User names may or  may  not  be  case
sensitive,   for   example,   [e-mail]  might  be
different from [e-mail].  Programs  should  avoid
changing  the case of electronic addresses when forwarding
news or mail.

RFC 822 specifies that all text in parentheses  is  to  be
interpreted as a comment.  It is common in ARPANET mail to
place the full name of the user in a comment at the end of
the  From  line.   This  standard  specifies  a more rigid
syntax.  The full name is not considered a comment, but an
optional part of the header line.  Either the full name is
omitted, or it appears in parentheses after the electronic
address  of  the person posting the article, or it appears
before an electronic address enclosed in  angle  brackets.
Thus, the three permissible forms are:

     From: [e-mail]
     From: [e-mail] (Mark Horton)
     From: Mark Horton <[e-mail]>

Full names may contain any printing ASCII characters  from
space through tilde, with the exceptions that they may not
contain parentheses  "("   or   ")",   or  angle  brackets
"<"   or  ">".    Additional restrictions may be placed on
full names  by  the  mail  standard,  in  particular,  the
characters  comma   ",",  colon  ":",  and semicolon   ";" 
are inadvisable in full names.

2.1.4  Date  The Date line (formerly   "Posted")   is  the
date,  in  a  format  that  must be acceptable both to the
ARPANET and to the getdate routine, that the  article  was
originally  posted  to  the  network.   This  date remains
unchanged as the  article  is  propagated  throughout  the
network.  One format that is acceptable to both is

     Weekday, DD-Mon-YY HH:MM:SS TIMEZONE

Several examples of  valid  dates  appear  in  the  sample
article above.  Note in particular that ctime format:

     Wdy Mon DD HH:MM:SS YYYY



                          - 4 -





is not acceptable because it is not a valid ARPANET  date.
However, since older software still generates this format,
news implementations are encouraged to accept this  format
and translate it into an acceptable format.

The contents of the TIMEZONE field is currently subject to
worldwide time zone  abbreviations,  including  the  usual
American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
the   other   North   American   zones   (Bering   through
Newfoundland),  European  zones,  Australian zones, and so
on.  Lacking a complete list at present (and unsure if  an
unambiguous   list   exists),   authors  of  software  are
encouraged to keep this code flexible, and  in  particular
not  to  assume  that  time  zone  names are exactly three
letters long.   Implementations  are  free  to  edit  this
field,  keeping  the  time the same, but changing the time
zone (with an appropriate adjustment  to  the  local  time
shown) to a known time zone.

2.1.5  Newsgroups  The  Newsgroups  line  specifies  which
newsgroup  or newsgroups the article belongs in.  Multiple
newsgroups  may  be  specified,  separated  by  a   comma.
Newsgroups  specified  must  all  be the names of existing
newsgroups, as no new newsgroups will be created by simply
posting to them.

Wildcards (e.g., the word  "all")  are never allowed in  a
Newsgroups  line.  For example, a newsgroup  "net.all"  is
illegal, although a newsgroup name    "net.sport.football" 
is permitted.

If an article is received with a Newsgroups  line  listing
some  valid newsgroups and some invalid newsgroups, a site
should  not  remove  invalid  newsgroups  from  the  list.
Instead,  the  invalid  newsgroups should be ignored.  For
example,  suppose  site  A  subscribes  to   the   classes
"btl.all"   and   "net.all",   and exchanges news articles
with site B,  which  subscribes  to   "net.all"   but  not
"btl.all".      Suppose   A   receives   an  article  with
"Newsgroups: net.micro,btl.general".     This  article  is
passed  on  to  B because B receives net.micro, but B does
not receive btl.general.  A must leave the Newsgroup  line
unchanged.   If  it  were  to  remove  "btl.general",  the
edited header could  eventually  reenter  the    "btl.all" 
class,  resulting in an article that is not shown to users
subscribing  to   "btl.general".    Also,  followups  from
outside  "btl.all"  would not be shown to such users.






                          - 5 -



2.1.6  Subject   The  Subject  line  (formerly    "Title")
tells  what the article is about.  It should be suggestive
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  "<[e-mail]>".
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 -