rfc2980.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,516 行 · 第 1/4 页

               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