Subject: v14i055: Network News Transfer Protocol, version 1.5, Part09/09 Newsgroups: comp.sources.unix Sender: sources Approved: rsalz@uunet.UU.NET Submitted-by: Phil Lapsley Posting-number: Volume 14, Issue 55 Archive-name: nntp1.5/part09 #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh './doc/rfc977' <<'END_OF_FILE' X X Network Working Group Brian Kantor (U.C. San Diego) Request for Comments: 977 Phil Lapsley (U.C. Berkeley) X February 1986 X X Network News Transfer Protocol X X A Proposed Standard for the Stream-Based X Transmission of News X Status of This Memo X X NNTP specifies a protocol for the distribution, inquiry, retrieval, X and posting of news articles using a reliable stream-based X transmission of news among the ARPA-Internet community. NNTP is X designed so that news articles are stored in a central database X allowing a subscriber to select only those items he wishes to read. X Indexing, cross-referencing, and expiration of aged messages are also X provided. This RFC suggests a proposed protocol for the ARPA-Internet X community, and requests discussion and suggestions for improvements. X Distribution of this memo is unlimited. X X1. Introduction X X For many years, the ARPA-Internet community has supported the X distribution of bulletins, information, and data in a timely fashion X to thousands of participants. We collectively refer to such items of X information as "news". Such news provides for the rapid X dissemination of items of interest such as software bug fixes, new X product reviews, technical tips, and programming pointers, as well as X rapid-fire discussions of matters of concern to the working computer X professional. News is very popular among its readers. X X There are popularly two methods of distributing such news: the X Internet method of direct mailing, and the USENET news system. X X1.1. Internet Mailing Lists X X The Internet community distributes news by the use of mailing lists. X These are lists of subscriber's mailbox addresses and remailing X sublists of all intended recipients. These mailing lists operate by X remailing a copy of the information to be distributed to each X subscriber on the mailing list. Such remailing is inefficient when a X mailing list grows beyond a dozen or so people, since sending a X separate copy to each of the subscribers occupies large quantities of X network bandwidth, CPU resources, and significant amounts of disk X storage at the destination host. There is also a significant problem X in maintenance of the list itself: as subscribers move from one job X to another; as new subscribers join and old ones leave; and as hosts X come in and out of service. X X X X Kantor & Lapsley [Page 1] X X X RFC 977 February 1986 Network News Transfer Protocol X X X1.2. The USENET News System X X Clearly, a worthwhile reduction of the amount of these resources used X can be achieved if articles are stored in a central database on the X receiving host instead of in each subscriber's mailbox. The USENET X news system provides a method of doing just this. There is a central X repository of the news articles in one place (customarily a spool X directory of some sort), and a set of programs that allow a X subscriber to select those items he wishes to read. Indexing, X cross-referencing, and expiration of aged messages are also provided. X X1.3. Central Storage of News X X For clusters of hosts connected together by fast local area networks X (such as Ethernet), it makes even more sense to consolidate news X distribution onto one (or a very few) hosts, and to allow access to X these news articles using a server and client model. Subscribers may X then request only the articles they wish to see, without having to X wastefully duplicate the storage of a copy of each item on each host. X X1.4. A Central News Server X X A way to achieve these economies is to have a central computer system X that can provide news service to the other systems on the local area X network. Such a server would manage the collection of news articles X and index files, with each person who desires to read news bulletins X doing so over the LAN. For a large cluster of computer systems, the X savings in total disk space is clearly worthwhile. Also, this allows X workstations with limited disk storage space to participate in the X news without incoming items consuming oppressive amounts of the X workstation's disk storage. X X We have heard rumors of somewhat successful attempts to provide X centralized news service using IBIS and other shared or distributed X file systems. While it is possible that such a distributed file X system implementation might work well with a group of similar X computers running nearly identical operating systems, such a scheme X is not general enough to offer service to a wide range of client X systems, especially when many diverse operating systems may be in use X among a group of clients. There are few (if any) shared or networked X file systems that can offer the generality of service that stream X connections using Internet TCP provide, particularly when a wide X range of host hardware and operating systems are considered. X X NNTP specifies a protocol for the distribution, inquiry, retrieval, X and posting of news articles using a reliable stream (such as TCP) X server-client model. NNTP is designed so that news articles need only X X Kantor & Lapsley [Page 2] X X X RFC 977 February 1986 Network News Transfer Protocol X X X be stored on one (presumably central) host, and subscribers on other X hosts attached to the LAN may read news articles using stream X connections to the news host. X X NNTP is modelled upon the news article specifications in RFC 850, X which describes the USENET news system. However, NNTP makes few X demands upon the structure, content, or storage of news articles, and X thus we believe it easily can be adapted to other non-USENET news X systems. X X Typically, the NNTP server runs as a background process on one host, X and would accept connections from other hosts on the LAN. This works X well when there are a number of small computer systems (such as X workstations, with only one or at most a few users each), and a large X central server. X X1.5. Intermediate News Servers X X For clusters of machines with many users (as might be the case in a X university or large industrial environment), an intermediate server X might be used. This intermediate or "slave" server runs on each X computer system, and is responsible for mediating news reading X requests and performing local caching of recently-retrieved news X articles. X X Typically, a client attempting to obtain news service would first X attempt to connect to the news service port on the local machine. If X this attempt were unsuccessful, indicating a failed server, an X installation might choose to either deny news access, or to permit X connection to the central "master" news server. X X For workstations or other small systems, direct connection to the X master server would probably be the normal manner of operation. X X This specification does not cover the operation of slave NNTP X servers. We merely suggest that slave servers are a logical addition X to NNTP server usage which would enhance operation on large local X area networks. X X1.6. News Distribution X X NNTP has commands which provide a straightforward method of X exchanging articles between cooperating hosts. Hosts which are well X connected on a local area or other fast network and who wish to X actually obtain copies of news articles for local storage might well X find NNTP to be a more efficient way to distribute news than more X traditional transfer methods (such as UUCP). X X Kantor & Lapsley [Page 3] X X X RFC 977 February 1986 Network News Transfer Protocol X X X In the traditional method of distributing news articles, news is X propagated from host to host by flooding - that is, each host will X send all its new news articles on to each host that it feeds. These X hosts will then in turn send these new articles on to other hosts X that they feed. Clearly, sending articles that a host already has X obtained a copy of from another feed (many hosts that receive news X are redundantly fed) again is a waste of time and communications X resources, but for transport mechanisms that are single-transaction X based rather than interactive (such as UUCP in the UNIX-world <1>), X distribution time is diminished by sending all articles and having X the receiving host simply discard the duplicates. This is an X especially true when communications sessions are limited to once a X day. X X Using NNTP, hosts exchanging news articles have an interactive X mechanism for deciding which articles are to be transmitted. A host X desiring new news, or which has new news to send, will typically X contact one or more of its neighbors using NNTP. First it will X inquire if any new news groups have been created on the serving host X by means of the NEWGROUPS command. If so, and those are appropriate X or desired (as established by local site-dependent rules), those new X newsgroups can be created. X X The client host will then inquire as to which new articles have X arrived in all or some of the newsgroups that it desires to receive, X using the NEWNEWS command. It will receive a list of new articles X from the server, and can request transmission of those articles that X it desires and does not already have. X X Finally, the client can advise the server of those new articles which X the client has recently received. The server will indicate those X articles that it has already obtained copies of, and which articles X should be sent to add to its collection. X X In this manner, only those articles which are not duplicates and X which are desired are transferred. X X X X X X X X X X X X X Kantor & Lapsley [Page 4] X X X RFC 977 February 1986 Network News Transfer Protocol X X X2. The NNTP Specification X X2.1. Overview X X The news server specified by this document uses a stream connection X (such as TCP) and SMTP-like commands and responses. It is designed X to accept connections from hosts, and to provide a simple interface X to the news database. X X This server is only an interface between programs and the news X databases. It does not perform any user interaction or presentation- X level functions. These "user-friendly" functions are better left to X the client programs, which have a better understanding of the X environment in which they are operating. X X When used via Internet TCP, the contact port assigned for this X service is 119. X X2.2. Character Codes X X Commands and replies are composed of characters from the ASCII X character set. When the transport service provides an 8-bit byte X (octet) transmission channel, each 7-bit character is transmitted X right justified in an octet with the high order bit cleared to zero. X X2.3. Commands X X Commands consist of a command word, which in some cases may be X followed by a parameter. Commands with parameters must separate the X parameters from each other and from the command by one or more space X or tab characters. Command lines must be complete with all required X parameters, and may not contain more than one command. X X Commands and command parameters are not case sensitive. That is, a X command or parameter word may be upper case, lower case, or any X mixture of upper and lower case. X X Each command line must be terminated by a CR-LF (Carriage Return - X Line Feed) pair. X X Command lines shall not exceed 512 characters in length, counting all X characters including spaces, separators, punctuation, and the X trailing CR-LF (thus there are 510 characters maximum allowed for the X command and its parameters). There is no provision for continuation X command lines. X X X X Kantor & Lapsley [Page 5] X X X RFC 977 February 1986 Network News Transfer Protocol X X X2.4. Responses X X Responses are of two kinds, textual and status. X X2.4.1. Text Responses X X Text is sent only after a numeric status response line has been sent X that indicates that text will follow. Text is sent as a series of X successive lines of textual matter, each terminated with CR-LF pair. X A single line containing only a period (.) is sent to indicate the X end of the text (i.e., the server will send a CR-LF pair at the end X of the last line of text, a period, and another CR-LF pair). X X If the text contained a period as the first character of the text X line in the original, that first period is doubled. Therefore, the X client must examine the first character of each line received, and X for those beginning with a period, determine either that this is the X end of the text or whether to collapse the doubled period to a single X one. X X The intention is that text messages will usually be displayed on the X user's terminal whereas command/status responses will be interpreted X by the client program before any possible display is done. X X2.4.2. Status Responses X X These are status reports from the server and indicate the response to X the last command received from the client. X X Status response lines begin with a 3 digit numeric code which is X sufficient to distinguish all responses. Some of these may herald X the subsequent transmission of text. X X The first digit of the response broadly indicates the success, X failure, or progress of the previous command. X X 1xx - Informative message X 2xx - Command ok X 3xx - Command ok so far, send the rest of it. X 4xx - Command was correct, but couldn't be performed for X some reason. X 5xx - Command unimplemented, or incorrect, or a serious X program error occurred. X X X X X X Kantor & Lapsley [Page 6] X X X RFC 977 February 1986 Network News Transfer Protocol X X X The next digit in the code indicates the function response category. X X x0x - Connection, setup, and miscellaneous messages X x1x - Newsgroup selection X x2x - Article selection X x3x - Distribution functions X x4x - Posting X x8x - Nonstandard (private implementation) extensions X x9x - Debugging output X X The exact response codes that should be expected from each command X are detailed in the description of that command. In addition, below X is listed a general set of response codes that may be received at any X time. X X Certain status responses contain parameters such as numbers and X names. The number and type of such parameters is fixed for each X response code to simplify interpretation of the response. X X Parameters are separated from the numeric response code and from each X other by a single space. All numeric parameters are decimal, and may X have leading zeros. All string parameters begin after the separating X space, and end before the following separating space or the CR-LF X pair at the end of the line. (String parameters may not, therefore, X contain spaces.) All text, if any, in the response which is not a X parameter of the response must follow and be separated from the last X parameter by a space. Also, note that the text following a response X number may vary in different implementations of the server. The X 3-digit numeric code should be used to determine what response was X sent. X X Response codes not specified in this standard may be used for any X installation-specific additional commands also not specified. These X should be chosen to fit the pattern of x8x specified above. (Note X that debugging is provided for explicitly in the x9x response codes.) X The use of unspecified response codes for standard commands is X prohibited. X X We have provided a response pattern x9x for debugging. Since much X debugging output may be classed as "informative messages", we would X expect, therefore, that responses 190 through 199 would be used for X various debugging outputs. There is no requirement in this X specification for debugging output, but if such is provided over the X connected stream, it must use these response codes. If appropriate X to a specific implementation, other x9x codes may be used for X debugging. (An example might be to use e.g., 290 to acknowledge a X remote debugging request.) X X Kantor & Lapsley [Page 7] X X X RFC 977 February 1986 Network News Transfer Protocol X X X2.4.3. General Responses X X The following is a list of general response codes that may be sent by X the NNTP server. These are not specific to any one command, but may X be returned as the result of a connection, a failure, or some unusual X condition. X X In general, 1xx codes may be ignored or displayed as desired; code X 200 or 201 is sent upon initial connection to the NNTP server X depending upon posting permission; code 400 will be sent when the X NNTP server discontinues service (by operator request, for example); X and 5xx codes indicate that the command could not be performed for X some unusual reason. X X 100 help text X 190 X through X 199 debug output X X 200 server ready - posting allowed X 201 server ready - no posting allowed X X 400 service discontinued X X 500 command not recognized X 501 command syntax error X 502 access restriction or permission denied X 503 program fault - command not performed X X3. Command and Response Details X X On the following pages are descriptions of each command recognized by X the NNTP server and the responses which will be returned by those X commands. X X Each command is shown in upper case for clarity, although case is X ignored in the interpretation of commands by the NNTP server. Any X parameters are shown in lower case. A parameter shown in [square X brackets] is optional. For example, [GMT] indicates that the X triglyph GMT may present or omitted. X X Every command described in this section must be implemented by all X NNTP servers. X X X X X X Kantor & Lapsley [Page 8] X X X RFC 977 February 1986 Network News Transfer Protocol X X X There is no prohibition against additional commands being added; X however, it is recommended that any such unspecified command begin X with the letter "X" to avoid conflict with later revisions of this X specification. X X Implementors are reminded that such additional commands may not X redefine specified status response codes. Using additional X unspecified responses for standard commands is also prohibited. X X3.1. The ARTICLE, BODY, HEAD, and STAT commands X X There are two forms to the ARTICLE command (and the related BODY, X HEAD, and STAT commands), each using a different method of specifying X which article is to be retrieved. When the ARTICLE command is X followed by a message-id in angle brackets ("<" and ">"), the first X form of the command is used; when a numeric parameter or no parameter X is supplied, the second form is invoked. X X The text of the article is returned as a textual response, as X described earlier in this document. X X The HEAD and BODY commands are identical to the ARTICLE command X except that they respectively return only the header lines or text X body of the article. X X The STAT command is similar to the ARTICLE command except that no X text is returned. When selecting by message number within a group, X the STAT command serves to set the current article pointer without X sending text. The returned acknowledgement response will contain the X message-id, which may be of some value. Using the STAT command to X select by message-id is valid but of questionable value, since a X selection by message-id does NOT alter the "current article pointer". X X3.1.1. ARTICLE (selection by message-id) X X ARTICLE X X Display the header, a blank line, then the body (text) of the X specified article. Message-id is the message id of an article as X shown in that article's header. It is anticipated that the client X will obtain the message-id from a list provided by the NEWNEWS X command, from references contained within another article, or from X the message-id provided in the response to some other commands. X X Please note that the internally-maintained "current article pointer" X is NOT ALTERED by this command. This is both to facilitate the X presentation of articles that may be referenced within an article X X Kantor & Lapsley [Page 9] X X X RFC 977 February 1986 Network News Transfer Protocol X X X being read, and because of the semantic difficulties of determining X the proper sequence and membership of an article which may have been X posted to more than one newsgroup. X X3.1.2. ARTICLE (selection by number) X X ARTICLE [nnn] X X Displays the header, a blank line, then the body (text) of the X current or specified article. The optional parameter nnn is the X X numeric id of an article in the current newsgroup and must be chosen X from the range of articles provided when the newsgroup was selected. X If it is omitted, the current article is assumed. X X The internally-maintained "current article pointer" is set by this X command if a valid article number is specified. X X [the following applies to both forms of the article command.] A X response indicating the current article number, a message-id string, X and that text is to follow will be returned. X X The message-id string returned is an identification string contained X within angle brackets ("<" and ">"), which is derived from the header X of the article itself. The Message-ID header line (required by X RFC850) from the article must be used to supply this information. If X the message-id header line is missing from the article, a single X digit "0" (zero) should be supplied within the angle brackets. X X Since the message-id field is unique with each article, it may be X used by a news reading program to skip duplicate displays of articles X that have been posted more than once, or to more than one newsgroup. X X3.1.3. Responses X X 220 n article retrieved - head and body follow X (n = article number, = message-id) X 221 n article retrieved - head follows X 222 n article retrieved - body follows X 223 n article retrieved - request text separately X 412 no newsgroup has been selected X 420 no current article has been selected X 423 no such article number in this group X 430 no such article found X X X X X Kantor & Lapsley [Page 10] X X X RFC 977 February 1986 Network News Transfer Protocol X X X3.2. The GROUP command X X3.2.1. GROUP X X GROUP ggg X X The required parameter ggg is the name of the newsgroup to be X selected (e.g. "net.news"). A list of valid newsgroups may be X obtained from the LIST command. X X The successful selection response will return the article numbers of X the first and last articles in the group, and an estimate of the X number of articles on file in the group. It is not necessary that X the estimate be correct, although that is helpful; it must only be X equal to or larger than the actual number of articles on file. (Some X implementations will actually count the number of articles on file. X Others will just subtract first article number from last to get an X estimate.) X X When a valid group is selected by means of this command, the X internally maintained "current article pointer" is set to the first X article in the group. If an invalid group is specified, the X previously selected group and article remain selected. If an empty X newsgroup is selected, the "current article pointer" is in an X indeterminate state and should not be used. X X Note that the name of the newsgroup is not case-dependent. It must X otherwise match a newsgroup obtained from the LIST command or an X error will result. X X3.2.2. Responses X X 211 n f l s group selected X (n = estimated number of articles in group, X f = first article number in the group, X l = last article number in the group, X s = name of the group.) X 411 no such news group X X X X X X X X X X X Kantor & Lapsley [Page 11] X X X RFC 977 February 1986 Network News Transfer Protocol X X X3.3. The HELP command X X3.3.1. HELP X X HELP X X Provides a short summary of commands that are understood by this X implementation of the server. The help text will be presented as a X textual response, terminated by a single period on a line by itself. X X 3.3.2. Responses X X 100 help text follows X X3.4. The IHAVE command X X3.4.1. IHAVE X X IHAVE X X The IHAVE command informs the server that the client has an article X whose id is . If the server desires a copy of that X article, it will return a response instructing the client to send the X entire article. If the server does not want the article (if, for X example, the server already has a copy of it), a response indicating X that the article is not wanted will be returned. X X If transmission of the article is requested, the client should send X the entire article, including header and body, in the manner X specified for text transmission from the server. A response code X indicating success or failure of the transferral of the article will X be returned. X X This function differs from the POST command in that it is intended X for use in transferring already-posted articles between hosts. X Normally it will not be used when the client is a personal X newsreading program. In particular, this function will invoke the X server's news posting program with the appropriate settings (flags, X options, etc) to indicate that the forthcoming article is being X forwarded from another host. X X The server may, however, elect not to post or forward the article if X after further examination of the article it deems it inappropriate to X do so. The 436 or 437 error codes may be returned as appropriate to X the situation. X X Reasons for such subsequent rejection of an article may include such X X Kantor & Lapsley [Page 12] X X X RFC 977 February 1986 Network News Transfer Protocol X X X problems as inappropriate newsgroups or distributions, disk space X limitations, article lengths, garbled headers, and the like. These X are typically restrictions enforced by the server host's news X software and not necessarily the NNTP server itself. X X3.4.2. Responses X X 235 article transferred ok X 335 send article to be transferred. End with . X 435 article not wanted - do not send it X 436 transfer failed - try again later X 437 article rejected - do not try again X X An implementation note: X X Because some host news posting software may not be able to decide X immediately that an article is inappropriate for posting or X forwarding, it is acceptable to acknowledge the successful transfer X of the article and to later silently discard it. Thus it is X permitted to return the 235 acknowledgement code and later discard X the received article. This is not a fully satisfactory solution to X the problem. Perhaps some implementations will wish to send mail to X the author of the article in certain of these cases. X X3.5. The LAST command X X3.5.1. LAST X X LAST X X The internally maintained "current article pointer" is set to the X previous article in the current newsgroup. If already positioned at X the first article of the newsgroup, an error message is returned and X the current article remains selected. X X The internally-maintained "current article pointer" is set by this X command. X X A response indicating the current article number, and a message-id X string will be returned. No text is sent in response to this X command. X X3.5.2. Responses X X 223 n a article retrieved - request text separately X (n = article number, a = unique article id) X X X Kantor & Lapsley [Page 13] X X X RFC 977 February 1986 Network News Transfer Protocol X X X 412 no newsgroup selected X 420 no current article has been selected X 422 no previous article in this group X X3.6. The LIST command X X3.6.1. LIST X X LIST X X Returns a list of valid newsgroups and associated information. Each X newsgroup is sent as a line of text in the following format: X X group last first p X X where is the name of the newsgroup, is the number of X the last known article currently in that newsgroup, is the X number of the first article currently in the newsgroup, and

is X either 'y' or 'n' indicating whether posting to this newsgroup is X allowed ('y') or prohibited ('n'). X X The and fields will always be numeric. They may have X leading zeros. If the field evaluates to less than the X field, there are no articles currently on file in the X newsgroup. X X Note that posting may still be prohibited to a client even though the X LIST command indicates that posting is permitted to a particular X newsgroup. See the POST command for an explanation of client X prohibitions. The posting flag exists for each newsgroup because X some newsgroups are moderated or are digests, and therefore cannot be X posted to; that is, articles posted to them must be mailed to a X moderator who will post them for the submitter. This is independent X of the posting permission granted to a client by the NNTP server. X X Please note that an empty list (i.e., the text body returned by this X command consists only of the terminating period) is a possible valid X response, and indicates that there are currently no valid newsgroups. X X3.6.2. Responses X X 215 list of newsgroups follows X X X X X X X Kantor & Lapsley [Page 14] X X X RFC 977 February 1986 Network News Transfer Protocol X X X3.7. The NEWGROUPS command X X3.7.1. NEWGROUPS X X NEWGROUPS date time [GMT] [] X X A list of newsgroups created since will be listed in X the same format as the LIST command. X X The date is sent as 6 digits in the format YYMMDD, where YY is the X last two digits of the year, MM is the two digits of the month (with X leading zero, if appropriate), and DD is the day of the month (with X leading zero, if appropriate). The closest century is assumed as X part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is X 1999, 00 is 2000). X X Time must also be specified. It must be as 6 digits HHMMSS with HH X being hours on the 24-hour clock, MM minutes 00-59, and SS seconds X 00-59. The time is assumed to be in the server's timezone unless the X token "GMT" appears, in which case both time and date are evaluated X at the 0 meridian. X X The optional parameter "distributions" is a list of distribution X groups, enclosed in angle brackets. If specified, the distribution X portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be X examined for a match with the distribution categories listed, and X only those new newsgroups which match will be listed. If more than X one distribution group is to be listed, they must be separated by X commas within the angle brackets. X X Please note that an empty list (i.e., the text body returned by this X command consists only of the terminating period) is a possible valid X response, and indicates that there are currently no new newsgroups. X X3.7.2. Responses X X 231 list of new newsgroups follows X X X X X X X X X X X X Kantor & Lapsley [Page 15] X X X RFC 977 February 1986 Network News Transfer Protocol X X X3.8. The NEWNEWS command X X3.8.1. NEWNEWS X X NEWNEWS newsgroups date time [GMT] [] X X A list of message-ids of articles posted or received to the specified X newsgroup since "date" will be listed. The format of the listing will X be one message-id per line, as though text were being sent. A single X line consisting solely of one period followed by CR-LF will terminate X the list. X X Date and time are in the same format as the NEWGROUPS command. X X A newsgroup name containing a "*" (an asterisk) may be specified to X broaden the article search to some or all newsgroups. The asterisk X will be extended to match any part of a newsgroup name (e.g., X net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus X if only an asterisk is given as the newsgroup name, all newsgroups X will be searched for new news. X X (Please note that the asterisk "*" expansion is a general X replacement; in particular, the specification of e.g., net.*.unix X should be correctly expanded to embrace names such as net.wombat.unix X and net.whocares.unix.) X X Conversely, if no asterisk appears in a given newsgroup name, only X the specified newsgroup will be searched for new articles. Newsgroup X names must be chosen from those returned in the listing of available X groups. Multiple newsgroup names (including a "*") may be specified X in this command, separated by a comma. No comma shall appear after X the last newsgroup in the list. [Implementors are cautioned to keep X the 512 character command length limit in mind.] X X The exclamation point ("!") may be used to negate a match. This can X be used to selectively omit certain newsgroups from an otherwise X larger list. For example, a newsgroups specification of X "net.*,mod.*,!mod.map.*" would specify that all net. and X all mod. EXCEPT mod.map. newsgroup names would be X matched. If used, the exclamation point must appear as the first X character of the given newsgroup name or pattern. X X The optional parameter "distributions" is a list of distribution X groups, enclosed in angle brackets. If specified, the distribution X portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will X be examined for a match with the distribution categories listed, and X only those articles which have at least one newsgroup belonging to X X Kantor & Lapsley [Page 16] X X X RFC 977 February 1986 Network News Transfer Protocol X X X the list of distributions will be listed. If more than one X distribution group is to be supplied, they must be separated by X commas within the angle brackets. X X The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute X news is discussed in an earlier part of this document. X X Please note that an empty list (i.e., the text body returned by this X command consists only of the terminating period) is a possible valid X response, and indicates that there is currently no new news. X X3.8.2. Responses X X 230 list of new articles by message-id follows X X3.9. The NEXT command X X3.9.1. NEXT X X NEXT X X The internally maintained "current article pointer" is advanced to X the next article in the current newsgroup. If no more articles X remain in the current group, an error message is returned and the X current article remains selected. X X The internally-maintained "current article pointer" is set by this X command. X X A response indicating the current article number, and the message-id X string will be returned. No text is sent in response to this X command. X X3.9.2. Responses X X 223 n a article retrieved - request text separately X (n = article number, a = unique article id) X 412 no newsgroup selected X 420 no current article has been selected X 421 no next article in this group X X X X X X X X X Kantor & Lapsley [Page 17] X X X RFC 977 February 1986 Network News Transfer Protocol X X X3.10. The POST command X X3.10.1. POST X X POST X X If posting is allowed, response code 340 is returned to indicate that X the article to be posted should be sent. Response code 440 indicates X that posting is prohibited for some installation-dependent reason. X X If posting is permitted, the article should be presented in the X format specified by RFC850, and should include all required header X lines. After the article's header and body have been completely sent X by the client to the server, a further response code will be returned X to indicate success or failure of the posting attempt. X X The text forming the header and body of the message to be posted X should be sent by the client using the conventions for text received X from the news server: A single period (".") on a line indicates the X end of the text, with lines starting with a period in the original X text having that period doubled during transmission. X X No attempt shall be made by the server to filter characters, fold or X limit lines, or otherwise process incoming text. It is our intent X that the server just pass the incoming message to be posted to the X server installation's news posting software, which is separate from X this specification. See RFC850 for more details. X X Since most installations will want the client news program to allow X the user to prepare his message using some sort of text editor, and X transmit it to the server for posting only after it is composed, the X client program should take note of the herald message that greeted it X when the connection was first established. This message indicates X whether postings from that client are permitted or not, and can be X used to caution the user that his access is read-only if that is the X case. This will prevent the user from wasting a good deal of time X composing a message only to find posting of the message was denied. X The method and determination of which clients and hosts may post is X installation dependent and is not covered by this specification. X X3.10.2. Responses X X 240 article posted ok X 340 send article to be posted. End with . X 440 posting not allowed X 441 posting failed X X X Kantor & Lapsley [Page 18] X X X RFC 977 February 1986 Network News Transfer Protocol X X X (for reference, one of the following codes will be sent upon initial X connection; the client program should determine whether posting is X generally permitted from these:) 200 server ready - posting allowed X 201 server ready - no posting allowed X X3.11. The QUIT command X X3.11.1. QUIT X X QUIT X X The server process acknowledges the QUIT command and then closes the X connection to the client. This is the preferred method for a client X to indicate that it has finished all its transactions with the NNTP X server. X X If a client simply disconnects (or the connection times out, or some X other fault occurs), the server should gracefully cease its attempts X to service the client. X X3.11.2. Responses X X 205 closing connection - goodbye! X X3.12. The SLAVE command X X3.12.1. SLAVE X X SLAVE X X Indicates to the server that this client connection is to a slave X server, rather than a user. X X This command is intended for use in separating connections to single X users from those to subsidiary ("slave") servers. It may be used to X indicate that priority should therefore be given to requests from X this client, as it is presumably serving more than one person. It X might also be used to determine which connections to close when X system load levels are exceeded, perhaps giving preference to slave X servers. The actual use this command is put to is entirely X implementation dependent, and may vary from one host to another. In X NNTP servers which do not give priority to slave servers, this X command must nonetheless be recognized and acknowledged. X X3.12.2. Responses X X 202 slave status noted X X Kantor & Lapsley [Page 19] X X X RFC 977 February 1986 Network News Transfer Protocol X X X4. Sample Conversations X X These are samples of the conversations that might be expected with X the news server in hypothetical sessions. The notation C: indicates X commands sent to the news server from the client program; S: indicate X responses received from the server by the client. X X4.1. Example 1 - relative access with NEXT X X S: (listens at TCP port 119) X X C: (requests connection on TCP port 119) X S: 200 wombatvax news server ready - posting ok X X (client asks for a current newsgroup list) X C: LIST X S: 215 list of newsgroups follows X S: net.wombats 00543 00501 y X S: net.unix-wizards 10125 10011 y X (more information here) X S: net.idiots 00100 00001 n X S: . X X (client selects a newsgroup) X C: GROUP net.unix-wizards X S: 211 104 10011 10125 net.unix-wizards group selected X (there are 104 articles on file, from 10011 to 10125) X X (client selects an article to read) X C: STAT 10110 X S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics X only (article 10110 selected, its message-id is X <23445@sdcsvax.ARPA>) X X (client examines the header) X C: HEAD X S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head X follows (text of the header appears here) X S: . X X (client wants to see the text body of the article) X C: BODY X S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body X follows (body text here) X S: . X X (client selects next article in group) X X Kantor & Lapsley [Page 20] X X X RFC 977 February 1986 Network News Transfer Protocol X X X C: NEXT X S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics X only (article 10113 was next in group) X X (client finishes session) X C: QUIT X S: 205 goodbye. X X4.2. Example 2 - absolute article access with ARTICLE X X S: (listens at TCP port 119) X X C: (requests connection on TCP port 119) X S: 201 UCB-VAX netnews server ready -- no posting allowed X X C: GROUP msgs X S: 211 103 402 504 msgs Your new group is msgs X (there are 103 articles, from 402 to 504) X X C: ARTICLE 401 X S: 423 No such article in this newsgroup X X C: ARTICLE 402 X S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows X S: (article header and body follow) X S: . X X C: HEAD 403 X S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows X S: (article header follows) X S: . X X C: QUIT X S: 205 UCB-VAX news server closing connection. Goodbye. X X4.3. Example 3 - NEWGROUPS command X X S: (listens at TCP port 119) X X C: (requests connection on TCP port 119) X S: 200 Imaginary Institute News Server ready (posting ok) X X (client asks for new newsgroups since April 3, 1985) X C: NEWGROUPS 850403 020000 X X S: 231 New newsgroups since 03/04/85 02:00:00 follow X X X Kantor & Lapsley [Page 21] X X X RFC 977 February 1986 Network News Transfer Protocol X X X S: net.music.gdead X S: net.games.sources X S: . X X C: GROUP net.music.gdead X S: 211 0 1 1 net.music.gdead Newsgroup selected X (there are no articles in that newsgroup, and X the first and last article numbers should be ignored) X X C: QUIT X S: 205 Imaginary Institute news server ceasing service. Bye! X X4.4. Example 4 - posting a news article X X S: (listens at TCP port 119) X X C: (requests connection on TCP port 119) X S: 200 BANZAIVAX news server ready, posting allowed. X X C: POST X S: 340 Continue posting; Period on a line by itself to end X C: (transmits news article in RFC850 format) X C: . X S: 240 Article posted successfully. X X C: QUIT X S: 205 BANZAIVAX closing connection. Goodbye. X X4.5. Example 5 - interruption due to operator request X X S: (listens at TCP port 119) X X C: (requests connection on TCP port 119) X S: 201 genericvax news server ready, no posting allowed. X X (assume normal conversation for some time, and X that a newsgroup has been selected) X X C: NEXT X S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate. X X C: HEAD X C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows. X X S: (sends head of article, but halfway through is X interrupted by an operator request. The following X then occurs, without client intervention.) X X Kantor & Lapsley [Page 22] X X X RFC 977 February 1986 Network News Transfer Protocol X X X S: (ends current line with a CR-LF pair) X S: . X S: 400 Connection closed by operator. Goodbye. X S: (closes connection) X X4.6. Example 6 - Using the news server to distribute news between X systems. X X S: (listens at TCP port 119) X X C: (requests connection on TCP port 119) X S: 201 Foobar NNTP server ready (no posting) X X (client asks for new newsgroups since 2 am, May 15, 1985) X C: NEWGROUPS 850515 020000 X S: 235 New newsgroups since 850515 follow X S: net.fluff X S: net.lint X S: . X X (client asks for new news articles since 2 am, May 15, 1985) X C: NEWNEWS * 850515 020000 X S: 230 New news since 850515 020000 follows X S: <1772@foo.UUCP> X S: <87623@baz.UUCP> X S: <17872@GOLD.CSNET> X S: . X X (client asks for article <1772@foo.UUCP>) X C: ARTICLE <1772@foo.UUCP> X S: 220 <1772@foo.UUCP> All of article follows X S: (sends entire message) X S: . X X (client asks for article <87623@baz.UUCP> X C: ARTICLE <87623@baz.UUCP> X S: 220 <87623@baz.UUCP> All of article follows X S: (sends entire message) X S: . X X (client asks for article <17872@GOLD.CSNET> X C: ARTICLE <17872@GOLD.CSNET> X S: 220 <17872@GOLD.CSNET> All of article follows X S: (sends entire message) X S: . X X X X Kantor & Lapsley [Page 23] X X X RFC 977 February 1986 Network News Transfer Protocol X X X (client offers an article it has received recently) X C: IHAVE <4105@ucbvax.ARPA> X S: 435 Already seen that one, where you been? X X (client offers another article) X C: IHAVE <4106@ucbvax.ARPA> X S: 335 News to me! to end. X C: (sends article) X C: . X S: 235 Article transferred successfully. Thanks. X X (or) X X S: 436 Transfer failed. X X (client is all through with the session) X C: QUIT X S: 205 Foobar NNTP server bids you farewell. X X4.7. Summary of commands and responses. X X The following are the commands recognized and responses returned by X the NNTP server. X X4.7.1. Commands X X ARTICLE X BODY X GROUP X HEAD X HELP X IHAVE X LAST X LIST X NEWGROUPS X NEWNEWS X NEXT X POST X QUIT X SLAVE X STAT X X4.7.2. Responses X X 100 help text follows X 199 debug output X X X Kantor & Lapsley [Page 24] X X X RFC 977 February 1986 Network News Transfer Protocol X X X 200 server ready - posting allowed X 201 server ready - no posting allowed X 202 slave status noted X 205 closing connection - goodbye! X 211 n f l s group selected X 215 list of newsgroups follows X 220 n article retrieved - head and body follow 221 n article X retrieved - head follows X 222 n article retrieved - body follows X 223 n article retrieved - request text separately 230 list of new X articles by message-id follows X 231 list of new newsgroups follows X 235 article transferred ok X 240 article posted ok X X 335 send article to be transferred. End with . X 340 send article to be posted. End with . X X 400 service discontinued X 411 no such news group X 412 no newsgroup has been selected X 420 no current article has been selected X 421 no next article in this group X 422 no previous article in this group X 423 no such article number in this group X 430 no such article found X 435 article not wanted - do not send it X 436 transfer failed - try again later X 437 article rejected - do not try again. X 440 posting not allowed X 441 posting failed X X 500 command not recognized X 501 command syntax error X 502 access restriction or permission denied X 503 program fault - command not performed X X4.8. A Brief Word about the USENET News System X X In the UNIX world, which traditionally has been linked by 1200 baud X dial-up telephone lines, the USENET News system has evolved to handle X central storage, indexing, retrieval, and distribution of news. With X the exception of its underlying transport mechanism (UUCP), USENET X News is an efficient means of providing news and bulletin service to X subscribers on UNIX and other hosts worldwide. The USENET News X X X X Kantor & Lapsley [Page 25] X X X RFC 977 February 1986 Network News Transfer Protocol X X X system is discussed in detail in RFC 850. It runs on most versions X of UNIX and on many other operating systems, and is customarily X distributed without charge. X X USENET uses a spooling area on the UNIX host to store news articles, X one per file. Each article consists of a series of heading text, X which contain the sender's identification and organizational X affiliation, timestamps, electronic mail reply paths, subject, X newsgroup (subject category), and the like. A complete news article X is reproduced in its entirety below. Please consult RFC 850 for more X details. X X Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site X sdcsvax.UUCP X Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp X Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek X !honman X From: honman@unitek.uucp (Man Wong) X Newsgroups: net.unix-wizards X Subject: foreground -> background ? X Message-ID: <167@unitek.uucp> X Date: 25 Sep 85 23:51:52 GMT X Date-Received: 29 Sep 85 09:54:48 GMT X Reply-To: honman@unitek.UUCP (Hon-Man Wong) X Distribution: net.all X Organization: Unitek Technologies Corporation X Lines: 12 X X I have a process (C program) which generates a child and waits for X it to return. What I would like to do is to be able to run the X child process interactively for a while before kicking itself into X the background so I can return to the parent process (while the X child process is RUNNING in the background). Can it be done? And X if it can, how? X X Please reply by E-mail. Thanks in advance. X X Hon-Man Wong X X X X X X X X X X X Kantor & Lapsley [Page 26] X X X RFC 977 February 1986 Network News Transfer Protocol X X X5. References X X [1] Crocker, D., "Standard for the Format of ARPA Internet Text X Messages", RFC-822, Department of Electrical Engineering, X University of Delaware, August, 1982. X X [2] Horton, M., "Standard for Interchange of USENET Messages", X RFC-850, USENET Project, June, 1983. X X [3] Postel, J., "Transmission Control Protocol- DARPA Internet X Program Protocol Specification", RFC-793, USC/Information X Sciences Institute, September, 1981. X X [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821, X USC/Information Sciences Institute, August, 1982. X X6. Acknowledgements X X The authors wish to express their heartfelt thanks to those many X people who contributed to this specification, and especially to Erik X Fair and Chuq von Rospach, without whose inspiration this whole thing X would not have been necessary. X X7. Notes X X <1> UNIX is a trademark of Bell Laboratories. X X X X X X X X X X X X X X X X X X X X X X X Kantor & Lapsley [Page 27] X END_OF_FILE if test 53523 -ne `wc -c <'./doc/rfc977'`; then echo shar: \"'./doc/rfc977'\" unpacked with wrong size! fi # end of './doc/rfc977' fi echo shar: End of archive 9 \(of 9\). cp /dev/null ark9isdone MISSING="" for I in 1 2 3 4 5 6 7 8 9 ; do if test ! -f ark${I}isdone ; then MISSING="${MISSING} ${I}" fi done if test "${MISSING}" = "" ; then echo You have unpacked all 9 archives. rm -f ark[1-9]isdone ark[1-9][0-9]isdone else echo You still need to unpack the following archives: echo " " ${MISSING} fi ## End of shell archive. exit 0