RFC1036 - Standard for interchange of USENET messages
Network Working Group M. Horton
Request for Comments: 1036 AT&T Bell Laboratories
Obsoletes: RFC-850 R. Adams
Center for Seismic Studies
December 1987
Standard for Interchange of USENET Messages
STATUS OF THIS MEMO
This document defines the standard format for the interchange of
network News messages among USENET hosts. It updates and replaces
RFC-850, reflecting version B2.11 of the News program. This memo is
disributed as an RFC to make this information easily accessible to
the Internet community. It does not specify an Internet standard.
Distribution of this memo is unlimited.
1. Introduction
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 in order to give a
good deal of flexibility to the hosts to choose transmission
hardware and software, to batch news, and so on.
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.
2. Message Format
The primary consideration in choosing a message format is that it
fit in with existing tools as well as possible. Existing tools
include implementations of both mail and news. (The notesfiles
system from the University of Illinois is considered a news
implementation.) A standard format for mail messages has existed
for many years on the Internet, and this format meets most of the
needs of USENET. Since the Internet format is extensible,
extensions to meet the additional needs of USENET are easily made
within the Internet standard. Therefore, the rule is adopted that
all USENET news messages must be formatted as valid Internet mail
messages, according to the Internet standard RFC-822. The USENET
News standard is more restrictive than the Internet standard,
placing additional requirements on each message and forbidding use
of certain Internet features. However, it should always be possible
to use a tool expecting an Internet message to process a news
message. In any situation where this standard conflicts with the
Internet standard, RFC-822 should be considered correct and this
standard in error.
Here is an example USENET message to illustrate the fields.
From:
jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@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.
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.
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.
Some news systems transmit news in the A format, which looks like
this:
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.
A standard USENET message consists of several header lines, followed
by a blank line, followed by the body of the message. Each header
line consist of a keyword, a colon, a blank, and some additional
information. This is a subset of the Internet 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
Internet 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 Internet convention of
continuation header lines (beginning with a blank or tab) is
allowed.
Certain headers are required, and certain other headers are
optional. Any unrecognized headers are allowed, and will be passed
through unchanged. The required header lines are "From", "Date",
"Newsgroups", "Subject", "Message-ID", and "Path". The optional
header lines are "Followup-To", "Expires", "Reply-To", "Sender",
"References", "Control", "Distribution", "Keywords", "Summary",
"Approved", "Lines", "Xref", and "Organization". Each of these
header lines will be described below.
Read more:
http://www.faqs.org/rfcs/rfc1036.html#ixzz0dZrruOdS
Facebook
Twitter