![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc977 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / nntp / doc|
Return to rfc977 CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / nntp / doc |
1.1 root 1:
2:
3: Network Working Group Brian Kantor (U.C. San Diego)
4: Request for Comments: 977 Phil Lapsley (U.C. Berkeley)
5: February 1986
6:
7: Network News Transfer Protocol
8:
9: A Proposed Standard for the Stream-Based
10: Transmission of News
11:
12: Status of This Memo
13:
14: NNTP specifies a protocol for the distribution, inquiry, retrieval,
15: and posting of news articles using a reliable stream-based
16: transmission of news among the ARPA-Internet community. NNTP is
17: designed so that news articles are stored in a central database
18: allowing a subscriber to select only those items he wishes to read.
19: Indexing, cross-referencing, and expiration of aged messages are also
20: provided. This RFC suggests a proposed protocol for the ARPA-Internet
21: community, and requests discussion and suggestions for improvements.
22: Distribution of this memo is unlimited.
23:
24: 1. Introduction
25:
26: For many years, the ARPA-Internet community has supported the
27: distribution of bulletins, information, and data in a timely fashion
28: to thousands of participants. We collectively refer to such items of
29: information as "news". Such news provides for the rapid
30: dissemination of items of interest such as software bug fixes, new
31: product reviews, technical tips, and programming pointers, as well as
32: rapid-fire discussions of matters of concern to the working computer
33: professional. News is very popular among its readers.
34:
35: There are popularly two methods of distributing such news: the
36: Internet method of direct mailing, and the USENET news system.
37:
38: 1.1. Internet Mailing Lists
39:
40: The Internet community distributes news by the use of mailing lists.
41: These are lists of subscriber's mailbox addresses and remailing
42: sublists of all intended recipients. These mailing lists operate by
43: remailing a copy of the information to be distributed to each
44: subscriber on the mailing list. Such remailing is inefficient when a
45: mailing list grows beyond a dozen or so people, since sending a
46: separate copy to each of the subscribers occupies large quantities of
47: network bandwidth, CPU resources, and significant amounts of disk
48: storage at the destination host. There is also a significant problem
49: in maintenance of the list itself: as subscribers move from one job
50: to another; as new subscribers join and old ones leave; and as hosts
51: come in and out of service.
52:
53:
54:
55:
56: Kantor & Lapsley [Page 1]
57:
58:
59:
60: RFC 977 February 1986
61: Network News Transfer Protocol
62:
63:
64: 1.2. The USENET News System
65:
66: Clearly, a worthwhile reduction of the amount of these resources used
67: can be achieved if articles are stored in a central database on the
68: receiving host instead of in each subscriber's mailbox. The USENET
69: news system provides a method of doing just this. There is a central
70: repository of the news articles in one place (customarily a spool
71: directory of some sort), and a set of programs that allow a
72: subscriber to select those items he wishes to read. Indexing,
73: cross-referencing, and expiration of aged messages are also provided.
74:
75: 1.3. Central Storage of News
76:
77: For clusters of hosts connected together by fast local area networks
78: (such as Ethernet), it makes even more sense to consolidate news
79: distribution onto one (or a very few) hosts, and to allow access to
80: these news articles using a server and client model. Subscribers may
81: then request only the articles they wish to see, without having to
82: wastefully duplicate the storage of a copy of each item on each host.
83:
84: 1.4. A Central News Server
85:
86: A way to achieve these economies is to have a central computer system
87: that can provide news service to the other systems on the local area
88: network. Such a server would manage the collection of news articles
89: and index files, with each person who desires to read news bulletins
90: doing so over the LAN. For a large cluster of computer systems, the
91: savings in total disk space is clearly worthwhile. Also, this allows
92: workstations with limited disk storage space to participate in the
93: news without incoming items consuming oppressive amounts of the
94: workstation's disk storage.
95:
96: We have heard rumors of somewhat successful attempts to provide
97: centralized news service using IBIS and other shared or distributed
98: file systems. While it is possible that such a distributed file
99: system implementation might work well with a group of similar
100: computers running nearly identical operating systems, such a scheme
101: is not general enough to offer service to a wide range of client
102: systems, especially when many diverse operating systems may be in use
103: among a group of clients. There are few (if any) shared or networked
104: file systems that can offer the generality of service that stream
105: connections using Internet TCP provide, particularly when a wide
106: range of host hardware and operating systems are considered.
107:
108: NNTP specifies a protocol for the distribution, inquiry, retrieval,
109: and posting of news articles using a reliable stream (such as TCP)
110: server-client model. NNTP is designed so that news articles need only
111:
112:
113: Kantor & Lapsley [Page 2]
114:
115:
116:
117: RFC 977 February 1986
118: Network News Transfer Protocol
119:
120:
121: be stored on one (presumably central) host, and subscribers on other
122: hosts attached to the LAN may read news articles using stream
123: connections to the news host.
124:
125: NNTP is modelled upon the news article specifications in RFC 850,
126: which describes the USENET news system. However, NNTP makes few
127: demands upon the structure, content, or storage of news articles, and
128: thus we believe it easily can be adapted to other non-USENET news
129: systems.
130:
131: Typically, the NNTP server runs as a background process on one host,
132: and would accept connections from other hosts on the LAN. This works
133: well when there are a number of small computer systems (such as
134: workstations, with only one or at most a few users each), and a large
135: central server.
136:
137: 1.5. Intermediate News Servers
138:
139: For clusters of machines with many users (as might be the case in a
140: university or large industrial environment), an intermediate server
141: might be used. This intermediate or "slave" server runs on each
142: computer system, and is responsible for mediating news reading
143: requests and performing local caching of recently-retrieved news
144: articles.
145:
146: Typically, a client attempting to obtain news service would first
147: attempt to connect to the news service port on the local machine. If
148: this attempt were unsuccessful, indicating a failed server, an
149: installation might choose to either deny news access, or to permit
150: connection to the central "master" news server.
151:
152: For workstations or other small systems, direct connection to the
153: master server would probably be the normal manner of operation.
154:
155: This specification does not cover the operation of slave NNTP
156: servers. We merely suggest that slave servers are a logical addition
157: to NNTP server usage which would enhance operation on large local
158: area networks.
159:
160: 1.6. News Distribution
161:
162: NNTP has commands which provide a straightforward method of
163: exchanging articles between cooperating hosts. Hosts which are well
164: connected on a local area or other fast network and who wish to
165: actually obtain copies of news articles for local storage might well
166: find NNTP to be a more efficient way to distribute news than more
167: traditional transfer methods (such as UUCP).
168:
169:
170: Kantor & Lapsley [Page 3]
171:
172:
173:
174: RFC 977 February 1986
175: Network News Transfer Protocol
176:
177:
178: In the traditional method of distributing news articles, news is
179: propagated from host to host by flooding - that is, each host will
180: send all its new news articles on to each host that it feeds. These
181: hosts will then in turn send these new articles on to other hosts
182: that they feed. Clearly, sending articles that a host already has
183: obtained a copy of from another feed (many hosts that receive news
184: are redundantly fed) again is a waste of time and communications
185: resources, but for transport mechanisms that are single-transaction
186: based rather than interactive (such as UUCP in the UNIX-world <1>),
187: distribution time is diminished by sending all articles and having
188: the receiving host simply discard the duplicates. This is an
189: especially true when communications sessions are limited to once a
190: day.
191:
192: Using NNTP, hosts exchanging news articles have an interactive
193: mechanism for deciding which articles are to be transmitted. A host
194: desiring new news, or which has new news to send, will typically
195: contact one or more of its neighbors using NNTP. First it will
196: inquire if any new news groups have been created on the serving host
197: by means of the NEWGROUPS command. If so, and those are appropriate
198: or desired (as established by local site-dependent rules), those new
199: newsgroups can be created.
200:
201: The client host will then inquire as to which new articles have
202: arrived in all or some of the newsgroups that it desires to receive,
203: using the NEWNEWS command. It will receive a list of new articles
204: from the server, and can request transmission of those articles that
205: it desires and does not already have.
206:
207: Finally, the client can advise the server of those new articles which
208: the client has recently received. The server will indicate those
209: articles that it has already obtained copies of, and which articles
210: should be sent to add to its collection.
211:
212: In this manner, only those articles which are not duplicates and
213: which are desired are transferred.
214:
215:
216:
217:
218:
219:
220:
221:
222:
223:
224:
225:
226:
227: Kantor & Lapsley [Page 4]
228:
229:
230:
231: RFC 977 February 1986
232: Network News Transfer Protocol
233:
234:
235: 2. The NNTP Specification
236:
237: 2.1. Overview
238:
239: The news server specified by this document uses a stream connection
240: (such as TCP) and SMTP-like commands and responses. It is designed
241: to accept connections from hosts, and to provide a simple interface
242: to the news database.
243:
244: This server is only an interface between programs and the news
245: databases. It does not perform any user interaction or presentation-
246: level functions. These "user-friendly" functions are better left to
247: the client programs, which have a better understanding of the
248: environment in which they are operating.
249:
250: When used via Internet TCP, the contact port assigned for this
251: service is 119.
252:
253: 2.2. Character Codes
254:
255: Commands and replies are composed of characters from the ASCII
256: character set. When the transport service provides an 8-bit byte
257: (octet) transmission channel, each 7-bit character is transmitted
258: right justified in an octet with the high order bit cleared to zero.
259:
260: 2.3. Commands
261:
262: Commands consist of a command word, which in some cases may be
263: followed by a parameter. Commands with parameters must separate the
264: parameters from each other and from the command by one or more space
265: or tab characters. Command lines must be complete with all required
266: parameters, and may not contain more than one command.
267:
268: Commands and command parameters are not case sensitive. That is, a
269: command or parameter word may be upper case, lower case, or any
270: mixture of upper and lower case.
271:
272: Each command line must be terminated by a CR-LF (Carriage Return -
273: Line Feed) pair.
274:
275: Command lines shall not exceed 512 characters in length, counting all
276: characters including spaces, separators, punctuation, and the
277: trailing CR-LF (thus there are 510 characters maximum allowed for the
278: command and its parameters). There is no provision for continuation
279: command lines.
280:
281:
282:
283:
284: Kantor & Lapsley [Page 5]
285:
286:
287:
288: RFC 977 February 1986
289: Network News Transfer Protocol
290:
291:
292: 2.4. Responses
293:
294: Responses are of two kinds, textual and status.
295:
296: 2.4.1. Text Responses
297:
298: Text is sent only after a numeric status response line has been sent
299: that indicates that text will follow. Text is sent as a series of
300: successive lines of textual matter, each terminated with CR-LF pair.
301: A single line containing only a period (.) is sent to indicate the
302: end of the text (i.e., the server will send a CR-LF pair at the end
303: of the last line of text, a period, and another CR-LF pair).
304:
305: If the text contained a period as the first character of the text
306: line in the original, that first period is doubled. Therefore, the
307: client must examine the first character of each line received, and
308: for those beginning with a period, determine either that this is the
309: end of the text or whether to collapse the doubled period to a single
310: one.
311:
312: The intention is that text messages will usually be displayed on the
313: user's terminal whereas command/status responses will be interpreted
314: by the client program before any possible display is done.
315:
316: 2.4.2. Status Responses
317:
318: These are status reports from the server and indicate the response to
319: the last command received from the client.
320:
321: Status response lines begin with a 3 digit numeric code which is
322: sufficient to distinguish all responses. Some of these may herald
323: the subsequent transmission of text.
324:
325: The first digit of the response broadly indicates the success,
326: failure, or progress of the previous command.
327:
328: 1xx - Informative message
329: 2xx - Command ok
330: 3xx - Command ok so far, send the rest of it.
331: 4xx - Command was correct, but couldn't be performed for
332: some reason.
333: 5xx - Command unimplemented, or incorrect, or a serious
334: program error occurred.
335:
336:
337:
338:
339:
340:
341: Kantor & Lapsley [Page 6]
342:
343:
344:
345: RFC 977 February 1986
346: Network News Transfer Protocol
347:
348:
349: The next digit in the code indicates the function response category.
350:
351: x0x - Connection, setup, and miscellaneous messages
352: x1x - Newsgroup selection
353: x2x - Article selection
354: x3x - Distribution functions
355: x4x - Posting
356: x8x - Nonstandard (private implementation) extensions
357: x9x - Debugging output
358:
359: The exact response codes that should be expected from each command
360: are detailed in the description of that command. In addition, below
361: is listed a general set of response codes that may be received at any
362: time.
363:
364: Certain status responses contain parameters such as numbers and
365: names. The number and type of such parameters is fixed for each
366: response code to simplify interpretation of the response.
367:
368: Parameters are separated from the numeric response code and from each
369: other by a single space. All numeric parameters are decimal, and may
370: have leading zeros. All string parameters begin after the separating
371: space, and end before the following separating space or the CR-LF
372: pair at the end of the line. (String parameters may not, therefore,
373: contain spaces.) All text, if any, in the response which is not a
374: parameter of the response must follow and be separated from the last
375: parameter by a space. Also, note that the text following a response
376: number may vary in different implementations of the server. The
377: 3-digit numeric code should be used to determine what response was
378: sent.
379:
380: Response codes not specified in this standard may be used for any
381: installation-specific additional commands also not specified. These
382: should be chosen to fit the pattern of x8x specified above. (Note
383: that debugging is provided for explicitly in the x9x response codes.)
384: The use of unspecified response codes for standard commands is
385: prohibited.
386:
387: We have provided a response pattern x9x for debugging. Since much
388: debugging output may be classed as "informative messages", we would
389: expect, therefore, that responses 190 through 199 would be used for
390: various debugging outputs. There is no requirement in this
391: specification for debugging output, but if such is provided over the
392: connected stream, it must use these response codes. If appropriate
393: to a specific implementation, other x9x codes may be used for
394: debugging. (An example might be to use e.g., 290 to acknowledge a
395: remote debugging request.)
396:
397:
398: Kantor & Lapsley [Page 7]
399:
400:
401:
402: RFC 977 February 1986
403: Network News Transfer Protocol
404:
405:
406: 2.4.3. General Responses
407:
408: The following is a list of general response codes that may be sent by
409: the NNTP server. These are not specific to any one command, but may
410: be returned as the result of a connection, a failure, or some unusual
411: condition.
412:
413: In general, 1xx codes may be ignored or displayed as desired; code
414: 200 or 201 is sent upon initial connection to the NNTP server
415: depending upon posting permission; code 400 will be sent when the
416: NNTP server discontinues service (by operator request, for example);
417: and 5xx codes indicate that the command could not be performed for
418: some unusual reason.
419:
420: 100 help text
421: 190
422: through
423: 199 debug output
424:
425: 200 server ready - posting allowed
426: 201 server ready - no posting allowed
427:
428: 400 service discontinued
429:
430: 500 command not recognized
431: 501 command syntax error
432: 502 access restriction or permission denied
433: 503 program fault - command not performed
434:
435: 3. Command and Response Details
436:
437: On the following pages are descriptions of each command recognized by
438: the NNTP server and the responses which will be returned by those
439: commands.
440:
441: Each command is shown in upper case for clarity, although case is
442: ignored in the interpretation of commands by the NNTP server. Any
443: parameters are shown in lower case. A parameter shown in [square
444: brackets] is optional. For example, [GMT] indicates that the
445: triglyph GMT may present or omitted.
446:
447: Every command described in this section must be implemented by all
448: NNTP servers.
449:
450:
451:
452:
453:
454:
455: Kantor & Lapsley [Page 8]
456:
457:
458:
459: RFC 977 February 1986
460: Network News Transfer Protocol
461:
462:
463: There is no prohibition against additional commands being added;
464: however, it is recommended that any such unspecified command begin
465: with the letter "X" to avoid conflict with later revisions of this
466: specification.
467:
468: Implementors are reminded that such additional commands may not
469: redefine specified status response codes. Using additional
470: unspecified responses for standard commands is also prohibited.
471:
472: 3.1. The ARTICLE, BODY, HEAD, and STAT commands
473:
474: There are two forms to the ARTICLE command (and the related BODY,
475: HEAD, and STAT commands), each using a different method of specifying
476: which article is to be retrieved. When the ARTICLE command is
477: followed by a message-id in angle brackets ("<" and ">"), the first
478: form of the command is used; when a numeric parameter or no parameter
479: is supplied, the second form is invoked.
480:
481: The text of the article is returned as a textual response, as
482: described earlier in this document.
483:
484: The HEAD and BODY commands are identical to the ARTICLE command
485: except that they respectively return only the header lines or text
486: body of the article.
487:
488: The STAT command is similar to the ARTICLE command except that no
489: text is returned. When selecting by message number within a group,
490: the STAT command serves to set the current article pointer without
491: sending text. The returned acknowledgement response will contain the
492: message-id, which may be of some value. Using the STAT command to
493: select by message-id is valid but of questionable value, since a
494: selection by message-id does NOT alter the "current article pointer".
495:
496: 3.1.1. ARTICLE (selection by message-id)
497:
498: ARTICLE <message-id>
499:
500: Display the header, a blank line, then the body (text) of the
501: specified article. Message-id is the message id of an article as
502: shown in that article's header. It is anticipated that the client
503: will obtain the message-id from a list provided by the NEWNEWS
504: command, from references contained within another article, or from
505: the message-id provided in the response to some other commands.
506:
507: Please note that the internally-maintained "current article pointer"
508: is NOT ALTERED by this command. This is both to facilitate the
509: presentation of articles that may be referenced within an article
510:
511:
512: Kantor & Lapsley [Page 9]
513:
514:
515:
516: RFC 977 February 1986
517: Network News Transfer Protocol
518:
519:
520: being read, and because of the semantic difficulties of determining
521: the proper sequence and membership of an article which may have been
522: posted to more than one newsgroup.
523:
524: 3.1.2. ARTICLE (selection by number)
525:
526: ARTICLE [nnn]
527:
528: Displays the header, a blank line, then the body (text) of the
529: current or specified article. The optional parameter nnn is the
530:
531: numeric id of an article in the current newsgroup and must be chosen
532: from the range of articles provided when the newsgroup was selected.
533: If it is omitted, the current article is assumed.
534:
535: The internally-maintained "current article pointer" is set by this
536: command if a valid article number is specified.
537:
538: [the following applies to both forms of the article command.] A
539: response indicating the current article number, a message-id string,
540: and that text is to follow will be returned.
541:
542: The message-id string returned is an identification string contained
543: within angle brackets ("<" and ">"), which is derived from the header
544: of the article itself. The Message-ID header line (required by
545: RFC850) from the article must be used to supply this information. If
546: the message-id header line is missing from the article, a single
547: digit "0" (zero) should be supplied within the angle brackets.
548:
549: Since the message-id field is unique with each article, it may be
550: used by a news reading program to skip duplicate displays of articles
551: that have been posted more than once, or to more than one newsgroup.
552:
553: 3.1.3. Responses
554:
555: 220 n <a> article retrieved - head and body follow
556: (n = article number, <a> = message-id)
557: 221 n <a> article retrieved - head follows
558: 222 n <a> article retrieved - body follows
559: 223 n <a> article retrieved - request text separately
560: 412 no newsgroup has been selected
561: 420 no current article has been selected
562: 423 no such article number in this group
563: 430 no such article found
564:
565:
566:
567:
568:
569: Kantor & Lapsley [Page 10]
570:
571:
572:
573: RFC 977 February 1986
574: Network News Transfer Protocol
575:
576:
577: 3.2. The GROUP command
578:
579: 3.2.1. GROUP
580:
581: GROUP ggg
582:
583: The required parameter ggg is the name of the newsgroup to be
584: selected (e.g. "net.news"). A list of valid newsgroups may be
585: obtained from the LIST command.
586:
587: The successful selection response will return the article numbers of
588: the first and last articles in the group, and an estimate of the
589: number of articles on file in the group. It is not necessary that
590: the estimate be correct, although that is helpful; it must only be
591: equal to or larger than the actual number of articles on file. (Some
592: implementations will actually count the number of articles on file.
593: Others will just subtract first article number from last to get an
594: estimate.)
595:
596: When a valid group is selected by means of this command, the
597: internally maintained "current article pointer" is set to the first
598: article in the group. If an invalid group is specified, the
599: previously selected group and article remain selected. If an empty
600: newsgroup is selected, the "current article pointer" is in an
601: indeterminate state and should not be used.
602:
603: Note that the name of the newsgroup is not case-dependent. It must
604: otherwise match a newsgroup obtained from the LIST command or an
605: error will result.
606:
607: 3.2.2. Responses
608:
609: 211 n f l s group selected
610: (n = estimated number of articles in group,
611: f = first article number in the group,
612: l = last article number in the group,
613: s = name of the group.)
614: 411 no such news group
615:
616:
617:
618:
619:
620:
621:
622:
623:
624:
625:
626: Kantor & Lapsley [Page 11]
627:
628:
629:
630: RFC 977 February 1986
631: Network News Transfer Protocol
632:
633:
634: 3.3. The HELP command
635:
636: 3.3.1. HELP
637:
638: HELP
639:
640: Provides a short summary of commands that are understood by this
641: implementation of the server. The help text will be presented as a
642: textual response, terminated by a single period on a line by itself.
643:
644: 3.3.2. Responses
645:
646: 100 help text follows
647:
648: 3.4. The IHAVE command
649:
650: 3.4.1. IHAVE
651:
652: IHAVE <messageid>
653:
654: The IHAVE command informs the server that the client has an article
655: whose id is <messageid>. If the server desires a copy of that
656: article, it will return a response instructing the client to send the
657: entire article. If the server does not want the article (if, for
658: example, the server already has a copy of it), a response indicating
659: that the article is not wanted will be returned.
660:
661: If transmission of the article is requested, the client should send
662: the entire article, including header and body, in the manner
663: specified for text transmission from the server. A response code
664: indicating success or failure of the transferral of the article will
665: be returned.
666:
667: This function differs from the POST command in that it is intended
668: for use in transferring already-posted articles between hosts.
669: Normally it will not be used when the client is a personal
670: newsreading program. In particular, this function will invoke the
671: server's news posting program with the appropriate settings (flags,
672: options, etc) to indicate that the forthcoming article is being
673: forwarded from another host.
674:
675: The server may, however, elect not to post or forward the article if
676: after further examination of the article it deems it inappropriate to
677: do so. The 436 or 437 error codes may be returned as appropriate to
678: the situation.
679:
680: Reasons for such subsequent rejection of an article may include such
681:
682:
683: Kantor & Lapsley [Page 12]
684:
685:
686:
687: RFC 977 February 1986
688: Network News Transfer Protocol
689:
690:
691: problems as inappropriate newsgroups or distributions, disk space
692: limitations, article lengths, garbled headers, and the like. These
693: are typically restrictions enforced by the server host's news
694: software and not necessarily the NNTP server itself.
695:
696: 3.4.2. Responses
697:
698: 235 article transferred ok
699: 335 send article to be transferred. End with <CR-LF>.<CR-LF>
700: 435 article not wanted - do not send it
701: 436 transfer failed - try again later
702: 437 article rejected - do not try again
703:
704: An implementation note:
705:
706: Because some host news posting software may not be able to decide
707: immediately that an article is inappropriate for posting or
708: forwarding, it is acceptable to acknowledge the successful transfer
709: of the article and to later silently discard it. Thus it is
710: permitted to return the 235 acknowledgement code and later discard
711: the received article. This is not a fully satisfactory solution to
712: the problem. Perhaps some implementations will wish to send mail to
713: the author of the article in certain of these cases.
714:
715: 3.5. The LAST command
716:
717: 3.5.1. LAST
718:
719: LAST
720:
721: The internally maintained "current article pointer" is set to the
722: previous article in the current newsgroup. If already positioned at
723: the first article of the newsgroup, an error message is returned and
724: the current article remains selected.
725:
726: The internally-maintained "current article pointer" is set by this
727: command.
728:
729: A response indicating the current article number, and a message-id
730: string will be returned. No text is sent in response to this
731: command.
732:
733: 3.5.2. Responses
734:
735: 223 n a article retrieved - request text separately
736: (n = article number, a = unique article id)
737:
738:
739:
740: Kantor & Lapsley [Page 13]
741:
742:
743:
744: RFC 977 February 1986
745: Network News Transfer Protocol
746:
747:
748: 412 no newsgroup selected
749: 420 no current article has been selected
750: 422 no previous article in this group
751:
752: 3.6. The LIST command
753:
754: 3.6.1. LIST
755:
756: LIST
757:
758: Returns a list of valid newsgroups and associated information. Each
759: newsgroup is sent as a line of text in the following format:
760:
761: group last first p
762:
763: where <group> is the name of the newsgroup, <last> is the number of
764: the last known article currently in that newsgroup, <first> is the
765: number of the first article currently in the newsgroup, and <p> is
766: either 'y' or 'n' indicating whether posting to this newsgroup is
767: allowed ('y') or prohibited ('n').
768:
769: The <first> and <last> fields will always be numeric. They may have
770: leading zeros. If the <last> field evaluates to less than the
771: <first> field, there are no articles currently on file in the
772: newsgroup.
773:
774: Note that posting may still be prohibited to a client even though the
775: LIST command indicates that posting is permitted to a particular
776: newsgroup. See the POST command for an explanation of client
777: prohibitions. The posting flag exists for each newsgroup because
778: some newsgroups are moderated or are digests, and therefore cannot be
779: posted to; that is, articles posted to them must be mailed to a
780: moderator who will post them for the submitter. This is independent
781: of the posting permission granted to a client by the NNTP server.
782:
783: Please note that an empty list (i.e., the text body returned by this
784: command consists only of the terminating period) is a possible valid
785: response, and indicates that there are currently no valid newsgroups.
786:
787: 3.6.2. Responses
788:
789: 215 list of newsgroups follows
790:
791:
792:
793:
794:
795:
796:
797: Kantor & Lapsley [Page 14]
798:
799:
800:
801: RFC 977 February 1986
802: Network News Transfer Protocol
803:
804:
805: 3.7. The NEWGROUPS command
806:
807: 3.7.1. NEWGROUPS
808:
809: NEWGROUPS date time [GMT] [<distributions>]
810:
811: A list of newsgroups created since <date and time> will be listed in
812: the same format as the LIST command.
813:
814: The date is sent as 6 digits in the format YYMMDD, where YY is the
815: last two digits of the year, MM is the two digits of the month (with
816: leading zero, if appropriate), and DD is the day of the month (with
817: leading zero, if appropriate). The closest century is assumed as
818: part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
819: 1999, 00 is 2000).
820:
821: Time must also be specified. It must be as 6 digits HHMMSS with HH
822: being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
823: 00-59. The time is assumed to be in the server's timezone unless the
824: token "GMT" appears, in which case both time and date are evaluated
825: at the 0 meridian.
826:
827: The optional parameter "distributions" is a list of distribution
828: groups, enclosed in angle brackets. If specified, the distribution
829: portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
830: examined for a match with the distribution categories listed, and
831: only those new newsgroups which match will be listed. If more than
832: one distribution group is to be listed, they must be separated by
833: commas within the angle brackets.
834:
835: Please note that an empty list (i.e., the text body returned by this
836: command consists only of the terminating period) is a possible valid
837: response, and indicates that there are currently no new newsgroups.
838:
839: 3.7.2. Responses
840:
841: 231 list of new newsgroups follows
842:
843:
844:
845:
846:
847:
848:
849:
850:
851:
852:
853:
854: Kantor & Lapsley [Page 15]
855:
856:
857:
858: RFC 977 February 1986
859: Network News Transfer Protocol
860:
861:
862: 3.8. The NEWNEWS command
863:
864: 3.8.1. NEWNEWS
865:
866: NEWNEWS newsgroups date time [GMT] [<distribution>]
867:
868: A list of message-ids of articles posted or received to the specified
869: newsgroup since "date" will be listed. The format of the listing will
870: be one message-id per line, as though text were being sent. A single
871: line consisting solely of one period followed by CR-LF will terminate
872: the list.
873:
874: Date and time are in the same format as the NEWGROUPS command.
875:
876: A newsgroup name containing a "*" (an asterisk) may be specified to
877: broaden the article search to some or all newsgroups. The asterisk
878: will be extended to match any part of a newsgroup name (e.g.,
879: net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
880: if only an asterisk is given as the newsgroup name, all newsgroups
881: will be searched for new news.
882:
883: (Please note that the asterisk "*" expansion is a general
884: replacement; in particular, the specification of e.g., net.*.unix
885: should be correctly expanded to embrace names such as net.wombat.unix
886: and net.whocares.unix.)
887:
888: Conversely, if no asterisk appears in a given newsgroup name, only
889: the specified newsgroup will be searched for new articles. Newsgroup
890: names must be chosen from those returned in the listing of available
891: groups. Multiple newsgroup names (including a "*") may be specified
892: in this command, separated by a comma. No comma shall appear after
893: the last newsgroup in the list. [Implementors are cautioned to keep
894: the 512 character command length limit in mind.]
895:
896: The exclamation point ("!") may be used to negate a match. This can
897: be used to selectively omit certain newsgroups from an otherwise
898: larger list. For example, a newsgroups specification of
899: "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
900: all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
901: matched. If used, the exclamation point must appear as the first
902: character of the given newsgroup name or pattern.
903:
904: The optional parameter "distributions" is a list of distribution
905: groups, enclosed in angle brackets. If specified, the distribution
906: portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
907: be examined for a match with the distribution categories listed, and
908: only those articles which have at least one newsgroup belonging to
909:
910:
911: Kantor & Lapsley [Page 16]
912:
913:
914:
915: RFC 977 February 1986
916: Network News Transfer Protocol
917:
918:
919: the list of distributions will be listed. If more than one
920: distribution group is to be supplied, they must be separated by
921: commas within the angle brackets.
922:
923: The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
924: news is discussed in an earlier part of this document.
925:
926: Please note that an empty list (i.e., the text body returned by this
927: command consists only of the terminating period) is a possible valid
928: response, and indicates that there is currently no new news.
929:
930: 3.8.2. Responses
931:
932: 230 list of new articles by message-id follows
933:
934: 3.9. The NEXT command
935:
936: 3.9.1. NEXT
937:
938: NEXT
939:
940: The internally maintained "current article pointer" is advanced to
941: the next article in the current newsgroup. If no more articles
942: remain in the current group, an error message is returned and the
943: current article remains selected.
944:
945: The internally-maintained "current article pointer" is set by this
946: command.
947:
948: A response indicating the current article number, and the message-id
949: string will be returned. No text is sent in response to this
950: command.
951:
952: 3.9.2. Responses
953:
954: 223 n a article retrieved - request text separately
955: (n = article number, a = unique article id)
956: 412 no newsgroup selected
957: 420 no current article has been selected
958: 421 no next article in this group
959:
960:
961:
962:
963:
964:
965:
966:
967:
968: Kantor & Lapsley [Page 17]
969:
970:
971:
972: RFC 977 February 1986
973: Network News Transfer Protocol
974:
975:
976: 3.10. The POST command
977:
978: 3.10.1. POST
979:
980: POST
981:
982: If posting is allowed, response code 340 is returned to indicate that
983: the article to be posted should be sent. Response code 440 indicates
984: that posting is prohibited for some installation-dependent reason.
985:
986: If posting is permitted, the article should be presented in the
987: format specified by RFC850, and should include all required header
988: lines. After the article's header and body have been completely sent
989: by the client to the server, a further response code will be returned
990: to indicate success or failure of the posting attempt.
991:
992: The text forming the header and body of the message to be posted
993: should be sent by the client using the conventions for text received
994: from the news server: A single period (".") on a line indicates the
995: end of the text, with lines starting with a period in the original
996: text having that period doubled during transmission.
997:
998: No attempt shall be made by the server to filter characters, fold or
999: limit lines, or otherwise process incoming text. It is our intent
1000: that the server just pass the incoming message to be posted to the
1001: server installation's news posting software, which is separate from
1002: this specification. See RFC850 for more details.
1003:
1004: Since most installations will want the client news program to allow
1005: the user to prepare his message using some sort of text editor, and
1006: transmit it to the server for posting only after it is composed, the
1007: client program should take note of the herald message that greeted it
1008: when the connection was first established. This message indicates
1009: whether postings from that client are permitted or not, and can be
1010: used to caution the user that his access is read-only if that is the
1011: case. This will prevent the user from wasting a good deal of time
1012: composing a message only to find posting of the message was denied.
1013: The method and determination of which clients and hosts may post is
1014: installation dependent and is not covered by this specification.
1015:
1016: 3.10.2. Responses
1017:
1018: 240 article posted ok
1019: 340 send article to be posted. End with <CR-LF>.<CR-LF>
1020: 440 posting not allowed
1021: 441 posting failed
1022:
1023:
1024:
1025: Kantor & Lapsley [Page 18]
1026:
1027:
1028:
1029: RFC 977 February 1986
1030: Network News Transfer Protocol
1031:
1032:
1033: (for reference, one of the following codes will be sent upon initial
1034: connection; the client program should determine whether posting is
1035: generally permitted from these:) 200 server ready - posting allowed
1036: 201 server ready - no posting allowed
1037:
1038: 3.11. The QUIT command
1039:
1040: 3.11.1. QUIT
1041:
1042: QUIT
1043:
1044: The server process acknowledges the QUIT command and then closes the
1045: connection to the client. This is the preferred method for a client
1046: to indicate that it has finished all its transactions with the NNTP
1047: server.
1048:
1049: If a client simply disconnects (or the connection times out, or some
1050: other fault occurs), the server should gracefully cease its attempts
1051: to service the client.
1052:
1053: 3.11.2. Responses
1054:
1055: 205 closing connection - goodbye!
1056:
1057: 3.12. The SLAVE command
1058:
1059: 3.12.1. SLAVE
1060:
1061: SLAVE
1062:
1063: Indicates to the server that this client connection is to a slave
1064: server, rather than a user.
1065:
1066: This command is intended for use in separating connections to single
1067: users from those to subsidiary ("slave") servers. It may be used to
1068: indicate that priority should therefore be given to requests from
1069: this client, as it is presumably serving more than one person. It
1070: might also be used to determine which connections to close when
1071: system load levels are exceeded, perhaps giving preference to slave
1072: servers. The actual use this command is put to is entirely
1073: implementation dependent, and may vary from one host to another. In
1074: NNTP servers which do not give priority to slave servers, this
1075: command must nonetheless be recognized and acknowledged.
1076:
1077: 3.12.2. Responses
1078:
1079: 202 slave status noted
1080:
1081:
1082: Kantor & Lapsley [Page 19]
1083:
1084:
1085:
1086: RFC 977 February 1986
1087: Network News Transfer Protocol
1088:
1089:
1090: 4. Sample Conversations
1091:
1092: These are samples of the conversations that might be expected with
1093: the news server in hypothetical sessions. The notation C: indicates
1094: commands sent to the news server from the client program; S: indicate
1095: responses received from the server by the client.
1096:
1097: 4.1. Example 1 - relative access with NEXT
1098:
1099: S: (listens at TCP port 119)
1100:
1101: C: (requests connection on TCP port 119)
1102: S: 200 wombatvax news server ready - posting ok
1103:
1104: (client asks for a current newsgroup list)
1105: C: LIST
1106: S: 215 list of newsgroups follows
1107: S: net.wombats 00543 00501 y
1108: S: net.unix-wizards 10125 10011 y
1109: (more information here)
1110: S: net.idiots 00100 00001 n
1111: S: .
1112:
1113: (client selects a newsgroup)
1114: C: GROUP net.unix-wizards
1115: S: 211 104 10011 10125 net.unix-wizards group selected
1116: (there are 104 articles on file, from 10011 to 10125)
1117:
1118: (client selects an article to read)
1119: C: STAT 10110
1120: S: 223 10110 <[email protected]> article retrieved - statistics
1121: only (article 10110 selected, its message-id is
1122: <[email protected]>)
1123:
1124: (client examines the header)
1125: C: HEAD
1126: S: 221 10110 <[email protected]> article retrieved - head
1127: follows (text of the header appears here)
1128: S: .
1129:
1130: (client wants to see the text body of the article)
1131: C: BODY
1132: S: 222 10110 <[email protected]> article retrieved - body
1133: follows (body text here)
1134: S: .
1135:
1136: (client selects next article in group)
1137:
1138:
1139: Kantor & Lapsley [Page 20]
1140:
1141:
1142:
1143: RFC 977 February 1986
1144: Network News Transfer Protocol
1145:
1146:
1147: C: NEXT
1148: S: 223 10113 <[email protected]> article retrieved - statistics
1149: only (article 10113 was next in group)
1150:
1151: (client finishes session)
1152: C: QUIT
1153: S: 205 goodbye.
1154:
1155: 4.2. Example 2 - absolute article access with ARTICLE
1156:
1157: S: (listens at TCP port 119)
1158:
1159: C: (requests connection on TCP port 119)
1160: S: 201 UCB-VAX netnews server ready -- no posting allowed
1161:
1162: C: GROUP msgs
1163: S: 211 103 402 504 msgs Your new group is msgs
1164: (there are 103 articles, from 402 to 504)
1165:
1166: C: ARTICLE 401
1167: S: 423 No such article in this newsgroup
1168:
1169: C: ARTICLE 402
1170: S: 220 402 <[email protected]> Article retrieved, text follows
1171: S: (article header and body follow)
1172: S: .
1173:
1174: C: HEAD 403
1175: S: 221 403 <[email protected]> Article retrieved, header follows
1176: S: (article header follows)
1177: S: .
1178:
1179: C: QUIT
1180: S: 205 UCB-VAX news server closing connection. Goodbye.
1181:
1182: 4.3. Example 3 - NEWGROUPS command
1183:
1184: S: (listens at TCP port 119)
1185:
1186: C: (requests connection on TCP port 119)
1187: S: 200 Imaginary Institute News Server ready (posting ok)
1188:
1189: (client asks for new newsgroups since April 3, 1985)
1190: C: NEWGROUPS 850403 020000
1191:
1192: S: 231 New newsgroups since 03/04/85 02:00:00 follow
1193:
1194:
1195:
1196: Kantor & Lapsley [Page 21]
1197:
1198:
1199:
1200: RFC 977 February 1986
1201: Network News Transfer Protocol
1202:
1203:
1204: S: net.music.gdead
1205: S: net.games.sources
1206: S: .
1207:
1208: C: GROUP net.music.gdead
1209: S: 211 0 1 1 net.music.gdead Newsgroup selected
1210: (there are no articles in that newsgroup, and
1211: the first and last article numbers should be ignored)
1212:
1213: C: QUIT
1214: S: 205 Imaginary Institute news server ceasing service. Bye!
1215:
1216: 4.4. Example 4 - posting a news article
1217:
1218: S: (listens at TCP port 119)
1219:
1220: C: (requests connection on TCP port 119)
1221: S: 200 BANZAIVAX news server ready, posting allowed.
1222:
1223: C: POST
1224: S: 340 Continue posting; Period on a line by itself to end
1225: C: (transmits news article in RFC850 format)
1226: C: .
1227: S: 240 Article posted successfully.
1228:
1229: C: QUIT
1230: S: 205 BANZAIVAX closing connection. Goodbye.
1231:
1232: 4.5. Example 5 - interruption due to operator request
1233:
1234: S: (listens at TCP port 119)
1235:
1236: C: (requests connection on TCP port 119)
1237: S: 201 genericvax news server ready, no posting allowed.
1238:
1239: (assume normal conversation for some time, and
1240: that a newsgroup has been selected)
1241:
1242: C: NEXT
1243: S: 223 1013 <[email protected]> Article retrieved; text separate.
1244:
1245: C: HEAD
1246: C: 221 1013 <[email protected]> Article retrieved; head follows.
1247:
1248: S: (sends head of article, but halfway through is
1249: interrupted by an operator request. The following
1250: then occurs, without client intervention.)
1251:
1252:
1253: Kantor & Lapsley [Page 22]
1254:
1255:
1256:
1257: RFC 977 February 1986
1258: Network News Transfer Protocol
1259:
1260:
1261: S: (ends current line with a CR-LF pair)
1262: S: .
1263: S: 400 Connection closed by operator. Goodbye.
1264: S: (closes connection)
1265:
1266: 4.6. Example 6 - Using the news server to distribute news between
1267: systems.
1268:
1269: S: (listens at TCP port 119)
1270:
1271: C: (requests connection on TCP port 119)
1272: S: 201 Foobar NNTP server ready (no posting)
1273:
1274: (client asks for new newsgroups since 2 am, May 15, 1985)
1275: C: NEWGROUPS 850515 020000
1276: S: 235 New newsgroups since 850515 follow
1277: S: net.fluff
1278: S: net.lint
1279: S: .
1280:
1281: (client asks for new news articles since 2 am, May 15, 1985)
1282: C: NEWNEWS * 850515 020000
1283: S: 230 New news since 850515 020000 follows
1284: S: <[email protected]>
1285: S: <[email protected]>
1286: S: <[email protected]>
1287: S: .
1288:
1289: (client asks for article <[email protected]>)
1290: C: ARTICLE <[email protected]>
1291: S: 220 <[email protected]> All of article follows
1292: S: (sends entire message)
1293: S: .
1294:
1295: (client asks for article <[email protected]>
1296: C: ARTICLE <[email protected]>
1297: S: 220 <[email protected]> All of article follows
1298: S: (sends entire message)
1299: S: .
1300:
1301: (client asks for article <[email protected]>
1302: C: ARTICLE <[email protected]>
1303: S: 220 <[email protected]> All of article follows
1304: S: (sends entire message)
1305: S: .
1306:
1307:
1308:
1309:
1310: Kantor & Lapsley [Page 23]
1311:
1312:
1313:
1314: RFC 977 February 1986
1315: Network News Transfer Protocol
1316:
1317:
1318: (client offers an article it has received recently)
1319: C: IHAVE <[email protected]>
1320: S: 435 Already seen that one, where you been?
1321:
1322: (client offers another article)
1323: C: IHAVE <[email protected]>
1324: S: 335 News to me! <CRLF.CRLF> to end.
1325: C: (sends article)
1326: C: .
1327: S: 235 Article transferred successfully. Thanks.
1328:
1329: (or)
1330:
1331: S: 436 Transfer failed.
1332:
1333: (client is all through with the session)
1334: C: QUIT
1335: S: 205 Foobar NNTP server bids you farewell.
1336:
1337: 4.7. Summary of commands and responses.
1338:
1339: The following are the commands recognized and responses returned by
1340: the NNTP server.
1341:
1342: 4.7.1. Commands
1343:
1344: ARTICLE
1345: BODY
1346: GROUP
1347: HEAD
1348: HELP
1349: IHAVE
1350: LAST
1351: LIST
1352: NEWGROUPS
1353: NEWNEWS
1354: NEXT
1355: POST
1356: QUIT
1357: SLAVE
1358: STAT
1359:
1360: 4.7.2. Responses
1361:
1362: 100 help text follows
1363: 199 debug output
1364:
1365:
1366:
1367: Kantor & Lapsley [Page 24]
1368:
1369:
1370:
1371: RFC 977 February 1986
1372: Network News Transfer Protocol
1373:
1374:
1375: 200 server ready - posting allowed
1376: 201 server ready - no posting allowed
1377: 202 slave status noted
1378: 205 closing connection - goodbye!
1379: 211 n f l s group selected
1380: 215 list of newsgroups follows
1381: 220 n <a> article retrieved - head and body follow 221 n <a> article
1382: retrieved - head follows
1383: 222 n <a> article retrieved - body follows
1384: 223 n <a> article retrieved - request text separately 230 list of new
1385: articles by message-id follows
1386: 231 list of new newsgroups follows
1387: 235 article transferred ok
1388: 240 article posted ok
1389:
1390: 335 send article to be transferred. End with <CR-LF>.<CR-LF>
1391: 340 send article to be posted. End with <CR-LF>.<CR-LF>
1392:
1393: 400 service discontinued
1394: 411 no such news group
1395: 412 no newsgroup has been selected
1396: 420 no current article has been selected
1397: 421 no next article in this group
1398: 422 no previous article in this group
1399: 423 no such article number in this group
1400: 430 no such article found
1401: 435 article not wanted - do not send it
1402: 436 transfer failed - try again later
1403: 437 article rejected - do not try again.
1404: 440 posting not allowed
1405: 441 posting failed
1406:
1407: 500 command not recognized
1408: 501 command syntax error
1409: 502 access restriction or permission denied
1410: 503 program fault - command not performed
1411:
1412: 4.8. A Brief Word about the USENET News System
1413:
1414: In the UNIX world, which traditionally has been linked by 1200 baud
1415: dial-up telephone lines, the USENET News system has evolved to handle
1416: central storage, indexing, retrieval, and distribution of news. With
1417: the exception of its underlying transport mechanism (UUCP), USENET
1418: News is an efficient means of providing news and bulletin service to
1419: subscribers on UNIX and other hosts worldwide. The USENET News
1420:
1421:
1422:
1423:
1424: Kantor & Lapsley [Page 25]
1425:
1426:
1427:
1428: RFC 977 February 1986
1429: Network News Transfer Protocol
1430:
1431:
1432: system is discussed in detail in RFC 850. It runs on most versions
1433: of UNIX and on many other operating systems, and is customarily
1434: distributed without charge.
1435:
1436: USENET uses a spooling area on the UNIX host to store news articles,
1437: one per file. Each article consists of a series of heading text,
1438: which contain the sender's identification and organizational
1439: affiliation, timestamps, electronic mail reply paths, subject,
1440: newsgroup (subject category), and the like. A complete news article
1441: is reproduced in its entirety below. Please consult RFC 850 for more
1442: details.
1443:
1444: Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
1445: sdcsvax.UUCP
1446: Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
1447: Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
1448: !honman
1449: From: [email protected] (Man Wong)
1450: Newsgroups: net.unix-wizards
1451: Subject: foreground -> background ?
1452: Message-ID: <[email protected]>
1453: Date: 25 Sep 85 23:51:52 GMT
1454: Date-Received: 29 Sep 85 09:54:48 GMT
1455: Reply-To: [email protected] (Hon-Man Wong)
1456: Distribution: net.all
1457: Organization: Unitek Technologies Corporation
1458: Lines: 12
1459:
1460: I have a process (C program) which generates a child and waits for
1461: it to return. What I would like to do is to be able to run the
1462: child process interactively for a while before kicking itself into
1463: the background so I can return to the parent process (while the
1464: child process is RUNNING in the background). Can it be done? And
1465: if it can, how?
1466:
1467: Please reply by E-mail. Thanks in advance.
1468:
1469: Hon-Man Wong
1470:
1471:
1472:
1473:
1474:
1475:
1476:
1477:
1478:
1479:
1480:
1481: Kantor & Lapsley [Page 26]
1482:
1483:
1484:
1485: RFC 977 February 1986
1486: Network News Transfer Protocol
1487:
1488:
1489: 5. References
1490:
1491: [1] Crocker, D., "Standard for the Format of ARPA Internet Text
1492: Messages", RFC-822, Department of Electrical Engineering,
1493: University of Delaware, August, 1982.
1494:
1495: [2] Horton, M., "Standard for Interchange of USENET Messages",
1496: RFC-850, USENET Project, June, 1983.
1497:
1498: [3] Postel, J., "Transmission Control Protocol- DARPA Internet
1499: Program Protocol Specification", RFC-793, USC/Information
1500: Sciences Institute, September, 1981.
1501:
1502: [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
1503: USC/Information Sciences Institute, August, 1982.
1504:
1505: 6. Acknowledgements
1506:
1507: The authors wish to express their heartfelt thanks to those many
1508: people who contributed to this specification, and especially to Erik
1509: Fair and Chuq von Rospach, without whose inspiration this whole thing
1510: would not have been necessary.
1511:
1512: 7. Notes
1513:
1514: <1> UNIX is a trademark of Bell Laboratories.
1515:
1516:
1517:
1518:
1519:
1520:
1521:
1522:
1523:
1524:
1525:
1526:
1527:
1528:
1529:
1530:
1531:
1532:
1533:
1534:
1535:
1536:
1537:
1538: Kantor & Lapsley [Page 27]
1539:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.