v07i048: 2.11 News Documentation and Conversion, Part08/08

[sources-request at mirror.UUCP]

Submitted by: seismo!rick (Rick Adams)
Mod.sources: Volume 7, Issue 48
Archive-name: 2.11news/Part08

[  I held off posting for a couple of days becuase of the West Coast
   "newsquake."  --r$  ]

Path: seismo!rick
From: rick at seismo.CSS.GOV (Rick Adams)
Newsgroups: mod.sources
Subject: news 2.11 documentation (6 of 6)
Message-ID: <41912 at beno.seismo.CSS.GOV>
Date: 30 Oct 86 21:44:19 GMT
Distribution: world
Organization: Center for Seismic Studies, Arlington, VA
Lines: 1490

# To extract, sh this file
#
#	news 2.11 documentation 6 of 6
#
if test ! -d doc
then
	mkdir doc
fi
echo x - doc/standard.mn 1>&2
sed 's/.//' >doc/standard.mn <<'*-*-END-of-doc/standard.mn-*-*'
-.ds h0 "RFC xxx
-.ds h1 DRAFT
-.ds h2 %
-.ds f0 "Standard for Interchange of USENET Messages
-.ds f1
-.ds f2 "October 20, 1986
-.mt
-Standard for Interchange of USENET Messages
-[Obsoletes RFC 850]
-.au
-Mark R. Horton
-.ai
-AT&T Bell Laboratories
-Columbus, OH  43213
-.au
-Revised for B 2.11 news by Rick Adams
-.hn
-Introduction
-.pg
-This document defines the standard format for the interchange
-of network News messages among USENET hosts.
-It describes the format for messages 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.
-.pg
-There are five sections to this document.
-Section two 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.
-.hn
-Message Format
-.pg
-The primary consideration in choosing a message format is
-that it fit in with existing tools as well as possible.
-Existing tools include both implementations of mail and news.
-(The
-.i 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 messages
-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 message
-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 message.
-In any situation where this standard conflicts with the ARPANET standard,
-RFC 822 should be considered correct and this standard in error.
-.pg
-An example message is included to illustrate the fields.
-.sd
-From: jerry at eagle.ATT.COM (Jerry Schwarz)
-Path: cbosgd!mhuxj!mhuxt!eagle!jerry
-Newsgroups: news.announce
-Subject: Usenet Etiquette -- Please Read
-Message-ID: <642 at eagle.ATT.COM>
-Date: Fri, 19 Nov 82 16:14:55 GMT
-Followup-To: news.misc
-Expires: Sat, 1 Jan 83 00:00:00 -0500
-Organization: AT&T Bell Laboratories, Murray Hill
-
-The body of the message comes here, after a blank line.
-.ed
-Here is an example of a message in the old format
-(before the existence of this standard).
-It is recommended that implementations also accept messages
-in this format to ease upward conversion.
-.sd
-From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
-Newsgroups: news.misc
-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 message comes here, after a blank line.
-.ed
-Some news systems transmit news in the
-.pa A
-format,
-which looks like this:
-.sd
-Aeagle.642
-news.misc
-cbosgd!mhuxj!mhuxt!eagle!jerry
-Fri Nov 19 16:14:55 1982
-Usenet Etiquette - Please Read
-The body of the message comes here, with no blank line.
-.ed
-.pg
-A message 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
-.hf 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.
-.pg
-Certain headers are required,
-and certain other headers are optional.
-Any unrecognized headers are allowed,
-and will be passed through unchanged.
-The required headers are
-.hf From ,
-.hf Date ,
-.hf Newsgroups ,
-.hf Subject ,
-.hf Message-ID ,
-and
-.hf Path .
-The optional headers are
-.hf Followup-To ,
-.hf Expires ,
-.hf Reply-To ,
-.hf Sender ,
-.hf References ,
-.hf Control ,
-.hf Distribution ,
-.hf Keywords ,
-.hf Summary ,
-.hf Approved ,
-.hf Lines ,
-.hf Xref ,
-and
-.hf Organization .
-.hn 2
-Required Headers
-.hn 3
-From
-.pg
-The
-.hf 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 message,
-unless the
-.hf Sender
-header is present,
-in which case the
-.hf From
-header might not be verified.
-Note that in all host and domain names,
-upper and lower case are considered the same,
-thus
-.cf mark at cbosgd.ATT.COM ,
-.cf mark at cbosgd.att.com ,
-and
-.cf mark at CBosgD.ATt.COm
-are all equivalent.
-User names may or may not be case sensitive, for example,
-.cf Billy at cbosgd.ATT.COM
-might be different from
-.cf BillY at cbosgd.ATT.COM .
-Programs should avoid changing the case of electronic addresses
-when forwarding news or mail.
-.pg
-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
-.hf 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 message,
-or it appears before an electronic address which is enclosed in angle brackets.
-Thus,
-the three permissible forms are:
-.sd
-From: mark at cbosgd.ATT.COM
-From: mark at cbosgd.ATT.COM (Mark Horton)
-From: Mark Horton <mark at cbosgd.ATT.COM>
-.ed
-Full names may contain any printing ASCII characters from space through tilde,
-except that they may not contain
-\&\*(lq(\*(rq (left parenthesis),
-\&\*(lq)\*(rq (right parenthesis),
-\&\*(lq<\*(rq (left angle bracket),
-or \*(lq>\*(rq (right angle bracket).
-Additional restrictions may be placed on full names by the mail standard,
-in particular,
-the characters
-\&\*(lq,\*(rq (comma),
-\&\*(lq:\*(rq (colon),
-\&\*(lq@\*(rq (at),
-\&\*(lq!\*(rq (bang),
-\&\*(lq/\*(rq (slash),
-\&\*(lq=\*(rq (equal),
-and \*(lq;\*(rq (semicolon) are inadvisable in full names.
-.hn 3
-Date
-.pg
-The
-.hf Date
-line (formerly
-.hf Posted )
-is the date,
-in a format that must be acceptable both to the ARPANET
-and to the
-.i getdate (3)
-routine,
-that the message was originally posted to the network.
-This date remains unchanged as the message is propagated
-throughout the network.
-One format that is acceptable to both is:
-.sd c
-\f2Wdy\fP, \f2DD\fP\ \f2Mon\fP\ \f2YY\fP \f2HH\fP:\f2MM\fP:\f2SS\fP \f2TIMEZONE\fP
-.ed
-Several examples of valid dates appear in the sample
-message above.
-Note in particular that
-.i ctime (3)
-format:
-.sd c
-\f2Wdy\fP \f2Mon\fP \f2DD\fP \f2HH\fP:\f2MM\fP:\f2SS\fP \f2YYYY\fP
-.ed
-is
-.i 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.
-.pg
-There is no hope of having a complete list of timezones.
-Universal Time (GMT), the North American timezones
-(PST, PDT, MST, MDT, CST, CDT, EST, EDT)  and the
-+/\-hhmm offset specifed in RFC822 should be supported.
-It is recommended that times in message headers be transmitted in GMT
-and displayed in the local time zone.
-.hn 3
-Newsgroups
-.pg
-The
-.hf Newsgroups
-line specifies the newsgroup or newsgroups in which the message belongs.
-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.
-.pg
-Wildcards
-.i e\f1.\fPg ., (
-the word
-.ng all)
-are never allowed in a
-.hf Newsgroups
-line.
-For example,
-a newsgroup
-.ng comp.all
-is illegal,
-although a newsgroup name
-.ng rec.sport.football
-is permitted.
-.pg
-If a message is received with a
-.hf Newsgroups
-line listing some valid newsgroups and some invalid newsgroups,
-a host should not remove invalid newsgroups from the list.
-Instead,
-the invalid newsgroups should be ignored.
-For example,
-suppose host
-.cn A
-subscribes to the classes
-.ng btl.all
-and 
-.ng comp.all ,
-and exchanges news messages with host
-.cn B ,
-which subscribes to
-.ng comp.all
-but not
-.ng btl.all .
-Suppose
-.cn A
-receives a message with
-.sd c
-Newsgroups: comp.unix,btl.general
-.ed
-This message is passed on to
-.cn B
-because
-.cn B
-receives
-.ng comp.unix ,
-but
-.cn B
-does not receive
-.ng btl.general .
-.cn A
-must leave the
-.hf Newsgroups
-line unchanged.
-If it were to remove
-.ng btl.general ,
-the edited header could eventually re-enter the
-.ng btl.all
-class,
-resulting in a message that is not shown to users subscribing to
-.ng btl.general .
-Also,
-follow-ups from outside
-.ng btl.all
-would not be shown to such users.
-.hn 3
-Subject
-.pg
-The
-.hf Subject
-line
-(formerly
-.hf Title )
-tells what the message is about.
-It should be suggestive enough of the contents of the message
-to enable a reader to make a decision whether to read the message
-based on the subject alone.
-If the message is submitted in response to another message
-.i e\f1.\fPg ., (
-is a
-.i follow-up )
-the default subject should begin with the four characters \*(lqRe: \*(rq
-and the
-.hf References
-line is required.
-For follow-ups, the use of the 
-.hf Summary
-line is encouraged.
-.hn 3
-Message-ID
-.pg
-The
-.hf Message-ID
-line gives the message a unique identifier.
-The Message-ID may not be reused during the lifetime of any previous message
-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
-.sd c
-<\f2string not containing blank or \*(lq>\*(rq\fP>
-.ed
-In order to conform to RFC 822,
-the Message-ID must have the format
-.sd c
-<\f2unique\fP@\f2full_domain_name\fP>
-.ed
-where
-.i "full_domain_name"
-is the full name of the host at which the message entered the network,
-including a domain that host is in,
-and
-.i unique
-is any string of printing ASCII characters,
-not including
-\*(lq<\*(rq (left angle bracket),
-\*(lq>\*(rq (right angle bracket),
-or \*(lq@\*(rq (at sign).
-For example,
-the
-.i unique
-part could be an integer representing a sequence number
-for messages submitted to the network,
-or a short string derived from the date and time the message was created.
-For example,
-a valid Message-ID for a message submitted from host
-.cn ucbvax
-in domain
-.cf Berkeley.EDU
-would be
-.cf <4123 at ucbvax.Berkeley.EDU> .
-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,
-that it is unique in the first 14 characters, nor that
-is does not contain a \*(lq/\*(rq.
-.pg
-The angle brackets are considered part of the Message-ID.
-Thus,
-in references to the Message-ID,
-such as the
-.pa ihave/sendme
-and
-.pa cancel
-control messages,
-the angle brackets are included.
-White space characters
-.i e\f1.\fPg ., (
-blank and tab)
-are not allowed in a Message-ID.
-Slashes (\*(lq/\*(rq) are strongly discouraged.
-All characters between the angle brackets must be printing ASCII characters.
-.hn 3
-Path
-.pg
-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
-.hf Path
-line.
-The names may be separated by any punctuation character or characters
-(except \*(lq.\*(rq which is considered part of the hostname).
-Thus, the following are valid entries:
-.sd c
-cbosgd!mhuxj!mhuxt
-cbosgd, mhuxj, mhuxt
- at cbosgd.ATT.COM, at mhuxj.ATT.COM, at mhuxt.ATT.COM
-teklabs, zehntel, sri-unix at cca!decvax
-.ed
-(The latter path indicates a message that passed through
-.cn decvax ,
-.cn cca ,
-.cn sri-unix ,
-.cn zehntel ,
-and
-.cn teklabs ,
-in that order.)
-Additional names should be added from the left.
-For example,
-the most recently added name in the third example was
-.cn teklabs .
-Letters,
-digits,
-periods and hyphens are considered part of host names;
-other punctuation,
-including blanks,
-are considered separators.
-.pg
-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.
-.pg
-The
-.hf 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
-.cn A
-sends a message to host
-.cn B ,
-the
-.hf Path
-line includes
-.cn A ,
-so that host
-.cn B
-will not immediately send the message back to host
-.cn 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.
-.pg
-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
-.cf A!X!Y!Z
-is passed from host
-.cn A
-to host
-.cn B ,
-.cn B
-will add its own name to the path when it receives the message from
-.cn A ,
-.i e\f1.\fPg .,
-.cf \*(lqB!A!X!Y!Z\*(rq .
-If
-.cn B
-then passes the message on to
-.cn C ,
-the message sent to
-.cn C
-will contain the path
-.cf B!A!X!Y!Z ,
-and when
-.cn C
-receives it,
-.cn C
-will change it to
-.cf C!B!A!X!Y!Z .
-.pg
-Special upward compatibility note:
-Since the
-.hf From ,
-.hf Sender ,
-and
-.hf 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
-.hf 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
-.cf !
-at the front of the path,
-and of starting the path with the host name,
-an
-.cf ! ,
-and the user name,
-should be maintained when possible.
-.hn 2
-Optional Headers
-.hn 3
-Reply-To
-.pg
-This line has the same format as
-.hf 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
-.hf From
-line.
-(This does not prevent additional copies from being sent to recipients
-named by the replier,
-or on
-.hf To
-or
-.hf Cc
-lines.)
-The full name may be optionally given,
-in parentheses,
-as in the
-.hf From
-line.
-.hn 3
-Sender
-.pg
-This field is present only if the submitter manually enters a
-.hf From
-line.
-It is intended to record the entity responsible
-for submitting the message to the network.
-It  should be verified by the software at the submitting host.
-.pg
-For example,
-if John Smith is visiting CCA and wishes to post a message to the network,
-using friend Sarah Jones' account,
-the message might read
-.sd
-From: smith at ucbvax.Berkeley.EDU (John Smith)
-Sender: jones at cca.COM (Sarah Jones)
-.ed
-If a gateway program enters a mail message into the network at host
-.cn unix.SRI.COM ,
-the lines might read
-.sd
-From: John.Doe at A.CS.CMU.EDU
-Sender: network at unix.SRI.COM
-.ed
-The primary purpose of this field is to be able to track down messages
-to determine how they were entered into the network.
-The full name may be optionally given,
-in parentheses,
-as in the
-.hf From
-line.
-.hn 3
-Followup-To
-.pg
-This line has the same format as
-.hf Newsgroups .
-If present,
-follow-up messages are to be posted
-to the newsgroup or newsgroups listed here.
-If this line is not present,
-follow-ups are posted to the newsgroup or newsgroups listed in the
-.hf Newsgroups
-line.
-.pg
-If the keyword
-.i poster
-is present, follow-up messages are not permitted. The message should
-be mailed to the submitter of the message via mail.
-.hn 3
-Expires
-.pg
-This line,
-if present,
-is in a legal USENET date format.
-It specifies a suggested expiration date for the message.
-If not present,
-the local default expiration date is used.
-.P
-This field is intended to be used to clean up
-messages with a limited usefulness,
-or to keep important messages 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 hosts have local policies for expiration of news
-(depending on available disk space,
-for instance),
-users are discouraged from providing expiration dates for messages
-unless there is a natural expiration date associated with the topic.
-System software should almost never provide a default
-.hf Expires
-line.
-Leave it out and allow local policies to be used
-unless there is a good reason not to.
-.hn 3
-References
-.pg
-This field lists the Message-ID's of any messages prompting
-the submission of this message.
-It is required for all follow-up message,
-and forbidden when a new subject is raised.
-Implementations should provide a follow-up command,
-which allows a user to post a follow-up message.
-This command should generate a
-.hf Subject
-line which is the same as the original message,
-except that if the original subject does not begin
-with \*(lqRe: \*(rq or \*(lqre: \*(rq,
-the four characters \*(lqRe: \*(rq are inserted before the subject.
-If there is no
-.hf References
-line on the original header,
-the
-.hf References
-line should contain the Message-ID of the original message
-(including the angle brackets).
-If the original message does have a
-.hf References
-line,
-the follow-up message should have a
-.hf References
-line containing the text of the original
-.hf References
-line,
-a blank,
-and the Message-ID of the original message.
-.pg
-The purpose of the
-.hf References
-header is to allow messages to be grouped into conversations
-by the user interface program.
-This allows conversations within a newsgroup to be kept together,
-and potentially users might shut off entire conversations
-without unsubscribing to a newsgroup.
-User interfaces need not make use of this header,
-but all automatically generated follow-ups should generate the
-.hf References
-line for the benefit of systems that do use it,
-and manually generated follow-ups
-.i e\f1.\fPg ., (
-typed in well after the original message has been printed by the machine)
-should be encouraged to include them as well.
-.pg
-It is permissible to not include the entire previous 
-.hf References
-line if it is too long. An attempt should be made to include a reasonable
-number of backwards references.
-.hn 3
-Control
-.pg
-If a message contains a
-.hf Control
-line,
-the message 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
-.hf Control
-header line is the message to the host.
-.pg
-For upward compatibility,
-messages that match the newsgroup pattern
-.ng all.all.ctl
-should also be interpreted as control messages.
-If no
-.hf 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.
-.pg
-Also for upward compatibility,
-if the first 4 characters of the 
-.hf Subject:
-line are \*(lqcmsg\*(rq, the rest of the
-.hf Subject:
-line should be interpreted as a control message.
-.hn 3
-Distribution
-.pg
-This line is used to alter the distribution scope of the message.
-It is a comma separated list similar to the 
-.hf Newsgroups
-line.  User subscriptions are still controlled by
-.hf Newsgroups ,
-but the message is sent to all systems subscribing to the newsgroups
-on the
-.hf Distribution
-line in addition to the
-.hf Newsgroups
-line.
-For the message to be transmitted, the receiving site must normally receive
-one of the specified newsgroups
-.b AND
-must receive one of the specified distributions.
-Thus, 
-a car for sale in New Jersey might have headers including
-.sd
-Newsgroups: rec.auto,misc.forsale
-Distribution: nj,ny
-.ed
-so that it would only go to persons subscribing to
-.ng rec.auto
-or
-.ng misc.forsale
-within New Jersey or New York.
-The intent of this header is to restrict the distribution of a newsgroup
-further, not to increase it.  A local newsgroup, such as
-.ng nj.crazy-eddie ,
-will probably not be propagated by hosts outside New Jersey
-that do not show such a newsgroup as valid.
-A follow-up message should default to the same
-.hf Distribution
-line as the original message, but the user can change it to a more limited one,
-or escalate the distribution if it was originally restricted
-and a more widely distributed reply is appropriate.
-.hn 3
-Organization
-.pg
-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 host names are often cryptic enough to make it hard
-to recognize the organization by the electronic address.
-.hn 3
-Keywords
-.pg
-A few, well selected keywords identifying the message should be on
-this line. This is used as an aid in determining if this message is
-interesting to the reader.
-.hn 3
-Summary
-.pg
-This line should contain a brief summary of the message. It is
-usually used as part of a follow-up to another message. Again, it is
-very useful to the reader in determining whether to read the message.
-.hn 3
-Approved
-.pg
-This line is required for any message posted to a moderated newsgroup.
-It should be added by the moderator and consist of his mail address.
-It is also required with certain control messages.
-.hn 3
-Lines
-.pg
-This contains a count of the number of lines in the body of the message.
-.hn 3
-Xref
-.pg
-This line contains the name of the host (with domains omitted) and a
-white space separated list of colon separated pairs of newsgroup names
-and message numbers. These are the newsgroups listed in the
-.hf Newsgroups
-line and the corresponding message numbers from the spool directory.
-.pg
-This is only of value to the local system, so it should not be transmitted.
-For example, in:
-.sd c
-Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
-From: reid at decwrl.DEC.COM (Brian Reid)
-Newsgroups: news.lists,news.groups
-Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
-Message-ID: <5658 at decwrl.DEC.COM>
-Date: 1 Oct 86 11:26:15 GMT
-Organization: DEC Western Research Laboratory
-Lines: 441
-Approved: reid at decwrl.UUCP
-Xref: seismo news.lists:461 news.groups:6378
-.ed
-the 
-.hf Xref
-line shows that the message is message number 461 in the newsgroup
-.b news.lists ,
-and message number 6378 in the newsgroup
-.b news.groups ,
-on host 
-.i seismo .
-This information may be used by certain user interfaces.
-.hn 1
-Control Messages
-.pg
-This section lists the control messages currently defined.
-The body of the
-.hf Control
-header is the control message.
-Messages are a sequence of zero or more words,
-separated by white space (blanks or tabs).
-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
-.hf From
-line might suggest an address to which a response is to be mailed.
-.pg
-Implementors and administrators may choose to allow control messages
-to be carried out automatically,
-or to queue them for manual processing.
-However,
-manually processed messages should be dealt with promptly.
-.pg
-Failed control messages should NOT be mailed to the originator of the message,
-but to the local \*(lqusenet\*(rq account.
-.hn 2
-Cancel
-.pg l
-.sd
-cancel <Message-ID>
-.ed
-If a message with the given Message-ID is present on the local system,
-the message is cancelled.
-This mechanism allows a user to cancel a message
-after the message has been distributed over the network.
-.pg
-If the system is unable to cancel the message as requested, it should not
-forward the cancellation request to its neighbor systems.
-.pg
-Only the author of the message or the local news administrator
-is allowed to send this message.
-The verified sender of a message is the
-.hf Sender
-line,
-or if no
-.hf Sender
-line is present,
-the
-.hf From
-line.
-The verified sender of the cancel message must be the same
-as either the
-.hf Sender
-or
-.hf From
-field of the original message.
-A verified sender in the cancel message is allowed to match an unverified
-.hf From
-in the original message.
-.hn 2
-Ihave/Sendme
-.pg l
-.sd
-ihave <Message-ID list> [<remotesys>]
-sendme <Message-ID list> [<remotesys>]
-.ed
-This message is part of the
-.pa ihave/sendme
-protocol,
-which allows one host
-(say
-.cn A )
-to tell another host
-.cn B ) (
-that a particular message has been received on
-.cn A .
-Suppose that host
-.cn A
-receives message
-.cf <1234 at ucbvax.Berkeley.edu> ,
-and wishes to transmit the message to host
-.cn B .
-.cn A
-sends the control message
-.cf "ihave <1234 at ucbvax.Berkeley.edu> A"
-to host
-.cn B
-(by posting it to newsgroup
-.bi B ). \f3to.\fP
-.cn B
-responds with the control message
-.cf "sendme <1234 at ucbvax.Berkeley.edu> B"
-(on newsgroup
-.bi A ) \f3to.\fP
-if it has not already received the message.
-Upon receiving the
-.pa sendme
-message,
-.cn A
-sends the message to
-.cn B .
-.pg
-This protocol can be used to cut down on redundant traffic between hosts.
-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
-.pa ihave
-as it would cost to send the message itself.
-.pg
-One possible solution to this overhead problem is to batch requests.
-Several Message-ID's may be announced or requested in one message.
-If no Message-ID's are listed in the control message,
-the body of the message should be scanned for Message-ID's,
-one per line.
-.hn 2
-Newgroup
-.sd
-newgroup <groupname> [moderated]
-.ed
-.pg
-This control message creates a new newsgroup with the given name.
-Since no messages 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.
-.pg
-If the second argument is present and it is the keyword
-.i moderated ,
-the group should be created moderated instead of the default of unmoderated.
-The 
-.pa newgroup
-message should be ignored unless there is an
-.hf Approved
-line in the same message header.
-.hn 2
-Rmgroup
-.sd
-rmgroup <groupname>
-.ed
-.pg
-This message removes a newsgroup with the given name.
-Since the newsgroup is removed from every host on the network,
-this command should be used carefully by a responsible administrator.
-The rmgroup message should be ignored unless there is an
-.hf Approved:
-line in the same message header.
-.hn 2
-Sendsys
-.sd
-sendsys	(no arguments)
-.ed
-.pg
-The
-.i sys
-file,
-listing all neighbors and which newsgroups are sent to each neighbor,
-will be mailed to the author of the control message
-.hf Reply-To , (
-if present,
-otherwise
-.hf 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.
-.pg
-The format of the file mailed back to the author
-should be the same as that of the
-.i sys
-file.
-This format has one line per neighboring host
-(plus one line for the local host),
-containing four colon separated fields.
-The first field has the host name of the neighbor,
-the second field has a newsgroup pattern
-describing the newsgroups sent to the neighbor.
-The third and fourth fields are not defined by this standard.
-The
-.i sys
-file is
-.b not
-the same as the UUCP
-.i L.sys
-file.
-A sample response is:
-.sd
-From: cbosgd!mark  (Mark Horton)
-Date: Sun, 27 Mar 83 20:39:37 -0500
-Subject: response to your sendsys request
-To: mark at cbosgd.ATT.COM
-
-Responding-System: cbosgd.ATT.COM
-cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,test
-ucbvax:world,comp,to.ucbvax:L:
-cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
-cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
-sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
-npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
-mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
-.ed
-.hn 2
-Senduuname
-.pg l
-.sd
-senduuname	(no arguments)
-.ed
-The
-.i uuname (1)
-program is run,
-and the output is mailed to the author of the control message
-.hf Reply-to , (
-if present,
-otherwise
-.hf From ).
-This program lists all UUCP neighbors of the local host.
-This information is used to make maps of the UUCP network.
-The
-.i L.sys
-file should
-.b never
-be transmitted to another party
-without the consent of the hosts whose passwords are listed therein.
-.pg
-It is optional for a host 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 host to run the
-.i 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 host per line,
-beginning with the UUCP host name.
-Additional information may be included,
-separated from the host name by a blank or tab.
-The phone number or password for the host should
-.ng not
-be included,
-as the reply is considered to be in the public domain.
-(The
-.i uuname
-program will send only the host name and not the entire contents of the
-.i L.sys
-file,
-thus,
-phone numbers and passwords are not transmitted.)
-.pg
-The purpose of this message was to generate and maintain UUCP mail routing maps.
-Thus, connections over which mail can be sent using the
-.cf host!user
-syntax should be included,
-regardless of whether the link is actually a UUCP link at the physical level.
-If a mail router should use it,
-it should be included.
-Since all information sent in response to this message is optional,
-hosts are free to edit the list,
-deleting secret or private links they do not wish to publicize.
-This control message is not used any more.
-.hn 2
-Version
-.pg l
-.sd
-version	(no arguments)
-.ed
-The name and version of the software running on the local system
-is to be mailed back to the author of the message
-.hf Reply-to "" (
-if present,
-otherwise
-.hf From ).
-.hn 2
-checkgroups
-.pg
-The message body is a list of \*(lqofficial\*(rq newsgroups and their
-description, one group per line.  They are compared against the  list
-of active newsgroups on the current host. The names of any obsolete or new 
-newsgroups are mailed to the user \*(lqusenet\*(rq and descriptions  of the
-new newsgroups are added to the help file used when posting news.
-.hn 1
-Transmission Methods
-.pg
-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 message,
-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
-.ux
-systems,
-this usually means the
-.i rnews
-program being run with the message on the standard input.)
-.pg
-It is not a requirement that USENET hosts have mail systems
-capable of understanding the ARPA Internet mail syntax,
-but it is strongly recommended.
-Since
-.hf From ,
-.hf Reply-To ,
-and
-.hf Sender
-lines use the Internet syntax, 
-replies will be difficult or impossible without an internet mailer.
-A host without an internet mailer can attempt to use the
-.hf Path
-header line for replies,
-but this field is not guaranteed to be a working path for replies.
-In any event,
-any host generating or forwarding news messages
-must have an internet address that allows them
-to receive mail from hosts with internet mailers,
-and they must include their internet address on their From line.
-.hn 2
-Remote Execution
-.pg
-Some networks permit direct remote command execution.
-On these networks,
-news may be forwarded by spooling the
-.i rnews
-command with the message on the standard input.
-For example,
-if the remote system is called
-.cn remote ,
-news would be sent over a UUCP link with the command
-.sd c
-uux \- remote!rnews
-.ed
-and on a Berknet,
-.sd c
-net \-mremote rnews
-.ed
-It is important that the message be sent via a reliable mechanism,
-normally involving the possibility of spooling,
-rather than direct real-time remote execution.
-This is because,
-if the remote system is down,
-a direct execution command will fail,
-and the message will never be delivered.
-If the message is spooled,
-it will eventually be delivered when both systems are up.
-.hn 2
-Transfer by Mail
-.pg
-On some systems,
-direct remote spooled execution is not possible.
-However,
-most systems support electronic mail,
-and a news message 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
-.i newsmail
-on the remote machine.
-.pg
-One problem with this method is that it may not be possible to convince
-the mail system that the
-.hf 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 message.
-Another problem is that error messages caused by the mail transmission
-would be sent to the originator of the news message,
-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.
-.pg
-A solution to this problem is to encapsulate the news message
-into a mail message, such that the entire message
-(headers and body)
-are part of the body of the mail message.
-The convention here is that such mail is sent to user
-.i rnews
-on the remote system.
-A mail message body is generated by prepending the letter
-.qp N
-to each line of the news message,
-and then attaching whatever mail headers are convenient to generate.
-The
-.qp N 's
-are attached to prevent any special lines in the news message
-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 message.
-A program on the receiving machine receives mail to
-.i rnews ,
-extracting the message itself and invoking the
-.i rnews
-program.
-An example in this format might look like this:
-.sd
-Date: Mon, 3 Jan 83 08:33:47 MST
-From: news at cbosgd.ATT.COM
-Subject: network news message
-To: rnews at npois.ATT.COM
-
-NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
-NFrom: derek at sask.UUCP (Derek Andrew)
-NNewsgroups: misc.test
-NSubject: necessary test
-NMessage-ID: <176 at sask.UUCP>
-NDate: Mon, 3 Jan 83 00:59:15 MST
-N
-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.
-N
-.ed
-.pg
-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 message)
-and makes it harder for software to give different priorities
-to news and mail.
-.hn 2
-Batching
-.pg
-Since news messages are usually short,
-and since a large number of messages
-are often sent between two hosts in a day,
-it may make sense to batch news messages.
-Several messages can be combined into one large message,
-using conventions agreed upon in advance by the two hosts.
-One such batching scheme is described here;
-its use is highly recommended.
-.pg
-News messages are combined into a script, separated by a header of the form:
-.sd
-#! rnews 1234
-.ed
-where
-.i 1234
-is the length,
-in bytes,
-of the message.
-Each such line is followed by a message containing the given number of bytes.
-(The newline at the end of each line of the message is counted as one byte,
-for purposes of this count, even if it is stored as
-.qc "CARRIAGE RETURN\s+2><\s-2LINE FEED" \&.)
-For example,
-a batch of message might look like this:
-.sd
-#! rnews 239
-From: jerry at eagle.ATT.COM (Jerry Schwarz)
-Path: cbosgd!mhuxj!mhuxt!eagle!jerry
-Newsgroups: news.announce
-Subject: Usenet Etiquette -- Please Read
-Message-ID: <642 at eagle.ATT.COM>
-Date: Fri, 19 Nov 82 16:14:55 EST
-Approved: mark at cbosgd.ATT.COM
-
-Here is an important message about USENET Etiquette.
-#! rnews 234
-From: jerry at eagle.ATT.COM (Jerry Schwarz)
-Path: cbosgd!mhuxj!mhuxt!eagle!jerry
-Newsgroups: news.announce
-Subject: Notes on Etiquette message
-Message-ID: <643 at eagle.ATT.COM>
-Date: Fri, 19 Nov 82 17:24:12 EST
-Approved: mark at cbosgd.ATT.COM
-
-There was something I forgot to mention in the last message.
-.ed
-Batched news is recognized because the first character in the message is
-.qp # .
-The message is then passed to the unbatcher for interpretation.
-.pg
-The second argument (in this example
-.i rnews ),
-determines which batching scheme is being used. Cooperating hosts
-may use whatever scheme is appropriate for them.
-.hn 1
-The News Propagation Algorithm
-.pg
-This section describes the overall scheme of USENET and the algorithm
-followed by hosts in propagating news to the entire network.
-Since all hosts are affected by incorrectly formatted messages
-and by propagation errors,
-it is important for the method to be standardized.
-.pg
-USENET is a directed graph.
-Each node in the graph is a host computer,
-and each arc in the graph is a transmission path
-from one host to another host.
-Each arc is labeled with a newsgroup pattern,
-specifying which newsgroup classes are forwarded along that link.
-Most arcs are bidirectional,
-that is,
-if host
-.cn A
-sends a class of newsgroups to host
-.cn B ,
-then host
-.cn B
-usually sends the same class of newsgroups to host
-.cn A .
-This bidirectionality is not,
-however,
-required.
-.pg
-USENET is made up of many subnetworks.
-Each subnet has a name,
-such as
-.ng comp
-or
-.ng btl .
-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 hosts
-to be unable to post messages reaching the rest of the network.)
-.pg
-A message 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
-.cn A
-deems host
-.cn B
-to be \*(lqinterested\*(rq in a newsgroup
-if the newsgroup matches the pattern on the arc from
-.cn A
-to
-.cn B .
-This pattern is stored in a file on the
-.cn A
-machine.)
-The hosts receiving the incoming message examine it
-to make sure they really want the message,
-accept it locally,
-and then in turn forward the message to all
-.i their
-interested neighbors.
-This process continues until the entire network has seen the message.
-.pg
-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 host
-.cn A
-sends a message to host
-.cn B ,
-host
-.cn B
-will send it back to host
-.cn A ,
-which will send it to host
-.cn B ,
-and so on.
-One solution to this is the history mechanism.
-Each host keeps track of all messages it has seen
-(by their Message-ID)
-and whenever a message comes in that it has already seen,
-the incoming message is discarded immediately.
-This solution is sufficient to prevent loops,
-but additional optimizations can be made to avoid sending messages to hosts
-that will simply throw them away.
-.pg
-One optimization is that a message should never be sent to a machine
-listed in the
-.hf Path
-line of the header.
-When a machine name is in the
-.hf Path
-line,
-the message is known to have passed through the machine.
-Another optimization is that, if the message originated on host
-.cn A ,
-then host
-.cn A
-has already seen the message.
-.P
-Thus,
-if a message is posted to newsgroup
-.ng misc.misc ,
-it will match the pattern
-.ng misc.all
-(where
-.ng all
-is a metasymbol that matches any string),
-and will be forwarded to all hosts that subscribe to
-.ng misc.all
-(as determined by what their neighbors send them).
-These hosts make up the
-.ng misc
-subnetwork.
-A message posted to
-.ng btl.general
-will reach all hosts receiving
-.ng btl.all ,
-but will not reach hosts that do not get
-.ng btl.all .
-In effect,
-the messages reaches the
-.ng btl
-subnetwork.
-A messages posted to newsgroups
-.ng misc.misc,btl.general
-will reach all hosts subscribing to either of the two classes.
*-*-END-of-doc/standard.mn-*-*
exit