 
  
 I Network Working Group                      Brian Kantor (U.C. San Diego)
 I Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)
 I                                                            February 1986
  
 4                      Network News Transfer Protocol
%                                     
 9                 A Proposed Standard for the Stream-Based
 /                           Transmission of News
  
  Status of This Memo
 
 G    NNTP specifies a protocol for the distribution, inquiry, retrieval,
 >    and posting of news articles using a reliable stream-based
D    transmission of news among the ARPA-Internet community.  NNTP is
C    designed so that news articles are stored in a central database
 G    allowing a subscriber to select only those items he wishes to read.
 I    Indexing, cross-referencing, and expiration of aged messages are also
 I    provided. This RFC suggests a proposed protocol for the ARPA-Internet
 H    community, and requests discussion and suggestions for improvements.
+    Distribution of this memo is unlimited.
  
  1.  Introduction
  
 A    For many years, the ARPA-Internet community has supported the
 H    distribution of bulletins, information, and data in a timely fashion
I    to thousands of participants.  We collectively refer to such items of
 <    information as "news".  Such news provides for the rapid
F    dissemination of items of interest such as software bug fixes, new
I    product reviews, technical tips, and programming pointers, as well as
 H    rapid-fire discussions of matters of concern to the working computer
9    professional. News is very popular among its readers.
  
 B    There are popularly two methods of distributing such news: the
B    Internet method of direct mailing, and the USENET news system.
 
  1.1.  Internet Mailing Lists
  
 H    The Internet community distributes news by the use of mailing lists.
C    These are lists of subscriber's mailbox addresses and remailing
 H    sublists of all intended recipients.  These mailing lists operate by
A    remailing a copy of the information to be distributed to each
 I    subscriber on the mailing list.  Such remailing is inefficient when a
 C    mailing list grows beyond a dozen or so people, since sending a
 I    separate copy to each of the subscribers occupies large quantities of
 E    network bandwidth, CPU resources, and significant amounts of disk
 I    storage at the destination host.  There is also a significant problem
 G    in maintenance of the list itself: as subscribers move from one job
 H    to another; as new subscribers join and old ones leave; and as hosts
    come in and out of service.
  
  
  
  
 I Kantor & Lapsley                                                [Page 1]
  
 
  
 I RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  1.2.  The USENET News System
  
 I    Clearly, a worthwhile reduction of the amount of these resources used
 G    can be achieved if articles are stored in a central database on the
 F    receiving host instead of in each subscriber's mailbox. The USENET
I    news system provides a method of doing just this.  There is a central
 E    repository of the news articles in one place (customarily a spool
 ?    directory of some sort), and a set of programs that allow a
 B    subscriber to select those items he wishes to read.  Indexing,
I    cross-referencing, and expiration of aged messages are also provided.
  
  1.3.  Central Storage of News
 
 H    For clusters of hosts connected together by fast local area networks
D    (such as Ethernet), it makes even more sense to consolidate news
G    distribution onto one (or a very few) hosts, and to allow access to
 I    these news articles using a server and client model.  Subscribers may
 F    then request only the articles they wish to see, without having to
I    wastefully duplicate the storage of a copy of each item on each host.
  
  1.4.  A Central News Server
 
 I    A way to achieve these economies is to have a central computer system
 H    that can provide news service to the other systems on the local area
H    network.  Such a server would manage the collection of news articles
H    and index files, with each person who desires to read news bulletins
H    doing so over the LAN.  For a large cluster of computer systems, the
I    savings in total disk space is clearly worthwhile.  Also, this allows
 F    workstations with limited disk storage space to participate in the
C    news without incoming items consuming oppressive amounts of the
     workstation's disk storage.
  
 C    We have heard rumors of somewhat successful attempts to provide
 G    centralized news service using IBIS and other shared or distributed
 D    file systems.  While it is possible that such a distributed file
A    system implementation might work well with a group of similar
 G    computers running nearly identical operating systems, such a scheme
 D    is not general enough to offer service to a wide range of client
I    systems, especially when many diverse operating systems may be in use
 I    among a group of clients.  There are few (if any) shared or networked
 E    file systems that can offer the generality of service that stream
 D    connections using Internet TCP provide, particularly when a wide
@    range of host hardware and operating systems are considered.
 
 G    NNTP specifies a protocol for the distribution, inquiry, retrieval,
 F    and posting of news articles using a reliable stream (such as TCP)
I    server-client model. NNTP is designed so that news articles need only
  
  
 I Kantor & Lapsley                                                [Page 2]
  
 
  
 I RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
 H    be stored on one (presumably central) host, and subscribers on other
A    hosts attached to the LAN may read news articles using stream
 !    connections to the news host.
  
 E    NNTP is modelled upon the news article specifications in RFC 850,
 D    which describes the USENET news system.  However, NNTP makes few
I    demands upon the structure, content, or storage of news articles, and
 E    thus we believe it easily can be adapted to other non-USENET news
     systems.
 
 H    Typically, the NNTP server runs as a background process on one host,
I    and would accept connections from other hosts on the LAN.  This works
 C    well when there are a number of small computer systems (such as
 I    workstations, with only one or at most a few users each), and a large
     central server.
  
   1.5.  Intermediate News Servers
 
 G    For clusters of machines with many users (as might be the case in a
 G    university or large industrial environment), an intermediate server
 D    might be used.  This intermediate or "slave" server runs on each
B    computer system, and is responsible for mediating news reading
D    requests and performing local caching of recently-retrieved news

    articles.
  
 E    Typically, a client attempting to obtain news service would first
 I    attempt to connect to the news service port on the local machine.  If
 B    this attempt were unsuccessful, indicating a failed server, an
F    installation might choose to either deny news access, or to permit
3    connection to the central "master" news server.
  
 E    For workstations or other small systems, direct connection to the
 C    master server would probably be the normal manner of operation.
  
 A    This specification does not cover the operation of slave NNTP
 I    servers.  We merely suggest that slave servers are a logical addition
 E    to NNTP server usage which would enhance operation on large local
     area networks.
 
  1.6.  News Distribution
 
 ?    NNTP has commands which provide a straightforward method of
 G    exchanging articles between cooperating hosts. Hosts which are well
 C    connected on a local area or other fast network and who wish to
 H    actually obtain copies of news articles for local storage might well
E    find NNTP to be a more efficient way to distribute news than more
 0    traditional transfer methods (such as UUCP).
 
  
 I Kantor & Lapsley                                                [Page 3]
  
 
  
 I RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
 D    In the traditional method of distributing news articles, news is
F    propagated from host to host by flooding - that is, each host will
H    send all its new news articles on to each host that it feeds.  These
E    hosts will then in turn send these new articles on to other hosts
 F    that they feed.  Clearly, sending articles that a host already has
F    obtained a copy of from another feed (many hosts that receive news
D    are redundantly fed) again is a waste of time and communications
G    resources, but for transport mechanisms that are single-transaction
 G    based rather than interactive (such as UUCP in the UNIX-world <1>),
 F    distribution time is diminished by sending all articles and having
A    the receiving host simply discard the duplicates.  This is an
 F    especially true when communications sessions are limited to once a
    day.
 
 B    Using NNTP, hosts exchanging news articles have an interactive
H    mechanism for deciding which articles are to be transmitted.  A host
D    desiring new news, or which has new news to send, will typically
C    contact one or more of its neighbors using NNTP.  First it will
 H    inquire if any new news groups have been created on the serving host
H    by means of the NEWGROUPS command.  If so, and those are appropriate
H    or desired (as established by local site-dependent rules), those new
    newsgroups can be created.
 
 C    The client host will then inquire as to which new articles have
 H    arrived in all or some of the newsgroups that it desires to receive,
F    using the NEWNEWS command.  It will receive a list of new articles
H    from the server, and can request transmission of those articles that
)    it desires and does not already have.
  
 I    Finally, the client can advise the server of those new articles which
 E    the client has recently received.  The server will indicate those
 G    articles that it has already obtained copies of, and which articles
 ,    should be sent to add to its collection.
 
 D    In this manner, only those articles which are not duplicates and
&    which are desired are transferred.
 
n 
s 
n 
  
s 
  
  
t 
o 
h 
M 

 
 I Kantor & Lapsley                                                [Page 4]
  
 
p 
iI RFC 977                                                    February 1986
  Network News Transfer Protocol
. 
N 
i 2.  The NNTP Specification
a 
c 2.1.  Overview
  
eG    The news server specified by this document uses a stream connection
wG    (such as TCP) and SMTP-like commands and responses.  It is designed
mG    to accept connections from hosts, and to provide a simple interface
r    to the news database.
m 
iB    This server is only an interface between programs and the news
H    databases. It does not perform any user interaction or presentation-
G    level functions. These "user-friendly" functions are better left to
bA    the client programs, which have a better understanding of the
t,    environment in which they are operating.
 
eB    When used via Internet TCP, the contact port assigned for this
    service is 119.
s 
i 2.2.  Character Codes
 
 B    Commands and replies are composed of characters from the ASCII
E    character set.  When the transport service provides an 8-bit byte
mE    (octet) transmission channel, each 7-bit character is transmitted
rH    right justified in an octet with the high order bit cleared to zero.
 
t 2.3.  Commands
s 
hB    Commands consist of a command word, which in some cases may be
H    followed by a parameter.  Commands with parameters must separate the
H    parameters from each other and from the command by one or more space
H    or tab characters.  Command lines must be complete with all required
:    parameters, and may not contain more than one command.
 
tF    Commands and command parameters are not case sensitive. That is, a
C    command or parameter word may be upper case, lower case, or any
 $    mixture of upper and lower case.
 
gF    Each command line must be terminated by a CR-LF (Carriage Return -
    Line Feed) pair.
 
wI    Command lines shall not exceed 512 characters in length, counting all
eA    characters including spaces, separators, punctuation, and the
eI    trailing CR-LF (thus there are 510 characters maximum allowed for the
;H    command and its parameters).  There is no provision for continuation
    command lines.
 
  
  
  
 I Kantor & Lapsley                                                [Page 5]
  
 
  
 I RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  2.4.  Responses
 
 3    Responses are of two kinds, textual and status.
h 
m 2.4.1.  Text Responses
s 
 H    Text is sent only after a numeric status response line has been sent
F    that indicates that text will follow.  Text is sent as a series of
H    successive lines of textual matter, each terminated with CR-LF pair.
F    A single line containing only a period (.) is sent to indicate the
G    end of the text (i.e., the server will send a CR-LF pair at the end
s@    of the last line of text, a period, and another CR-LF pair).
 
oE    If the text contained a period as the first character of the text
 G    line in the original, that first period is doubled.  Therefore, the
tF    client must examine the first character of each line received, and
H    for those beginning with a period, determine either that this is the
I    end of the text or whether to collapse the doubled period to a single
n    one.
 
lH    The intention is that text messages will usually be displayed on the
H    user's terminal whereas command/status responses will be interpreted
>    by the client program before any possible display is done.
 
y 2.4.2.  Status Responses
  
tI    These are status reports from the server and indicate the response to
 .    the last command received from the client.
 
 D    Status response lines begin with a 3 digit numeric code which is
F    sufficient to distinguish all responses.  Some of these may herald
(    the subsequent transmission of text.
 
rB    The first digit of the response broadly indicates the success,
1    failure, or progress of the previous command.
d 
s        1xx - Informative message
       2xx - Command ok
o4       3xx - Command ok so far, send the rest of it.
?       4xx - Command was correct, but couldn't be performed for
w             some reason.
p>       5xx - Command unimplemented, or incorrect, or a serious
$             program error occurred.
 
l 
t 
  
s 
e 
aI Kantor & Lapsley                                                [Page 6]
  
 
f 
mI RFC 977                                                    February 1986
e Network News Transfer Protocol
  
e 
eH    The next digit in the code indicates the function response category.
 
e:       x0x - Connection, setup, and miscellaneous messages
        x1x - Newsgroup selection
       x2x - Article selection
#       x3x - Distribution functions
e       x4x - Posting
<       x8x - Nonstandard (private implementation) extensions
       x9x - Debugging output
  
rF    The exact response codes that should be expected from each command
H    are detailed in the description of that command.  In addition, below
I    is listed a general set of response codes that may be received at any
d	    time.
w 
rC    Certain status responses contain parameters such as numbers and
 C    names. The number and type of such parameters is fixed for each
 =    response code to simplify interpretation of the response.
s 
aI    Parameters are separated from the numeric response code and from each
dH    other by a single space. All numeric parameters are decimal, and may
H    have leading zeros. All string parameters begin after the separating
E    space, and end before the following separating space or the CR-LF
bG    pair at the end of the line. (String parameters may not, therefore,
 E    contain spaces.) All text, if any, in the response which is not a
eH    parameter of the response must follow and be separated from the last
H    parameter by a space.  Also, note that the text following a response
C    number may vary in different implementations of the server. The
rF    3-digit numeric code should be used to determine what response was
	    sent.
s 
iE    Response codes not specified in this standard may be used for any
rG    installation-specific additional commands also not specified. These
fF    should be chosen to fit the pattern of x8x specified above.  (Note
I    that debugging is provided for explicitly in the x9x response codes.)
 B    The use of unspecified response codes for standard commands is
    prohibited.
s 
eF    We have provided a response pattern x9x for debugging.  Since much
G    debugging output may be classed as "informative messages", we would
tG    expect, therefore, that responses 190 through 199 would be used for
e?    various debugging outputs.  There is no requirement in this
eH    specification for debugging output, but if such is provided over the
G    connected stream, it must use these response codes.  If appropriate
rA    to a specific implementation, other x9x codes may be used for
sF    debugging.  (An example might be to use e.g., 290 to acknowledge a
    remote debugging request.)
 
  
 I Kantor & Lapsley                                                [Page 7]
s 
 
e 
yI RFC 977                                                    February 1986
g Network News Transfer Protocol
n 
r 
l 2.4.3.  General Responses
 
 I    The following is a list of general response codes that may be sent by
fH    the NNTP server.  These are not specific to any one command, but may
I    be returned as the result of a connection, a failure, or some unusual
w    condition.
 
tG    In general, 1xx codes may be ignored or displayed as desired;  code
nA    200 or 201 is sent upon initial connection to the NNTP server
 E    depending upon posting permission; code 400 will be sent when the
yH    NNTP server discontinues service (by operator request, for example);
F    and 5xx codes indicate that the command could not be performed for
    some unusual reason.
 
c       100 help text
       190
         through
       199 debug output
s 

)       200 server ready - posting allowed
n,       201 server ready - no posting allowed
 
        400 service discontinued
t 
 !       500 command not recognized
i       501 command syntax error
 2       502 access restriction or permission denied
0       503 program fault - command not performed
 
o! 3.  Command and Response Details
  
tI    On the following pages are descriptions of each command recognized by
iE    the NNTP server and the responses which will be returned by those
a
    commands.
b 
dE    Each command is shown in upper case for clarity, although case is
sF    ignored in the interpretation of commands by the NNTP server.  Any
E    parameters are shown in lower case.  A parameter shown in [square
aA    brackets] is optional.  For example, [GMT] indicates that the
y(    triglyph GMT may present or omitted.
 
aF    Every command described in this section must be implemented by all
    NNTP servers.
d 
A 
s 
  
d 
r 
 I Kantor & Lapsley                                                [Page 8]
  
 
  
 I RFC 977                                                    February 1986
a Network News Transfer Protocol
s 
  
bD    There is no prohibition against additional commands being added;
F    however, it is recommended that any such unspecified command begin
F    with the letter "X" to avoid conflict with later revisions of this
    specification.
 
cC    Implementors are reminded that such additional commands may not
e?    redefine specified status response codes.  Using additional
lC    unspecified responses for standard commands is also prohibited.
n 
 1 3.1.  The ARTICLE, BODY, HEAD, and STAT commands
r 
yE    There are two forms to the ARTICLE command (and the related BODY,
 I    HEAD, and STAT commands), each using a different method of specifying
iB    which article is to be retrieved.  When the ARTICLE command is
G    followed by a message-id in angle brackets ("<" and ">"), the first
II    form of the command is used; when a numeric parameter or no parameter
a,    is supplied, the second form is invoked.
 
 A    The text of the article is returned as a textual response, as
 '    described earlier in this document.

 
pC    The HEAD and BODY commands are identical to the ARTICLE command
uF    except that they respectively return only the header lines or text
    body of the article.
 
wE    The STAT command is similar to the ARTICLE command except that no
nG    text is returned.  When selecting by message number within a group,
eF    the STAT command serves to set the current article pointer without
H    sending text. The returned acknowledgement response will contain the
F    message-id, which may be of some value.  Using the STAT command to
D    select by message-id is valid but of questionable value, since a
I    selection by message-id does NOT alter the "current article pointer".
a 
a* 3.1.1.  ARTICLE (selection by message-id)
 
i    ARTICLE <message-id>
 
 A    Display the header, a blank line, then the body (text) of the
iE    specified article.  Message-id is the message id of an article as
nF    shown in that article's header.  It is anticipated that the client
B    will obtain the message-id from a list provided by the NEWNEWS
F    command, from references contained within another article, or from
C    the message-id provided in the response to some other commands.
  
mH    Please note that the internally-maintained "current article pointer"
B    is NOT ALTERED by this command. This is both to facilitate the
E    presentation of articles that may be referenced within an article
r 
r 
pI Kantor & Lapsley                                                [Page 9]
e 
 
p 
mI RFC 977                                                    February 1986
m Network News Transfer Protocol
t 
. 
aG    being read, and because of the semantic difficulties of determining
aH    the proper sequence and membership of an article which may have been
&    posted to more than one newsgroup.
 

& 3.1.2.  ARTICLE (selection by number)
 
s    ARTICLE [nnn]
1 
hB    Displays the header, a blank line, then the body (text) of the
D    current or specified article.  The optional parameter nnn is the
 
 H    numeric id of an article in the current newsgroup and must be chosen
H    from the range of articles provided when the newsgroup was selected.
5    If it is omitted, the current article is assumed.
  
 F    The internally-maintained "current article pointer" is set by this
3    command if a valid article number is specified.
  
tC    [the following applies to both forms of the article command.] A
tH    response indicating the current article number, a message-id string,
0    and that text is to follow will be returned.
 

H    The message-id string returned is an identification string contained
I    within angle brackets ("<" and ">"), which is derived from the header
 C    of the article itself.  The Message-ID header line (required by
 H    RFC850) from the article must be used to supply this information. If
D    the message-id header line is missing from the article, a single
B    digit "0" (zero) should be supplied within the angle brackets.
 
 E    Since the message-id field is unique with each article, it may be
tI    used by a news reading program to skip duplicate displays of articles
 H    that have been posted more than once, or to more than one newsgroup.
 
d 3.1.3.  Responses
 
 6    220 n <a> article retrieved - head and body follow
2            (n = article number, <a> = message-id)
.    221 n <a> article retrieved - head follows
.    222 n <a> article retrieved - body follows
9    223 n <a> article retrieved - request text separately
 &    412 no newsgroup has been selected
,    420 no current article has been selected
,    423 no such article number in this group
    430 no such article found
t 
  
  
S 
u 
eI Kantor & Lapsley                                               [Page 10]
d 
 
i 
aI RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
p 3.2.  The GROUP command
 
c 3.2.1.  GROUP
 
 
    GROUP ggg
t 
pA    The required parameter ggg is the name of the newsgroup to be
 B    selected (e.g. "net.news").  A list of valid newsgroups may be
#    obtained from the LIST command.
t 
uH    The successful selection response will return the article numbers of
D    the first and last articles in the group, and an estimate of the
F    number of articles on file in the group.  It is not necessary that
F    the estimate be correct, although that is helpful; it must only be
I    equal to or larger than the actual number of articles on file.  (Some
eG    implementations will actually count the number of articles on file.
nF    Others will just subtract first article number from last to get an
    estimate.)
 
 @    When a valid group is selected by means of this command, the
G    internally maintained "current article pointer" is set to the first
d@    article in the group.  If an invalid group is specified, the
G    previously selected group and article remain selected.  If an empty
 A    newsgroup is selected, the "current article pointer" is in an
d/    indeterminate state and should not be used.
p 
eG    Note that the name of the newsgroup is not case-dependent.  It must
eD    otherwise match a newsgroup obtained from the LIST command or an
    error will result.
 
s 3.2.2.  Responses
 
     211 n f l s group selected
7            (n = estimated number of articles in group,
a2            f = first article number in the group,
1            l = last article number in the group,
a#            s = name of the group.)
     411 no such news group
 
g 
a 
r 
e 
p 
t 

 
  
a 
  
 I Kantor & Lapsley                                               [Page 11]
d 
 
  
eI RFC 977                                                    February 1986
f Network News Transfer Protocol
t 
e 
  3.3.  The HELP command
e 
s
 3.3.1.  HELP
  
a    HELP
 
eD    Provides a short summary of commands that are understood by this
F    implementation of the server. The help text will be presented as a
H    textual response, terminated by a single period on a line by itself.
 
a    3.3.2.  Responses
R 
o    100 help text follows
t 
  3.4.  The IHAVE command
 
r 3.4.1.  IHAVE
 
p    IHAVE <messageid>
n 
aG    The IHAVE command informs the server that the client has an article
 B    whose id is <messageid>.  If the server desires a copy of that
I    article, it will return a response instructing the client to send the
fE    entire article.  If the server does not want the article (if, for
eH    example, the server already has a copy of it), a response indicating
4    that the article is not wanted will be returned.
 
,G    If transmission of the article is requested, the client should send
s@    the entire article, including header and body, in the manner
D    specified for text transmission from the server. A response code
H    indicating success or failure of the transferral of the article will
    be returned.
 
tF    This function differs from the POST command in that it is intended
B    for use in transferring already-posted articles between hosts.
>    Normally it will not be used when the client is a personal
F    newsreading program.  In particular, this function will invoke the
G    server's news posting program with the appropriate settings (flags,
 C    options, etc) to indicate that the forthcoming article is being
      forwarded from another host.
 
nH    The server may, however, elect not to post or forward the article if
I    after further examination of the article it deems it inappropriate to
uH    do so.  The 436 or 437 error codes may be returned as appropriate to
    the situation.
 
eH    Reasons for such subsequent rejection of an article may include such
 
p 
iI Kantor & Lapsley                                               [Page 12]
r 
 
t 
eI RFC 977                                                    February 1986
h Network News Transfer Protocol
r 
  

E    problems as inappropriate newsgroups or distributions, disk space
 G    limitations, article lengths, garbled headers, and the like.  These
gA    are typically restrictions enforced by the server host's news
 8    software and not necessarily the NNTP server itself.
 
z 3.4.2.  Responses
 
     235 article transferred ok
A    335 send article to be transferred.  End with <CR-LF>.<CR-LF>
n+    435 article not wanted - do not send it
e)    436 transfer failed - try again later
r+    437 article rejected - do not try again
i 
     An implementation note:
o 
sE    Because some host news posting software may not be able to decide
 ?    immediately that an article is inappropriate for posting or
dG    forwarding, it is acceptable to acknowledge the successful transfer
r@    of the article and to later silently discard it.  Thus it is
F    permitted to return the 235 acknowledgement code and later discard
G    the received article.  This is not a fully satisfactory solution to
cH    the problem.  Perhaps some implementations will wish to send mail to
8    the author of the article in certain of these cases.
 
  3.5.  The LAST command
  
 
 3.5.1.  LAST
  
     LAST
 
 E    The internally maintained "current article pointer" is set to the
lH    previous article in the current newsgroup.  If already positioned at
H    the first article of the newsgroup, an error message is returned and
)    the current article remains selected.
i 
wF    The internally-maintained "current article pointer" is set by this
    command.
 
uF    A response indicating the current article number, and a message-id
A    string will be returned.  No text is sent in response to this
o    command.
 
o 3.5.2.  Responses
 
h7    223 n a article retrieved - request text separately
a7            (n = article number, a = unique article id)
, 
  
H 
,I Kantor & Lapsley                                               [Page 13]
h 
 
e 
 I RFC 977                                                    February 1986
  Network News Transfer Protocol
t 
f 
t    412 no newsgroup selected
s,    420 no current article has been selected
)    422 no previous article in this group
d 
  3.6.  The LIST command
t 
e
 3.6.1.  LIST
  
e    LIST
 
eH    Returns a list of valid newsgroups and associated information.  Each
@    newsgroup is sent as a line of text in the following format:
 
        group last first p
e 
aG    where <group> is the name of the newsgroup, <last> is the number of
sF    the last known article currently in that newsgroup, <first> is the
F    number of the first article currently in the newsgroup, and <p> is
E    either 'y' or 'n' indicating whether posting to this newsgroup is
r&    allowed ('y') or prohibited ('n').
 
iH    The <first> and <last> fields will always be numeric.  They may have
B    leading zeros.  If the <last> field evaluates to less than the
A    <first> field, there are no articles currently on file in the
c    newsgroup.
 
 I    Note that posting may still be prohibited to a client even though the
 D    LIST command indicates that posting is permitted to a particular
@    newsgroup. See the POST command for an explanation of client
E    prohibitions.  The posting flag exists for each newsgroup because
iI    some newsgroups are moderated or are digests, and therefore cannot be
 C    posted to; that is, articles posted to them must be mailed to a
 H    moderator who will post them for the submitter.  This is independent
E    of the posting permission granted to a client by the NNTP server.

 
 H    Please note that an empty list (i.e., the text body returned by this
H    command consists only of the terminating period) is a possible valid
I    response, and indicates that there are currently no valid newsgroups.

 
p 3.6.2.  Responses
 
 "    215 list of newsgroups follows
 
  
b 
r 
9 
m 
e 
rI Kantor & Lapsley                                               [Page 14]
t 
 
i 
tI RFC 977                                                    February 1986
h Network News Transfer Protocol
m 
  
n 3.7.  The NEWGROUPS command
 
I 3.7.1.  NEWGROUPS
 
r/    NEWGROUPS date time [GMT] [<distributions>]
e 
rH    A list of newsgroups created since <date and time> will be listed in
(    the same format as the LIST command.
 
 F    The date is sent as 6 digits in the format YYMMDD, where YY is the
H    last two digits of the year, MM is the two digits of the month (with
G    leading zero, if appropriate), and DD is the day of the month (with
rE    leading zero, if appropriate).  The closest century is assumed as
iG    part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
o    1999, 00 is 2000).
 
cG    Time must also be specified.  It must be as 6 digits HHMMSS with HH
eF    being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
I    00-59.  The time is assumed to be in the server's timezone unless the
tG    token "GMT" appears, in which case both time and date are evaluated
o    at the 0 meridian.
 
MD    The optional parameter "distributions" is a list of distribution
G    groups, enclosed in angle brackets.  If specified, the distribution
sC    portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
uE    examined for a match with the distribution categories listed, and
sG    only those new newsgroups which match will be listed.  If more than
 E    one distribution group is to be listed, they must be separated by
 %    commas within the angle brackets.
p 
 H    Please note that an empty list (i.e., the text body returned by this
H    command consists only of the terminating period) is a possible valid
G    response, and indicates that there are currently no new newsgroups.
  
l 3.7.2.  Responses
 
c&    231 list of new newsgroups follows
 
  
2 
  
s 
u 
a 
e 
s 
c 

 
  
0I Kantor & Lapsley                                               [Page 15]
i 
 

 
 I RFC 977                                                    February 1986
  Network News Transfer Protocol
  
[ 
e 3.8.  The NEWNEWS command
 
  3.8.1.  NEWNEWS
 
 7    NEWNEWS newsgroups date time [GMT] [<distribution>]
a 
eI    A list of message-ids of articles posted or received to the specified
GI    newsgroup since "date" will be listed. The format of the listing will
tI    be one message-id per line, as though text were being sent.  A single
 I    line consisting solely of one period followed by CR-LF will terminate
n
    the list.
t 
aB    Date and time are in the same format as the NEWGROUPS command.
 
 G    A newsgroup name containing a "*" (an asterisk) may be specified to
nG    broaden the article search to some or all newsgroups.  The asterisk
mA    will be extended to match any part of a newsgroup name (e.g.,
lG    net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
fF    if only an asterisk is given as the newsgroup name, all newsgroups
"    will be searched for new news.
 
 =    (Please note that the asterisk "*" expansion is a general
hE    replacement; in particular, the specification of e.g., net.*.unix
rI    should be correctly expanded to embrace names such as net.wombat.unix
p    and net.whocares.unix.)
a 
cF    Conversely, if no asterisk appears in a given newsgroup name, only
H    the specified newsgroup will be searched for new articles. Newsgroup
H    names must be chosen from those returned in the listing of available
H    groups.  Multiple newsgroup names (including a "*") may be specified
G    in this command, separated by a comma.  No comma shall appear after
sH    the last newsgroup in the list.  [Implementors are cautioned to keep
4    the 512 character command length limit in mind.]
 
 G    The exclamation point ("!") may be used to negate a match. This can
eD    be used to selectively omit certain newsgroups from an otherwise
<    larger list.  For example, a newsgroups specification of
F    "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
I    all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
tE    matched.  If used, the exclamation point must appear as the first
e5    character of the given newsgroup name or pattern.
r 
oD    The optional parameter "distributions" is a list of distribution
G    groups, enclosed in angle brackets.  If specified, the distribution
eG    portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
 H    be examined for a match with the distribution categories listed, and
F    only those articles which have at least one newsgroup belonging to
 
c 
 I Kantor & Lapsley                                               [Page 16]
t 
 
t 
lI RFC 977                                                    February 1986
. Network News Transfer Protocol
  
i 
 ?    the list of distributions will be listed.  If more than one
eC    distribution group is to be supplied, they must be separated by
d%    commas within the angle brackets.
l 
sG    The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
a:    news is discussed in an earlier part of this document.
 
nH    Please note that an empty list (i.e., the text body returned by this
H    command consists only of the terminating period) is a possible valid
@    response, and indicates that there is currently no new news.
 
  3.8.2.  Responses
 
s2    230 list of new articles by message-id follows
 
e 3.9.  The NEXT command
a 
r
 3.9.1.  NEXT
r 
i    NEXT
 
IF    The internally maintained "current article pointer" is advanced to
C    the next article in the current newsgroup.  If no more articles
nE    remain in the current group, an error message is returned and the
e%    current article remains selected.
r 
lF    The internally-maintained "current article pointer" is set by this
    command.
 
tH    A response indicating the current article number, and the message-id
A    string will be returned.  No text is sent in response to this
r    command.
 
r 3.9.2.  Responses
 
m7    223 n a article retrieved - request text separately
 7            (n = article number, a = unique article id)
F    412 no newsgroup selected
 ,    420 no current article has been selected
%    421 no next article in this group
  
o 
m 
s 
a 
o 
a 
n 
g 
pI Kantor & Lapsley                                               [Page 17]
h 
 
  
 I RFC 977                                                    February 1986
s Network News Transfer Protocol
e 
s 
l 3.10.  The POST command
 
z 3.10.1.  POST
 

    POST
 
aI    If posting is allowed, response code 340 is returned to indicate that
RH    the article to be posted should be sent. Response code 440 indicates
F    that posting is prohibited for some installation-dependent reason.
 
iC    If posting is permitted, the article should be presented in the
tF    format specified by RFC850, and should include all required header
H    lines. After the article's header and body have been completely sent
I    by the client to the server, a further response code will be returned
 :    to indicate success or failure of the posting attempt.
 
lD    The text forming the header and body of the message to be posted
H    should be sent by the client using the conventions for text received
H    from the news server:  A single period (".") on a line indicates the
F    end of the text, with lines starting with a period in the original
8    text having that period doubled during transmission.
 
lH    No attempt shall be made by the server to filter characters, fold or
F    limit lines, or otherwise process incoming text.  It is our intent
F    that the server just pass the incoming message to be posted to the
G    server installation's news posting software, which is separate from
i5    this specification.  See RFC850 for more details.
e 
aG    Since most installations will want the client news program to allow
 G    the user to prepare his message using some sort of text editor, and
2H    transmit it to the server for posting only after it is composed, the
I    client program should take note of the herald message that greeted it
 E    when the connection was first established. This message indicates
 F    whether postings from that client are permitted or not, and can be
H    used to caution the user that his access is read-only if that is the
E    case. This will prevent the user from wasting a good deal of time
hG    composing a message only to find posting of the message was denied.

G    The method and determination of which clients and hosts may post is
ED    installation dependent and is not covered by this specification.
 
  3.10.2.  Responses
r 
p    240 article posted ok
 ;    340 send article to be posted. End with <CR-LF>.<CR-LF>
l    440 posting not allowed
n    441 posting failed
 
  

 
 I Kantor & Lapsley                                               [Page 18]
t 
 
  
'I RFC 977                                                    February 1986
r Network News Transfer Protocol
s 
a 
<H    (for reference, one of the following codes will be sent upon initial
F    connection; the client program should determine whether posting is
G    generally permitted from these:) 200 server ready - posting allowed
h)    201 server ready - no posting allowed
e 
e 3.11.  The QUIT command
 
m 3.11.1.  QUIT
 
p    QUIT
 
mH    The server process acknowledges the QUIT command and then closes the
H    connection to the client.  This is the preferred method for a client
G    to indicate that it has finished all its transactions with the NNTP
o    server.
  
 H    If a client simply disconnects (or the connection times out, or some
H    other fault occurs), the server should gracefully cease its attempts
    to service the client.
 
t 3.11.2.  Responses
P 
r%    205 closing connection - goodbye!
y 
s 3.12.  The SLAVE command
r 
  3.12.1.  SLAVE
a 
c	    SLAVE
y 
 E    Indicates to the server that this client connection is to a slave
s    server, rather than a user.
d 
wH    This command is intended for use in separating connections to single
H    users from those to subsidiary ("slave") servers.  It may be used to
E    indicate that priority should therefore be given to requests from
 F    this client, as it is presumably serving more than one person.  It
C    might also be used to determine which connections to close when

G    system load levels are exceeded, perhaps giving preference to slave
n?    servers.  The actual use this command is put to is entirely
eH    implementation dependent, and may vary from one host to another.  In
B    NNTP servers which do not give priority to slave servers, this
<    command must nonetheless be recognized and acknowledged.
 
p 3.12.2.  Responses
  
     202 slave status noted
 
a 
gI Kantor & Lapsley                                               [Page 19]
e 
 
i 
,I RFC 977                                                    February 1986
  Network News Transfer Protocol
I 
u 
b 4.  Sample Conversations
H 
 F    These are samples of the conversations that might be expected with
H    the news server in hypothetical sessions.  The notation C: indicates
I    commands sent to the news server from the client program; S: indicate
 5    responses received from the server by the client.
d 
r, 4.1.  Example 1 - relative access with NEXT
 
e%    S:      (listens at TCP port 119)
d 
h1    C:      (requests connection on TCP port 119)
g8    S:      200 wombatvax news server ready - posting ok
 
i.    (client asks for a current newsgroup list)
    C:      LIST
*    S:      215 list of newsgroups follows
%    S:      net.wombats 00543 00501 y
t*    S:      net.unix-wizards 10125 10011 y
#            (more information here)
 $    S:      net.idiots 00100 00001 n

    S:      .
  
y     (client selects a newsgroup)
"    C:      GROUP net.unix-wizards
?    S:      211 104 10011 10125 net.unix-wizards group selected
 A            (there are 104 articles on file, from 10011 to 10125)
l 
 '    (client selects an article to read)
s    C:      STAT 10110
I    S:      223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
a;            only (article 10110 selected, its message-id is
 !            <23445@sdcsvax.ARPA>)
  
w     (client examines the header)
    C:      HEAD
C    S:      221 10110 <23445@sdcsvax.ARPA> article retrieved - head
m5            follows (text of the header appears here)
s
    S:      .
s 
 6    (client wants to see the text body of the article)
    C:      BODY
C    S:      222 10110 <23445@sdcsvax.ARPA> article retrieved - body
h$            follows (body text here)

    S:      .
s 
g*    (client selects next article in group)
 
r 
aI Kantor & Lapsley                                               [Page 20]
W 
 
c 
aI RFC 977                                                    February 1986
e Network News Transfer Protocol
a 
  
s    C:      NEXT
I    S:      223 10113 <21495@nudebch.uucp> article retrieved - statistics
n2            only (article 10113 was next in group)
 
,    (client finishes session)
     C:      QUIT
    S:      205 goodbye.
 
p7 4.2.  Example 2 - absolute article access with ARTICLE

 
 %    S:      (listens at TCP port 119)
  
a1    C:      (requests connection on TCP port 119)
,B    S:      201 UCB-VAX netnews server ready -- no posting allowed
 
e    C:      GROUP msgs
7    S:      211 103 402 504 msgs Your new group is msgs
 5            (there are 103 articles, from 402 to 504)
p 
m    C:      ARTICLE 401
d1    S:      423 No such article in this newsgroup
r 

    C:      ARTICLE 402
 F    S:      220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
,    S:      (article header and body follow)

    S:      .
s 
m    C:      HEAD 403
G    S:      221 403 <3108@mcvax.UUCP> Article retrieved, header follows
 $    S:      (article header follows)

    S:      .
a 
r    C:      QUIT
A    S:      205 UCB-VAX news server closing connection.  Goodbye.
e 
e$ 4.3.  Example 3 - NEWGROUPS command
 
t%    S:      (listens at TCP port 119)
t 
w1    C:      (requests connection on TCP port 119)
eB    S:      200 Imaginary Institute News Server ready (posting ok)
 
<8    (client asks for new newsgroups since April 3, 1985)
#    C:      NEWGROUPS 850403 020000
m 
h=    S:      231 New newsgroups since 03/04/85 02:00:00 follow
  
c 
a 
rI Kantor & Lapsley                                               [Page 21]
d 
 
t 
sI RFC 977                                                    February 1986
e Network News Transfer Protocol
r 
n 
     S:      net.music.gdead
'    S:      net.games.sources
 
    S:      .
r 
m!    C:      GROUP net.music.gdead
e8    S:      211 0 1 1 net.music.gdead Newsgroup selected
9            (there are no articles in that newsgroup, and
 A            the first and last article numbers should be ignored)
F 
7    C:      QUIT
F    S:      205 Imaginary Institute news server ceasing service.  Bye!
 
r) 4.4.  Example 4 - posting a news article
o 
w%    S:      (listens at TCP port 119)
d 
r1    C:      (requests connection on TCP port 119)
a=    S:      200 BANZAIVAX news server ready, posting allowed.
e 
     C:      POST
C    S:      340 Continue posting; Period on a line by itself to end
e5    C:      (transmits news article in RFC850 format)
 
    C:      .
i,    S:      240 Article posted successfully.
 
c    C:      QUIT
7    S:      205 BANZAIVAX closing connection.  Goodbye.
a 
i7 4.5.  Example 5 - interruption due to operator request
. 
e%    S:      (listens at TCP port 119)
e 
y1    C:      (requests connection on TCP port 119)
 A    S:      201 genericvax news server ready, no posting allowed.
" 
r:            (assume normal conversation for some time, and
/            that a newsgroup has been selected)
  
m    C:      NEXT
H    S:      223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
 
l    C:      HEAD
G    C:      221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
m 
d:    S:      (sends head of article, but halfway through is
>            interrupted by an operator request.  The following
6            then occurs, without client intervention.)
 
e 
 I Kantor & Lapsley                                               [Page 22]
  
 
l 
uI RFC 977                                                    February 1986
u Network News Transfer Protocol
  
4 
n1    S:      (ends current line with a CR-LF pair)
 
    S:      .
 8    S:      400 Connection closed by operator.  Goodbye.
    S:      (closes connection)
  
 C 4.6.  Example 6 - Using the news server to distribute news between
e       systems.
e 
r%    S:      (listens at TCP port 119)
n 
 1    C:      (requests connection on TCP port 119)
 5    S:      201 Foobar NNTP server ready (no posting)
h 
R=    (client asks for new newsgroups since 2 am, May 15, 1985)
 #    C:      NEWGROUPS 850515 020000
i2    S:      235 New newsgroups since 850515 follow
    S:      net.fluff
d    S:      net.lint

    S:      .
t 
t@    (client asks for new news articles since 2 am, May 15, 1985)
#    C:      NEWNEWS * 850515 020000
 4    S:      230 New news since 850515 020000 follows
    S:      <1772@foo.UUCP>
e    S:      <87623@baz.UUCP>
    S:      <17872@GOLD.CSNET>

    S:      .
p 
i-    (client asks for article <1772@foo.UUCP>)
r#    C:      ARTICLE <1772@foo.UUCP>

6    S:      220 <1772@foo.UUCP> All of article follows
"    S:      (sends entire message)

    S:      .
g 
p-    (client asks for article <87623@baz.UUCP>
 $    C:      ARTICLE <87623@baz.UUCP>
7    S:      220 <87623@baz.UUCP> All of article follows
d"    S:      (sends entire message)

    S:      .
m 
 /    (client asks for article <17872@GOLD.CSNET>
l&    C:      ARTICLE <17872@GOLD.CSNET>
9    S:      220 <17872@GOLD.CSNET> All of article follows
e"    S:      (sends entire message)

    S:      .
n 
l 
i 
s 
wI Kantor & Lapsley                                               [Page 23]
F 
 
r 
rI RFC 977                                                    February 1986
g Network News Transfer Protocol
e 
e 
s7    (client offers an article it has received recently)
i$    C:      IHAVE <4105@ucbvax.ARPA>
6    S:      435 Already seen that one, where you been?
 
e#    (client offers another article)
t$    C:      IHAVE <4106@ucbvax.ARPA>
0    S:      335 News to me!  <CRLF.CRLF> to end.
    C:      (sends article)
p
    C:      .
,:    S:      235 Article transferred successfully.  Thanks.
 
a    (or)
 
t     S:      436 Transfer failed.
 
t,    (client is all through with the session)
    C:      QUIT
5    S:      205 Foobar NNTP server bids you farewell.
  
e) 4.7.  Summary of commands and responses.
a 
hG    The following are the commands recognized and responses returned by
s    the NNTP server.
 
2 4.7.1.  Commands
  
2    ARTICLE
s    BODY
	    GROUP
     HEAD
    HELP
	    IHAVE
<    LAST
    LIST

    NEWGROUPS
t    NEWNEWS
     NEXT
    POST
    QUIT
	    SLAVE
&    STAT
 
  4.7.2.  Responses
 
     100 help text follows
t    199 debug output
 
  
  
 I Kantor & Lapsley                                               [Page 24]
e 
 
c 
sI RFC 977                                                    February 1986
n Network News Transfer Protocol
  
g 
 &    200 server ready - posting allowed
)    201 server ready - no posting allowed
r    202 slave status noted
%    205 closing connection - goodbye!
d    211 n f l s group selected
"    215 list of newsgroups follows
H    220 n <a> article retrieved - head and body follow 221 n <a> article
    retrieved - head follows
.    222 n <a> article retrieved - body follows
I    223 n <a> article retrieved - request text separately 230 list of new
 "    articles by message-id follows
&    231 list of new newsgroups follows
    235 article transferred ok
    240 article posted ok
c 
lA    335 send article to be transferred.  End with <CR-LF>.<CR-LF>
s;    340 send article to be posted. End with <CR-LF>.<CR-LF>
2 
T    400 service discontinued
    411 no such news group
&    412 no newsgroup has been selected
,    420 no current article has been selected
%    421 no next article in this group
m)    422 no previous article in this group
c,    423 no such article number in this group
    430 no such article found
y+    435 article not wanted - do not send it
d)    436 transfer failed - try again later
t,    437 article rejected - do not try again.
    440 posting not allowed
t    441 posting failed
 
w    500 command not recognized
    501 command syntax error
/    502 access restriction or permission denied
s-    503 program fault - command not performed
i 
n0 4.8.  A Brief Word about the USENET News System
 
rG    In the UNIX world, which traditionally has been linked by 1200 baud
tI    dial-up telephone lines, the USENET News system has evolved to handle
wI    central storage, indexing, retrieval, and distribution of news.  With
 F    the exception of its underlying transport mechanism (UUCP), USENET
H    News is an efficient means of providing news and bulletin service to
C    subscribers on UNIX and other hosts worldwide.  The USENET News
e 
n 
s 
o 
HI Kantor & Lapsley                                               [Page 25]

 
 
e 
wI RFC 977                                                    February 1986
  Network News Transfer Protocol
c 
n 
rG    system is discussed in detail in RFC 850.  It runs on most versions
.C    of UNIX and on many other operating systems, and is customarily
(    distributed without charge.
  
 H    USENET uses a spooling area on the UNIX host to store news articles,
D    one per file. Each article consists of a series of heading text,
@    which contain the sender's identification and organizational
B    affiliation, timestamps, electronic mail reply paths, subject,
H    newsgroup (subject category), and the like.  A complete news article
I    is reproduced in its entirety below.  Please consult RFC 850 for more
p    details.
 
O?       Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
a       sdcsvax.UUCP
 F       Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
I       Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
        !honman
*       From: honman@unitek.uucp (Man Wong)
#       Newsgroups: net.unix-wizards
s*       Subject: foreground -> background ?
$       Message-ID: <167@unitek.uucp>
#       Date: 25 Sep 85 23:51:52 GMT

,       Date-Received: 29 Sep 85 09:54:48 GMT
2       Reply-To: honman@unitek.UUCP (Hon-Man Wong)
       Distribution: net.all
4       Organization: Unitek Technologies Corporation
       Lines: 12
 
 I       I have a process (C program) which generates a child and waits for
eF       it to return.  What I would like to do is to be able to run the
I       child process interactively for a while before kicking itself into
 F       the background so I can return to the parent process (while the
I       child process is RUNNING in the background).  Can it be done?  And
e       if it can, how?
 
 2       Please reply by E-mail.  Thanks in advance.
 
c       Hon-Man Wong
e 
  
t 
s 
s 
  
  
  
o 
  
t 
eI Kantor & Lapsley                                               [Page 26]
Q 
 
  
 I RFC 977                                                    February 1986
C Network News Transfer Protocol
T 
p 
  5.  References
  
 D    [1]  Crocker, D., "Standard for the Format of ARPA Internet Text
B         Messages", RFC-822, Department of Electrical Engineering,
.         University of Delaware, August, 1982.
 
sC    [2]  Horton, M., "Standard for Interchange of USENET Messages",
C-         RFC-850, USENET Project, June, 1983.
t 
eC    [3]  Postel, J., "Transmission Control Protocol- DARPA Internet
2B         Program Protocol Specification", RFC-793, USC/Information
-         Sciences Institute, September, 1981.
  
 >    [4]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
:         USC/Information Sciences Institute, August, 1982.
 
o 6.  Acknowledgements
r 
 D    The authors wish to express their heartfelt thanks to those many
H    people who contributed to this specification, and especially to Erik
I    Fair and Chuq von Rospach, without whose inspiration this whole thing
1"    would not have been necessary.
 
e
 7.  Notes
 
a1    <1> UNIX is a trademark of Bell Laboratories.
r 
s 
n 
A 
l 
  
5 
  
C 
  
N 
R 
S 
0 
  
0 
m 
h 
  
  
  
1 
w 
wI Kantor & Lapsley                                               [Page 27]
  
