Message-ID: < bnews.cbosgd.3185>
Path: utzoo!decvax!harpo!npoiv!npois!cbosgd!mark
X-Path: utzoo!decvax!harpo!npoiv!npois!cbosgd!mark
From: cbosgd!mark
Date: Mon Feb 28 01:13:56 1983
Subject: USENET interchanged standard posted
Posted: Sun Feb 27 21:11:57 1983
Received: Mon Feb 28 01:13:56 1983

The article following this one is the text of the proposed
standard for the interchange of messages among USENET sites.
I'd like to emphasize that this is a draft proposal, NOT a
final standard.  It is being posted to the net in order to
encourage comments and discussion.  Please put all discussion
either in this newsgroup ( or mail it to me if you
feel that is more appropriate.

The reason for having a standard is that there are now five
separate, full fledged implementations of news, all talking
to each other, and up until now the only specification for
how sites should communicate has been "whatever doesn't
break the code".  Needless to say, this is not very helpful
to someone who is producing a new implementation.  It just
all needed to be written down.  Please note that this is a
standard for the interchange of news between computer systems,
NOT a standard for the user interface.  Requesting new features
in the user interface is a different issue entirely.  However,
some improvements to the user interface require information
to be present in the news as it's exchanged, thus fields like
References and Organization.

This standard does provide for some technical advances over
B news 2.9.  Headers are now compatible with RFC 822, making
it possible (in theory) to use the same software to process
both news and mail.  (All mail will soon be in 822 format,
since 4.2BSD and some Bell Labs version of mail will soon
support it.  At last - a common, documented UNIX mail format!)
There are no longer any limitations on the length of newsgroup
names.  Replies will work properly, in spite of the route the
article happened to reach you by (assuming you have an internet
mailer on your system - if not the old method will continue to
work as well as it ever did for a reasonable period of time
[e.g., there are no plans to break it]).  Several other new features
exist, and you are encouraged to read the proposed standard
for details.

In suggesting changes to this document, please keep in mind that
any new features added must be implemented by at least five people,
so don't make them lightly.  B news 2.10 supports the full
standard as described here (well, almost), and will be made
available once it has been thoroughly tested.  (It's being
alpha tested right now, and the release is estimated to be
about a month off.)  Also please bear in mind that, once a
standard is adopted, it's pretty well cast in concrete.
Enhancements are possible, by some sort of mutual agreement,
but old features must continue to be supported essentially
forever, so if you see a better way to do something, let's
hear about it now!  Also bear in mind that we have an existing
network out there, and upward compatibility with sites running
older software is very important - don't suggest that we all
change to some totally incompatible format all at once.

The standard itself is pretty long - 17 pages of nroff output.
Hopefully nobody's /usr/spool will fill up on the way out.
It has some overstriking in it - if this causes you problems,
note that it's done with CR's, not BS's, so you can edit away
all of the line after the first CR if your printer can't overstrike.
The document is intended to be printed, not read at your CRT.

I'll post RFC 822 in a few days unless I'm asked not to - I want
to wait to try to avoid overflowing spool directories by posting
two big things at once.

	Mark Horton

Path: utzoo!decvax!harpo!npoiv!npois!cbosgd!mark
X-Path: utzoo!decvax!harpo!npoiv!npois!cbosgd!mark
From: cbosgd!mark
Date: Mon Feb 28 01:15:46 1983
Subject: Standard draft text itself
Posted: Sun Feb 27 21:13:11 1983
Received: Mon Feb 28 01:15:46 1983

                 Standard for Interchange of USENET Messages

                                Mark R. Horton

          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.) An existing
          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
          current ARPANET standard (RFC 822  as  of  this  writing).
          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.

          An example message is included to illustrate the fields.

                              February 23, 1983
                                  D R A F T

                                    - 2 -

               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: j...@eagle.uucp (Jerry Schwarz)
               Newsgroups: net.general
               Subject: Usenet Etiquette -- Please Read
               Message-ID: <6...@eagle.UUCP>
               Date: Friday, 19-Nov-82 16:14:55 EST
               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:

               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

                              February 23, 1983
                                  D R A F T

                                    - 3 -

          blank or tab) is allowed.

          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 ignored.)

          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
          should identify the same site as the Message-ID.

          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

                              February 23, 1983
                                  D R A F T

                                    - 4 -

          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
          m...@cbosgd.UUCP,  m...@cbosgd.uucp,  and m...@CBosgD.UUcp
          are all equivalent.  User names may or  may  not  be  case
          sensitive,   for   example,   B...@cbosgd.UUCP  might  be
          different from B...@cbosgd.UUCP.  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: m...@cbosgd.UUCP
               From: m...@cbosgd.UUCP (Mark Horton)
               From: Mark Horton 

          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

          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
          revision.   Eventually,  we  hope  to  accept all possible
          worldwide time zone  abbreviations,  including  the  usual
          American  zones  (PST, PDT, MST, MDT, CST, CDT, EST, EDT),

                              February 23, 1983
                                  D R A F T

                                    - 5 -

          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.

          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  ``''
          is permitted.

          If an article is received with a Newsgroups  line  listing
          some  valid newsgroups and some invalid newsgroups, a site
          should remove any invalid newsgroups from the  list.   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 should change the Newsgroups
          line to read ``Newsgroups: net.micro'', but  in  order  to
          allow  direct transmission from the local spool directory,
          A is permitted to pass the Newsgroups line unchanged to B.
          In  this  case,  B  should remove ``btl.general'' from the
          line immediately upon receipt of the message.

          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
          subject must begin with the four characters ``Re:  ''  and
          the References line is required.

          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

                              February 23, 1983
                                  D R A F T

                                    - 6 -

               "<" "string not containing >" ">"

          It is recommended that the Message-ID 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  "<4...@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

          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.

          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
          ``cbosgd!mhuxj!mhuxt'', ``cbosgd, mhuxj, mhuxt'', and even
          ``teklabs,     zehntel,     sri-unix@cca!decvax''      and
          `...@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp''     are     valid
          entries.  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.

          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

                              February 23, 1983
                                  D R A F T

                                    - 7 -

          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

          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

          2.2  Optional Headers

          2.2.1  Reply-To  This line has the same  format  as  From.
          If present, mailed replies to the author should be sent to
          the name given here.  Otherwise, replies are mailed to the
          name  on the From line.  (This does not prevent additional
          copies from being sent to recipients named by the replier,
          or  on  To  or  Cc lines.) The full name may be optionally
          given, in parentheses, as in the From line.

          2.2.2  Sender  This field is present only if the submitter
          manually enters a From line.  It is intended to record the
          entity responsible  for  submitting  the  article  to  the
          network,  and  should  be  verified by the software at the
          submitting site.

          For example, if John Smith is visiting CCA and  wishes  to
          post  an  article to the network, using friend Sarah Jones
          account, the message might read

               From: s...@ucbvax.uucp (John Smith)
               Sender: (Sarah Jones)

          If a gateway  program  enters  a  mail  message  into  the
          network at site sri-unix, the lines might read

               From: John....@CMU-CS-A.ARPA
               Sender: netw...@sri-unix.ARPA

          The primary purpose of this field is to be able  to  track
          down  articles to determine how they were entered into the
          network.  The  full  name  may  be  optionally  given,  in
          parentheses, as in the From line.

                              February 23, 1983
                                  D R A F T

                                    - 8 -

          2.2.3  Followup-To  This  line  has  the  same  format  as
          Newsgroups.   If  present,  follow-up  articles  are to be
          posted to the newsgroup(s) listed here.  If this  line  is
          not  present,  followups  are  posted  to the newsgroup(s)
          listed in the Newsgroups line, except  that  followups  to
          ``net.general'' should instead go to ``net.followup''.

          2.2.4  Date-Received  This line (formerly ``Received'') is
          in  a  legal  USENET date format.  It records the date and
          time that the article was  first  received  on  the  local
          system.   If  this  line  is  present  in an article being
          transmitted from one host to another, the  receiving  host
          should  ignore  it  and  replace it with the current date.
          Since this field is intended for local use only,  no  site
          is  required  to support it.  However, no site should pass
          this field on to another site unchanged.

          2.2.5  Expires  This line,  if  present,  is  in  a  legal
          USENET  date  format.  It specifies a suggested expiration
          date for the article.  If not present, the  local  default
          expiration date is used.

          This field is intended to be used  to  clean  up  articles
          with  a  limited usefulness, or to keep important articles
          around for longer than  usual.   For  example,  a  message
          announcing  an  upcoming  seminar could have an expiration
          date the day after the seminar, since the message  is  not
          useful  after the seminar is over.  Since local sites have
          local  policies  for  expiration  of  news  (depending  on
          available disk space, for instance), users are discouraged
          from providing expiration dates for articles unless  there
          is a natural expiration date associated with the topic.

          2.2.6  References  This field lists the  message  ID's  of
          any articles prompting the submission of this article.  It
          is required for all follow-up articles, and forbidden when
          a new subject is raised.  Implementations should provide a
          follow-up command, which allows a user to post a follow-up
          article.   This  command  should  generate  a Subject line
          which is the same as the original article, except that  if
          the original subject does not begin with ``Re: '' or ``re:
          '', the four characters ``Re: '' are inserted  before  the
          subject.   If  there is no References line on the original
          header, the References line should contain the message  ID
          of  the  original  article (including the angle brackets).
          If the original article does have a References  line,  the
          followup  article should have a References line containing
          the text of the  original  References  line,  a  comma,  a
          blank, and the message ID of the original article.

                              February 23, 1983
                                  D R A F T

                                    - 9 -

          2.2.7  Control  If an article contains a Control line, the
          article  is  a control message.  Control messages are used
          for communication among USENET host machines,  not  to  be
          read  by  users.   Control messages are distributed by the
          same newsgroup mechanism as ordinary messages.   The  body
          of the Control header line is the message to the host.

          For  upward  compatibility,  messages   that   match   the
          newsgroup   pattern   ``all.all.ctl''   should   also   be
          interpreted as control messages.  If no Control: header is
          present  on  such  messages,  the  subject  is used as the
          control message.  However, messages on newsgroups matching
          this pattern do not conform to this standard.

          2.2.8  Distribution   This  line  is  used  to  alter  the
          distribution scope of the message.  It has the same format
          as the Newsgroups  line.   User  subscriptions  are  still
          controlled  by  Newsgroups, but the message is sent to all
          systems subscribing to the newsgroups on the  Distribution
          line instead of the Newsgroups line.  Thus, a car for sale
          in New Jersey might have headers including

          2.2.9  Organization  The text of  this  line  is  a  short
          phrase  describing  the  organization  to which the sender
          belongs, or to which the machine belongs.  The  intent  of
          this  line  is  to  help  identify  the person posting the
          message, since site names are often cryptic enough to make
          it  hard  to  recognize the organization by the electronic

               Distribution: nj.all

          so that  it  would  only  go  to  persons  subscribing  to
  or  net.wanted within New Jersey.  The intent of
          this header is to further restrict the distribution  of  a
          newsgroup, not to increase it.  A local newsgroup, such as
          nj.crazy-eddie, will probably not be propagated  by  sites
          outside  New  Jersey  that do not show such a newsgroup as

          3.  Control Messages

          This section lists the control messages currently defined.
          The  body  of  the  Control header is the control message.
          Messages are a sequence of zero or more  words,  separated
          by  blanks.   The  first  word  is the name of the control
          message, remaining words are parameters  to  the  message.
          The  remainder  of  the header and the body of the message
          are also potential parameters; for example, the From  line

                              February 23, 1983
                                  D R A F T

                                    - 10 -

          might  suggest  an  address  to  which a response is to be

          3.1  Cancel


          If an article with the given message ID is present on  the
          local  system,  the  article is cancelled.  This mechanism
          allows a user to cancel an article once  the  article  has
          been distributed over the network.

          Only the author of the article or the local super user  is
          allowed to use this message.  The message should be denied
          unless the From field (or Sender if present) is  the  same
          as  the  From  field (or Sender if present) of the article
          being  cancelled.   The  verified  sender  of  the  cancel
          message  (Sender  if  present, otherwise From) must be the
          same as either the Sender or From field  of  the  original
          message.   A  verified  sender  in  the  cancel message is
          allowed to  match  an  unverified  From  in  the  original

          3.2  Ihave/Sendme


          This message is part  of  the  ``ihave/sendme''  protocol,
          which  allows  one  site  (say ``A'') to tell another site
          (``B'') that a particular message has been received on  A.
          Suppose  that site A receives article ``ucbvax.1234'', and
          wishes to transmit the article to site  B.   A  sends  the
          control  message  ``ihave  ucbvax.1234  A''  to site B (by
          posting it to newsgroup ``to.B'').  B  responds  with  the
          control  message  ``sendme  ucbvax.1234  B'' (on newsgroup
          to.A) if it has not already received  the  article.   Upon
          receiving the Sendme message, A sends the article to B.

          This protocol can be used to cut down on redundant traffic
          between  sites.  It is optional and should be used only if
          the particular situation makes it worthwhile.  Frequently,
          the  outcome  is  that,  since  most original messages are
          short, and since there is a high overhead to start sending
          a  new  message  with  UUCP,  it costs as much to send the
          Ihave as it would cost to send the article itself.

          One possible solution to this overhead problem is to batch
          requests.   Several  message  ID's  may  be  announced  or
          requested in one message.  A maximum of  15  message  ID's
          may be included in one message ID list.

                              February 23, 1983
                                  D R A F T

                                    - 11 -

          3.3  Newgroup


          This control message creates a new newsgroup with the name
          given.  Since no articles may be posted or forwarded until
          a newsgroup is created, this message is required before  a
          newsgroup  can  be  used.   The  body  of  the  message is
          expected to be a short paragraph describing  the  intended
          use of the newsgroup.

          3.4  Rmgroup


          This message removes a  newsgroup  with  the  given  name.
          Since  the  newsgroup  is  removed  from every site on the
          network, this  command  should  be  used  carefully  by  a
          responsible administrator.

          3.5  Sendsys

               sendsys (no arguments)

          The  ``sys''  file,  listing  all  neighbors   and   which
          newsgroups  are  sent  to each neighbor, will be mailed to
          the author of the control message (Reply-to,  if  present,
          otherwise  From).   This  information is considered public
          information, and it is  a  requirement  of  membership  in
          USENET  that  this  information  be  provided  on request,
          either automatically in response to this control  message,
          or  manually,  by mailing the requested information to the
          author of the message.  This information is used  to  keep
          the  map  of  USENET  up  to  date, and to determine where
          netnews is sent.  The format of the file  mailed  back  to
          the  author  is  not specified by this standard, since the
          reply is intended to be read by a human and not a program.

          3.6  Senduuname

               senduuname      (no arguments)

          The ``uuname'' program is run, and the output is mailed to
          the  author  of the control message (Reply-to, if present,
          otherwise From).  This program lists all uucp neighbors of
          the  local site.  This information is used to make maps of
          the UUCP network.  The sys file is not  the  same  as  the
          UUCP   L.sys   file.   The  L.sys  file  should  never  be
          transmitted to another party without the  consent  of  the
          sites whose passwords are listed therein.

                              February 23, 1983
                                  D R A F T

                                    - 12 -

          It is optional for a site  to  provide  this  information.
          Some  reply  should  be  made to the author of the control
          message, so that a transmission error won't be blamed.  It
          is  also  permissible for a site to run the uuname program
          (or in some other way determine the  uucp  neighbors)  and
          edit  the output, either automatically or manually, before
          mailing the reply back to the  author.   The  file  should
          contain  one  site  per line, beginning with the uucp site
          name.  Additional information may be  included,  separated
          from the site name by a blank or tab.  The phone number or
          password for the site should NOT be included, as the reply
          is  considered  to  be  in the public domain.  (The uuname
          program will send only the site name and  not  the  entire
          contents  of  the  L.sys  file,  thus,  phone  numbers and
          passwords are not transmitted.)

          3.7  Version

               version (no arguments)

          The name and version of the software running on the  local
          system  is  to be mailed back to the author of the article
          (Reply-to if present, otherwise From).

          4.  Transmission Methods

          USENET is not a physical network,  but  rather  a  logical
          network  resting  on  top  of  several  existing  physical
          networks.  These networks include, but are not limited to,
          UUCP,  the ARPANET, an Ethernet, the BLICN network, an NSC
          Hyperchannel, and a Berknet.  What is  important  is  that
          two  neighboring systems on USENET have some method to get
          a new article, in the format listed here, from one  system
          to  the other, and once on the receiving system, processed
          by the netnews software on that system.  (On UNIX systems,
          this  usually  means  the ``rnews'' program being run with
          the article on the standard input.)

          It is not  a  requirement  that  USENET  sites  have  mail
          systems  capable  of  understanding the ARPA Internet mail
          syntax, but  it  is  strongly  recommended.   Since  From,
          Reply-To,  and  Sender  lines  use  the  Internet  syntax,
          replies  will  be  difficult  or  impossible  without   an
          internet  mailer.   A  site without an internet mailer can
          attempt to use the Path header line for replies, but  this
          field  is not guaranteed to be a working path for replies.
          In any event,  any  site  generating  or  forwarding  news
          messages must have an internet address that allows them to
          receive mail from sites with internet  mailers,  and  they
          must include their internet address on their From line.

                              February 23, 1983
                                  D R A F T

                                    - 13 -

          4.1  Remote Execution

          Some networks permit direct remote command execution.   On
          these  networks,  news  may  be  forwarded by spooling the
          rnews command with the article on the standard input.  For
          example,  if  the remote system is called ``remote'', news
          would be sent over a UUCP link with the  command  ``uux  -
          remote!rnews'',  and on a Berknet, ``net -mremote rnews''.
          It is important that the article be spooled,  rather  than
          direct  real-time  remote  execution.  This is because, if
          the remote system is down, a direct execution command will
          fail,  and  the  article  will never be delivered.  If the
          article is spooled, it will eventually be  delivered  when
          both systems are up.

          4.2  Transfer by Mail

          On some systems, direct remote spooled  execution  is  not
          possible.   However, most systems support electronic mail,
          and a news article can be sent as mail.  One  approach  is
          to  send  a  mail  message  which is identical to the news
          message: the mail headers are the news  headers,  and  the
          mail  body  is the news body.  By convention, this mail is
          sent to the user ``newsmail'' on the remote machine.

          One problem with  this  method  is  that  it  may  not  be
          possible to convince the mail system that the From line of
          the message is valid, since the mail message was generated
          by  a program on a system different from the source of the
          news article.  Another  problem  is  that  error  messages
          caused  by  the  mail  transmission  would  be sent to the
          originator of the news article, who has  no  control  over
          news  transmission  between two cooperating hosts and does
          not know who  to  contact.   Transmission  error  messages
          should  be directed to a responsible contact person on the
          sending machine.

          A solution to this problem  is  to  encapsulate  the  news
          article  into a mail message, such that the entire article
          (headers and body) are  part  of  the  body  of  the  mail
          message.  The convention here is that such mail is sent to
          user ``rnews'' on the remote system.  A mail message  body
          is  generated  by prepending the letter ``N'' to each line
          of the news article,  and  then  attaching  whatever  mail
          headers  are convenient to generate.  The N's are attached
          to prevent any special lines  in  the  news  article  from
          interfering  with  mail  transmission,  and to prevent any
          extra lines inserted by the mailer (headers, blank  lines,
          etc.)  from  becoming part of the news article.  A program
          on the  receiving  machine  receives  mail  to  ``rnews'',
          extracting  the  article itself and invoking the ``rnews''

                              February 23, 1983
                                  D R A F T

                                    - 14 -

          program.  An example in this format might look like this:

               Date: Monday, 3-Jan-83 08:33:47 MST
               From: n...@cbosgd.UUCP
               Subject: network news article
               To: r...@npois.UUCP

               NRelay-Version: B 2.10  2/13/83 cbosgd.UUCP
               NPosting-Version: B 2.9 6/21/82 sask.UUCP
               NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
               NFrom: d...@sask.UUCP (Derek Andrew)
               NNewsgroups: net.test
               NSubject: necessary test
               NMessage-ID: <1...@sask.UUCP>
               NDate: Monday, 3-Jan-83 00:59:15 MST
               NThis really is a test.  If anyone out there more than 6
               Nhops away would kindly confirm this note I would
               Nappreciate it.  We suspect that our news postings
               Nare not getting out into the world.

          Using mail solves the spooling problem,  since  mail  must
          always  be  spooled  if  the  destination  host  is  down.
          However, it adds more overhead to the transmission process
          (to  encapsulate  and  extract  the  article) and makes it
          harder for software to give different priorities  to  news
          and mail.

          4.3  Batching

          Since news articles are usually short, and since  a  large
          number  of  messages are often sent between two sites in a
          day, it may make sense to batch  news  articles.   Several
          articles  can  be  combined  into one large article, using
          conventions agreed upon in advance by the two sites.   One
          such  batching  scheme  is  described  here;  its  use  is
          recommended but not required.

          News articles are  combined  into  a  UNIX  shell  script,
          invoking  the rnews program on each article.  For example,
          a batch of articles might look like this:

                              February 23, 1983
                                  D R A F T

                                    - 15 -

                #! /bin/sh
                rnews << 'EndOfNews'
                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: j...@eagle.uucp (Jerry Schwarz)
                Newsgroups: net.general
                Subject: Usenet Etiquette -- Please Read
                Message-ID: <6...@eagle.UUCP>
                Date: Friday, 19-Nov-82 16:14:55 EST

                Here is an important message about USENET Etiquette.
                rnews << 'EndOfNews'
                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: j...@eagle.uucp (Jerry Schwarz)
                Newsgroups: net.followup
                Subject: Notes on Etiquette article
                Message-ID: <6...@eagle.UUCP>
                Date: Friday, 19-Nov-82 17:24:12 EST

                There was something I forgot to mention in the last message.

          Batched news is recognized because the first character  in
          the  message  is ``#''.  The message is then passed to the
          UNIX shell for interpretation.  (For security  reasons,  a
          site  may  instead  wish to pass the batch to a restricted
          shell allowing only the ``rnews'' command.)

          5.  The News Propagation Algorithm

          This section describes the overall scheme  of  USENET  and
          the algorithm followed by sites in propagating news to the
          entire  network.   Since  all  sites   are   affected   by
          incorrectly  formatted articles and by propagation errors,
          it is important for the method to be standardized.

          USENET is a directed graph.  Each node in the graph  is  a
          host  computer,  each  arc  in the graph is a transmission
          path from one host to another host.  Each arc is  labelled
          with  a  newsgroup  pattern,  specifying  which  newsgroup
          classes are forwarded along  that  link.   Most  arcs  are
          bidirectional,  that  is,  if  site  A  sends  a  class of
          newsgroups to site B, then site B usually sends  the  same
          class  of  newsgroups to site A.  This bidirectionality is
          not, however, required.

                              February 23, 1983
                                  D R A F T

                                    - 16 -

          USENET is made up of many subnetworks.  Each subnet has  a
          name,  such  as  ``net''  or  ``btl''.  The special subnet
          ``net'' is defined to be USENET, although the union of all
          subnets may be a superset of USENET (because of sites that
          get local newsgroups but do not get net.all).  Each subnet
          is  a  connected  graph, that is, a path exists from every
          node to every other node in the subnet.  In addition,  the
          entire  graph is (theoretically) connected.  (In practice,
          some political considerations have caused some sites to be
          unable to post articles reaching the rest of the network.)

          An  article  is  posted  on  one  machine  to  a  list  of
          newsgroups.    That   machine  accepts  it  locally,  then
          forwards it to all its neighbors that are interested in at
          least one of the newsgroups of the message.  (Site A deems
          site  B  to  be  ``interested''  in  a  newsgroup  if  the
          newsgroup  matches  the  pattern  on  the arc from A to B.
          This pattern is stored in a file on the  A  machine.)  The
          sites  receiving  the  incoming article examine it to make
          sure they really want the article, accept it locally,  and
          then  in  turn forward the article to all their interested
          neighbors.   This  process  continues  until  the   entire
          network has seen the article.

          An important part of the algorithm is  the  prevention  of
          loops.   The  above  process would cause a message to loop
          along a cycle forever.  In particular, when site  A  sends
          an  article to site B, site B will send it back to site A,
          which will send it to site B, and so on.  One solution  to
          this  is  the history mechanism.  Each site keeps track of
          all articles  it  has  seen  (by  their  message  ID)  and
          whenever an article comes in that it has already seen, the
          incoming article is discarded immediately.  This  solution
          is   sufficient   to   prevent   loops,   but   additional
          optimizations can be made to  avoid  sending  articles  to
          sites that will simply throw them away.

          One optimization is that an article should never  be  sent
          to  a machine listed in the Path line of the header.  When
          a machine name is in the Path line, the message  is  known
          to  have passed through the machine.  Another optimization
          is that, if the article originated on site A, then site  A
          has   already  seen  the  article.   (Origination  can  be
          determined by the Posting-Version line.)

          Thus, if an article is posted to  newsgroup  ``net.misc'',
          it  will match the pattern ``net.all'' (where ``all'' is a
          metasymbol that matches any string), and will be forwarded
          to  all  sites that subscribe to net.all (as determined by
          what their neighbors send them).  These sites make up  the
          ``net''  subnetwork.  An article posted to ``btl.general''

                              February 23, 1983
                                  D R A F T

                                    - 17 -

          will reach all sites receiving ``btl.all'', but  will  not
          reach  sites  that do not get ``btl.all''.  In effect, the
          articles  reaches  the  ``btl''  subnetwork.   An  article
          posted  to newsgroups ``net.micro,btl.general'' will reach
          all sites subscribing to either of the two classes.

                              February 23, 1983
                                  D R A F T

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.