Flutterby™!: RFC 977

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics


This is my first attempt at trying to build a Wiki-like knowledge base on top of the Flutterby content management system.

This is a place for explanation, description and static links on a topic that's either too broad to be covered under a single link, or that you're just too lazy to find the real link to.

Entries are automatically generated.

RFC 977

by:Dan Lyke started: 2003-08-07 21:27:31.421944+02 updated: 2003-08-07 21:27:31.421944+02

Network Working Group                      Brian Kantor (U.C. San Diego)
Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)
                                                           February 1986

                     Network News Transfer Protocol

                A Proposed Standard for the Stream-Based
                          Transmission of News

Status of This Memo

   NNTP specifies a protocol for the distribution, inquiry, retrieval,
   and posting of news articles using a reliable stream-based
   transmission of news among the ARPA-Internet community.  NNTP is
   designed so that news articles are stored in a central database
   allowing a subscriber to select only those items he wishes to read.
   Indexing, cross-referencing, and expiration of aged messages are also
   provided. This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

1.  Introduction

   For many years, the ARPA-Internet community has supported the
   distribution of bulletins, information, and data in a timely fashion
   to thousands of participants.  We collectively refer to such items of
   information as "news".  Such news provides for the rapid
   dissemination of items of interest such as software bug fixes, new
   product reviews, technical tips, and programming pointers, as well as
   rapid-fire discussions of matters of concern to the working computer
   professional. News is very popular among its readers.

   There are popularly two methods of distributing such news: the
   Internet method of direct mailing, and the USENET news system.

1.1.  Internet Mailing Lists

   The Internet community distributes news by the use of mailing lists.
   These are lists of subscriber's mailbox addresses and remailing
   sublists of all intended recipients.  These mailing lists operate by
   remailing a copy of the information to be distributed to each
   subscriber on the mailing list.  Such remailing is inefficient when a
   mailing list grows beyond a dozen or so people, since sending a
   separate copy to each of the subscribers occupies large quantities of
   network bandwidth, CPU resources, and significant amounts of disk
   storage at the destination host.  There is also a significant problem
   in maintenance of the list itself: as subscribers move from one job
   to another; as new subscribers join and old ones leave; and as hosts
   come in and out of service.

Kantor & Lapsley                                                [Page 1]

RFC 977                                                    February 1986
Network News Transfer Protocol

1.2.  The USENET News System

   Clearly, a worthwhile reduction of the amount of these resources used
   can be achieved if articles are stored in a central database on the
   receiving host instead of in each subscriber's mailbox. The USENET
   news system provides a method of doing just this.  There is a central
   repository of the news articles in one place (customarily a spool
   directory of some sort), and a set of programs that allow a
   subscriber to select those items he wishes to read.  Indexing,
   cross-referencing, and expiration of aged messages are also provided.

1.3.  Central Storage of News

   For clusters of hosts connected together by fast local area networks
   (such as Ethernet), it makes even more sense to consolidate news
   distribution onto one (or a very few) hosts, and to allow access to
   these news articles using a server and client model.  Subscribers may
   then request only the articles they wish to see, without having to
   wastefully duplicate the storage of a copy of each item on each host.

1.4.  A Central News Server

   A way to achieve these economies is to have a central computer system
   that can provide news service to the other systems on the local area
   network.  Such a server would manage the collection of news articles
   and index files, with each person who desires to read news bulletins
   doing so over the LAN.  For a large cluster of computer systems, the
   savings in total disk space is clearly worthwhile.  Also, this allows
   workstations with limited disk storage space to participate in the
   news without incoming items consuming oppressive amounts of the
   workstation's disk storage.

   We have heard rumors of somewhat successful attempts to provide
   centralized news service using IBIS and other shared or distributed
   file systems.  While it is possible that such a distributed file
   system implementation might work well with a group of similar
   computers running nearly identical operating systems, such a scheme
   is not general enough to offer service to a wide range of client
   systems, especially when many diverse operating systems may be in use
   among a group of clients.  There are few (if any) shared or networked
   file systems that can offer the generality of service that stream
   connections using Internet TCP provide, particularly when a wide
   range of host hardware and operating systems are considered.

   NNTP specifies a protocol for the distribution, inquiry, retrieval,
   and posting of news articles using a reliable stream (such as TCP)
   server-client model. NNTP is designed so that news articles need only

Kantor & Lapsley                                                [Page 2]

RFC 977                                                    February 1986
Network News Transfer Protocol

   be stored on one (presumably central) host, and subscribers on other
   hosts attached to the LAN may read news articles using stream
   connections to the news host.

   NNTP is modelled upon the news article specifications in RFC 850,
   which describes the USENET news system.  However, NNTP makes few
   demands upon the structure, content, or storage of news articles, and
   thus we believe it easily can be adapted to other non-USENET news

   Typically, the NNTP server runs as a background process on one host,
   and would accept connections from other hosts on the LAN.  This works
   well when there are a number of small computer systems (such as
   workstations, with only one or at most a few users each), and a large
   central server.

1.5.  Intermediate News Servers

   For clusters of machines with many users (as might be the case in a
   university or large industrial environment), an intermediate server
   might be used.  This intermediate or "slave" server runs on each
   computer system, and is responsible for mediating news reading
   requests and performing local caching of recently-retrieved news

   Typically, a client attempting to obtain news service would first
   attempt to connect to the news service port on the local machine.  If
   this attempt were unsuccessful, indicating a failed server, an
   installation might choose to either deny news access, or to permit
   connection to the central "master" news server.

   For workstations or other small systems, direct connection to the
   master server would probably be the normal manner of operation.

   This specification does not cover the operation of slave NNTP
   servers.  We merely suggest that slave servers are a logical addition
   to NNTP server usage which would enhance operation on large local
   area networks.

1.6.  News Distribution

   NNTP has commands which provide a straightforward method of
   exchanging articles between cooperating hosts. Hosts which are well
   connected on a local area or other fast network and who wish to
   actually obtain copies of news articles for local storage might well
   find NNTP to be a more efficient way to distribute news than more
   traditional transfer methods (such as UUCP).

Kantor & Lapsley                                                [Page 3]

RFC 977                                                    February 1986
Network News Transfer Protocol

   In the traditional method of distributing news articles, news is
   propagated from host to host by flooding - that is, each host will
   send all its new news articles on to each host that it feeds.  These
   hosts will then in turn send these new articles on to other hosts
   that they feed.  Clearly, sending articles that a host already has
   obtained a copy of from another feed (many hosts that receive news
   are redundantly fed) again is a waste of time and communications
   resources, but for transport mechanisms that are single-transaction
   based rather than interactive (such as UUCP in the UNIX-world <1>),
   distribution time is diminished by sending all articles and having
   the receiving host simply discard the duplicates.  This is an
   especially true when communications sessions are limited to once a

   Using NNTP, hosts exchanging news articles have an interactive
   mechanism for deciding which articles are to be transmitted.  A host
   desiring new news, or which has new news to send, will typically
   contact one or more of its neighbors using NNTP.  First it will
   inquire if any new news groups have been created on the serving host
   by means of the NEWGROUPS command.  If so, and those are appropriate
   or desired (as established by local site-dependent rules), those new
   newsgroups can be created.

   The client host will then inquire as to which new articles have
   arrived in all or some of the newsgroups that it desires to receive,
   using the NEWNEWS command.  It will receive a list of new articles
   from the server, and can request transmission of those articles that
   it desires and does not already have.

   Finally, the client can advise the server of those new articles which
   the client has recently received.  The server will indicate those
   articles that it has already obtained copies of, and which articles
   should be sent to add to its collection.

   In this manner, only those articles which are not duplicates and
   which are desired are transferred.

Kantor & Lapsley                                                [Page 4]

RFC 977                                                    February 1986
Network News Transfer Protocol

2.  The NNTP Specification

2.1.  Overview

   The news server specified by this document uses a stream connection
   (such as TCP) and SMTP-like commands and responses.  It is designed
   to accept connections from hosts, and to provide a simple interface
   to the news database.

   This server is only an interface between programs and the news
   databases. It does not perform any user interaction or presentation-
   level functions. These "user-friendly" functions are better left to
   the client programs, which have a better understanding of the
   environment in which they are operating.

   When used via Internet TCP, the contact port assigned for this
   service is 119.

2.2.  Character Codes

   Commands and replies are composed of characters from the ASCII
   character set.  When the transport service provides an 8-bit byte
   (octet) transmission channel, each 7-bit character is transmitted
   right justified in an octet with the high order bit cleared to zero.

2.3.  Commands

   Commands consist of a command word, which in some cases may be
   followed by a parameter.  Commands with parameters must separate the
   parameters from each other and from the command by one or more space
   or tab characters.  Command lines must be complete with all required
   parameters, and may not contain more than one command.

   Commands and command parameters are not case sensitive. That is, a
   command or parameter word may be upper case, lower case, or any
   mixture of upper and lower case.

   Each command line must be terminated by a CR-LF (Carriage Return -
   Line Feed) pair.

   Command lines shall not exceed 512 characters in length, counting all
   characters including spaces, separators, punctuation, and the
   trailing CR-LF (thus there are 510 characters maximum allowed for the
   command and its parameters).  There is no provision for continuation
   command lines.

Kantor & Lapsley                                                [Page 5]

Flutterby™ is a trademark claimed by

Dan Lyke
for the web publications at www.flutterby.com and www.flutterby.net.