rfc977.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,540 行 · 第 1/4 页

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
   systems.

   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
   articles.

   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
   day.

   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]



RFC 977                                                    February 1986
Network News Transfer Protocol


2.4.  Responses

   Responses are of two kinds, textual and status.

2.4.1.  Text Responses

   Text is sent only after a numeric status response line has been sent
   that indicates that text will follow.  Text is sent as a series of
   successive lines of textual matter, each terminated with CR-LF pair.
   A single line containing only a period (.) is sent to indicate the
   end of the text (i.e., the server will send a CR-LF pair at the end
   of the last line of text, a period, and another CR-LF pair).

   If the text contained a period as the first character of the text
   line in the original, that first period is doubled.  Therefore, the
   client must examine the first character of each line received, and
   for those beginning with a period, determine either that this is the
   end of the text or whether to collapse the doubled period to a single
   one.

   The intention is that text messages will usually be displayed on the
   user's terminal whereas command/status responses will be interpreted
   by the client program before any possible display is done.

2.4.2.  Status Responses

   These are status reports from the server and indicate the response to
   the last command received from the client.

   Status response lines begin with a 3 digit numeric code which is
   sufficient to distinguish all responses.  Some of these may herald
   the subsequent transmission of text.

   The first digit of the response broadly indicates the success,
   failure, or progress of the previous command.

      1xx - Informative message
      2xx - Command ok
      3xx - Command ok so far, send the rest of it.
      4xx - Command was correct, but couldn't be performed for
            some reason.
      5xx - Command unimplemented, or incorrect, or a serious
            program error occurred.






Kantor & Lapsley                                                [Page 6]



RFC 977                                                    February 1986
Network News Transfer Protocol


   The next digit in the code indicates the function response category.

      x0x - Connection, setup, and miscellaneous messages
      x1x - Newsgroup selection
      x2x - Article selection
      x3x - Distribution functions
      x4x - Posting
      x8x - Nonstandard (private implementation) extensions
      x9x - Debugging output

   The exact response codes that should be expected from each command
   are detailed in the description of that command.  In addition, below
   is listed a general set of response codes that may be received at any
   time.

   Certain status responses contain parameters such as numbers and
   names. The number and type of such parameters is fixed for each
   response code to simplify interpretation of the response.

   Parameters are separated from the numeric response code and from each
   other by a single space. All numeric parameters are decimal, and may
   have leading zeros. All string parameters begin after the separating
   space, and end before the following separating space or the CR-LF
   pair at the end of the line. (String parameters may not, therefore,
   contain spaces.) All text, if any, in the response which is not a
   parameter of the response must follow and be separated from the last
   parameter by a space.  Also, note that the text following a response
   number may vary in different implementations of the server. The
   3-digit numeric code should be used to determine what response was
   sent.

   Response codes not specified in this standard may be used for any
   installation-specific additional commands also not specified. These
   should be chosen to fit the pattern of x8x specified above.  (Note
   that debugging is provided for explicitly in the x9x response codes.)
   The use of unspecified response codes for standard commands is
   prohibited.