rfc2980.txt

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

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