From d78b61e3efaea197a6e5b2b72bf2981a9ed69461 Mon Sep 17 00:00:00 2001 From: Rob Funk Date: Tue, 8 Jun 2004 03:59:01 +0000 Subject: Add files from ESR's dev directory that weren't under version control svn path=/trunk/; revision=3881 --- RFC/rfc977.txt | 1539 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1539 insertions(+) create mode 100644 RFC/rfc977.txt (limited to 'RFC/rfc977.txt') diff --git a/RFC/rfc977.txt b/RFC/rfc977.txt new file mode 100644 index 00000000..0f965c48 --- /dev/null +++ b/RFC/rfc977.txt @@ -0,0 +1,1539 @@ + + +Network Working Group Brian Kantor (U.C. San Diego) +Request for Comments: 977 Phil Lapsley (U.C. Berkeley) + February 1986 + + Network News Transfer Protocol + + A Proposed Standard for the Stream-Based + Transmission of News + +Status of This Memo + + NNTP specifies a protocol for the distribution, inquiry, retrieval, + and posting of news articles using a reliable stream-based + transmission of news among the ARPA-Internet community. NNTP is + designed so that news articles are stored in a central database + allowing a subscriber to select only those items he wishes to read. + Indexing, cross-referencing, and expiration of aged messages are also + provided. This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + +1. Introduction + + For many years, the ARPA-Internet community has supported the + distribution of bulletins, information, and data in a timely fashion + to thousands of participants. We collectively refer to such items of + information as "news". Such news provides for the rapid + dissemination of items of interest such as software bug fixes, new + product reviews, technical tips, and programming pointers, as well as + rapid-fire discussions of matters of concern to the working computer + professional. News is very popular among its readers. + + There are popularly two methods of distributing such news: the + Internet method of direct mailing, and the USENET news system. + +1.1. Internet Mailing Lists + + The Internet community distributes news by the use of mailing lists. + These are lists of subscriber's mailbox addresses and remailing + sublists of all intended recipients. These mailing lists operate by + remailing a copy of the information to be distributed to each + subscriber on the mailing list. Such remailing is inefficient when a + mailing list grows beyond a dozen or so people, since sending a + separate copy to each of the subscribers occupies large quantities of + network bandwidth, CPU resources, and significant amounts of disk + storage at the destination host. There is also a significant problem + in maintenance of the list itself: as subscribers move from one job + to another; as new subscribers join and old ones leave; and as hosts + come in and out of service. + + + + +Kantor & Lapsley [Page 1] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +1.2. The USENET News System + + Clearly, a worthwhile reduction of the amount of these resources used + can be achieved if articles are stored in a central database on the + receiving host instead of in each subscriber's mailbox. The USENET + news system provides a method of doing just this. There is a central + repository of the news articles in one place (customarily a spool + directory of some sort), and a set of programs that allow a + subscriber to select those items he wishes to read. Indexing, + cross-referencing, and expiration of aged messages are also provided. + +1.3. Central Storage of News + + For clusters of hosts connected together by fast local area networks + (such as Ethernet), it makes even more sense to consolidate news + distribution onto one (or a very few) hosts, and to allow access to + these news articles using a server and client model. Subscribers may + then request only the articles they wish to see, without having to + wastefully duplicate the storage of a copy of each item on each host. + +1.4. A Central News Server + + A way to achieve these economies is to have a central computer system + that can provide news service to the other systems on the local area + network. Such a server would manage the collection of news articles + and index files, with each person who desires to read news bulletins + doing so over the LAN. For a large cluster of computer systems, the + savings in total disk space is clearly worthwhile. Also, this allows + workstations with limited disk storage space to participate in the + news without incoming items consuming oppressive amounts of the + workstation's disk storage. + + We have heard rumors of somewhat successful attempts to provide + centralized news service using IBIS and other shared or distributed + file systems. While it is possible that such a distributed file + system implementation might work well with a group of similar + computers running nearly identical operating systems, such a scheme + is not general enough to offer service to a wide range of client + systems, especially when many diverse operating systems may be in use + among a group of clients. There are few (if any) shared or networked + file systems that can offer the generality of service that stream + connections using Internet TCP provide, particularly when a wide + range of host hardware and operating systems are considered. + + NNTP specifies a protocol for the distribution, inquiry, retrieval, + and posting of news articles using a reliable stream (such as TCP) + server-client model. NNTP is designed so that news articles need only + + +Kantor & Lapsley [Page 2] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + be stored on one (presumably central) host, and subscribers on other + hosts attached to the LAN may read news articles using stream + connections to the news host. + + NNTP is modelled upon the news article specifications in RFC 850, + which describes the USENET news system. However, NNTP makes few + demands upon the structure, content, or storage of news articles, and + thus we believe it easily can be adapted to other non-USENET news + systems. + + Typically, the NNTP server runs as a background process on one host, + and would accept connections from other hosts on the LAN. This works + well when there are a number of small computer systems (such as + workstations, with only one or at most a few users each), and a large + central server. + +1.5. Intermediate News Servers + + For clusters of machines with many users (as might be the case in a + university or large industrial environment), an intermediate server + might be used. This intermediate or "slave" server runs on each + computer system, and is responsible for mediating news reading + requests and performing local caching of recently-retrieved news + articles. + + Typically, a client attempting to obtain news service would first + attempt to connect to the news service port on the local machine. If + this attempt were unsuccessful, indicating a failed server, an + installation might choose to either deny news access, or to permit + connection to the central "master" news server. + + For workstations or other small systems, direct connection to the + master server would probably be the normal manner of operation. + + This specification does not cover the operation of slave NNTP + servers. We merely suggest that slave servers are a logical addition + to NNTP server usage which would enhance operation on large local + area networks. + +1.6. News Distribution + + NNTP has commands which provide a straightforward method of + exchanging articles between cooperating hosts. Hosts which are well + connected on a local area or other fast network and who wish to + actually obtain copies of news articles for local storage might well + find NNTP to be a more efficient way to distribute news than more + traditional transfer methods (such as UUCP). + + +Kantor & Lapsley [Page 3] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + In the traditional method of distributing news articles, news is + propagated from host to host by flooding - that is, each host will + send all its new news articles on to each host that it feeds. These + hosts will then in turn send these new articles on to other hosts + that they feed. Clearly, sending articles that a host already has + obtained a copy of from another feed (many hosts that receive news + are redundantly fed) again is a waste of time and communications + resources, but for transport mechanisms that are single-transaction + based rather than interactive (such as UUCP in the UNIX-world <1>), + distribution time is diminished by sending all articles and having + the receiving host simply discard the duplicates. This is an + especially true when communications sessions are limited to once a + day. + + Using NNTP, hosts exchanging news articles have an interactive + mechanism for deciding which articles are to be transmitted. A host + desiring new news, or which has new news to send, will typically + contact one or more of its neighbors using NNTP. First it will + inquire if any new news groups have been created on the serving host + by means of the NEWGROUPS command. If so, and those are appropriate + or desired (as established by local site-dependent rules), those new + newsgroups can be created. + + The client host will then inquire as to which new articles have + arrived in all or some of the newsgroups that it desires to receive, + using the NEWNEWS command. It will receive a list of new articles + from the server, and can request transmission of those articles that + it desires and does not already have. + + Finally, the client can advise the server of those new articles which + the client has recently received. The server will indicate those + articles that it has already obtained copies of, and which articles + should be sent to add to its collection. + + In this manner, only those articles which are not duplicates and + which are desired are transferred. + + + + + + + + + + + + + +Kantor & Lapsley [Page 4] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +2. The NNTP Specification + +2.1. Overview + + The news server specified by this document uses a stream connection + (such as TCP) and SMTP-like commands and responses. It is designed + to accept connections from hosts, and to provide a simple interface + to the news database. + + This server is only an interface between programs and the news + databases. It does not perform any user interaction or presentation- + level functions. These "user-friendly" functions are better left to + the client programs, which have a better understanding of the + environment in which they are operating. + + When used via Internet TCP, the contact port assigned for this + service is 119. + +2.2. Character Codes + + Commands and replies are composed of characters from the ASCII + character set. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted + right justified in an octet with the high order bit cleared to zero. + +2.3. Commands + + Commands consist of a command word, which in some cases may be + followed by a parameter. Commands with parameters must separate the + parameters from each other and from the command by one or more space + or tab characters. Command lines must be complete with all required + parameters, and may not contain more than one command. + + Commands and command parameters are not case sensitive. That is, a + command or parameter word may be upper case, lower case, or any + mixture of upper and lower case. + + Each command line must be terminated by a CR-LF (Carriage Return - + Line Feed) pair. + + Command lines shall not exceed 512 characters in length, counting all + characters including spaces, separators, punctuation, and the + trailing CR-LF (thus there are 510 characters maximum allowed for the + command and its parameters). There is no provision for continuation + command lines. + + + + +Kantor & Lapsley [Page 5] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +2.4. Responses + + Responses are of two kinds, textual and status. + +2.4.1. Text Responses + + Text is sent only after a numeric status response line has been sent + that indicates that text will follow. Text is sent as a series of + successive lines of textual matter, each terminated with CR-LF pair. + A single line containing only a period (.) is sent to indicate the + end of the text (i.e., the server will send a CR-LF pair at the end + of the last line of text, a period, and another CR-LF pair). + + If the text contained a period as the first character of the text + line in the original, that first period is doubled. Therefore, the + client must examine the first character of each line received, and + for those beginning with a period, determine either that this is the + end of the text or whether to collapse the doubled period to a single + one. + + The intention is that text messages will usually be displayed on the + user's terminal whereas command/status responses will be interpreted + by the client program before any possible display is done. + +2.4.2. Status Responses + + These are status reports from the server and indicate the response to + the last command received from the client. + + Status response lines begin with a 3 digit numeric code which is + sufficient to distinguish all responses. Some of these may herald + the subsequent transmission of text. + + The first digit of the response broadly indicates the success, + failure, or progress of the previous command. + + 1xx - Informative message + 2xx - Command ok + 3xx - Command ok so far, send the rest of it. + 4xx - Command was correct, but couldn't be performed for + some reason. + 5xx - Command unimplemented, or incorrect, or a serious + program error occurred. + + + + + + +Kantor & Lapsley [Page 6] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + + The next digit in the code indicates the function response category. + + x0x - Connection, setup, and miscellaneous messages + x1x - Newsgroup selection + x2x - Article selection + x3x - Distribution functions + x4x - Posting + x8x - Nonstandard (private implementation) extensions + x9x - Debugging output + + The exact response codes that should be expected from each command + are detailed in the description of that command. In addition, below + is listed a general set of response codes that may be received at any + time. + + Certain status responses contain parameters such as numbers and + names. The number and type of such parameters is fixed for each + response code to simplify interpretation of the response. + + Parameters are separated from the numeric response code and from each + other by a single space. All numeric parameters are decimal, and may + have leading zeros. All string parameters begin after the separating + space, and end before the following separating space or the CR-LF + pair at the end of the line. (String parameters may not, therefore, + contain spaces.) All text, if any, in the response which is not a + parameter of the response must follow and be separated from the last + parameter by a space. Also, note that the text following a response + number may vary in different implementations of the server. The + 3-digit numeric code should be used to determine what response was + sent. + + Response codes not specified in this standard may be used for any + installation-specific additional commands also not specified. These + should be chosen to fit the pattern of x8x specified above. (Note + that debugging is provided for explicitly in the x9x response codes.) + The use of unspecified response codes for standard commands is + prohibited. + + 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] + + + +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] + + + +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 + + 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] + + + +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 article retrieved - head and body follow + (n = article number, = message-id) + 221 n article retrieved - head follows + 222 n article retrieved - body follows + 223 n 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] + + + +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] + + + +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 + + The IHAVE command informs the server that the client has an article + whose id is . 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] + + + +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 . + 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] + + + +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 is the name of the newsgroup, is the number of + the last known article currently in that newsgroup, is the + number of the first article currently in the newsgroup, and

is + either 'y' or 'n' indicating whether posting to this newsgroup is + allowed ('y') or prohibited ('n'). + + The and fields will always be numeric. They may have + leading zeros. If the field evaluates to less than the + 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] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.7. The NEWGROUPS command + +3.7.1. NEWGROUPS + + NEWGROUPS date time [GMT] [] + + A list of newsgroups created since 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] + + + +RFC 977 February 1986 +Network News Transfer Protocol + + +3.8. The NEWNEWS command + +3.8.1. NEWNEWS + + NEWNEWS newsgroups date time [GMT] [] + + 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. and + all mod. EXCEPT mod.map. 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] + + + +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] + + + +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 . + 440 posting not allowed + 441 posting failed + + + +Kantor & Lapsley [Page 18] + + + +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] + + + +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] + + + +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] + + + +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] + + + +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] + + + +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! 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] + + + +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 article retrieved - head and body follow 221 n article + retrieved - head follows + 222 n article retrieved - body follows + 223 n 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 . + 340 send article to be posted. End with . + + 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] + + + +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] + + + +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] + -- cgit v1.2.3