doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc2980.txt b/doc/rfc/rfc2980.txt
new file mode 100644
index 0000000..2def1be
--- /dev/null
+++ b/doc/rfc/rfc2980.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                          S. Barber
+Request for Comments: 2980                    Academ Consulting Services
+Category: Informational                                     October 2000
+
+
+                         Common NNTP Extensions
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   In this document, a number of popular extensions to the Network News
+   Transfer Protocol (NNTP) protocol defined in RFC 977 are documented
+   and discussed.  While this document is not intended to serve as a
+   standard of any kind, it will hopefully serve as a reference document
+   for future implementers of the NNTP protocol.  In the role, this
+   document would hopefully create the possibility for some level of
+   interoperability among implementations that make use of extensions.
+
+Introduction
+
+   RFC 977 [1] defines the NNTP protocol and  was released over a decade
+   ago.  Since then, NNTP has become one of the most popular protocols
+   in use on the Internet.  Many implementations of the protocol have
+   been created on many different platforms and operating systems.  With
+   the growth in use of the protocol, work began on a revision to NNTP
+   in 1991, but that work did not result in a new standard protocol
+   specification.  However, many ideas from that working group did find
+   their way into many implementations of NNTP.  Additionally, many
+   other extensions, often created by newsreader authors, are also in
+   use.  This document will capture and define all known extensions to
+   NNTP available in official NNTP server releases of some type as of
+   this writing.  Where possible, the server software first implementing
+   a particular extension will be noted.  It is the hope of the author
+   that using this document in tandem with RFC 977 will limit the
+   addition of new extensions that essentially do the same thing.
+   Software developers may wish to use this document and others [2] as a
+   resource for the  development of new software.
+
+
+
+
+
+Barber                       Informational                      [Page 1]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   This document does not specify an Internet Standard of any kind.  It
+   only attempts to document current practices.  While this document may
+   clarify some ambiguity in RFC 977, RFC 977 should be regarded as
+   authoritative in all cases.  There are some implementations that are
+   not strictly RFC 977 compliant and where necessary, these deviations
+   from the standard will be noted.  This document does reflect the work
+   of the IETF NNTP-EXT working group chaired by Ned Freed and Stan
+   Barber.
+
+   This document is provided to help implementers have a uniform source
+   of information about extensions, however, it is important for any
+   prospective implementer to understand that the extensions listed here
+   are NOT part of any current standard for NNTP.  In fact, some of the
+   ones listed in this document should not be included in new NNTP
+   implementations as they should no longer be used modern NNTP
+   environments.  Such commands should be considered historic and are
+   documented as such in this document.
+
+   Extensions fall into three categories: transport, newsreader and
+   other.  Transport extensions are additions to the NNTP specification
+   that were made specifically to move news articles from one server to
+   another server.  Newsreader extensions are additions to the NNTP
+   specification that were made to assist NNTP clients in selecting and
+   retrieving news articles from servers.  Other extensions to the NNTP
+   specification are those which did not specifically fall into either
+   of the other two categories.  Examples of other extensions include
+   authentication and time-of-day extensions.  For each command, the
+   format of section 3 of RFC 977 will be used.
+
+1. Transport Extensions
+
+   A transport extension is one which is primarily used in inter-server
+   communications.  Following are the descriptions of each transport
+   extension commands 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.  A parameter that may be
+   repeated is followed by an ellipsis.
+
+
+
+
+
+
+
+
+
+Barber                       Informational                      [Page 2]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+1.1.1  The CHECK command
+
+   CHECK <message-id>
+
+   CHECK is used by a peer to discover if the article with the specified
+   message-id should be sent to the server using the TAKETHIS command.
+   The peer does not have to wait for a response from the server before
+   sending the next command.
+
+   From using the responses to the sequence of CHECK commands, a list of
+   articles to be sent can be constructed for subsequent use by the
+   TAKETHIS command.
+
+   The use of the CHECK command for streaming is optional.  Some
+   implementations will directly use the TAKETHIS command and send all
+   articles in the send queue on that peer for the server.
+
+   On some implementations, the use of the CHECK command is not
+   permitted when the server is in slave mode (via the SLAVE command).
+
+   Responses that are of the form X3X must specify the message-id in the
+   response.
+
+1.1.2.  Responses
+
+      238 no such article found, please send it to me
+      400 not accepting articles
+      431 try sending it again later
+      438 already have it, please don't send it to me
+      480 Transfer permission denied
+      500 Command not understood
+
+1.2.1  The MODE STREAM command
+
+   MODE STREAM
+
+   MODE STREAM is used by a peer to indicate to the server that it would
+   like to suspend the lock step conversational nature of NNTP and send
+   commands in streams.  This command should be used before TAKETHIS and
+   CHECK.  See the section on the commands TAKETHIS and CHECK for more
+   details.
+
+1.2.2.  Responses
+
+      203 Streaming is OK
+      500 Command not understood
+
+
+
+
+
+Barber                       Informational                      [Page 3]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+1.3.1  The TAKETHIS command
+
+   TAKETHIS <message-id>
+
+   TAKETHIS is used to send articles to a server when in streaming mode.
+   The entire article (header and body, in that sequence) is sent
+   immediately after the peer sends the TAKETHIS command.  The peer does
+   not have to wait for a response from the server before sending the
+   next command and the associated article.
+
+   During transmission of the article, the peer should send the entire
+   article, including header and body, in the manner specified for text
+   transmission from the server.  See RFC 977, Section 2.4.1 for
+   details.
+
+   Responses that are of the form X3X must specify the message-id in the
+   response.
+
+1.3.2.  Responses
+
+      239 article transferred ok
+      400 not accepting articles
+      439 article transfer failed
+      480 Transfer permission denied
+      500 Command not understood
+
+1.4.1  The XREPLIC command
+
+   XREPLIC ggg:nnn[,ggg:nnn...]
+
+   The XREPLIC command makes is possible to exactly duplicate the news
+   spool structure of one server in another server.  It first appeared
+   in INN.
+
+   This command works similarly to the IHAVE command as specified in RFC
+   977.  The same response codes are used.  The command line arguments
+   consist of entries separated by a single comma.  Each entry consists
+   of a news group name, a colon, and an article number.  If the server
+   responds with a 335 response, the article should be filed in the news
+   group(s) and article number(s) specified in the XREPLIC command line.
+   If the server cannot do successfully install the article once it has
+   accepted it, a 436 or 437 response code can be used to indicate the
+   failure.
+
+   This command should only be used when the receiving server is being
+   fed by only one other server.  It is likely that when used with
+   servers that have multiple feeds that this command will frequently
+   fail.
+
+
+
+Barber                       Informational                      [Page 4]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
+   INN now has the ability to slave servers via transparent means,
+   simply by having the article's Xref header transferred.  (In previous
+   versions, this header was generated locally and stripped off on
+   outgoing feeds.)
+
+   It is likely that future versions of INN will no longer support
+   XREPLIC.
+
+1.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
+
+2. Newsreader Extensions
+
+   Newsreader extensions are those which are primarily used by
+   newsreading clients.  Following are the descriptions of each
+   newsreader extension commands 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.  A parameter that may be
+   repeated is followed by an ellipsis.  Mutually exclusive parameters
+   are separated by a vertical bar (|) character.  For example,
+   ggg|<message-id> indicates that  a group name or a <message-id> may
+   be specified, but not both.  Some parameters, notably <message-id>,
+   is case specific.  See RFC 1036 for these details.
+
+   Also, certain commands make use of a pattern for selection of
+   multiple news groups.  The pattern in all cases is based on the
+   wildmat [4] format introduced by Rich Salz in 1986.  Arguments
+   expected to be in wildmat format will be represented by the string
+   wildmat.  This format is discussed in detail in section 3.3 of this
+   document.
+
+2.1.1 Extensions to the LIST command
+
+   The original LIST command took no arguments in RFC 977 and returned
+   the contents of the active file in a specific format.  Since the
+   original newsreaders made use of other information available in the
+   news transport software in addition to the active file, extensions to
+
+
+
+Barber                       Informational                      [Page 5]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   the LIST command were created to make that information available to
+   NNTP newsreaders.  There may be other extensions to the LIST command
+   that simply return the contents of a file.  This approach is
+   suggested over the addition of over verbs.  For example, LIST MOTD
+   could be used instead of adding XMOTD.
+
+2.1.2 LIST ACTIVE
+
+   LIST ACTIVE [wildmat]
+
+   LIST ACTIVE is exactly the same as the LIST command specified in RFC
+   977.  The responses and the format should exactly match the LIST
+   command without arguments.  If the optional matching 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, and multiple groups may be specified by using wildmat
+   patterns (described later in this document), not regular expressions.
+   If nothing is matched an empty list is returned, not an error.  This
+   command first appeared in the UNIX reference version.
+
+2.1.3 LIST ACTIVE.TIMES
+
+   LIST ACTIVE.TIMES
+
+   The active.times file is maintained by some news transports systems
+   to contain information about the when and who created a particular
+   news group.  The format of this file generally include three fields.
+   The first field is the name of the news group.  The second is the
+   time when this group was created on this news server measured in
+   seconds since January 1, 1970.  The third is the email address of the
+   entity that created the news group.  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.  This command first appeared in the UNIX reference version.
+
+2.1.3.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.4 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
+
+
+
+Barber                       Informational                      [Page 6]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   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.  This command first
+   appeared in the UNIX reference version.
+
+2.1.4.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.5 LIST DISTRIB.PATS
+
+   LIST DISTRIB.PATS
+
+   The distrib.pats file is maintained by some news transport systems to
+   contain default values for the Distribution:  line in a news article
+   header when posting to particular news groups.  This information
+   could be used to provide a default value for the Distribution: line
+   in the header when posting an article.  The information returned
+   involves three fields separated by colons.  The first column is a
+   weight.  The second is a group name or a pattern that can be used to
+   match a group name in the wildmat format.  The third is the value of
+   the Distribution:  line that should be used when the group name
+   matches and the weight value is the highest.  All this processing is
+   done by the news posting client and not by the server itself.  The
+   server just provides this information to the client for it to use or
+   ignore as it chooses.  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.  This
+   command first appeared in INN.
+
+2.1.5.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.6 LIST NEWSGROUPS
+
+   LIST NEWSGROUPS [wildmat]
+
+   The newsgroups file is maintained by some news transport systems to
+   contain the name of each news group which is active on the server and
+   a short description about the purpose of each news group.  Each line
+   in the file contains two fields, the news group name and a short
+   explanation of the purpose of that news group.  When executed, the
+
+
+
+Barber                       Informational                      [Page 7]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   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 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 wildmat patterns (similar to file globbing), not
+   regular expressions.  If nothing is matched an empty list is
+   returned, not an error.
+
+   When the optional parameter is specified, this command is equivalent
+   to the XGTITLE command, though the response code are different.
+
+      215 information follows
+      503 program error, function not performed
+
+2.1.7 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 news group.  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 [5] 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.
+
+   Please note that 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.
+
+   Many newsreaders work better if Xref: is one of the optional fields.
+
+   It is STRONGLY recommended that this command be implemented in any
+   server that implements the XOVER command.  See section 2.8 for more
+   details about the XOVER command.
+
+2.1.7.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+
+
+
+
+
+
+Barber                       Informational                      [Page 8]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.1.8 LIST SUBSCRIPTIONS
+
+   LIST SUBSCRIPTIONS
+
+   This command is used to get a default subscription list for new users
+   of this server.  The order of groups is significant.
+
+   When this list is available, it is preceded by the 215 response and
+   followed by a period on a line by itself.  When this list is not
+   available, the server returns a 503 response code.
+
+2.1.8.1 Responses
+
+      215 information follows
+      503 program error, function not performed
+
+2.2 LISTGROUP
+
+   LISTGROUP [ggg]
+
+   The LISTGROUP command is used to get a listing of all the article
+   numbers in a particular news group.
+
+   The optional parameter ggg is the name of the news group to be
+   selected (e.g. "news.software.b").  A list of valid news groups 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.
+
+   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
+   news group is selected, the "current article pointer" is in an
+   indeterminate state and should not be used.
+
+   Note that the name of the news group is not case-dependent.  It must
+   otherwise match a news group obtained from the LIST command or an
+   error will result.
+
+2.2.1  Responses
+
+      211 list of article numbers follow
+      412 Not currently in newsgroup
+      502 no permission
+
+
+
+
+Barber                       Informational                      [Page 9]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.3 MODE READER
+
+   MODE READER is used by the client to indicate to the server that it
+   is a news reading client.  Some implementations make use of this
+   information to reconfigure themselves for better performance in
+   responding to news reader commands.  This command can be contrasted
+   with the SLAVE command in RFC 977, which was not widely implemented.
+   MODE READER was first available in INN.
+
+2.3.1 Responses
+
+      200 Hello, you can post
+      201 Hello, you can't post
+
+2.4 XGTITLE
+
+   XGTITLE [wildmat]
+
+   The XGTITLE command is used to retrieve news group descriptions for
+   specific news groups.
+
+   This extension first appeared in ANU-NEWS, an NNTP implementation for
+   DEC's VMS.  The optional parameter is a pattern in wildmat format.
+   When executed, a 282 response is given followed by lines that have
+   two fields, the news group name (which matches the pattern in the
+   argument) and a short explanation of the purpose of the news group.
+   When no argument is specified, the default argument is the current
+   group name.  When display is completed, the server sends a period on
+   a line by itself.
+
+   Please note that this command and the LIST NEWSGROUP command provide
+   the same functionality with different response codes.
+
+   Since this command provides the same functionality as LIST NEWSGROUP
+   it is suggested that this extension be deprecated and no longer be
+   used in newsreading clients.
+
+   Note that there is a conflict in one of the response codes from
+   XGTITLE and some of the authentication extensions.
+
+2.5.1 Responses
+
+      481 Groups and descriptions unavailable
+      282 list of groups and descriptions follows
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 10]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.6 XHDR
+
+   XHDR header [range|<message-id>]
+
+   The XHDR command is used to retrieve specific headers from specific
+   articles.
+
+   The required parameter is the name of a header line (e.g.  "subject")
+   in a news group article.  See RFC 1036 for a list of valid header
+   lines.  The optional 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 optional message-id argument indicates a specific article.  The
+   range and message-id arguments are mutually exclusive.  If no
+   argument is specified, then information from the current article is
+   displayed.  Successful responses start with a 221 response followed
+   by a the matched headers from all matched messages.  Each line
+   containing matched headers returned by the server has an article
+   number (or message ID, if a message ID was specified in the command),
+   then one or more spaces, then the value of the requested header in
+   that article.  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, the 430 error response is returned.  If a range is
+   specified, a news group must have been selected earlier, else a 412
+   error response is returned.  If no articles are in the range
+   specified, a 420 error response is returned by the server.  A 502
+   response will be returned if the client only has permission to
+   transfer articles.
+
+   Some implementations will return "(none)" followed by a period on a
+   line by itself if no headers match in any of the articles searched.
+   Others return the 221 response code followed by a period on a line by
+   itself.
+
+   The XHDR command has been available in the UNIX reference
+   implementation from its first release.  However, until now, it has
+   been documented only in the source for the server.
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 11]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.6.1 Responses
+
+      221 Header follows
+      412 No news group current selected
+      420 No current article selected
+      430 no such article
+      502 no permission
+
+2.7 XINDEX
+
+   XINDEX ggg
+
+   The XINDEX command is used to retrieve an index file in the format of
+   originally created for use by the TIN [6] news reader.
+
+   The required parameter ggg is the name of the news group to be
+   selected (e.g. "news.software.b").  A list of valid news groups may
+   be obtained from the LIST command.
+
+   The successful selection response will return index file in the
+   format used by the TIN news reader followed by a period on a line by
+   itself.
+
+   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
+   news group is selected, the "current article pointer" is in an
+   indeterminate state and should not be used.
+
+   Note that the name of the news group is not case-dependent.  It must
+   otherwise match a news group obtained from the LIST command or an
+   error will result.
+
+   The format of the tin-style index file is discussed in the
+   documentation for the TIN newsreader.  Since more recent versions of
+   TIN support the news overview (NOV) format, it is recommended that
+   this extension become historic and no longer be used in current
+   servers or future implementations.
+
+2.7.1 Responses
+
+      218 tin-style index follows
+      418 no tin-style index is available for this news group
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 12]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.8 XOVER
+
+   XOVER [range]
+
+   The XOVER command returns information from the overview database for
+   the article(s) specified.  This command was originally suggested as
+   part of the OVERVIEW work described in "The Design of a Common
+   Newsgroup Overview Database for Newsreaders" by Geoff Collyer.  This
+   document is distributed in the Cnews distribution.  The optional
+   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
+
+   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 news group must have been selected earlier, else a 412
+   error response is returned.  If no articles are in the range
+   specified, a 420 error response is returned by the server.  A 502
+   response will be returned if the client only has permission to
+   transfer articles.
+
+   Each line of output will be formatted with the article number,
+   followed by each of the headers in the overview database or the
+   article itself (when the data is not available in the overview
+   database) for that article separated by a tab character.  The
+   sequence of fields must be in this order: subject, author, date,
+   message-id, references, byte count, and line count.  Other optional
+   fields may follow line count.  Other optional fields may follow line
+   count.  These fields are specified by examining the response to the
+   LIST OVERVIEW.FMT command.  Where no data exists, a null field must
+   be provided (i.e. the output will have two tab characters adjacent to
+   each other).  Servers should not output fields for articles that have
+   been removed since the XOVER database was created.
+
+   The LIST OVERVIEW.FMT command should be implemented if XOVER is
+   implemented.  A client can use LIST OVERVIEW.FMT to determine what
+   optional fields  and in which order all fields will be supplied by
+   the XOVER command.  See Section 2.1.7 for more details about the LIST
+   OVERVIEW.FMT command.
+
+
+
+
+
+Barber                       Informational                     [Page 13]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   Note that any tab and end-of-line characters in any header data that
+   is returned will be converted to a space character.
+
+2.8.1 Responses
+
+      224 Overview information follows
+      412 No news group current selected
+      420 No article(s) selected
+      502 no permission
+
+2.9 XPAT
+
+   XPAT header range|<message-id> pat [pat...]
+
+   The XPAT command is used to retrieve specific headers from specific
+   articles, based on pattern matching on the contents of the header.
+   This command was first available in INN.
+
+   The required header parameter is the name of a header line (e.g.
+   "subject") in a news group 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.  At least one
+   pattern in wildmat must be specified as well.  If there are
+   additional arguments the are joined together separated by a single
+   space to form one complete pattern.  Successful responses start with
+   a 221 response followed by a the headers from all messages in which
+   the pattern matched the contents of the specified header line.  This
+   includes an empty list.  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, the 430 error response is returned.  A
+   502 response will be returned if the client only has permission to
+   transfer articles.
+
+2.9.1 Responses
+
+      221 Header follows
+      430 no such article
+      502 no permission
+
+
+
+
+Barber                       Informational                     [Page 14]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+2.10 The XPATH command
+
+   XPATH <message-id>
+
+   The XPATH command is used to determine the filenames in which an
+   article is filed.  It first appeared in INN.
+
+   The required parameter message-id is the message id of an article as
+   shown in that article's message-id header.  According to RFC 1036
+   [3], all message ids for all articles within the netnews environment
+   are unique, but articles may be crossposted to multiple groups.  The
+   response to an XPATH command will include a listing of all filenames
+   in which an article is stored separated by spaces or a response
+   indicating that no article with the specified message-id exists.  The
+   returned data is only useful if the news client knows the
+   implementation details of the server.  Because of this, it is
+   recommended that client avoid using this command.
+
+2.10.1  Responses
+
+      223 path1[ path2 ...]
+      430 no such article on server
+
+2.11 The XROVER command
+
+   XROVER [range]
+
+   The XROVER command returns reference information from the overview
+   database for the article(s) specified.  This command first appeared
+   in the Unix reference implementation.  The optional 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
+
+   Successful responses start with a 224 response followed by the
+   contents of reference 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 news group must have been selected earlier, else a 412
+   error response is returned.  If no articles are in the range
+   specified, a 420 error response is returned by the server.  A 502
+   response will be returned if the client only has permission to
+   transfer articles.
+
+
+
+
+Barber                       Informational                     [Page 15]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   The output will be formatted with the article number, followed by the
+   contents of the References: line for that article, but does not
+   contain the field name itself.
+
+   This command provides the same basic functionality as using the XHDR
+   command and "references" as the header argument.
+
+2.11.1 Responses
+
+      224 Overview information follows
+      412 No news group current selected
+      420 No article(s) selected
+      502 no permission
+
+2.12 XTHREAD
+
+   XTHREAD [DBINIT|THREAD]
+
+   The XTHREAD command is used to retrieve threading information
+   in format of originally created for use by the TRN [6] news
+   reader.
+
+   The command XTHREAD DBINIT may be issued prior to entering
+   any groups to see if a thread database exists.  If it does,
+   the database's byte order and version number are returned
+   as binary data.
+
+   If no parameter is given, XTHREAD THREAD is assumed.
+
+   To use XTHREAD THREAD, a news group must have been selected
+   earlier, else a 412 error response is returned.
+
+   A 502 response will be returned if the client only has
+   permission to transfer articles.  A 503 response is returned
+   if the threading files are not available.
+
+   The format of the trn-style thread format is discussed in
+   the documentation for the TRN newsreader.  Since more recent
+   versions of TRN support the news overview (NOV) format, it
+   is recommended that this extension become historic and no
+   longer be used in current servers or future implementations.
+
+2.12.1 Responses
+
+      288 Binary data to follow
+      412 No newsgroup current selected
+      502 No permission
+      503 program error, function not performed
+
+
+
+Barber                       Informational                     [Page 16]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3. Other Extensions
+
+3.1 AUTHINFO
+
+   AUTHINFO is used to inform a server about the identity of a user of
+   the server.  In all cases, clients must provide this information when
+   requested by the server.  Servers are not required to accept
+   authentication information that is volunteered by the client.
+   Clients must accommodate servers that reject any authentication
+   information volunteered by the client.
+
+   There are three forms of AUTHINFO in use.  The original version, an
+   NNTP v2 revision called AUTHINFO SIMPLE and a more recent version
+   which is called AUTHINFO GENERIC.
+
+3.1.1 Original AUTHINFO
+
+   AUTHINFO USER username
+   AUTHINFO PASS password
+
+   The original AUTHINFO is used to identify a specific entity to the
+   server using a simple username/password combination.  It first
+   appeared in the UNIX reference implementation.
+
+   When authorization is required, the server will send a 480 response
+   requesting authorization from the client.  The client must enter
+   AUTHINFO USER followed by the username.  Once sent, the server will
+   cache the username and may send a 381 response requesting the
+   password associated with that username.  Should the server request a
+   password using the 381 response, the client must enter AUTHINFO PASS
+   followed by a password and the server will then check the
+   authentication database to see if the username/password combination
+   is valid.  If the combination is valid or if no password is required,
+   the server will return a 281 response.  The client should then retry
+   the original command to which the server responded with the 480
+   response.  The command should then be processed by the server
+   normally.  If the combination is not valid, the server will return a
+   502 response.
+
+   Clients must provide authentication when requested by the server.  It
+   is possible that some implementations will accept authentication
+   information at the beginning of a session, but this was not the
+   original intent of the specification.  If a client attempts to
+   reauthenticate, the server may return 482 response indicating that
+   the new authentication data is rejected by the server.  The 482 code
+   will also be returned when the AUTHINFO commands are not entered in
+   the correct sequence (like two AUTHINFO USERs in a row, or AUTHINFO
+   PASS preceding AUTHINFO USER).
+
+
+
+Barber                       Informational                     [Page 17]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   All information is passed in cleartext.
+
+   When authentication succeeds, the server will create an email address
+   for the client from the user name supplied in the AUTHINFO USER
+   command and the hostname generated by a reverse lookup on the IP
+   address of the client.  If the reverse lookup fails, the IP address,
+   represented in dotted-quad format, will be used.  Once authenticated,
+   the server shall generate a Sender:  line using the email address
+   provided by authentication if it does not match the client-supplied
+   From: line.  Additionally, the server should log the event, including
+   the email address.  This will provide a means by which subsequent
+   statistics generation can associate newsgroup references with unique
+   entities - not necessarily by name.
+
+3.1.1.1 Responses
+
+      281 Authentication accepted
+      381 More authentication information required
+      480 Authentication required
+      482 Authentication rejected
+      502 No permission
+
+3.1.2 AUTHINFO SIMPLE
+
+   AUTHINFO SIMPLE
+   user password
+
+   This version of AUTHINFO was part of a proposed NNTP V2
+   specification, which was started in 1991 but never completed, and is
+   implemented in some servers and clients.  It is a refinement of the
+   original AUTHINFO and provides the same basic functionality, but the
+   sequence of commands is much simpler.
+
+   When authorization is required, the server sends a 450 response
+   requesting authorization from the client.  The client must enter
+   AUTHINFO SIMPLE.  If the server will accept this form of
+   authentication, the server responds with a 350 response.  The client
+   must then send the username followed by one or more space characters
+   followed by the password.  If accepted, the server returns a 250
+   response and the client should then retry the original command to
+   which the server responded with the 450 response.  The command should
+   then be processed by the server normally.  If the combination is not
+   valid, the server will return a 452 response.
+
+   Note that the response codes used here were part of the proposed NNTP
+   V2 specification and are violations of RFC 977.  It is recommended
+   that this command not be implemented, but use either or both of the
+   other forms of AUTHINFO if such functionality if required.
+
+
+
+Barber                       Informational                     [Page 18]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3.1.2.1 Responses
+
+      250 Authorization accepted
+      350 Continue with authorization sequence
+      450 Authorization required for this command
+      452 Authorization rejected
+
+3.1.3 AUTHINFO GENERIC
+
+   AUTHINFO GENERIC authenticator arguments...
+
+   AUTHINFO GENERIC is used to identify a specific entity to the server
+   using arbitrary authentication  or identification protocols.  The
+   desired protocol is indicated by the authenticator parameter, and any
+   number of parameters can be passed to the authenticator.
+
+   When authorization is required, the server will send a 480 response
+   requesting authorization from the client.  The client should enter
+   AUTHINFO GENERIC followed by the authenticator name, and the
+   arguments if any.  The authenticator and arguments must not contain
+   the sequence "..".
+
+   The server will attempt to engage the server end authenticator,
+   similarly, the client should engage the client end authenticator.
+   The server end authenticator will then initiate authentication using
+   the NNTP sockets (if appropriate for that authentication protocol),
+   using the protocol specified by the authenticator name.  These
+   authentication protocols are not included in this document, but are
+   similar in structure to those referenced in RFC 1731 [8] for the
+   IMAP-4 protocol.
+
+   If the server returns 501, this means that the authenticator
+   invocation was syntactically incorrect, or that AUTHINFO GENERIC is
+   not supported.  The client should retry using the AUTHINFO USER
+   command.
+
+   If the requested authenticator capability is not found, the server
+   returns the 503 response code.
+
+   If there is some other unspecified server program error, the server
+   returns the 500 response code.
+
+   The authenticators converse using their protocol until complete.  If
+   the authentication succeeds, the server authenticator will terminate
+   with a 281, and the client can continue by reissuing the command that
+   prompted the 380.  If the authentication fails, the server will
+   respond with a 502.
+
+
+
+
+Barber                       Informational                     [Page 19]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   The client must provide authentication when requested by the server.
+   The server may request authentication at any time.  Servers may
+   request authentication more than once during a single session.
+
+   When the server authenticator completes, it provides to the server
+   (by a mechanism herein undefined) the email address of the user, and
+   potentially what the user is allowed to access.  Once authenticated,
+   the server shall generate a Sender:  line using the email address
+   provided by the authenticator if it does not match the user-supplied
+   From: line.  Additionally, the server should log the event, including
+   the user's authenticated email address (if available).  This will
+   provide a means by which subsequent statistics generation can
+   associate newsgroup references with unique entities - not necessarily
+   by name.
+
+   Some implementations make it possible to obtain a list of
+   authentication procedures available by sending the server AUTHINFO
+   GENERIC with no arguments.  The server then returns a list of
+   supported mechanisms followed by a period on a line by itself.
+
+3.1.3.1 Responses
+
+      281 Authentication succeeded
+      480 Authentication required
+      500 Command not understood
+      501 Command not supported
+      502 No permission
+      503 Program error, function not performed
+      nnn  authenticator-specific protocol.
+
+3.2 DATE
+
+   DATE
+
+   The first NNTP working group discussed and proposed a syntax for this
+   command to help clients find out the current time from the server's
+   perspective.  At the time this command was discussed (1991-1992), the
+   Network Time Protocol [9] (NTP) was not yet in wide use and there was
+   also some concern that small systems may not be able to make
+   effective use of NTP.
+
+   This command returns a one-line response code of 111 followed by the
+   GMT date and time on the server in the form YYYYMMDDhhmmss.
+
+3.2.1 Responses
+
+      111 YYYYMMDDhhmmss
+
+
+
+
+Barber                       Informational                     [Page 20]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3.3 The WILDMAT format
+
+   The WILDMAT format was first developed by Rich Salz based on 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 characters.  The second is a
+   question mark (?) to match any single 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 a 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.
+
+3.3.1 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.
+
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 21]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+3.4 Additional Headers
+
+   Many NNTP implementations add headers to Usenet articles when then
+   are POSTed via NNTP.  These headers are discussed in this section.
+   None of these headers conflict with those specified in RFC 1036 and
+   should be passed unchanged by Usenet transports conforming to RFC
+   1036.
+
+3.4.1 NNTP-Posting-Host
+
+   This line is added to the header of a posted article by the server.
+   The contents of the header is either the IP address or the fully
+   qualified domain name of the client host posting the article.  The
+   fully qualified domain name should be determined by doing a reverse
+   lookup in the DNS on the IP address of the client.  If the client
+   article contains this line, it is removed by the server before
+   acceptance of the article by the Usenet transport system.
+
+   This header provides some idea of the actual host posting the article
+   as opposed to information in the Sender or From lines that may be
+   present in the article.  This is not a fool-proof methodology since
+   reverse lookups in the DNS are vulnerable to certain types of
+   spoofing, but such discussions are outside the scope of this
+   document.
+
+3.4.2 X-Newsreader and others
+
+
+   There are other lines that are added by clients as well.  Most of
+   these indicate the type of newsreader software that is posting the
+   article.
+
+4.0 Common Implementation Issues
+
+   Many NNTP implementations do not follow the specifications in RFC
+   977.  In this section, some common implementation issues are
+   summarized.
+
+4.1 The Response to the LIST command
+
+   RFC 977 says that the fourth field of the "list of valid newsgroups
+   associated information" returned must be "either 'y' or 'n'
+   indicating whether posting to this newsgroup is allowed ('y') or
+   prohibited ('n').  Most implementations simply output the exact
+   contents of the transport system's active newsgroup list.  For more
+   implementations, the fourth field usually has more values that 'y' or
+   'n'.
+
+
+
+
+Barber                       Informational                     [Page 22]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+4.2 The Required Headers in an Article and the POST command
+
+   RFC 977 notes in section 3.10.1 that articles presented "should
+   include all required header lines." In fact, modern implementations
+   only require From, Subject, and Newsgroups header lines and will
+   supply the rest; further, many implementers believe that it is best
+   for clients to generate as few headers as possible, since clients
+   often do not format other headers correctly.
+
+   This implementation behavior is consistent with both Bnews and Cnews
+   which would supply missing headers for articles directly submitted to
+   them.
+
+4.3 Article Numbering
+
+   RFC 977 does not directly address the rules concerning articles
+   number.  However, the current practice is simple: article numbers are
+   monotonically increasing, articles may disappear, and therefore the
+   high and low water marks returned in a GROUP command should be
+   treated as maximum minima, and minimum maxima, respectively.
+
+4.4 Availability of commands defined in RFC 977
+
+   Some implementations permit administrators to disable commands
+   defined RFC 977.  Some implementations have some set of commands
+   disabled by default.  This means that client implementations cannot
+   depend on the availability of the disabled set of commands.  This
+   increases the complexity of the client and does not encourage
+   implementors to optimize the implementation of commands that don't
+   perform well.
+
+   NEWNEWS is one of the commands frequently disabled.
+
+4.5 The Distribution header and NEWNEWS
+
+   In section 12.4 of RFC 977, the optional distributions argument is
+   described.  This argument, according to RFC 977, would limit the
+   responses to articles that were in newsgroups with prefixes that
+   matched the optional distributions argument.
+
+   Some implementations implement this by matching the Distributions
+   header in articles to the distribution argument.  Others do the match
+   against segments of the newsgroup's name.
+
+   This variation is probably best explained by the evolution of the
+   USENET article format.  At the time RFC 977 was specified, the
+   newsgroup name defined how the group was distributed throughout
+   USENET.  RFC 1036 changed this convention.  So, those that are
+
+
+
+Barber                       Informational                     [Page 23]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   strictly implementing RFC 977 would match the newsgroup name prefix
+   against the distribution argument and only display matches.  Those
+   that implement against the intent of the command (as modified by the
+   redefinition of the article format)would match the Distributions
+   header against the distribution argument and only display those
+   matches.
+
+5.0 Further Work
+
+   With the continued use of NNTP on the Internet, there remains an
+   interest in creating an optimized transport protocol for server-to-
+   server transfers and an optimized client protocol for client-to-
+   server interactions.  There is also considerable interest is building
+   better mechanisms to provide audit information on which news groups
+   are being read by which users.
+
+   An IETF working group has been formed and it is the hope of this
+   author that these issues will be addressed in that forum.
+
+6.0 Security Considerations
+
+   The use of the AUTHINFO is optional.  This command as documented has
+   a number of security implications.  In the original and simple forms,
+   all passwords are passed in plaintext and could be discovered by
+   various forms of network or system surveillance.  The AUTHINFO
+   GENERIC command has the potential for the same problems if a
+   mechanism is used that also passes cleartext passwords.  RFC 1731 [8]
+   discusses these issues in greater detail.
+
+7.0 References
+
+   [1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
+        977, February 1986.
+
+   [2]  Limoncelli, Tom, "Read This Before You Write a Newsreader",
+        http://mars.superlink.net/tal/news-software-authors.html, June,
+        1996.
+
+   [3]  Horton, M. and R. Adams, "Standard for interchange of USENET
+        messages",  RFC 1036, December 1987.
+
+   [4]  Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
+        distribution, UUNET Technologies, Revision 1.10, April, 1992.
+
+   [5]  Robertson, Rob, "FAQ: Overview database / NOV General
+        Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
+        nov.Z, January, 1995.
+
+
+
+
+Barber                       Informational                     [Page 24]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   [6]  Lea, Iain, "FAQ about the TIN newsreader",
+        http://www.cs.unca.edu/~davidson/handouts/tinfaq.html
+
+   [7]  Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
+        2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
+        software/readers/%5Bnews.software.readers%5D_trn_newsreader
+        _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
+        -hierarchy/news/software/readers/%5Bnews.software.readers
+        %5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.
+
+   [8]  Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
+        December 1994.
+
+   [9]  Mills, D., "Network Time Protocol (Version 3), Specification,
+        Implementation and Analysis", RFC 1305, March 1992.
+
+8.0 Notes
+
+   DEC is a registered trademark of Compaq Computer Corporation.  UNIX
+   is a registered trademark of The Open Group.  VMS is a registered
+   trademark of Compaq Computer Corporation.
+
+9.0 Acknowledgments
+
+   The author gratefully acknowledges the comments and additional
+   information provided by the following individuals:
+
+   Wayne Davison <davison@armory.com>
+   Chris Lewis <clewis@bnr.ca>
+   Tom Limoncelli <tal@lucent.com>
+   Eric Schnoebelen <eric@egsner.cirr.com>
+   Rich Salz <rsalz@osf.org>
+
+   This work was precipitated by the work of various newsreader authors
+   and newsserver authors which includes those listed below:
+
+   Rick Adams    -- Original author of the NNTP extensions to the RN
+                    newsreader and last maintainer of Bnews
+   Stan Barber   -- Original author of the NNTP extensions to the
+                    newsreaders 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 newsreader
+   Wayne Davison -- Author of the first threading extensions to the
+                    RN newsreader (commonly called TRN).
+   Geoff Huston  -- Original author of ANU NEWS
+
+
+
+
+
+Barber                       Informational                     [Page 25]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+   Phil Lapsey   -- Original author of the UNIX reference
+                    implementation
+   Iain Lea      -- Original maintainer of the TIN newsreader
+   Chris Lewis   -- First known implementor 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 newsreader
+
+10.0 Author's Address
+
+   Stan Barber
+   P.O. Box 300481
+   Houston, Texas, 77230
+
+   EMail: sob@academ.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 26]
+
+RFC 2980                 Common NNTP Extensions             October 2000
+
+
+11.0 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barber                       Informational                     [Page 27]
+