2009-11-25 [colin] 3.7.3cvs21
[claws.git] / doc / src / rfc977.txt
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 <23445@sdcsvax.ARPA> article retrieved - statistics
1121            only (article 10110 selected, its message-id is
1122            <23445@sdcsvax.ARPA>)
1123
1124    (client examines the header)
1125    C:      HEAD
1126    S:      221 10110 <23445@sdcsvax.ARPA> 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 <23445@sdcsvax.ARPA> 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 \f
1141
1142
1143 RFC 977                                                    February 1986
1144 Network News Transfer Protocol
1145
1146
1147    C:      NEXT
1148    S:      223 10113 <21495@nudebch.uucp> 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 <4105@ucbvax.ARPA> Article retrieved, text follows
1171    S:      (article header and body follow)
1172    S:      .
1173
1174    C:      HEAD 403
1175    S:      221 403 <3108@mcvax.UUCP> 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 \f
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 <5734@mcvax.UUCP> Article retrieved; text separate.
1244
1245    C:      HEAD
1246    C:      221 1013 <5734@mcvax.UUCP> 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 \f
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:      <1772@foo.UUCP>
1285    S:      <87623@baz.UUCP>
1286    S:      <17872@GOLD.CSNET>
1287    S:      .
1288
1289    (client asks for article <1772@foo.UUCP>)
1290    C:      ARTICLE <1772@foo.UUCP>
1291    S:      220 <1772@foo.UUCP> All of article follows
1292    S:      (sends entire message)
1293    S:      .
1294
1295    (client asks for article <87623@baz.UUCP>
1296    C:      ARTICLE <87623@baz.UUCP>
1297    S:      220 <87623@baz.UUCP> All of article follows
1298    S:      (sends entire message)
1299    S:      .
1300
1301    (client asks for article <17872@GOLD.CSNET>
1302    C:      ARTICLE <17872@GOLD.CSNET>
1303    S:      220 <17872@GOLD.CSNET> All of article follows
1304    S:      (sends entire message)
1305    S:      .
1306
1307
1308
1309
1310 Kantor & Lapsley                                               [Page 23]
1311 \f
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 <4105@ucbvax.ARPA>
1320    S:      435 Already seen that one, where you been?
1321
1322    (client offers another article)
1323    C:      IHAVE <4106@ucbvax.ARPA>
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 \f
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 \f
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: honman@unitek.uucp (Man Wong)
1450       Newsgroups: net.unix-wizards
1451       Subject: foreground -> background ?
1452       Message-ID: <167@unitek.uucp>
1453       Date: 25 Sep 85 23:51:52 GMT
1454       Date-Received: 29 Sep 85 09:54:48 GMT
1455       Reply-To: honman@unitek.UUCP (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 \f
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 \f