james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hb...@apache.org
Subject cvs commit: jakarta-james/docs/rfclist rfc977.txt rfc822.txt rfc1036.txt README draft-ietf-nntpext-base-13.txt
Date Thu, 05 Apr 2001 09:51:26 GMT
hbedi       01/04/05 02:51:25

  Added:       docs/rfclist rfc977.txt rfc822.txt rfc1036.txt README
                        draft-ietf-nntpext-base-13.txt
  Log:
  RFC and drafts relevant to James
  
  Revision  Changes    Path
  1.1                  jakarta-james/docs/rfclist/rfc977.txt
  
  Index: rfc977.txt
  ===================================================================
  
  Network Working Group                      Brian Kantor (U.C. San Diego)
  Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)
                                                             February 1986
  
                       Network News Transfer Protocol
                                      
                  A Proposed Standard for the Stream-Based
                            Transmission of News
  
  Status of This Memo
  
     NNTP specifies a protocol for the distribution, inquiry, retrieval,
     and posting of news articles using a reliable stream-based
     transmission of news among the ARPA-Internet community.  NNTP is
     designed so that news articles are stored in a central database
     allowing a subscriber to select only those items he wishes to read.
     Indexing, cross-referencing, and expiration of aged messages are also
     provided. This RFC suggests a proposed protocol for the ARPA-Internet
     community, and requests discussion and suggestions for improvements.
     Distribution of this memo is unlimited.
  
  1.  Introduction
  
     For many years, the ARPA-Internet community has supported the
     distribution of bulletins, information, and data in a timely fashion
     to thousands of participants.  We collectively refer to such items of
     information as "news".  Such news provides for the rapid
     dissemination of items of interest such as software bug fixes, new
     product reviews, technical tips, and programming pointers, as well as
     rapid-fire discussions of matters of concern to the working computer
     professional. News is very popular among its readers.
  
     There are popularly two methods of distributing such news: the
     Internet method of direct mailing, and the USENET news system.
  
  1.1.  Internet Mailing Lists
  
     The Internet community distributes news by the use of mailing lists.
     These are lists of subscriber's mailbox addresses and remailing
     sublists of all intended recipients.  These mailing lists operate by
     remailing a copy of the information to be distributed to each
     subscriber on the mailing list.  Such remailing is inefficient when a
     mailing list grows beyond a dozen or so people, since sending a
     separate copy to each of the subscribers occupies large quantities of
     network bandwidth, CPU resources, and significant amounts of disk
     storage at the destination host.  There is also a significant problem
     in maintenance of the list itself: as subscribers move from one job
     to another; as new subscribers join and old ones leave; and as hosts
     come in and out of service.
  
  
  
  
  Kantor & Lapsley                                                [Page 1]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  1.2.  The USENET News System
  
     Clearly, a worthwhile reduction of the amount of these resources used
     can be achieved if articles are stored in a central database on the
     receiving host instead of in each subscriber's mailbox. The USENET
     news system provides a method of doing just this.  There is a central
     repository of the news articles in one place (customarily a spool
     directory of some sort), and a set of programs that allow a
     subscriber to select those items he wishes to read.  Indexing,
     cross-referencing, and expiration of aged messages are also provided.
  
  1.3.  Central Storage of News
  
     For clusters of hosts connected together by fast local area networks
     (such as Ethernet), it makes even more sense to consolidate news
     distribution onto one (or a very few) hosts, and to allow access to
     these news articles using a server and client model.  Subscribers may
     then request only the articles they wish to see, without having to
     wastefully duplicate the storage of a copy of each item on each host.
  
  1.4.  A Central News Server
  
     A way to achieve these economies is to have a central computer system
     that can provide news service to the other systems on the local area
     network.  Such a server would manage the collection of news articles
     and index files, with each person who desires to read news bulletins
     doing so over the LAN.  For a large cluster of computer systems, the
     savings in total disk space is clearly worthwhile.  Also, this allows
     workstations with limited disk storage space to participate in the
     news without incoming items consuming oppressive amounts of the
     workstation's disk storage.
  
     We have heard rumors of somewhat successful attempts to provide
     centralized news service using IBIS and other shared or distributed
     file systems.  While it is possible that such a distributed file
     system implementation might work well with a group of similar
     computers running nearly identical operating systems, such a scheme
     is not general enough to offer service to a wide range of client
     systems, especially when many diverse operating systems may be in use
     among a group of clients.  There are few (if any) shared or networked
     file systems that can offer the generality of service that stream
     connections using Internet TCP provide, particularly when a wide
     range of host hardware and operating systems are considered.
  
     NNTP specifies a protocol for the distribution, inquiry, retrieval,
     and posting of news articles using a reliable stream (such as TCP)
     server-client model. NNTP is designed so that news articles need only
  
  
  Kantor & Lapsley                                                [Page 2]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     be stored on one (presumably central) host, and subscribers on other
     hosts attached to the LAN may read news articles using stream
     connections to the news host.
  
     NNTP is modelled upon the news article specifications in RFC 850,
     which describes the USENET news system.  However, NNTP makes few
     demands upon the structure, content, or storage of news articles, and
     thus we believe it easily can be adapted to other non-USENET news
     systems.
  
     Typically, the NNTP server runs as a background process on one host,
     and would accept connections from other hosts on the LAN.  This works
     well when there are a number of small computer systems (such as
     workstations, with only one or at most a few users each), and a large
     central server.
  
  1.5.  Intermediate News Servers
  
     For clusters of machines with many users (as might be the case in a
     university or large industrial environment), an intermediate server
     might be used.  This intermediate or "slave" server runs on each
     computer system, and is responsible for mediating news reading
     requests and performing local caching of recently-retrieved news
     articles.
  
     Typically, a client attempting to obtain news service would first
     attempt to connect to the news service port on the local machine.  If
     this attempt were unsuccessful, indicating a failed server, an
     installation might choose to either deny news access, or to permit
     connection to the central "master" news server.
  
     For workstations or other small systems, direct connection to the
     master server would probably be the normal manner of operation.
  
     This specification does not cover the operation of slave NNTP
     servers.  We merely suggest that slave servers are a logical addition
     to NNTP server usage which would enhance operation on large local
     area networks.
  
  1.6.  News Distribution
  
     NNTP has commands which provide a straightforward method of
     exchanging articles between cooperating hosts. Hosts which are well
     connected on a local area or other fast network and who wish to
     actually obtain copies of news articles for local storage might well
     find NNTP to be a more efficient way to distribute news than more
     traditional transfer methods (such as UUCP).
  
  
  Kantor & Lapsley                                                [Page 3]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     In the traditional method of distributing news articles, news is
     propagated from host to host by flooding - that is, each host will
     send all its new news articles on to each host that it feeds.  These
     hosts will then in turn send these new articles on to other hosts
     that they feed.  Clearly, sending articles that a host already has
     obtained a copy of from another feed (many hosts that receive news
     are redundantly fed) again is a waste of time and communications
     resources, but for transport mechanisms that are single-transaction
     based rather than interactive (such as UUCP in the UNIX-world <1>),
     distribution time is diminished by sending all articles and having
     the receiving host simply discard the duplicates.  This is an
     especially true when communications sessions are limited to once a
     day.
  
     Using NNTP, hosts exchanging news articles have an interactive
     mechanism for deciding which articles are to be transmitted.  A host
     desiring new news, or which has new news to send, will typically
     contact one or more of its neighbors using NNTP.  First it will
     inquire if any new news groups have been created on the serving host
     by means of the NEWGROUPS command.  If so, and those are appropriate
     or desired (as established by local site-dependent rules), those new
     newsgroups can be created.
  
     The client host will then inquire as to which new articles have
     arrived in all or some of the newsgroups that it desires to receive,
     using the NEWNEWS command.  It will receive a list of new articles
     from the server, and can request transmission of those articles that
     it desires and does not already have.
  
     Finally, the client can advise the server of those new articles which
     the client has recently received.  The server will indicate those
     articles that it has already obtained copies of, and which articles
     should be sent to add to its collection.
  
     In this manner, only those articles which are not duplicates and
     which are desired are transferred.
  
  
  
  
  
  
  
  
  
  
  
  
  
  Kantor & Lapsley                                                [Page 4]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  2.  The NNTP Specification
  
  2.1.  Overview
  
     The news server specified by this document uses a stream connection
     (such as TCP) and SMTP-like commands and responses.  It is designed
     to accept connections from hosts, and to provide a simple interface
     to the news database.
  
     This server is only an interface between programs and the news
     databases. It does not perform any user interaction or presentation-
     level functions. These "user-friendly" functions are better left to
     the client programs, which have a better understanding of the
     environment in which they are operating.
  
     When used via Internet TCP, the contact port assigned for this
     service is 119.
  
  2.2.  Character Codes
  
     Commands and replies are composed of characters from the ASCII
     character set.  When the transport service provides an 8-bit byte
     (octet) transmission channel, each 7-bit character is transmitted
     right justified in an octet with the high order bit cleared to zero.
  
  2.3.  Commands
  
     Commands consist of a command word, which in some cases may be
     followed by a parameter.  Commands with parameters must separate the
     parameters from each other and from the command by one or more space
     or tab characters.  Command lines must be complete with all required
     parameters, and may not contain more than one command.
  
     Commands and command parameters are not case sensitive. That is, a
     command or parameter word may be upper case, lower case, or any
     mixture of upper and lower case.
  
     Each command line must be terminated by a CR-LF (Carriage Return -
     Line Feed) pair.
  
     Command lines shall not exceed 512 characters in length, counting all
     characters including spaces, separators, punctuation, and the
     trailing CR-LF (thus there are 510 characters maximum allowed for the
     command and its parameters).  There is no provision for continuation
     command lines.
  
  
  
  
  Kantor & Lapsley                                                [Page 5]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  2.4.  Responses
  
     Responses are of two kinds, textual and status.
  
  2.4.1.  Text Responses
  
     Text is sent only after a numeric status response line has been sent
     that indicates that text will follow.  Text is sent as a series of
     successive lines of textual matter, each terminated with CR-LF pair.
     A single line containing only a period (.) is sent to indicate the
     end of the text (i.e., the server will send a CR-LF pair at the end
     of the last line of text, a period, and another CR-LF pair).
  
     If the text contained a period as the first character of the text
     line in the original, that first period is doubled.  Therefore, the
     client must examine the first character of each line received, and
     for those beginning with a period, determine either that this is the
     end of the text or whether to collapse the doubled period to a single
     one.
  
     The intention is that text messages will usually be displayed on the
     user's terminal whereas command/status responses will be interpreted
     by the client program before any possible display is done.
  
  2.4.2.  Status Responses
  
     These are status reports from the server and indicate the response to
     the last command received from the client.
  
     Status response lines begin with a 3 digit numeric code which is
     sufficient to distinguish all responses.  Some of these may herald
     the subsequent transmission of text.
  
     The first digit of the response broadly indicates the success,
     failure, or progress of the previous command.
  
        1xx - Informative message
        2xx - Command ok
        3xx - Command ok so far, send the rest of it.
        4xx - Command was correct, but couldn't be performed for
              some reason.
        5xx - Command unimplemented, or incorrect, or a serious
              program error occurred.
  
  
  
  
  
  
  Kantor & Lapsley                                                [Page 6]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     The next digit in the code indicates the function response category.
  
        x0x - Connection, setup, and miscellaneous messages
        x1x - Newsgroup selection
        x2x - Article selection
        x3x - Distribution functions
        x4x - Posting
        x8x - Nonstandard (private implementation) extensions
        x9x - Debugging output
  
     The exact response codes that should be expected from each command
     are detailed in the description of that command.  In addition, below
     is listed a general set of response codes that may be received at any
     time.
  
     Certain status responses contain parameters such as numbers and
     names. The number and type of such parameters is fixed for each
     response code to simplify interpretation of the response.
  
     Parameters are separated from the numeric response code and from each
     other by a single space. All numeric parameters are decimal, and may
     have leading zeros. All string parameters begin after the separating
     space, and end before the following separating space or the CR-LF
     pair at the end of the line. (String parameters may not, therefore,
     contain spaces.) All text, if any, in the response which is not a
     parameter of the response must follow and be separated from the last
     parameter by a space.  Also, note that the text following a response
     number may vary in different implementations of the server. The
     3-digit numeric code should be used to determine what response was
     sent.
  
     Response codes not specified in this standard may be used for any
     installation-specific additional commands also not specified. These
     should be chosen to fit the pattern of x8x specified above.  (Note
     that debugging is provided for explicitly in the x9x response codes.)
     The use of unspecified response codes for standard commands is
     prohibited.
  
     We have provided a response pattern x9x for debugging.  Since much
     debugging output may be classed as "informative messages", we would
     expect, therefore, that responses 190 through 199 would be used for
     various debugging outputs.  There is no requirement in this
     specification for debugging output, but if such is provided over the
     connected stream, it must use these response codes.  If appropriate
     to a specific implementation, other x9x codes may be used for
     debugging.  (An example might be to use e.g., 290 to acknowledge a
     remote debugging request.)
  
  
  Kantor & Lapsley                                                [Page 7]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  2.4.3.  General Responses
  
     The following is a list of general response codes that may be sent by
     the NNTP server.  These are not specific to any one command, but may
     be returned as the result of a connection, a failure, or some unusual
     condition.
  
     In general, 1xx codes may be ignored or displayed as desired;  code
     200 or 201 is sent upon initial connection to the NNTP server
     depending upon posting permission; code 400 will be sent when the
     NNTP server discontinues service (by operator request, for example);
     and 5xx codes indicate that the command could not be performed for
     some unusual reason.
  
        100 help text
        190
          through
        199 debug output
  
        200 server ready - posting allowed
        201 server ready - no posting allowed
  
        400 service discontinued
  
        500 command not recognized
        501 command syntax error
        502 access restriction or permission denied
        503 program fault - command not performed
  
  3.  Command and Response Details
  
     On the following pages are descriptions of each command recognized by
     the NNTP server and the responses which will be returned by those
     commands.
  
     Each command is shown in upper case for clarity, although case is
     ignored in the interpretation of commands by the NNTP server.  Any
     parameters are shown in lower case.  A parameter shown in [square
     brackets] is optional.  For example, [GMT] indicates that the
     triglyph GMT may present or omitted.
  
     Every command described in this section must be implemented by all
     NNTP servers.
  
  
  
  
  
  
  Kantor & Lapsley                                                [Page 8]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     There is no prohibition against additional commands being added;
     however, it is recommended that any such unspecified command begin
     with the letter "X" to avoid conflict with later revisions of this
     specification.
  
     Implementors are reminded that such additional commands may not
     redefine specified status response codes.  Using additional
     unspecified responses for standard commands is also prohibited.
  
  3.1.  The ARTICLE, BODY, HEAD, and STAT commands
  
     There are two forms to the ARTICLE command (and the related BODY,
     HEAD, and STAT commands), each using a different method of specifying
     which article is to be retrieved.  When the ARTICLE command is
     followed by a message-id in angle brackets ("<" and ">"), the first
     form of the command is used; when a numeric parameter or no parameter
     is supplied, the second form is invoked.
  
     The text of the article is returned as a textual response, as
     described earlier in this document.
  
     The HEAD and BODY commands are identical to the ARTICLE command
     except that they respectively return only the header lines or text
     body of the article.
  
     The STAT command is similar to the ARTICLE command except that no
     text is returned.  When selecting by message number within a group,
     the STAT command serves to set the current article pointer without
     sending text. The returned acknowledgement response will contain the
     message-id, which may be of some value.  Using the STAT command to
     select by message-id is valid but of questionable value, since a
     selection by message-id does NOT alter the "current article pointer".
  
  3.1.1.  ARTICLE (selection by message-id)
  
     ARTICLE <message-id>
  
     Display the header, a blank line, then the body (text) of the
     specified article.  Message-id is the message id of an article as
     shown in that article's header.  It is anticipated that the client
     will obtain the message-id from a list provided by the NEWNEWS
     command, from references contained within another article, or from
     the message-id provided in the response to some other commands.
  
     Please note that the internally-maintained "current article pointer"
     is NOT ALTERED by this command. This is both to facilitate the
     presentation of articles that may be referenced within an article
  
  
  Kantor & Lapsley                                                [Page 9]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     being read, and because of the semantic difficulties of determining
     the proper sequence and membership of an article which may have been
     posted to more than one newsgroup.
  
  3.1.2.  ARTICLE (selection by number)
  
     ARTICLE [nnn]
  
     Displays the header, a blank line, then the body (text) of the
     current or specified article.  The optional parameter nnn is the
  
     numeric id of an article in the current newsgroup and must be chosen
     from the range of articles provided when the newsgroup was selected.
     If it is omitted, the current article is assumed.
  
     The internally-maintained "current article pointer" is set by this
     command if a valid article number is specified.
  
     [the following applies to both forms of the article command.] A
     response indicating the current article number, a message-id string,
     and that text is to follow will be returned.
  
     The message-id string returned is an identification string contained
     within angle brackets ("<" and ">"), which is derived from the header
     of the article itself.  The Message-ID header line (required by
     RFC850) from the article must be used to supply this information. If
     the message-id header line is missing from the article, a single
     digit "0" (zero) should be supplied within the angle brackets.
  
     Since the message-id field is unique with each article, it may be
     used by a news reading program to skip duplicate displays of articles
     that have been posted more than once, or to more than one newsgroup.
  
  3.1.3.  Responses
  
     220 n <a> article retrieved - head and body follow
             (n = article number, <a> = message-id)
     221 n <a> article retrieved - head follows
     222 n <a> article retrieved - body follows
     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
  
  
  
  
  
  Kantor & Lapsley                                               [Page 10]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  3.2.  The GROUP command
  
  3.2.1.  GROUP
  
     GROUP ggg
  
     The required parameter ggg is the name of the newsgroup to be
     selected (e.g. "net.news").  A list of valid newsgroups may be
     obtained from the LIST command.
  
     The successful selection response will return the article numbers of
     the first and last articles in the group, and an estimate of the
     number of articles on file in the group.  It is not necessary that
     the estimate be correct, although that is helpful; it must only be
     equal to or larger than the actual number of articles on file.  (Some
     implementations will actually count the number of articles on file.
     Others will just subtract first article number from last to get an
     estimate.)
  
     When a valid group is selected by means of this command, the
     internally maintained "current article pointer" is set to the first
     article in the group.  If an invalid group is specified, the
     previously selected group and article remain selected.  If an empty
     newsgroup is selected, the "current article pointer" is in an
     indeterminate state and should not be used.
  
     Note that the name of the newsgroup is not case-dependent.  It must
     otherwise match a newsgroup obtained from the LIST command or an
     error will result.
  
  3.2.2.  Responses
  
     211 n f l s group selected
             (n = estimated number of articles in group,
             f = first article number in the group,
             l = last article number in the group,
             s = name of the group.)
     411 no such news group
  
  
  
  
  
  
  
  
  
  
  
  Kantor & Lapsley                                               [Page 11]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  3.3.  The HELP command
  
  3.3.1.  HELP
  
     HELP
  
     Provides a short summary of commands that are understood by this
     implementation of the server. The help text will be presented as a
     textual response, terminated by a single period on a line by itself.
  
     3.3.2.  Responses
  
     100 help text follows
  
  3.4.  The IHAVE command
  
  3.4.1.  IHAVE
  
     IHAVE <messageid>
  
     The IHAVE command informs the server that the client has an article
     whose id is <messageid>.  If the server desires a copy of that
     article, it will return a response instructing the client to send the
     entire article.  If the server does not want the article (if, for
     example, the server already has a copy of it), a response indicating
     that the article is not wanted will be returned.
  
     If transmission of the article is requested, the client should send
     the entire article, including header and body, in the manner
     specified for text transmission from the server. A response code
     indicating success or failure of the transferral of the article will
     be returned.
  
     This function differs from the POST command in that it is intended
     for use in transferring already-posted articles between hosts.
     Normally it will not be used when the client is a personal
     newsreading program.  In particular, this function will invoke the
     server's news posting program with the appropriate settings (flags,
     options, etc) to indicate that the forthcoming article is being
     forwarded from another host.
  
     The server may, however, elect not to post or forward the article if
     after further examination of the article it deems it inappropriate to
     do so.  The 436 or 437 error codes may be returned as appropriate to
     the situation.
  
     Reasons for such subsequent rejection of an article may include such
  
  
  Kantor & Lapsley                                               [Page 12]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     problems as inappropriate newsgroups or distributions, disk space
     limitations, article lengths, garbled headers, and the like.  These
     are typically restrictions enforced by the server host's news
     software and not necessarily the NNTP server itself.
  
  3.4.2.  Responses
  
     235 article transferred ok
     335 send article to be transferred.  End with <CR-LF>.<CR-LF>
     435 article not wanted - do not send it
     436 transfer failed - try again later
     437 article rejected - do not try again
  
     An implementation note:
  
     Because some host news posting software may not be able to decide
     immediately that an article is inappropriate for posting or
     forwarding, it is acceptable to acknowledge the successful transfer
     of the article and to later silently discard it.  Thus it is
     permitted to return the 235 acknowledgement code and later discard
     the received article.  This is not a fully satisfactory solution to
     the problem.  Perhaps some implementations will wish to send mail to
     the author of the article in certain of these cases.
  
  3.5.  The LAST command
  
  3.5.1.  LAST
  
     LAST
  
     The internally maintained "current article pointer" is set to the
     previous article in the current newsgroup.  If already positioned at
     the first article of the newsgroup, an error message is returned and
     the current article remains selected.
  
     The internally-maintained "current article pointer" is set by this
     command.
  
     A response indicating the current article number, and a message-id
     string will be returned.  No text is sent in response to this
     command.
  
  3.5.2.  Responses
  
     223 n a article retrieved - request text separately
             (n = article number, a = unique article id)
  
  
  
  Kantor & Lapsley                                               [Page 13]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     412 no newsgroup selected
     420 no current article has been selected
     422 no previous article in this group
  
  3.6.  The LIST command
  
  3.6.1.  LIST
  
     LIST
  
     Returns a list of valid newsgroups and associated information.  Each
     newsgroup is sent as a line of text in the following format:
  
        group last first p
  
     where <group> is the name of the newsgroup, <last> is the number of
     the last known article currently in that newsgroup, <first> is the
     number of the first article currently in the newsgroup, and <p> is
     either 'y' or 'n' indicating whether posting to this newsgroup is
     allowed ('y') or prohibited ('n').
  
     The <first> and <last> fields will always be numeric.  They may have
     leading zeros.  If the <last> field evaluates to less than the
     <first> field, there are no articles currently on file in the
     newsgroup.
  
     Note that posting may still be prohibited to a client even though the
     LIST command indicates that posting is permitted to a particular
     newsgroup. See the POST command for an explanation of client
     prohibitions.  The posting flag exists for each newsgroup because
     some newsgroups are moderated or are digests, and therefore cannot be
     posted to; that is, articles posted to them must be mailed to a
     moderator who will post them for the submitter.  This is independent
     of the posting permission granted to a client by the NNTP server.
  
     Please note that an empty list (i.e., the text body returned by this
     command consists only of the terminating period) is a possible valid
     response, and indicates that there are currently no valid newsgroups.
  
  3.6.2.  Responses
  
     215 list of newsgroups follows
  
  
  
  
  
  
  
  Kantor & Lapsley                                               [Page 14]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  3.7.  The NEWGROUPS command
  
  3.7.1.  NEWGROUPS
  
     NEWGROUPS date time [GMT] [<distributions>]
  
     A list of newsgroups created since <date and time> will be listed in
     the same format as the LIST command.
  
     The date is sent as 6 digits in the format YYMMDD, where YY is the
     last two digits of the year, MM is the two digits of the month (with
     leading zero, if appropriate), and DD is the day of the month (with
     leading zero, if appropriate).  The closest century is assumed as
     part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
     1999, 00 is 2000).
  
     Time must also be specified.  It must be as 6 digits HHMMSS with HH
     being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
     00-59.  The time is assumed to be in the server's timezone unless the
     token "GMT" appears, in which case both time and date are evaluated
     at the 0 meridian.
  
     The optional parameter "distributions" is a list of distribution
     groups, enclosed in angle brackets.  If specified, the distribution
     portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
     examined for a match with the distribution categories listed, and
     only those new newsgroups which match will be listed.  If more than
     one distribution group is to be listed, they must be separated by
     commas within the angle brackets.
  
     Please note that an empty list (i.e., the text body returned by this
     command consists only of the terminating period) is a possible valid
     response, and indicates that there are currently no new newsgroups.
  
  3.7.2.  Responses
  
     231 list of new newsgroups follows
  
  
  
  
  
  
  
  
  
  
  
  
  Kantor & Lapsley                                               [Page 15]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  3.8.  The NEWNEWS command
  
  3.8.1.  NEWNEWS
  
     NEWNEWS newsgroups date time [GMT] [<distribution>]
  
     A list of message-ids of articles posted or received to the specified
     newsgroup since "date" will be listed. The format of the listing will
     be one message-id per line, as though text were being sent.  A single
     line consisting solely of one period followed by CR-LF will terminate
     the list.
  
     Date and time are in the same format as the NEWGROUPS command.
  
     A newsgroup name containing a "*" (an asterisk) may be specified to
     broaden the article search to some or all newsgroups.  The asterisk
     will be extended to match any part of a newsgroup name (e.g.,
     net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
     if only an asterisk is given as the newsgroup name, all newsgroups
     will be searched for new news.
  
     (Please note that the asterisk "*" expansion is a general
     replacement; in particular, the specification of e.g., net.*.unix
     should be correctly expanded to embrace names such as net.wombat.unix
     and net.whocares.unix.)
  
     Conversely, if no asterisk appears in a given newsgroup name, only
     the specified newsgroup will be searched for new articles. Newsgroup
     names must be chosen from those returned in the listing of available
     groups.  Multiple newsgroup names (including a "*") may be specified
     in this command, separated by a comma.  No comma shall appear after
     the last newsgroup in the list.  [Implementors are cautioned to keep
     the 512 character command length limit in mind.]
  
     The exclamation point ("!") may be used to negate a match. This can
     be used to selectively omit certain newsgroups from an otherwise
     larger list.  For example, a newsgroups specification of
     "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
     all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
     matched.  If used, the exclamation point must appear as the first
     character of the given newsgroup name or pattern.
  
     The optional parameter "distributions" is a list of distribution
     groups, enclosed in angle brackets.  If specified, the distribution
     portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
     be examined for a match with the distribution categories listed, and
     only those articles which have at least one newsgroup belonging to
  
  
  Kantor & Lapsley                                               [Page 16]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     the list of distributions will be listed.  If more than one
     distribution group is to be supplied, they must be separated by
     commas within the angle brackets.
  
     The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
     news is discussed in an earlier part of this document.
  
     Please note that an empty list (i.e., the text body returned by this
     command consists only of the terminating period) is a possible valid
     response, and indicates that there is currently no new news.
  
  3.8.2.  Responses
  
     230 list of new articles by message-id follows
  
  3.9.  The NEXT command
  
  3.9.1.  NEXT
  
     NEXT
  
     The internally maintained "current article pointer" is advanced to
     the next article in the current newsgroup.  If no more articles
     remain in the current group, an error message is returned and the
     current article remains selected.
  
     The internally-maintained "current article pointer" is set by this
     command.
  
     A response indicating the current article number, and the message-id
     string will be returned.  No text is sent in response to this
     command.
  
  3.9.2.  Responses
  
     223 n a article retrieved - request text separately
             (n = article number, a = unique article id)
     412 no newsgroup selected
     420 no current article has been selected
     421 no next article in this group
  
  
  
  
  
  
  
  
  
  Kantor & Lapsley                                               [Page 17]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  3.10.  The POST command
  
  3.10.1.  POST
  
     POST
  
     If posting is allowed, response code 340 is returned to indicate that
     the article to be posted should be sent. Response code 440 indicates
     that posting is prohibited for some installation-dependent reason.
  
     If posting is permitted, the article should be presented in the
     format specified by RFC850, and should include all required header
     lines. After the article's header and body have been completely sent
     by the client to the server, a further response code will be returned
     to indicate success or failure of the posting attempt.
  
     The text forming the header and body of the message to be posted
     should be sent by the client using the conventions for text received
     from the news server:  A single period (".") on a line indicates the
     end of the text, with lines starting with a period in the original
     text having that period doubled during transmission.
  
     No attempt shall be made by the server to filter characters, fold or
     limit lines, or otherwise process incoming text.  It is our intent
     that the server just pass the incoming message to be posted to the
     server installation's news posting software, which is separate from
     this specification.  See RFC850 for more details.
  
     Since most installations will want the client news program to allow
     the user to prepare his message using some sort of text editor, and
     transmit it to the server for posting only after it is composed, the
     client program should take note of the herald message that greeted it
     when the connection was first established. This message indicates
     whether postings from that client are permitted or not, and can be
     used to caution the user that his access is read-only if that is the
     case. This will prevent the user from wasting a good deal of time
     composing a message only to find posting of the message was denied.
     The method and determination of which clients and hosts may post is
     installation dependent and is not covered by this specification.
  
  3.10.2.  Responses
  
     240 article posted ok
     340 send article to be posted. End with <CR-LF>.<CR-LF>
     440 posting not allowed
     441 posting failed
  
  
  
  Kantor & Lapsley                                               [Page 18]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     (for reference, one of the following codes will be sent upon initial
     connection; the client program should determine whether posting is
     generally permitted from these:) 200 server ready - posting allowed
     201 server ready - no posting allowed
  
  3.11.  The QUIT command
  
  3.11.1.  QUIT
  
     QUIT
  
     The server process acknowledges the QUIT command and then closes the
     connection to the client.  This is the preferred method for a client
     to indicate that it has finished all its transactions with the NNTP
     server.
  
     If a client simply disconnects (or the connection times out, or some
     other fault occurs), the server should gracefully cease its attempts
     to service the client.
  
  3.11.2.  Responses
  
     205 closing connection - goodbye!
  
  3.12.  The SLAVE command
  
  3.12.1.  SLAVE
  
     SLAVE
  
     Indicates to the server that this client connection is to a slave
     server, rather than a user.
  
     This command is intended for use in separating connections to single
     users from those to subsidiary ("slave") servers.  It may be used to
     indicate that priority should therefore be given to requests from
     this client, as it is presumably serving more than one person.  It
     might also be used to determine which connections to close when
     system load levels are exceeded, perhaps giving preference to slave
     servers.  The actual use this command is put to is entirely
     implementation dependent, and may vary from one host to another.  In
     NNTP servers which do not give priority to slave servers, this
     command must nonetheless be recognized and acknowledged.
  
  3.12.2.  Responses
  
     202 slave status noted
  
  
  Kantor & Lapsley                                               [Page 19]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  4.  Sample Conversations
  
     These are samples of the conversations that might be expected with
     the news server in hypothetical sessions.  The notation C: indicates
     commands sent to the news server from the client program; S: indicate
     responses received from the server by the client.
  
  4.1.  Example 1 - relative access with NEXT
  
     S:      (listens at TCP port 119)
  
     C:      (requests connection on TCP port 119)
     S:      200 wombatvax news server ready - posting ok
  
     (client asks for a current newsgroup list)
     C:      LIST
     S:      215 list of newsgroups follows
     S:      net.wombats 00543 00501 y
     S:      net.unix-wizards 10125 10011 y
             (more information here)
     S:      net.idiots 00100 00001 n
     S:      .
  
     (client selects a newsgroup)
     C:      GROUP net.unix-wizards
     S:      211 104 10011 10125 net.unix-wizards group selected
             (there are 104 articles on file, from 10011 to 10125)
  
     (client selects an article to read)
     C:      STAT 10110
     S:      223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
             only (article 10110 selected, its message-id is
             <23445@sdcsvax.ARPA>)
  
     (client examines the header)
     C:      HEAD
     S:      221 10110 <23445@sdcsvax.ARPA> article retrieved - head
             follows (text of the header appears here)
     S:      .
  
     (client wants to see the text body of the article)
     C:      BODY
     S:      222 10110 <23445@sdcsvax.ARPA> article retrieved - body
             follows (body text here)
     S:      .
  
     (client selects next article in group)
  
  
  Kantor & Lapsley                                               [Page 20]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     C:      NEXT
     S:      223 10113 <21495@nudebch.uucp> article retrieved - statistics
             only (article 10113 was next in group)
  
     (client finishes session)
     C:      QUIT
     S:      205 goodbye.
  
  4.2.  Example 2 - absolute article access with ARTICLE
  
     S:      (listens at TCP port 119)
  
     C:      (requests connection on TCP port 119)
     S:      201 UCB-VAX netnews server ready -- no posting allowed
  
     C:      GROUP msgs
     S:      211 103 402 504 msgs Your new group is msgs
             (there are 103 articles, from 402 to 504)
  
     C:      ARTICLE 401
     S:      423 No such article in this newsgroup
  
     C:      ARTICLE 402
     S:      220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
     S:      (article header and body follow)
     S:      .
  
     C:      HEAD 403
     S:      221 403 <3108@mcvax.UUCP> Article retrieved, header follows
     S:      (article header follows)
     S:      .
  
     C:      QUIT
     S:      205 UCB-VAX news server closing connection.  Goodbye.
  
  4.3.  Example 3 - NEWGROUPS command
  
     S:      (listens at TCP port 119)
  
     C:      (requests connection on TCP port 119)
     S:      200 Imaginary Institute News Server ready (posting ok)
  
     (client asks for new newsgroups since April 3, 1985)
     C:      NEWGROUPS 850403 020000
  
     S:      231 New newsgroups since 03/04/85 02:00:00 follow
  
  
  
  Kantor & Lapsley                                               [Page 21]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     S:      net.music.gdead
     S:      net.games.sources
     S:      .
  
     C:      GROUP net.music.gdead
     S:      211 0 1 1 net.music.gdead Newsgroup selected
             (there are no articles in that newsgroup, and
             the first and last article numbers should be ignored)
  
     C:      QUIT
     S:      205 Imaginary Institute news server ceasing service.  Bye!
  
  4.4.  Example 4 - posting a news article
  
     S:      (listens at TCP port 119)
  
     C:      (requests connection on TCP port 119)
     S:      200 BANZAIVAX news server ready, posting allowed.
  
     C:      POST
     S:      340 Continue posting; Period on a line by itself to end
     C:      (transmits news article in RFC850 format)
     C:      .
     S:      240 Article posted successfully.
  
     C:      QUIT
     S:      205 BANZAIVAX closing connection.  Goodbye.
  
  4.5.  Example 5 - interruption due to operator request
  
     S:      (listens at TCP port 119)
  
     C:      (requests connection on TCP port 119)
     S:      201 genericvax news server ready, no posting allowed.
  
             (assume normal conversation for some time, and
             that a newsgroup has been selected)
  
     C:      NEXT
     S:      223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
  
     C:      HEAD
     C:      221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
  
     S:      (sends head of article, but halfway through is
             interrupted by an operator request.  The following
             then occurs, without client intervention.)
  
  
  Kantor & Lapsley                                               [Page 22]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     S:      (ends current line with a CR-LF pair)
     S:      .
     S:      400 Connection closed by operator.  Goodbye.
     S:      (closes connection)
  
  4.6.  Example 6 - Using the news server to distribute news between
        systems.
  
     S:      (listens at TCP port 119)
  
     C:      (requests connection on TCP port 119)
     S:      201 Foobar NNTP server ready (no posting)
  
     (client asks for new newsgroups since 2 am, May 15, 1985)
     C:      NEWGROUPS 850515 020000
     S:      235 New newsgroups since 850515 follow
     S:      net.fluff
     S:      net.lint
     S:      .
  
     (client asks for new news articles since 2 am, May 15, 1985)
     C:      NEWNEWS * 850515 020000
     S:      230 New news since 850515 020000 follows
     S:      <1772@foo.UUCP>
     S:      <87623@baz.UUCP>
     S:      <17872@GOLD.CSNET>
     S:      .
  
     (client asks for article <1772@foo.UUCP>)
     C:      ARTICLE <1772@foo.UUCP>
     S:      220 <1772@foo.UUCP> All of article follows
     S:      (sends entire message)
     S:      .
  
     (client asks for article <87623@baz.UUCP>
     C:      ARTICLE <87623@baz.UUCP>
     S:      220 <87623@baz.UUCP> All of article follows
     S:      (sends entire message)
     S:      .
  
     (client asks for article <17872@GOLD.CSNET>
     C:      ARTICLE <17872@GOLD.CSNET>
     S:      220 <17872@GOLD.CSNET> All of article follows
     S:      (sends entire message)
     S:      .
  
  
  
  
  Kantor & Lapsley                                               [Page 23]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     (client offers an article it has received recently)
     C:      IHAVE <4105@ucbvax.ARPA>
     S:      435 Already seen that one, where you been?
  
     (client offers another article)
     C:      IHAVE <4106@ucbvax.ARPA>
     S:      335 News to me!  <CRLF.CRLF> to end.
     C:      (sends article)
     C:      .
     S:      235 Article transferred successfully.  Thanks.
  
     (or)
  
     S:      436 Transfer failed.
  
     (client is all through with the session)
     C:      QUIT
     S:      205 Foobar NNTP server bids you farewell.
  
  4.7.  Summary of commands and responses.
  
     The following are the commands recognized and responses returned by
     the NNTP server.
  
  4.7.1.  Commands
  
     ARTICLE
     BODY
     GROUP
     HEAD
     HELP
     IHAVE
     LAST
     LIST
     NEWGROUPS
     NEWNEWS
     NEXT
     POST
     QUIT
     SLAVE
     STAT
  
  4.7.2.  Responses
  
     100 help text follows
     199 debug output
  
  
  
  Kantor & Lapsley                                               [Page 24]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     200 server ready - posting allowed
     201 server ready - no posting allowed
     202 slave status noted
     205 closing connection - goodbye!
     211 n f l s group selected
     215 list of newsgroups follows
     220 n <a> article retrieved - head and body follow 221 n <a> article
     retrieved - head follows
     222 n <a> article retrieved - body follows
     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
  
     335 send article to be transferred.  End with <CR-LF>.<CR-LF>
     340 send article to be posted. End with <CR-LF>.<CR-LF>
  
     400 service discontinued
     411 no such news group
     412 no newsgroup has been selected
     420 no current article has been selected
     421 no next article in this group
     422 no previous article in this group
     423 no such article number in this group
     430 no such article found
     435 article not wanted - do not send it
     436 transfer failed - try again later
     437 article rejected - do not try again.
     440 posting not allowed
     441 posting failed
  
     500 command not recognized
     501 command syntax error
     502 access restriction or permission denied
     503 program fault - command not performed
  
  4.8.  A Brief Word about the USENET News System
  
     In the UNIX world, which traditionally has been linked by 1200 baud
     dial-up telephone lines, the USENET News system has evolved to handle
     central storage, indexing, retrieval, and distribution of news.  With
     the exception of its underlying transport mechanism (UUCP), USENET
     News is an efficient means of providing news and bulletin service to
     subscribers on UNIX and other hosts worldwide.  The USENET News
  
  
  
  
  Kantor & Lapsley                                               [Page 25]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
     system is discussed in detail in RFC 850.  It runs on most versions
     of UNIX and on many other operating systems, and is customarily
     distributed without charge.
  
     USENET uses a spooling area on the UNIX host to store news articles,
     one per file. Each article consists of a series of heading text,
     which contain the sender's identification and organizational
     affiliation, timestamps, electronic mail reply paths, subject,
     newsgroup (subject category), and the like.  A complete news article
     is reproduced in its entirety below.  Please consult RFC 850 for more
     details.
  
        Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
        sdcsvax.UUCP
        Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
        Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
        !honman
        From: honman@unitek.uucp (Man Wong)
        Newsgroups: net.unix-wizards
        Subject: foreground -> background ?
        Message-ID: <167@unitek.uucp>
        Date: 25 Sep 85 23:51:52 GMT
        Date-Received: 29 Sep 85 09:54:48 GMT
        Reply-To: honman@unitek.UUCP (Hon-Man Wong)
        Distribution: net.all
        Organization: Unitek Technologies Corporation
        Lines: 12
  
        I have a process (C program) which generates a child and waits for
        it to return.  What I would like to do is to be able to run the
        child process interactively for a while before kicking itself into
        the background so I can return to the parent process (while the
        child process is RUNNING in the background).  Can it be done?  And
        if it can, how?
  
        Please reply by E-mail.  Thanks in advance.
  
        Hon-Man Wong
  
  
  
  
  
  
  
  
  
  
  
  Kantor & Lapsley                                               [Page 26]
  
  
  
  RFC 977                                                    February 1986
  Network News Transfer Protocol
  
  
  5.  References
  
     [1]  Crocker, D., "Standard for the Format of ARPA Internet Text
          Messages", RFC-822, Department of Electrical Engineering,
          University of Delaware, August, 1982.
  
     [2]  Horton, M., "Standard for Interchange of USENET Messages",
          RFC-850, USENET Project, June, 1983.
  
     [3]  Postel, J., "Transmission Control Protocol- DARPA Internet
          Program Protocol Specification", RFC-793, USC/Information
          Sciences Institute, September, 1981.
  
     [4]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,
          USC/Information Sciences Institute, August, 1982.
  
  6.  Acknowledgements
  
     The authors wish to express their heartfelt thanks to those many
     people who contributed to this specification, and especially to Erik
     Fair and Chuq von Rospach, without whose inspiration this whole thing
     would not have been necessary.
  
  7.  Notes
  
     <1> UNIX is a trademark of Bell Laboratories.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Kantor & Lapsley                                               [Page 27]
  
  
  
  
  
  
  1.1                  jakarta-james/docs/rfclist/rfc822.txt
  
  Index: rfc822.txt
  ===================================================================
   
  
  
  
  
       RFC #  822
  
       Obsoletes:  RFC #733  (NIC #41952)
  
  
  
  
  
  
  
  
  
  
  
  
                          STANDARD FOR THE FORMAT OF
  
                          ARPA INTERNET TEXT MESSAGES
  
  
  
  
  
  
                                August 13, 1982
  
  
  
  
  
  
                                  Revised by
  
                               David H. Crocker
  
  
                        Dept. of Electrical Engineering
                   University of Delaware, Newark, DE  19711
                        Network:  DCrocker @ UDel-Relay
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   
       Standard for ARPA Internet Text Messages
  
  
                               TABLE OF CONTENTS
  
  
       PREFACE ....................................................   ii
  
       1.  INTRODUCTION ...........................................    1
  
           1.1.  Scope ............................................    1
           1.2.  Communication Framework ..........................    2
  
       2.  NOTATIONAL CONVENTIONS .................................    3
  
       3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
  
           3.1.  General Description ..............................    5
           3.2.  Header Field Definitions .........................    9
           3.3.  Lexical Tokens ...................................   10
           3.4.  Clarifications ...................................   11
  
       4.  MESSAGE SPECIFICATION ..................................   17
  
           4.1.  Syntax ...........................................   17
           4.2.  Forwarding .......................................   19
           4.3.  Trace Fields .....................................   20
           4.4.  Originator Fields ................................   21
           4.5.  Receiver Fields ..................................   23
           4.6.  Reference Fields .................................   23
           4.7.  Other Fields .....................................   24
  
       5.  DATE AND TIME SPECIFICATION ............................   26
  
           5.1.  Syntax ...........................................   26
           5.2.  Semantics ........................................   26
  
       6.  ADDRESS SPECIFICATION ..................................   27
  
           6.1.  Syntax ...........................................   27
           6.2.  Semantics ........................................   27
           6.3.  Reserved Address .................................   33
  
       7.  BIBLIOGRAPHY ...........................................   34
  
  
                               APPENDIX
  
       A.  EXAMPLES ...............................................   36
       B.  SIMPLE FIELD PARSING ...................................   40
       C.  DIFFERENCES FROM RFC #733 ..............................   41
       D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
  
  
       August 13, 1982               - i -                      RFC #822
  
  
  
   
       Standard for ARPA Internet Text Messages
  
  
                                    PREFACE
  
  
            By 1977, the Arpanet employed several informal standards for
       the  text  messages (mail) sent among its host computers.  It was
       felt necessary to codify these practices and  provide  for  those
       features  that  seemed  imminent.   The result of that effort was
       Request for Comments (RFC) #733, "Standard for the Format of ARPA
       Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
       The specification attempted to avoid major  changes  in  existing
       software, while permitting several new features.
  
            This document revises the specifications  in  RFC  #733,  in
       order  to  serve  the  needs  of the larger and more complex ARPA
       Internet.  Some of RFC #733's features failed  to  gain  adequate
       acceptance.   In  order to simplify the standard and the software
       that follows it, these features have been removed.   A  different
       addressing  scheme  is  used, to handle the case of inter-network
       mail; and the concept of re-transmission has been introduced.
  
            This specification is intended for use in the ARPA Internet.
       However, an attempt has been made to free it of any dependence on
       that environment, so that it can be applied to other network text
       message systems.
  
            The specification of RFC #733 took place over the course  of
       one  year, using the ARPANET mail environment, itself, to provide
       an on-going forum for discussing the capabilities to be included.
       More  than  twenty individuals, from across the country, partici-
       pated in  the  original  discussion.   The  development  of  this
       revised specification has, similarly, utilized network mail-based
       group discussion.  Both specification efforts  greatly  benefited
       from the comments and ideas of the participants.
  
            The syntax of the standard,  in  RFC  #733,  was  originally
       specified  in  the  Backus-Naur Form (BNF) meta-language.  Ken L.
       Harrenstien, of SRI International, was responsible for  re-coding
       the  BNF  into  an  augmented  BNF  that makes the representation
       smaller and easier to understand.
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - ii -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       1.  INTRODUCTION
  
       1.1.  SCOPE
  
            This standard specifies a syntax for text messages that  are
       sent  among  computer  users, within the framework of "electronic
       mail".  The standard supersedes  the  one  specified  in  ARPANET
       Request  for Comments #733, "Standard for the Format of ARPA Net-
       work Text Messages".
  
            In this context, messages are viewed as having  an  envelope
       and  contents.   The  envelope  contains  whatever information is
       needed to accomplish transmission  and  delivery.   The  contents
       compose  the object to be delivered to the recipient.  This stan-
       dard applies only to the format and some of the semantics of mes-
       sage  contents.   It contains no specification of the information
       in the envelope.
  
            However, some message systems may use information  from  the
       contents  to create the envelope.  It is intended that this stan-
       dard facilitate the acquisition of such information by programs.
  
            Some message systems may  store  messages  in  formats  that
       differ  from the one specified in this standard.  This specifica-
       tion is intended strictly as a definition of what message content
       format is to be passed BETWEEN hosts.
  
       Note:  This standard is NOT intended to dictate the internal for-
              mats  used  by sites, the specific message system features
              that they are expected to support, or any of  the  charac-
              teristics  of  user interface programs that create or read
              messages.
  
            A distinction should be made between what the  specification
       REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
       rich with formally-structured components of information or can be
       kept small and simple, with a minimum of such information.  Also,
       the standard simplifies the interpretation  of  differing  visual
       formats  in  messages;  only  the  visual  aspect of a message is
       affected and not the interpretation  of  information  within  it.
       Implementors may choose to retain such visual distinctions.
  
            The formal definition is divided into four levels.  The bot-
       tom level describes the meta-notation used in this document.  The
       second level describes basic lexical analyzers that  feed  tokens
       to  higher-level  parsers.   Next is an overall specification for
       messages; it permits distinguishing individual fields.   Finally,
       there is definition of the contents of several structured fields.
  
  
  
       August 13, 1982               - 1 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       1.2.  COMMUNICATION FRAMEWORK
  
            Messages consist of lines of text.   No  special  provisions
       are  made for encoding drawings, facsimile, speech, or structured
       text.  No significant consideration has been given  to  questions
       of  data  compression  or to transmission and storage efficiency,
       and the standard tends to be free with the number  of  bits  con-
       sumed.   For  example,  field  names  are specified as free text,
       rather than special terse codes.
  
            A general "memo" framework is used.  That is, a message con-
       sists of some information in a rigid format, followed by the main
       part of the message, with a format that is not specified in  this
       document.   The  syntax of several fields of the rigidly-formated
       ("headers") section is defined in  this  specification;  some  of
       these fields must be included in all messages.
  
            The syntax  that  distinguishes  between  header  fields  is
       specified  separately  from  the  internal  syntax for particular
       fields.  This separation is intended to allow simple  parsers  to
       operate on the general structure of messages, without concern for
       the detailed structure of individual header fields.   Appendix  B
       is provided to facilitate construction of these parsers.
  
            In addition to the fields specified in this document, it  is
       expected  that  other fields will gain common use.  As necessary,
       the specifications for these "extension-fields" will be published
       through  the same mechanism used to publish this document.  Users
       may also  wish  to  extend  the  set  of  fields  that  they  use
       privately.  Such "user-defined fields" are permitted.
  
            The framework severely constrains document tone and  appear-
       ance and is primarily useful for most intra-organization communi-
       cations and  well-structured   inter-organization  communication.
       It  also  can  be used for some types of inter-process communica-
       tion, such as simple file transfer and remote job entry.  A  more
       robust  framework might allow for multi-font, multi-color, multi-
       dimension encoding of information.  A  less  robust  one,  as  is
       present  in  most  single-machine  message  systems,  would  more
       severely constrain the ability to add fields and the decision  to
       include specific fields.  In contrast with paper-based communica-
       tion, it is interesting to note that the RECEIVER  of  a  message
       can   exercise  an  extraordinary  amount  of  control  over  the
       message's appearance.  The amount of actual control available  to
       message  receivers  is  contingent upon the capabilities of their
       individual message systems.
  
  
  
  
  
       August 13, 1982               - 2 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       2.  NOTATIONAL CONVENTIONS
  
            This specification uses an augmented Backus-Naur Form  (BNF)
       notation.  The differences from standard BNF involve naming rules
       and indicating repetition and "local" alternatives.
  
       2.1.  RULE NAMING
  
            Angle brackets ("<", ">") are not  used,  in  general.   The
       name  of  a rule is simply the name itself, rather than "<name>".
       Quotation-marks enclose literal text (which may be  upper  and/or
       lower  case).   Certain  basic  rules  are  in uppercase, such as
       SPACE, TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used  in
       rule  definitions,  and  in  the rest of this  document, whenever
       their presence will facilitate discerning the use of rule names.
  
       2.2.  RULE1 / RULE2:  ALTERNATIVES
  
            Elements separated by slash ("/") are alternatives.   There-
       fore "foo / bar" will accept foo or bar.
  
       2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
  
            Elements enclosed in parentheses are  treated  as  a  single
       element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
       sequences "elem foo elem" and "elem bar elem".
  
       2.4.  *RULE:  REPETITION
  
            The character "*" preceding an element indicates repetition.
       The full form is:
  
                                <l>*<m>element
  
       indicating at least <l> and at most <m> occurrences  of  element.
       Default values are 0 and infinity so that "*(element)" allows any
       number, including zero; "1*element" requires at  least  one;  and
       "1*2element" allows one or two.
  
       2.5.  [RULE]:  OPTIONAL
  
            Square brackets enclose optional elements; "[foo  bar]"   is
       equivalent to "*1(foo bar)".
  
       2.6.  NRULE:  SPECIFIC REPETITION
  
            "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
       exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
       number, and 3ALPHA is a string of three alphabetic characters.
  
  
       August 13, 1982               - 3 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       2.7.  #RULE:  LISTS
  
            A construct "#" is defined, similar to "*", as follows:
  
                                <l>#<m>element
  
       indicating at least <l> and at most <m> elements, each  separated
       by  one  or more commas (","). This makes the usual form of lists
       very easy; a rule such as '(element *("," element))' can be shown
       as  "1#element".   Wherever this construct is used, null elements
       are allowed, but do not  contribute  to  the  count  of  elements
       present.   That  is,  "(element),,(element)"  is  permitted,  but
       counts as only two elements.  Therefore, where at least one  ele-
       ment  is required, at least one non-null element must be present.
       Default values are 0 and infinity so that "#(element)" allows any
       number,  including  zero;  "1#element" requires at least one; and
       "1#2element" allows one or two.
  
       2.8.  ; COMMENTS
  
            A semi-colon, set off some distance to  the  right  of  rule
       text,  starts  a comment that continues to the end of line.  This
       is a simple way of including useful notes in  parallel  with  the
       specifications.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982               - 4 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       3.  LEXICAL ANALYSIS OF MESSAGES
  
       3.1.  GENERAL DESCRIPTION
  
            A message consists of header fields and, optionally, a body.
       The  body  is simply a sequence of lines containing ASCII charac-
       ters.  It is separated from the headers by a null line  (i.e.,  a
       line with nothing preceding the CRLF).
  
       3.1.1.  LONG HEADER FIELDS
  
          Each header field can be viewed as a single, logical  line  of
          ASCII  characters,  comprising  a field-name and a field-body.
          For convenience, the field-body  portion  of  this  conceptual
          entity  can be split into a multiple-line representation; this
          is called "folding".  The general rule is that wherever  there
          may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
          immediately followed by AT LEAST one LWSP-char may instead  be
          inserted.  Thus, the single line
  
              To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
  
          can be represented as:
  
              To:  "Joe & J. Harvey" <ddd @ Org>,
                      JJV@BBN
  
          and
  
              To:  "Joe & J. Harvey"
                              <ddd@ Org>, JJV
               @BBN
  
          and
  
              To:  "Joe &
               J. Harvey" <ddd @ Org>, JJV @ BBN
  
               The process of moving  from  this  folded   multiple-line
          representation  of a header field to its single line represen-
          tation is called "unfolding".  Unfolding  is  accomplished  by
          regarding   CRLF   immediately  followed  by  a  LWSP-char  as
          equivalent to the LWSP-char.
  
          Note:  While the standard  permits  folding  wherever  linear-
                 white-space is permitted, it is recommended that struc-
                 tured fields, such as those containing addresses, limit
                 folding  to higher-level syntactic breaks.  For address
                 fields, it  is  recommended  that  such  folding  occur
  
  
       August 13, 1982               - 5 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
                 between addresses, after the separating comma.
  
       3.1.2.  STRUCTURE OF HEADER FIELDS
  
          Once a field has been unfolded, it may be viewed as being com-
          posed of a field-name followed by a colon (":"), followed by a
          field-body, and  terminated  by  a  carriage-return/line-feed.
          The  field-name must be composed of printable ASCII characters
          (i.e., characters that  have  values  between  33.  and  126.,
          decimal, except colon).  The field-body may be composed of any
          ASCII characters, except CR or LF.  (While CR and/or LF may be
          present  in the actual text, they are removed by the action of
          unfolding the field.)
  
          Certain field-bodies of headers may be  interpreted  according
          to  an  internal  syntax  that some systems may wish to parse.
          These  fields  are  called  "structured   fields".    Examples
          include  fields containing dates and addresses.  Other fields,
          such as "Subject"  and  "Comments",  are  regarded  simply  as
          strings of text.
  
          Note:  Any field which has a field-body  that  is  defined  as
                 other  than  simply <text> is to be treated as a struc-
                 tured field.
  
                 Field-names, unstructured field bodies  and  structured
                 field bodies each are scanned by their own, independent
                 "lexical" analyzers.
  
       3.1.3.  UNSTRUCTURED FIELD BODIES
  
          For some fields, such as "Subject" and "Comments",  no  struc-
          turing  is assumed, and they are treated simply as <text>s, as
          in the message body.  Rules of folding apply to these  fields,
          so  that  such  field  bodies  which occupy several lines must
          therefore have the second and successive lines indented by  at
          least one LWSP-char.
  
       3.1.4.  STRUCTURED FIELD BODIES
  
          To aid in the creation and reading of structured  fields,  the
          free  insertion   of linear-white-space (which permits folding
          by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
          Rather  than  obscuring  the  syntax  specifications for these
          structured fields with explicit syntax for this  linear-white-
          space, the existence of another "lexical" analyzer is assumed.
          This analyzer does not apply  for  unstructured  field  bodies
          that  are  simply  strings  of  text, as described above.  The
          analyzer provides  an  interpretation  of  the  unfolded  text
  
  
       August 13, 1982               - 6 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          composing  the body of the field as a sequence of lexical sym-
          bols.
  
          These symbols are:
  
                       -  individual special characters
                       -  quoted-strings
                       -  domain-literals
                       -  comments
                       -  atoms
  
          The first four of these symbols  are  self-delimiting.   Atoms
          are not; they are delimited by the self-delimiting symbols and
          by  linear-white-space.   For  the  purposes  of  regenerating
          sequences  of  atoms  and quoted-strings, exactly one SPACE is
          assumed to exist, and should be used, between them.  (Also, in
          the "Clarifications" section on "White Space", below, note the
          rules about treatment of multiple contiguous LWSP-chars.)
  
          So, for example, the folded body of an address field
  
              ":sysmail"@  Some-Group. Some-Org,
              Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982               - 7 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          is analyzed into the following lexical symbols and types:
  
                      :sysmail              quoted string
                      @                     special
                      Some-Group            atom
                      .                     special
                      Some-Org              atom
                      ,                     special
                      Muhammed              atom
                      .                     special
                      (I am  the greatest)  comment
                      Ali                   atom
                      @                     atom
                      (the)                 comment
                      Vegas                 atom
                      .                     special
                      WBA                   atom
  
          The canonical representations for the data in these  addresses
          are the following strings:
  
                          ":sysmail"@Some-Group.Some-Org
  
          and
  
                              Muhammed.Ali@Vegas.WBA
  
          Note:  For purposes of display, and when passing  such  struc-
                 tured information to other systems, such as mail proto-
                 col  services,  there  must  be  NO  linear-white-space
                 between  <word>s  that are separated by period (".") or
                 at-sign ("@") and exactly one SPACE between  all  other
                 <word>s.  Also, headers should be in a folded form.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982               - 8 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       3.2.  HEADER FIELD DEFINITIONS
  
            These rules show a field meta-syntax, without regard for the
       particular  type  or internal syntax.  Their purpose is to permit
       detection of fields; also, they present to  higher-level  parsers
       an image of each field as fitting on one line.
  
       field       =  field-name ":" [ field-body ] CRLF
  
       field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
  
       field-body  =  field-body-contents
                      [CRLF LWSP-char field-body]
  
       field-body-contents =
                     <the ASCII characters making up the field-body, as
                      defined in the following sections, and consisting
                      of combinations of atom, quoted-string, and
                      specials tokens, or else consisting of texts>
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982               - 9 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       3.3.  LEXICAL TOKENS
  
            The following rules are used to define an underlying lexical
       analyzer,  which  feeds  tokens to higher level parsers.  See the
       ANSI references, in the Bibliography.
  
                                                   ; (  Octal, Decimal.)
       CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
       ALPHA       =  <any ASCII alphabetic character>
                                                   ; (101-132, 65.- 90.)
                                                   ; (141-172, 97.-122.)
       DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
       CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
                       character and DEL>          ; (    177,     127.)
       CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
       LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
       SPACE       =  <ASCII SP, space>            ; (     40,      32.)
       HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
       <">         =  <ASCII quote mark>           ; (     42,      34.)
       CRLF        =  CR LF
  
       LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
  
       linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
                                                   ; CRLF => folding
  
       specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
                   /  "," / ";" / ":" / "\" / <">  ;  string, to use
                   /  "." / "[" / "]"              ;  within a word.
  
       delimiters  =  specials / linear-white-space / comment
  
       text        =  <any CHAR, including bare    ; => atoms, specials,
                       CR & bare LF, but NOT       ;  comments and
                       including CRLF>             ;  quoted-strings are
                                                   ;  NOT recognized.
  
       atom        =  1*<any CHAR except specials, SPACE and CTLs>
  
       quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                   ;   quoted chars.
  
       qtext       =  <any CHAR excepting <">,     ; => may be folded
                       "\" & CR, and including
                       linear-white-space>
  
       domain-literal =  "[" *(dtext / quoted-pair) "]"
  
  
  
  
       August 13, 1982              - 10 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       dtext       =  <any CHAR excluding "[",     ; => may be folded
                       "]", "\" & CR, & including
                       linear-white-space>
  
       comment     =  "(" *(ctext / quoted-pair / comment) ")"
  
       ctext       =  <any CHAR excluding "(",     ; => may be folded
                       ")", "\" & CR, & including
                       linear-white-space>
  
       quoted-pair =  "\" CHAR                     ; may quote any char
  
       phrase      =  1*word                       ; Sequence of words
  
       word        =  atom / quoted-string
  
  
       3.4.  CLARIFICATIONS
  
       3.4.1.  QUOTING
  
          Some characters are reserved for special interpretation,  such
          as  delimiting lexical tokens.  To permit use of these charac-
          ters as uninterpreted data, a quoting mechanism  is  provided.
          To quote a character, precede it with a backslash ("\").
  
          This mechanism is not fully general.  Characters may be quoted
          only  within  a subset of the lexical constructs.  In particu-
          lar, quoting is limited to use within:
  
                               -  quoted-string
                               -  domain-literal
                               -  comment
  
          Within these constructs, quoting is REQUIRED for  CR  and  "\"
          and for the character(s) that delimit the token (e.g., "(" and
          ")" for a comment).  However, quoting  is  PERMITTED  for  any
          character.
  
          Note:  In particular, quoting is NOT permitted  within  atoms.
                 For  example  when  the local-part of an addr-spec must
                 contain a special character, a quoted  string  must  be
                 used.  Therefore, a specification such as:
  
                              Full\ Name@Domain
  
                 is not legal and must be specified as:
  
                              "Full Name"@Domain
  
  
       August 13, 1982              - 11 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       3.4.2.  WHITE SPACE
  
          Note:  In structured field bodies, multiple linear space ASCII
                 characters  (namely  HTABs  and  SPACEs) are treated as
                 single spaces and may freely surround any  symbol.   In
                 all header fields, the only place in which at least one
                 LWSP-char is REQUIRED is at the beginning of  continua-
                 tion lines in a folded field.
  
          When passing text to processes  that  do  not  interpret  text
          according to this standard (e.g., mail protocol servers), then
          NO linear-white-space characters should occur between a period
          (".") or at-sign ("@") and a <word>.  Exactly ONE SPACE should
          be used in place of arbitrary linear-white-space  and  comment
          sequences.
  
          Note:  Within systems conforming to this standard, wherever  a
                 member of the list of delimiters is allowed, LWSP-chars
                 may also occur before and/or after it.
  
          Writers of  mail-sending  (i.e.,  header-generating)  programs
          should realize that there is no network-wide definition of the
          effect of ASCII HT (horizontal-tab) characters on the  appear-
          ance  of  text  at another network host; therefore, the use of
          tabs in message headers, though permitted, is discouraged.
  
       3.4.3.  COMMENTS
  
          A comment is a set of ASCII characters, which is  enclosed  in
          matching  parentheses  and which is not within a quoted-string
          The comment construct permits message originators to add  text
          which  will  be  useful  for  human readers, but which will be
          ignored by the formal semantics.  Comments should be  retained
          while  the  message  is subject to interpretation according to
          this standard.  However, comments  must  NOT  be  included  in
          other  cases,  such  as  during  protocol  exchanges with mail
          servers.
  
          Comments nest, so that if an unquoted left parenthesis  occurs
          in  a  comment  string,  there  must  also be a matching right
          parenthesis.  When a comment acts as the delimiter  between  a
          sequence of two lexical symbols, such as two atoms, it is lex-
          ically equivalent with a single SPACE,  for  the  purposes  of
          regenerating  the  sequence, such as when passing the sequence
          onto a mail protocol server.  Comments are  detected  as  such
          only within field-bodies of structured fields.
  
          If a comment is to be "folded" onto multiple lines,  then  the
          syntax  for  folding  must  be  adhered to.  (See the "Lexical
  
  
       August 13, 1982              - 12 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          Analysis of Messages" section on "Folding Long Header  Fields"
          above,  and  the  section on "Case Independence" below.)  Note
          that  the  official  semantics  therefore  do  not  "see"  any
          unquoted CRLFs that are in comments, although particular pars-
          ing programs may wish to note their presence.  For these  pro-
          grams,  it would be reasonable to interpret a "CRLF LWSP-char"
          as being a CRLF that is part of the comment; i.e., the CRLF is
          kept  and  the  LWSP-char is discarded.  Quoted CRLFs (i.e., a
          backslash followed by a CR followed by a  LF)  still  must  be
          followed by at least one LWSP-char.
  
       3.4.4.  DELIMITING AND QUOTING CHARACTERS
  
          The quote character (backslash) and  characters  that  delimit
          syntactic  units  are not, generally, to be taken as data that
          are part of the delimited or quoted unit(s).   In  particular,
          the   quotation-marks   that   define   a  quoted-string,  the
          parentheses that define  a  comment  and  the  backslash  that
          quotes  a  following  character  are  NOT  part of the quoted-
          string, comment or quoted character.  A quotation-mark that is
          to  be  part  of  a quoted-string, a parenthesis that is to be
          part of a comment and a backslash that is to be part of either
          must  each be preceded by the quote-character backslash ("\").
          Note that the syntax allows any character to be quoted  within
          a  quoted-string  or  comment; however only certain characters
          MUST be quoted to be included as data.  These  characters  are
          the  ones that are not part of the alternate text group (i.e.,
          ctext or qtext).
  
          The one exception to this rule  is  that  a  single  SPACE  is
          assumed  to  exist  between  contiguous words in a phrase, and
          this interpretation is independent of  the  actual  number  of
          LWSP-chars  that  the  creator  places  between the words.  To
          include more than one SPACE, the creator must make  the  LWSP-
          chars be part of a quoted-string.
  
          Quotation marks that delimit a quoted string  and  backslashes
          that  quote  the  following character should NOT accompany the
          quoted-string when the string is passed to processes  that  do
          not interpret data according to this specification (e.g., mail
          protocol servers).
  
       3.4.5.  QUOTED-STRINGS
  
          Where permitted (i.e., in words in structured fields)  quoted-
          strings  are  treated  as a single symbol.  That is, a quoted-
          string is equivalent to an atom, syntactically.  If a  quoted-
          string  is to be "folded" onto multiple lines, then the syntax
          for folding must be adhered to.  (See the "Lexical Analysis of
  
  
       August 13, 1982              - 13 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          Messages"  section  on "Folding Long Header Fields" above, and
          the section on "Case  Independence"  below.)   Therefore,  the
          official  semantics  do  not  "see" any bare CRLFs that are in
          quoted-strings; however particular parsing programs  may  wish
          to  note  their presence.  For such programs, it would be rea-
          sonable to interpret a "CRLF LWSP-char" as being a CRLF  which
          is  part  of the quoted-string; i.e., the CRLF is kept and the
          LWSP-char is discarded.  Quoted CRLFs (i.e., a backslash  fol-
          lowed  by  a CR followed by a LF) are also subject to rules of
          folding, but the presence of the quoting character (backslash)
          explicitly  indicates  that  the  CRLF  is  data to the quoted
          string.  Stripping off the first following LWSP-char  is  also
          appropriate when parsing quoted CRLFs.
  
       3.4.6.  BRACKETING CHARACTERS
  
          There is one type of bracket which must occur in matched pairs
          and may have pairs nested within each other:
  
              o   Parentheses ("(" and ")") are used  to  indicate  com-
                  ments.
  
          There are three types of brackets which must occur in  matched
          pairs, and which may NOT be nested:
  
              o   Colon/semi-colon (":" and ";") are   used  in  address
                  specifications  to  indicate that the included list of
                  addresses are to be treated as a group.
  
              o   Angle brackets ("<" and ">")  are  generally  used  to
                  indicate  the  presence of a one machine-usable refer-
                  ence (e.g., delimiting mailboxes), possibly  including
                  source-routing to the machine.
  
              o   Square brackets ("[" and "]") are used to indicate the
                  presence  of  a  domain-literal, which the appropriate
                  name-domain  is  to  use  directly,  bypassing  normal
                  name-resolution mechanisms.
  
       3.4.7.  CASE INDEPENDENCE
  
          Except as noted, alphabetic strings may be represented in  any
          combination of upper and lower case.  The only syntactic units
  
  
  
  
  
  
  
  
       August 13, 1982              - 14 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          which requires preservation of case information are:
  
                      -  text
                      -  qtext
                      -  dtext
                      -  ctext
                      -  quoted-pair
                      -  local-part, except "Postmaster"
  
          When matching any other syntactic unit, case is to be ignored.
          For  example, the field-names "From", "FROM", "from", and even
          "FroM" are semantically equal and should all be treated ident-
          ically.
  
          When generating these units, any mix of upper and  lower  case
          alphabetic  characters  may  be  used.  The case shown in this
          specification is suggested for message-creating processes.
  
          Note:  The reserved local-part address unit, "Postmaster",  is
                 an  exception.   When  the  value "Postmaster" is being
                 interpreted, it must be  accepted  in  any  mixture  of
                 case, including "POSTMASTER", and "postmaster".
  
       3.4.8.  FOLDING LONG HEADER FIELDS
  
          Each header field may be represented on exactly one line  con-
          sisting  of the name of the field and its body, and terminated
          by a CRLF; this is what the parser sees.  For readability, the
          field-body  portion of long header fields may be "folded" onto
          multiple lines of the actual field.  "Long" is commonly inter-
          preted  to  mean greater than 65 or 72 characters.  The former
          length serves as a limit, when the message is to be viewed  on
          most  simple terminals which use simple display software; how-
          ever, the limit is not imposed by this standard.
  
          Note:  Some display software often can selectively fold lines,
                 to  suit  the display terminal.  In such cases, sender-
                 provided  folding  can  interfere  with   the   display
                 software.
  
       3.4.9.  BACKSPACE CHARACTERS
  
          ASCII BS characters (Backspace, decimal 8) may be included  in
          texts and quoted-strings to effect overstriking.  However, any
          use of backspaces which effects an overstrike to the  left  of
          the beginning of the text or quoted-string is prohibited.
  
  
  
  
  
       August 13, 1982              - 15 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
  
          During transmission through heterogeneous networks, it may  be
          necessary  to  force data to conform to a network's local con-
          ventions.  For example, it may be required that a CR  be  fol-
          lowed  either by LF, making a CRLF, or by <null>, if the CR is
          to stand alone).  Such transformations are reversed, when  the
          message exits that network.
  
          When  crossing  network  boundaries,  the  message  should  be
          treated  as  passing  through  two modules.  It will enter the
          first module containing whatever network-specific  transforma-
          tions  that  were  necessary  to  permit migration through the
          "current" network.  It then passes through the modules:
  
              o   Transformation Reversal
  
                  The "current" network's idiosyncracies are removed and
                  the  message  is returned to the canonical form speci-
                  fied in this standard.
  
              o   Transformation
  
                  The "next" network's local idiosyncracies are  imposed
                  on the message.
  
                                  ------------------
                      From   ==>  | Remove Net-A   |
                      Net-A       | idiosyncracies |
                                  ------------------
                                         ||
                                         \/
                                    Conformance
                                    with standard
                                         ||
                                         \/
                                  ------------------
                                  | Impose Net-B   |  ==>  To
                                  | idiosyncracies |       Net-B
                                  ------------------
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 16 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       4.  MESSAGE SPECIFICATION
  
       4.1.  SYNTAX
  
       Note:  Due to an artifact of the notational conventions, the syn-
              tax  indicates that, when present, some fields, must be in
              a particular order.  Header fields  are  NOT  required  to
              occur  in  any  particular  order, except that the message
              body must occur AFTER  the  headers.   It  is  recommended
              that,  if  present,  headers be sent in the order "Return-
              Path", "Received", "Date",  "From",  "Subject",  "Sender",
              "To", "cc", etc.
  
              This specification permits multiple  occurrences  of  most
              fields.   Except  as  noted,  their  interpretation is not
              specified here, and their use is discouraged.
  
            The following syntax for the bodies of various fields should
       be  thought  of  as  describing  each field body as a single long
       string (or line).  The "Lexical Analysis of Message"  section  on
       "Long  Header Fields", above, indicates how such long strings can
       be represented on more than one line in  the  actual  transmitted
       message.
  
       message     =  fields *( CRLF *text )       ; Everything after
                                                   ;  first null line
                                                   ;  is message body
  
       fields      =    dates                      ; Creation time,
                        source                     ;  author id & one
                      1*destination                ;  address required
                       *optional-field             ;  others optional
  
       source      = [  trace ]                    ; net traversals
                        originator                 ; original mail
                     [  resent ]                   ; forwarded
  
       trace       =    return                     ; path to sender
                      1*received                   ; receipt tags
  
       return      =  "Return-path" ":" route-addr ; return address
  
       received    =  "Received"    ":"            ; one per relay
                         ["from" domain]           ; sending host
                         ["by"   domain]           ; receiving host
                         ["via"  atom]             ; physical path
                        *("with" atom)             ; link/mail protocol
                         ["id"   msg-id]           ; receiver msg id
                         ["for"  addr-spec]        ; initial form
  
  
       August 13, 1982              - 17 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
                          ";"    date-time         ; time received
  
       originator  =   authentic                   ; authenticated addr
                     [ "Reply-To"   ":" 1#address] )
  
       authentic   =   "From"       ":"   mailbox  ; Single author
                   / ( "Sender"     ":"   mailbox  ; Actual submittor
                       "From"       ":" 1#mailbox) ; Multiple authors
                                                   ;  or not sender
  
       resent      =   resent-authentic
                     [ "Resent-Reply-To"  ":" 1#address] )
  
       resent-authentic =
                   =   "Resent-From"      ":"   mailbox
                   / ( "Resent-Sender"    ":"   mailbox
                       "Resent-From"      ":" 1#mailbox  )
  
       dates       =   orig-date                   ; Original
                     [ resent-date ]               ; Forwarded
  
       orig-date   =  "Date"        ":"   date-time
  
       resent-date =  "Resent-Date" ":"   date-time
  
       destination =  "To"          ":" 1#address  ; Primary
                   /  "Resent-To"   ":" 1#address
                   /  "cc"          ":" 1#address  ; Secondary
                   /  "Resent-cc"   ":" 1#address
                   /  "bcc"         ":"  #address  ; Blind carbon
                   /  "Resent-bcc"  ":"  #address
  
       optional-field =
                   /  "Message-ID"        ":"   msg-id
                   /  "Resent-Message-ID" ":"   msg-id
                   /  "In-Reply-To"       ":"  *(phrase / msg-id)
                   /  "References"        ":"  *(phrase / msg-id)
                   /  "Keywords"          ":"  #phrase
                   /  "Subject"           ":"  *text
                   /  "Comments"          ":"  *text
                   /  "Encrypted"         ":" 1#2word
                   /  extension-field              ; To be defined
                   /  user-defined-field           ; May be pre-empted
  
       msg-id      =  "<" addr-spec ">"            ; Unique message id
  
  
  
  
  
  
       August 13, 1982              - 18 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       extension-field =
                     <Any field which is defined in a document
                      published as a formal extension to this
                      specification; none will have names beginning
                      with the string "X-">
  
       user-defined-field =
                     <Any field which has not been defined
                      in this specification or published as an
                      extension to this specification; names for
                      such fields must be unique and may be
                      pre-empted by published extensions>
  
       4.2.  FORWARDING
  
            Some systems permit mail recipients to  forward  a  message,
       retaining  the original headers, by adding some new fields.  This
       standard supports such a service, through the "Resent-" prefix to
       field names.
  
            Whenever the string "Resent-" begins a field name, the field
       has  the  same  semantics as a field whose name does not have the
       prefix.  However, the message is assumed to have  been  forwarded
       by  an original recipient who attached the "Resent-" field.  This
       new field is treated as being more recent  than  the  equivalent,
       original  field.   For  example, the "Resent-From", indicates the
       person that forwarded the message, whereas the "From" field indi-
       cates the original author.
  
            Use of such precedence  information  depends  upon  partici-
       pants'  communication needs.  For example, this standard does not
       dictate when a "Resent-From:" address should receive replies,  in
       lieu of sending them to the "From:" address.
  
       Note:  In general, the "Resent-" fields should be treated as con-
              taining  a  set  of information that is independent of the
              set of original fields.  Information for  one  set  should
              not  automatically be taken from the other.  The interpre-
              tation of multiple "Resent-" fields, of the same type,  is
              undefined.
  
            In the remainder of this specification, occurrence of  legal
       "Resent-"  fields  are treated identically with the occurrence of
  
  
  
  
  
  
  
  
       August 13, 1982              - 19 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       fields whose names do not contain this prefix.
  
       4.3.  TRACE FIELDS
  
            Trace information is used to provide an audit trail of  mes-
       sage  handling.   In  addition,  it indicates a route back to the
       sender of the message.
  
            The list of known "via" and  "with"  values  are  registered
       with  the  Network  Information  Center, SRI International, Menlo
       Park, California.
  
       4.3.1.  RETURN-PATH
  
          This field  is  added  by  the  final  transport  system  that
          delivers  the message to its recipient.  The field is intended
          to contain definitive information about the address and  route
          back to the message's originator.
  
          Note:  The "Reply-To" field is added  by  the  originator  and
                 serves  to  direct  replies,  whereas the "Return-Path"
                 field is used to identify a path back to  the  origina-
                 tor.
  
          While the syntax  indicates  that  a  route  specification  is
          optional,  every attempt should be made to provide that infor-
          mation in this field.
  
       4.3.2.  RECEIVED
  
          A copy of this field is added by each transport  service  that
          relays the message.  The information in the field can be quite
          useful for tracing transport problems.
  
          The names of the sending  and  receiving  hosts  and  time-of-
          receipt may be specified.  The "via" parameter may be used, to
          indicate what physical mechanism the message  was  sent  over,
          such  as  Arpanet or Phonenet, and the "with" parameter may be
          used to indicate the mail-,  or  connection-,  level  protocol
          that  was  used, such as the SMTP mail protocol, or X.25 tran-
          sport protocol.
  
          Note:  Several "with" parameters may  be  included,  to  fully
                 specify the set of protocols that were used.
  
          Some transport services queue mail; the internal message iden-
          tifier that is assigned to the message may be noted, using the
          "id" parameter.  When the  sending  host  uses  a  destination
          address specification that the receiving host reinterprets, by
  
  
       August 13, 1982              - 20 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          expansion or transformation, the receiving host  may  wish  to
          record  the original specification, using the "for" parameter.
          For example, when a copy of mail is sent to the  member  of  a
          distribution  list,  this  parameter may be used to record the
          original address that was used to specify the list.
  
       4.4.  ORIGINATOR FIELDS
  
            The standard allows only a subset of the combinations possi-
       ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
       and Resent-Reply-To fields.  The limitation is intentional.
  
       4.4.1.  FROM / RESENT-FROM
  
          This field contains the identity of the person(s)  who  wished
          this  message to be sent.  The message-creation process should
          default this field  to  be  a  single,  authenticated  machine
          address,  indicating  the  AGENT  (person,  system or process)
          entering the message.  If this is not done, the "Sender" field
          MUST  be  present.  If the "From" field IS defaulted this way,
          the "Sender" field is  optional  and  is  redundant  with  the
          "From"  field.   In  all  cases, addresses in the "From" field
          must be machine-usable (addr-specs) and may not contain  named
          lists (groups).
  
       4.4.2.  SENDER / RESENT-SENDER
  
          This field contains the authenticated identity  of  the  AGENT
          (person,  system  or  process)  that sends the message.  It is
          intended for use when the sender is not the author of the mes-
          sage,  or  to  indicate  who among a group of authors actually
          sent the message.  If the contents of the "Sender" field would
          be  completely  redundant  with  the  "From"  field,  then the
          "Sender" field need not be present and its use is  discouraged
          (though  still legal).  In particular, the "Sender" field MUST
          be present if it is NOT the same as the "From" Field.
  
          The Sender mailbox  specification  includes  a  word  sequence
          which  must correspond to a specific agent (i.e., a human user
          or a computer program) rather than a standard  address.   This
          indicates  the  expectation  that  the field will identify the
          single AGENT (person,  system,  or  process)  responsible  for
          sending  the mail and not simply include the name of a mailbox
          from which the mail was sent.  For example in the  case  of  a
          shared login name, the name, by itself, would not be adequate.
          The local-part address unit, which refers to  this  agent,  is
          expected to be a computer system term, and not (for example) a
          generalized person reference which can  be  used  outside  the
          network text message context.
  
  
       August 13, 1982              - 21 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          Since the critical function served by the  "Sender"  field  is
          identification  of  the agent responsible for sending mail and
          since computer programs cannot be held accountable  for  their
          behavior, it is strongly recommended that when a computer pro-
          gram generates a message, the HUMAN  who  is  responsible  for
          that program be referenced as part of the "Sender" field mail-
          box specification.
  
       4.4.3.  REPLY-TO / RESENT-REPLY-TO
  
          This field provides a general  mechanism  for  indicating  any
          mailbox(es)  to which responses are to be sent.  Three typical
          uses for this feature can  be  distinguished.   In  the  first
          case,  the  author(s) may not have regular machine-based mail-
          boxes and therefore wish(es) to indicate an alternate  machine
          address.   In  the  second case, an author may wish additional
          persons to be made aware of, or responsible for,  replies.   A
          somewhat  different  use  may be of some help to "text message
          teleconferencing" groups equipped with automatic  distribution
          services:   include the address of that service in the "Reply-
          To" field of all messages  submitted  to  the  teleconference;
          then  participants  can  "reply"  to conference submissions to
          guarantee the correct distribution of any submission of  their
          own.
  
          Note:  The "Return-Path" field is added by the mail  transport
                 service,  at the time of final deliver.  It is intended
                 to identify a path back to the orginator  of  the  mes-
                 sage.   The  "Reply-To"  field  is added by the message
                 originator and is intended to direct replies.
  
       4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
  
          For systems which automatically  generate  address  lists  for
          replies to messages, the following recommendations are made:
  
              o   The "Sender" field mailbox should be sent  notices  of
                  any  problems in transport or delivery of the original
                  messages.  If there is no  "Sender"  field,  then  the
                  "From" field mailbox should be used.
  
              o   The  "Sender"  field  mailbox  should  NEVER  be  used
                  automatically, in a recipient's reply message.
  
              o   If the "Reply-To" field exists, then the reply  should
                  go to the addresses indicated in that field and not to
                  the address(es) indicated in the "From" field.
  
  
  
  
       August 13, 1982              - 22 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
              o   If there is a "From" field, but no  "Reply-To"  field,
                  the  reply should be sent to the address(es) indicated
                  in the "From" field.
  
          Sometimes, a recipient may actually wish to  communicate  with
          the  person  that  initiated  the  message  transfer.  In such
          cases, it is reasonable to use the "Sender" address.
  
          This recommendation is intended  only  for  automated  use  of
          originator-fields  and is not intended to suggest that replies
          may not also be sent to other recipients of messages.   It  is
          up  to  the  respective  mail-handling programs to decide what
          additional facilities will be provided.
  
          Examples are provided in Appendix A.
  
       4.5.  RECEIVER FIELDS
  
       4.5.1.  TO / RESENT-TO
  
          This field contains the identity of the primary recipients  of
          the message.
  
       4.5.2.  CC / RESENT-CC
  
          This field contains the identity of  the  secondary  (informa-
          tional) recipients of the message.
  
       4.5.3.  BCC / RESENT-BCC
  
          This field contains the identity of additional  recipients  of
          the  message.   The contents of this field are not included in
          copies of the message sent to the primary and secondary  reci-
          pients.   Some  systems  may choose to include the text of the
          "Bcc" field only in the author(s)'s  copy,  while  others  may
          also include it in the text sent to all those indicated in the
          "Bcc" list.
  
       4.6.  REFERENCE FIELDS
  
       4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
  
               This field contains a unique identifier  (the  local-part
          address  unit)  which  refers to THIS version of THIS message.
          The uniqueness of the message identifier is guaranteed by  the
          host  which  generates  it.  This identifier is intended to be
          machine readable and not necessarily meaningful to humans.   A
          message  identifier pertains to exactly one instantiation of a
          particular message; subsequent revisions to the message should
  
  
       August 13, 1982              - 23 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          each receive new message identifiers.
  
       4.6.2.  IN-REPLY-TO
  
               The contents of this field identify  previous  correspon-
          dence  which this message answers.  Note that if message iden-
          tifiers are used in this  field,  they  must  use  the  msg-id
          specification format.
  
       4.6.3.  REFERENCES
  
               The contents of this field identify other  correspondence
          which  this message references.  Note that if message identif-
          iers are used, they must use the msg-id specification format.
  
       4.6.4.  KEYWORDS
  
               This field contains keywords  or  phrases,  separated  by
          commas.
  
       4.7.  OTHER FIELDS
  
       4.7.1.  SUBJECT
  
               This is intended to provide a summary,  or  indicate  the
          nature, of the message.
  
       4.7.2.  COMMENTS
  
               Permits adding text comments  onto  the  message  without
          disturbing the contents of the message's body.
  
       4.7.3.  ENCRYPTED
  
               Sometimes,  data  encryption  is  used  to  increase  the
          privacy  of  message  contents.   If the body of a message has
          been encrypted, to keep its contents private, the  "Encrypted"
          field  can be used to note the fact and to indicate the nature
          of the encryption.  The first <word> parameter  indicates  the
          software  used  to  encrypt the body, and the second, optional
          <word> is intended to  aid  the  recipient  in  selecting  the
          proper  decryption  key.   This  code word may be viewed as an
          index to a table of keys held by the recipient.
  
          Note:  Unfortunately, headers must contain envelope,  as  well
                 as  contents,  information.  Consequently, it is neces-
                 sary that they remain unencrypted, so that  mail  tran-
                 sport   services   may   access   them.   Since  names,
                 addresses, and "Subject"  field  contents  may  contain
  
  
       August 13, 1982              - 24 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
                 sensitive  information,  this  requirement limits total
                 message privacy.
  
               Names of encryption software are registered with the Net-
          work  Information Center, SRI International, Menlo Park, Cali-
          fornia.
  
       4.7.4.  EXTENSION-FIELD
  
               A limited number of common fields have  been  defined  in
          this  document.   As  network mail requirements dictate, addi-
          tional fields may be standardized.   To  provide  user-defined
          fields  with  a  measure  of  safety,  in name selection, such
          extension-fields will never have names  that  begin  with  the
          string "X-".
  
               Names of Extension-fields are registered with the Network
          Information Center, SRI International, Menlo Park, California.
  
       4.7.5.  USER-DEFINED-FIELD
  
               Individual users of network mail are free to  define  and
          use  additional  header  fields.   Such fields must have names
          which are not already used in the current specification or  in
          any definitions of extension-fields, and the overall syntax of
          these user-defined-fields must conform to this specification's
          rules   for   delimiting  and  folding  fields.   Due  to  the
          extension-field  publishing  process,  the  name  of  a  user-
          defined-field may be pre-empted
  
          Note:  The prefatory string "X-" will never  be  used  in  the
                 names  of Extension-fields.  This provides user-defined
                 fields with a protected set of names.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 25 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       5.  DATE AND TIME SPECIFICATION
  
       5.1.  SYNTAX
  
       date-time   =  [ day "," ] date time        ; dd mm yy
                                                   ;  hh:mm:ss zzz
  
       day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                   /  "Fri"  / "Sat" /  "Sun"
  
       date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                   ;  e.g. 20 Jun 82
  
       month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                   /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                   /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
  
       time        =  hour zone                    ; ANSI and Military
  
       hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                   ; 00:00:00 - 23:59:59
  
       zone        =  "UT"  / "GMT"                ; Universal Time
                                                   ; North American : UT
                   /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                   /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                   /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                   /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                   /  1ALPHA                       ; Military: Z = UT;
                                                   ;  A:-1; (J not used)
                                                   ;  M:-12; N:+1; Y:+12
                   / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                   ;  hours+min. (HHMM)
  
       5.2.  SEMANTICS
  
            If included, day-of-week must be the day implied by the date
       specification.
  
            Time zone may be indicated in several ways.  "UT" is Univer-
       sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
       mitted as a reference to Universal Time.  The  military  standard
       uses  a  single  character for each zone.  "Z" is Universal Time.
       "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
       lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
       letter "J" is not used.  The other remaining two forms are  taken
       from ANSI standard X3.51-1975.  One allows explicit indication of
       the amount of offset from UT; the other uses  common  3-character
       strings for indicating time zones in North America.
  
  
       August 13, 1982              - 26 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       6.  ADDRESS SPECIFICATION
  
       6.1.  SYNTAX
  
       address     =  mailbox                      ; one addressee
                   /  group                        ; named list
  
       group       =  phrase ":" [#mailbox] ";"
  
       mailbox     =  addr-spec                    ; simple address
                   /  phrase route-addr            ; name & addr-spec
  
       route-addr  =  "<" [route] addr-spec ">"
  
       route       =  1#("@" domain) ":"           ; path-relative
  
       addr-spec   =  local-part "@" domain        ; global address
  
       local-part  =  word *("." word)             ; uninterpreted
                                                   ; case-preserved
  
       domain      =  sub-domain *("." sub-domain)
  
       sub-domain  =  domain-ref / domain-literal
  
       domain-ref  =  atom                         ; symbolic reference
  
       6.2.  SEMANTICS
  
            A mailbox receives mail.  It is a  conceptual  entity  which
       does  not necessarily pertain to file storage.  For example, some
       sites may choose to print mail on their line printer and  deliver
       the output to the addressee's desk.
  
            A mailbox specification comprises a person, system  or  pro-
       cess name reference, a domain-dependent string, and a name-domain
       reference.  The name reference is optional and is usually used to
       indicate  the  human name of a recipient.  The name-domain refer-
       ence specifies a sequence of sub-domains.   The  domain-dependent
       string is uninterpreted, except by the final sub-domain; the rest
       of the mail service merely transmits it as a literal string.
  
       6.2.1.  DOMAINS
  
          A name-domain is a set of registered (mail)  names.   A  name-
          domain  specification  resolves  to  a subordinate name-domain
          specification  or  to  a  terminal  domain-dependent   string.
          Hence,  domain  specification  is  extensible,  permitting any
          number of registration levels.
  
  
       August 13, 1982              - 27 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          Name-domains model a global, logical, hierarchical  addressing
          scheme.   The  model is logical, in that an address specifica-
          tion is related to name registration and  is  not  necessarily
          tied  to  transmission  path.   The  model's  hierarchy  is  a
          directed graph, called an in-tree, such that there is a single
          path  from  the root of the tree to any node in the hierarchy.
          If more than one path actually exists, they are considered  to
          be different addresses.
  
          The root node is common to all addresses; consequently, it  is
          not  referenced.   Its  children  constitute "top-level" name-
          domains.  Usually, a service has access to its own full domain
          specification and to the names of all top-level name-domains.
  
          The "top" of the domain addressing hierarchy -- a child of the
          root  --  is  indicated  by  the right-most field, in a domain
          specification.  Its child is specified to the left, its  child
          to the left, and so on.
  
          Some groups provide formal registration services;  these  con-
          stitute   name-domains   that  are  independent  logically  of
          specific machines.  In addition, networks and machines  impli-
          citly  compose name-domains, since their membership usually is
          registered in name tables.
  
          In the case of formal registration, an organization implements
          a  (distributed)  data base which provides an address-to-route
          mapping service for addresses of the form:
  
                           person@registry.organization
  
          Note that "organization" is a logical  entity,  separate  from
          any particular communication network.
  
          A mechanism for accessing "organization" is universally avail-
          able.   That mechanism, in turn, seeks an instantiation of the
          registry; its location is not indicated in the address specif-
          ication.   It  is assumed that the system which operates under
          the name "organization" knows how to find a subordinate regis-
          try.  The registry will then use the "person" string to deter-
          mine where to send the mail specification.
  
          The latter,  network-oriented  case  permits  simple,  direct,
          attachment-related address specification, such as:
  
                                user@host.network
  
          Once the network is accessed, it is expected  that  a  message
          will  go  directly  to the host and that the host will resolve
  
  
       August 13, 1982              - 28 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          the user name, placing the message in the user's mailbox.
  
       6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
  
          Since any number of  levels  is  possible  within  the  domain
          hierarchy,  specification  of  a  fully  qualified address can
          become inconvenient.  This standard permits abbreviated domain
          specification, in a special case:
  
              For the address of  the  sender,  call  the  left-most
              sub-domain  Level  N.   In a header address, if all of
              the sub-domains above (i.e., to the right of) Level  N
              are  the same as those of the sender, then they do not
              have to appear in the specification.   Otherwise,  the
              address must be fully qualified.
  
              This feature is subject  to  approval  by  local  sub-
              domains.   Individual  sub-domains  may  require their
              member systems, which originate mail, to provide  full
              domain  specification only.  When permitted, abbrevia-
              tions may be present  only  while  the  message  stays
              within the sub-domain of the sender.
  
              Use of this mechanism requires the sender's sub-domain
              to reserve the names of all top-level domains, so that
              full specifications can be distinguished from abbrevi-
              ated specifications.
  
          For example, if a sender's address is:
  
                   sender@registry-A.registry-1.organization-X
  
          and one recipient's address is:
  
                  recipient@registry-B.registry-1.organization-X
  
          and another's is:
  
                  recipient@registry-C.registry-2.organization-X
  
          then ".registry-1.organization-X" need not be specified in the
          the  message,  but  "registry-C.registry-2"  DOES  have  to be
          specified.  That is, the first two addresses may  be  abbrevi-
          ated, but the third address must be fully specified.
  
          When a message crosses a domain boundary, all  addresses  must
          be  specified  in  the  full format, ending with the top-level
          name-domain in the right-most field.  It is the responsibility
          of  mail  forwarding services to ensure that addresses conform
  
  
       August 13, 1982              - 29 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          with this requirement.  In the case of abbreviated  addresses,
          the  relaying  service must make the necessary expansions.  It
          should be noted that it often is difficult for such a  service
          to locate all occurrences of address abbreviations.  For exam-
          ple, it will not be possible to find such abbreviations within
          the  body  of  the  message.   The "Return-Path" field can aid
          recipients in recovering from these errors.
  
          Note:  When passing any portion of an addr-spec onto a process
                 which  does  not interpret data according to this stan-
                 dard (e.g., mail protocol servers).  There must  be  NO
                 LWSP-chars  preceding  or  following the at-sign or any
                 delimiting period ("."), such as  shown  in  the  above
                 examples,   and   only  ONE  SPACE  between  contiguous
                 <word>s.
  
       6.2.3.  DOMAIN TERMS
  
          A domain-ref must be THE official name of a registry, network,
          or  host.   It  is  a  symbolic  reference, within a name sub-
          domain.  At times, it is necessary to bypass standard  mechan-
          isms  for  resolving  such  references,  using  more primitive
          information, such as a network host address  rather  than  its
          associated host name.
  
          To permit such references, this standard provides the  domain-
          literal  construct.   Its contents must conform with the needs
          of the sub-domain in which it is interpreted.
  
          Domain-literals which refer to domains within the ARPA  Inter-
          net  specify  32-bit  Internet addresses, in four 8-bit fields
          noted in decimal, as described in Request for  Comments  #820,
          "Assigned Numbers."  For example:
  
                                   [10.0.3.19]
  
          Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
                 is  permitted  only  as  a means of bypassing temporary
                 system limitations, such as name tables which  are  not
                 complete.
  
          The names of "top-level" domains, and  the  names  of  domains
          under  in  the  ARPA Internet, are registered with the Network
          Information Center, SRI International, Menlo Park, California.
  
       6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
  
          The local-part of an  addr-spec  in  a  mailbox  specification
          (i.e.,  the  host's  name for the mailbox) is understood to be
  
  
       August 13, 1982              - 30 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          whatever the receiving mail protocol server allows.  For exam-
          ple,  some systems do not understand mailbox references of the
          form "P. D. Q. Bach", but others do.
  
          This specification treats periods (".") as lexical separators.
          Hence,  their  presence  in  local-parts which are not quoted-
          strings, is detected.   However,  such  occurrences  carry  NO
          semantics.  That is, if a local-part has periods within it, an
          address parser will divide the local-part into several tokens,
          but  the  sequence  of  tokens will be treated as one uninter-
          preted unit.  The sequence  will  be  re-assembled,  when  the
          address is passed outside of the system such as to a mail pro-
          tocol service.
  
          For example, the address:
  
                             First.Last@Registry.Org
  
          is legal and does not require the local-part to be  surrounded
          with  quotation-marks.   (However,  "First  Last" DOES require
          quoting.)  The local-part of the address, when passed  outside
          of  the  mail  system,  within  the  Registry.Org  domain,  is
          "First.Last", again without quotation marks.
  
       6.2.5.  BALANCING LOCAL-PART AND DOMAIN
  
          In some cases, the boundary between local-part and domain  can
          be  flexible.  The local-part may be a simple string, which is
          used for the final determination of the  recipient's  mailbox.
          All  other  levels  of  reference  are, therefore, part of the
          domain.
  
          For some systems, in the case of abbreviated reference to  the
          local  and  subordinate  sub-domains,  it  may  be possible to
          specify only one reference within the domain  part  and  place
          the  other,  subordinate  name-domain  references  within  the
          local-part.  This would appear as:
  
                          mailbox.sub1.sub2@this-domain
  
          Such a specification would be acceptable  to  address  parsers
          which  conform  to  RFC  #733,  but  do not support this newer
          Internet standard.  While contrary to the intent of this stan-
          dard, the form is legal.
  
          Also, some sub-domains have a specification syntax which  does
          not conform to this standard.  For example:
  
                        sub-net.mailbox@sub-domain.domain
  
  
       August 13, 1982              - 31 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          uses a different parsing  sequence  for  local-part  than  for
          domain.
  
          Note:  As a rule,  the  domain  specification  should  contain
                 fields  which  are  encoded  according to the syntax of
                 this standard and which contain  generally-standardized
                 information.   The local-part specification should con-
                 tain only that portion of the  address  which  deviates
                 from the form or intention of the domain field.
  
       6.2.6.  MULTIPLE MAILBOXES
  
          An individual may have several mailboxes and wish  to  receive
          mail  at  whatever  mailbox  is  convenient  for the sender to
          access.  This standard does not provide a means of  specifying
          "any member of" a list of mailboxes.
  
          A set of individuals may wish to receive mail as a single unit
          (i.e.,  a  distribution  list).  The <group> construct permits
          specification of such a list.  Recipient mailboxes are  speci-
          fied  within  the  bracketed  part (":" - ";").  A copy of the
          transmitted message is to be  sent  to  each  mailbox  listed.
          This  standard  does  not  permit  recursive  specification of
          groups within groups.
  
          While a list must be named, it is not required that  the  con-
          tents  of  the  list be included.  In this case, the <address>
          serves only as an indication of group distribution  and  would
          appear in the form:
  
                                      name:;
  
          Some mail  services  may  provide  a  group-list  distribution
          facility,  accepting  a single mailbox reference, expanding it
          to the full distribution list, and relaying the  mail  to  the
          list's  members.   This standard provides no additional syntax
          for indicating such a  service.   Using  the  <group>  address
          alternative,  while listing one mailbox in it, can mean either
          that the mailbox reference will be expanded to a list or  that
          there is a group with one member.
  
       6.2.7.  EXPLICIT PATH SPECIFICATION
  
          At times, a  message  originator  may  wish  to  indicate  the
          transmission  path  that  a  message  should  follow.  This is
          called source routing.  The normal addressing scheme, used  in
          an  addr-spec,  is  carefully separated from such information;
          the <route> portion of a route-addr is provided for such occa-
          sions.  It specifies the sequence of hosts and/or transmission
  
  
       August 13, 1982              - 32 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          services that are  to  be  traversed.   Both  domain-refs  and
          domain-literals may be used.
  
          Note:  The use of source routing is discouraged.   Unless  the
                 sender has special need of path restriction, the choice
                 of transmission route should be left to the mail  tran-
                 sport service.
  
       6.3.  RESERVED ADDRESS
  
            It often is necessary to send mail to a site, without  know-
       ing  any  of its valid addresses.  For example, there may be mail
       system dysfunctions, or a user may wish to find  out  a  person's
       correct address, at that site.
  
            This standard specifies a single, reserved  mailbox  address
       (local-part)  which  is  to  be valid at each site.  Mail sent to
       that address is to be routed to  a  person  responsible  for  the
       site's mail system or to a person with responsibility for general
       site operation.  The name of the reserved local-part address is:
  
                                  Postmaster
  
       so that "Postmaster@domain" is required to be valid.
  
       Note:  This reserved local-part must be  matched  without  sensi-
              tivity to alphabetic case, so that "POSTMASTER", "postmas-
              ter", and even "poStmASteR" is to be accepted.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 33 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       7.  BIBLIOGRAPHY
  
  
       ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
          American  National Standards Institute: New York (1968).  Also
          in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
          book", NIC 7104.
  
       ANSI.  "Representations of Universal Time, Local  Time  Differen-
          tials,  and United States Time Zone References for Information
          Interchange," X3.51-1975.  American National Standards  Insti-
          tute:  New York (1975).
  
       Bemer, R.W., "Time and the Computer."  In:  Interface  Age  (Feb.
          1979).
  
       Bennett, C.J.  "JNT Mail Protocol".  Joint Network Team,  Ruther-
          ford and Appleton Laboratory:  Didcot, England.
  
       Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
          "Standardizing  Network  Mail  Headers,"   ARPANET Request for
          Comments No. 561, Network Information Center  No.  18516;  SRI
          International:  Menlo Park (September 1973).
  
       Birrell, A.D., Levin, R.,  Needham,  R.M.,  and  Schroeder,  M.D.
          "Grapevine:  An Exercise in Distributed Computing," Communica-
          tions of the ACM 25, 4 (April 1982), 260-274.
  
       Crocker,  D.H.,  Vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A.
          "Standard  for  the  Format  of  ARPA  Network  Text Message,"
          ARPANET Request for  Comments  No.  733,  Network  Information
          Center  No.  41952.   SRI International:  Menlo Park (November
          1977).
  
       Feinler, E.J. and Postel, J.B.  ARPANET Protocol  Handbook,  Net-
          work  Information  Center  No.  7104   (NTIS AD A003890).  SRI
          International:  Menlo Park (April 1976).
  
       Harary, F.   "Graph  Theory".   Addison-Wesley:   Reading,  Mass.
          (1969).
  
       Levin, R. and Schroeder, M.  "Transport  of  Electronic  Messages
          through  a  Network,"   TeleInformatics  79, pp. 29-33.  North
          Holland (1979).  Also  as  Xerox  Palo  Alto  Research  Center
          Technical Report CSL-79-4.
  
       Myer, T.H. and Henderson, D.A.  "Message Transmission  Protocol,"
          ARPANET  Request  for  Comments,  No. 680, Network Information
          Center No. 32116.  SRI International:  Menlo Park (1975).
  
  
       August 13, 1982              - 34 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       NBS.  "Specification of Message Format for Computer Based Message
          Systems, Recommended Federal Information Processing Standard."
          National  Bureau   of   Standards:    Gaithersburg,   Maryland
          (October 1981).
  
       NIC.  Internet Protocol Transition Workbook.  Network Information
          Center,   SRI-International,  Menlo  Park,  California  (March
          1982).
  
       Oppen, D.C. and Dalal, Y.K.  "The Clearinghouse:  A Decentralized
          Agent  for  Locating  Named  Objects in a Distributed Environ-
          ment," OPD-T8103.  Xerox Office Products Division:  Palo Alto,
          CA. (October 1981).
  
       Postel, J.B.  "Assigned Numbers,"  ARPANET Request for  Comments,
          No. 820.  SRI International:  Menlo Park (August 1982).
  
       Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
          for Comments, No. 821.  SRI International:  Menlo Park (August
          1982).
  
       Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
          Proc. 17th IEEE Computer Society International Conference, pp.
          72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
  
       Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
          User  Applications,"  ARPANET  Request  for Comments, No. 819.
          SRI International:  Menlo Park (August 1982).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 35 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
                                   APPENDIX
  
  
       A.  EXAMPLES
  
       A.1.  ADDRESSES
  
       A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
  
       A.1.2.  Neuman@BBN-TENEXA
  
               These two "Alfred Neuman" examples have identical  seman-
          tics, as far as the operation of the local host's mail sending
          (distribution) program (also sometimes  called  its  "mailer")
          and  the remote host's mail protocol server are concerned.  In
          the first example, the  "Alfred  Neuman"  is  ignored  by  the
          mailer,  as "Neuman@BBN-TENEXA" completely specifies the reci-
          pient.  The second example contains  no  superfluous  informa-
          tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
          pient.
  
          Note:  When the message crosses name-domain  boundaries,  then
                 these specifications must be changed, so as to indicate
                 the remainder of the hierarchy, starting with  the  top
                 level.
  
       A.1.3.  "George, Ted" <Shared@Group.Arpanet>
  
               This form might be used to indicate that a single mailbox
          is  shared  by several users.  The quoted string is ignored by
          the originating host's mailer, because  "Shared@Group.Arpanet"
          completely specifies the destination mailbox.
  
       A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
  
               The "(the  Stilt)" is a comment, which is NOT included in
          the  destination  mailbox  address  handed  to the originating
          system's mailer.  The local-part of the address is the  string
          "Wilt.Chamberlain", with NO space between the first and second
          words.
  
       A.1.5.  Address Lists
  
       Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
                  Childs@WGBH.Boston, Galloping Gourmet@
                  ANT.Down-Under (Australian National Television),
                  Cheapie@Discount-Liquors;,
         Cruisers:  Port@Portugal, Jones@SEA;,
           Another@Somewhere.SomeOrg
  
  
       August 13, 1982              - 36 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          This group list example points out the use of comments and the
          mixing of addresses and groups.
  
       A.2.  ORIGINATOR ITEMS
  
       A.2.1.  Author-sent
  
               George Jones logs into his host  as  "Jones".   He  sends
          mail himself.
  
              From:  Jones@Group.Org
  
          or
  
              From:  George Jones <Jones@Group.Org>
  
       A.2.2.  Secretary-sent
  
               George Jones logs in as Jones on his  host.   His  secre-
          tary,  who logs in as Secy sends mail for him.  Replies to the
          mail should go to George.
  
              From:    George Jones <Jones@Group>
              Sender:  Secy@Other-Group
  
       A.2.3.  Secretary-sent, for user of shared directory
  
               George Jones' secretary sends mail  for  George.  Replies
          should go to George.
  
              From:     George Jones<Shared@Group.Org>
              Sender:   Secy@Other-Group
  
          Note that there need not be a space between  "Jones"  and  the
          "<",  but  adding a space enhances readability (as is the case
          in other examples.
  
       A.2.4.  Committee activity, with one author
  
               George is a member of a committee.  He wishes to have any
          replies to his message go to all committee members.
  
              From:     George Jones <Jones@Host.Net>
              Sender:   Jones@Host
              Reply-To: The Committee: Jones@Host.Net,
                                       Smith@Other.Org,
                                       Doe@Somewhere-Else;
  
          Note  that  if  George  had  not  included  himself   in   the
  
  
       August 13, 1982              - 37 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
          enumeration  of  The  Committee,  he  would not have gotten an
          implicit reply; the presence of the  "Reply-to"  field  SUPER-
          SEDES the sending of a reply to the person named in the "From"
          field.
  
       A.2.5.  Secretary acting as full agent of author
  
               George Jones asks his secretary  (Secy@Host)  to  send  a
          message for him in his capacity as Group.  He wants his secre-
          tary to handle all replies.
  
              From:     George Jones <Group@Host>
              Sender:   Secy@Host
              Reply-To: Secy@Host
  
       A.2.6.  Agent for user without online mailbox
  
               A friend  of  George's,  Sarah,  is  visiting.   George's
          secretary  sends  some  mail to a friend of Sarah in computer-
          land.  Replies should go to George, whose mailbox is Jones  at
          Registry.
  
              From:     Sarah Friendly <Secy@Registry>
              Sender:   Secy-Name <Secy@Registry>
              Reply-To: Jones@Registry.
  
       A.2.7.  Agent for member of a committee
  
               George's secretary sends out a message which was authored
          jointly by all the members of a committee.  Note that the name
          of the committee cannot be specified, since <group> names  are
          not permitted in the From field.
  
              From:   Jones@Host,
                      Smith@Other-Host,
                      Doe@Somewhere-Else
              Sender: Secy@SHost
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 38 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       A.3.  COMPLETE HEADERS
  
       A.3.1.  Minimum required
  
       Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
       From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
       Bcc:                                To:       Smith@Registry.Org
  
          Note that the "Bcc" field may be empty, while the  "To"  field
          is required to have at least one address.
  
       A.3.2.  Using some of the additional fields
  
       Date:     26 Aug 76 1430 EDT
       From:     George Jones<Group@Host>
       Sender:   Secy@SHOST
       To:       "Al Neuman"@Mad-Host,
                 Sam.Irving@Other-Host
       Message-ID:  <some.string@SHOST>
  
       A.3.3.  About as complex as you're going to get
  
       Date     :  27 Aug 76 0932 PDT
       From     :  Ken Davis <KDavis@This-Host.This-net>
       Subject  :  Re: The Syntax in the RFC
       Sender   :  KSecy@Other-Host
       Reply-To :  Sam.Irving@Reg.Organization
       To       :  George Jones <Group@Some-Reg.An-Org>,
                   Al.Neuman@MAD.Publisher
       cc       :  Important folk:
                     Tom Softwood <Balsa@Tree.Root>,
                     "Sam Irving"@Other-Host;,
                   Standard Distribution:
                     /main/davis/people/standard@Other-Host,
                     "<Jones>standard.dist.3"@Tops-20-Host>;
       Comment  :  Sam is away on business. He asked me to handle
                   his mail for him.  He'll be able to provide  a
                   more  accurate  explanation  when  he  returns
                   next week.
       In-Reply-To: <some.string@DBM.Group>, George's message
       X-Special-action:  This is a sample of user-defined field-
                   names.  There could also be a field-name
                   "Special-action", but its name might later be
                   preempted
       Message-ID: <4231.629.XYzi-What@Other-Host>
  
  
  
  
  
  
       August 13, 1982              - 39 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       B.  SIMPLE FIELD PARSING
  
            Some mail-reading software systems may wish to perform  only
       minimal  processing,  ignoring  the internal syntax of structured
       field-bodies and treating them the  same  as  unstructured-field-
       bodies.  Such software will need only to distinguish:
  
           o   Header fields from the message body,
  
           o   Beginnings of fields from lines which continue fields,
  
           o   Field-names from field-contents.
  
            The abbreviated set of syntactic rules  which  follows  will
       suffice  for  this  purpose.  It describes a limited view of mes-
       sages and is a subset of the syntactic rules provided in the main
       part of this specification.  One small exception is that the con-
       tents of field-bodies consist only of text:
  
       B.1.  SYNTAX
  
  
       message         =   *field *(CRLF *text)
  
       field           =    field-name ":" [field-body] CRLF
  
       field-name      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
  
       field-body      =   *text [CRLF LWSP-char field-body]
  
  
       B.2.  SEMANTICS
  
            Headers occur before the message body and are terminated  by
       a null line (i.e., two contiguous CRLFs).
  
            A line which continues a header field begins with a SPACE or
       HTAB  character,  while  a  line  beginning a field starts with a
       printable character which is not a colon.
  
            A field-name consists of one or  more  printable  characters
       (excluding  colon,  space, and control-characters).  A field-name
       MUST be contained on one line.  Upper and lower case are not dis-
       tinguished when comparing field-names.
  
  
  
  
  
  
  
       August 13, 1982              - 40 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       C.  DIFFERENCES FROM RFC #733
  
            The following summarizes the differences between this  stan-
       dard  and the one specified in Arpanet Request for Comments #733,
       "Standard for the Format of ARPA  Network  Text  Messages".   The
       differences  are  listed  in the order of their occurrence in the
       current specification.
  
       C.1.  FIELD DEFINITIONS
  
       C.1.1.  FIELD NAMES
  
          These now must be a sequence of  printable  characters.   They
          may not contain any LWSP-chars.
  
       C.2.  LEXICAL TOKENS
  
       C.2.1.  SPECIALS
  
          The characters period ("."), left-square  bracket  ("["),  and
          right-square  bracket ("]") have been added.  For presentation
          purposes, and when passing a specification to  a  system  that
          does  not conform to this standard, periods are to be contigu-
          ous with their surrounding lexical tokens.   No  linear-white-
          space  is  permitted  between them.  The presence of one LWSP-
          char between other tokens is still directed.
  
       C.2.2.  ATOM
  
          Atoms may not contain SPACE.
  
       C.2.3.  SPECIAL TEXT
  
          ctext and qtext have had backslash ("\") added to the list  of
          prohibited characters.
  
       C.2.4.  DOMAINS
  
          The lexical tokens  <domain-literal>  and  <dtext>  have  been
          added.
  
       C.3.  MESSAGE SPECIFICATION
  
       C.3.1.  TRACE
  
          The "Return-path:" and "Received:" fields have been specified.
  
  
  
  
  
       August 13, 1982              - 41 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       C.3.2.  FROM
  
          The "From" field must contain machine-usable addresses  (addr-
          spec).   Multiple  addresses may be specified, but named-lists
          (groups) may not.
  
       C.3.3.  RESENT
  
          The meta-construct of prefacing field names  with  the  string
          "Resent-"  has been added, to indicate that a message has been
          forwarded by an intermediate recipient.
  
       C.3.4.  DESTINATION
  
          A message must contain at least one destination address field.
          "To" and "CC" are required to contain at least one address.
  
       C.3.5.  IN-REPLY-TO
  
          The field-body is no longer a comma-separated list, although a
          sequence is still permitted.
  
       C.3.6.  REFERENCE
  
          The field-body is no longer a comma-separated list, although a
          sequence is still permitted.
  
       C.3.7.  ENCRYPTED
  
          A field has been specified that permits  senders  to  indicate
          that the body of a message has been encrypted.
  
       C.3.8.  EXTENSION-FIELD
  
          Extension fields are prohibited from beginning with the  char-
          acters "X-".
  
       C.4.  DATE AND TIME SPECIFICATION
  
       C.4.1.  SIMPLIFICATION
  
          Fewer optional forms are permitted  and  the  list  of  three-
          letter time zones has been shortened.
  
       C.5.  ADDRESS SPECIFICATION
  
  
  
  
  
  
       August 13, 1982              - 42 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       C.5.1.  ADDRESS
  
          The use of quoted-string, and the ":"-atom-":" construct, have
          been  removed.   An  address  now  is  either a single mailbox
          reference or is a named list of addresses.  The  latter  indi-
          cates a group distribution.
  
       C.5.2.  GROUPS
  
          Group lists are now required to to have a name.   Group  lists
          may not be nested.
  
       C.5.3.  MAILBOX
  
          A mailbox specification  may  indicate  a  person's  name,  as
          before.   Such  a  named  list  no longer may specify multiple
          mailboxes and may not be nested.
  
       C.5.4.  ROUTE ADDRESSING
  
          Addresses now are taken to be absolute, global specifications,
          independent  of transmission paths.  The <route> construct has
          been provided, to permit explicit specification  of  transmis-
          sion  path.   RFC  #733's  use  of multiple at-signs ("@") was
          intended as a general syntax  for  indicating  routing  and/or
          hierarchical addressing.  The current standard separates these
          specifications and only one at-sign is permitted.
  
       C.5.5.  AT-SIGN
  
          The string " at " no longer is used as an  address  delimiter.
          Only at-sign ("@") serves the function.
  
       C.5.6.  DOMAINS
  
          Hierarchical, logical name-domains have been added.
  
       C.6.  RESERVED ADDRESS
  
       The local-part "Postmaster" has been reserved, so that users  can
       be guaranteed at least one valid address at a site.
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 43 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       D.  ALPHABETICAL LISTING OF SYNTAX RULES
  
       address     =  mailbox                      ; one addressee
                   /  group                        ; named list
       addr-spec   =  local-part "@" domain        ; global address
       ALPHA       =  <any ASCII alphabetic character>
                                                   ; (101-132, 65.- 90.)
                                                   ; (141-172, 97.-122.)
       atom        =  1*<any CHAR except specials, SPACE and CTLs>
       authentic   =   "From"       ":"   mailbox  ; Single author
                   / ( "Sender"     ":"   mailbox  ; Actual submittor
                       "From"       ":" 1#mailbox) ; Multiple authors
                                                   ;  or not sender
       CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
       comment     =  "(" *(ctext / quoted-pair / comment) ")"
       CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
       CRLF        =  CR LF
       ctext       =  <any CHAR excluding "(",     ; => may be folded
                       ")", "\" & CR, & including
                       linear-white-space>
       CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
                       character and DEL>          ; (    177,     127.)
       date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                   ;  e.g. 20 Jun 82
       dates       =   orig-date                   ; Original
                     [ resent-date ]               ; Forwarded
       date-time   =  [ day "," ] date time        ; dd mm yy
                                                   ;  hh:mm:ss zzz
       day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                   /  "Fri"  / "Sat" /  "Sun"
       delimiters  =  specials / linear-white-space / comment
       destination =  "To"          ":" 1#address  ; Primary
                   /  "Resent-To"   ":" 1#address
                   /  "cc"          ":" 1#address  ; Secondary
                   /  "Resent-cc"   ":" 1#address
                   /  "bcc"         ":"  #address  ; Blind carbon
                   /  "Resent-bcc"  ":"  #address
       DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
       domain      =  sub-domain *("." sub-domain)
       domain-literal =  "[" *(dtext / quoted-pair) "]"
       domain-ref  =  atom                         ; symbolic reference
       dtext       =  <any CHAR excluding "[",     ; => may be folded
                       "]", "\" & CR, & including
                       linear-white-space>
       extension-field =
                     <Any field which is defined in a document
                      published as a formal extension to this
                      specification; none will have names beginning
                      with the string "X-">
  
  
       August 13, 1982              - 44 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       field       =  field-name ":" [ field-body ] CRLF
       fields      =    dates                      ; Creation time,
                        source                     ;  author id & one
                      1*destination                ;  address required
                       *optional-field             ;  others optional
       field-body  =  field-body-contents
                      [CRLF LWSP-char field-body]
       field-body-contents =
                     <the ASCII characters making up the field-body, as
                      defined in the following sections, and consisting
                      of combinations of atom, quoted-string, and
                      specials tokens, or else consisting of texts>
       field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
       group       =  phrase ":" [#mailbox] ";"
       hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                   ; 00:00:00 - 23:59:59
       HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
       LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
       linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
                                                   ; CRLF => folding
       local-part  =  word *("." word)             ; uninterpreted
                                                   ; case-preserved
       LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
       mailbox     =  addr-spec                    ; simple address
                   /  phrase route-addr            ; name & addr-spec
       message     =  fields *( CRLF *text )       ; Everything after
                                                   ;  first null line
                                                   ;  is message body
       month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                   /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                   /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
       msg-id      =  "<" addr-spec ">"            ; Unique message id
       optional-field =
                   /  "Message-ID"        ":"   msg-id
                   /  "Resent-Message-ID" ":"   msg-id
                   /  "In-Reply-To"       ":"  *(phrase / msg-id)
                   /  "References"        ":"  *(phrase / msg-id)
                   /  "Keywords"          ":"  #phrase
                   /  "Subject"           ":"  *text
                   /  "Comments"          ":"  *text
                   /  "Encrypted"         ":" 1#2word
                   /  extension-field              ; To be defined
                   /  user-defined-field           ; May be pre-empted
       orig-date   =  "Date"        ":"   date-time
       originator  =   authentic                   ; authenticated addr
                     [ "Reply-To"   ":" 1#address] )
       phrase      =  1*word                       ; Sequence of words
  
  
  
  
       August 13, 1982              - 45 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       qtext       =  <any CHAR excepting <">,     ; => may be folded
                       "\" & CR, and including
                       linear-white-space>
       quoted-pair =  "\" CHAR                     ; may quote any char
       quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                   ;   quoted chars.
       received    =  "Received"    ":"            ; one per relay
                         ["from" domain]           ; sending host
                         ["by"   domain]           ; receiving host
                         ["via"  atom]             ; physical path
                        *("with" atom)             ; link/mail protocol
                         ["id"   msg-id]           ; receiver msg id
                         ["for"  addr-spec]        ; initial form
                          ";"    date-time         ; time received
  
       resent      =   resent-authentic
                     [ "Resent-Reply-To"  ":" 1#address] )
       resent-authentic =
                   =   "Resent-From"      ":"   mailbox
                   / ( "Resent-Sender"    ":"   mailbox
                       "Resent-From"      ":" 1#mailbox  )
       resent-date =  "Resent-Date" ":"   date-time
       return      =  "Return-path" ":" route-addr ; return address
       route       =  1#("@" domain) ":"           ; path-relative
       route-addr  =  "<" [route] addr-spec ">"
       source      = [  trace ]                    ; net traversals
                        originator                 ; original mail
                     [  resent ]                   ; forwarded
       SPACE       =  <ASCII SP, space>            ; (     40,      32.)
       specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
                   /  "," / ";" / ":" / "\" / <">  ;  string, to use
                   /  "." / "[" / "]"              ;  within a word.
       sub-domain  =  domain-ref / domain-literal
       text        =  <any CHAR, including bare    ; => atoms, specials,
                       CR & bare LF, but NOT       ;  comments and
                       including CRLF>             ;  quoted-strings are
                                                   ;  NOT recognized.
       time        =  hour zone                    ; ANSI and Military
       trace       =    return                     ; path to sender
                      1*received                   ; receipt tags
       user-defined-field =
                     <Any field which has not been defined
                      in this specification or published as an
                      extension to this specification; names for
                      such fields must be unique and may be
                      pre-empted by published extensions>
       word        =  atom / quoted-string
  
  
  
  
       August 13, 1982              - 46 -                      RFC #822
  
  
   
       Standard for ARPA Internet Text Messages
  
  
       zone        =  "UT"  / "GMT"                ; Universal Time
                                                   ; North American : UT
                   /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                   /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                   /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                   /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                   /  1ALPHA                       ; Military: Z = UT;
       <">         =  <ASCII quote mark>           ; (     42,      34.)
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
       August 13, 1982              - 47 -                      RFC #822
  
  
  
  
  
  
  1.1                  jakarta-james/docs/rfclist/rfc1036.txt
  
  Index: rfc1036.txt
  ===================================================================
  
  
  
  
  
  Network Working Group                                          M. Horton
  Request for Comments:  1036                       AT&T Bell Laboratories
  Obsoletes: RFC-850                                              R. Adams
                                                Center for Seismic Studies
                                                             December 1987
  
  
                Standard for Interchange of USENET Messages
  
  
  
  STATUS OF THIS MEMO
  
      This document defines the standard format for the interchange of
      network News messages among USENET hosts.  It updates and replaces
      RFC-850, reflecting version B2.11 of the News program.  This memo is
      disributed as an RFC to make this information easily accessible to
      the Internet community.  It does not specify an Internet standard.
      Distribution of this memo is unlimited.
  
  1.  Introduction
  
      This document defines the standard format for the interchange of
      network News messages among USENET hosts.  It describes the format
      for messages themselves and gives partial standards for transmission
      of news.  The news transmission is not entirely in order to give a
      good deal of flexibility to the hosts to choose transmission
      hardware and software, to batch news, and so on.
  
      There are five sections to this document.  Section two defines the
      format.  Section three defines the valid control messages.  Section
      four specifies some valid transmission methods.  Section five
      describes the overall news propagation algorithm.
  
  2.  Message Format
  
      The primary consideration in choosing a message format is that it
      fit in with existing tools as well as possible.  Existing tools
      include implementations of both mail and news.  (The notesfiles
      system from the University of Illinois is considered a news
      implementation.)  A standard format for mail messages has existed
      for many years on the Internet, and this format meets most of the
      needs of USENET.  Since the Internet format is extensible,
      extensions to meet the additional needs of USENET are easily made
      within the Internet standard.  Therefore, the rule is adopted that
      all USENET news messages must be formatted as valid Internet mail
      messages, according to the Internet standard RFC-822.  The USENET
      News standard is more restrictive than the Internet standard,
  
  
  
  Horton & Adams                                                  [Page 1]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      placing additional requirements on each message and forbidding use
      of certain Internet features.  However, it should always be possible
      to use a tool expecting an Internet message to process a news
      message.  In any situation where this standard conflicts with the
      Internet standard, RFC-822 should be considered correct and this
      standard in error.
  
      Here is an example USENET message to illustrate the fields.
  
                From: jerry@eagle.ATT.COM (Jerry Schwarz)
                Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                Newsgroups: news.announce
                Subject: Usenet Etiquette -- Please Read
                Message-ID: <642@eagle.ATT.COM>
                Date: Fri, 19 Nov 82 16:14:55 GMT
                Followup-To: news.misc
                Expires: Sat, 1 Jan 83 00:00:00 -0500
                Organization: AT&T Bell Laboratories, Murray Hill
  
                The body of the message comes here, after a blank line.
  
        Here is an example of a message in the old format (before the
        existence of this standard). It is recommended that
        implementations also accept messages in this format to ease upward
        conversion.
  
                 From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
                 Newsgroups: news.misc
                 Title: Usenet Etiquette -- Please Read
                 Article-I.D.: eagle.642
                 Posted: Fri Nov 19 16:14:55 1982
                 Received: Fri Nov 19 16:59:30 1982
                 Expires: Mon Jan 1 00:00:00 1990
  
                 The body of the message comes here, after a blank line.
  
        Some news systems transmit news in the A format, which looks like
        this:
  
                  Aeagle.642
                  news.misc
                  cbosgd!mhuxj!mhuxt!eagle!jerry
                  Fri Nov 19 16:14:55 1982
                  Usenet Etiquette - Please Read
                  The body of the message comes here, with no blank line.
  
      A standard USENET message consists of several header lines, followed
      by a blank line, followed by the body of the message.  Each header
  
  
  
  Horton & Adams                                                  [Page 2]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      line consist of a keyword, a colon, a blank, and some additional
      information.  This is a subset of the Internet standard, simplified
      to allow simpler software to handle it.  The "From" line may
      optionally include a full name, in the format above, or use the
      Internet angle bracket syntax.  To keep the implementations simple,
      other formats (for example, with part of the machine address after
      the close parenthesis) are not allowed.  The Internet convention of
      continuation header lines (beginning with a blank or tab) is
      allowed.
  
      Certain headers are required, and certain other headers are
      optional.  Any unrecognized headers are allowed, and will be passed
      through unchanged.  The required header lines are "From", "Date",
      "Newsgroups", "Subject", "Message-ID", and "Path".  The optional
      header lines are "Followup-To", "Expires", "Reply-To", "Sender",
      "References", "Control", "Distribution", "Keywords", "Summary",
      "Approved", "Lines", "Xref", and "Organization".  Each of these
      header lines will be described below.
  
  2.1.  Required Header lines
  
  2.1.1.  From
  
      The "From" line contains the electronic mailing address of the
      person who sent the message, in the Internet syntax.  It may
      optionally also contain the full name of the person, in parentheses,
      after the electronic address.  The electronic address is the same as
      the entity responsible for originating the message, unless the
      "Sender" header is present, in which case the "From" header might
      not be verified.  Note that in all host and domain names, upper and
      lower case are considered the same, thus "mark@cbosgd.ATT.COM",
      "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
      User names may or may not be case sensitive, for example,
      "Billy@cbosgd.ATT.COM" might be different from
      "BillY@cbosgd.ATT.COM".  Programs should avoid changing the case of
      electronic addresses when forwarding news or mail.
  
      RFC-822 specifies that all text in parentheses is to be interpreted
      as a comment.  It is common in Internet mail to place the full name
      of the user in a comment at the end of the "From" line.  This
      standard specifies a more rigid syntax.  The full name is not
      considered a comment, but an optional part of the header line.
      Either the full name is omitted, or it appears in parentheses after
      the electronic address of the person posting the message, or it
      appears before an electronic address which is enclosed in angle
      brackets.  Thus, the three permissible forms are:
  
  
  
  
  
  Horton & Adams                                                  [Page 3]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
                From: mark@cbosgd.ATT.COM
                From: mark@cbosgd.ATT.COM (Mark Horton)
                From: Mark Horton <mark@cbosgd.ATT.COM>
  
      Full names may contain any printing ASCII characters from space
      through tilde, except that they may not contain "(" (left
      parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
      ">" (right angle bracket).  Additional restrictions may be placed on
      full names by the mail standard, in particular, the characters ","
      (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
      (equal), and ";" (semicolon) are inadvisable in full names.
  
  2.1.2.  Date
  
      The "Date" line (formerly "Posted") is the date that the message was
      originally posted to the network.  Its format must be acceptable
      both in RFC-822 and to the getdate(3) routine that is provided with
      the Usenet software.  This date remains unchanged as the message is
      propagated throughout the network.  One format that is acceptable to
      both is:
  
                        Wdy, DD Mon YY HH:MM:SS TIMEZONE
  
      Several examples of valid dates appear in the sample message above.
      Note in particular that ctime(3) format:
  
                            Wdy Mon DD HH:MM:SS YYYY
  
      is not acceptable because it is not a valid RFC-822 date.  However,
      since older software still generates this format, news
      implementations are encouraged to accept this format and translate
      it into an acceptable format.
  
      There is no hope of having a complete list of timezones.  Universal
      Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST,
      CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be
      supported.  It is recommended that times in message headers be
      transmitted in GMT and displayed in the local time zone.
  
  2.1.3.  Newsgroups
  
      The "Newsgroups" line specifies the newsgroup or newsgroups in which
      the message belongs.  Multiple newsgroups may be specified,
      separated by a comma.  Newsgroups specified must all be the names of
      existing newsgroups, as no new newsgroups will be created by simply
      posting to them.
  
  
  
  
  
  Horton & Adams                                                  [Page 4]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      Wildcards (e.g., the word "all") are never allowed in a "News-
      groups" line.  For example, a newsgroup comp.all is illegal,
      although a newsgroup rec.sport.football is permitted.
  
      If a message is received with a "Newsgroups" line listing some valid
      newsgroups and some invalid newsgroups, a host should not remove
      invalid newsgroups from the list.  Instead, the invalid newsgroups
      should be ignored.  For example, suppose host A subscribes to the
      classes btl.all and comp.all, and exchanges news messages with host
      B, which subscribes to comp.all but not btl.all.  Suppose A receives
      a message with Newsgroups: comp.unix,btl.general.
  
      This message is passed on to B because B receives comp.unix, but B
      does not receive btl.general.  A must leave the "Newsgroups" line
      unchanged.  If it were to remove btl.general, the edited header
      could eventually re-enter the btl.all class, resulting in a message
      that is not shown to users subscribing to btl.general.  Also,
      follow-ups from outside btl.all would not be shown to such users.
  
  2.1.4.  Subject
  
      The "Subject" line (formerly "Title") tells what the message is
      about.  It should be suggestive enough of the contents of the
      message to enable a reader to make a decision whether to read the
      message based on the subject alone.  If the message is submitted in
      response to another message (e.g., is a follow-up) the default
      subject should begin with the four characters "Re:", and the
      "References" line is required.  For follow-ups, the use of the
      "Summary" line is encouraged.
  
  2.1.5.  Message-ID
  
      The "Message-ID" line gives the message a unique identifier.  The
      Message-ID may not be reused during the lifetime of any previous
      message with the same Message-ID.  (It is recommended that no
      Message-ID be reused for at least two years.)  Message-ID's have the
      syntax:
  
                       <string not containing blank or ">">
  
      In order to conform to RFC-822, the Message-ID must have the format:
  
                            <unique@full_domain_name>
  
      where full_domain_name is the full name of the host at which the
      message entered the network, including a domain that host is in, and
      unique is any string of printing ASCII characters, not including "<"
      (left angle bracket), ">" (right angle bracket), or "@" (at sign).
  
  
  
  Horton & Adams                                                  [Page 5]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      For example, the unique part could be an integer representing a
      sequence number for messages submitted to the network, or a short
      string derived from the date and time the message was created.  For
      example, a valid Message-ID for a message submitted from host ucbvax
      in domain "Berkeley.EDU" would be "<4123@ucbvax.Berkeley.EDU>".
      Programmers are urged not to make assumptions about the content of
      Message-ID fields from other hosts, but to treat them as unknown
      character strings.  It is not safe, for example, to assume that a
      Message-ID will be under 14 characters, that it is unique in the
      first 14 characters, nor that is does not contain a "/".
  
      The angle brackets are considered part of the Message-ID.  Thus, in
      references to the Message-ID, such as the ihave/sendme and cancel
      control messages, the angle brackets are included.  White space
      characters (e.g., blank and tab) are not allowed in a Message-ID.
      Slashes ("/") are strongly discouraged.  All characters between the
      angle brackets must be printing ASCII characters.
  
  2.1.6.  Path
  
      This line shows the path the message took to reach the current
      system.  When a system forwards the message, it should add its own
      name to the list of systems in the "Path" line.  The names may be
      separated by any punctuation character or characters (except "."
      which is considered part of the hostname).  Thus, the following are
      valid entries:
  
                     cbosgd!mhuxj!mhuxt
                     cbosgd, mhuxj, mhuxt
                     @cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
                     teklabs, zehntel, sri-unix@cca!decvax
  
      (The latter path indicates a message that passed through decvax,
      cca, sri-unix, zehntel, and teklabs, in that order.) Additional
      names should be added from the left.  For example, the most recently
      added name in the fourth example was teklabs.  Letters, digits,
      periods and hyphens are considered part of host names; other
      punctuation, including blanks, are considered separators.
  
      Normally, the rightmost name will be the name of the originating
      system.  However, it is also permissible to include an extra entry
      on the right, which is the name of the sender.  This is for upward
      compatibility with older systems.
  
      The "Path" line is not used for replies, and should not be taken as
      a mailing address.  It is intended to show the route the message
      traveled to reach the local host.  There are several uses for this
      information.  One is to monitor USENET routing for performance
  
  
  
  Horton & Adams                                                  [Page 6]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      reasons.  Another is to establish a path to reach new hosts.
      Perhaps the most important use is to cut down on redundant USENET
      traffic by failing to forward a message to a host that is known to
      have already received it.  In particular, when host A sends a
      message to host B, the "Path" line includes A, so that host B will
      not immediately send the message back to host A.  The name each host
      uses to identify itself should be the same as the name by which its
      neighbors know it, in order to make this optimization possible.
  
      A host adds its own name to the front of a path when it receives a
      message from another host.  Thus, if a message with path "A!X!Y!Z"
      is passed from host A to host B, B will add its own name to the path
      when it receives the message from A, e.g., "B!A!X!Y!Z".  If B then
      passes the message on to C, the message sent to C will contain the
      path "B!A!X!Y!Z", and when C receives it, C will change it to
      "C!B!A!X!Y!Z".
  
      Special upward compatibility note:  Since the "From", "Sender", and
      "Reply-To" lines are in Internet format, and since many USENET hosts
      do not yet have mailers capable of understanding Internet format, it
      would break the reply capability to completely sever the connection
      between the "Path" header and the reply function.  It is recognized
      that the path is not always a valid reply string in older
      implementations, and no requirement to fix this problem is placed on
      implementations.  However, the existing convention of placing the
      host name and an "!"  at the front of the path, and of starting the
      path with the host name, an "!", and the user name, should be
      maintained when possible.
  
  2.2.  Optional Headers
  
  2.2.1.  Reply-To
  
      This line has the same format as "From".  If present, mailed replies
      to the author should be sent to the name given here.  Otherwise,
      replies are mailed to the name on the "From" line. (This does not
      prevent additional copies from being sent to recipients named by the
      replier, or on "To" or "Cc" lines.)  The full name may be optionally
      given, in parentheses, as in the "From" line.
  
  2.2.2.  Sender
  
      This field is present only if the submitter manually enters a "From"
      line.  It is intended to record the entity responsible for
      submitting the message to the network.  It should be verified by the
      software at the submitting host.
  
  
  
  
  
  Horton & Adams                                                  [Page 7]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      For example, if John Smith is visiting CCA and wishes to post a
      message to the network, using friend Sarah Jones' account, the
      message might read:
  
                From: smith@ucbvax.Berkeley.EDU (John Smith)
                Sender: jones@cca.COM (Sarah Jones)
  
      If a gateway program enters a mail message into the network at host
      unix.SRI.COM, the lines might read:
  
                From: John.Doe@A.CS.CMU.EDU
                Sender: network@unix.SRI.COM
  
      The primary purpose of this field is to be able to track down
      messages to determine how they were entered into the network.  The
      full name may be optionally given, in parentheses, as in the "From"
      line.
  
  2.2.3.  Followup-To
  
      This line has the same format as "Newsgroups".  If present, follow-
      up messages are to be posted to the newsgroup or newsgroups listed
      here.  If this line is not present, follow-ups are posted to the
      newsgroup or newsgroups listed in the "Newsgroups" line.
  
      If the keyword poster is present, follow-up messages are not
      permitted.  The message should be mailed to the submitter of the
      message via mail.
  
  2.2.4.  Expires
  
      This line, if present, is in a legal USENET date format.  It
      specifies a suggested expiration date for the message.  If not
      present, the local default expiration date is used.  This field is
      intended to be used to clean up messages with a limited usefulness,
      or to keep important messages around for longer than usual.  For
      example, a message announcing an upcoming seminar could have an
      expiration date the day after the seminar, since the message is not
      useful after the seminar is over.  Since local hosts have local
      policies for expiration of news (depending on available disk space,
      for instance), users are discouraged from providing expiration dates
      for messages unless there is a natural expiration date associated
      with the topic.  System software should almost never provide a
      default "Expires" line.  Leave it out and allow local policies to be
      used unless there is a good reason not to.
  
  
  
  
  
  
  Horton & Adams                                                  [Page 8]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
  2.2.5.  References
  
      This field lists the Message-ID's of any messages prompting the
      submission of this message.  It is required for all follow-up
      messages, and forbidden when a new subject is raised.
      Implementations should provide a follow-up command, which allows a
      user to post a follow-up message.  This command should generate a
      "Subject" line which is the same as the original message, except
      that if the original subject does not begin with "Re:" or "re:", the
      four characters "Re:" are inserted before the subject.  If there is
      no "References" line on the original header, the "References" line
      should contain the Message-ID of the original message (including the
      angle brackets).  If the original message does have a "References"
      line, the follow-up message should have a "References" line
      containing the text of the original "References" line, a blank, and
      the Message-ID of the original message.
  
      The purpose of the "References" header is to allow messages to be
      grouped into conversations by the user interface program.  This
      allows conversations within a newsgroup to be kept together, and
      potentially users might shut off entire conversations without
      unsubscribing to a newsgroup.  User interfaces need not make use of
      this header, but all automatically generated follow-ups should
      generate the "References" line for the benefit of systems that do
      use it, and manually generated follow-ups (e.g., typed in well after
      the original message has been printed by the machine) should be
      encouraged to include them as well.
  
      It is permissible to not include the entire previous "References"
      line if it is too long.  An attempt should be made to include a
      reasonable number of backwards references.
  
  2.2.6.  Control
  
      If a message contains a "Control" line, the message is a control
      message.  Control messages are used for communication among USENET
      host machines, not to be read by users.  Control messages are
      distributed by the same newsgroup mechanism as ordinary messages.
      The body of the "Control" header line is the message to the host.
  
      For upward compatibility, messages that match the newsgroup pattern
      "all.all.ctl" should also be interpreted as control messages.  If no
      "Control" header is present on such messages, the subject is used as
      the control message.  However, messages on newsgroups matching this
      pattern do not conform to this standard.
  
  
  
  
  
  
  Horton & Adams                                                  [Page 9]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      Also for upward compatibility, if the first 4 characters of the
      "Subject:" line are "cmsg", the rest of the "Subject:" line should
      be interpreted as a control message.
  
  2.2.7.  Distribution
  
      This line is used to alter the distribution scope of the message.
      It is a comma separated list similar to the "Newsgroups" line.  User
      subscriptions are still controlled by "Newsgroups", but the message
      is sent to all systems subscribing to the newsgroups on the
      "Distribution" line in addition to the "Newsgroups" line.  For the
      message to be transmitted, the receiving site must normally receive
      one of the specified newsgroups AND must receive one of the
      specified distributions.  Thus, a message concerning a car for sale
      in New Jersey might have headers including:
  
                     Newsgroups: rec.auto,misc.forsale
                     Distribution: nj,ny
  
      so that it would only go to persons subscribing to rec.auto or misc.
      for sale within New Jersey or New York.  The intent of this header
      is to restrict the distribution of a newsgroup further, not to
      increase it.  A local newsgroup, such as nj.crazy-eddie, will
      probably not be propagated by hosts outside New Jersey that do not
      show such a newsgroup as valid.  A follow-up message should default
      to the same "Distribution" line as the original message, but the
      user can change it to a more limited one, or escalate the
      distribution if it was originally restricted and a more widely
      distributed reply is appropriate.
  
  2.2.8.  Organization
  
      The text of this line is a short phrase describing the organization
      to which the sender belongs, or to which the machine belongs.  The
      intent of this line is to help identify the person posting the
      message, since host names are often cryptic enough to make it hard
      to recognize the organization by the electronic address.
  
  2.2.9.  Keywords
  
      A few well-selected keywords identifying the message should be on
      this line.  This is used as an aid in determining if this message is
      interesting to the reader.
  
  2.2.10.  Summary
  
      This line should contain a brief summary of the message.  It is
      usually used as part of a follow-up to another message.  Again, it
  
  
  
  Horton & Adams                                                 [Page 10]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      is very useful to the reader in determining whether to read the
      message.
  
  2.2.11.  Approved
  
      This line is required for any message posted to a moderated
      newsgroup.  It should be added by the moderator and consist of his
      mail address.  It is also required with certain control messages.
  
  2.2.12.  Lines
  
      This contains a count of the number of lines in the body of the
      message.
  
  2.2.13.  Xref
  
      This line contains the name of the host (with domains omitted) and a
      white space separated list of colon-separated pairs of newsgroup
      names and message numbers.  These are the newsgroups listed in the
      "Newsgroups" line and the corresponding message numbers from the
      spool directory.
  
      This is only of value to the local system, so it should not be
      transmitted.  For example, in:
  
                 Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
                 From: reid@decwrl.DEC.COM (Brian Reid)
                 Newsgroups: news.lists,news.groups
                 Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
                 Message-ID: <5658@decwrl.DEC.COM>
                 Date: 1 Oct 86 11:26:15 GMT
                 Organization: DEC Western Research Laboratory
                 Lines: 441
                 Approved: reid@decwrl.UUCP
                 Xref: seismo news.lists:461 news.groups:6378
  
      the "Xref" line shows that the message is message number 461 in the
      newsgroup news.lists, and message number 6378 in the newsgroup
      news.groups, on host seismo.  This information may be used by
      certain user interfaces.
  
  3.  Control Messages
  
      This section lists the control messages currently defined.  The body
      of the "Control" header line is the control message.  Messages are a
      sequence of zero or more words, separated by white space (blanks or
      tabs).  The first word is the name of the control message, remaining
      words are parameters to the message.  The remainder of the header
  
  
  
  Horton & Adams                                                 [Page 11]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      and the body of the message are also potential parameters; for
      example, the "From" line might suggest an address to which a
      response is to be mailed.
  
      Implementors and administrators may choose to allow control messages
      to be carried out automatically, or to queue them for annual
      processing.  However, manually processed messages should be dealt
      with promptly.
  
      Failed control messages should NOT be mailed to the originator of
      the message, but to the local "usenet" account.
  
  3.1.  Cancel
  
                       cancel <Message-ID>
  
  
      If a message with the given Message-ID is present on the local
      system, the message is cancelled.  This mechanism allows a user to
      cancel a message after the message has been distributed over the
      network.
  
      If the system is unable to cancel the message as requested, it
      should not forward the cancellation request to its neighbor systems.
  
      Only the author of the message or the local news administrator is
      allowed to send this message.  The verified sender of a message is
      the "Sender" line, or if no "Sender" line is present, the "From"
      line.  The verified sender of the cancel message must be the same as
      either the "Sender" or "From" field of the original message.  A
      verified sender in the cancel message is allowed to match an
      unverified "From" in the original message.
  
  3.2.  Ihave/Sendme
  
                     ihave <Message-ID list> [<remotesys>]
                     sendme <Message-ID list> [<remotesys>]
  
      This message is part of the ihave/sendme protocol, which allows one
      host (say A) to tell another host (B) that a particular message has
      been received on A.  Suppose that host A receives message
      "<1234@ucbvax.Berkeley.edu>", and wishes to transmit the message to
      host B.
  
      A sends the control message "ihave <1234@ucbvax.Berkeley.edu> A" to
      host B (by posting it to newsgroup to.B).  B responds with the
      control message "sendme <1234@ucbvax.Berkeley.edu> B" (on newsgroup
      to.A), if it has not already received the message.  Upon receiving
  
  
  
  Horton & Adams                                                 [Page 12]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      the sendme message, A sends the message to B.
  
      This protocol can be used to cut down on redundant traffic between
      hosts.  It is optional and should be used only if the particular
      situation makes it worthwhile.  Frequently, the outcome is that,
      since most original messages are short, and since there is a high
      overhead to start sending a new message with UUCP, it costs as much
      to send the ihave as it would cost to send the message itself.
  
      One possible solution to this overhead problem is to batch requests.
      Several Message-ID's may be announced or requested in one message.
      If no Message-ID's are listed in the control message, the body of
      the message should be scanned for Message-ID's, one per line.
  
  3.3.  Newgroup
  
                        newgroup <groupname> [moderated]
  
      This control message creates a new newsgroup with the given name.
      Since no messages may be posted or forwarded until a newsgroup is
      created, this message is required before a newsgroup can be used.
      The body of the message is expected to be a short paragraph
      describing the intended use of the newsgroup.
  
      If the second argument is present and it is the keyword moderated,
      the group should be created moderated instead of the default of
      unmoderated.  The newgroup message should be ignored unless there is
      an "Approved" line in the same message header.
  
  3.4.  Rmgroup
  
                              rmgroup <groupname>
  
      This message removes a newsgroup with the given name.  Since the
      newsgroup is removed from every host on the network, this command
      should be used carefully by a responsible administrator.  The
      rmgroup message should be ignored unless there is an "Approved:"
      line in the same message header.
  
  
  
  
  
  
  
  
  
  
  
  
  
  Horton & Adams                                                 [Page 13]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
  3.5.  Sendsys
                             sendsys (no arguments)
  
      The sys file, listing all neighbors and the newsgroups to be sent to
      each neighbor, will be mailed to the author of the control message
      ("Reply-To", if present, otherwise "From").  This information is
      considered public information, and it is a requirement of membership
      in USENET that this information be provided on request, either
      automatically in response to this control message, or manually, by
      mailing the requested information to the author of the message.
      This information is used to keep the map of USENET up to date, and
      to determine where netnews is sent.
  
      The format of the file mailed back to the author should be the same
      as that of the sys file.  This format has one line per neighboring
      host (plus one line for the local host), containing four colon
      separated fields.  The first field has the host name of the
      neighbor, the second field has a newsgroup pattern describing the
      newsgroups sent to the neighbor.  The third and fourth fields are
      not defined by this standard.  The sys file is not the same as the
      UUCP L.sys file.  A sample response is:
  
        From: cbosgd!mark  (Mark Horton)
        Date: Sun, 27 Mar 83 20:39:37 -0500
        Subject: response to your sendsys request
        To: mark@cbosgd.ATT.COM
  
        Responding-System: cbosgd.ATT.COM
        cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
              test
        ucbvax:world,comp,to.ucbvax:L:
        cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews
              /cbosg
        cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
        sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews
              /sescent
        npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
        mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
  
  3.6.  Version
  
                             version (no arguments)
  
      The name and version of the software running on the local system is
      to be mailed back to the author of the message ("Reply-to" if
      present, otherwise "From").
  
  3.7.  Checkgroups
  
  
  
  Horton & Adams                                                 [Page 14]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      The message body is a list of "official" newsgroups and their
      description, one group per line.  They are compared against the list
      of active newsgroups on the current host.  The names of any obsolete
      or new newsgroups are mailed to the user "usenet" and descriptions
      of the new newsgroups are added to the help file used when posting
      news.
  
  4.  Transmission Methods
  
      USENET is not a physical network, but rather a logical network
      resting on top of several existing physical networks.  These
      networks include, but are not limited to, UUCP, the Internet, an
      Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET.
      What is important is that two neighboring systems on USENET have
      some method to get a new message, in the format listed here, from
      one system to the other, and once on the receiving system, processed
      by the netnews software on that system.  (On UNIX systems, this
      usually means the rnews program being run with the message on the
      standard input. <1>)
  
      It is not a requirement that USENET hosts have mail systems capable
      of understanding the Internet mail syntax, but it is strongly
      recommended.  Since "From", "Reply-To", and "Sender" lines use the
      Internet syntax, replies will be difficult or impossible without an
      Internet mailer.  A host without an Internet mailer can attempt to
      use the "Path" header line for replies, but this field is not
      guaranteed to be a working path for replies.  In any event, any host
      generating or forwarding news messages must have an Internet address
      that allows them to receive mail from hosts with Internet mailers,
      and they must include their Internet address on their From line.
  
  4.1.  Remote Execution
  
      Some networks permit direct remote command execution.  On these
      networks, news may be forwarded by spooling the rnews command with
      the message on the standard input.  For example, if the remote
      system is called remote, news would be sent over a UUCP link
      with the command:
  
                                uux - remote!rnews
  
      and on a Berknet:
  
                                net -mremote rnews
  
  
  
  
  
  
  
  Horton & Adams                                                 [Page 15]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      It is important that the message be sent via a reliable mechanism,
      normally involving the possibility of spooling, rather than direct
      real-time remote execution.  This is because, if the remote system
      is down, a direct execution command will fail, and the message will
      never be delivered.  If the message is spooled, it will eventually
      be delivered when both systems are up.
  
  4.2.  Transfer by Mail
  
      On some systems, direct remote spooled execution is not possible.
      However, most systems support electronic mail, and a news message
      can be sent as mail.  One approach is to send a mail message which
      is identical to the news message: the mail headers are the news
      headers, and the mail body is the news body.  By convention, this
      mail is sent to the user newsmail on the remote machine.
  
      One problem with this method is that it may not be possible to
      convince the mail system that the "From" line of the message is
      valid, since the mail message was generated by a program on a
      system different from the source of the news message.  Another
      problem is that error messages caused by the mail transmission
      would be sent to the originator of the news message, who has no
      control over news transmission between two cooperating hosts
      and does not know whom to contact.  Transmission error messages
      should be directed to a responsible contact person on the
      sending machine.
  
      A solution to this problem is to encapsulate the news message into a
      mail message, such that the entire message (headers and body) are
      part of the body of the mail message.  The convention here is that
      such mail is sent to user rnews on the remote system.  A mail
      message body is generated by prepending the letter N to each line of
      the news message, and then attaching whatever mail headers are
      convenient to generate.  The N's are attached to prevent any special
      lines in the news message from interfering with mail transmission,
      and to prevent any extra lines inserted by the mailer (headers,
      blank lines, etc.) from becoming part of the news message.  A
      program on the receiving machine receives mail to rnews, extracting
      the message itself and invoking the rnews program.  An example in
      this format might look like this:
  
  
  
  
  
  
  
  
  
  
  
  Horton & Adams                                                 [Page 16]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
                  Date: Mon, 3 Jan 83 08:33:47 MST
                  From: news@cbosgd.ATT.COM
                  Subject: network news message
                  To: rnews@npois.ATT.COM
  
                  NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
                  NFrom: derek@sask.UUCP (Derek Andrew)
                  NNewsgroups: misc.test
                  NSubject: necessary test
                  NMessage-ID: <176@sask.UUCP>
                  NDate: Mon, 3 Jan 83 00:59:15 MST
                  N
                  NThis really is a test.  If anyone out there more than 6
                  Nhops away would kindly confirm this note I would
                  Nappreciate it.  We suspect that our news postings
                  Nare not getting out into the world.
                  N
  
      Using mail solves the spooling problem, since mail must always be
      spooled if the destination host is down.  However, it adds more
      overhead to the transmission process (to encapsulate and extract the
      message) and makes it harder for software to give different
      priorities to news and mail.
  
  4.3.  Batching
  
      Since news messages are usually short, and since a large number of
      messages are often sent between two hosts in a day, it may make
      sense to batch news messages.  Several messages can be combined into
      one large message, using conventions agreed upon in advance by the
      two hosts.  One such batching scheme is described here; its use is
      highly recommended.
  
      News messages are combined into a script, separated by a header of
      the form:
  
  
                     #! rnews 1234
  
      where 1234 is the length of the message in bytes.  Each such line is
      followed by a message containing the given number of bytes.  (The
      newline at the end of each line of the message is counted as one
      byte, for purposes of this count, even if it is stored as <CARRIAGE
      RETURN><LINE FEED>.)  For example, a batch of message might look
      like this:
  
  
  
  
  
  
  Horton & Adams                                                 [Page 17]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
                  #! rnews 239
                  From: jerry@eagle.ATT.COM (Jerry Schwarz)
                  Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                  Newsgroups: news.announce
                  Subject: Usenet Etiquette -- Please Read
                  Message-ID: <642@eagle.ATT.COM>
                  Date: Fri, 19 Nov 82 16:14:55 EST
                  Approved: mark@cbosgd.ATT.COM
  
                  Here is an important message about USENET Etiquette.
                  #! rnews 234
                  From: jerry@eagle.ATT.COM (Jerry Schwarz)
                  Path: cbosgd!mhuxj!mhuxt!eagle!jerry
                  Newsgroups: news.announce
                  Subject: Notes on Etiquette message
                  Message-ID: <643@eagle.ATT.COM>
                  Date: Fri, 19 Nov 82 17:24:12 EST
                  Approved: mark@cbosgd.ATT.COM
  
                  There was something I forgot to mention in the last
                  message.
  
      Batched news is recognized because the first character in the
      message is #.  The message is then passed to the unbatcher for
      interpretation.
  
      The second argument (in this example rnews) determines which
      batching scheme is being used.  Cooperating hosts may use whatever
      scheme is appropriate for them.
  
  5.  The News Propagation Algorithm
  
      This section describes the overall scheme of USENET and the
      algorithm followed by hosts in propagating news to the entire
      logical network.  Since all hosts are affected by incorrectly
      formatted messages and by propagation errors, it is important
      for the method to be standardized.
  
      USENET is a directed graph.  Each node in the graph is a host
      computer, and each arc in the graph is a transmission path from
      one host to another host.  Each arc is labeled with a newsgroup
      pattern, specifying which newsgroup classes are forwarded along
      that link.  Most arcs are bidirectional, that is, if host A
      sends a class of newsgroups to host B, then host B usually sends
      the same class of newsgroups to host A.  This bidirectionality
      is not, however, required.
  
      USENET is made up of many subnetworks.  Each subnet has a name, such
  
  
  
  Horton & Adams                                                 [Page 18]
  
  RFC 1036              Standard for USENET Messages         December 1987
  
  
      as comp or btl.  Each subnet is a connected graph, that is, a path
      exists from every node to every other node in the subnet.  In
      addition, the entire graph is (theoretically) connected.  (In
      practice, some political considerations have caused some hosts to be
      unable to post messages reaching the rest of the network.)
  
      A message is posted on one machine to a list of newsgroups. That
      machine accepts it locally, then forwards it to all its neighbors
      that are interested in at least one of the newsgroups of the
      message.  (Site A deems host B to be "interested" in a newsgroup if
      the newsgroup matches the pattern on the arc from A to B.  This
      pattern is stored in a file on the A machine.)  The hosts receiving
      the incoming message examine it to make sure they really want the
      message, accept it locally, and then in turn forward the message to
      all their interested neighbors.  This process continues until the
      entire network has seen the message.
  
      An important part of the algorithm is the prevention of loops.  The
      above process would cause a message to loop along a cycle forever.
      In particular, when host A sends a message to host B, host B will
      send it back to host A, which will send it to host B, and so on.
      One solution to this is the history mechanism.  Each host keeps
      track of all messages it has seen (by their Message-ID) and
      whenever a message comes in that it has already seen, the incoming
      message is discarded immediately.  This solution is sufficient to
      prevent loops, but additional optimizations can be made to avoid
      sending messages to hosts that will simply throw them away.
  
      One optimization is that a message should never be sent to a machine
      listed in the "Path" line of the header.  When a machine name is
      in the "Path" line, the message is known to have passed through the
      machine.  Another optimization is that, if the message originated
      on host A, then host A has already seen the message.  Thus, if a
      message is posted to newsgroup misc.misc, it will match the pattern
      misc.all (where all is a metasymbol that matches any string), and
      will be forwarded to all hosts that subscribe to misc.all (as
      determined by what their neighbors send them).  These hosts make up
      the misc subnetwork.  A message posted to btl.general will reach all
      hosts receiving btl.all, but will not reach hosts that do not get
      btl.all.  In effect, the messages reaches the btl subnetwork.  A
      messages posted to newsgroups misc.misc,btl.general will reach all
      hosts subscribing to either of the two classes.
  
  Notes
  
      <1>  UNIX is a registered trademark of AT&T.
  
  
  
  
  
  Horton & Adams                                                 [Page 19]
  
  
  
  
  
  
  1.1                  jakarta-james/docs/rfclist/README
  
  Index: README
  ===================================================================
  This Document contains references to relevant RFCs and Drafts.
  
  Basic RFC
  ---------
  RFC 822: Mail Message Format
  
  SMTP
  ----
  
  POP3
  ----
  
  IMAP
  ----
  
  NNTP
  ----
  RFC 977 : NNTP Protocol.
  draft-ietf-nntpext-base-13.txt: Latest draft of NNTP protocol
  RFC 2980: Common NNTP Extensions
  RFC 1036: Format of News Messages
  NNTP Working group: http://www.academ.com/academ/nntp/
  
  LDAP
  ----
  
  
  1.1                  jakarta-james/docs/rfclist/draft-ietf-nntpext-base-13.txt
  
  Index: draft-ietf-nntpext-base-13.txt
  ===================================================================
  
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                             Network News Transport Protocol 
  
                             draft-ietf-nntpext-base-13.txt 
  
            1. Status of this Document 
             
              This document is an Internet-Draft and is in full conformance 
              with Section 10 of RFC 2026. Internet-Drafts are working 
              documents of the Internet Engineering Task Force (IETF), its 
              areas, and its working groups.  Note that other groups may 
              also distribute working documents as Internet-Drafts. 
              Internet-Drafts are draft documents valid for a maximum of six 
              months and may be updated, replaced, or made obsolete by other 
              documents at any time.  It is inappropriate to use Internet-
              Drafts as reference material or to cite them other than as 
              "work in progress." 
  
              The list of current Internet-Drafts can be accesses at 
              http://www.ietf.org/ietf/1id-abstracts.txt. 
              The list of Internet-Draft shadow directories can be accessed 
              at http://www.ietf.org/shadow.html. 
  
              This section will be updated with the appropriate verbiage 
              from RFC 2223 should this document has been found ready for 
              publication as an RFC.  
  
              This document is a product of the NNTP Working Group, chaired 
              by Ned Freed and Stan Barber. 
  
            2. Abstract 
             
              The Network News Transport Protocol has been in use in the 
              Internet for a decade and remains one of the most popular 
              protocols (by volume) in use today. This document is a 
              replacement for RFC 977 and officially updates the protocol 
              specification. It clarifies some vagueness in RFC 977, 
              includes some new base functionality and provides a specific 
              mechanism to add standardized extensions to NNTP. 
  
            3. Introduction 
             
              This document specifies the Network News Transport Protocol 
              (NNTP), which is used for the distribution, inquiry, 
              retrieval, and posting of net news articles using a reliable 
              stream-based mechanism. For news reading clients, NNTP enables 
              retrieval of news articles that are stored in a central 
  
  
            Barber                                              [Page 1] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              database, giving subscribers the ability to select only those 
              articles they wish to read. 
  
              The netnews model provides for indexing, cross-referencing, 
              and expiration of aged messages. For server-to-server 
              interaction, NNTP is designed for efficient transmission of 
              net news articles over a reliable full duplex communication 
              method. 
  
              Every attempt is made to insure that the protocol 
              specification in this document is compatible with the version 
              specified in RFC 977[1]. However, this version does not 
              support the ill-defined SLAVE command and permits four digit 
              years to be specified in the NEWNEWS and NEWGROUPS commands. 
              It changes the default character set to UTF-8[2] instead of 
              US-ASCII[3]. It also extends the newsgroup name matching 
              capabilities already documented in RFC 977. 
  
              Generally, new functionality is available using new keywords. 
              Part of that new functionality involves a mechanism to 
              discover what new functionality is available to clients from a 
              server. 
  
              This mechanism can also be used to add more functionality as 
              needs merit such additions. 
  
              The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
              NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
              "OPTIONAL" in this document are to be interpreted as described 
              in RFC 2119[4]. 
  
              An implementation is not compliant if it fails to satisfy one 
              or more of the MUST requirements for this protocol.  An 
              implementation that satisfies all the MUST and all the SHOULD 
              requirements for its protocols is said to be "unconditionally 
              compliant"; one that satisfies all the MUST requirements but 
              not all the SHOULD requirements for NNTP is said to be 
              "conditionally compliant". 
  
              For the remainder of this memo, the term "client host" refers 
              to a host making use of the NNTP service, while the term 
              "server host" refers to a host that offers the NNTP service. 
  
              In addition, where examples of interactions between a client 
              host and a server host are provided a "[C]" will be used to 
              represent the client host and a "[S]" will be used to 
              represent the server host.  
  
            4. Basic Operation. 
             
              Every NNTP session MUST involve the following in this order: 
  
  
  
            Barber                                              [Page 2] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              CONNECTION 
              GREETING 
              DISCONNECTION 
             
              Other steps may occur between the GREETING and DISCONNECTION 
              step. They are: 
  
              CAPABILITIES DISCOVERY 
              NEWS EXCHANGE 
              CONCLUSION 
  
              NNTP operates over any reliable data stream 8-bit-wide 
              channel. When running over TCP/IP, the official port for the 
              NNTP service is 119. Initially, the server host starts the 
              NNTP service by listening on a TCP port.  When a client host 
              wishes to make use of the service, it MUST establish a TCP 
              connection with the server host by connecting to that host on 
              the same port on which the server is listening. This is the 
              CONNECTION step.  When the connection is established, the NNTP 
              server host MUST send a greeting. This is the GREETING step. 
              The client host and server host SHOULD then exchange commands 
              and responses (respectively) until the connection is closed or 
              aborted. This final step is called the DISCONNECTION step.  
  
              If there is a CONCLUSION step, it MUST immediately precede the 
              DISCONNECTION step. There MUST be only one CONNECTION, 
              CONCLUSION and DISCONNECTION step for each NNTP session. All 
              other steps MAY be repeated as needed. For example, the 
              GREETING step may be repeated if the client makes use of the 
              MODE READER command (See Section 7.2 for more on the MODE 
              READER command). 
  
              The character set for all NNTP commands is UTF-8. Commands in 
              the NNTP MUST consist of an US-ASCII case-insensitive keyword, 
              which MAY be followed by one or more arguments.  An US-ASCII 
              CRLF pair MUST terminate all commands. Multiple commands MUST 
              NOT be on the same line. Keywords MUST consist of printable 
              US-ASCII characters.  Unless otherwise noted elsewhere in this 
              document, arguments SHOULD consist of printable US-ASCII 
              characters. Keywords and arguments MUST be each separated by 
              one or more US-ASCII SPACE or US-ASCII TAB characters. 
              Keywords MUST be at least three US-ASCII characters and MUST 
              NOT exceed 12 US-ASCII characters.  Command lines MUST NOT 
              exceed 512 octets, which includes the terminating US-ASCII 
              CRLF pair. Arguments MUST NOT exceed 497 octets. 
  
              Each response MUST start with a three-digit response code that 
              is sufficient to distinguish all responses. Certain valid 
              responses are defined to be multi-line; for all others, the 
              response is contained in a single line. All multi-line 
  
  
            Barber                                              [Page 3] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              responses MUST adhere to the following format: After sending 
              the first line of the response and an US-ASCII CRLF, any 
              additional lines are sent, each terminated by an US-ASCII CRLF 
              pair. When all lines of the response have been sent, a final 
              line MUST be sent, consisting of a termination octet (US-ASCII 
              decimal code 046, ".") and an US-ASCII CRLF pair.  If any line 
              of the multi-line response begins with the termination octet, 
              the line MUST be "byte-stuffed" by pre-pending the termination 
              octet to that line of the response. Hence, a multi-line 
              response is terminated with the five octets "CRLF.CRLF" (in 
              US-ASCII).  When examining a multi-line response, the client 
              MUST check to see if the line begins with the termination 
              octet. If so and if octets other than US-ASCII CRLF follow, 
              the first octet of the line (the termination octet) MUST be 
              stripped away.  If so and if US-ASCII CRLF immediately follows 
              the termination character, then the response from the NNTP 
              server is ended and the line containing ".CRLF" (in US-ASCII) 
              MUST NOT be considered part of the multi-line response. Where 
              a response is multi-line, the description of the command will 
              define the format of the response before "byte-stuffing" takes 
              place.   
  
              An NNTP server MAY have an inactivity autologout timer. Such a 
              timer MUST be of at least three minutes duration.  The receipt 
              of any command from the client during that interval SHOULD 
              suffice to reset the autologout timer.  When the timer 
              expires, the server should close the TCP connection without 
              sending any response to the client. 
  
            4.1  Response Codes 
             
              Each response MUST begin with a three-digit status indicator. 
              These are status reports from the server and indicate the 
              response to the last command received from the client. 
  
              The first digit of the response broadly indicates the success, 
              failure, or progress of the previous command. 
  
              1xx - Informative message 
              2xx - Command ok 
              3xx - Command ok so far, send the rest of it.   
              4xx - Command was correct, but couldn't be performed for some 
                 reason. 
              5xx - Command unimplemented, or incorrect, or a serious 
                 program error occurred. 
  
              The next digit in the code indicates the function response 
              category. 
  
              x0x - Connection, setup, and miscellaneous messages 
  
  
            Barber                                              [Page 4] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              x1x - Newsgroup selection 
              x2x - Article selection 
              x3x - Distribution functions 
              x4x - Posting 
              x8x - Reserved for authentication and authorization extensions 
              x9x - Reserved for private use (non-standard extensions) 
             
              Certain responses contain parameters such as numbers and names 
              in addition to the status indicator. In those cases, the 
              number and type of such parameters is fixed for each response 
              code to simplify interpretation by the client (any extension 
              MUST follow this principle as well). In all other cases, the 
              client MUST only use the status indicator itself to determine 
              the nature of the response. The exact response codes that can 
              be returned in response to a given command are detailed in the 
              description of the keyword that is the first part of the 
              command.  
  
              Parameters MUST be separated from the numeric status indicator 
              and from each other by a single US-ASCII space. All numeric 
              parameters MUST be in base 10 (decimal) format, and MAY have 
              leading zeros. String parameters MUST contain at least one 
              character and MUST NOT contain US-ASCII spaces, CR, LF, or 
              tab). The server MAY add any text after the response code or 
              last parameter as appropriate, and the client MUST NOT make 
              decisions based on this text. Such text MUST be separated from 
              the numeric status indicator or the last parameter by at least 
              one US-ASCII space. 
  
              The server MUST respond to any command with the appropriate 
              generic response (given in section 4.1.1) if it represents the 
              situation. Otherwise, each recognized command MUST return one 
              of the response codes specifically listed in its description 
              or in an extension. A server MAY provide extensions to this 
              specification, including new commands, new features of 
              existing commands, and other ways of changing the internal 
              state of the server. However, the server MUST NOT produce any 
              other responses to a client that does not invoke any of the 
              additional features. (Therefore a client that restricts itself 
              to this specification will only receive the responses that are 
              listed). 
  
              Each recognized command MUST return 501 (as above) or one of 
              the response codes specifically listed in its description or 
              in an extension. A server MAY provide extensions to this 
              specification, including new commands, new features of 
              existing commands, and other ways of changing the internal 
              state of the server. However, the server MUST NOT produce any 
              other responses to a client that does not invoke any of the 
  
  
            Barber                                              [Page 5] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              additional features. (Therefore a client that restricts itself 
              to this specification will only receive the responses that are 
              listed). 
  
              If a client receives an unexpected response, it SHOULD use the 
              first digit of the response to determine the result. For 
              example, an unexpected 2xx should be taken as success and an 
              unexpected 4xx or 5xx as failure. 
  
              Response codes not specified in this standard MAY be used for 
              any installation-specific additional commands also not 
              specified. These SHOULD be chosen to fit the pattern of x9x 
              specified above. 
  
              Neither this document nor any extension registered with IANA 
              (see section 12) will specify any response codes of the x9x 
              pattern. (Implementers of extensions are accordingly cautioned 
              not to use such responses for extensions that may subsequently 
              be submitted for registration.) 
  
            4.1.1 Generic Response Codes 
  
              The server MUST respond to any command with the appropriate 
              one of the following generic responses if it represents the 
              situation. 
  
              If the command is not recognized, or it is an optional command 
              or extension that is not implemented by the server, the 
              response code 500 MUST be returned. 
  
              If there is a syntax error in the arguments of a recognized 
              command, the response code 501 MUST be returned. Note that 
              where a command has variants depending on a keyword (e.g. LIST 
              ACTIVE and LIST NEWSGROUPS), then 501 MUST be used when the 
              requested variant is not implemented but the base command is. 
  
              If the client is not authorized to use the specified facility 
              when the server is in its current state, the response code 502 
              MUST be returned. A different command MIGHT change the server 
              state and permit the command if it is retried. 
  
              If the server does not provide an optional feature, then the 
              response code 403 MUST be returned if the omission is 
              temporary (e.g. because a necessary facility is unavailable) 
              and the code 503 if it is permanent  (e.g. because the server 
              does not store the required information). 
  
              If the server has to terminate the connection for some reason, 
              it MUST give a 400 response code to the next command and then 
              immediately close the TCP connection. It MAY give a 401 
              response code to any command to indicate that termination is 
  
  
  
            Barber                                              [Page 6] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              imminent (following a 401 response, it MUST NOT close the TCP 
              connection immediately). 
  
            5. The WILDMAT format 
             
              The WILDMAT format[5] described here is based on the version 
              first developed by Rich Salz which was derived from the format 
              used in the UNIX "find" command to articulate file names. It 
              was developed to provide a uniform mechanism for matching 
              patterns in the same manner that the UNIX shell matches 
              filenames. Patterns are implicitly anchored at the beginning 
              and end of each string when testing for a match.  There are 
              five pattern-matching operations other than a strict one-to-
              one match between the pattern and the source to be checked for 
              a match. The first is an asterisk (*) to match any sequence of 
              zero or more UTF-8 characters. The second is a question mark 
              (?) to match any single UTF-8 character. The third specifies a 
              specific set of characters. The set is specified as a list of 
              characters, or as a range of characters where the beginning 
              and end of the range are separated by a minus (or dash) 
              character, or as any combination of lists and ranges. The dash 
              can also be included in the set as a character it if is the 
              beginning or end of the set. This set is enclosed in square 
              brackets. The close square bracket (]) may be used in a set if 
              it is the first character in the set. The fourth operation is 
              the same as the logical not of the third operation and is 
              specified the same way as the third with the addition of a 
              caret character (^) at the beginning of the test string just 
              inside the open square bracket. The final operation uses the 
              backslash character to invalidate the special meaning of the 
              open square bracket ([), the asterisk, backslash, or the 
              question mark. Two backslashes in sequence will result in the 
              evaluation of the backslash as a character with no special 
              meaning. 
  
              Implementers must be careful to apply the pattern-matching 
              operators to whole characters encoded in UTF-8, and not to 
              individual octets. 
  
            5.1 Negating the wildmat pattern 
             
              The exclamation point can be used at the beginning of a 
              wildmat to negate it. That is, if the remainder of the pattern 
              would match the string then the negated pattern does not, and 
              vice versa. If it appears as any other character other than 
              the first one, it has no special meaning. 
  
  
  
            Barber                                              [Page 7] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
            5.2 Examples  
             
                   a) [^]-] -- matches any single character other than a 
                      close square bracket or a minus sign/dash. 
                   b) *bdc  -- matches any string that ends with the string 
                      "bdc" including the string "bdc" (without quotes). 
                   c) [0-9a-zA-Z] -- matches any single printable 
                      alphanumeric ASCII character. 
                   d) a??d  --  matches any four character string which 
                      begins with a and ends with d. 
                   e)!bc*d -- matches any string that does not start with 
                      "bc" and end with "d" (without quotes) 
                   f)!\\x  -- matches any string that does not start with 
                      "\x" (without quotes) 
  
            6. Format for Keyword Descriptions 
             
              On the following pages are descriptions of each keyword 
              recognized by the NNTP server and the responses that will be 
              returned by those commands. These keywords are grouped by the 
              functional step in which they are used. 
  
              Each keyword is shown in upper case for clarity, although the 
              NNTP server ignores case in the interpretation of commands. 
  
              Parameters are shown as follows: 
  
                 . UPPERCASE    indicates literal text to be included in the 
                   command; 
                 . lowercase    indicates a token described elsewhere; 
                 . [brackets]   indicate that the parameter is optional; 
                 . ellipsis...  indicates that the parameter may be repeated 
                   any number of times (it must occur at least once); 
                 . vertical|bar indicates a choice of two mutually exclusive 
                   parameters (exactly one must be provided). 
  
              Parameters are case or language specific only when specified 
              (either in this document or in RFC 1036[6]). 
  
              The name "wildmat" for a parameter indicates that it is a 
              wildmat format pattern as defined in section 5. 
  
            7. The GREETING Step 
  
            7.1 Initial Connection 
             
              There is no keyword presented by the client upon initial 
              connection to the server. The server MUST present an 
              appropriate response code as a greeting to the client.  This 
  
  
            Barber                                              [Page 8] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              response informs the client about what steps the client should 
              take to reach the news exchange step. 
  
              If the server will accept further commands from the client 
              including POST, the server MUST present a 200 greeting code. 
              If the server will accept further commands from the client, 
              but it is not authorized to post articles using the POST 
              command, the server MUST present a 201 greeting code. 
  
              Otherwise the server MUST present a 400 or 502 greeting code 
              and then immediately close the connection. 502 MUST be used if 
              the client is not permitted under any circumstances to 
              interact with the server and 400 otherwise. 
  
            7.1.1 Initial Connection Example 
               
              Example of a normal connection from an authorized client 
                      [Initial TCP connection setup completed.] 
                      [C] Initial TCP connection completed 
                      [S] 200 NNTP Service Ready, posting permitted 
              Client can send commands at this point. In this example, the 
              client jumps directly to the conclusion step (See section 10). 
                      [C] QUIT 
                      [S] 205 NNTP Service exits normally 
                      [Server closes connection.] 
  
              Example of a normal connection from an unauthorized client 
                      [C] Initial TCP connection completed 
                      [S] 502 NNTP Service Unavailable 
                      [Server closes connection.] 
  
              Example of a normal connection from an authorized client that 
              is not permitted to post 
                      [Initial TCP connection setup completed.] 
                      [S] 201 NNTP Service Ready, posting prohibited 
              Client can send commands at this point. In this example, the 
              client jumps directly to the conclusion step (See section 10). 
                      [C] QUIT 
                      [S] 205 NNTP Service exits normally 
                      [Server closes connection.] 
  
  
  
            Barber                                              [Page 9] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Example of a connection from any client where the server is 
              unable to provide service 
                      [Initial TCP connection setup completed.] 
                      [S] 400 NNTP Service temporarily unavailable 
                      [Server closes connection.] 
  
            7.2 MODE READER 
               
              MODE READER 
  
              MODE READER SHOULD be sent by any client that intends to use 
              any command other than IHAVE, HEAD, STAT, LIST, LIST 
              EXTENSIONS, or commands advertised by the server as available 
              via LIST EXTENSIONS.  
  
              Servers MAY require that this command be issued before any 
              other commands are sent and MAY reject any other commands 
              until after a MODE READER command has been sent.  
  
              The server MUST present a response using the same codes as the  
              initial greeting (as described in section 7.1) to indicate its  
              ability to provide reading service to the client.  
  
              Clients SHOULD wait for a response to MODE READER after 
              sending this command and SHOULD NOT send any additional 
              commands until that response has been received from the 
              server.  
  
              Once MODE READER is sent, IHAVE (and any extensions intended 
              for peer-to-peer article transfer) MAY no longer be permitted, 
              even if it were permitted before the MODE READER command. The 
              results of LIST EXTENSIONS MAY be different following a 
              MODE READER command than prior to the issuing of that command.  
              Servers are encouraged to not require this command even though 
              clients SHOULD send it when appropriate. It is present to 
              support some news architectures that switch between modes 
              based on whether a given connection is a peer-to-peer 
              connection with another server or a news reading client. 
  
            7.2.1 Responses 
                   200 Posting Permitted 
                   201 Posting Not Permitted 
                   400 Service temporarily unavailable 
                   502 Service unavailable 
                    
              Following a 400 or 502 response the server MUST immediately 
              close the connection. 
  
  
            Barber                                             [Page 10] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Note that the response need not be the same as the one 
              presented during the initial greeting. 
  
            7.2.2 MODE READER Examples 
               
              Example of use of the MODE READER command by an authorized 
              client 
                      [C] MODE READER 
                      [S] 200 NNTP Service Ready, posting permitted 
              Client can send commands at this point. In this example, the 
              client jumps directly to the conclusion step (See section 10). 
                      [C] QUIT 
                      [S] 205 NNTP Service exits normally 
                      [Server closes connection.] 
  
              Example of use of MODE READER by a client not authorized to 
              receive service from the server as a news reader 
                      [C] MODE READER 
                      [S] 502 Service Unavailable 
                      [Server closes connection.] 
               
              Example of a normal connection from an authorized client that 
              is not permitted to post 
                      [C] MODE READER 
                      [S] 201 NNTP Service Ready, posting prohibited 
  
              Client can send commands at this point. In this example, the 
              client jumps directly to the conclusion step (See section 10). 
                      [C] QUIT 
                      [S] 205 NNTP Service exits normally 
                      [Server closes connection.] 
  
              Example of a connection from any client where the server is 
              unable to provide news reader service 
                      [C] MODE READER 
                      [S] 400 NNTP Service temporarily unavailable 
                      [Server closes connection.] 
             
  
  
  
            Barber                                             [Page 11] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
            8. The CAPABILITIES DISCOVERY Step 
             
              To discover what extensions are available, an NNTP client can 
              query the server with the LIST EXTENSIONS command. 
              If a particular extension is unavailable, the client can 
              attempt to work around it or it may wish to terminate the 
              session. 
  
              See section 12 for further discussion of extensions. 
  
            8.1 LIST EXTENSIONS 
             
              The LIST EXTENSIONS command allows a client to determine which 
              extensions are supported by the server. 
  
              To discover what extensions are available, an NNTP client 
              SHOULD query the server early in the session for extensions 
              information by issuing the LIST EXTENSIONS command. This 
              command MAY be issued at anytime during a session.  It is not 
              required that the client issues this command before attempting 
              to make use of any extension. The response generated by this 
              command MAY change during a session because of other state 
              information. However, an NNTP client MUST NOT cache (for use 
              in another session) any information returned if the LIST 
              EXTENSIONS command succeeds. That is, an NNTP client is only 
              able to get the current and correct information concerning 
              available extensions during a session by issuing a LIST 
              EXTENSIONS command during that session and processing that 
              response. 
  
              A successful response starts with a 202 code and is followed 
              by a list of extensions, one per line. Each line MUST begin 
              with exactly one space followed by an extension-label and 
              optionally one or more parameters (separated by single 
              spaces). The extension-label and the meaning of the parameters 
              are specified as part of the definition of the extension. The 
              extension-label MUST be in uppercase. 
  
              The server MUST NOT list the same extension twice in the 
              response, and MUST list all supported extensions. The order in 
              which the extensions are listed is not significant. The server 
              need not even consistently return the same order. 
  
              If the server does not support any extensions, it SHOULD 
              return a 402 failure response but MAY return an empty list 
              instead. 
  
  
  
  
  
            Barber                                             [Page 12] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
            8.1.1 Responses 
             
                   202        extension list follows (multiline) 
                   400        service about to terminate 
                   402        no extensions available 
                   503        unable to list extensions 
                    
              Following a 503 response an extension might still be 
              available, and the client MAY attempt to use it.
  
              The LIST EXTENSIONS command is optional, and a server MAY 
              issue a 500 (unknown command) or 501 (syntax error) response 
              to it. 
  
            8.1.1.1 LIST EXTENSIONS Examples 
             
              Example of a successful response: 
             
                      [C] LIST EXTENSIONS 
                      [S] 202 Extensions supported: 
                      [S]  OVER 
                      [S]  PAT 
                      [S]  LISTGROUP 
                      [S] . 
             
              The particular extensions shown here are simply examples of 
              what might be defined in other places, and no particular 
              meaning should be attributed to them. 
  
              Example where no extensions are available, using preferred 
              format:          
                     [C] LIST EXTENSIONS 
                     [S] 402 Server has no extensions 
               
              Example where no extensions are available, using an empty 
              list: 
                      [C] LIST EXTENSIONS 
                      [S] 202 Extensions supported: 
                      [S] . 
  
  
  
  
  
            Barber                                             [Page 13] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
            9. The NEWS EXCHANGE Step 
             
              During this step, two basic types of transactions occur: 
  
                 . article retrieval from the server 
                 . article posting to the server 
  
            9.1 Article Retrieval 
             
              News reading clients have available a variety of mechanisms to 
              retrieve articles via NNTP. The news articles are stored and 
              indexed using three types of keys. One key is the message id 
              of an article. According to RFC 1036, this identifier should 
              be globally unique. Another key is composed of the newsgroup 
              name and the article number within that newsgroup. That key 
              MUST be unique to a particular server (there will be only one 
              article with that number within a particular newsgroup), but 
              is not required to be globally unique.  Additionally, because 
              the same article can be cross-posted to multiple newsgroups, 
              there may be multiple keys that point to the same article on 
              the same server. The final key is the arrival timestamp, 
              giving the time that the article arrived at the server. 
  
              The server MUST ensure that article numbers are issued in 
              order of arrival timestamp; that is, articles arriving later 
              MUST have higher numbers than those that arrive earlier. The 
              server SHOULD allocate the next sequential unused number to 
              each new article. 
  
              Article numbers MUST lie between 1 and 4,294,967,295 
              inclusive. The client and server SHOULD NOT use leading zeroes 
              in specifying article numbers, and MUST NOT use more than 16 
              digits. In some situations, the value zero replaces an article 
              number to show some special situation.  
  
            9.1.1 Article Retrieval by Newsgroup Name and Article Number 
             
              The following commands are used to set the current newsgroup 
              name and the "current article pointer" which is used by other 
              commands for article retrieval. At the start of an NNTP 
              session, both of these values are undefined. 
  
            9.1.1.1 GROUP 
             
              GROUP ggg 
  
              The required parameter ggg is the name of the newsgroup to be 
              selected (e.g. "news.software.b"). A list of valid newsgroups 
  
  
            Barber                                             [Page 14] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              may be obtained by using the LIST keyword.  See section 9.4 
              for more information on the LIST keyword. 
  
              The successful selection response will return the article 
              numbers of the first and last articles in the group at the 
              moment of selection (these numbers are referred to as the 
              "reported low water mark" and the "reported high water mark"), 
              and an estimate of the number of articles on file in the 
              group. 
  
              If the group is not empty, the estimate MUST be at least the 
              actual number of articles available, and MUST be no greater 
              than one more than the difference between the reported low and 
              high water marks. (Some implementations will actually count 
              the number of articles on file. Others will just subtract the 
              low water mark from the high water mark and add one to get an 
              estimate.) 
  
              If the group is empty, one of the following three situations 
              will occur. Clients MUST accept all three cases; servers MUST 
              NOT represent an empty group in any other way. 
  
                 . The high water mark will be one less than the low water 
                   mark, and the estimated article count will be zero. 
                   Servers SHOULD use this method to show an empty group. 
                   This is the only time that the high water mark can be 
                   less than the low water mark. 
                 . All three numbers will be zero. 
                 . The high water mark is greater than or equal to the low 
                   water mark; the estimated article count might be zero or 
                   non-zero; if non-zero, the same requirements apply as for 
                   a non-empty group. 
             
              The set of articles in a group may change after the GROUP 
              command is carried out. That is: 
  
                 . articles may be removed from the group 
                 . articles may be reinstated in the group with the same 
                   article number, but those articles MUST have numbers no 
                   less than the reported low water mark (note that this is 
                   a reinstatement of the previous article, not a new 
                   article reusing the number) 
                 . new articles may be added with article numbers greater 
                   than the reported high water mark (if an article that was 
                   the one with the highest number has been removed, the 
                   next new article will not have the number one greater 
                   than the reported high water mark) 
               
  
  
  
            Barber                                             [Page 15] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Except when the group is empty and all three numbers are zero, 
              whenever a subsequent GROUP command for the same newsgroup is 
              issued, either by the same client or a different client, the 
              reported low water mark in the response MUST be no less than 
              that in any previous response for that newsgroup sent to any 
              client. The client may make use of the low water mark to 
              remove all remembered information about articles with lower 
              numbers, as these will never recur. This includes the 
              situation when the high water mark is one less than the low 
              water mark. 
  
              No similar assumption can be made about the high water mark, 
              as this can decrease if an article is removed, and then 
              increase again if it is reinstated or if new articles arrive. 
  
              When a valid group is selected by means of this command, the 
              internally maintained "current article pointer" MUST be set to 
              the first article in the group and the name of the current 
              newsgroup MUST be set to the selected newsgroup name. If an 
              invalid group is specified, the previously selected group, if 
              any, and article MUST remain selected. If an empty newsgroup 
              is selected, the "current article pointer" is in an 
              indeterminate state and MUST NOT be used. 
  
              The GROUP keyword (or the LISTGROUP keyword, if implemented) 
              MUST be used by a client and a successful response received 
              before the any other command is used that depends on having 
              the "current article pointer" be valid. 
             
  
            9.1.1.1.1 Responses 
             
                   211 n f l s group selected 
                   (n = estimated number of articles in group, f = first 
                      article number in the group, l = last article number 
                      in the group, s = name of the group.) 
                   411 no such newsgroup 
  
            9.1.1.1.2 GROUP Examples 
             
              Example for a group known to the server  
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
               
              Example for a group unknown to the server 
                      [C] GROUP example.is.sob.bradner.or.barber 
  
  
            Barber                                             [Page 16] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] 411 example.is.sob.bradner.or.barber is unknown 
  
            9.1.1.2   LAST 
             
              LAST 
  
              If the current newsgroup is valid, the internally maintained 
              "current article pointer" MUST be set to the previous article 
              in the current newsgroup.  If already positioned at the first 
              article of the newsgroup, an error message MUST be returned 
              and the current article MUST remain selected. 
  
              There MAY be no previous article in the group, although the 
              current article number is not the reported low water mark. 
  
              There MUST NOT be a previous article when the current article 
              number is the reported low water mark. 
  
              Because articles can be removed and added, the results of 
              multiple LAST and NEXT commands MAY not be consistent over the 
              life of a particular NNTP session. 
  
              If successful, a response indicating the current article 
              number and a message-id string MUST be returned. No article 
              text is sent in response to this command. 
  
            9.1.1.2.1 Responses 
             
                   223 n a article retrieved - request text separately (n = 
                      article number, a = unique article id) 
                   412 no newsgroup selected 
                   420 no current article has been selected 
                   422 no previous article in this group 
  
            9.1.1.2.2 LAST Examples 
             
              Example of a successful article retrieval using LAST 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] NEXT 
                      [S] 223 3000237 <668929@domain.com> retrieved 
                      [C] LAST 
                      [S] 223 3000234 <45223423@to.to> retrieved 
               
  
  
  
            Barber                                             [Page 17] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Example of an attempt to retrieve an article without having 
              selected a group (via the GROUP command) first 
                      [S] 200 NNTP Service ready 
                      [C] LAST 
                      [S] 412 no newsgroup selected 
               
              Example of an attempt to retrieve an article using the LAST 
              command when the current article pointer is pointing at the 
              first article in the group 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] LAST 
                      [S] 422 No previous article to retrieve 
               
              Example of an attempt to retrieve an article using the LAST 
              command when the current group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] LAST 
                      [S] 420 No current article selected 
  
            9.1.1.3 NEXT 
             
              NEXT 
  
              If the current newsgroup is valid, the internally maintained 
              "current article pointer" MUST be advanced to the next article 
              in the current newsgroup.  If no more articles remain in the 
              current group, an error message MUST be returned and the 
              current article MUST remain selected. 
  
              If successful, a response indicating the current article 
              number and the message-id string MUST be returned.  No article 
              text is sent in response to this command. 
             
  
            9.1.1.3.1 Responses 
             
  
  
            Barber                                             [Page 18] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                   223 n a article retrieved - request text separately (n = 
                      article number, a = unique article id) 
                   412 no newsgroup selected 
                   420 no current article has been selected 
                   421 no next article in this group 
  
            9.1.1.3.2 NEXT Examples 
             
              Example of a successful article retrieval using NEXT 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] NEXT 
                      [S] 223 3000237 <668929@domain.com> retrieved 
               
              Example of an attempt to retrieve an article without having 
              selected a group (via the GROUP command) first 
                      [S] 200 NNTP Service ready 
                      [C] NEXT 
                      [S] 412 no newsgroup selected 
               
              Example of an attempt to retrieve an article using the NEXT 
              command when the current article pointer is pointing at the 
              last article in the group 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] ARTICLE 3002322 
                      [S] 220 3002322 <411@whitehouse.gov> retrieved 
                      [S] Path: pathost!demo!whitehouse!not-for-mail 
                      [S] From: nobody@whitehouse.gov(Demo User) 
                      [S] Newsgroups: misc.test 
                      [S] Subject: I am just a test article 
                      [S] Date: 6 Oct 1998 04:38:40 -0500 
                      [S] Organization: The White House, Washington, DC 
                      [S] Message-ID: <411@whitehouse.gov> 
  
  
  
            Barber                                             [Page 19] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] 
                      [S] This is just a test article. 
                      [S] . 
                      [C] NEXT 
                      [S] 422 No next article to retrieve 
               
              Example of an attempt to retrieve an article using the NEXT 
              command when the current group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] NEXT 
                      [S] 420 No current article selected 
               
  
            9.2 Retrieval of Articles and Article Sections 
             
              The ARTICLE, BODY, HEAD, and STAT commands are very similar. 
              They differ only in the parts of the article that are 
              presented to the client and in the successful response code. 
  
              The ARTICLE command is described here in full, while the other 
              commands are described in terms of the differences. 
  
              An article, as defined by RFC 1036, consists of two parts: the 
              article headers and the article body. When responding to one 
              of these commands, the server presents the entire article or 
              appropriate part and does not attempt to alter or translate it 
              in any way. 
  
            9.2.1 ARTICLE 
             
              ARTICLE <message-id> 
  
              ARTICLE [number] 
  
              The ARTICLE command selects an article based on the arguments 
              and presents the header, a blank line, and the body of that 
              article. The command has two forms. 
  
              In the first form, a message-id is specified (including the 
              angle brackets), and the server presents the article with that 
              message-id in its headers. In this case, the server MUST NOT 
              alter the "current article pointer". This is both to 
  
  
            Barber                                             [Page 20] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              facilitate the presentation of articles that may be referenced 
              within another article being read, and because of the semantic 
              difficulties of determining the proper sequence and membership 
              of an article which may have been posted to more than one 
              newsgroup. 
  
              In the second form, an article number may be specified. If so, 
              and if there is an article with that number in the currently 
              selected group, the server MUST set the current article 
              pointer to that number. 
  
              Then, whether or not a number was specified, the article 
              indicated by the current article pointer is presented to the 
              client. 
  
              Note that a previously valid article number MAY become invalid 
              if the article has been removed. A previously invalid article 
              number MAY become valid if the article has been reinstated, 
              but such an article number MUST be no less than the reported 
              low water mark for that group. 
  
              The server MUST NOT change the currently selected group as a 
              result of this command. The server MUST NOT change the current 
              selected article except when an article number argument was 
              provided and the article exists; in particular, it MUST NOT 
              change it following an unsuccessful response. 
  
            9.2.1.1 Responses 
  
                   First form (message-id specified): 
                    
                   220 0 a     article retrieved and follows (multiline, a = 
                      unique article id) 
                   430         no such article 
                   502         service unavailable 
                    
                   Second form (optional article number specified): 
                    
                   220 n a     article retrieved and follows (multiline, n = 
                      article number, a = unique article id) 
                   412         no newsgroup selected 
                   420         no current article selected 
                   423         no such article number in this group 
                   502         service unavailable 
                    
              The 420 response only occurs if no article number has been 
              specified. 
  
              In the 220 response, the first parameter is 0 for the first 
              form and the article number (within the current group) for the 
  
  
            Barber                                             [Page 21] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              second form. The second parameter is the message-id of the 
              article (within angle brackets). This is taken from the 
              message-id header line of the article (required by RFC 1036). 
  
              If there is no such line, the message-id "<0>" MUST be used 
              instead (without the double quotes). 
  
              Since the message-id field is unique for each article, it may 
              be used by a client to skip duplicate displays of articles 
              that have been posted more than once, or to more than one 
              newsgroup. 
  
              The article headers and body are returned as a multiline 
              response following the initial response line. 
  
            9.2.1.2 Examples 
  
              Example of a successful retrieval of an article (using no 
              article number) 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] ARTICLE 
                      [S] 220 3000234 <45223423@to.to> 
                      [S] Path: pathost!demo!somewhere!not-for-mail 
                      [S] From: nobody@nowhere.to (Demo User) 
                      [S] Newsgroups: misc.test 
                      [S] Subject: I am just a test article 
                      [S] Date: 6 Oct 1998 04:38:40 -0500 
                      [S] Organization: Nowhere, To 
                      [S] Message-ID: <45223423@to.to> 
                      [S]  
                      [S] This is just a test article. 
                      [S] . 
  
              Example of a successful retrieval of an article by message-id 
                      [S] 200 NNTP Service Ready 
                      [C] ARTICLE <45223423@to.to> 
                      [S] 220 0 <45223423@to.to> 
                      [S] Path: pathost!demo!somewhere!not-for-mail 
                      [S] From: nobody@nowhere.to (Demo User) 
  
  
  
            Barber                                             [Page 22] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] Newsgroups: misc.test 
                      [S] Subject: I am just a test article 
                      [S] Date: 6 Oct 1998 04:38:40 -0500 
                      [S] Organization: Nowhere, To 
                      [S] Message-ID: <45223423@to.to> 
                      [S]  
                      [S] This is just a test article. 
                      [S] . 
  
              Example of an unsuccessful retrieval of an article by message-
              id 
                      [S] 200 NNTP Service Ready 
                      [C] ARTICLE <i.am.not.there@nowhere.to> 
                      [S] 430 No Such Article Found 
  
              Example of an unsuccessful retrieval of an article by number 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 news.groups 
                      [C] ARTICLE 300256 
                      [S] 423 No such article number in this group 
  
              Example of an unsuccessful retrieval of an article by number 
              because no newsgroup was selected first 
                      [S] 200 NNTP Service Ready 
                      [C] ARTICLE 300256 
                      [S] 412 No newsgroup selected 
  
              Example of an attempt to retrieve an article when the current 
              group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] ARTICLE 
                      [S] 420 No current article selected  
  
              Example of a failure due to the service being unavailable 
                      [S] 200 NNTP Service Ready 
                      [C] ARTICLE <i.am.a.test.article@nowhere.to> 
  
  
            Barber                                             [Page 23] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] 502 Service unavailable 
                 
  
            9.2.2 HEAD 
  
              HEAD <message-id> 
  
              HEAD [number] 
  
              The HEAD command behaves identically to the ARTICLE command 
              except that, if the article exists, only the headers are 
              presented (the blank line separating the headers and body MUST 
              NOT be included). 
  
            9.2.2.1 Responses 
  
                   First form (message-id specified): 
                    
                   221 0 a     article retrieved, headers follow (multiline) 
                   430         no such article 
                   502         service unavailable 
                    
                   Second form (optional article number specified): 
                    
                   221 n a     article retrieved, headers follow (multiline) 
                   412         no newsgroup selected 
                   420         no current article selected 
                   423         no such article number in this group 
                   502         service unavailable 
                    
              Except that only the headers are included in the response, the 
              221 response behaves identically to the 220 response of the 
              ARTICLE command. 
                    
  
            9.2.2.2 Examples 
  
              Example of a successful retrieval of the headers in an article 
              (using no article number) 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] HEAD 
                      [S] 220 3000234 <45223423@to.to> 
                      [S] Path: pathost!demo!somewhere!not-for-mail 
                      [S] From: nobody@nowhere.to (Demo User) 
  
  
            Barber                                             [Page 24] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] Newsgroups: misc.test 
                      [S] Subject: I am just a test article 
                      [S] Date: 6 Oct 1998 04:38:40 -0500 
                      [S] Organization: Nowhere, To 
                      [S] Message-ID: <45223423@to.to> 
                      [S] . 
  
              Example of a successful retrieval of the headers in an article 
              by message-id 
                      [S] 200 NNTP Service Ready 
                      [C] HEAD <45223423@to.to> 
                      [S] 220 0 <45223423@to.to> 
                      [S] Path: pathost!demo!somewhere!not-for-mail 
                      [S] From: nobody@nowhere.to (Demo User) 
                      [S] Newsgroups: misc.test 
                      [S] Subject: I am just a test article 
                      [S] Date: 6 Oct 1998 04:38:40 -0500 
                      [S] Organization: Nowhere, To 
                      [S] Message-ID: <45223423@to.to> 
                      [S] . 
  
              Example of an unsuccessful retrieval of the header of an 
              article by message-id 
                      [S] 200 NNTP Service Ready 
                      [C] HEAD <i.am.not.there@nowhere.to> 
                      [S] 430 No Such Article Found 
  
              Example of an unsuccessful retrieval of the header of an 
              article by number 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] HEAD 300256 
                      [S] 423 No such article number in this group 
  
              Example of an unsuccessful retrieval the header of an article 
              by number because no newsgroup was selected first 
                      [S] 200 NNTP Service Ready 
  
  
            Barber                                             [Page 25] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [C] HEAD 300256 
                      [S] 412 No newsgroup selected 
  
              Example of an attempt to retrieve the header of an article 
              when the current group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] HEAD 
                      [S] 420 No current article selected  
  
              Example of a failure due to the service being unavailable 
                      [S] 200 NNTP Service Ready 
                      [C] HEAD <i.am.a.test.article@nowhere.to> 
                      [S] 502 Service unavailable 
  
            9.2.3 BODY 
  
              BODY <message-id> 
  
              BODY [number] 
  
              The BODY command behaves identically to the ARTICLE command 
              except that, if the article exists, only the body is presented 
              (the blank line separating the headers and body MUST NOT be 
              included). 
  
            9.2.3.1 Responses 
                    
                   First form (message-id specified): 
                    
                   222 0 a     article retrieved, body follows (multiline) 
                   430         no such article 
                   502         service unavailable 
                    
                   Second form (optional article number specified): 
                    
                   222 n a     article retrieved, body follows (multiline) 
                   412         no newsgroup selected 
                   420         no current article selected 
                   423         no such article number in this group 
                   502         service unavailable 
                    
  
  
  
  
  
            Barber                                             [Page 26] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Except that only the body is included in the response, the 222 
              response behaves identically to the 220 response of the 
              ARTICLE command. 
  
            9.2.3.2 Examples 
  
              Example of a successful retrieval of the body of an article 
              (using no article number) 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] BODY 
                      [S] 222 3000234 <45223423@to.to>  
                      [S] This is just a test article. 
                      [S] . 
  
              Example of a successful retrieval of the body of an article by 
              message-id 
                      [S] 200 NNTP Service Ready 
                      [C] BODY <45223423@to.to> 
                      [S] 222 0 <45223423@to.to> 
                      [S] This is just a test article. 
                      [S] . 
  
              Example of an unsuccessful retrieval of the body of an article 
              by message-id 
                      [S] 200 NNTP Service Ready 
                      [C] BODY <i.am.not.there@nowhere.to> 
                      [S] 430 No Such Article Found 
  
              Example of an unsuccessful retrieval of the body of an article 
              by number 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] BODY 300256 
                      [S] 423 No such article number in this group 
  
              Example of an unsuccessful retrieval of the body of an article 
              by number because no newsgroup was selected first 
  
  
  
            Barber                                             [Page 27] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] 200 NNTP Service Ready 
                      [C] BODY 300256 
                      [S] 412 No newsgroup selected 
  
              Example of an attempt to retrieve the body of an article when 
              the current group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] BODY 
                      [S] 420 No current article selected  
  
              Example of a failure due to the service being unavailable 
                      [S] 200 NNTP Service Ready 
                      [C] BODY <i.am.a.test.article@nowhere.to> 
                      [S] 502 Service unavailable 
  
            9.2.4 STAT 
  
              STAT <message-id> 
  
              STAT [number] 
  
              The STAT command behaves identically to the ARTICLE command 
              except that, if the article exists, it is NOT presented to the 
              client. 
              This command allows the client to determine whether an article 
              exists, and in the second form what its message-id is, without 
              having to process an arbitrary amount of text. 
  
            9.2.4.1 Responses 
  
                   First form (message-id specified): 
                    
                   223 0 a     article exists 
                   430         no such article 
                   502         service unavailable 
                    
                   Second form (optional article number specified): 
                    
                   223 n a     article exists 
                   412         no newsgroup selected 
                   420         no current article selected 
                   423         no such article number in this group 
                   502         service unavailable 
               
  
  
            Barber                                             [Page 28] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              The parameters of the 223 response are identical to those that 
              would have been given in a 220 response to the equivalent 
              ARTICLE command. However, the response is NOT multiline. 
  
            9.2.4.2 Examples 
  
              Example of STAT on an existing article (using no article 
              number) 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] STAT 
                      [S] 223 3000234 <45223423@to.to>  
               
              Example of a STAT of an existing article by message-id 
                      [S] 200 NNTP Service Ready 
                      [C] STAT <45223423@to.to> 
                      [S] 223 0 <45223423@to.to> 
               
              Example of an STAT of an article not on the server by message-
              id 
                      [S] 200 NNTP Service Ready 
                      [C] STAT <i.am.not.there@nowhere.to> 
                      [S] 430 No Such Article Found 
  
              Example of STAT of an article not in the server by number 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] STAT 300256 
                      [S] 423 No such article number in this group 
  
              Example of STAT of an article by number when no newsgroup was 
              selected first 
                      [S] 200 NNTP Service Ready 
                      [C] STAT 300256 
                      [S] 412 No newsgroup selected 
  
  
  
  
            Barber                                             [Page 29] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Example of STAT of an article when the current group selected 
              is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] STAT 
                      [S] 420 No current article selected  
  
              Example of a failure due to the service being unavailable 
                      [S] 200 NNTP Service Ready 
                      [C] STAT <i.am.a.test.article@nowhere.to> 
                      [S] 502 Service unavailable 
             
  
            9.3 Article Posting 
             
              Article posting is done in one of two modes: individual 
              article posting from news reading clients and article transfer 
              from other news servers. 
  
            9.3.1 POST 
             
              POST 
  
              If posting is allowed, response code 340 MUST be returned to 
              indicate that the article to be posted should be sent.  
              Response code 440 MUST be sent if that posting is prohibited 
              for some installation-dependent reason. 
  
              If posting is permitted, the article MUST be presented to the 
              server by the client in the format specified by RFC 1036. The 
              text forming the header and body of the message to be posted 
              MUST be sent by the client using the conventions for text 
              received from the news server: A single period (".") on a line 
              indicates the end of the text, with lines starting with a 
              period in the original text having that period doubled during 
              transmission. 
  
              Following the presentation of the termination sequence by the 
              client, the server MUST return a response code indicating 
              success or failure of the article transfer. Note that response 
              codes 340 and 440 are used in direct response to the POST 
              command. Others are returned following the sending of the 
              article. 
  
  
  
            Barber                                             [Page 30] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              No attempt shall be made by the server to filter characters, 
              fold or limit lines, or otherwise process incoming text. The 
              intent is that the server just passes the incoming message to 
              be posted to the server installation's news posting software, 
              which is not part of this specification. 
             
  
            9.3.1.1 Responses 
                    
                   240 article received ok 
                   340 send article to be posted. End with <CR-LF>.<CR-LF> 
                   440 posting not allowed 
                   441 posting failed 
             
  
            9.3.1.2 Examples 
  
              Example of a successful posting 
                      [S] 200 NNTP Service Ready 
                      [C] POST 
                      [S] 340 Input article. End with <CR-LF>.<CR-LF> 
                      [C] From: demo@testdomain.com(Demo User) 
                      [C] Newsgroups: misc.test  
                      [C] Subject: I am just a test article 
                      [C] Organization: Testdomain, USA 
                      [C]  
                      [C] This is just a test article. 
                      [C] . 
                      [S] 240 Article received ok 
  
              Example of an unsuccessful posting 
                      [S] 200 NNTP Service Ready 
                      [C] POST 
                      [S] 340 Input article. End with <CR-LF>.<CR-LF> 
                      [C] From: demo@testdomain.com(Demo User) 
                      [C] Newsgroups: misc.test  
                      [C] Subject: I am just a test article 
                      [C] Organization: Testdomain, USA 
                      [C]  
  
  
  
            Barber                                             [Page 31] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [C] This is just a test article. 
                      [C] . 
                      [S] 441 Posting failed 
  
              Example of an attempt to posting when posting is not allowed 
                      [S] 201 NNTP Service Ready, read-only 
                      [C] POST 
                      [S] 440 Posting not permitted  
                    
  
            9.3.2 IHAVE 
             
              IHAVE <message-id> 
  
              The IHAVE command informs the server that the client has an 
              article whose id is <message-id>. If the server desires a copy 
              of that article, it MUST return a response instructing the 
              client to send the entire article. If the server does not want 
              the article (if, for example, the server already has a copy of 
              it), a response indicating that the article is not wanted MUST 
              be returned. 
  
              If transmission of the article is requested, the client MUST 
              send the entire article, including header and body, in the 
              manner specified for text transmission from the server. The 
              server MUST return a response code indicating success or 
              failure of the transferal of the article. 
  
              This function differs from the POST command in that it is 
              intended for use in transferring already-posted articles 
              between hosts. It SHOULD NOT be used when the client is a 
              personal news reading program. In particular, this function 
              will invoke the server's news posting program with the 
              appropriate settings (flags, options, etc.) to indicate that 
              the forthcoming article is being forwarded from another host. 
              However, the server MAY elect not to post or forward the 
              article if after further examination of the article it deems 
              it inappropriate to do so. Reasons for such subsequent 
              rejection of an article may include such problems as 
              inappropriate newsgroups or distributions, disk space 
              limitations, article lengths, garbled headers, and the like. 
              These are typically restrictions enforced by the server host's 
              news software and not necessarily the NNTP server itself. 
  
            9.3.2.1 Responses 
             
  
  
            Barber                                             [Page 32] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                   235 article transferred ok 
                   335 send article to be transferred.  End with <CR- 
                   LF>.<CR-LF> 
                   435 article not wanted - do not send it 
                   436 transfer failed - try again later 
                   437 article rejected - do not try again 
                    
              Because some host news posting software may not be able to 
              immediately render status on the whether an article is 
              inappropriate for posting or forwarding, an NNTP server MAY 
              acknowledge the successful transfer of the article and later 
              silently discard it. Thus, an NNTP server MAY return the 235 
              acknowledgment code and later discard the received article. 
  
            9.3.2.2 Examples 
             
              Example of successfully sending an article to another site 
                      [S] 200 NNTP Service Ready 
                      [C] IHAVE <i.am.an.article.you.will.want@nowhere.to> 
                      [S] 335 Send it. End with <CR-LF>.<CR-LF>  
                      [C] Path: pathost!demo!somewhere!not-for-mail  
                      [C] From: nobody@nowhere.to (Demo User) 
                      [C] Newsgroups: misc.test  
                      [C] Subject: I am just a test article 
                      [C] Date: 6 Oct 1998 04:38:40 -0500  
                      [C] Organization: Nowhere, To 
                      [C] Message-ID: <i.am.a.test.article@nowhere.to>  
                      [C]  
                      [C] This is just a test article. 
                      [C] . 
                      [S] 235 Article transferred ok 
               
              Example of sending an article to another site that rejects it 
                      [S] 200 NNTP Service Ready 
                      [C] IHAVE <i.am.an.article.you.will.want@nowhere.to> 
                      [S] 335 Send it. End with <CR-LF>.<CR-LF>  
                      [C] Path: pathost!demo!somewhere!not-for-mail  
  
  
  
            Barber                                             [Page 33] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [C] From: nobody@nowhere.to (Demo User) 
                      [C] Newsgroups: misc.test  
                      [C] Subject: I am just a test article 
                      [C] Date: 6 Oct 1998 04:38:40 -0500  
                      [C] Organization: Nowhere, To 
                      [C] Message-ID: <i.am.a.test.article@nowhere.to>  
                      [C]  
                      [C] This is just a test article. 
                      [C] . 
                      [S] 437 Article rejected. Don't send again 
               
              Example of sending an article to another site where the 
              transfer fails 
                      [S] 200 NNTP Service Ready 
                      [C] IHAVE <i.am.an.article.you.will.want@nowhere.to> 
                      [S] 335 Send it. End with <CR-LF>.<CR-LF>  
                      [C] Path: pathost!demo!somewhere!not-for-mail 
                      [C] From: nobody@nowhere.to (Demo User) 
                      [C] Newsgroups: misc.test  
                      [C] Subject: I am just a test article 
                      [C] Date: 6 Oct 1998 04:38:40 -0500  
                      [C] Organization: Nowhere, To 
                      [C] Message-ID: <i.am.a.test.article@nowhere.to>  
                      [C]  
                      [C] This is just a test article. 
                      [C] . 
                      [S] 436 Transfer failed 
               
              Example of sending an article to another site that rejects it 
                      [S] 200 NNTP Service Ready 
                      [C] IHAVE <i.am.an.article.you.will.want@nowhere.to> 
                      [S] 335 Send it. End with <CR-LF>.<CR-LF>  
                      [C] Path: pathost!demo!somewhere!not-for-mail 
  
  
  
            Barber                                             [Page 34] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [C] From: nobody@nowhere.to (Demo User) 
                      [C] Newsgroups: misc.test  
                      [C] Subject: I am just a test article 
                      [C] Date: 6 Oct 1998 04:38:40 -0500  
                      [C] Organization: Nowhere, To 
                      [C] Message-ID: <i.am.a.test.article@nowhere.to>  
                      [C]  
                      [C] This is just a test article. 
                      [C] . 
                      [S] 435 Don't send it again 
  
            9.4 The LIST Keyword 
  
            9.4.1 LIST 
             
              LIST [ACTIVE [wildmat]] 
  
              The response to the LIST keyword with no parameters returns a 
              list of valid newsgroups and associated information.  Each 
              newsgroup is sent as a line of text in the following format: 
                 group first last status 
              where <group> is the name of the newsgroup, <last> is the 
              number of the last known article currently in that newsgroup, 
              <first> is the number of the first article currently in the 
              newsgroup, and <status> indicates the current status of the 
              group on this server. Typically, the <status> will be consist 
              of the US-ASCII character 'y' where posting is permitted, 'n' 
              where posting is not permitted and 'm' where postings will be 
              forwarded to the newsgroup moderator by the news server. Other 
              status strings may exist. The definition of these other values 
              and the circumstances under which they are returned is covered 
              in other specifications. 
  
              The <first> and <last> fields will always be numeric.  They 
              may have leading zeros. The <first> field corresponds to the 
              "reported low water mark" and the <last> field corresponds to 
              the "reported high water mark" described in the GROUP command 
              (see Section 9.1.1.1).  
  
              The status of a newsgroup only indicates how posts to that 
              newsgroup are processed. It does not indicate if the current 
              client is permitted to post. That is indicated by the status 
              code returned as part of the greeting.  
  
  
            Barber                                             [Page 35] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Please note that an empty list (i.e., the text body returned 
              by this command consists only of the terminating period) is a 
              possible valid response, and indicates that there are 
              currently no valid newsgroups. 
  
              If the optional wildmat parameter is specified, the list is 
              limited to only the groups that match the pattern. 
   
              Specifying a single group is usually very efficient for the 
              server. Multiple groups may be specified by using wildmat 
              patterns (described in section 5). 
  
            9.4.1.1 Responses 
                   215 list of newsgroups follows 
  
            9.4.1.2 Examples 
             
             Example of LIST returning a list of newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST 
                      [S] 215 list of newsgroups follows 
                      [S] misc.test 3000234 3002322 y  
                      [S] alt.fc-writers.recovery 1 4 y  
                      [S] tx.natives.recovery 56 89 y  
                      [S] . 
  
              Example of LIST returning no newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST 
                      [S] 215 list of newsgroups follows  
                      [S] . 
  
            9.4.2 LIST ACTIVE.TIMES 
             
              LIST ACTIVE.TIMES [wildmat] 
  
              The active.times file is maintained by some news transport 
              systems to contain information about who created a particular 
              newsgroup and when. The format of this file includes three 
              fields. The first field is the name of the newsgroup. The 
              second is the time when this group was created on this news 
              server measured in seconds since the start of January 1, 1970.  
              The third is the email address of the entity that created the 
              newsgroup. When executed, the information is displayed 
  
  
            Barber                                             [Page 36] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              following the 215 response. When display is completed, the 
              server will send a period on a line by itself. If the 
              information is not available, the server will return the 503 
              error response. If the server does not recognize the command, 
              it SHOULD return the 501 error response. 
  
              If the optional wildmat parameter is specified, the list is 
              limited to only the groups that match the pattern. 
  
              Specifying a single group is usually very efficient for the 
              server. Multiple groups may be specified by using wildmat 
              patterns (described in section 5). 
  
            9.4.2.1 Responses 
                    
                   215 information follows 
                   501 Syntax error 
                   503 program error, function not performed 
  
            9.4.2.2 Examples 
             
            Example of LIST ACTIVE.TIMES returning a list of newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST ACTIVE.TIMES 
                      [S] 215 information follows 
                      [S] misc.test 930445408 <creatme@isc.org>  
                      [S] alt.rfc-writers.recovery 930562309 <m@nowhere.to>            
                      [S] tx.natives.recovery 930678923 <sob@academ.com>  
                      [S]  . 
               
              Example of LIST ACTIVE.TIMES returning an error (The server 
              software is not configured to maintain this information, but 
              does recognize the command as valid.) 
                      [S] 200 NNTP Service Ready 
                      [C] LIST ACTIVE.TIMES 
                      [S] 503 program error, function not performed 
               
              Example of LIST ACTIVE.TIMES sent to a server that does not 
              recognize this argument (e.g. The software does not maintain 
              this information.) 
                      [S] 200 NNTP Service Ready 
  
  
  
            Barber                                             [Page 37] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [C] LIST ACTIVE.TIMES 
                      [S] 501 Syntax Error 
  
            9.4.3 LIST DISTRIBUTIONS 
             
              LIST DISTRIBUTIONS 
  
              The distributions file is maintained by some news transport 
              systems to contain information about valid values for the 
              Distribution: line in a news article header and about what the 
              values mean. Each line contains two fields, the value and a 
              short explanation on the meaning of the value. When executed, 
              the information is displayed following the 215 response. When 
              display is completed, the server will send a period on a line 
              by itself. If the information is not available, the server 
              will return the 503 error response. If the server does not 
              recognize this command, it SHOULD return the 501 error 
              response. 
  
            9.4.3.1 Responses 
                    
                   215 information follows 
                   501 Syntax error 
                   503 program error, function not performed 
  
            9.4.3.2 Examples 
  
            Example of LIST DISTRIBUTIONS returning a list of newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST DISTRIBUTIONS 
                      [S] 215 information follows  
                      [S] usa United States of America  
                      [S] na North America  
                      [S] world All over the World  
                      [S] . 
  
              Example of LIST DISTRIBUTIONS returning an error (e.g. The 
              server software is not configured to maintain this 
              information, but does recognize the command as valid.) 
                      [S] 200 NNTP Service Ready 
                      [C] LIST DISTRIBUTIONS 
                      [S] 503 program error, function not performed 
               
  
  
            Barber                                             [Page 38] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Example of LIST DISTRIBUTIONS sent to a server that does not 
              recognize the command (e.g. The server does not maintain this 
              information regardless of configuration.) 
                      [S] 200 NNTP Service Ready 
                      [C] LIST DISTRIBUTIONS 
                      [S] 501 Syntax Error 
  
            9.4.4 LIST DISTRIB.PATS 
             
              LIST DISTRIB.PATS 
  
              The distrib.pats file is maintained by some news transport 
              systems to allow clients to choose a value for the 
              Distribution: line in the header of a news article being 
              posted. The information returned consists of lines, in no 
              particular order, each of which contains three fields 
              separated by colons. These fields are a weight, a group name 
              or wildmat pattern, and a Distribution: value, in that order. 
  
              The client MAY use this information to select a Distribution: 
              value based on the name of a newsgroup. To do so, it should 
              determine the lines whose second field matches the newsgroup 
              name, select that line with the highest weight (with 0 being 
              the lowest), and use the Distribution: field from that line. 
  
              When executed, the information is displayed following the 215 
              response.  When display is completed, the server will send a 
              period on a line by itself. If the information is not 
              available, the server will return the 503 error response. If 
              this command is not recognized, the server SHOULD return the 
              501 error response. 
  
            9.4.4.1 Responses 
                    
                   215 information follows 
                   501 Syntax error 
                   503 program error, function not performed 
  
            9.4.4.2 Examples 
             
            Example of LIST DISTRIB.PATS returning a list of newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST DISTRIB.PATS 
                      [S] 215 information follows  
                      [S] 10:local.*:local  
  
  
            Barber                                             [Page 39] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] . 
  
              Example of LIST DISTRIB.PATS returning an error (e.g. The 
              server software is not configured to maintain this 
              information, but does recognize the command as valid.) 
                      [S] 200 NNTP Service Ready 
                      [C] LIST DISTRIB.PATS 
                      [S] 503 program error, function not performed 
  
              Example of LIST DISTRIB.PATS sent to a server that does not 
              recognize the command (e.g. The software does not maintain 
              this information regardless of configuration.) 
                      [S] 200 NNTP Service Ready 
                      [C] LIST DISTRIB.PATS 
                      [S] 501 Syntax Error 
  
            9.4.5 LIST NEWSGROUPS 
             
                 LIST NEWSGROUPS [wildmat] 
  
                 The newsgroups file is maintained by some news transport 
                 systems to contain the name of each newsgroup that is 
                 active on the server and a short description about the 
                 purpose of each newsgroup. Each line in the file contains 
                 two fields, the newsgroup name and a short explanation of 
                 the purpose of that newsgroup. When executed, the 
                 information is displayed following the 215 response. When 
                 display is completed, the server will send a period on a 
                 line by itself. If the information is not available, the 
                 server will return the 503 response. If the server does not 
                 recognize the command it should return a 501 response. If 
                 the optional matching parameter is specified, the list is 
                 limited to only the groups that match the pattern (no 
                 matching is done on the group descriptions).  Specifying a 
                 single group is usually very efficient for the server, and 
                 multiple groups may be specified by using a wildmat(see 
                 section 5), not regular expressions. If nothing is matched 
                 an empty list is returned, not an error. 
  
            9.4.5.1 Responses 
             
                   215 information follows 
                   501 Syntax error 
                   503 program error, function not performed 
  
  
  
            Barber                                             [Page 40] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
            9.4.5.2 Examples 
  
               Example of LIST NEWSGROUPS returning a list of newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST NEWSGROUPS 
                      [S] 215 information follows  
                      [S] misc.test General Usenet testing  
                      [S] alt.rfc-writers.recovery RFC Writers Recovery  
                      [S] tx.natives.recovery Texas Natives Recovery 
                      [S] . 
  
              Example of LIST NEWSGROUPS returning an error (e.g. The server 
              software recognizes the command as valid, but the information 
              is not available.) 
                      [S] 200 NNTP Service Ready 
                      [C] LIST NEWSGROUPS 
                      [S] 503 program error, function not performed 
                    
  
            9.5 Standard extensions 
             
              Each of the following sections describes an extension that a 
              server MAY provide. If the server provides the extension, it 
              MUST include the appropriate extension label in the response 
              to LIST EXTENSIONS. If it does not provide it, it MUST NOT 
              include the appropriate extension label. The descriptions of 
              facilities in each section are written as if the extension is 
              provided. If it is not provided, the entire section should be 
              ignored.    
  
            9.5.1 LISTGROUP extension 
             
              This extension provides one command and has the extension 
              label LISTGROUP. 
             
  
            9.5.1.1 The LISTGROUP Command 
             
                 LISTGROUP [ggg] 
  
                 The LISTGROUP command is used to get a listing of all the 
                 article numbers in a particular newsgroup.  
  
  
  
            Barber                                             [Page 41] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                 The optional parameter ggg is the name of the newsgroup to 
                 be selected (e.g. "news.software.b").  A list of valid 
                 newsgroups may be obtained from the LIST command. If no 
                 group is specified, the current group is used as the 
                 default argument. 
  
                 The successful selection response will be a list of the 
                 article numbers in the group followed by a period on a line 
                 by itself. The list starts on the next line following the 
                 211 response code. 
  
                 When a valid group is selected by means of this command, 
                 the internally maintained "current article pointer" MUST be 
                 set to the first article in the group and the name of the 
                 current newsgroup MUST be set to the selected newsgroup 
                 name. If an invalid group is specified, the previously 
                 selected group and article remain selected.  If an empty 
                 newsgroup is selected, the "current article pointer" may be 
                 in an indeterminate state and should not be used.  
  
                 The LISTGROUP keyword MAY be used by a client as a 
                 replacement for the GROUP command in establishing a valid 
                 "current article pointer." After a successful response is 
                 received, any other command may be used that depends on 
                 having the "current article pointer" be valid. 
  
                 The group name MUST match a newsgroup obtained from the 
                 LIST command or an error will result, else the server will 
                 respond with the 411 error code. 
  
                 A server that does not implement this command SHOULD return 
                 a 500 error response. 
  
            9.5.1.1.1 Responses 
                    
                   211 list of article numbers follow 
                   411 No such group 
                   412 Not currently in newsgroup 
                   500 Command not recognized 
  
            9.5.1.1.2 Examples 
             
              Example of a successful execution with a group that exists on 
              the server 
                      [S] 200 NNTP Service Ready 
                      [C] LISTGROUP misc.test 
                      [S] 211 list of article numbers follow  
  
  
  
            Barber                                             [Page 42] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] 3000234  
                      [S] 3000237  
                      [S] 3000238  
                      [S] 3000239  
                      [S] 3002322  
                      [S] . 
  
              Example of an unsuccessful execution with a group that does 
              not exist on the server 
                      [S] 200 NNTP Service Ready 
                      [C] LISTGROUP this.group.is.not.here 
                      [S] 411 no such group 
  
              Example of an attempt to retrieve an article when the current 
              group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] LISTGROUP example.empty.newsgroup 
                      [S] 412 No current article selected  
  
            9.5.2 The OVER Extension 
             
              This extension provides two commands, OVER and LIST 
              OVERVIEW.FMT. The label for this extension is OVER. 
  
            9.5.2.1 LIST OVERVIEW.FMT 
             
              LIST OVERVIEW.FMT 
  
              The overview.fmt file is maintained by some news transport 
              systems to contain the order in which header information is 
              stored in the overview databases for each newsgroup.  When 
              executed, news article header fields are displayed one line at 
              a time in the order in which they are stored in the overview 
              database[6] following the 215 response.  When display is 
              completed, the server will send a period on a line by itself. 
  
              If the information is not available, the server will return 
              the 503 response. 
              If the header has the word "full" (without quotes) after the 
              colon, the header's name is prepended to its field in the 
              output returned by the server. 
  
              This is command is part of the optional OVER extension which 
              includes the OVER command defined in section . If the OVER 
  
  
            Barber                                             [Page 43] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              extension is not implemented, then this command MUST NOT be 
              implemented. If that case, the server MUST return a 501 error 
              response when this command is presented by the client. 
             
  
            9.5.2.1.1 Responses 
             
                   215 information follows 
                   501 Syntax Error 
                   503 program error, function not performed 
  
            9.5.2.1.2 Examples 
  
              Example of LIST OVERVIEW.FMT returning a list of newsgroups 
                      [S] 200 NNTP Service Ready 
                      [C] LIST OVERVIEW.FMT 
                      [S] 215 Order of fields in overview database.  
                      [S] Subject:  
                      [S] From:  
                      [S] Date:  
                      [S] Message-ID:  
                      [S] . 
  
              Example of LIST OVERVIEW.FMT returning an error 
                      [S] 200 NNTP Service Ready 
                      [C] LIST OVERVIEW.FMT 
                      [S] 503 program error, function not performed   
             
  
            9.5.2.2 OVER 
             
              OVER [range] 
  
              The OVER command returns specific header information for the 
              article(s) specified from the current selected group. The 
              information returned in the response to this command can be 
              used by clients to follow discussion threads. 
              The optional range argument may be any of the following: 
  
                 . an article number 
                 . an article number followed by a dash to indicate all 
                   following 
  
  
  
  
            Barber                                             [Page 44] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                 . an article number followed by a dash followed by another 
                   article number 
               
              If no argument is specified, then information from the current 
              article is displayed. Successful responses start with a 224 
              response followed by the overview information for all matched 
              messages. Once the output is complete, a period is sent on a 
              line by itself. If no argument is specified, the information 
              for the current article is returned.  A newsgroup must have 
              been selected earlier, else a 412 error response is returned. 
              If no articles are in the range specified, the server returns 
              a 420 error response. A 502 response will be returned if the 
              client only has permission to transfer articles. A 500 
              response SHOULD be returned by servers do not implement this 
              command. 
  
              The output consists of one line per article, sorted in 
              numerical order of article number. Each line consists of a 
              number of fields separated by an US-ASCII TAB character. The 
              first 8 fields MUST be the following, in order: 
              article number, subject, author, date, message-ID, references, 
              byte count, line count 
               
              The content of any subsequent field is given by the response 
              to the LIST OVERVIEW.FMT command. A field may be empty (in 
              which case there will be two adjacent US-ASCII tabs, and a 
              sequence of trailing US-ASCII tabs may be omitted). Any 
              sequence of US-ASCII space or non-printing characters in a 
              field MUST be replaced by a single US-ASCII space. 
             
              The server SHOULD not produce output for articles that no 
              longer exist. 
  
            9.5.2.2.1 Responses 
             
                   224 Overview information follows 
                   412 No newsgroup current selected 
                   420 No article(s) selected 
                   500 Command not recognized 
                   502 Service Unavailable 
  
            9.5.2.2.2 Examples 
  
              Example of a successful retrieval of overview information for 
              an article (using no article number) 
                      [S] 200 NNTP Service Ready 
  
  
            Barber                                             [Page 45] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] OVER 
                      [S] 224 Overview information follows 
                          300234|I am just a test article|nobody@nowhere.to 
                          (Demo User)|6 Oct 1998 04:38:40 -0500| 
                          <45223423@to.to> 
                      [S] . 
              [Please note that the line that begins with 300234 is all one 
              line that has been wrapped for readability. A vertical bar has 
              been inserted to show where the US-ASCII TAB should actually 
              be.] 
  
              Example of an unsuccessful retrieval of overview information 
              on an article by number 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] OVER 300256 
                      [S] 420 No such article in this group 
  
              Example of an unsuccessful retrieval of overview information 
              by number because no newsgroup was selected first 
                      [S] 200 NNTP Service Ready 
                      [C] OVER  
                      [S] 412 No newsgroup selected 
  
              Example of an attempt to retrieve an article when the current 
              group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] OVER 
                      [S] 420 No current article selected  
  
            9.5.3 The HDR Extension 
              This extension provides one new command, HDR. The label for 
              this extension is PAT. 
  
  
  
            Barber                                             [Page 46] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
            9.5.3.1 HDR 
             
              HDR range|<message-id>  
  
              The HDR command is used to retrieve specific headers from 
              specific articles in the currently selected group. 
  
              The required header parameter is the name of a header line 
              (e.g.  "subject") in a newsgroup article. See RFC-1036 for a 
              list of valid header lines. The required range argument may be 
              any of the following: 
  
                 . an article number 
                 . an article number followed by a dash to indicate all 
                   following 
                 . an article number followed by a dash followed by another 
                   article number. 
             
              The required message-id argument indicates a specific article. 
              The range and message-id arguments are mutually exclusive. 
               
              A successful response consists of a 221 code followed by the 
              output from the command. The output consists of one line for 
              each article where the relevant header line exists. The line 
              consists of the article number, a US-ASCII space, and then the 
              contents of the header (without the header name). A valid 
              response includes an empty list (indicating that there were no 
              matches). Once the output is complete, a period is sent on a 
              line by itself. If the optional argument is a message-id and 
              no such article exists, a 430 error response shall be 
              returned. A 502 response shall be returned if the client only 
              has permission to transfer articles. A 500 response SHOULD be 
              issued by all servers that do not recognize this command. 
  
            9.5.3.1.1 Responses 
             
                   221 Header follows 
                   412 no newsgroup selected 
                   430 no such article 
                   500 Command not recognized 
                   502 Service Unavailable 
  
            9.5.3.1.2 Examples 
             
              Example of a successful retrieval of subject lines from a 
              range of articles 
  
  
  
            Barber                                             [Page 47] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] HDR Subject 3000234-300238  
                      [S] 221 Header Follows  
                      [S] 3000234 I am just a test article 
                      [S] 3000237 Re: I am just a test article 
                      [S] 3000238 Ditto 
                      [S] . 
  
              Example of a successful retrieval of header from an article by 
              message-id 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP misc.test 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] HDR subject <i.am.a.test.article@nowhere.to> 
                      [S] 221 Header information follows  
                      [S] 3000345 I am just a test article 
                      [S] . 
  
              Example of an unsuccessful retrieval of a header from an 
              article by message-id 
                      [S] 200 NNTP Service Ready 
                      [C] HDR subject <i.am.not.there@nowhere.to> 
                      [S] 430 No Such Article Found 
  
              Example of an unsuccessful retrieval of headers from articles 
              by number because no newsgroup was selected first 
                      [S] 200 NNTP Service Ready 
                      [C] HDR subject 300256- 
                      [S] 412 No newsgroup selected 
  
              Example of an unsuccessful retrieval of headers from articles 
              by message-id because no newsgroup was selected first 
                      [S] 200 NNTP Service Ready 
                      [C] HDR subject <i.am.a.test.article@nowhere.to> 
                      [S] 412 No newsgroup selected 
  
  
  
  
            Barber                                             [Page 48] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Example of retrieving header information when the current 
              group selected is empty 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP example.empty.newsgroup 
                      [S] 211 0 0 0 example.empty.newsgroup 
                      [C] HDR subject 0- 
                      [S] 221 Headers follow 
                          . 
  
              Example of a failure due to restrictions configured into the 
              server 
                      [S] 200 NNTP Service Ready 
                      [C] GROUP news.group 
                      [S] 211 1234 3000234 3002322 misc.test 
                      [C] HDR Subject 3000234-300238  
                      [S] 502 Service Unavailable 
  
            10. The CONCLUSION Step 
  
            10.1 QUIT 
             
              QUIT 
  
              The server process MUST acknowledge the QUIT command and then 
              close the connection to the client.  This is the preferred 
              method for a client to indicate that it has finished all its 
              transactions with the NNTP server. 
  
              If a client simply disconnects (or the connection times out or 
              some other fault occurs), the server MUST gracefully cease its 
              attempts to service the client, disconnecting from its end if 
              necessary. 
  
            10.1.1 Responses 
             
                   205 closing connection - goodbye! 
  
            10.1.2 Example 
                      [S] 200 NNTP Service Ready 
                      [C] QUIT 
                      [S] 205 closing connection 
  
  
  
            Barber                                             [Page 49] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                      [Server closes connection.] 
  
            11. Other Keywords 
             
              There are other keywords that may be used at any time between 
              the beginning of a session and its termination.  Using these 
              keywords does not alter any state information, but the 
              response generated from the use of these keywords may provide 
              useful information to clients that use them. 
  
            11.1 DATE 
             
              DATE 
  
              This command exists to help clients find out the current 
              Coordinated Universal Time[7] from the server's perspective.  
              This command SHOULD NOT be used as a substitute for NTP[8], 
              but to provide information that might be useful when using the 
              NEWNEWS command (see section 11.4). A system providing NNTP 
              service SHOULD implement NTP for the purposes of keeping the 
              system clock as accurate as possible.  
              This command returns a one-line response code of 111 followed 
              by the date and time on the server in the form YYYYMMDDhhmmss.  
  
            11.1.1 Responses 
             
                   111 YYYYMMDDhhmmss 
  
            11.1.2 Example 
                      [S] 200 NNTP Service Ready 
                      [C] DATE 
                      [S] 111 19990623135624 
  
            11.2 The HELP Command 
             
              HELP 
  
              This command provides a short summary of commands that are 
              understood by this implementation of the server. The help text 
              will be presented as a textual response terminated by a single 
              period on a line by itself. 
  
              This text is not guaranteed to be in any particular format and 
              SHALL NOT be used by clients as a replacement for the LIST 
              EXTENSIONS command described in section 8.1. 
  
  
            Barber                                             [Page 50] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
             
  
            11.2.1 Responses 
             
                   100 help text follows 
  
            11.2.2 Example 
                      [S] 200 NNTP Service Ready 
                      [C] HELP 
                      [S] 100 Help text follows  
                      [S] This is some help text. There is no specific 
                      [S] formatting requirement for this test, though 
                      [S] it is customary for it to list the valid commands 
                      [S] and give a brief definition of what they do 
                      [S] . 
  
            11.3 NEWGROUPS 
             
              NEWGROUPS date time [GMT]  
  
              A list of newsgroups created since <date and time> MUST be 
              listed in the same format as the LIST command. 
  
              The date is sent as 6 or 8 digits in the format [XX]YYMMDD, 
              where XX is the first two digits of the year, YY is the last 
              two digits of the year, MM is the two digits of the month 
              (with leading zero, if appropriate), and DD is the day of the 
              month (with leading zero, if appropriate). If the first two 
              digits of the year are not specified, the year is to be taken 
              from the current century if YY is smaller than or equal to the 
              current year, otherwise the year is from the previous century. 
  
              Time must also be specified.  It must be as 6 digits HHMMSS 
              with HH being hours in the 24-hour clock 00-23, MM minutes 00-
              59, and SS seconds 00-60, which allows for leap seconds. The 
              token "GMT" specifies that the date and time are given in 
              Coordinated Universal Time. If the token "GMT" is omitted then 
              the date and time are specified in the server's local 
              timezone. Note that there is no way within this specification 
              of NNTP to establish the server's local timezone. 
  
              Note that an empty list (i.e., the text body returned by this 
              command consists only of the terminating period) is a possible 
              valid response, and indicates that there are currently no new 
              newsgroups. 
  
  
  
            Barber                                             [Page 51] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Clients SHOULD make all queries using Coordinated Universal 
              Time when possible. 
  
            11.3.1 Responses 
             
                   231 list of new newsgroups follows 
  
            11.3.2 Examples 
  
              Example where there are new groups 
                      [S] 200 NNTP Service Ready 
                      [C] NEWGROUPS 19990624 000000 GMT 
                      [S] 230 list of new newsgroups follows 
                      [S] alt.rfc-writers.recovery 
                      [S] tx.natives.recovery 
                      [S] . 
  
              Example where there are no new groups 
                      [S] 200 NNTP Service Ready 
                      [C] NEWGROUPS 19990624 000000 GMT 
                      [S] 230 list of new newsgroups follows 
                      [S] . 
  
            11.4 NEWNEWS 
             
              NEWNEWS newsgroups date time [GMT]  
  
              A list of message-ids of articles posted or received to the 
              specified newsgroup or groups since "date" will be listed. The 
              format of the listing will be one message-id per line, as 
              though text were being sent. Each message-id SHALL appear only 
              once in a response. The order of the response has no specific 
              significance and may vary from response to response in the 
              same session. A single line consisting solely of one period 
              followed by CR-LF will terminate the list. 
  
              Date and time are in the same format as the NEWGROUPS command. 
              The newsgroups parameter MUST be in wildmat format and MAY 
              consist of multiple wildmat constructs separated by an US-
              ASCII comma character. 
  
              Note that an empty list (i.e., the text body returned by this 
              command consists only of the terminating period) is a possible 
              valid response, and indicates that there is currently no new 
              news. 
  
  
            Barber                                             [Page 52] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Clients SHOULD make all queries in Coordinated Universal Time 
              when possible. 
  
            11.4.1 Responses 
             
                 230 list of new articles by message-id follows 
  
            11.4.2 Examples 
  
              Example where there are new articles 
                      [S] 200 NNTP Service Ready 
                      [C] NEWNEWS news.*,sci.* 19990624 000000 
                      [S] 230 list of new articles by message-id follows 
                      [S] <i.am.a.new.article@nowhere.to>  
                      [S] <i.am.another.new.article@nowhere.to> 
               
              Example where there are no new articles 
                      [S] 200 NNTP Service Ready 
                      [C] NEWNEWS alt.* 19990624 000000 
                      [S] 230 list of new articles by message-id follows 
                      [S] . 
  
            12. Framework for NNTP Extensions 
             
              Although NNTP is widely and robustly deployed, some parts of 
              the Internet community might wish to extend the NNTP service.  
              This memo defines a means whereby an extended NNTP client may 
              query the server to determine the service extensions that it 
              supports. 
  
              It must be emphasized that any extension to the NNTP service 
              should not be considered lightly. NNTP's strength comes 
              primarily from its simplicity.  Experience with many protocols 
              has shown that: 
  
              Protocols with few options tend towards ubiquity, whilst 
              protocols with many options tend towards obscurity. 
  
              This means that each and every extension, regardless of its 
              benefits, must be carefully scrutinized with respect to its 
              implementation, deployment, and interoperability costs. In 
              many cases, the cost of extending the NNTP service will likely 
              outweigh the benefit. 
  
  
            Barber                                             [Page 53] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              Given this environment, the framework for the extensions 
              described in this memo consists of: 
              a)a mechanism for clients to determine a server's available 
                   extensions 
              b)a registry of NNTP service extensions 
             
              The LIST EXTENSIONS command is described in section 8.1 of 
              this memo and is the mechanism for clients to use to determine 
              what extensions are available for client use. 
  
              The IANA shall maintain a registry of NNTP service extensions. 
              An extension is identified by a unique extension-label, which 
              is a string of 1 to 12 uppercase letters. The extension-label 
              will often be the name of a new command that the extension 
              adds. However this is not a requirement: an extension might 
              not add any new commands or keywords. 
  
              An extension is either a private extension or else it is 
              included in the IANA registry and is defined in an RFC. Such 
              RFCs either must be on the standards-track or must define an 
              IESG-approved experimental protocol. 
  
              The definition of an extension must include: 
  
                 . a descriptive name for the extension 
                 . the extension-label (which is returned by LIST EXTENSIONS 
                   to indicate to the client that the server supports this 
                   particular extension) 
                 . the syntax, values, and meanings of any parameters 
                   following the extension-label in the output of LIST 
                   EXTENSIONS 
                 . any new NNTP keywords associated with the extension 
                 . the syntax and possible values of parameters associated 
                   with the new NNTP keywords 
                 . any new parameters the extension associates with any 
                   other pre-existing NNTP keywords 
                 . how support for the extension affects the behavior of a 
                   server and NNTP client 
                 . any increase in the maximum length of commands over the 
                   value specified in this memo 
               
              The extension-label of private extensions MUST begin with "X". 
              The extension-label of registered extensions MUST NOT begin 
              with "X". 
  
              Any keyword values presented in the NNTP response that do not 
              begin with "X" MUST correspond to a standard, standards-track, 
  
  
            Barber                                             [Page 54] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              or IESG-approved experimental NNTP service extension 
              registered with IANA.  A conforming server MUST NOT offer non 
              "X" prefixed keyword values that are not described in a 
              registered extension. 
  
              Except where stated otherwise, the commands in this document 
              are understood (even if not supported) by all servers and are 
              not described in the list of features returned by the LIST 
              EXTENSIONS command. 
  
              A server MAY provide additional keywords - either new commands 
              or new parameters to existing commands - as part of a private 
              extension. These new keywords MUST begin with "X". 
  
              A server MUST NOT send different response codes to basic NNTP 
              commands documented here or commands documented in registered 
              extensions in response to the availability or use of a private 
              extension. 
  
            12.1 Initial IANA Registry 
             
              The IANA's initial registry of NNTP service extensions 
              consists of these entries: 
  
            Service Extension    NNTP Extension Label Added Behavior 
  
            Overview Support     OVER                Defined in this 
                                                       document 
            Specific Article     LISTGROUP            Defined in this 
            Numbers                                    document 
            Header Pattern       HDR                  Defined in this 
            Matching                                   document 
             
  
            13. Augmented BNF[9] Syntax for NNTP Commands 
             
            This syntax defines the non-terminal "command". The non-terminal 
            "parameter" is used for command parameters whose syntax is 
            specified elsewhere. The syntax is in alphabetical order. Note 
            that ABNF strings are case insensitive.  
             
              article-command = "ARTICLE" [1*WSP (msg-id / article-number)] 
                 *WSP CRLF 
              article-number = 1*16DIGIT 
              argument = parameter ; excluding sequence ".." 
              body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP 
                 CRLF 
              command = article-command /  
                 body-command /  
  
  
            Barber                                             [Page 55] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
                 date-command / 
                 group-command / 
                 head-command / 
                 help-command / 
                 ihave-command / 
                 last-command / 
                 list-active-times-command / 
                 list-distrib-pats-command / 
                 list-distributions-command / 
                 list-extensions-command / 
                 list-newsgroups-command / 
                 list-overview-fmt-command / 
                 list-command / 
                 listgroup-command / 
                 mode-reader-command / 
                 newgroups-command / 
                 newnews-command / 
                 next-command / 
                 over-command / 
                 hdr-command / 
                 post-command / 
                 quit-command / 
                 stat-command 
              CR = %x0D 
              CRLF = CR LF 
              date-command = "DATE" *WSP CRLF  
              date = 6*8DIGIT 
              DIGIT = %x30-39 
              group-command = "GROUP" 1*WSP newsgroup *WSP CRLF 
              hdr-command = "PAT" 1*WSP header 1*WSP (range / msg-id) *WSP 
                 CRLF  
              head-command = "HEAD" [1*WSP (msg-id / article-number)] *WSP 
                 CRLF 
              header = parameter 
              help-command = "HELP" *WSP CRLF 
              HT = %x09 
              ihave-command = "IHAVE" 1*WSP msg-id *WSP CRLF 
              last-command = "LAST" *WSP CRLF 
              LF = %x0A 
              list-active-times-command = "LIST" 1*WSP "ACTIVE.TIMES" 
                 [1*WSP wildmat] *WSP CRLF 
              list-command = "LIST" [1*WSP "ACTIVE" [1*WSP wildmat]] *WSP 
                 CRLF 
              list-distrib-pats-command = "LIST" 1*WSP "DISTRIB.PATS" *WSP 
                 CRLF 
              list-distributions-command = "LIST" 1*WSP "DISTRIBUTIONS" *WSP 
                 CRLF 
  
  
            Barber                                             [Page 56] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              list-extensions-command = "LIST" 1*WSP "EXTENSIONS" *WSP CRLF 
              list-newsgroups-command = "LIST" 1*WSP "NEWSGROUPS" [1*WSP 
                 wildmat] 
                 *WSP CRLF 
              list-overview-fmt-command = "LIST" 1*WSP "OVERVIEW.FMT" *WSP 
                 CRLF 
              listgroup-command = "LISTGROUP" [1*WSP newsgroup] *WSP CRLF 
              mode-reader-command = "MODE" 1*WSP "READER" *WSP CRLF 
              msg-id = <defined in RFC822> 
              newgroups-command = "NEWGROUPS" 1*WSP date 1*WSP time [1*WSP 
                 "GMT"] *WSP CRLF 
              newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup) 
                 1*WSP date 1*WSP time [1*WSP "GMT"] 
                 *WSP CRLF 
              newsgroup = parameter 
              next-command = "NEXT" *WSP CRLF 
              over-command = "OVER" [1*WSP range] *WSP CRLF 
              parameter = 1*(%x21-FF) ; generic command parameter 
              post-command = "POST" *WSP CRLF 
              quit-command = "QUIT" *WSP CRLF 
              range = article-number ["-" [article-number]]  
              SP = %x20 
              stat-command = "STAT" [1*WSP (msg-id / article-number)] *WSP 
                 CRLF 
              time = 6DIGIT 
              UTF-8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 
              UTF8-1 = %x80-BF 
              UTF8-2 = %xC0-DF UTF8-1 
              UTF8-3 = %xE0-EF 2UTF8-1 
              UTF8-4 = %xF0-F7 3UTF8-1 
              UTF8-5 = %xF8-FB 4UTF8-1 
              UTF8-6 = %xFC-FD 5UTF8-1  
              wildmat = ["!"]1*("*" / "?" / wildmat-exact / wildmat-set / 
              "\" (%x22-7F / UTF-8-non-ascii)) 
              wildmat-exact = %x22-29 / %x2B-3E / %x40-5A / %x5D-7F / UTF-8-
                 non-ascii ; exclude space ! * ? [ \ 
              wildmat-non-hyphen = %x21-2C / %x2E-7F / UTF-8-non-ascii ; 
                 exclude space - 
              wildmat-set = "[" ["^"] ["]" / "-"] *(wildmat-non-hyphen"["-" 
                 wildmat-non-hyphen]) ["-"] 
              WSP = SP / HT 
             
  
            14. Security Considerations 
  
              This section is meant to inform application developers, 
              information providers, and users of the security limitations 
              in NNTP as described by this document. The discussion does not 
  
  
            Barber                                             [Page 57] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              include definitive solutions to the problems revealed, though 
              it does make some suggestions for reducing security risks.  
  
            14.1 Personal and Proprietary Information 
  
              NNTP, because it was created to distribute network news 
              articles, will forward whatever information is stored in those 
              articles. Specification of that information is outside this 
              scope of this document, but it is likely that some personal 
              and/or proprietary information is available in some of those 
              articles. It is very important that designers and implementers 
              provide informative warnings to users so personal and/or 
              proprietary information is not disclosed inadvertently. 
  
              Additionally, effective and easily understood mechanisms to 
              manage the distribution of news articles must be provided to 
              NNTP Server administrators, so that they are able to report 
              with confidence what information is and is not being forwarded 
              in news articles passing though their servers. 
  
            14.2 Abuse of Server Log Information 
             
              A server is in the position to save session data about a 
              user's requests that might identify their reading patterns or 
              subjects of interest. This information is clearly confidential 
              in nature and its handling can be constrained by law in 
              certain countries. People using the NNTP protocol to provide 
              data are responsible for ensuring that such material is not 
              distributed without the permission of any individuals that are 
              identifiable by the published results.  
  
            14.3 DNS Spoofing  
             
              Clients and Servers using NNTP rely heavily on the Domain Name 
              Service, and are thus generally prone to security attacks 
              based on the deliberate misassociation of IP addresses and DNS 
              names. Clients and Servers need to be cautious in assuming the 
              continuing validity of an IP number/DNS name association.  
  
              In particular, NNTP clients and servers SHOULD rely on their 
              name resolver for confirmation of an IP number/DNS name 
              association, rather than caching the result of previous host 
              name lookups. Many platforms already can cache host name 
              lookups locally when appropriate, and they SHOULD be 
              configured to do so. It is proper for these lookups to be 
              cached, however, only when the TTL (Time To Live) information 
              reported by the name server makes it likely that the cached 
              information will remain useful.  
  
  
            Barber                                             [Page 58] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              If NNTP clients or servers cache the results of host name 
              lookups in order to achieve a performance improvement, they 
              MUST observe the TTL information reported by DNS.  
  
              If NNTP clients or servers do not observe this rule, they 
              could be spoofed when a previously accessed server's IP 
              address changes. As network renumbering is expected to become 
              increasingly common, the possibility of this form of attack 
              will grow. Observing this requirement thus reduces this 
              potential security vulnerability.  
  
              This requirement also improves the load-balancing behavior of 
              clients for replicated servers using the same DNS name and 
              reduces the likelihood of a user's experiencing failure in 
              accessing sites that use that strategy.  
  
            14.4 Weak Authentication and Access Control 
             
              There is no user-based or token-based authentication in the 
              basic NNTP specification. Access is normally controlled by 
              server configuration files. Those files specify access by 
              using domain names or IP addresses. However, this 
              specification does permit the creation of extensions to the 
              NNTP protocol itself for such purposes. While including such 
              mechanisms is optional, doing so is strongly encouraged. 
              Other mechanisms are also available. For example, a proxy 
              server could be put in place that requires authentication 
              before connecting via the proxy to the NNTP server. 
  
            15. References
  
             [1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", 
              RFC-977, U.C. San Diego and U.C. Berkeley.
  	   [2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 
              RFC 2279, Alis Technologies. 
             [3] Coded Character Set-7-bit American Standard Code for 
              Information Interchange, ANSI x3.4-1986. 
             [4]Bradner, Scott, "Keywords for use in RFCs to Indicate 
              Requirement Levels", RFC-2119, Harvard University. 
             [5] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 
              distribution, UUNET Technologies, Revision 1.10, April, 1992.
             [6] Robertson, Rob, "FAQ: Overview database / NOV General 
              Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
              nov.Z, January, 1995. 
             [7] International Telecommunications Union-Radio, "Glossary", 
              ITU-R Recommendation TF.686-1, October, 1997.
             [8] Mills, David L., "Network Time Protocol (Version 3), 
              Specification, Implementation and Analysis", RFC-1305, 
              University of Delaware, March 1992. 
  
            Barber                                             [Page 59] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
             [9] Crocker, D. and Overell, P., "Augmented BNF for Syntax 
              Specifications: ABNF", RFC-2234, Internet Mail Consortium and 
              Demon Internet, Ltd. 
  
            16. Notes 
             
              UNIX is a registered trademark of the X/Open Consortium. 
  
            17. Acknowledgments 
             
              The author acknowledges the original authors of NNTP as 
              documented in RFC 977: Brian Kantor and Phil Lapsey. 
  
              The author gratefully acknowledges the work of the NNTP 
              committee chaired by Eliot Lear. The organization of this 
              document was influenced by the last available draft from this 
              working group. A special thanks to Eliot for generously 
              providing the original machine-readable sources for that 
              document. 
  
              The author gratefully acknowledges the work of the Marshall 
              Rose & John G. Meyers in RFC 1939 and the work of the DRUMS 
              working group, specifically RFC 1869, which is the basis of 
              the NNTP extensions mechanism detailed in this document. 
              The author gratefully acknowledges the authors of RFC 2616 for 
              providing specific and relevant examples of security issues 
              that should be considered for HTTP. Since many of the same 
              considerations exist for NNTP, those examples that are 
              relevant have been included here with some minor rewrites. 
  
              The author gratefully acknowledges the comments and additional 
              information provided by the following individuals in preparing 
              one of the progenitors of this document: 
  
                 . Russ Allbery <rra@stanford.edu> 
                 . Wayne Davison <davison@armory.com> 
                 . Clive D.W. Feather <clive@demon.net> 
                 . Chris Lewis <clewis@bnr.ca> 
                 . Tom Limoncelli <tal@mars.superlink.net> 
                 . Eric Schnoebelen <eric@egsner.cirr.com> 
                 . Rich Salz <rsalz@osf.org> 
               
             
  
  
            Barber                                             [Page 60] 
  
  
  
            INTERNET DRAFT                                          S. Barber 
            Expires: October 30, 2001              Academ Consulting Services 
                                                                   March 2001 
              This work was motivated by the work of various news reader 
              authors and news server authors, which includes those listed 
              below: 
  
                 . Rick Adams-Original author of the NNTP extensions to the 
                   RN news reader and last maintainer of Bnews 
                 . Stan Barber-Original author of the NNTP extensions to the 
                   news readers that are part of Bnews. 
                 . Geoff Collyer-Original author of the OVERVIEW database 
                   proposal and one of the original authors of CNEWS 
                 . Dan Curry-Original author of the xvnews news reader 
                 . Wayne Davison-Author of the first threading extensions to 
                   the RN news reader (commonly called TRN). 
                 . Geoff Huston-Original author of ANU NEWS 
                 . Phil Lapsey-Original author of the UNIX reference 
                   implementation for NNTP 
                 . Iain Lea-Original maintainer of the TIN news reader 
                 . Chris Lewis-First known implementer of the AUTHINFO 
                   GENERIC extension 
                 . Rich Salz-Original author of INN 
                 . Henry Spencer-One of the original authors of CNEWS 
                 . Kim Storm-Original author of the NN news reader 
  
            18. Author's Address 
  
              Stan Barber 
              P.O. Box 300481 
              Houston, Texas 77230 
              Email: sob@academ.com 
             
              This document expires October 30, 2001. 
             
             
             
             
             
             
             
             
             
             
             
             
             
            Barber                                             [Page 61] 
  
  
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message