--- /dev/null
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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.
+
+ We have provided a response pattern x9x for debugging. Since much
+ debugging output may be classed as "informative messages", we would
+ expect, therefore, that responses 190 through 199 would be used for
+ various debugging outputs. There is no requirement in this
+ specification for debugging output, but if such is provided over the
+ connected stream, it must use these response codes. If appropriate
+ to a specific implementation, other x9x codes may be used for
+ debugging. (An example might be to use e.g., 290 to acknowledge a
+ remote debugging request.)
+
+
+Kantor & Lapsley [Page 7]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+2.4.3. General Responses
+
+ The following is a list of general response codes that may be sent by
+ the NNTP server. These are not specific to any one command, but may
+ be returned as the result of a connection, a failure, or some unusual
+ condition.
+
+ In general, 1xx codes may be ignored or displayed as desired; code
+ 200 or 201 is sent upon initial connection to the NNTP server
+ depending upon posting permission; code 400 will be sent when the
+ NNTP server discontinues service (by operator request, for example);
+ and 5xx codes indicate that the command could not be performed for
+ some unusual reason.
+
+ 100 help text
+ 190
+ through
+ 199 debug output
+
+ 200 server ready - posting allowed
+ 201 server ready - no posting allowed
+
+ 400 service discontinued
+
+ 500 command not recognized
+ 501 command syntax error
+ 502 access restriction or permission denied
+ 503 program fault - command not performed
+
+3. Command and Response Details
+
+ On the following pages are descriptions of each command recognized by
+ the NNTP server and the responses which will be returned by those
+ commands.
+
+ Each command is shown in upper case for clarity, although case is
+ ignored in the interpretation of commands by the NNTP server. Any
+ parameters are shown in lower case. A parameter shown in [square
+ brackets] is optional. For example, [GMT] indicates that the
+ triglyph GMT may present or omitted.
+
+ Every command described in this section must be implemented by all
+ NNTP servers.
+
+
+
+
+
+
+Kantor & Lapsley [Page 8]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ There is no prohibition against additional commands being added;
+ however, it is recommended that any such unspecified command begin
+ with the letter "X" to avoid conflict with later revisions of this
+ specification.
+
+ Implementors are reminded that such additional commands may not
+ redefine specified status response codes. Using additional
+ unspecified responses for standard commands is also prohibited.
+
+3.1. The ARTICLE, BODY, HEAD, and STAT commands
+
+ There are two forms to the ARTICLE command (and the related BODY,
+ HEAD, and STAT commands), each using a different method of specifying
+ which article is to be retrieved. When the ARTICLE command is
+ followed by a message-id in angle brackets ("<" and ">"), the first
+ form of the command is used; when a numeric parameter or no parameter
+ is supplied, the second form is invoked.
+
+ The text of the article is returned as a textual response, as
+ described earlier in this document.
+
+ The HEAD and BODY commands are identical to the ARTICLE command
+ except that they respectively return only the header lines or text
+ body of the article.
+
+ The STAT command is similar to the ARTICLE command except that no
+ text is returned. When selecting by message number within a group,
+ the STAT command serves to set the current article pointer without
+ sending text. The returned acknowledgement response will contain the
+ message-id, which may be of some value. Using the STAT command to
+ select by message-id is valid but of questionable value, since a
+ selection by message-id does NOT alter the "current article pointer".
+
+3.1.1. ARTICLE (selection by message-id)
+
+ ARTICLE <message-id>
+
+ Display the header, a blank line, then the body (text) of the
+ specified article. Message-id is the message id of an article as
+ shown in that article's header. It is anticipated that the client
+ will obtain the message-id from a list provided by the NEWNEWS
+ command, from references contained within another article, or from
+ the message-id provided in the response to some other commands.
+
+ Please note that the internally-maintained "current article pointer"
+ is NOT ALTERED by this command. This is both to facilitate the
+ presentation of articles that may be referenced within an article
+
+
+Kantor & Lapsley [Page 9]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ being read, and because of the semantic difficulties of determining
+ the proper sequence and membership of an article which may have been
+ posted to more than one newsgroup.
+
+3.1.2. ARTICLE (selection by number)
+
+ ARTICLE [nnn]
+
+ Displays the header, a blank line, then the body (text) of the
+ current or specified article. The optional parameter nnn is the
+
+ numeric id of an article in the current newsgroup and must be chosen
+ from the range of articles provided when the newsgroup was selected.
+ If it is omitted, the current article is assumed.
+
+ The internally-maintained "current article pointer" is set by this
+ command if a valid article number is specified.
+
+ [the following applies to both forms of the article command.] A
+ response indicating the current article number, a message-id string,
+ and that text is to follow will be returned.
+
+ The message-id string returned is an identification string contained
+ within angle brackets ("<" and ">"), which is derived from the header
+ of the article itself. The Message-ID header line (required by
+ RFC850) from the article must be used to supply this information. If
+ the message-id header line is missing from the article, a single
+ digit "0" (zero) should be supplied within the angle brackets.
+
+ Since the message-id field is unique with each article, it may be
+ used by a news reading program to skip duplicate displays of articles
+ that have been posted more than once, or to more than one newsgroup.
+
+3.1.3. Responses
+
+ 220 n <a> article retrieved - head and body follow
+ (n = article number, <a> = message-id)
+ 221 n <a> article retrieved - head follows
+ 222 n <a> article retrieved - body follows
+ 223 n <a> article retrieved - request text separately
+ 412 no newsgroup has been selected
+ 420 no current article has been selected
+ 423 no such article number in this group
+ 430 no such article found
+
+
+
+
+
+Kantor & Lapsley [Page 10]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.2. The GROUP command
+
+3.2.1. GROUP
+
+ GROUP ggg
+
+ The required parameter ggg is the name of the newsgroup to be
+ selected (e.g. "net.news"). A list of valid newsgroups may be
+ obtained from the LIST command.
+
+ The successful selection response will return the article numbers of
+ the first and last articles in the group, and an estimate of the
+ number of articles on file in the group. It is not necessary that
+ the estimate be correct, although that is helpful; it must only be
+ equal to or larger than the actual number of articles on file. (Some
+ implementations will actually count the number of articles on file.
+ Others will just subtract first article number from last to get an
+ estimate.)
+
+ When a valid group is selected by means of this command, the
+ internally maintained "current article pointer" is set to the first
+ article in the group. If an invalid group is specified, the
+ previously selected group and article remain selected. If an empty
+ newsgroup is selected, the "current article pointer" is in an
+ indeterminate state and should not be used.
+
+ Note that the name of the newsgroup is not case-dependent. It must
+ otherwise match a newsgroup obtained from the LIST command or an
+ error will result.
+
+3.2.2. Responses
+
+ 211 n f l s group selected
+ (n = estimated number of articles in group,
+ f = first article number in the group,
+ l = last article number in the group,
+ s = name of the group.)
+ 411 no such news group
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 11]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.3. The HELP command
+
+3.3.1. HELP
+
+ HELP
+
+ Provides a short summary of commands that are understood by this
+ implementation of the server. The help text will be presented as a
+ textual response, terminated by a single period on a line by itself.
+
+ 3.3.2. Responses
+
+ 100 help text follows
+
+3.4. The IHAVE command
+
+3.4.1. IHAVE
+
+ IHAVE <messageid>
+
+ The IHAVE command informs the server that the client has an article
+ whose id is <messageid>. If the server desires a copy of that
+ article, it will return a response instructing the client to send the
+ entire article. If the server does not want the article (if, for
+ example, the server already has a copy of it), a response indicating
+ that the article is not wanted will be returned.
+
+ If transmission of the article is requested, the client should send
+ the entire article, including header and body, in the manner
+ specified for text transmission from the server. A response code
+ indicating success or failure of the transferral of the article will
+ be returned.
+
+ This function differs from the POST command in that it is intended
+ for use in transferring already-posted articles between hosts.
+ Normally it will not be used when the client is a personal
+ newsreading program. In particular, this function will invoke the
+ server's news posting program with the appropriate settings (flags,
+ options, etc) to indicate that the forthcoming article is being
+ forwarded from another host.
+
+ The server may, however, elect not to post or forward the article if
+ after further examination of the article it deems it inappropriate to
+ do so. The 436 or 437 error codes may be returned as appropriate to
+ the situation.
+
+ Reasons for such subsequent rejection of an article may include such
+
+
+Kantor & Lapsley [Page 12]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ problems as inappropriate newsgroups or distributions, disk space
+ limitations, article lengths, garbled headers, and the like. These
+ are typically restrictions enforced by the server host's news
+ software and not necessarily the NNTP server itself.
+
+3.4.2. Responses
+
+ 235 article transferred ok
+ 335 send article to be transferred. End with <CR-LF>.<CR-LF>
+ 435 article not wanted - do not send it
+ 436 transfer failed - try again later
+ 437 article rejected - do not try again
+
+ An implementation note:
+
+ Because some host news posting software may not be able to decide
+ immediately that an article is inappropriate for posting or
+ forwarding, it is acceptable to acknowledge the successful transfer
+ of the article and to later silently discard it. Thus it is
+ permitted to return the 235 acknowledgement code and later discard
+ the received article. This is not a fully satisfactory solution to
+ the problem. Perhaps some implementations will wish to send mail to
+ the author of the article in certain of these cases.
+
+3.5. The LAST command
+
+3.5.1. LAST
+
+ LAST
+
+ The internally maintained "current article pointer" is set to the
+ previous article in the current newsgroup. If already positioned at
+ the first article of the newsgroup, an error message is returned and
+ the current article remains selected.
+
+ The internally-maintained "current article pointer" is set by this
+ command.
+
+ A response indicating the current article number, and a message-id
+ string will be returned. No text is sent in response to this
+ command.
+
+3.5.2. Responses
+
+ 223 n a article retrieved - request text separately
+ (n = article number, a = unique article id)
+
+
+
+Kantor & Lapsley [Page 13]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ 412 no newsgroup selected
+ 420 no current article has been selected
+ 422 no previous article in this group
+
+3.6. The LIST command
+
+3.6.1. LIST
+
+ LIST
+
+ Returns a list of valid newsgroups and associated information. Each
+ newsgroup is sent as a line of text in the following format:
+
+ group last first p
+
+ where <group> is the name of the newsgroup, <last> is the number of
+ the last known article currently in that newsgroup, <first> is the
+ number of the first article currently in the newsgroup, and <p> is
+ either 'y' or 'n' indicating whether posting to this newsgroup is
+ allowed ('y') or prohibited ('n').
+
+ The <first> and <last> fields will always be numeric. They may have
+ leading zeros. If the <last> field evaluates to less than the
+ <first> field, there are no articles currently on file in the
+ newsgroup.
+
+ Note that posting may still be prohibited to a client even though the
+ LIST command indicates that posting is permitted to a particular
+ newsgroup. See the POST command for an explanation of client
+ prohibitions. The posting flag exists for each newsgroup because
+ some newsgroups are moderated or are digests, and therefore cannot be
+ posted to; that is, articles posted to them must be mailed to a
+ moderator who will post them for the submitter. This is independent
+ of the posting permission granted to a client by the NNTP server.
+
+ Please note that an empty list (i.e., the text body returned by this
+ command consists only of the terminating period) is a possible valid
+ response, and indicates that there are currently no valid newsgroups.
+
+3.6.2. Responses
+
+ 215 list of newsgroups follows
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 14]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.7. The NEWGROUPS command
+
+3.7.1. NEWGROUPS
+
+ NEWGROUPS date time [GMT] [<distributions>]
+
+ A list of newsgroups created since <date and time> will be listed in
+ the same format as the LIST command.
+
+ The date is sent as 6 digits in the format YYMMDD, where YY is the
+ last two digits of the year, MM is the two digits of the month (with
+ leading zero, if appropriate), and DD is the day of the month (with
+ leading zero, if appropriate). The closest century is assumed as
+ part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
+ 1999, 00 is 2000).
+
+ Time must also be specified. It must be as 6 digits HHMMSS with HH
+ being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
+ 00-59. The time is assumed to be in the server's timezone unless the
+ token "GMT" appears, in which case both time and date are evaluated
+ at the 0 meridian.
+
+ The optional parameter "distributions" is a list of distribution
+ groups, enclosed in angle brackets. If specified, the distribution
+ portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
+ examined for a match with the distribution categories listed, and
+ only those new newsgroups which match will be listed. If more than
+ one distribution group is to be listed, they must be separated by
+ commas within the angle brackets.
+
+ Please note that an empty list (i.e., the text body returned by this
+ command consists only of the terminating period) is a possible valid
+ response, and indicates that there are currently no new newsgroups.
+
+3.7.2. Responses
+
+ 231 list of new newsgroups follows
+
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 15]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.8. The NEWNEWS command
+
+3.8.1. NEWNEWS
+
+ NEWNEWS newsgroups date time [GMT] [<distribution>]
+
+ A list of message-ids of articles posted or received to the specified
+ newsgroup since "date" will be listed. The format of the listing will
+ be one message-id per line, as though text were being sent. A single
+ line consisting solely of one period followed by CR-LF will terminate
+ the list.
+
+ Date and time are in the same format as the NEWGROUPS command.
+
+ A newsgroup name containing a "*" (an asterisk) may be specified to
+ broaden the article search to some or all newsgroups. The asterisk
+ will be extended to match any part of a newsgroup name (e.g.,
+ net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
+ if only an asterisk is given as the newsgroup name, all newsgroups
+ will be searched for new news.
+
+ (Please note that the asterisk "*" expansion is a general
+ replacement; in particular, the specification of e.g., net.*.unix
+ should be correctly expanded to embrace names such as net.wombat.unix
+ and net.whocares.unix.)
+
+ Conversely, if no asterisk appears in a given newsgroup name, only
+ the specified newsgroup will be searched for new articles. Newsgroup
+ names must be chosen from those returned in the listing of available
+ groups. Multiple newsgroup names (including a "*") may be specified
+ in this command, separated by a comma. No comma shall appear after
+ the last newsgroup in the list. [Implementors are cautioned to keep
+ the 512 character command length limit in mind.]
+
+ The exclamation point ("!") may be used to negate a match. This can
+ be used to selectively omit certain newsgroups from an otherwise
+ larger list. For example, a newsgroups specification of
+ "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
+ all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
+ matched. If used, the exclamation point must appear as the first
+ character of the given newsgroup name or pattern.
+
+ The optional parameter "distributions" is a list of distribution
+ groups, enclosed in angle brackets. If specified, the distribution
+ portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
+ be examined for a match with the distribution categories listed, and
+ only those articles which have at least one newsgroup belonging to
+
+
+Kantor & Lapsley [Page 16]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ the list of distributions will be listed. If more than one
+ distribution group is to be supplied, they must be separated by
+ commas within the angle brackets.
+
+ The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
+ news is discussed in an earlier part of this document.
+
+ Please note that an empty list (i.e., the text body returned by this
+ command consists only of the terminating period) is a possible valid
+ response, and indicates that there is currently no new news.
+
+3.8.2. Responses
+
+ 230 list of new articles by message-id follows
+
+3.9. The NEXT command
+
+3.9.1. NEXT
+
+ NEXT
+
+ The internally maintained "current article pointer" is advanced to
+ the next article in the current newsgroup. If no more articles
+ remain in the current group, an error message is returned and the
+ current article remains selected.
+
+ The internally-maintained "current article pointer" is set by this
+ command.
+
+ A response indicating the current article number, and the message-id
+ string will be returned. No text is sent in response to this
+ command.
+
+3.9.2. Responses
+
+ 223 n a article retrieved - request text separately
+ (n = article number, a = unique article id)
+ 412 no newsgroup selected
+ 420 no current article has been selected
+ 421 no next article in this group
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 17]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.10. The POST command
+
+3.10.1. POST
+
+ POST
+
+ If posting is allowed, response code 340 is returned to indicate that
+ the article to be posted should be sent. Response code 440 indicates
+ that posting is prohibited for some installation-dependent reason.
+
+ If posting is permitted, the article should be presented in the
+ format specified by RFC850, and should include all required header
+ lines. After the article's header and body have been completely sent
+ by the client to the server, a further response code will be returned
+ to indicate success or failure of the posting attempt.
+
+ The text forming the header and body of the message to be posted
+ should be sent by the client using the conventions for text received
+ from the news server: A single period (".") on a line indicates the
+ end of the text, with lines starting with a period in the original
+ text having that period doubled during transmission.
+
+ No attempt shall be made by the server to filter characters, fold or
+ limit lines, or otherwise process incoming text. It is our intent
+ that the server just pass the incoming message to be posted to the
+ server installation's news posting software, which is separate from
+ this specification. See RFC850 for more details.
+
+ Since most installations will want the client news program to allow
+ the user to prepare his message using some sort of text editor, and
+ transmit it to the server for posting only after it is composed, the
+ client program should take note of the herald message that greeted it
+ when the connection was first established. This message indicates
+ whether postings from that client are permitted or not, and can be
+ used to caution the user that his access is read-only if that is the
+ case. This will prevent the user from wasting a good deal of time
+ composing a message only to find posting of the message was denied.
+ The method and determination of which clients and hosts may post is
+ installation dependent and is not covered by this specification.
+
+3.10.2. Responses
+
+ 240 article posted ok
+ 340 send article to be posted. End with <CR-LF>.<CR-LF>
+ 440 posting not allowed
+ 441 posting failed
+
+
+
+Kantor & Lapsley [Page 18]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ (for reference, one of the following codes will be sent upon initial
+ connection; the client program should determine whether posting is
+ generally permitted from these:) 200 server ready - posting allowed
+ 201 server ready - no posting allowed
+
+3.11. The QUIT command
+
+3.11.1. QUIT
+
+ QUIT
+
+ The server process acknowledges the QUIT command and then closes the
+ connection to the client. This is the preferred method for a client
+ to indicate that it has finished all its transactions with the NNTP
+ server.
+
+ If a client simply disconnects (or the connection times out, or some
+ other fault occurs), the server should gracefully cease its attempts
+ to service the client.
+
+3.11.2. Responses
+
+ 205 closing connection - goodbye!
+
+3.12. The SLAVE command
+
+3.12.1. SLAVE
+
+ SLAVE
+
+ Indicates to the server that this client connection is to a slave
+ server, rather than a user.
+
+ This command is intended for use in separating connections to single
+ users from those to subsidiary ("slave") servers. It may be used to
+ indicate that priority should therefore be given to requests from
+ this client, as it is presumably serving more than one person. It
+ might also be used to determine which connections to close when
+ system load levels are exceeded, perhaps giving preference to slave
+ servers. The actual use this command is put to is entirely
+ implementation dependent, and may vary from one host to another. In
+ NNTP servers which do not give priority to slave servers, this
+ command must nonetheless be recognized and acknowledged.
+
+3.12.2. Responses
+
+ 202 slave status noted
+
+
+Kantor & Lapsley [Page 19]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+4. Sample Conversations
+
+ These are samples of the conversations that might be expected with
+ the news server in hypothetical sessions. The notation C: indicates
+ commands sent to the news server from the client program; S: indicate
+ responses received from the server by the client.
+
+4.1. Example 1 - relative access with NEXT
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 200 wombatvax news server ready - posting ok
+
+ (client asks for a current newsgroup list)
+ C: LIST
+ S: 215 list of newsgroups follows
+ S: net.wombats 00543 00501 y
+ S: net.unix-wizards 10125 10011 y
+ (more information here)
+ S: net.idiots 00100 00001 n
+ S: .
+
+ (client selects a newsgroup)
+ C: GROUP net.unix-wizards
+ S: 211 104 10011 10125 net.unix-wizards group selected
+ (there are 104 articles on file, from 10011 to 10125)
+
+ (client selects an article to read)
+ C: STAT 10110
+ S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
+ only (article 10110 selected, its message-id is
+ <23445@sdcsvax.ARPA>)
+
+ (client examines the header)
+ C: HEAD
+ S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head
+ follows (text of the header appears here)
+ S: .
+
+ (client wants to see the text body of the article)
+ C: BODY
+ S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body
+ follows (body text here)
+ S: .
+
+ (client selects next article in group)
+
+
+Kantor & Lapsley [Page 20]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ C: NEXT
+ S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics
+ only (article 10113 was next in group)
+
+ (client finishes session)
+ C: QUIT
+ S: 205 goodbye.
+
+4.2. Example 2 - absolute article access with ARTICLE
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 201 UCB-VAX netnews server ready -- no posting allowed
+
+ C: GROUP msgs
+ S: 211 103 402 504 msgs Your new group is msgs
+ (there are 103 articles, from 402 to 504)
+
+ C: ARTICLE 401
+ S: 423 No such article in this newsgroup
+
+ C: ARTICLE 402
+ S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
+ S: (article header and body follow)
+ S: .
+
+ C: HEAD 403
+ S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows
+ S: (article header follows)
+ S: .
+
+ C: QUIT
+ S: 205 UCB-VAX news server closing connection. Goodbye.
+
+4.3. Example 3 - NEWGROUPS command
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 200 Imaginary Institute News Server ready (posting ok)
+
+ (client asks for new newsgroups since April 3, 1985)
+ C: NEWGROUPS 850403 020000
+
+ S: 231 New newsgroups since 03/04/85 02:00:00 follow
+
+
+
+Kantor & Lapsley [Page 21]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ S: net.music.gdead
+ S: net.games.sources
+ S: .
+
+ C: GROUP net.music.gdead
+ S: 211 0 1 1 net.music.gdead Newsgroup selected
+ (there are no articles in that newsgroup, and
+ the first and last article numbers should be ignored)
+
+ C: QUIT
+ S: 205 Imaginary Institute news server ceasing service. Bye!
+
+4.4. Example 4 - posting a news article
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 200 BANZAIVAX news server ready, posting allowed.
+
+ C: POST
+ S: 340 Continue posting; Period on a line by itself to end
+ C: (transmits news article in RFC850 format)
+ C: .
+ S: 240 Article posted successfully.
+
+ C: QUIT
+ S: 205 BANZAIVAX closing connection. Goodbye.
+
+4.5. Example 5 - interruption due to operator request
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 201 genericvax news server ready, no posting allowed.
+
+ (assume normal conversation for some time, and
+ that a newsgroup has been selected)
+
+ C: NEXT
+ S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
+
+ C: HEAD
+ C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
+
+ S: (sends head of article, but halfway through is
+ interrupted by an operator request. The following
+ then occurs, without client intervention.)
+
+
+Kantor & Lapsley [Page 22]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ S: (ends current line with a CR-LF pair)
+ S: .
+ S: 400 Connection closed by operator. Goodbye.
+ S: (closes connection)
+
+4.6. Example 6 - Using the news server to distribute news between
+ systems.
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 201 Foobar NNTP server ready (no posting)
+
+ (client asks for new newsgroups since 2 am, May 15, 1985)
+ C: NEWGROUPS 850515 020000
+ S: 235 New newsgroups since 850515 follow
+ S: net.fluff
+ S: net.lint
+ S: .
+
+ (client asks for new news articles since 2 am, May 15, 1985)
+ C: NEWNEWS * 850515 020000
+ S: 230 New news since 850515 020000 follows
+ S: <1772@foo.UUCP>
+ S: <87623@baz.UUCP>
+ S: <17872@GOLD.CSNET>
+ S: .
+
+ (client asks for article <1772@foo.UUCP>)
+ C: ARTICLE <1772@foo.UUCP>
+ S: 220 <1772@foo.UUCP> All of article follows
+ S: (sends entire message)
+ S: .
+
+ (client asks for article <87623@baz.UUCP>
+ C: ARTICLE <87623@baz.UUCP>
+ S: 220 <87623@baz.UUCP> All of article follows
+ S: (sends entire message)
+ S: .
+
+ (client asks for article <17872@GOLD.CSNET>
+ C: ARTICLE <17872@GOLD.CSNET>
+ S: 220 <17872@GOLD.CSNET> All of article follows
+ S: (sends entire message)
+ S: .
+
+
+
+
+Kantor & Lapsley [Page 23]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ (client offers an article it has received recently)
+ C: IHAVE <4105@ucbvax.ARPA>
+ S: 435 Already seen that one, where you been?
+
+ (client offers another article)
+ C: IHAVE <4106@ucbvax.ARPA>
+ S: 335 News to me! <CRLF.CRLF> to end.
+ C: (sends article)
+ C: .
+ S: 235 Article transferred successfully. Thanks.
+
+ (or)
+
+ S: 436 Transfer failed.
+
+ (client is all through with the session)
+ C: QUIT
+ S: 205 Foobar NNTP server bids you farewell.
+
+4.7. Summary of commands and responses.
+
+ The following are the commands recognized and responses returned by
+ the NNTP server.
+
+4.7.1. Commands
+
+ ARTICLE
+ BODY
+ GROUP
+ HEAD
+ HELP
+ IHAVE
+ LAST
+ LIST
+ NEWGROUPS
+ NEWNEWS
+ NEXT
+ POST
+ QUIT
+ SLAVE
+ STAT
+
+4.7.2. Responses
+
+ 100 help text follows
+ 199 debug output
+
+
+
+Kantor & Lapsley [Page 24]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ 200 server ready - posting allowed
+ 201 server ready - no posting allowed
+ 202 slave status noted
+ 205 closing connection - goodbye!
+ 211 n f l s group selected
+ 215 list of newsgroups follows
+ 220 n <a> article retrieved - head and body follow 221 n <a> article
+ retrieved - head follows
+ 222 n <a> article retrieved - body follows
+ 223 n <a> article retrieved - request text separately 230 list of new
+ articles by message-id follows
+ 231 list of new newsgroups follows
+ 235 article transferred ok
+ 240 article posted ok
+
+ 335 send article to be transferred. End with <CR-LF>.<CR-LF>
+ 340 send article to be posted. End with <CR-LF>.<CR-LF>
+
+ 400 service discontinued
+ 411 no such news group
+ 412 no newsgroup has been selected
+ 420 no current article has been selected
+ 421 no next article in this group
+ 422 no previous article in this group
+ 423 no such article number in this group
+ 430 no such article found
+ 435 article not wanted - do not send it
+ 436 transfer failed - try again later
+ 437 article rejected - do not try again.
+ 440 posting not allowed
+ 441 posting failed
+
+ 500 command not recognized
+ 501 command syntax error
+ 502 access restriction or permission denied
+ 503 program fault - command not performed
+
+4.8. A Brief Word about the USENET News System
+
+ In the UNIX world, which traditionally has been linked by 1200 baud
+ dial-up telephone lines, the USENET News system has evolved to handle
+ central storage, indexing, retrieval, and distribution of news. With
+ the exception of its underlying transport mechanism (UUCP), USENET
+ News is an efficient means of providing news and bulletin service to
+ subscribers on UNIX and other hosts worldwide. The USENET News
+
+
+
+
+Kantor & Lapsley [Page 25]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ system is discussed in detail in RFC 850. It runs on most versions
+ of UNIX and on many other operating systems, and is customarily
+ distributed without charge.
+
+ USENET uses a spooling area on the UNIX host to store news articles,
+ one per file. Each article consists of a series of heading text,
+ which contain the sender's identification and organizational
+ affiliation, timestamps, electronic mail reply paths, subject,
+ newsgroup (subject category), and the like. A complete news article
+ is reproduced in its entirety below. Please consult RFC 850 for more
+ details.
+
+ Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
+ sdcsvax.UUCP
+ Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
+ Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
+ !honman
+ From: honman@unitek.uucp (Man Wong)
+ Newsgroups: net.unix-wizards
+ Subject: foreground -> background ?
+ Message-ID: <167@unitek.uucp>
+ Date: 25 Sep 85 23:51:52 GMT
+ Date-Received: 29 Sep 85 09:54:48 GMT
+ Reply-To: honman@unitek.UUCP (Hon-Man Wong)
+ Distribution: net.all
+ Organization: Unitek Technologies Corporation
+ Lines: 12
+
+ I have a process (C program) which generates a child and waits for
+ it to return. What I would like to do is to be able to run the
+ child process interactively for a while before kicking itself into
+ the background so I can return to the parent process (while the
+ child process is RUNNING in the background). Can it be done? And
+ if it can, how?
+
+ Please reply by E-mail. Thanks in advance.
+
+ Hon-Man Wong
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 26]
+\f
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+5. References
+
+ [1] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", RFC-822, Department of Electrical Engineering,
+ University of Delaware, August, 1982.
+
+ [2] Horton, M., "Standard for Interchange of USENET Messages",
+ RFC-850, USENET Project, June, 1983.
+
+ [3] Postel, J., "Transmission Control Protocol- DARPA Internet
+ Program Protocol Specification", RFC-793, USC/Information
+ Sciences Institute, September, 1981.
+
+ [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
+ USC/Information Sciences Institute, August, 1982.
+
+6. Acknowledgements
+
+ The authors wish to express their heartfelt thanks to those many
+ people who contributed to this specification, and especially to Erik
+ Fair and Chuq von Rospach, without whose inspiration this whole thing
+ would not have been necessary.
+
+7. Notes
+
+ <1> UNIX is a trademark of Bell Laboratories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 27]
+\f
projects / claws.git / blobdiff