diff -r f907866f0e4b -r 6fceb66e1ad7 RFC3977
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/RFC3977	Fri Jun 26 16:48:50 2009 +0200
@@ -0,0 +1,6998 @@
+
+Network Working Group                                         C. Feather
+Request for Comments: 3977                                      THUS plc
+Obsoletes: 977                                              October 2006
+Updates: 2980
+Category: Standards Track
+
+
+                 Network News Transfer Protocol (NNTP)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Network News Transfer Protocol (NNTP) 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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Author's Note . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Basic Concepts  . . . . . . . . . . . . . . . . . . . . . . .  6
+     3.1.  Commands and Responses  . . . . . . . . . . . . . . . . .  6
+       3.1.1.  Multi-line Data Blocks . . . . . . . . . . . . . . . . 8
+     3.2.  Response Codes  . . . . . . . . . . . . . . . . . . . . .  9
+       3.2.1.  Generic Response Codes  . . . . . . . . . . . . . . . 10
+         3.2.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . 12
+     3.3.  Capabilities and Extensions . . . . . . . . . . . . . . . 14
+       3.3.1.  Capability Descriptions . . . . . . . . . . . . . . . 14
+       3.3.2.  Standard Capabilities . . . . . . . . . . . . . . . . 15
+       3.3.3.  Extensions  . . . . . . . . . . . . . . . . . . . . . 16
+       3.3.4.  Initial IANA Register . . . . . . . . . . . . . . . . 18
+     3.4.  Mandatory and Optional Commands . . . . . . . . . . . . . 20
+
+
+
+Feather                     Standards Track                     [Page 1]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+       3.4.1.  Reading and Transit Servers . . . . . . . . . . . . . 21
+       3.4.2.  Mode Switching  . . . . . . . . . . . . . . . . . . . 21
+     3.5.  Pipelining  . . . . . . . . . . . . . . . . . . . . . . . 22
+       3.5.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . 23
+     3.6.  Articles  . . . . . . . . . . . . . . . . . . . . . . . . 24
+   4.  The WILDMAT Format  . . . . . . . . . . . . . . . . . . . . . 25
+     4.1.  Wildmat Syntax  . . . . . . . . . . . . . . . . . . . . . 26
+     4.2.  Wildmat Semantics . . . . . . . . . . . . . . . . . . . . 26
+     4.3.  Extensions  . . . . . . . . . . . . . . . . . . . . . . . 27
+     4.4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . 27
+   5.  Session Administration Commands . . . . . . . . . . . . . . . 28
+     5.1.  Initial Connection  . . . . . . . . . . . . . . . . . . . 28
+     5.2.  CAPABILITIES  . . . . . . . . . . . . . . . . . . . . . . 29
+     5.3.  MODE READER . . . . . . . . . . . . . . . . . . . . . . . 32
+     5.4.  QUIT  . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+   6.  Article Posting and Retrieval . . . . . . . . . . . . . . . . 35
+     6.1.  Group and Article Selection . . . . . . . . . . . . . . . 36
+       6.1.1.  GROUP . . . . . . . . . . . . . . . . . . . . . . . . 36
+       6.1.2.  LISTGROUP . . . . . . . . . . . . . . . . . . . . . . 39
+       6.1.3.  LAST  . . . . . . . . . . . . . . . . . . . . . . . . 42
+       6.1.4.  NEXT  . . . . . . . . . . . . . . . . . . . . . . . . 44
+     6.2.  Retrieval of Articles and Article Sections  . . . . . . . 45
+       6.2.1.  ARTICLE . . . . . . . . . . . . . . . . . . . . . . . 46
+       6.2.2.  HEAD  . . . . . . . . . . . . . . . . . . . . . . . . 49
+       6.2.3.  BODY  . . . . . . . . . . . . . . . . . . . . . . . . 51
+       6.2.4.  STAT  . . . . . . . . . . . . . . . . . . . . . . . . 53
+     6.3.  Article Posting . . . . . . . . . . . . . . . . . . . . . 56
+       6.3.1.  POST  . . . . . . . . . . . . . . . . . . . . . . . . 56
+       6.3.2.  IHAVE . . . . . . . . . . . . . . . . . . . . . . . . 58
+   7.  Information Commands  . . . . . . . . . . . . . . . . . . . . 61
+     7.1.  DATE  . . . . . . . . . . . . . . . . . . . . . . . . . . 61
+     7.2.  HELP  . . . . . . . . . . . . . . . . . . . . . . . . . . 62
+     7.3.  NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . . 63
+     7.4.  NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . . 64
+     7.5.  Time  . . . . . . . . . . . . . . . . . . . . . . . . . . 65
+       7.5.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . 66
+     7.6.  The LIST Commands . . . . . . . . . . . . . . . . . . . . 66
+       7.6.1.  LIST  . . . . . . . . . . . . . . . . . . . . . . . . 67
+       7.6.2.  Standard LIST Keywords  . . . . . . . . . . . . . . . 69
+       7.6.3.  LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . 70
+       7.6.4.  LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . 71
+       7.6.5.  LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . 72
+       7.6.6.  LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . 73
+   8.  Article Field Access Commands . . . . . . . . . . . . . . . . 73
+     8.1.  Article Metadata  . . . . . . . . . . . . . . . . . . . . 74
+       8.1.1.  The :bytes Metadata Item  . . . . . . . . . . . . . . 74
+       8.1.2.  The :lines Metadata Item  . . . . . . . . . . . . . . 75
+     8.2.  Database Consistency  . . . . . . . . . . . . . . . . . . 75
+
+
+
+Feather                     Standards Track                     [Page 2]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+     8.3.  OVER  . . . . . . . . . . . . . . . . . . . . . . . . . . 76
+     8.4.  LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . . 81
+     8.5.  HDR . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
+     8.6.  LIST HEADERS  . . . . . . . . . . . . . . . . . . . . . . 87
+   9.  Augmented BNF Syntax for NNTP . . . . . . . . . . . . . . . . 90
+     9.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . 90
+     9.2.  Commands  . . . . . . . . . . . . . . . . . . . . . . . . 92
+     9.3.  Command Continuation  . . . . . . . . . . . . . . . . . . 93
+     9.4.  Responses . . . . . . . . . . . . . . . . . . . . . . . . 93
+       9.4.1.  Generic Responses . . . . . . . . . . . . . . . . . . 93
+       9.4.2.  Initial Response Line Contents  . . . . . . . . . . . 94
+       9.4.3.  Multi-line Response Contents  . . . . . . . . . . . . 94
+     9.5.  Capability Lines  . . . . . . . . . . . . . . . . . . . . 95
+     9.6.  LIST Variants . . . . . . . . . . . . . . . . . . . . . . 96
+     9.7.  Articles  . . . . . . . . . . . . . . . . . . . . . . . . 97
+     9.8.  General Non-terminals . . . . . . . . . . . . . . . . . . 97
+     9.9.  Extensions and Validation . . . . . . . . . . . . . . . . 99
+   10. Internationalisation Considerations . . . . . . . . . . . . .100
+     10.1. Introduction and Historical Situation . . . . . . . . . .100
+     10.2. This Specification  . . . . . . . . . . . . . . . . . . .101
+     10.3. Outstanding Issues  . . . . . . . . . . . . . . . . . . .102
+   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .103
+   12. Security Considerations . . . . . . . . . . . . . . . . . . .103
+     12.1. Personal and Proprietary Information  . . . . . . . . . .104
+     12.2. Abuse of Server Log Information . . . . . . . . . . . . .104
+     12.3. Weak Authentication and Access Control  . . . . . . . . .104
+     12.4. DNS Spoofing  . . . . . . . . . . . . . . . . . . . . . .104
+     12.5. UTF-8 Issues  . . . . . . . . . . . . . . . . . . . . . .105
+     12.6. Caching of Capability Lists . . . . . . . . . . . . . . .106
+   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .107
+   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .110
+     14.1. Normative References  . . . . . . . . . . . . . . . . . .110
+     14.2. Informative References  . . . . . . . . . . . . . . . . .110
+   A.  Interaction with Other Specifications . . . . . . . . . . . .112
+     A.1.  Header Folding  . . . . . . . . . . . . . . . . . . . . .112
+     A.2.  Message-IDs . . . . . . . . . . . . . . . . . . . . . . .112
+     A.3.  Article Posting . . . . . . . . . . . . . . . . . . . . .114
+   B.  Summary of Commands . . . . . . . . . . . . . . . . . . . . .115
+   C.  Summary of Response Codes . . . . . . . . . . . . . . . . . .117
+   D.  Changes from RFC 977  . . . . . . . . . . . . . . . . . . . .121
+
+1.  Introduction
+
+   This document specifies the Network News Transfer Protocol (NNTP),
+   which is used for the distribution, inquiry, retrieval, and posting
+   of Netnews articles using a reliable stream-based mechanism.  For
+   news-reading clients, NNTP enables retrieval of news articles that
+
+
+
+
+Feather                     Standards Track                     [Page 3]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   are stored in a central 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.  NNTP is designed for efficient
+   transmission of Netnews articles over a reliable full duplex
+   communication channel.
+
+   Although the protocol specification in this document is largely
+   compatible with the version specified in RFC 977 [RFC977], a number
+   of changes are summarised in Appendix D.  In particular:
+
+   o  the default character set is changed from US-ASCII [ANSI1986] to
+      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);
+
+   o  a number of commands that were optional in RFC 977 or that have
+      been taken from RFC 2980 [RFC2980] are now mandatory; and
+
+   o  a CAPABILITIES command has been added to allow clients to
+      determine what functionality is available from a server.
+
+   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 [RFC2119].
+
+   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 document, the terms "client" and "client
+   host" refer to a host making use of the NNTP service, while the terms
+   "server" and "server host" refer to a host that offers the NNTP
+   service.
+
+1.1.  Author's Note
+
+   This document is written in XML using an NNTP-specific DTD.  Custom
+   software is used to convert this to RFC 2629 [RFC2629] format, and
+   then the public "xml2rfc" package to further reduce this to text,
+   nroff source, and HTML.
+
+   No perl was used in producing this document.
+
+
+
+
+
+
+Feather                     Standards Track                     [Page 4]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+2.  Notation
+
+   The following notational conventions are used in this document.
+
+     UPPERCASE     indicates literal text to be included in the
+                   command.
+
+     lowercase     indicates a token described elsewhere.
+
+     [brackets]    indicate that the enclosed material is optional.
+
+     elliptical    indicates that the argument may be repeated any
+     ... marks     number of times (it must occur at least once).
+
+     vertical|bar  indicates a choice of two mutually exclusive
+                   arguments (exactly one must be provided).
+
+   The name "message-id" for a command or response argument indicates
+   that it is the message-id of an article as described in Section 3.6,
+   including the angle brackets.
+
+   The name "wildmat" for an argument indicates that it is a wildmat as
+   defined in Section 4.  If the argument does not meet the requirements
+   of that section (for example, if it does not fit the grammar of
+   Section 4.1), the NNTP server MAY place some interpretation on it
+   (not specified by this document) or otherwise MUST treat it as a
+   syntax error.
+
+   Responses for each command will be described in tables listing the
+   required format of a response followed by the meaning that should be
+   ascribed to that response.
+
+   The terms "NUL", "TAB", "LF", "CR, and "space" refer to the octets
+   %x00, %x09, %x0A, %x0D, and %x20, respectively (that is, the octets
+   with those codes in US-ASCII [ANSI1986] and thus in UTF-8 [RFC3629]).
+   The term "CRLF" or "CRLF pair" means the sequence CR immediately
+   followed by LF (that is, %x0D.0A).  A "printable US-ASCII character"
+   is an octet in the range %x21-7E.  Quoted characters refer to the
+   octets with those codes in US-ASCII (so "." and "<" refer to %x2E and
+   %x3C) and will always be printable US-ASCII characters; similarly,
+   "digit" refers to the octets %x30-39.
+
+   A "keyword" MUST consist only of US-ASCII letters, digits, and the
+   characters dot (".") and dash ("-") and MUST begin with a letter.
+   Keywords MUST be at least three characters in length.
+
+
+
+
+
+
+Feather                     Standards Track                     [Page 5]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Examples in this document are not normative but serve to illustrate
+   usages, arguments, and responses.  In the examples, a "[C]" will be
+   used to represent the client host and an "[S]" will be used to
+   represent the server host.  Most of the examples do not rely on a
+   particular server state.  In some cases, however, they do assume that
+   the currently selected newsgroup (see the GROUP command,
+   Section 6.1.1) is invalid; when so, this is indicated at the start of
+   the example.  Examples may use commands or other keywords not defined
+   in this specification (such as an XENCRYPT command).  These will be
+   used to illustrate some point and do not imply that any such command
+   is defined elsewhere or needs to exist in any particular
+   implementation.
+
+   Terms that might be read as specifying details of a client or server
+   implementation, such as "database", are used simply to ease
+   description.  Provided that implementations conform to the protocol
+   and format specifications in this document, no specific technique is
+   mandated.
+
+3.  Basic Concepts
+
+3.1.  Commands and Responses
+
+   NNTP operates over any reliable bi-directional 8-bit-wide data stream
+   channel.  When the connection is established, the NNTP server host
+   MUST send a greeting.  The client host and server host then exchange
+   commands and responses (respectively) until the connection is closed
+   or aborted.  If the connection used is TCP, then 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.
+
+   The character set for all NNTP commands is UTF-8 [RFC3629].  Commands
+   in NNTP MUST consist of a keyword, which MAY be followed by one or
+   more arguments.  A CRLF pair MUST terminate all commands.  Multiple
+   commands MUST NOT be on the same line.  Unless otherwise noted
+   elsewhere in this document, arguments SHOULD consist of printable US-
+   ASCII characters.  Keywords and arguments MUST each be separated by
+   one or more space or TAB characters.  Command lines MUST NOT exceed
+   512 octets, which includes the terminating CRLF pair.  The arguments
+   MUST NOT exceed 497 octets.  A server MAY relax these limits for
+   commands defined in an extension.
+
+   Where this specification permits UTF-8 characters outside the range
+   of U+0000 to U+007F, implementations MUST NOT use the Byte Order Mark
+   (U+FEFF, encoding %xEF.BB.BF) and MUST use the Word Joiner (U+2060,
+   encoding %xE2.91.A0) for the meaning Zero Width No-Break Space in
+
+
+
+Feather                     Standards Track                     [Page 6]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   command lines and the initial lines of responses.  Implementations
+   SHOULD apply these same principles throughout.
+
+   The term "character" means a single Unicode code point.
+   Implementations are not required to carry out Unicode normalisation.
+   Thus, U+0084 (A-dieresis) is one character, while U+0041 U+0308 (A
+   composed with dieresis) is two; the two need not be treated as
+   equivalent.
+
+   Commands may have variants; if so, they use a second keyword
+   immediately after the first to indicate which variant is required.
+   The only such commands in this specification are LIST and MODE.  Note
+   that such variants are sometimes referred to as if they were commands
+   in their own right: "the LIST ACTIVE" command should be read as
+   shorthand for "the ACTIVE variant of the LIST command".
+
+   Keywords are case insensitive; the case of keywords for commands MUST
+   be ignored by the server.  Command and response arguments are case or
+   language specific only when stated, either in this document or in
+   other relevant specifications.
+
+   In some cases, a command involves more data than just a single line.
+   The further data may be sent either immediately after the command
+   line (there are no instances of this in this specification, but there
+   are in extensions such as [NNTP-STREAM]) or following a request from
+   the server (indicated by a 3xx response).
+
+   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.  The initial line of the response MUST NOT exceed
+   512 octets, which includes the response code and the terminating CRLF
+   pair; an extension MAY specify a greater maximum for commands that it
+   defines, but not for any other command.  Single-line responses
+   consist of an initial line only.  Multi-line responses consist of an
+   initial line followed by a multi-line data block.
+
+   An NNTP server MAY have an inactivity autologout timer.  Such a timer
+   SHOULD be of at least three minutes' duration, with the exception
+   that there MAY be a shorter limit on how long the server is willing
+   to wait for the first command from the client.  The receipt of any
+   command from the client during the timer interval SHOULD suffice to
+   reset the autologout timer.  Similarly, the receipt of any
+   significant amount of data from a client that is sending a multi-line
+   data block (such as during a POST or IHAVE command) SHOULD suffice to
+   reset the autologout timer.  When the timer expires, the server
+   SHOULD close the connection without sending any response to the
+   client.
+
+
+
+Feather                     Standards Track                     [Page 7]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+3.1.1.  Multi-line Data Blocks
+
+   A multi-line data block is used in certain commands and responses.
+   It MUST adhere to the following rules:
+
+   1.  The block consists of a sequence of zero or more "lines", each
+       being a stream of octets ending with a CRLF pair.  Apart from
+       those line endings, the stream MUST NOT include the octets NUL,
+       LF, or CR.
+
+   2.  In a multi-line response, the block immediately follows the CRLF
+       at the end of the initial line of the response.  When used in any
+       other context, the specific command will define when the block is
+       sent.
+
+   3.  If any line of the data block begins with the "termination octet"
+       ("." or %x2E), that line MUST be "dot-stuffed" by prepending an
+       additional termination octet to that line of the block.
+
+   4.  The lines of the block MUST be followed by a terminating line
+       consisting of a single termination octet followed by a CRLF pair
+       in the normal way.  Thus, unless it is empty, a multi-line block
+       is always terminated with the five octets CRLF "." CRLF
+       (%x0D.0A.2E.0D.0A).
+
+   5.  When a multi-line block is interpreted, the "dot-stuffing" MUST
+       be undone; i.e., the recipient MUST ensure that, in any line
+       beginning with the termination octet followed by octets other
+       than a CRLF pair, that initial termination octet is disregarded.
+
+   6.  Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT
+       be considered part of the multi-line block; i.e., the recipient
+       MUST ensure that any line beginning with the termination octet
+       followed immediately by a CRLF pair is disregarded.  (The first
+       CRLF pair of the terminating CRLF "." CRLF of a non-empty block
+       is, of course, part of the last line of the block.)
+
+   Note that texts using an encoding (such as UTF-16 or UTF-32) that may
+   contain the octets NUL, LF, or CR other than a CRLF pair cannot be
+   reliably conveyed in the above format (that is, they violate the MUST
+   requirement above).  However, except when stated otherwise, this
+   specification does not require the content to be UTF-8, and therefore
+   (subject to that same requirement) it MAY include octets above and
+   below 128 mixed arbitrarily.
+
+   This document does not place any limit on the length of a line in a
+   multi-line block.  However, the standards that define the format of
+   articles may do so.
+
+
+
+Feather                     Standards Track                     [Page 8]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+3.2.  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 completed OK
+      3xx - Command OK so far; send the rest of it
+      4xx - Command was syntactically correct but failed for some reason
+      5xx - Command unknown, unsupported, unavailable, or syntax error
+
+   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 - Reserved for authentication and privacy extensions
+      x9x - Reserved for private use (non-standard extensions)
+
+   Certain responses contain arguments such as numbers and names in
+   addition to the status indicator.  In those cases, to simplify
+   interpretation by the client, the number and type of such arguments
+   is fixed for each response code, as is whether the code is
+   single-line or multi-line.  Any extension MUST follow this principle
+   as well.  Note that, for historical reasons, the 211 response code is
+   an exception to this in that the response may be single-line or
+   multi-line depending on the command (GROUP or LISTGROUP) that
+   generated it.  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 by any given command are
+   detailed in the description of that command.
+
+   Arguments MUST be separated from the numeric status indicator and
+   from each other by a single space.  All numeric arguments MUST be in
+   base 10 (decimal) format and MAY have leading zeros.  String
+   arguments MUST contain at least one character and MUST NOT contain
+   TAB, LF, CR, or space.  The server MAY add any text after the
+   response code or last argument, 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 argument by at least
+   one space.
+
+
+
+
+Feather                     Standards Track                     [Page 9]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The server MUST respond to any command with the appropriate generic
+   response (given in Section 3.2.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 variants or 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.)
+
+   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 document 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 registered extension (see
+   Section 3.3.3) 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.)
+
+3.2.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 if it is an optional command
+   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,
+   including the case where more arguments are provided than the command
+   specifies or the command line is longer than the server accepts, the
+   response code 501 MUST be returned.  The line MUST NOT be truncated
+   or split and then interpreted.  Note that where a command has
+   variants depending on a second keyword (e.g., LIST ACTIVE and LIST
+   NEWSGROUPS), 501 MUST be used when the base command is implemented
+   but the requested variant is not, and 500 MUST be used only when the
+   base command itself is not implemented.
+
+   If an argument is required to be a base64-encoded string [RFC4648]
+   (there are no such arguments in this specification, but there may be
+
+
+
+Feather                     Standards Track                    [Page 10]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   in extensions) and is not validly encoded, the response code 504 MUST
+   be returned.
+
+   If the server experiences an internal fault or problem that means it
+   is unable to carry out the command (for example, a necessary file is
+   missing or a necessary service could not be contacted), the response
+   code 403 MUST be returned.  If the server recognizes the command but
+   does not provide an optional feature (for example, because it does
+   not store the required information), or if it only handles a subset
+   of legitimate cases (see the HDR command, Section 8.5, for an
+   example), the response code 503 MUST be returned.
+
+   If the client is not authorized to use the specified facility when
+   the server is in its current state, then the appropriate one of the
+   following response codes MUST be used.
+
+   502: It is necessary to terminate the connection and to start a new
+      one with the appropriate authority before the command can be used.
+      Historically, some mode-switching servers (see Section 3.4.1) used
+      this response to indicate that this command will become available
+      after the MODE READER command (Section 5.3) is used, but this
+      usage does not conform to this specification and MUST NOT be used.
+      Note that the server MUST NOT close the connection immediately
+      after a 502 response except at the initial connection
+      (Section 5.1) and with the MODE READER command.
+
+   480: The client must authenticate itself to the server (that is, it
+      must provide information as to the identity of the client) before
+      the facility can be used on this connection.  This will involve
+      the use of an authentication extension such as [NNTP-AUTH].
+
+   483: The client must negotiate appropriate privacy protection on the
+      connection.  This will involve the use of a privacy extension such
+      as [NNTP-TLS].
+
+   401: The client must change the state of the connection in some other
+      manner.  The first argument of the response MUST be the capability
+      label (see Section 5.2) of the facility that provides the
+      necessary mechanism (usually an extension, which may be a private
+      extension).  The server MUST NOT use this response code except as
+      specified by the definition of the capability in question.
+
+   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 connection.  Following a 400 response, clients
+   SHOULD NOT simply reconnect immediately and retry the same actions.
+   Rather, a client SHOULD either use an exponentially increasing delay
+   between retries (e.g., double the waiting time after each 400
+
+
+
+Feather                     Standards Track                    [Page 11]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   response) or present any associated text to the user for them to
+   decide whether and when to retry.
+
+   The client MUST be prepared to receive any of these responses for any
+   command (except, of course, that the server MUST NOT generate a 500
+   response code for mandatory commands).
+
+3.2.1.1.  Examples
+
+   Example of an unknown command:
+
+      [C] MAIL
+      [S] 500 Unknown command
+
+   Example of an unsupported command:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] NEWNEWS
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] .
+      [C] OVER
+      [S] 500 Unknown command
+
+   Example of an unsupported variant:
+
+      [C] MODE POSTER
+      [S] 501 Unknown MODE option
+
+   Example of a syntax error:
+
+      [C] ARTICLE a.message.id@no.angle.brackets
+      [S] 501 Syntax error
+
+   Example of an overlong command line:
+
+      [C] HEAD 53 54 55
+      [S] 501 Too many arguments
+
+   Example of a bad wildmat:
+
+      [C] LIST ACTIVE u[ks].*
+      [S] 501 Syntax error
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 12]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of a base64-encoding error (the second argument is meant to
+   be base64 encoded):
+
+      [C] XENCRYPT RSA abcd=efg
+      [S] 504 Base64 encoding error
+
+   Example of an attempt to access a facility not available to this
+   connection:
+
+      [C] MODE READER
+      [S] 200 Reader mode, posting permitted
+      [C] IHAVE <i.am.an.article.you.will.want@example.com>
+      [S] 500 Permission denied
+
+   Example of an attempt to access a facility requiring authentication:
+
+      [C] GROUP secret.group
+      [S] 480 Permission denied
+
+   Example of a successful attempt following such authentication:
+
+      [C] XSECRET fred flintstone
+      [S] 290 Password for fred accepted
+      [C] GROUP secret.group
+      [S] 211 5 1 20 secret.group selected
+
+   Example of an attempt to access a facility requiring privacy:
+
+      [C] GROUP secret.group
+      [S] 483 Secure connection required
+      [C] XENCRYPT
+      [Client and server negotiate encryption on the link]
+      [S] 283 Encrypted link established
+      [C] GROUP secret.group
+      [S] 211 5 1 20 secret.group selected
+
+   Example of a need to change mode before a facility is used:
+
+      [C] GROUP binary.group
+      [S] 401 XHOST Not on this virtual host
+      [C] XHOST binary.news.example.org
+      [S] 290 binary.news.example.org virtual host selected
+      [C] GROUP binary.group
+      [S] 211 5 1 77 binary.group selected
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 13]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of a temporary failure:
+
+      [C] GROUP archive.local
+      [S] 403 Archive server temporarily offline
+
+   Example of the server needing to close down immediately:
+
+      [C] ARTICLE 123
+      [S] 400 Power supply failed, running on UPS
+      [Server closes connection.]
+
+3.3.  Capabilities and Extensions
+
+   Not all NNTP servers provide exactly the same facilities, both
+   because this specification allows variation and because servers may
+   provide extensions.  A set of facilities that are related are called
+   a "capability".  This specification provides a way to determine what
+   capabilities are available, includes a list of standard capabilities,
+   and includes a mechanism (the extension mechanism) for defining new
+   capabilities.
+
+3.3.1.  Capability Descriptions
+
+   A client can determine the available capabilities of the server by
+   using the CAPABILITIES command (Section 5.2).  This returns a
+   capability list, which is a list of capability lines.  Each line
+   describes one available capability.
+
+   Each capability line consists of one or more tokens, which MUST be
+   separated by one or more space or TAB characters.  A token is a
+   string of 1 or more printable UTF-8 characters (that is, either
+   printable US-ASCII characters or any UTF-8 sequence outside the US-
+   ASCII range, but not space or TAB).  Unless stated otherwise, tokens
+   are case insensitive.  Each capability line consists of the
+   following:
+
+   o  The capability label, which is a keyword indicating the
+      capability.  A capability label may be defined by this
+      specification or a successor, or by an extension.
+
+   o  The label is then followed by zero or more tokens, which are
+      arguments of the capability.  The form and meaning of these tokens
+      is specific to each capability.
+
+   The server MUST ensure that the capability list accurately reflects
+   the capabilities (including extensions) currently available.  If a
+   capability is only available with the server in a certain state (for
+   example, only after authentication), the list MUST only include the
+
+
+
+Feather                     Standards Track                    [Page 14]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   capability label when the server is in that state.  Similarly, if
+   only some of the commands in an extension will be available, or if
+   the behaviour of the extension will change in some other manner,
+   according to the state of the server, this MUST be indicated by
+   different arguments in the capability line.
+
+   Note that a capability line can only begin with a letter.  Lines
+   beginning with other characters are reserved for future versions of
+   this specification.  In order to interoperate with such versions,
+   clients MUST be prepared to receive lines beginning with other
+   characters and MUST ignore any they do not understand.
+
+3.3.2.  Standard Capabilities
+
+   The following capabilities are defined by this specification.
+
+   VERSION
+      This capability MUST be advertised by all servers and MUST be the
+      first capability in the capability list; it indicates the
+      version(s) of NNTP that the server supports.  There must be at
+      least one argument; each argument is a decimal number and MUST NOT
+      have a leading zero.  Version numbers are assigned only in RFCs
+      that update or replace this specification; servers MUST NOT create
+      their own version numbers.
+
+      The version number of this specification is 2.
+
+   READER
+      This capability indicates that the server implements the various
+      commands useful for reading clients.
+
+   IHAVE
+      This capability indicates that the server implements the IHAVE
+      command.
+
+   POST
+      This capability indicates that the server implements the POST
+      command.
+
+   NEWNEWS
+      This capability indicates that the server implements the NEWNEWS
+      command.
+
+   HDR
+      This capability indicates that the server implements the header
+      access commands (HDR and LIST HEADERS).
+
+
+
+
+
+Feather                     Standards Track                    [Page 15]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   OVER
+      This capability indicates that the server implements the overview
+      access commands (OVER and LIST OVERVIEW.FMT).  If and only if the
+      server supports the message-id form of the OVER command, there
+      must be a single argument MSGID.
+
+   LIST
+      This capability indicates that the server implements at least one
+      variant of the LIST command.  There MUST be one argument for each
+      variant of the LIST command supported by the server, giving the
+      keyword for that variant.
+
+   IMPLEMENTATION
+      This capability MAY be provided by a server.  If so, the arguments
+      SHOULD be used to provide information such as the server software
+      name and version number.  The client MUST NOT use this line to
+      determine capabilities of the server.  (While servers often
+      provide this information in the initial greeting, clients need to
+      guess whether this is the case; this capability makes it clear
+      what the information is.)
+
+   MODE-READER
+      This capability indicates that the server is mode-switching
+      (Section 3.4.2) and that the MODE READER command needs to be used
+      to enable the READER capability.
+
+3.3.3.  Extensions
+
+   Although NNTP is widely and robustly deployed, some parts of the
+   Internet community might wish to extend the NNTP service.  It must be
+   emphasized that any extension to NNTP 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.
+
+   An extension is a package of associated facilities, often but not
+   always including one or more new commands.  Each extension MUST
+   define at least one new capability label (this will often, but need
+   not, be the name of one of these new commands).  While any additional
+   capability information can normally be specified using arguments to
+
+
+
+
+Feather                     Standards Track                    [Page 16]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   that label, an extension MAY define more than one capability label.
+   However, this SHOULD be limited to exceptional circumstances.
+
+   An extension is either a private extension, or its capabilities are
+   included in the IANA registry of capabilities (see Section 3.3.4) and
+   it is defined in an RFC (in which case it is a "registered
+   extension").  Such RFCs either must be on the standards track or must
+   define an IESG-approved experimental protocol.
+
+   The definition of an extension must include the following:
+
+   o  a descriptive name for the extension.
+
+   o  the capability label or labels defined by the extension (the
+      capability label of a registered extension MUST NOT begin with
+      "X").
+
+   o  The syntax, values, and meanings of any arguments for each
+      capability label defined by the extension.
+
+   o  Any new NNTP commands associated with the extension (the names of
+      commands associated with registered extensions MUST NOT begin with
+      "X").
+
+   o  The syntax and possible values of arguments associated with the
+      new NNTP commands.
+
+   o  The response codes and possible values of arguments for the
+      responses of the new NNTP commands.
+
+   o  Any new arguments the extension associates with any other
+      pre-existing NNTP commands.
+
+   o  Any increase in the maximum length of commands and initial
+      response lines over the value specified in this document.
+
+   o  A specific statement about the effect on pipelining that this
+      extension may have (if any).
+
+   o  A specific statement about the circumstances when use of this
+      extension can alter the contents of the capabilities list (other
+      than the new capability labels it defines).
+
+   o  A specific statement about the circumstances under which the
+      extension can cause any pre-existing command to produce a 401,
+      480, or 483 response.
+
+
+
+
+
+Feather                     Standards Track                    [Page 17]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   o  A description of how the use of MODE READER on a mode-switching
+      server interacts with the extension.
+
+   o  A description of how support for the extension affects the
+      behaviour of a server and NNTP client in any other manner not
+      outlined above.
+
+   o  Formal syntax as described in Section 9.9.
+
+   A private extension MAY or MAY NOT be included in the capabilities
+   list.  If it is, the capability label MUST begin with "X".  A server
+   MAY provide additional keywords (for new commands and also for new
+   variants of existing commands) as part of a private extension.  To
+   avoid the risk of a clash with a future registered extension, these
+   keywords SHOULD begin with "X".
+
+   If the server advertises a capability defined by a registered
+   extension, it MUST implement the extension so as to fully conform
+   with the specification (for example, it MUST implement all the
+   commands that the extension describes as mandatory).  If it does not
+   implement the extension as specified, it MUST NOT list the extension
+   in the capabilities list under its registered name.  In that case, it
+   MAY, but SHOULD NOT, provide a private extension (not listed, or
+   listed with a different name) that implements part of the extension
+   or implements the commands of the extension with a different meaning.
+
+   A server MUST NOT send different response codes to basic NNTP
+   commands documented here or to commands documented in registered
+   extensions in response to the availability or use of a private
+   extension.
+
+3.3.4.  Initial IANA Register
+
+   IANA will maintain a registry of NNTP capability labels.  All
+   capability labels in the registry MUST be keywords and MUST NOT begin
+   with X.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 18]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The initial content of the registry consists of these entries:
+
+   +-------------------+--------------------------+--------------------+
+   | Label             | Meaning                  | Definition         |
+   +-------------------+--------------------------+--------------------+
+   | AUTHINFO          | Authentication           | [NNTP-AUTH]        |
+   |                   |                          |                    |
+   | HDR               | Batched header retrieval | Section 3.3.2,     |
+   |                   |                          | Section 8.5, and   |
+   |                   |                          | Section 8.6        |
+   |                   |                          |                    |
+   | IHAVE             | IHAVE command available  | Section 3.3.2 and  |
+   |                   |                          | Section 6.3.2      |
+   |                   |                          |                    |
+   | IMPLEMENTATION    | Server                   | Section 3.3.2      |
+   |                   | implementation-specific  |                    |
+   |                   | information              |                    |
+   |                   |                          |                    |
+   | LIST              | LIST command variants    | Section 3.3.2 and  |
+   |                   |                          | Section 7.6.1      |
+   |                   |                          |                    |
+   | MODE-READER       | Mode-switching server    | Section 3.4.2      |
+   |                   | and MODE READER command  |                    |
+   |                   | available                |                    |
+   |                   |                          |                    |
+   | NEWNEWS           | NEWNEWS command          | Section 3.3.2 and  |
+   |                   | available                | Section 7.4        |
+   |                   |                          |                    |
+   | OVER              | Overview support         | Section 3.3.2,     |
+   |                   |                          | Section 8.3, and   |
+   |                   |                          | Section 8.4        |
+   |                   |                          |                    |
+   | POST              | POST command available   | Section 3.3.2 and  |
+   |                   |                          | Section 6.3.1      |
+   |                   |                          |                    |
+   | READER            | Reader commands          | Section 3.3.2      |
+   |                   | available                |                    |
+   |                   |                          |                    |
+   | SASL              | Supported SASL           | [NNTP-AUTH]        |
+   |                   | mechanisms               |                    |
+   |                   |                          |                    |
+   | STARTTLS          | Transport layer security | [NNTP-TLS]         |
+   |                   |                          |                    |
+   | STREAMING         | Streaming feeds          | [NNTP-STREAM]      |
+   |                   |                          |                    |
+   | VERSION           | Supported NNTP versions  | Section 3.3.2      |
+   +-------------------+--------------------------+--------------------+
+
+
+
+
+Feather                     Standards Track                    [Page 19]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+3.4.  Mandatory and Optional Commands
+
+   For a number of reasons, not all the commands in this specification
+   are mandatory.  However, it is equally undesirable for every command
+   to be optional, since this means that a client will have no idea what
+   facilities are available.  Therefore, as a compromise, some of the
+   commands in this specification are mandatory (they must be supported
+   by all servers) while the remainder are not.  The latter are then
+   subdivided into bundles, each indicated by a single capability label.
+
+   o  If the label is included in the capability list returned by the
+      server, the server MUST support all commands in that bundle.
+
+   o  If the label is not included, the server MAY support none or some
+      of the commands but SHOULD NOT support all of them.  In general,
+      there will be no way for a client to determine which commands are
+      supported without trying them.
+
+   The bundles have been chosen to provide useful functionality, and
+   therefore server authors are discouraged from implementing only part
+   of a bundle.
+
+   The description of each command will either indicate that it is
+   mandatory, or will give, using the term "indicating capability", the
+   capability label indicating whether the bundle including this command
+   is available.
+
+   Where a server does not implement a command, it MUST always generate
+   a 500 generic response code (or a 501 generic response code in the
+   case of a variant of a command depending on a second keyword where
+   the base command is recognised).  Otherwise, the command MUST be
+   fully implemented as specified; a server MUST NOT only partially
+   implement any of the commands in this specification.  (Client authors
+   should note that some servers not conforming to this specification
+   will return a 502 generic response code to some commands that are not
+   implemented.)
+
+   Note: some commands have cases that require other commands to be used
+   first.  If the former command is implemented but the latter is not,
+   the former MUST still generate the relevant specific response code.
+   For example, if ARTICLE (Section 6.2.1) is implemented but GROUP
+   (Section 6.1.1) is not, the correct response to "ARTICLE 1234"
+   remains 412.
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 20]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+3.4.1.  Reading and Transit Servers
+
+   NNTP is traditionally used in two different ways.  The first use is
+   "reading", where the client fetches articles from a large store
+   maintained by the server for immediate or later presentation to a
+   user and sends articles created by that user back to the server (an
+   action called "posting") to be stored and distributed to other stores
+   and users.  The second use is for the bulk transfer of articles from
+   one store to another.  Since the hosts making this transfer tend to
+   be peers in a network that transmit articles among one another, and
+   not end-user systems, this process is called "peering" or "transit".
+   (Even so, one host is still the client and the other is the server).
+
+   In practice, these two uses are so different that some server
+   implementations are optimised for reading or for transit and, as a
+   result, do not offer the other facility or only offer limited
+   features.  Other implementations are more general and offer both.
+   This specification allows for this by bundling the relevant commands
+   accordingly: the IHAVE command is designed for transit, while the
+   commands indicated by the READER capability are designed for reading
+   clients.
+
+   Except as an effect of the MODE READER command (Section 5.3) on a
+   mode-switching server, once a server advertises either or both of the
+   IHAVE or READER capabilities, it MUST continue to advertise them for
+   the entire session.
+
+   A server MAY provide different modes of behaviour (transit, reader,
+   or a combination) to different client connections and MAY use
+   external information, such as the IP address of the client, to
+   determine which mode to provide to any given connection.
+
+   The official TCP port for the NNTP service is 119.  However, if a
+   host wishes to offer separate servers for transit and reading
+   clients, port 433 SHOULD be used for the transit server and 119 for
+   the reading server.
+
+3.4.2.  Mode Switching
+
+   An implementation MAY, but SHOULD NOT, provide both transit and
+   reader facilities on the same server but require the client to select
+   which it wishes to use.  Such an arrangement is called a
+   "mode-switching" server.
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 21]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   A mode-switching server has two modes:
+
+   o  Transit mode, which applies after the initial connection.
+
+      *  It MUST advertise the MODE-READER capability.
+
+      *  It MUST NOT advertise the READER capability.
+
+      However, the server MAY cease to advertise the MODE-READER
+      capability after the client uses any command except CAPABILITIES.
+
+   o  Reading mode, after a successful MODE READER command (see Section
+      5.3).
+
+      *  It MUST NOT advertise the MODE-READER capability.
+
+      *  It MUST advertise the READER capability.
+
+      *  It MAY NOT advertise the IHAVE capability, even if it was
+         advertising it in transit mode.
+
+   A client SHOULD only issue a MODE READER command to a server if it is
+   advertising the MODE-READER capability.  If the server does not
+   support CAPABILITIES (and therefore does not conform to this
+   specification), the client MAY use the following heuristic:
+
+   o  If the client wishes to use any "reader" commands, it SHOULD use
+      the MODE READER command immediately after the initial connection.
+
+   o  Otherwise, it SHOULD NOT use the MODE READER command.
+
+   In each case, it should be prepared for some commands to be
+   unavailable that would have been available if it had made the other
+   choice.
+
+3.5.  Pipelining
+
+   NNTP is designed to operate over a reliable bi-directional
+   connection, such as TCP.  Therefore, if a command does not depend on
+   the response to the previous one, it should not matter if it is sent
+   before that response is received.  Doing this is called "pipelining".
+   However, certain server implementations throw away all text received
+   from the client following certain commands before sending their
+   response.  If this happens, pipelining will be affected because one
+   or more commands will have been ignored or misinterpreted, and the
+   client will be matching the wrong responses to each command.  Since
+   there are significant benefits to pipelining, but also circumstances
+   where it is reasonable or common for servers to behave in the above
+
+
+
+Feather                     Standards Track                    [Page 22]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   manner, this document puts certain requirements on both clients and
+   servers.
+
+   Except where stated otherwise, a client MAY use pipelining.  That is,
+   it may send a command before receiving the response for the previous
+   command.  The server MUST allow pipelining and MUST NOT throw away
+   any text received after a command.  Irrespective of whether
+   pipelining is used, the server MUST process commands in the order
+   they are sent.
+
+   If the specific description of a command says it "MUST NOT be
+   pipelined", that command MUST end any pipeline of commands.  That is,
+   the client MUST NOT send any following command until it receives the
+   CRLF at the end of the response from the command.  The server MAY
+   ignore any data received after the command and before the CRLF at the
+   end of the response is sent to the client.
+
+   The initial connection must not be part of a pipeline; that is, the
+   client MUST NOT send any command until it receives the CRLF at the
+   end of the greeting.
+
+   If the client uses blocking system calls to send commands, it MUST
+   ensure that the amount of text sent in pipelining does not cause a
+   deadlock between transmission and reception.  The amount of text
+   involved will depend on window sizes in the transmission layer;
+   typically, it is 4k octets for TCP.  (Since the server only sends
+   data in response to commands from the client, the converse problem
+   does not occur.)
+
+3.5.1.  Examples
+
+   Example of correct use of pipelining:
+
+      [C] GROUP misc.test
+      [C] STAT
+      [C] NEXT
+      [S] 211 1234 3000234 3002322 misc.test
+      [S] 223 3000234 <45223423@example.com> retrieved
+      [S] 223 3000237 <668929@example.org> retrieved
+
+   Example of incorrect use of pipelining (the MODE READER command may
+   not be pipelined):
+
+      [C] MODE READER
+      [C] DATE
+      [C] NEXT
+      [S] 200 Server ready, posting allowed
+      [S] 223 3000237 <668929@example.org> retrieved
+
+
+
+Feather                     Standards Track                    [Page 23]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The DATE command has been thrown away by the server, so there is no
+   111 response to match it.
+
+3.6.  Articles
+
+   NNTP is intended to transfer articles between clients and servers.
+   For the purposes of this specification, articles are required to
+   conform to the rules in this section, and clients and servers MUST
+   correctly process any article received from the other that does so.
+   Note that this requirement applies only to the contents of
+   communications over NNTP; it does not prevent the client or server
+   from subsequently rejecting an article for reasons of local policy.
+   Also see Appendix A for further restrictions on the format of
+   articles in some uses of NNTP.
+
+   An article consists of two parts: the headers and the body.  They are
+   separated by a single empty line, or in other words by two
+   consecutive CRLF pairs (if there is more than one empty line, the
+   second and subsequent ones are part of the body).  In order to meet
+   the general requirements of NNTP, an article MUST NOT include the
+   octet NUL, MUST NOT contain the octets LF and CR other than as part
+   of a CRLF pair, and MUST end with a CRLF pair.  This specification
+   puts no further restrictions on the body; in particular, it MAY be
+   empty.
+
+   The headers of an article consist of one or more header lines.  Each
+   header line consists of a header name, a colon, a space, the header
+   content, and a CRLF, in that order.  The name consists of one or more
+   printable US-ASCII characters other than colon and, for the purposes
+   of this specification, is not case sensitive.  There MAY be more than
+   one header line with the same name.  The content MUST NOT contain
+   CRLF; it MAY be empty.  A header may be "folded"; that is, a CRLF
+   pair may be placed before any TAB or space in the line.  There MUST
+   still be some other octet between any two CRLF pairs in a header
+   line.  (Note that folding means that the header line occupies more
+   than one line when displayed or transmitted; nevertheless, it is
+   still referred to as "a" header line.)  The presence or absence of
+   folding does not affect the meaning of the header line; that is, the
+   CRLF pairs introduced by folding are not considered part of the
+   header content.  Header lines SHOULD NOT be folded before the space
+   after the colon that follows the header name and SHOULD include at
+   least one octet other than %x09 or %x20 between CRLF pairs.  However,
+   if an article that fails to satisfy this requirement has been
+   received from elsewhere, clients and servers MAY transfer it to each
+   other without re-folding it.
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 24]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The content of a header SHOULD be in UTF-8.  However, if an
+   implementation receives an article from elsewhere that uses octets in
+   the range 128 to 255 in some other manner, it MAY pass it to a client
+   or server without modification.  Therefore, implementations MUST be
+   prepared to receive such headers, and data derived from them (e.g.,
+   in the responses from the OVER command, Section 8.3), and MUST NOT
+   assume that they are always UTF-8.  Any external processing of those
+   headers, including identifying the encoding used, is outside the
+   scope of this document.
+
+   Each article MUST have a unique message-id; two articles offered by
+   an NNTP server MUST NOT have the same message-id.  For the purposes
+   of this specification, message-ids are opaque strings that MUST meet
+   the following requirements:
+
+   o  A message-id MUST begin with "<", end with ">", and MUST NOT
+      contain the latter except at the end.
+
+   o  A message-id MUST be between 3 and 250 octets in length.
+
+   o  A message-id MUST NOT contain octets other than printable US-ASCII
+      characters.
+
+   Two message-ids are the same if and only if they consist of the same
+   sequence of octets.
+
+   This specification does not describe how the message-id of an article
+   is determined.  If the server does not have any way to determine a
+   message-id from the article itself, it MUST synthesize one (this
+   specification does not require that the article be changed as a
+   result).  See also Appendix A.2.
+
+4.  The WILDMAT Format
+
+   The WILDMAT format described here is based on the version first
+   developed by Rich Salz [SALZ1992], which was in turn 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 25]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+4.1.  Wildmat Syntax
+
+   A wildmat is described by the following ABNF [RFC4234] syntax, which
+   is an extract of that in Section 9.8.
+
+     wildmat = wildmat-pattern *("," ["!"] wildmat-pattern)
+     wildmat-pattern = 1*wildmat-item
+     wildmat-item = wildmat-exact / wildmat-wild
+     wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E /
+          UTF8-non-ascii ; exclude ! * , ? [ \ ]
+     wildmat-wild = "*" / "?"
+
+   Note: the characters ",", "\", "[", and "]" are not allowed in
+   wildmats, while * and ? are always wildcards.  This should not be a
+   problem, since these characters cannot occur in newsgroup names,
+   which is the only current use of wildmats.  Backslash is commonly
+   used to suppress the special meaning of characters, whereas brackets
+   are used to introduce sets.  However, these usages are not universal,
+   and interpretation of these characters in the context of UTF-8
+   strings is potentially complex and differs from existing practice, so
+   they were omitted from this specification.  A future extension to
+   this specification may provide semantics for these characters.
+
+4.2.  Wildmat Semantics
+
+   A wildmat is tested against a string and either matches or does not
+   match.  To do this, each constituent <wildmat-pattern> is matched
+   against the string, and the rightmost pattern that matches is
+   identified.  If that <wildmat-pattern> is not preceded with "!", the
+   whole wildmat matches.  If it is preceded by "!", or if no <wildmat-
+   pattern> matches, the whole wildmat does not match.
+
+   For example, consider the wildmat "a*,!*b,*c*":
+
+   o  The string "aaa" matches because the rightmost match is with "a*".
+
+   o  The string "abb" does not match because the rightmost match is
+      with "*b".
+
+   o  The string "ccb" matches because the rightmost match is with
+      "*c*".
+
+   o  The string "xxx" does not match because no <wildmat-pattern>
+      matches.
+
+   A <wildmat-pattern> matches a string if the string can be broken into
+   components, each of which matches the corresponding <wildmat-item> in
+   the pattern.  The matches must be in the same order, and the whole
+
+
+
+Feather                     Standards Track                    [Page 26]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   string must be used in the match.  The pattern is "anchored"; that
+   is, the first and last characters in the string must match the first
+   and last item, respectively (unless that item is an asterisk matching
+   zero characters).
+
+   A <wildmat-exact> matches the same character (which may be more than
+   one octet in UTF-8).
+
+   "?" matches exactly one character (which may be more than one octet).
+
+   "*" matches zero or more characters.  It can match an empty string,
+   but it cannot match a subsequence of a UTF-8 sequence that is not
+   aligned to the character boundaries.
+
+4.3.  Extensions
+
+   An NNTP server or extension MAY extend the syntax or semantics of
+   wildmats provided that all wildmats that meet the requirements of
+   Section 4.1 have the meaning ascribed to them by Section 4.2.  Future
+   editions of this document may also extend wildmats.
+
+4.4.  Examples
+
+   In these examples, $ and @ are used to represent the two octets %xC2
+   and %xA3, respectively; $@ is thus the UTF-8 encoding for the pound
+   sterling symbol, shown as # in the descriptions.
+
+     Wildmat    Description of strings that match
+       abc      The one string "abc"
+       abc,def  The two strings "abc" and "def"
+       $@       The one character string "#"
+       a*       Any string that begins with "a"
+       a*b      Any string that begins with "a" and ends with "b"
+       a*,*b    Any string that begins with "a" or ends with "b"
+       a*,!*b   Any string that begins with "a" and does not end with
+                "b"
+     a*,!*b,c*  Any string that begins with "a" and does not end with
+                "b", and any string that begins with "c" no matter
+                what it ends with
+     a*,c*,!*b  Any string that begins with "a" or "c" and does not
+                end with "b"
+       ?a*      Any string with "a" as its second character
+       ??a*     Any string with "a" as its third character
+       *a?      Any string with "a" as its penultimate character
+       *a??     Any string with "a" as its antepenultimate character
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 27]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+5.  Session Administration Commands
+
+5.1.  Initial Connection
+
+5.1.1.  Usage
+
+   This command MUST NOT be pipelined.
+
+   Responses [1]
+     200    Service available, posting allowed
+     201    Service available, posting prohibited
+     400    Service temporarily unavailable [2]
+     502    Service permanently unavailable [2]
+
+   [1] These are the only valid response codes for the initial greeting;
+       the server MUST not return any other generic response code.
+
+   [2] Following a 400 or 502 response, the server MUST immediately
+       close the connection.
+
+5.1.2.  Description
+
+   There is no command 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 response informs the client
+   whether service is available and whether the client is permitted to
+   post.
+
+   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 the client 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. 400 SHOULD be used if the
+   issue is only temporary (for example, because of load) and the client
+   can expect to be able to connect successfully at some point in the
+   future without making any changes. 502 MUST be used if the client is
+   not permitted under any circumstances to interact with the server,
+   and MAY be used if the server has insufficient information to
+   determine whether the issue is temporary or permanent.
+
+   Note: the distinction between the 200 and 201 response codes has
+   turned out in practice to be insufficient; for example, some servers
+   do not allow posting until the client has authenticated, while other
+   clients assume that a 201 response means that posting will never be
+   possible even after authentication.  Therefore, clients SHOULD use
+
+
+
+Feather                     Standards Track                    [Page 28]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   the CAPABILITIES command (Section 5.2) rather than rely on this
+   response.
+
+5.1.3.  Examples
+
+   Example of a normal connection from an authorized client that then
+   terminates the session (see Section 5.4):
+
+      [Initial connection set-up completed.]
+      [S] 200 NNTP Service Ready, posting permitted
+      [C] QUIT
+      [S] 205 NNTP Service exits normally
+      [Server closes connection.]
+
+   Example of a normal connection from an authorized client that is not
+   permitted to post, which also immediately terminates the session:
+
+      [Initial connection set-up completed.]
+      [S] 201 NNTP Service Ready, posting prohibited
+      [C] QUIT
+      [S] 205 NNTP Service exits normally
+      [Server closes connection.]
+
+   Example of a normal connection from an unauthorized client:
+
+      [Initial connection set-up completed.]
+      [S] 502 NNTP Service permanently unavailable
+      [Server closes connection.]
+
+   Example of a connection from a client if the server is unable to
+   provide service:
+
+      [Initial connection set-up completed.]
+      [S] 400 NNTP Service temporarily unavailable
+      [Server closes connection.]
+
+5.2.  CAPABILITIES
+
+5.2.1.  Usage
+
+   This command is mandatory.
+
+   Syntax
+     CAPABILITIES [keyword]
+
+   Responses
+     101    Capability list follows (multi-line)
+
+
+
+
+Feather                     Standards Track                    [Page 29]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Parameters
+     keyword    additional feature, see description
+
+5.2.2.  Description
+
+   The CAPABILITIES command allows a client to determine the
+   capabilities of the server at any given time.
+
+   This command MAY be issued at any time; the server MUST NOT require
+   it to be issued in order to make use of any capability.  The response
+   generated by this command MAY change during a session because of
+   other state information (which, in turn, may be changed by the
+   effects of other commands or by external events).  An NNTP client is
+   only able to get the current and correct information concerning
+   available capabilities at any point during a session by issuing a
+   CAPABILITIES command at that point of that session and processing the
+   response.
+
+   The capability list is returned as a multi-line data block following
+   the 101 response code.  Each capability is described by a separate
+   capability line.  The server MUST NOT list the same capability twice
+   in the response, even with different arguments.  Except that the
+   VERSION capability MUST be the first line, the order in which the
+   capability lines appears is not significant; the server need not even
+   consistently return the same order.
+
+   While some capabilities are likely to be always available or never
+   available, others (notably extensions) will appear and disappear
+   depending on server state changes within the session or on external
+   events between sessions.  An NNTP client MAY cache the results of
+   this command, but MUST NOT rely on the correctness of any cached
+   results, whether from earlier in this session or from a previous
+   session, MUST cope gracefully with the cached status being out of
+   date, and SHOULD (if caching results) provide a way to force the
+   cached information to be refreshed.  Furthermore, a client MUST NOT
+   use cached results in relation to security, privacy, and
+   authentication extensions.  See Section 12.6 for further discussion
+   of this topic.
+
+   The keyword argument is not used by this specification.  It is
+   provided so that extensions or revisions to this specification can
+   include extra features for this command without requiring the
+   CAPABILITIES command to be used twice (once to determine if the extra
+   features are available, and a second time to make use of them).  If
+   the server does not recognise the argument (and it is a keyword), it
+   MUST respond with the 101 response code as if the argument had been
+   omitted.  If an argument is provided that the server does recognise,
+   it MAY use the 101 response code or MAY use some other response code
+
+
+
+Feather                     Standards Track                    [Page 30]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   (which will be defined in the specification of that feature).  If the
+   argument is not a keyword, the 501 generic response code MUST be
+   returned.  The server MUST NOT generate any other response code to
+   the CAPABILITIES command.
+
+5.2.3.  Examples
+
+   Example of a minimal response (a read-only server):
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] .
+
+   Example of a response from a server that has a range of facilities
+   and that also describes itself:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] IHAVE
+      [S] POST
+      [S] NEWNEWS
+      [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES OVERVIEW.FMT
+      [S] IMPLEMENTATION INN 4.2 2004-12-25
+      [S] OVER MSGID
+      [S] STREAMING
+      [S] XSECRET
+      [S] .
+
+   Example of a server that supports more than one version of NNTP:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2 3
+      [S] READER
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] .
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 31]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of a client attempting to use a feature of the CAPABILITIES
+   command that the server does not support:
+
+      [C] CAPABILITIES AUTOUPDATE
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] IHAVE
+      [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT HEADERS
+      [S] OVER MSGID
+      [S] HDR
+      [S] NEWNEWS
+      [S] .
+
+5.3.  MODE READER
+
+5.3.1.  Usage
+
+   Indicating capability: MODE-READER
+
+   This command MUST NOT be pipelined.
+
+   Syntax
+     MODE READER
+
+   Responses
+     200    Posting allowed
+     201    Posting prohibited
+     502    Reading service permanently unavailable [1]
+
+   [1] Following a 502 response the server MUST immediately close the
+       connection.
+
+5.3.2.  Description
+
+   The MODE READER command instructs a mode-switching server to switch
+   modes, as described in Section 3.4.2.
+
+   If the server is mode-switching, it switches from its transit mode to
+   its reader mode, indicating this by changing the capability list
+   accordingly.  It MUST then return a 200 or 201 response with the same
+   meaning as for the initial greeting (as described in Section 5.1.1).
+   Note that the response need not be the same as that presented during
+   the initial greeting.  The client MUST NOT issue MODE READER more
+   than once in a session or after any security or privacy commands are
+   issued.  When the MODE READER command is issued, the server MAY reset
+   its state to that immediately after the initial connection before
+   switching mode.
+
+
+
+Feather                     Standards Track                    [Page 32]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   If the server is not mode-switching, then the following apply:
+
+   o  If it advertises the READER capability, it MUST return a 200 or
+      201 response with the same meaning as for the initial greeting; in
+      this case, the command MUST NOT affect the server state in any
+      way.
+
+   o  If it does not advertise the READER capability, it MUST return a
+      502 response and then immediately close the connection.
+
+5.3.3.  Examples
+
+   Example of use of the MODE READER command on a transit-only server
+   (which therefore does not providing reading facilities):
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] IHAVE
+      [S] .
+      [C] MODE READER
+      [S] 502 Transit service only
+      [Server closes connection.]
+
+   Example of use of the MODE READER command on a server that provides
+   reading facilities:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] .
+      [C] MODE READER
+      [S] 200 Reader mode, posting permitted
+      [C] IHAVE <i.am.an.article.you.have@example.com>
+      [S] 500 Permission denied
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+
+   Note that in both of these situations, the client SHOULD NOT use MODE
+   READER.
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 33]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of use of the MODE READER command on a mode-switching server:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] IHAVE
+      [S] MODE-READER
+      [S] .
+      [C] MODE READER
+      [S] 200 Reader mode, posting permitted
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] NEWNEWS
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] STARTTLS
+      [S] .
+
+   In this case, the server offers (but does not require) TLS privacy in
+   its reading mode but not in its transit mode.
+
+   Example of use of the MODE READER command where the client is not
+   permitted to post:
+
+      [C] MODE READER
+      [S] 201 NNTP Service Ready, posting prohibited
+
+5.4.  QUIT
+
+5.4.1.  Usage
+
+   This command is mandatory.
+
+   Syntax
+     QUIT
+
+   Responses
+     205    Connection closing
+
+5.4.2.  Description
+
+   The client uses the QUIT command to terminate the session.  The
+   server 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 of its transactions with the
+   NNTP server.
+
+
+
+
+Feather                     Standards Track                    [Page 34]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   If a client simply disconnects (or if 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.
+
+   The server MUST NOT generate any response code to the QUIT command
+   other than 205 or, if any arguments are provided, 501.
+
+5.4.3.  Examples
+
+      [C] QUIT
+      [S] 205 closing connection
+      [Server closes connection.]
+
+6.  Article Posting and 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.  The first type of key is the message-id
+   of an article and is globally unique.  The second type of key is
+   composed of a newsgroup name and an article number within that
+   newsgroup.  On a particular server, there MUST only be one article
+   with a given number within any newsgroup, and an article MUST NOT
+   have two different numbers in the same newsgroup.  An article can be
+   cross-posted to multiple newsgroups, so there may be multiple keys
+   that point to the same article on the same server; these MAY have
+   different numbers in each newsgroup.  However, this type of key is
+   not required to be globally unique, so the same key MAY refer to
+   different articles on different servers.  (Note that the terms
+   "group" and "newsgroup" are equivalent.)
+
+   The final type of 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 2,147,483,647, inclusive.  The
+   client and server MAY use leading zeroes in specifying article
+   numbers but MUST NOT use more than 16 digits.  In some situations,
+   the value zero replaces an article number to show some special
+   situation.
+
+   Note that it is likely that the article number limit of 2,147,483,647
+   will be increased by a future revision or extension to this
+   specification.  While servers MUST NOT send article numbers greater
+   than this current limit, client and server developers are advised to
+
+
+
+Feather                     Standards Track                    [Page 35]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   use internal structures and datatypes capable of handling larger
+   values in anticipation of such a change.
+
+6.1.  Group and Article Selection
+
+   The following commands are used to set the "currently selected
+   newsgroup" and the "current article number", which are used by
+   various commands.  At the start of an NNTP session, both of these
+   values are set to the special value "invalid".
+
+6.1.1.  GROUP
+
+6.1.1.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     GROUP group
+
+   Responses
+     211 number low high group     Group successfully selected
+     411                           No such newsgroup
+
+   Parameters
+     group     Name of newsgroup
+     number    Estimated number of articles in the group
+     low       Reported low water mark
+     high      Reported high water mark
+
+6.1.1.2.  Description
+
+   The GROUP command selects a newsgroup as the currently selected
+   newsgroup and returns summary information about it.
+
+   The required argument is the name of the newsgroup to be selected
+   (e.g., "news.software.nntp").  A list of valid newsgroups may be
+   obtained by using the LIST ACTIVE command (see Section 7.6.3).
+
+   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 in the group currently available.
+
+   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
+
+
+
+Feather                     Standards Track                    [Page 36]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   currently stored.  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.
+
+   o  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.
+
+   o  All three numbers will be zero.
+
+   o  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
+      it is 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:
+
+   o  Articles may be removed from the group.
+
+   o  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).
+
+   o  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 and the high water mark has
+      been adjusted accordingly, the next new article will not have the
+      number one greater than the reported high water mark.)
+
+   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 in this session, and it SHOULD be no less
+   than that in any previous response for that newsgroup ever sent to
+   any client.  Any failure to meet the latter condition SHOULD be
+   transient only.  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
+
+
+
+
+Feather                     Standards Track                    [Page 37]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   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
+   currently selected newsgroup MUST be set to that group, and the
+   current article number MUST be set to the first article in the group
+   (this applies even if the group is already the currently selected
+   newsgroup).  If an empty newsgroup is selected, the current article
+   number is made invalid.  If an invalid group is specified, the
+   currently selected newsgroup and current article number MUST NOT be
+   changed.
+
+   The GROUP or LISTGROUP command (see Section 6.1.2) MUST be used by a
+   client, and a successful response received, before any other command
+   is used that depends on the value of the currently selected newsgroup
+   or current article number.
+
+   If the group specified is not available on the server, a 411 response
+   MUST be returned.
+
+6.1.1.3.  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
+      [S] 411 example.is.sob.bradner.or.barber is unknown
+
+   Example of an empty group using the preferred response:
+
+      [C] GROUP example.currently.empty.newsgroup
+      [S] 211 0 4000 3999 example.currently.empty.newsgroup
+
+   Example of an empty group using an alternative response:
+
+      [C] GROUP example.currently.empty.newsgroup
+      [S] 211 0 0 0 example.currently.empty.newsgroup
+
+   Example of an empty group using a different alternative response:
+
+      [C] GROUP example.currently.empty.newsgroup
+      [S] 211 0 4000 4321 example.currently.empty.newsgroup
+
+
+
+
+
+Feather                     Standards Track                    [Page 38]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example reselecting the currently selected newsgroup:
+
+      [C] GROUP misc.test
+      [S] 211 1234 234 567 misc.test
+      [C] STAT 444
+      [S] 223 444 <123456@example.net> retrieved
+      [C] GROUP misc.test
+      [S] 211 1234 234 567 misc.test
+      [C] STAT
+      [S] 223 234 <different@example.net> retrieved
+
+6.1.2.  LISTGROUP
+
+6.1.2.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     LISTGROUP [group [range]]
+
+   Responses
+     211 number low high group     Article numbers follow (multi-line)
+     411                           No such newsgroup
+     412                           No newsgroup selected [1]
+
+   Parameters
+     group     Name of newsgroup
+     range     Range of articles to report
+     number    Estimated number of articles in the group
+     low       Reported low water mark
+     high      Reported high water mark
+
+   [1] The 412 response can only occur if no group has been specified.
+
+6.1.2.2.  Description
+
+   The LISTGROUP command selects a newsgroup in the same manner as the
+   GROUP command (see Section 6.1.1) but also provides a list of article
+   numbers in the newsgroup.  If no group is specified, the currently
+   selected newsgroup is used.
+
+   On success, a list of article numbers is returned as a multi-line
+   data block following the 211 response code (the arguments on the
+   initial response line are the same as for the GROUP command).  The
+   list contains one number per line and is in numerical order.  It
+   lists precisely those articles that exist in the group at the moment
+   of selection (therefore, an empty group produces an empty list).  If
+   the optional range argument is specified, only articles within the
+
+
+
+Feather                     Standards Track                    [Page 39]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   range are included in the list (therefore, the list MAY be empty even
+   if the group is not).
+
+   The range argument may be any of the following:
+
+   o  An article number.
+
+   o  An article number followed by a dash to indicate all following.
+
+   o  An article number followed by a dash followed by another article
+      number.
+
+   In the last case, if the second number is less than the first number,
+   then the range contains no articles.  Omitting the range is
+   equivalent to the range 1- being specified.
+
+   If the group specified is not available on the server, a 411 response
+   MUST be returned.  If no group is specified and the currently
+   selected newsgroup is invalid, a 412 response MUST be returned.
+
+   Except that the group argument is optional, that a range argument can
+   be specified, and that a multi-line data block follows the 211
+   response code, the LISTGROUP command is identical to the GROUP
+   command.  In particular, when successful, the command sets the
+   current article number to the first article in the group, if any,
+   even if this is not within the range specified by the second
+   argument.
+
+   Note that the range argument is a new feature in this specification
+   and servers that do not support CAPABILITIES (and therefore do not
+   conform to this specification) are unlikely to support it.
+
+6.1.2.3.  Examples
+
+   Example of LISTGROUP being used to select a group:
+
+      [C] LISTGROUP misc.test
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] 3000234
+      [S] 3000237
+      [S] 3000238
+      [S] 3000239
+      [S] 3002322
+      [S] .
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 40]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of LISTGROUP on an empty group:
+
+      [C] LISTGROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup list follows
+      [S] .
+
+   Example of LISTGROUP on a valid, currently selected newsgroup:
+
+      [C] GROUP misc.test
+      [S] 211 2000 3000234 3002322 misc.test
+      [C] LISTGROUP
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] 3000234
+      [S] 3000237
+      [S] 3000238
+      [S] 3000239
+      [S] 3002322
+      [S] .
+
+   Example of LISTGROUP with a range:
+
+      [C] LISTGROUP misc.test 3000238-3000248
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] 3000238
+      [S] 3000239
+      [S] .
+
+   Example of LISTGROUP with an empty range:
+
+      [C] LISTGROUP misc.test 12345678-
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] .
+
+   Example of LISTGROUP with an invalid range:
+
+      [C] LISTGROUP misc.test 9999-111
+      [S] 211 2000 3000234 3002322 misc.test list follows
+      [S] .
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 41]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.1.3.  LAST
+
+6.1.3.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     LAST
+
+   Responses
+     223 n message-id    Article found
+     412                 No newsgroup selected
+     420                 Current article number is invalid
+     422                 No previous article in this group
+
+   Parameters
+     n             Article number
+     message-id    Article message-id
+
+6.1.3.2.  Description
+
+   If the currently selected newsgroup is valid, the current article
+   number MUST be set to the previous article in that newsgroup (that
+   is, the highest existing article number less than the current article
+   number).  If successful, a response indicating the new current
+   article number and the message-id of that article MUST be returned.
+   No article text is sent in response to this command.
+
+   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 the current article number is already the first article of the
+   newsgroup, a 422 response MUST be returned.  If the current article
+   number is invalid, a 420 response MUST be returned.  If the currently
+   selected newsgroup is invalid, a 412 response MUST be returned.  In
+   all three cases, the currently selected newsgroup and current article
+   number MUST NOT be altered.
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 42]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.1.3.3.  Examples
+
+   Example of a successful article retrieval using LAST:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] NEXT
+      [S] 223 3000237 <668929@example.org> retrieved
+      [C] LAST
+      [S] 223 3000234 <45223423@example.com> retrieved
+
+   Example of an attempt to retrieve an article without having selected
+   a group (via the GROUP command) first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] LAST
+      [S] 412 no newsgroup selected
+
+   Example of an attempt to retrieve an article using the LAST command
+   when the current article number is that of the first article in the
+   group:
+
+      [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 currently selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] LAST
+      [S] 420 No current article selected
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 43]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.1.4.  NEXT
+
+6.1.4.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     NEXT
+
+   Responses
+     223 n message-id    Article found
+     412                 No newsgroup selected
+     420                 Current article number is invalid
+     421                 No next article in this group
+
+   Parameters
+     n             Article number
+     message-id    Article message-id
+
+6.1.4.2.  Description
+
+   If the currently selected newsgroup is valid, the current article
+   number MUST be set to the next article in that newsgroup (that is,
+   the lowest existing article number greater than the current article
+   number).  If successful, a response indicating the new current
+   article number and the message-id of that article MUST be returned.
+   No article text is sent in response to this command.
+
+   If the current article number is already the last article of the
+   newsgroup, a 421 response MUST be returned.  In all other aspects
+   (apart, of course, from the lack of 422 response), this command is
+   identical to the LAST command (Section 6.1.3).
+
+6.1.4.3.  Examples
+
+   Example of a successful article retrieval using NEXT:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] NEXT
+      [S] 223 3000237 <668929@example.org> retrieved
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 44]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an attempt to retrieve an article without having selected
+   a group (via the GROUP command) first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] NEXT
+      [S] 412 no newsgroup selected
+
+   Example of an attempt to retrieve an article using the NEXT command
+   when the current article number is that of the last article in the
+   group:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] STAT 3002322
+      [S] 223 3002322 <411@example.net> retrieved
+      [C] NEXT
+      [S] 421 No next article to retrieve
+
+   Example of an attempt to retrieve an article using the NEXT command
+   when the currently selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] NEXT
+      [S] 420 No current article selected
+
+6.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 three commands are described
+   in terms of the differences.  As specified in Section 3.6, an article
+   consists of two parts: the article headers and the article body.
+
+   When responding to one of these commands, the server MUST present the
+   entire article or appropriate part and MUST NOT attempt to alter or
+   translate it in any way.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 45]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.2.1.  ARTICLE
+
+6.2.1.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     ARTICLE message-id
+     ARTICLE number
+     ARTICLE
+
+   Responses
+
+   First form (message-id specified)
+     220 0|n message-id    Article follows (multi-line)
+     430                   No article with that message-id
+
+   Second form (article number specified)
+     220 n message-id      Article follows (multi-line)
+     412                   No newsgroup selected
+     423                   No article with that number
+
+   Third form (current article number used)
+     220 n message-id      Article follows (multi-line)
+     412                   No newsgroup selected
+     420                   Current article number is invalid
+
+   Parameters
+     number        Requested article number
+     n             Returned article number
+     message-id    Article message-id
+
+6.2.1.2.  Description
+
+   The ARTICLE command selects an article according to the arguments and
+   presents the entire article (that is, the headers, an empty line, and
+   the body, in that order) to the client.  The command has three forms.
+
+   In the first form, a message-id is specified, and the server presents
+   the article with that message-id.  In this case, the server MUST NOT
+   alter the currently selected newsgroup or current article number.
+   This is both to 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 that may have been cross-posted to more than
+   one newsgroup.
+
+
+
+
+
+Feather                     Standards Track                    [Page 46]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   In the response, the article number MUST be replaced with zero,
+   unless there is a currently selected newsgroup and the article is
+   present in that group, in which case the server MAY use the article's
+   number in that group.  (The server is not required to determine
+   whether the article is in the currently selected newsgroup or, if so,
+   what article number it has; the client MUST always be prepared for
+   zero to be specified.)  The server MUST NOT provide an article number
+   unless use of that number in a second ARTICLE command immediately
+   following this one would return the same article.  Even if the server
+   chooses to return article numbers in these circumstances, it need not
+   do so consistently; it MAY return zero to any such command (also see
+   the STAT examples, Section 6.2.4.3).
+
+   In the second form, an article number is specified.  If there is an
+   article with that number in the currently selected newsgroup, the
+   server MUST set the current article number to that number.
+
+   In the third form, the article indicated by the current article
+   number in the currently selected newsgroup is used.
+
+   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 this article
+   number MUST be no less than the reported low water mark for that
+   group.
+
+   The server MUST NOT change the currently selected newsgroup as a
+   result of this command.  The server MUST NOT change the current
+   article number except when an article number argument was provided
+   and the article exists; in particular, it MUST NOT change it
+   following an unsuccessful response.
+
+   Since the message-id 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 is returned as a multi-line data block following the 220
+   response code.
+
+   If the argument is a message-id and no such article exists, a 430
+   response MUST be returned.  If the argument is a number or is omitted
+   and the currently selected newsgroup is invalid, a 412 response MUST
+   be returned.  If the argument is a number and that article does not
+   exist in the currently selected newsgroup, a 423 response MUST be
+   returned.  If the argument is omitted and the current article number
+   is invalid, a 420 response MUST be returned.
+
+
+
+
+
+Feather                     Standards Track                    [Page 47]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.2.1.3.  Examples
+
+   Example of a successful retrieval of an article (explicitly not using
+   an article number):
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] ARTICLE
+      [S] 220 3000234 <45223423@example.com>
+      [S] Path: pathost!demo!whitehouse!not-for-mail
+      [S] From: "Demo User" <nobody@example.net>
+      [S] Newsgroups: misc.test
+      [S] Subject: I am just a test article
+      [S] Date: 6 Oct 1998 04:38:40 -0500
+      [S] Organization: An Example Net, Uncertain, Texas
+      [S] Message-ID: <45223423@example.com>
+      [S]
+      [S] This is just a test article.
+      [S] .
+
+   Example of a successful retrieval of an article by message-id:
+
+      [C] ARTICLE <45223423@example.com>
+      [S] 220 0 <45223423@example.com>
+      [S] Path: pathost!demo!whitehouse!not-for-mail
+      [S] From: "Demo User" <nobody@example.net>
+      [S] Newsgroups: misc.test
+      [S] Subject: I am just a test article
+      [S] Date: 6 Oct 1998 04:38:40 -0500
+      [S] Organization: An Example Net, Uncertain, Texas
+      [S] Message-ID: <45223423@example.com>
+      [S]
+      [S] This is just a test article.
+      [S] .
+
+   Example of an unsuccessful retrieval of an article by message-id:
+
+      [C] ARTICLE <i.am.not.there@example.com>
+      [S] 430 No Such Article Found
+
+   Example of an unsuccessful retrieval of an article by number:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 news.groups
+      [C] ARTICLE 300256
+      [S] 423 No article with that number
+
+
+
+
+
+Feather                     Standards Track                    [Page 48]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an unsuccessful retrieval of an article by number because
+   no newsgroup was selected first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] ARTICLE 300256
+      [S] 412 No newsgroup selected
+
+   Example of an attempt to retrieve an article when the currently
+   selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] ARTICLE
+      [S] 420 No current article selected
+
+6.2.2.  HEAD
+
+6.2.2.1.  Usage
+
+   This command is mandatory.
+
+   Syntax
+     HEAD message-id
+     HEAD number
+     HEAD
+
+   Responses
+
+   First form (message-id specified)
+     221 0|n message-id    Headers follow (multi-line)
+     430                   No article with that message-id
+
+   Second form (article number specified)
+     221 n message-id      Headers follow (multi-line)
+     412                   No newsgroup selected
+     423                   No article with that number
+
+   Third form (current article number used)
+     221 n message-id      Headers follow (multi-line)
+     412                   No newsgroup selected
+     420                   Current article number is invalid
+
+   Parameters
+     number        Requested article number
+     n             Returned article number
+     message-id    Article message-id
+
+
+
+
+
+Feather                     Standards Track                    [Page 49]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.2.2.2.  Description
+
+   The HEAD command behaves identically to the ARTICLE command except
+   that, if the article exists, the response code is 221 instead of 220
+   and only the headers are presented (the empty line separating the
+   headers and body MUST NOT be included).
+
+6.2.2.3.  Examples
+
+   Example of a successful retrieval of the headers of an article
+   (explicitly not using an article number):
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HEAD
+      [S] 221 3000234 <45223423@example.com>
+      [S] Path: pathost!demo!whitehouse!not-for-mail
+      [S] From: "Demo User" <nobody@example.net>
+      [S] Newsgroups: misc.test
+      [S] Subject: I am just a test article
+      [S] Date: 6 Oct 1998 04:38:40 -0500
+      [S] Organization: An Example Net, Uncertain, Texas
+      [S] Message-ID: <45223423@example.com>
+      [S] .
+
+   Example of a successful retrieval of the headers of an article by
+   message-id:
+
+      [C] HEAD <45223423@example.com>
+      [S] 221 0 <45223423@example.com>
+      [S] Path: pathost!demo!whitehouse!not-for-mail
+      [S] From: "Demo User" <nobody@example.net>
+      [S] Newsgroups: misc.test
+      [S] Subject: I am just a test article
+      [S] Date: 6 Oct 1998 04:38:40 -0500
+      [S] Organization: An Example Net, Uncertain, Texas
+      [S] Message-ID: <45223423@example.com>
+      [S] .
+
+   Example of an unsuccessful retrieval of the headers of an article by
+   message-id:
+
+      [C] HEAD <i.am.not.there@example.com>
+      [S] 430 No Such Article Found
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 50]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an unsuccessful retrieval of the headers of an article by
+   number:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HEAD 300256
+      [S] 423 No article with that number
+
+   Example of an unsuccessful retrieval of the headers of an article by
+   number because no newsgroup was selected first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] HEAD 300256
+      [S] 412 No newsgroup selected
+
+   Example of an attempt to retrieve the headers of an article when the
+   currently selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] HEAD
+      [S] 420 No current article selected
+
+6.2.3.  BODY
+
+6.2.3.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     BODY message-id
+     BODY number
+     BODY
+
+   Responses
+
+   First form (message-id specified)
+     222 0|n message-id    Body follows (multi-line)
+     430                   No article with that message-id
+
+   Second form (article number specified)
+     222 n message-id      Body follows (multi-line)
+     412                   No newsgroup selected
+     423                   No article with that number
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 51]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Third form (current article number used)
+     222 n message-id      Body follows (multi-line)
+     412                   No newsgroup selected
+     420                   Current article number is invalid
+
+   Parameters
+     number        Requested article number
+     n             Returned article number
+     message-id    Article message-id
+
+6.2.3.2.  Description
+
+   The BODY command behaves identically to the ARTICLE command except
+   that, if the article exists, the response code is 222 instead of 220
+   and only the body is presented (the empty line separating the headers
+   and body MUST NOT be included).
+
+6.2.3.3.  Examples
+
+   Example of a successful retrieval of the body of an article
+   (explicitly not using an article number):
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] BODY
+      [S] 222 3000234 <45223423@example.com>
+      [S] This is just a test article.
+      [S] .
+
+   Example of a successful retrieval of the body of an article by
+   message-id:
+
+      [C] BODY <45223423@example.com>
+      [S] 222 0 <45223423@example.com>
+      [S] This is just a test article.
+      [S] .
+
+   Example of an unsuccessful retrieval of the body of an article by
+   message-id:
+
+      [C] BODY <i.am.not.there@example.com>
+      [S] 430 No Such Article Found
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 52]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an unsuccessful retrieval of the body of an article by
+   number:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] BODY 300256
+      [S] 423 No article with that number
+
+   Example of an unsuccessful retrieval of the body of an article by
+   number because no newsgroup was selected first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] BODY 300256
+      [S] 412 No newsgroup selected
+
+   Example of an attempt to retrieve the body of an article when the
+   currently selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] BODY
+      [S] 420 No current article selected
+
+6.2.4.  STAT
+
+6.2.4.1.  Usage
+
+   This command is mandatory.
+
+   Syntax
+     STAT message-id
+     STAT number
+     STAT
+
+   Responses
+
+   First form (message-id specified)
+     223 0|n message-id    Article exists
+     430                   No article with that message-id
+
+   Second form (article number specified)
+     223 n message-id      Article exists
+     412                   No newsgroup selected
+     423                   No article with that number
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 53]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Third form (current article number used)
+     223 n message-id      Article exists
+     412                   No newsgroup selected
+     420                   Current article number is invalid
+
+   Parameters
+     number        Requested article number
+     n             Returned article number
+     message-id    Article message-id
+
+6.2.4.2.  Description
+
+   The STAT command behaves identically to the ARTICLE command except
+   that, if the article exists, it is NOT presented to the client and
+   the response code is 223 instead of 220.  Note that the response is
+   NOT multi-line.
+
+   This command allows the client to determine whether an article exists
+   and, in the second and third forms, what its message-id is, without
+   having to process an arbitrary amount of text.
+
+6.2.4.3.  Examples
+
+   Example of STAT on an existing article (explicitly not using an
+   article number):
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] STAT
+      [S] 223 3000234 <45223423@example.com>
+
+   Example of STAT on an existing article by message-id:
+
+      [C] STAT <45223423@example.com>
+      [S] 223 0 <45223423@example.com>
+
+   Example of STAT on an article not on the server by message-id:
+
+      [C] STAT <i.am.not.there@example.com>
+      [S] 430 No Such Article Found
+
+   Example of STAT on an article not in the server by number:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] STAT 300256
+      [S] 423 No article with that number
+
+
+
+
+Feather                     Standards Track                    [Page 54]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of STAT on an article by number when no newsgroup was
+   selected first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] STAT 300256
+      [S] 412 No newsgroup selected
+
+   Example of STAT on an article when the currently selected newsgroup
+   is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] STAT
+      [S] 420 No current article selected
+
+   Example of STAT by message-id on a server that sometimes reports the
+   actual article number:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] STAT
+      [S] 223 3000234 <45223423@example.com>
+      [C] STAT <45223423@example.com>
+      [S] 223 0 <45223423@example.com>
+      [C] STAT <45223423@example.com>
+      [S] 223 3000234 <45223423@example.com>
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] STAT <45223423@example.com>
+      [S] 223 0 <45223423@example.com>
+      [C] GROUP alt.crossposts
+      [S] 211 9999 111111 222222 alt.crossposts
+      [C] STAT <45223423@example.com>
+      [S] 223 123456 <45223423@example.com>
+      [C] STAT
+      [S] 223 111111 <23894720@example.com>
+
+   The first STAT command establishes the identity of an article in the
+   group.  The second and third show that the server may, but need not,
+   give the article number when the message-id is specified.  The fourth
+   STAT command shows that zero must be specified if the article isn't
+   in the currently selected newsgroup.  The fifth shows that the
+   number, if provided, must be that relating to the currently selected
+   newsgroup.  The last one shows that the current article number is
+   still not changed by the use of STAT with a message-id even if it
+   returns an article number.
+
+
+
+
+
+Feather                     Standards Track                    [Page 55]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.3.  Article Posting
+
+   Article posting is done in one of two ways: individual article
+   posting from news-reading clients using POST, and article transfer
+   from other news servers using IHAVE.
+
+6.3.1.  POST
+
+6.3.1.1.  Usage
+
+   Indicating capability: POST
+
+   This command MUST NOT be pipelined.
+
+   Syntax
+     POST
+
+   Responses
+
+   Initial responses
+     340    Send article to be posted
+     440    Posting not permitted
+
+   Subsequent responses
+     240    Article received OK
+     441    Posting failed
+
+6.3.1.2.  Description
+
+   If posting is allowed, a 340 response MUST be returned to indicate
+   that the article to be posted should be sent.  If posting is
+   prohibited for some installation-dependent reason, a 440 response
+   MUST be returned.
+
+   If posting is permitted, the article MUST be in the format specified
+   in Section 3.6 and MUST be sent by the client to the server as a
+   multi-line data block (see Section 3.1.1).  Thus a single dot (".")
+   on a line indicates the end of the text, and lines starting with a
+   dot in the original text have that dot doubled during transmission.
+
+   Following the presentation of the termination sequence by the client,
+   the server MUST return a response indicating success or failure of
+   the article transfer.  Note that response codes 340 and 440 are used
+   in direct response to the POST command while 240 and 441 are returned
+   after the article is sent.
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 56]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   A response of 240 SHOULD indicate that, barring unforeseen server
+   errors, the posted article will be made available on the server
+   and/or transferred to other servers, as appropriate, possibly
+   following further processing.  In other words, articles not wanted by
+   the server SHOULD be rejected with a 441 response, rather than being
+   accepted and then discarded silently.  However, the client SHOULD NOT
+   assume that the article has been successfully transferred unless it
+   receives an affirmative response from the server and SHOULD NOT
+   assume that it is being made available to other clients without
+   explicitly checking (for example, using the STAT command).
+
+   If the session is interrupted before the response is received, it is
+   possible that an affirmative response was sent but has been lost.
+   Therefore, in any subsequent session, the client SHOULD either check
+   whether the article was successfully posted before resending or
+   ensure that the server will allocate the same message-id to the new
+   attempt (see Appendix A.2).  The latter approach is preferred since
+   the article might not have been made available for reading yet (for
+   example, it may have to go through a moderation process).
+
+6.3.1.3.  Examples
+
+   Example of a successful posting:
+
+      [C] POST
+      [S] 340 Input article; end with <CR-LF>.<CR-LF>
+      [C] From: "Demo User" <nobody@example.net>
+      [C] Newsgroups: misc.test
+      [C] Subject: I am just a test article
+      [C] Organization: An Example Net
+      [C]
+      [C] This is just a test article.
+      [C] .
+      [S] 240 Article received OK
+
+   Example of an unsuccessful posting:
+
+      [C] POST
+      [S] 340 Input article; end with <CR-LF>.<CR-LF>
+      [C] From: "Demo User" <nobody@example.net>
+      [C] Newsgroups: misc.test
+      [C] Subject: I am just a test article
+      [C] Organization: An Example Net
+      [C]
+      [C] This is just a test article.
+      [C] .
+      [S] 441 Posting failed
+
+
+
+
+Feather                     Standards Track                    [Page 57]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an attempt to post when posting is not allowed:
+
+      [Initial connection set-up completed.]
+      [S] 201 NNTP Service Ready, posting prohibited
+      [C] POST
+      [S] 440 Posting not permitted
+
+6.3.2.  IHAVE
+
+6.3.2.1.  Usage
+
+   Indicating capability: IHAVE
+
+   This command MUST NOT be pipelined.
+
+   Syntax
+     IHAVE message-id
+
+   Responses
+
+   Initial responses
+     335    Send article to be transferred
+     435    Article not wanted
+     436    Transfer not possible; try again later
+
+   Subsequent responses
+     235    Article transferred OK
+     436    Transfer failed; try again later
+     437    Transfer rejected; do not retry
+
+   Parameters
+     message-id    Article message-id
+
+6.3.2.2.  Description
+
+   The IHAVE command informs the server that the client has an article
+   with the specified message-id.  If the server desires a copy of that
+   article, a 335 response MUST be returned, 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 435
+   response MUST be returned, indicating that the article is not wanted.
+   Finally, if the article isn't wanted immediately but the client
+   should retry later if possible (if, for example, another client is in
+   the process of sending the same article to the server), a 436
+   response MUST be returned.
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 58]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   If transmission of the article is requested, the client MUST send the
+   entire article, including headers and body, to the server as a
+   multi-line data block (see Section 3.1.1).  Thus, a single dot (".")
+   on a line indicates the end of the text, and lines starting with a
+   dot in the original text have that dot doubled during transmission.
+   The server MUST return a 235 response, indicating that the article
+   was successfully transferred; a 436 response, indicating that the
+   transfer failed but should be tried again later; or a 437 response,
+   indicating that the article was rejected.
+
+   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, since use of this command indicates that the article has
+   already been posted at another site and is simply being forwarded
+   from another host.  However, despite this, 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 problems such as
+   inappropriate newsgroups or distributions, disc space limitations,
+   article lengths, garbled headers, and the like.  These are typically
+   restrictions enforced by the server host's news software and not
+   necessarily by the NNTP server itself.
+
+   The client SHOULD NOT assume that the article has been successfully
+   transferred unless it receives an affirmative response from the
+   server.  A lack of response (such as a dropped network connection or
+   a network timeout) SHOULD be treated the same as a 436 response.
+
+   Because some news server software may not immediately be able to
+   determine whether an article is suitable for posting or forwarding,
+   an NNTP server MAY acknowledge the successful transfer of the article
+   (with a 235 response) but later silently discard it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 59]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+6.3.2.3.  Examples
+
+   Example of successfully sending an article to another site:
+
+      [C] IHAVE <i.am.an.article.you.will.want@example.com>
+      [S] 335 Send it; end with <CR-LF>.<CR-LF>
+      [C] Path: pathost!demo!somewhere!not-for-mail
+      [C] From: "Demo User" <nobody@example.com>
+      [C] Newsgroups: misc.test
+      [C] Subject: I am just a test article
+      [C] Date: 6 Oct 1998 04:38:40 -0500
+      [C] Organization: An Example Com, San Jose, CA
+      [C] Message-ID: <i.am.an.article.you.will.want@example.com>
+      [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.  Note
+   that the message-id in the IHAVE command is not the same as the one
+   in the article headers; while this is bad practice and SHOULD NOT be
+   done, it is not forbidden.
+
+      [C] IHAVE <i.am.an.article.you.will.want@example.com>
+      [S] 335 Send it; end with <CR-LF>.<CR-LF>
+      [C] Path: pathost!demo!somewhere!not-for-mail
+      [C] From: "Demo User" <nobody@example.com>
+      [C] Newsgroups: misc.test
+      [C] Subject: I am just a test article
+      [C] Date: 6 Oct 1998 04:38:40 -0500
+      [C] Organization: An Example Com, San Jose, CA
+      [C] Message-ID: <i.am.an.article.you.have@example.com>
+      [C]
+      [C] This is just a test article.
+      [C] .
+      [S] 437 Article rejected; don't send again
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 60]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of sending an article to another site where the transfer
+   fails:
+
+      [C] IHAVE <i.am.an.article.you.will.want@example.com>
+      [S] 335 Send it; end with <CR-LF>.<CR-LF>
+      [C] Path: pathost!demo!somewhere!not-for-mail
+      [C] From: "Demo User" <nobody@example.com>
+      [C] Newsgroups: misc.test
+      [C] Subject: I am just a test article
+      [C] Date: 6 Oct 1998 04:38:40 -0500
+      [C] Organization: An Example Com, San Jose, CA
+      [C] Message-ID: <i.am.an.article.you.will.want@example.com>
+      [C]
+      [C] This is just a test article.
+      [C] .
+      [S] 436 Transfer failed
+
+   Example of sending an article to a site that already has it:
+
+      [C] IHAVE <i.am.an.article.you.have@example.com>
+      [S] 435 Duplicate
+
+   Example of sending an article to a site that requests that the
+   article be tried again later:
+
+      [C] IHAVE <i.am.an.article.you.defer@example.com>
+      [S] 436 Retry later
+
+7.  Information Commands
+
+   This section lists other commands that may be used at any time
+   between the beginning of a session and its termination.  Using these
+   commands does not alter any state information, but the response
+   generated from their use may provide useful information to clients.
+
+7.1.  DATE
+
+7.1.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     DATE
+
+   Responses
+     111 yyyymmddhhmmss    Server date and time
+
+
+
+
+
+Feather                     Standards Track                    [Page 61]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Parameters
+     yyyymmddhhmmss    Current UTC date and time on server
+
+7.1.2.  Description
+
+   This command exists to help clients find out the current Coordinated
+   Universal Time [TF.686-1] from the server's perspective.  This
+   command SHOULD NOT be used as a substitute for NTP [RFC1305] but to
+   provide information that might be useful when using the NEWNEWS
+   command (see Section 7.4).
+
+   The DATE command MUST return a timestamp from the same clock as is
+   used for determining article arrival and group creation times (see
+   Section 6).  This clock SHOULD be monotonic, and adjustments SHOULD
+   be made by running it fast or slow compared to "real" time rather
+   than by making sudden jumps.  A system providing NNTP service SHOULD
+   keep the system clock as accurate as possible, either with NTP or by
+   some other method.
+
+   The server MUST return a 111 response specifying the date and time on
+   the server in the form yyyymmddhhmmss.  This date and time is in
+   Coordinated Universal Time.
+
+7.1.3.  Examples
+
+      [C] DATE
+      [S] 111 19990623135624
+
+7.2.  HELP
+
+7.2.1.  Usage
+
+   This command is mandatory.
+
+   Syntax
+     HELP
+
+   Responses
+     100    Help text follows (multi-line)
+
+7.2.2.  Description
+
+   This command provides a short summary of the commands that are
+   understood by this implementation of the server.  The help text will
+   be presented as a multi-line data block following the 100 response
+   code.
+
+
+
+
+
+Feather                     Standards Track                    [Page 62]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   This text is not guaranteed to be in any particular format (but must
+   be UTF-8) and MUST NOT be used by clients as a replacement for the
+   CAPABILITIES command described in Section 5.2.
+
+7.2.3.  Examples
+
+      [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] .
+
+7.3.  NEWGROUPS
+
+7.3.1.  Usage
+
+   Indicating capability: READER
+
+   Syntax
+     NEWGROUPS date time [GMT]
+
+   Responses
+     231    List of new newsgroups follows (multi-line)
+
+   Parameters
+     date    Date in yymmdd or yyyymmdd format
+     time    Time in hhmmss format
+
+7.3.2.  Description
+
+   This command returns a list of newsgroups created on the server since
+   the specified date and time.  The results are in the same format as
+   the LIST ACTIVE command (see Section 7.6.3).  However, they MAY
+   include groups not available on the server (and so not returned by
+   LIST ACTIVE) and MAY omit groups for which the creation date is not
+   available.
+
+   The date is specified as 6 or 8 digits in the format [xx]yymmdd,
+   where xx is the first two digits of the year (19-99), yy is the last
+   two digits of the year (00-99), mm is the month (01-12), and dd is
+   the day of the month (01-31).  Clients SHOULD specify all four digits
+   of the year.  If the first two digits of the year are not specified
+   (this is supported only for backward compatibility), the year is to
+   be taken from the current century if yy is smaller than or equal to
+   the current year, and the previous century otherwise.
+
+
+
+
+Feather                     Standards Track                    [Page 63]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The time is specified as 6 digits in the format hhmmss, where hh is
+   the hours in the 24-hour clock (00-23), mm is the minutes (00-59),
+   and ss is the seconds (00-60, to allow for leap seconds).  The token
+   "GMT" specifies that the date and time are given in Coordinated
+   Universal Time [TF.686-1]; if it is omitted, then the date and time
+   are specified in the server's local timezone.  Note that there is no
+   way of using the protocol specified in this document to establish the
+   server's local timezone.
+
+   Note that an empty list is a possible valid response and indicates
+   that there are no new newsgroups since that date-time.
+
+   Clients SHOULD make all queries using Coordinated Universal Time
+   (i.e., by including the "GMT" argument) when possible.
+
+7.3.3.  Examples
+
+   Example where there are new groups:
+
+      [C] NEWGROUPS 19990624 000000 GMT
+      [S] 231 list of new newsgroups follows
+      [S] alt.rfc-writers.recovery 4 1 y
+      [S] tx.natives.recovery 89 56 y
+      [S] .
+
+   Example where there are no new groups:
+
+      [C] NEWGROUPS 19990624 000000 GMT
+      [S] 231 list of new newsgroups follows
+      [S] .
+
+7.4.  NEWNEWS
+
+7.4.1.  Usage
+
+   Indicating capability: NEWNEWS
+
+   Syntax
+     NEWNEWS wildmat date time [GMT]
+
+   Responses
+     230    List of new articles follows (multi-line)
+
+   Parameters
+     wildmat    Newsgroups of interest
+     date       Date in yymmdd or yyyymmdd format
+     time       Time in hhmmss format
+
+
+
+
+Feather                     Standards Track                    [Page 64]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+7.4.2.  Description
+
+   This command returns a list of message-ids of articles posted or
+   received on the server, in the newsgroups whose names match the
+   wildmat, since the specified date and time.  One message-id is sent
+   on each line; the order of the response has no specific significance
+   and may vary from response to response in the same session.  A
+   message-id MAY appear more than once; if it does, it has the same
+   meaning as if it appeared only once.
+
+   Date and time are in the same format as the NEWGROUPS command (see
+   Section 7.3).
+
+   Note that an empty list is a possible valid response and indicates
+   that there is currently no new news in the relevant groups.
+
+   Clients SHOULD make all queries in Coordinated Universal Time (i.e.,
+   by using the "GMT" argument) when possible.
+
+7.4.3.  Examples
+
+   Example where there are new articles:
+
+      [C] NEWNEWS news.*,sci.* 19990624 000000 GMT
+      [S] 230 list of new articles by message-id follows
+      [S] <i.am.a.new.article@example.com>
+      [S] <i.am.another.new.article@example.com>
+      [S] .
+
+   Example where there are no new articles:
+
+      [C] NEWNEWS alt.* 19990624 000000 GMT
+      [S] 230 list of new articles by message-id follows
+      [S] .
+
+7.5.  Time
+
+   As described in Section 6, each article has an arrival timestamp.
+   Each newsgroup also has a creation timestamp.  These timestamps are
+   used by the NEWNEWS and NEWGROUP commands to construct their
+   responses.
+
+   Clients can ensure that they do not have gaps in lists of articles or
+   groups by using the DATE command in the following manner:
+
+   First session:
+      Issue DATE command and record result.
+      Issue NEWNEWS command using a previously chosen timestamp.
+
+
+
+Feather                     Standards Track                    [Page 65]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Subsequent sessions:
+      Issue DATE command and hold result in temporary storage.
+      Issue NEWNEWS command using timestamp saved from previous session.
+      Overwrite saved timestamp with that currently in temporary
+      storage.
+
+   In order to allow for minor errors, clients MAY want to adjust the
+   timestamp back by two or three minutes before using it in NEWNEWS.
+
+7.5.1.  Examples
+
+   First session:
+
+      [C] DATE
+      [S] 111 20010203112233
+      [C] NEWNEWS local.chat 20001231 235959 GMT
+      [S] 230 list follows
+      [S] <article.1@local.service>
+      [S] <article.2@local.service>
+      [S] <article.3@local.service>
+      [S] .
+
+   Second session (the client has subtracted 3 minutes from the
+   timestamp returned previously):
+
+      [C] DATE
+      [S] 111 20010204003344
+      [C] NEWNEWS local.chat 20010203 111933 GMT
+      [S] 230 list follows
+      [S] <article.3@local.service>
+      [S] <article.4@local.service>
+      [S] <article.5@local.service>
+      [S] .
+
+   Note how <article.3@local.service> arrived in the 3 minute gap and so
+   is listed in both responses.
+
+7.6.  The LIST Commands
+
+   The LIST family of commands all return information that is multi-line
+   and that can, in general, be expected not to change during the
+   session.  Often the information is related to newsgroups, in which
+   case the response has one line per newsgroup and a wildmat MAY be
+   provided to restrict the groups for which information is returned.
+
+   The set of available keywords (including those provided by
+   extensions) is given in the capability list with capability label
+   LIST.
+
+
+
+Feather                     Standards Track                    [Page 66]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+7.6.1.  LIST
+
+7.6.1.1.  Usage
+
+   Indicating capability: LIST
+
+   Syntax
+     LIST [keyword [wildmat|argument]]
+
+   Responses
+     215    Information follows (multi-line)
+
+   Parameters
+     keyword     Information requested [1]
+     argument    Specific to keyword
+     wildmat     Groups of interest
+
+   [1] If no keyword is provided, it defaults to ACTIVE.
+
+7.6.1.2.  Description
+
+   The LIST command allows the server to provide blocks of information
+   to the client.  This information may be global or may be related to
+   newsgroups; in the latter case, the information may be returned
+   either for all groups or only for those matching a wildmat.  Each
+   block of information is represented by a different keyword.  The
+   command returns the specific information identified by the keyword.
+
+   If the information is available, it is returned as a multi-line data
+   block following the 215 response code.  The format of the information
+   depends on the keyword.  The information MAY be affected by the
+   additional argument, but the format MUST NOT be.
+
+   If the information is based on newsgroups and the optional wildmat
+   argument is specified, the response is limited to only the groups (if
+   any) whose names match the wildmat and for which the information is
+   available.
+
+   Note that an empty list is a possible valid response; for a
+   newsgroup-based keyword, it indicates that there are no groups
+   meeting the above criteria.
+
+   If the keyword is not recognised, or if an argument is specified and
+   the keyword does not expect one, a 501 response code MUST BE
+   returned.  If the keyword is recognised but the server does not
+   maintain the information, a 503 response code MUST BE returned.
+
+
+
+
+
+Feather                     Standards Track                    [Page 67]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The LIST command MUST NOT change the visible state of the server in
+   any way; that is, the behaviour of subsequent commands MUST NOT be
+   affected by whether the LIST command was issued.  For example, it
+   MUST NOT make groups available that otherwise would not have been.
+
+7.6.1.3.  Examples
+
+   Example of LIST with the ACTIVE keyword:
+
+      [C] LIST ACTIVE
+      [S] 215 list of newsgroups follows
+      [S] misc.test 3002322 3000234 y
+      [S] comp.risks 442001 441099 m
+      [S] alt.rfc-writers.recovery 4 1 y
+      [S] tx.natives.recovery 89 56 y
+      [S] tx.natives.recovery.d 11 9 n
+      [S] .
+
+   Example of LIST with no keyword:
+
+      [C] LIST
+      [S] 215 list of newsgroups follows
+      [S] misc.test 3002322 3000234 y
+      [S] comp.risks 442001 441099 m
+      [S] alt.rfc-writers.recovery 4 1 y
+      [S] tx.natives.recovery 89 56 y
+      [S] tx.natives.recovery.d 11 9 n
+      [S] .
+
+   The output is identical to that of the previous example.
+
+   Example of LIST on a newsgroup-based keyword with and without
+   wildmat:
+
+      [C] LIST ACTIVE.TIMES
+      [S] 215 information follows
+      [S] misc.test 930445408 <creatme@isc.org>
+      [S] alt.rfc-writers.recovery 930562309 <m@example.com>
+      [S] tx.natives.recovery 930678923 <sob@academ.com>
+      [S] .
+      [C] LIST ACTIVE.TIMES tx.*
+      [S] 215 information follows
+      [S] tx.natives.recovery 930678923 <sob@academ.com>
+      [S] .
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 68]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of LIST returning an error where the keyword is recognized
+   but the software does not maintain this information:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA
+      [S] .
+      [C] LIST XTRA.DATA
+      [S] 503 Data item not stored
+
+   Example of LIST where the keyword is not recognised:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] LIST ACTIVE NEWSGROUPS ACTIVE.TIMES XTRA.DATA
+      [S] .
+      [C] LIST DISTRIB.PATS
+      [S] 501 Syntax Error
+
+7.6.2.  Standard LIST Keywords
+
+   This specification defines the following LIST keywords:
+
+   +--------------+---------------+------------------------------------+
+   | Keyword      | Definition    | Status                             |
+   +--------------+---------------+------------------------------------+
+   | ACTIVE       | Section 7.6.3 | Mandatory if the READER capability |
+   |              |               | is advertised                      |
+   |              |               |                                    |
+   | ACTIVE.TIMES | Section 7.6.4 | Optional                           |
+   |              |               |                                    |
+   | DISTRIB.PATS | Section 7.6.5 | Optional                           |
+   |              |               |                                    |
+   | HEADERS      | Section 8.6   | Mandatory if the HDR capability is |
+   |              |               | advertised                         |
+   |              |               |                                    |
+   | NEWSGROUPS   | Section 7.6.6 | Mandatory if the READER capability |
+   |              |               | is advertised                      |
+   |              |               |                                    |
+   | OVERVIEW.FMT | Section 8.4   | Mandatory if the OVER capability   |
+   |              |               | is advertised                      |
+   +--------------+---------------+------------------------------------+
+
+
+
+
+
+Feather                     Standards Track                    [Page 69]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Where one of these LIST keywords is supported by a server, it MUST
+   have the meaning given in the relevant sub-section.
+
+7.6.3.  LIST ACTIVE
+
+   This keyword MUST be supported by servers advertising the READER
+   capability.
+
+   LIST ACTIVE returns a list of valid newsgroups and associated
+   information.  If no wildmat is specified, the server MUST include
+   every group that the client is permitted to select with the GROUP
+   command (Section 6.1.1).  Each line of this list consists of four
+   fields separated from each other by one or more spaces:
+
+   o  The name of the newsgroup.
+   o  The reported high water mark for the group.
+   o  The reported low water mark for the group.
+   o  The current status of the group on this server.
+
+   The reported high and low water marks are as described in the GROUP
+   command (see Section 6.1.1), but note that they are in the opposite
+   order to the 211 response to that command.
+
+   The status field is typically one of the following:
+
+   "y" Posting is permitted.
+
+   "n" Posting is not permitted.
+
+   "m" Postings will be forwarded to the newsgroup moderator.
+
+   The server SHOULD use these values when these meanings are required
+   and MUST NOT use them with any other meaning.  Other values for the
+   status may exist; the definition of these other values and the
+   circumstances under which they are returned may be specified in an
+   extension or may be private to the server.  A client SHOULD treat an
+   unrecognized status as giving no information.
+
+   The status of a newsgroup only indicates how posts to that newsgroup
+   are normally processed and is not necessarily customised to the
+   specific client.  For example, if the current client is forbidden
+   from posting, then this will apply equally to groups with status "y".
+   Conversely, a client with special privileges (not defined by this
+   specification) might be able to post to a group with status "n".
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 70]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   For example:
+
+      [C] LIST ACTIVE
+      [S] 215 list of newsgroups follows
+      [S] misc.test 3002322 3000234 y
+      [S] comp.risks 442001 441099 m
+      [S] alt.rfc-writers.recovery 4 1 y
+      [S] tx.natives.recovery 89 56 y
+      [S] tx.natives.recovery.d 11 9 n
+      [S] .
+
+   or, on an implementation that includes leading zeroes:
+
+      [C] LIST ACTIVE
+      [S] 215 list of newsgroups follows
+      [S] misc.test 0003002322 0003000234 y
+      [S] comp.risks 0000442001 0000441099 m
+      [S] alt.rfc-writers.recovery 0000000004 0000000001 y
+      [S] tx.natives.recovery 0000000089 0000000056 y
+      [S] tx.natives.recovery.d 0000000011 0000000009 n
+      [S] .
+
+   The information is newsgroup based, and a wildmat MAY be specified,
+   in which case the response is limited to only the groups (if any)
+   whose names match the wildmat.  For example:
+
+      [C] LIST ACTIVE *.recovery
+      [S] 215 list of newsgroups follows
+      [S] alt.rfc-writers.recovery 4 1 y
+      [S] tx.natives.recovery 89 56 y
+      [S] .
+
+7.6.4.  LIST ACTIVE.TIMES
+
+   This keyword is optional.
+
+   The active.times list is maintained by some NNTP servers to contain
+   information about who created a particular newsgroup and when.  Each
+   line of this list consists of three fields separated from each other
+   by one or more spaces.  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 plain text intended to describe the entity that created the
+   newsgroup; it is often a mailbox as defined in RFC 2822 [RFC2822].
+   For example:
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 71]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+      [C] LIST ACTIVE.TIMES
+      [S] 215 information follows
+      [S] misc.test 930445408 <creatme@isc.org>
+      [S] alt.rfc-writers.recovery 930562309 <m@example.com>
+      [S] tx.natives.recovery 930678923 <sob@academ.com>
+      [S] .
+
+   The list MAY omit newsgroups for which the information is unavailable
+   and MAY include groups not available on the server; in particular, it
+   MAY omit all groups created before the date and time of the oldest
+   entry.  The client MUST NOT assume that the list is complete or that
+   it matches the list returned by the LIST ACTIVE command
+   (Section 7.6.3).  The NEWGROUPS command (Section 7.3) may provide a
+   better way to access this information, and the results of the two
+   commands SHOULD be consistent except that, if the latter is invoked
+   with a date and time earlier than the oldest entry in active.times
+   list, its result may include extra groups.
+
+   The information is newsgroup based, and a wildmat MAY be specified,
+   in which case the response is limited to only the groups (if any)
+   whose names match the wildmat.
+
+7.6.5.  LIST DISTRIB.PATS
+
+   This keyword is optional.
+
+   The distrib.pats list is maintained by some NNTP servers to assist
+   clients to choose a value for the content of the Distribution header
+   of a news article being posted.  Each line of this list consists of
+   three fields separated from each other by a colon (":").  The first
+   field is a weight, the second field is a wildmat (which may be a
+   simple newsgroup name), and the third field is a value for the
+   Distribution header content.  For example:
+
+      [C] LIST DISTRIB.PATS
+      [S] 215 information follows
+      [S] 10:local.*:local
+      [S] 5:*:world
+      [S] 20:local.here.*:thissite
+      [S] .
+
+   The client MAY use this information to construct an appropriate
+   Distribution header given the name of a newsgroup.  To do so, it
+   should determine the lines whose second field matches the newsgroup
+   name, select from among them the line with the highest weight (with 0
+   being the lowest), and use the value of the third field to construct
+   the Distribution header.
+
+
+
+
+Feather                     Standards Track                    [Page 72]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   The information is not newsgroup based, and an argument MUST NOT be
+   specified.
+
+7.6.6.  LIST NEWSGROUPS
+
+   This keyword MUST be supported by servers advertising the READER
+   capability.
+
+   The newsgroups list is maintained by NNTP servers to contain the name
+   of each newsgroup that is available on the server and a short
+   description about the purpose of the group.  Each line of this list
+   consists of two fields separated from each other by one or more space
+   or TAB characters (the usual practice is a single TAB).  The first
+   field is the name of the newsgroup, and the second is a short
+   description of the group.  For example:
+
+      [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] .
+
+   The list MAY omit newsgroups for which the information is unavailable
+   and MAY include groups not available on the server.  The client MUST
+   NOT assume that the list is complete or that it matches the list
+   returned by LIST ACTIVE.
+
+   The description SHOULD be in UTF-8.  However, servers often obtain
+   the information from external sources.  These sources may have used
+   different encodings (ones that use octets in the range 128 to 255 in
+   some other manner) and, in that case, the server MAY pass it on
+   unchanged.  Therefore, clients MUST be prepared to receive such
+   descriptions.
+
+   The information is newsgroup based, and a wildmat MAY be specified,
+   in which case the response is limited to only the groups (if any)
+   whose names match the wildmat.
+
+8.  Article Field Access Commands
+
+   This section lists commands that may be used to access specific
+   article fields; that is, headers of articles and metadata about
+   articles.  These commands typically fetch data from an "overview
+   database", which is a database of headers extracted from incoming
+   articles plus metadata determined as the article arrives.  Only
+   certain fields are included in the database.
+
+
+
+
+Feather                     Standards Track                    [Page 73]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   This section is based on the Overview/NOV database [ROBE1995]
+   developed by Geoff Collyer.
+
+8.1.  Article Metadata
+
+   Article "metadata" is data about articles that does not occur within
+   the article itself.  Each metadata item has a name that MUST begin
+   with a colon (and that MUST NOT contain a colon elsewhere within it).
+   As with header names, metadata item names are not case sensitive.
+
+   When generating a metadata item, the server MUST compute it for
+   itself and MUST NOT trust any related value provided in the article.
+   (In particular, a Lines or Bytes header in the article MUST NOT be
+   assumed to specify the correct number of lines or bytes in the
+   article.)  If the server has access to several non-identical copies
+   of an article, the value returned MUST be correct for any copy of
+   that article retrieved during the same session.
+
+   This specification defines two metadata items: ":bytes" and ":lines".
+   Other metadata items may be defined by extensions.  The names of
+   metadata items defined by registered extensions MUST NOT begin with
+   ":x-".  To avoid the risk of a clash with a future registered
+   extension, the names of metadata items defined by private extensions
+   SHOULD begin with ":x-".
+
+8.1.1.  The :bytes Metadata Item
+
+   The :bytes metadata item for an article is a decimal integer.  It
+   SHOULD equal the number of octets in the entire article: headers,
+   body, and separating empty line (counting a CRLF pair as two octets,
+   and excluding both the "." CRLF terminating the response and any "."
+   added for "dot-stuffing" purposes).
+
+   Note to client implementers: some existing servers return a value
+   different from that above.  The commonest reasons for this are as
+   follows:
+
+   o  Counting a CRLF pair as one octet.
+
+   o  Including the "." character used for dot-stuffing in the number.
+
+   o  Including the terminating "." CRLF in the number.
+
+   o  Using one copy of an article for counting the octets but then
+      returning another one that differs in some (permitted) manner.
+
+   Implementations should be prepared for such variation and MUST NOT
+   rely on the value being accurate.
+
+
+
+Feather                     Standards Track                    [Page 74]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+8.1.2.  The :lines Metadata Item
+
+   The :lines metadata item for an article is a decimal integer.  It
+   MUST equal the number of lines in the article body (excluding the
+   empty line separating headers and body).  Equivalently, it is two
+   less than the number of CRLF pairs that the BODY command would return
+   for that article (the extra two are those following the response code
+   and the termination octet).
+
+8.2.  Database Consistency
+
+   The information stored in the overview database may change over time.
+   If the database records the content or absence of a given field (that
+   is, a header or metadata item) for all articles, it is said to be
+   "consistent" for that field.  If it records the content of a header
+   for some articles but not for others that nevertheless included that
+   header, or if it records a metadata item for some articles but not
+   for others to which that item applies, it is said to be
+   "inconsistent" for that field.
+
+   The LIST OVERVIEW.FMT command SHOULD list all the fields for which
+   the database is consistent at that moment.  It MAY omit such fields
+   (for example, if it is not known whether the database is consistent
+   or inconsistent).  It MUST NOT include fields for which the database
+   is inconsistent or that are not stored in the database.  Therefore,
+   if a header appears in the LIST OVERVIEW.FMT output but not in the
+   OVER output for a given article, that header does not appear in the
+   article (similarly for metadata items).
+
+   These rules assume that the fields being stored in the database
+   remain constant for long periods of time, and therefore the database
+   will be consistent.  When the set of fields to be stored is changed,
+   it will be inconsistent until either the database is rebuilt or the
+   only articles remaining are those received since the change.
+   Therefore, the output from LIST OVERVIEW.FMT needs to be altered
+   twice.  Firstly, before any fields stop being stored they MUST be
+   removed from the output; then, when the database is once more known
+   to be consistent, the new fields SHOULD be added to the output.
+
+   If the HDR command uses the overview database rather than taking
+   information directly from the articles, the same issues of
+   consistency and inconsistency apply, and the LIST HEADERS command
+   SHOULD take the same approach as the LIST OVERVIEW.FMT command in
+   resolving them.
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 75]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+8.3.  OVER
+
+8.3.1.  Usage
+
+   Indicating capability: OVER
+
+   Syntax
+     OVER message-id
+     OVER range
+     OVER
+
+   Responses
+
+   First form (message-id specified)
+     224    Overview information follows (multi-line)
+     430    No article with that message-id
+
+   Second form (range specified)
+     224    Overview information follows (multi-line)
+     412    No newsgroup selected
+     423    No articles in that range
+
+   Third form (current article number used)
+     224    Overview information follows (multi-line)
+     412    No newsgroup selected
+     420    Current article number is invalid
+
+   Parameters
+     range         Number(s) of articles
+     message-id    Message-id of article
+
+8.3.2.  Description
+
+   The OVER command returns the contents of all the fields in the
+   database for an article specified by message-id, or from a specified
+   article or range of articles in the currently selected newsgroup.
+
+   The message-id argument indicates a specific article.  The range
+   argument may be any of the following:
+
+   o  An article number.
+
+   o  An article number followed by a dash to indicate all following.
+
+   o  An article number followed by a dash followed by another article
+      number.
+
+   If neither is specified, the current article number is used.
+
+
+
+Feather                     Standards Track                    [Page 76]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Support for the first (message-id) form is optional.  If it is
+   supported, the OVER capability line MUST include the argument
+   "MSGID".  Otherwise, the capability line MUST NOT include this
+   argument, and the OVER command MUST return the generic response code
+   503 when this form is used.
+
+   If the information is available, it is returned as a multi-line data
+   block following the 224 response code and contains one line per
+   article, sorted in numerical order of article number.  (Note that
+   unless the argument is a range including a dash, there will be
+   exactly one line in the data block.)  Each line consists of a number
+   of fields separated by a TAB.  A field may be empty (in which case
+   there will be two adjacent TABs), and a sequence of trailing TABs may
+   be omitted.
+
+   The first 8 fields MUST be the following, in order:
+
+      "0" or article number (see below)
+      Subject header content
+      From header content
+      Date header content
+      Message-ID header content
+      References header content
+      :bytes metadata item
+      :lines metadata item
+
+   If the article is specified by message-id (the first form of the
+   command), the article number MUST be replaced with zero, except that
+   if there is a currently selected newsgroup and the article is present
+   in that group, the server MAY use the article's number in that group.
+   (See the ARTICLE command (Section 6.2.1) and STAT examples
+   (Section 6.2.4.3) for more details.)  In the other two forms of the
+   command, the article number MUST be returned.
+
+   Any subsequent fields are the contents of the other headers and
+   metadata held in the database.
+
+   For the five mandatory headers, the content of each field MUST be
+   based on the content of the header (that is, with the header name and
+   following colon and space removed).  If the article does not contain
+   that header, or if the content is empty, the field MUST be empty.
+   For the two mandatory metadata items, the content of the field MUST
+   be just the value, with no other text.
+
+   For all subsequent fields that contain headers, the content MUST be
+   the entire header line other than the trailing CRLF.  For all
+   subsequent fields that contain metadata, the field consists of the
+   metadata name, a single space, and then the value.
+
+
+
+Feather                     Standards Track                    [Page 77]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   For all fields, the value is processed by first removing all CRLF
+   pairs (that is, undoing any folding and removing the terminating
+   CRLF) and then replacing each TAB with a single space.  If there is
+   no such header in the article, no such metadata item, or no header or
+   item stored in the database for that article, the corresponding field
+   MUST be empty.
+
+   Note that, after unfolding, the characters NUL, LF, and CR cannot
+   occur in the header of an article offered by a conformant server.
+   Nevertheless, servers SHOULD check for these characters and replace
+   each one by a single space (so that, for example, CR LF LF TAB will
+   become two spaces, since the CR and first LF will be removed by the
+   unfolding process).  This will encourage robustness in the face of
+   non-conforming data; it is also possible that future versions of this
+   specification could permit these characters to appear in articles.
+
+   The server SHOULD NOT produce output for articles that no longer
+   exist.
+
+   If the argument is a message-id and no such article exists, a 430
+   response MUST be returned.  If the argument is a range or is omitted
+   and the currently selected newsgroup is invalid, a 412 response MUST
+   be returned.  If the argument is a range and no articles in that
+   number range exist in the currently selected newsgroup, including the
+   case where the second number is less than the first one, a 423
+   response MUST be returned.  If the argument is omitted and the
+   current article number is invalid, a 420 response MUST be returned.
+
+8.3.3.  Examples
+
+   In the first four examples, TAB has been replaced by vertical bar and
+   some lines have been folded for readability.
+
+   Example of a successful retrieval of overview information for an
+   article (explicitly not using an article number):
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] OVER
+      [S] 224 Overview information follows
+      [S] 3000234|I am just a test article|"Demo User"
+          <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
+          <45223423@example.com>|<45454@example.net>|1234|
+          17|Xref: news.example.com misc.test:3000363
+      [S] .
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 78]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of a successful retrieval of overview information for an
+   article by message-id:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] OVER MSGID
+      [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
+      [S] .
+      [C] OVER <45223423@example.com>
+      [S] 224 Overview information follows
+      [S] 0|I am just a test article|"Demo User"
+          <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
+          <45223423@example.com>|<45454@example.net>|1234|
+          17|Xref: news.example.com misc.test:3000363
+      [S] .
+
+   Note that the article number has been replaced by "0".
+
+   Example of the same commands on a system that does not implement
+   retrieval by message-id:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] OVER
+      [S] LIST ACTIVE NEWSGROUPS OVERVIEW.FMT
+      [S] .
+      [C] OVER <45223423@example.com>
+      [S] 503 Overview by message-id unsupported
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 79]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of a successful retrieval of overview information for a range
+   of articles:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] OVER 3000234-3000240
+      [S] 224 Overview information follows
+      [S] 3000234|I am just a test article|"Demo User"
+          <nobody@example.com>|6 Oct 1998 04:38:40 -0500|
+          <45223423@example.com>|<45454@example.net>|1234|
+          17|Xref: news.example.com misc.test:3000363
+      [S] 3000235|Another test article|nobody@nowhere.to
+          (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425@to.to>||
+          4818|37||Distribution: fi
+      [S] 3000238|Re: I am just a test article|somebody@elsewhere.to|
+          7 Oct 1998 11:38:40 +1200|<kfwer3v@elsewhere.to>|
+          <45223423@to.to>|9234|51
+      [S] .
+
+   Note the missing "References" and Xref headers in the second line,
+   the missing trailing fields in the first and last lines, and that
+   there are only results for those articles that still exist.
+
+   Example of an unsuccessful retrieval of overview information on an
+   article by number:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] OVER 300256
+      [S] 423 No such article in this group
+
+   Example of an invalid range:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] OVER 3000444-3000222
+      [S] 423 Empty range
+
+   Example of an unsuccessful retrieval of overview information by
+   number because no newsgroup was selected first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] OVER
+      [S] 412 No newsgroup selected
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 80]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an attempt to retrieve information when the currently
+   selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] OVER
+      [S] 420 No current article selected
+
+8.4.  LIST OVERVIEW.FMT
+
+8.4.1.  Usage
+
+   Indicating capability: OVER
+
+   Syntax
+     LIST OVERVIEW.FMT
+
+   Responses
+     215    Information follows (multi-line)
+
+8.4.2.  Description
+
+   See Section 7.6.1 for general requirements of the LIST command.
+
+   The LIST OVERVIEW.FMT command returns a description of the fields in
+   the database for which it is consistent (as described above).  The
+   information is returned as a multi-line data block following the 215
+   response code.  The information contains one line per field in the
+   order in which they are returned by the OVER command; the first 7
+   lines MUST (except for the case of letters) be exactly as follows:
+
+       Subject:
+       From:
+       Date:
+       Message-ID:
+       References:
+       :bytes
+       :lines
+
+   For compatibility with existing implementations, the last two lines
+   MAY instead be:
+
+       Bytes:
+       Lines:
+
+   even though they refer to metadata, not headers.
+
+
+
+
+
+Feather                     Standards Track                    [Page 81]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   All subsequent lines MUST consist of either a header name followed by
+   ":full", or the name of a piece of metadata.
+
+   There are no leading or trailing spaces in the output.
+
+   Note that the 7 fixed lines describe the 2nd to 8th fields of the
+   OVER output.  The "full" suffix (which may use either uppercase,
+   lowercase, or a mix) is a reminder that the corresponding fields
+   include the header name.
+
+   This command MAY generate different results if it is used more than
+   once in a session.
+
+   If the OVER command is not implemented, the meaning of the output
+   from this command is not specified, but it must still meet the above
+   syntactic requirements.
+
+8.4.3.  Examples
+
+   Example of LIST OVERVIEW.FMT output corresponding to the example OVER
+   output above, in the preferred format:
+
+      [C] LIST OVERVIEW.FMT
+      [S] 215 Order of fields in overview database.
+      [S] Subject:
+      [S] From:
+      [S] Date:
+      [S] Message-ID:
+      [S] References:
+      [S] :bytes
+      [S] :lines
+      [S] Xref:full
+      [S] Distribution:full
+      [S] .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 82]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of LIST OVERVIEW.FMT output corresponding to the example OVER
+   output above, in the alternative format:
+
+      [C] LIST OVERVIEW.FMT
+      [S] 215 Order of fields in overview database.
+      [S] Subject:
+      [S] From:
+      [S] Date:
+      [S] Message-ID:
+      [S] References:
+      [S] Bytes:
+      [S] Lines:
+      [S] Xref:FULL
+      [S] Distribution:FULL
+      [S] .
+
+8.5.  HDR
+
+8.5.1.  Usage
+
+   Indicating capability: HDR
+
+   Syntax
+     HDR field message-id
+     HDR field range
+     HDR field
+
+   Responses
+
+   First form (message-id specified)
+     225    Headers follow (multi-line)
+     430    No article with that message-id
+
+   Second form (range specified)
+     225    Headers follow (multi-line)
+     412    No newsgroup selected
+     423    No articles in that range
+
+   Third form (current article number used)
+     225    Headers follow (multi-line)
+     412    No newsgroup selected
+     420    Current article number is invalid
+
+   Parameters
+     field         Name of field
+     range         Number(s) of articles
+     message-id    Message-id of article
+
+
+
+
+Feather                     Standards Track                    [Page 83]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+8.5.2.  Description
+
+   The HDR command provides access to specific fields from an article
+   specified by message-id, or from a specified article or range of
+   articles in the currently selected newsgroup.  It MAY take the
+   information directly from the articles or from the overview database.
+   In the case of headers, an implementation MAY restrict the use of
+   this command to a specific list of headers or MAY allow it to be used
+   with any header; it may behave differently when it is used with a
+   message-id argument and when it is used with a range or no argument.
+
+   The required field argument is the name of a header with the colon
+   omitted (e.g., "subject") or the name of a metadata item including
+   the leading colon (e.g., ":bytes"), and is case insensitive.
+
+   The message-id argument indicates a specific article.  The range
+   argument may be any of the following:
+
+   o  An article number.
+
+   o  An article number followed by a dash to indicate all following.
+
+   o  An article number followed by a dash followed by another article
+      number.
+
+   If neither is specified, the current article number is used.
+
+   If the information is available, it is returned as a multi-line data
+   block following the 225 response code and contains one line for each
+   article in the range that exists.  (Note that unless the argument is
+   a range including a dash, there will be exactly one line in the data
+   block.)  The line consists of the article number, a space, and then
+   the contents of the field.  In the case of a header, the header name,
+   the colon, and the first space after the colon are all omitted.
+
+   If the article is specified by message-id (the first form of the
+   command), the article number MUST be replaced with zero, except that
+   if there is a currently selected newsgroup and the article is present
+   in that group, the server MAY use the article's number in that group.
+   (See the ARTICLE command (Section 6.2.1) and STAT examples
+   (Section 6.2.4.3) for more details.)  In the other two forms of the
+   command, the article number MUST be returned.
+
+   Header contents are modified as follows: all CRLF pairs are removed,
+   and then each TAB is replaced with a single space.  (Note that this
+   is the same transformation as is performed by the OVER command
+   (Section 8.3.2), and the same comment concerning NUL, CR, and LF
+   applies.)
+
+
+
+Feather                     Standards Track                    [Page 84]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Note the distinction between headers and metadata appearing to have
+   the same meaning.  Headers are always taken unchanged from the
+   article; metadata are always calculated.  For example, a request for
+   "Lines" returns the contents of the "Lines" header of the specified
+   articles, if any, no matter whether they accurately state the number
+   of lines, while a request for ":lines" returns the line count
+   metadata, which is always the actual number of lines irrespective of
+   what any header may state.
+
+   If the requested header is not present in the article, or if it is
+   present but empty, a line for that article is included in the output,
+   but the header content portion of the line is empty (the space after
+   the article number MAY be retained or omitted).  If the header occurs
+   in a given article more than once, only the content of the first
+   occurrence is returned by HDR.  If any article number in the provided
+   range does not exist in the group, no line for that article number is
+   included in the output.
+
+   If the second argument is a message-id and no such article exists, a
+   430 response MUST be returned.  If the second argument is a range or
+   is omitted and the currently selected newsgroup is invalid, a 412
+   response MUST be returned.  If the second argument is a range and no
+   articles in that number range exist in the currently selected
+   newsgroup, including the case where the second number is less than
+   the first one, a 423 response MUST be returned.  If the second
+   argument is omitted and the current article number is invalid, a 420
+   response MUST be returned.
+
+   A server MAY only allow HDR commands for a limited set of fields; it
+   may behave differently in this respect for the first (message-id)
+   form from how it would for the other forms.  If so, it MUST respond
+   with the generic 503 response to attempts to request other fields,
+   rather than return erroneous results, such as a successful empty
+   response.
+
+   If HDR uses the overview database and it is inconsistent for the
+   requested field, the server MAY return what results it can, or it MAY
+   respond with the generic 503 response.  In the latter case, the field
+   MUST NOT appear in the output from LIST HEADERS.
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 85]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+8.5.3.  Examples
+
+   Example of a successful retrieval of subject lines from a range of
+   articles (3000235 has no Subject header, and 3000236 is missing):
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HDR Subject 3000234-3000238
+      [S] 225 Headers follow
+      [S] 3000234 I am just a test article
+      [S] 3000235
+      [S] 3000237 Re: I am just a test article
+      [S] 3000238 Ditto
+      [S] .
+
+   Example of a successful retrieval of line counts from a range of
+   articles:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HDR :lines 3000234-3000238
+      [S] 225 Headers follow
+      [S] 3000234 42
+      [S] 3000235 5
+      [S] 3000237 11
+      [S] 3000238 2378
+      [S] .
+
+   Example of a successful retrieval of the subject line from an article
+   by message-id:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HDR subject <i.am.a.test.article@example.com>
+      [S] 225 Header information follows
+      [S] 0 I am just a test article
+      [S] .
+
+   Example of a successful retrieval of the subject line from the
+   current article:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HDR subject
+      [S] 225 Header information follows
+      [S] 3000234 I am just a test article
+      [S] .
+
+
+
+
+Feather                     Standards Track                    [Page 86]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an unsuccessful retrieval of a header from an article by
+   message-id:
+
+      [C] HDR subject <i.am.not.there@example.com>
+      [S] 430 No Such Article Found
+
+   Example of an unsuccessful retrieval of headers from articles by
+   number because no newsgroup was selected first:
+
+      [Assumes currently selected newsgroup is invalid.]
+      [C] HDR subject 300256-
+      [S] 412 No newsgroup selected
+
+   Example of an unsuccessful retrieval of headers because the currently
+   selected newsgroup is empty:
+
+      [C] GROUP example.empty.newsgroup
+      [S] 211 0 0 0 example.empty.newsgroup
+      [C] HDR subject 1-
+      [S] 423 No articles in that range
+
+   Example of an unsuccessful retrieval of headers because the server
+   does not allow HDR commands for that header:
+
+      [C] GROUP misc.test
+      [S] 211 1234 3000234 3002322 misc.test
+      [C] HDR Content-Type 3000234-3000238
+      [S] 503 HDR not permitted on Content-Type
+
+8.6.  LIST HEADERS
+
+8.6.1.  Usage
+
+   Indicating capability: HDR
+
+   Syntax
+     LIST HEADERS [MSGID|RANGE]
+
+   Responses
+     215    Field list follows (multi-line)
+
+   Parameters
+     MSGID    Requests list for access by message-id
+     RANGE    Requests list for access by range
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 87]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+8.6.2.  Description
+
+   See Section 7.6.1 for general requirements of the LIST command.
+
+   The LIST HEADERS command returns a list of fields that may be
+   retrieved using the HDR command.
+
+   The information is returned as a multi-line data block following the
+   215 response code and contains one line for each field name
+   (excluding the trailing colon for headers and including the leading
+   colon for metadata items).  If the implementation allows any header
+   to be retrieved, it MUST NOT include any header names in the list but
+   MUST include the special entry ":" (a single colon on its own).  It
+   MUST still explicitly list any metadata items that are available.
+   The order of items in the list is not significant; the server need
+   not even consistently return the same order.  The list MAY be empty
+   (though in this circumstance there is little point in providing the
+   HDR command).
+
+   An implementation that also supports the OVER command SHOULD at least
+   permit all the headers and metadata items listed in the output from
+   the LIST OVERVIEW.FMT command.
+
+   If the server treats the first form of the HDR command (message-id
+   specified) differently from the other two forms (range specified or
+   current article number used) in respect of which headers or metadata
+   items are available, then the following apply:
+
+   o  If the MSGID argument is specified, the results MUST be those
+      available for the first form of the HDR command.
+
+   o  If the RANGE argument is specified, the results MUST be those
+      available for the second and third forms of the HDR command.
+
+   o  If no argument is specified, the results MUST be those available
+      in all forms of the HDR command (that is, it MUST only list those
+      items listed in both the previous cases).
+
+   If the server does not treat the various forms differently, then it
+   MUST ignore any argument and always produce the same results (though
+   not necessarily always in the same order).
+
+   If the HDR command is not implemented, the meaning of the output from
+   this command is not specified, but it must still meet the above
+   syntactic requirements.
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 88]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+8.6.3.  Examples
+
+   Example of an implementation providing access to only a few headers:
+
+      [C] LIST HEADERS
+      [S] 215 headers supported:
+      [S] Subject
+      [S] Message-ID
+      [S] Xref
+      [S] .
+
+   Example of an implementation providing access to the same fields as
+   the first example in Section 8.4.3:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] OVER
+      [S] HDR
+      [S] LIST ACTIVE NEWSGROUPS HEADERS OVERVIEW.FMT
+      [S] .
+      [C] LIST HEADERS
+      [S] 215 headers and metadata items supported:
+      [S] Date
+      [S] Distribution
+      [S] From
+      [S] Message-ID
+      [S] References
+      [S] Subject
+      [S] Xref
+      [S] :bytes
+      [S] :lines
+      [S] .
+
+   Example of an implementation providing access to all headers:
+
+      [C] LIST HEADERS
+      [S] 215 metadata items supported:
+      [S] :
+      [S] :lines
+      [S] :bytes
+      [S] :x-article-number
+      [S] .
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 89]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Example of an implementation distinguishing the first form of the HDR
+   command from the other two forms:
+
+      [C] LIST HEADERS RANGE
+      [S] 215 metadata items supported:
+      [S] :
+      [S] :lines
+      [S] :bytes
+      [S] .
+      [C] LIST HEADERS MSGID
+      [S] 215 headers and metadata items supported:
+      [S] Date
+      [S] Distribution
+      [S] From
+      [S] Message-ID
+      [S] References
+      [S] Subject
+      [S] :lines
+      [S] :bytes
+      [S] :x-article-number
+      [S] .
+      [C] LIST HEADERS
+      [S] 215 headers and metadata items supported:
+      [S] Date
+      [S] Distribution
+      [S] From
+      [S] Message-ID
+      [S] References
+      [S] Subject
+      [S] :lines
+      [S] :bytes
+      [S] .
+
+   Note that :x-article-number does not appear in the last set of
+   output.
+
+9.  Augmented BNF Syntax for NNTP
+
+9.1.  Introduction
+
+   Each of the following sections describes the syntax of a major
+   element of NNTP.  This syntax extends and refines the descriptions
+   elsewhere in this specification and should be given precedence when
+   resolving apparent conflicts.  Note that ABNF [RFC4234] strings are
+   case insensitive.  Non-terminals used in several places are defined
+   in a separate section at the end.
+
+
+
+
+
+Feather                     Standards Track                    [Page 90]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Between them, the non-terminals <command-line>, <command-datastream>,
+   <command-continuation>, and <response> specify the text that flows
+   between client and server.  A consistent naming scheme is used in
+   this document for the non-terminals relating to each command, and
+   SHOULD be used by the specification of registered extensions.
+
+   For each command, the sequence is as follows:
+
+   o  The client sends an instance of <command-line>; the syntax for the
+      EXAMPLE command is <example-command>.
+
+   o  If the client is one that immediately streams data, it sends an
+      instance of <command-datastream>; the syntax for the EXAMPLE
+      command is <example-datastream>.
+
+   o  The server sends an instance of <response>.
+
+      *  The initial response line is independent of the command that
+         generated it; if the 000 response has arguments, the syntax of
+         the initial line is <response-000-content>.
+
+      *  If the response is multi-line, the initial line is followed by
+         a <multi-line-data-block>.  The syntax for the contents of this
+         block after "dot-stuffing" has been removed is (for the 000
+         response to the EXAMPLE command) <example-000-ml-content> and
+         is an instance of <multi-line-response-content>.
+
+   o  While the latest response is one that indicates more data is
+      required (in general, a 3xx response):
+
+      *  the client sends an instance of <command-continuation>; the
+         syntax for the EXAMPLE continuation following a 333 response is
+         <example-333-continuation>;
+
+      *  the server sends another instance of <response>, as above.
+
+   (There are no commands in this specification that immediately stream
+   data, but this non-terminal is defined for the convenience of
+   extensions.)
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                    [Page 91]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+9.2.  Commands
+
+   This syntax defines the non-terminal <command-line>, which represents
+   what is sent from the client to the server (see section 3.1 for
+   limits on lengths).
+
+     command-line = command EOL
+     command = X-command
+     X-command = keyword *(WS token)
+
+     command =/ article-command /
+           body-command /
+           capabilities-command /
+           date-command /
+           group-command /
+           hdr-command /
+           head-command /
+           help-command /
+           ihave-command /
+           last-command /
+           list-command /
+           listgroup-command /
+           mode-reader-command /
+           newgroups-command /
+           newnews-command /
+           next-command /
+           over-command /
+           post-command /
+           quit-command /
+           stat-command
+
+     article-command = "ARTICLE" [WS article-ref]
+     body-command = "BODY" [WS article-ref]
+     capabilities-command = "CAPABILITIES" [WS keyword]
+     date-command = "DATE"
+     group-command = "GROUP" [WS newsgroup-name]
+     hdr-command = "HDR" WS header-meta-name [WS range-ref]
+     head-command = "HEAD" [WS article-ref]
+     help-command = "HELP"
+     ihave-command = "IHAVE" WS message-id
+     last-command = "LAST"
+     list-command = "LIST" [WS list-arguments]
+     listgroup-command = "LISTGROUP" [WS newsgroup-name [WS range]]
+     mode-reader-command = "MODE" WS "READER"
+     newgroups-command = "NEWGROUPS" WS date-time
+     newnews-command = "NEWNEWS" WS wildmat WS date-time
+     next-command = "NEXT"
+     over-command = "OVER" [WS range-ref]
+
+
+
+Feather                     Standards Track                    [Page 92]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+     post-command = "POST"
+     quit-command = "QUIT"
+     stat-command = "STAT" [WS article-ref]
+
+     article-ref = article-number / message-id
+     date = date2y / date4y
+     date4y = 4DIGIT 2DIGIT 2DIGIT
+     date2y = 2DIGIT 2DIGIT 2DIGIT
+     date-time = date WS time [WS "GMT"]
+     header-meta-name = header-name / metadata-name
+     list-arguments = keyword [WS token]
+     metadata-name = ":" 1*A-NOTCOLON
+     range = article-number ["-" [article-number]]
+     range-ref = range / message-id
+     time = 2DIGIT 2DIGIT 2DIGIT
+
+9.3.  Command Continuation
+
+   This syntax defines the further material sent by the client in the
+   case of multi-stage commands and those that stream data.
+
+     command-datastream = UNDEFINED
+       ; not used, provided as a hook for extensions
+     command-continuation = ihave-335-continuation /
+           post-340-continuation
+
+     ihave-335-continuation = encoded-article
+     post-340-continuation = encoded-article
+
+     encoded-article = multi-line-data-block
+       ; after undoing the "dot-stuffing", this MUST match <article>
+
+9.4.  Responses
+
+9.4.1.  Generic Responses
+
+   This syntax defines the non-terminal <response>, which represents the
+   generic form of responses; that is, what is sent from the server to
+   the client in response to a <command> or a <command-continuation>.
+
+     response = simple-response / multi-line-response
+     simple-response = initial-response-line
+     multi-line-response = initial-response-line multi-line-data-block
+
+     initial-response-line =
+           initial-response-content [SP trailing-comment] CRLF
+     initial-response-content = X-initial-response-content
+     X-initial-response-content = 3DIGIT *(SP response-argument)
+
+
+
+Feather                     Standards Track                    [Page 93]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+     response-argument = 1*A-CHAR
+     trailing-comment = *U-CHAR
+
+9.4.2.  Initial Response Line Contents
+
+   This syntax defines the specific initial response lines for the
+   various commands in this specification (see section 3.1 for limits on
+   lengths).  Only those response codes with arguments are listed.
+
+     initial-response-content =/ response-111-content /
+           response-211-content /
+           response-220-content /
+           response-221-content /
+           response-222-content /
+           response-223-content /
+           response-401-content
+
+     response-111-content = "111" SP date4y time
+     response-211-content = "211" 3(SP article-number) SP newsgroup-name
+     response-220-content = "220" SP article-number SP message-id
+     response-221-content = "221" SP article-number SP message-id
+     response-222-content = "222" SP article-number SP message-id
+     response-223-content = "223" SP article-number SP message-id
+     response-401-content = "401" SP capability-label
+
+9.4.3.  Multi-line Response Contents
+
+   This syntax defines the content of the various multi-line responses;
+   more precisely, it defines the part of the response in the multi-line
+   data block after any "dot-stuffing" has been undone.  The numeric
+   portion of each non-terminal name indicates the response code that is
+   followed by this data.
+
+     multi-line-response-content = article-220-ml-content /
+           body-222-ml-content /
+           capabilities-101-ml-content /
+           hdr-225-ml-content /
+           head-221-ml-content /
+           help-100-ml-content /
+           list-215-ml-content /
+           listgroup-211-ml-content /
+           newgroups-231-ml-content /
+           newnews-230-ml-content /
+           over-224-ml-content
+
+     article-220-ml-content = article
+     body-222-ml-content = body
+     capabilities-101-ml-content = version-line CRLF
+
+
+
+Feather                     Standards Track                    [Page 94]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+           *(capability-line CRLF)
+     hdr-225-ml-content = *(article-number SP hdr-content CRLF)
+     head-221-ml-content = 1*header
+     help-100-ml-content = *(*U-CHAR CRLF)
+     list-215-ml-content = list-content
+     listgroup-211-ml-content = *(article-number CRLF)
+     newgroups-231-ml-content = active-groups-list
+     newnews-230-ml-content = *(message-id CRLF)
+     over-224-ml-content = *(article-number over-content CRLF)
+
+     active-groups-list = *(newsgroup-name SPA article-number
+           SPA article-number SPA newsgroup-status CRLF)
+     hdr-content = *S-NONTAB
+     hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content]
+     list-content = body
+     newsgroup-status = %x79 / %x6E / %x6D / private-status
+     over-content = 1*6(TAB hdr-content) /
+           7(TAB hdr-content) *(TAB hdr-n-content)
+     private-status = token ; except the values in newsgroup-status
+
+9.5.  Capability Lines
+
+   This syntax defines the generic form of a capability line in the
+   capabilities list (see Section 3.3.1).
+
+     capability-line = capability-entry
+     capability-entry = X-capability-entry
+     X-capability-entry = capability-label *(WS capability-argument)
+     capability-label = keyword
+     capability-argument = token
+
+   This syntax defines the specific capability entries for the
+   capabilities in this specification.
+
+     capability-entry =/
+           hdr-capability /
+           ihave-capability /
+           implementation-capability /
+           list-capability /
+           mode-reader-capability /
+           newnews-capability /
+           over-capability /
+           post-capability /
+           reader-capability
+
+     hdr-capability = "HDR"
+     ihave-capability = "IHAVE"
+     implementation-capability = "IMPLEMENTATION" *(WS token)
+
+
+
+Feather                     Standards Track                    [Page 95]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+     list-capability = "LIST" 1*(WS keyword)
+     mode-reader-capability = "MODE-READER"
+     newnews-capability = "NEWNEWS"
+     over-capability = "OVER" [WS "MSGID"]
+     post-capability = "POST"
+     reader-capability = "READER"
+
+     version-line = "VERSION" 1*(WS version-number)
+     version-number = nzDIGIT *5DIGIT
+
+9.6.  LIST Variants
+
+   This section defines more specifically the keywords for the LIST
+   command and the syntax of the corresponding response contents.
+
+     ; active
+     list-arguments =/ "ACTIVE" [WS wildmat]
+     list-content =/ list-active-content
+     list-active-content = active-groups-list
+
+
+     ; active.times
+     list-arguments =/ "ACTIVE.TIMES" [WS wildmat]
+     list-content =/ list-active-times-content
+     list-active-times-content =
+           *(newsgroup-name SPA 1*DIGIT SPA newsgroup-creator CRLF)
+     newsgroup-creator = U-TEXT
+
+
+     ; distrib.pats
+     list-arguments =/ "DISTRIB.PATS"
+     list-content =/ list-distrib-pats-content
+     list-distrib-pats-content =
+           *(1*DIGIT ":" wildmat ":" distribution CRLF)
+     distribution = token
+
+
+     ; headers
+     list-arguments =/ "HEADERS" [WS ("MSGID" / "RANGE")]
+     list-content =/ list-headers-content
+     list-headers-content = *(header-meta-name CRLF) /
+           *((metadata-name / ":") CRLF)
+
+
+     ; newsgroups
+     list-arguments =/ "NEWSGROUPS" [WS wildmat]
+     list-content =/ list-newsgroups-content
+     list-newsgroups-content =
+
+
+
+Feather                     Standards Track                    [Page 96]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+           *(newsgroup-name WS newsgroup-description CRLF)
+     newsgroup-description = S-TEXT
+
+
+     ; overview.fmt
+     list-arguments =/ "OVERVIEW.FMT"
+     list-content =/ list-overview-fmt-content
+     list-overview-fmt-content = "Subject:" CRLF
+           "From:" CRLF
+           "Date:" CRLF
+           "Message-ID:" CRLF
+           "References:" CRLF
+           ( ":bytes" CRLF ":lines" / "Bytes:" CRLF "Lines:") CRLF
+           *((header-name ":full" / metadata-name) CRLF)
+
+9.7.  Articles
+
+   This syntax defines the non-terminal <article>, which represents the
+   format of an article as described in Section 3.6.
+
+     article = 1*header CRLF body
+     header = header-name ":" [CRLF] SP header-content CRLF
+     header-content = *(S-CHAR / [CRLF] WS)
+     body = *(*B-CHAR CRLF)
+
+9.8.  General Non-terminals
+
+   These non-terminals are used at various places in the syntax and are
+   collected here for convenience.  A few of these non-terminals are not
+   used in this specification but are provided for the consistency and
+   convenience of extension authors.
+
+     multi-line-data-block = content-lines termination
+     content-lines = *([content-text] CRLF)
+     content-text = (".." / B-NONDOT) *B-CHAR
+     termination = "." CRLF
+
+     article-number = 1*16DIGIT
+     header-name = 1*A-NOTCOLON
+     keyword = ALPHA 2*(ALPHA / DIGIT / "." / "-")
+     message-id = "<" 1*248A-NOTGT ">"
+     newsgroup-name = 1*wildmat-exact
+     token = 1*P-CHAR
+
+     wildmat = wildmat-pattern *("," ["!"] wildmat-pattern)
+     wildmat-pattern = 1*wildmat-item
+     wildmat-item = wildmat-exact / wildmat-wild
+     wildmat-exact = %x22-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E /
+
+
+
+Feather                     Standards Track                    [Page 97]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+          UTF8-non-ascii  ; exclude ! * , ? [ \ ]
+     wildmat-wild = "*" / "?"
+
+     base64 = *(4base64-char) [base64-terminal]
+     base64-char = UPPER / LOWER / DIGIT / "+" / "/"
+     base64-terminal = 2base64-char "==" / 3base64-char "="
+
+     ; Assorted special character sets
+     ;   A- means based on US-ASCII, excluding controls and SP
+     ;   P- means based on UTF-8, excluding controls and SP
+     ;   U- means based on UTF-8, excluding NUL CR and LF
+     ;   B- means based on bytes, excluding NUL CR and LF
+     A-CHAR     = %x21-7E
+     A-NOTCOLON = %x21-39 / %x3B-7E  ; exclude ":"
+     A-NOTGT    = %x21-3D / %x3F-7E  ; exclude ">"
+     P-CHAR     = A-CHAR / UTF8-non-ascii
+     U-CHAR     = CTRL / TAB / SP / A-CHAR / UTF8-non-ascii
+     U-NONTAB   = CTRL /       SP / A-CHAR / UTF8-non-ascii
+     U-TEXT     = P-CHAR *U-CHAR
+     B-CHAR     = CTRL / TAB / SP / %x21-FF
+     B-NONDOT   = CTRL / TAB / SP / %x21-2D / %x2F-FF  ; exclude "."
+
+     ALPHA = UPPER / LOWER   ; use only when case-insensitive
+     CR = %x0D
+     CRLF = CR LF
+     CTRL = %x01-08 / %x0B-0C / %x0E-1F
+     DIGIT = %x30-39
+     nzDIGIT = %x31-39
+     EOL = *(SP / TAB) CRLF
+     LF = %x0A
+     LOWER = %x61-7A
+     SP = %x20
+     SPA = 1*SP
+     TAB = %x09
+     UPPER = %x41-5A
+     UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
+     UTF8-2    = %xC2-DF UTF8-tail
+     UTF8-3    = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail /
+                 %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail
+     UTF8-4    = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail /
+                 %xF4 %x80-8F 2UTF8-tail
+     UTF8-tail = %x80-BF
+     WS = 1*(SP / TAB)
+
+   The following non-terminals require special consideration.  They
+   represent situations where material SHOULD be restricted to UTF-8,
+   but implementations MUST be able to cope with other character
+   encodings.  Therefore, there are two sets of definitions for them.
+
+
+
+Feather                     Standards Track                    [Page 98]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Implementations MUST accept any content that meets this syntax:
+
+     S-CHAR   = %x21-FF
+     S-NONTAB = CTRL / SP / S-CHAR
+     S-TEXT   = (CTRL / S-CHAR) *B-CHAR
+
+   and MAY pass such content on unaltered.
+
+   When generating new content or re-encoding existing content,
+   implementations SHOULD conform to this syntax:
+
+     S-CHAR   = P-CHAR
+     S-NONTAB = U-NONTAB
+     S-TEXT   = U-TEXT
+
+9.9.  Extensions and Validation
+
+   The specification of a registered extension MUST include formal
+   syntax that defines additional forms for the following non-terminals:
+
+   command
+      for each new command other than a variant of the LIST command -
+      the syntax of each command MUST be compatible with the definition
+      of <X-command>;
+
+   command-datastream
+      for each new command that immediately streams data;
+
+   command-continuation
+      for each new command that sends further material after the initial
+      command line - the syntax of each continuation MUST be exactly
+      what is sent to the server, including any escape mechanisms such
+      as "dot-stuffing";
+
+   initial-response-content
+      for each new response code that has arguments - the syntax of each
+      response MUST be compatible with the definition of <X-initial-
+      response-content>;
+
+   multi-line-response-content
+      for each new response code that has a multi-line response - the
+      syntax MUST show the response after the lines containing the
+      response code and the terminating octet have been removed and any
+      "dot-stuffing" undone;
+
+   capability-entry
+      for each new capability label - the syntax of each entry MUST be
+      compatible with the definition of <X-capability-entry>;
+
+
+
+Feather                     Standards Track                    [Page 99]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   list-arguments
+      for each new variant of the LIST command - the syntax of each
+      entry MUST be compatible with the definition of <X-command>;
+
+   list-content
+      for each new variant of the LIST command - the syntax MUST show
+      the response after the lines containing the 215 response code and
+      the terminating octet have been removed and any "dot-stuffing"
+      undone.
+
+   The =/ notation of ABNF [RFC4234] and the naming conventions
+   described in Section 9.1 SHOULD be used for this.
+
+   When the syntax in this specification, or syntax based on it, is
+   validated, it should be noted that:
+
+   o  the non-terminals <command-line>, <command-datastream>,
+      <command-continuation>, <response>, and
+      <multi-line-response-content> describe basic concepts of the
+      protocol and are not referred to by any other rule;
+
+   o  the non-terminal <base64> is provided for the convenience of
+      extension authors and is not referred to by any rule in this
+      specification;
+
+   o  for the reasons given above, the non-terminals <S-CHAR>,
+      <S-NONTAB>, and <S-TEXT> each have two definitions; and
+
+   o  the non-terminal <UNDEFINED> is deliberately not defined.
+
+10.  Internationalisation Considerations
+
+10.1.  Introduction and Historical Situation
+
+   RFC 977 [RFC977] was written at a time when internationalisation was
+   not seen as a significant issue.  As such, it was written on the
+   assumption that all communication would be in ASCII and use only a
+   7-bit transport layer, although in practice just about all known
+   implementations are 8-bit clean.
+
+   Since then, Usenet and NNTP have spread throughout the world.  In the
+   absence of standards for handling the issues of language and
+   character sets, countries, newsgroup hierarchies, and individuals
+   have found a variety of solutions that work for them but that are not
+   necessarily appropriate elsewhere.  For example, some have adopted a
+   default 8-bit character set appropriate to their needs (such as
+   ISO/IEC 8859-1 in Western Europe or KOI-8 in Russia), others have
+   used ASCII (either US-ASCII or national variants) in headers but
+
+
+
+Feather                     Standards Track                   [Page 100]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   local 16-bit character sets in article bodies, and still others have
+   gone for a combination of MIME [RFC2045] and UTF-8.  With the
+   increased use of MIME in email, it is becoming more common to find
+   NNTP articles containing MIME headers that identify the character set
+   of the body, but this is far from universal.
+
+   The resulting confusion does not help interoperability.
+
+   One point that has been generally accepted is that articles can
+   contain octets with the top bit set, and NNTP is only expected to
+   operate on 8-bit clean transport paths.
+
+10.2.  This Specification
+
+   Part of the role of this present specification is to eliminate this
+   confusion and promote interoperability as far as possible.  At the
+   same time, it is necessary to accept the existence of the present
+   situation and not break existing implementations and arrangements
+   gratuitously, even if they are less than optimal.  Therefore, the
+   current practice described above has been taken into consideration in
+   producing this specification.
+
+   This specification extends NNTP from US-ASCII [ANSI1986] to UTF-8
+   [RFC3629].  Except in the two areas discussed below, UTF-8 (which is
+   a superset of US-ASCII) is mandatory, and implementations MUST NOT
+   use any other encoding.
+
+   Firstly, the use of MIME for article headers and bodies is strongly
+   recommended.  However, given widely divergent existing practices, an
+   attempt to require a particular encoding and tagging standard would
+   be premature at this time.  Accordingly, this specification allows
+   the use of arbitrary 8-bit data in articles subject to the following
+   requirements and recommendations.
+
+   o  The names of headers (e.g., "From" or "Subject") MUST be in
+      US-ASCII.
+
+   o  Header values SHOULD use US-ASCII or an encoding based on it, such
+      as RFC 2047 [RFC2047], until such time as another approach has
+      been standardised.  At present, 8-bit encodings (including UTF-8)
+      SHOULD NOT be used because they are likely to cause
+      interoperability problems.
+
+   o  The character set of article bodies SHOULD be indicated in the
+      article headers, and this SHOULD be done in accordance with MIME.
+
+   o  Where an article is obtained from an external source, an
+      implementation MAY pass it on and derive data from it (such as the
+
+
+
+Feather                     Standards Track                   [Page 101]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+      response to the HDR command), even though the article or the data
+      does not meet the above requirements.  Implementations MUST
+      transfer such articles and data correctly and unchanged; they MUST
+      NOT attempt to convert or re-encode the article or derived data.
+      (Nevertheless, a client or server MAY elect not to post or forward
+      the article if, after further examination of the article, it deems
+      it inappropriate to do so.)
+
+   This requirement affects the ARTICLE (Section 6.2.1), BODY
+   (Section 6.2.3), HDR (Section 8.5), HEAD (Section 6.2.2), IHAVE
+   (Section 6.3.2), OVER (Section 8.3), and POST (Section 6.3.1)
+   commands.
+
+   Secondly, the following requirements are placed on the newsgroups
+   list returned by the LIST NEWSGROUPS command (Section 7.6.6):
+
+   o  Although this specification allows UTF-8 for newsgroup names, they
+      SHOULD be restricted to US-ASCII until a successor to RFC 1036
+      [RFC1036] standardises another approach. 8-bit encodings SHOULD
+      NOT be used because they are likely to cause interoperability
+      problems.
+
+   o  The newsgroup description SHOULD be in US-ASCII or UTF-8 unless
+      and until a successor to RFC 1036 standardises other encoding
+      arrangements.  8-bit encodings other than UTF-8 SHOULD NOT be used
+      because they are likely to cause interoperability problems.
+
+   o  Implementations that obtain this data from an external source MUST
+      handle it correctly even if it does not meet the above
+      requirements.  Implementations (in particular, clients) MUST
+      handle such data correctly.
+
+10.3.  Outstanding Issues
+
+   While the primary use of NNTP is for transmitting articles that
+   conform to RFC 1036 (Netnews articles), it is also used for other
+   formats (see Appendix A).  It is therefore most appropriate that
+   internationalisation issues related to article formats be addressed
+   in the relevant specifications.  For Netnews articles, this is any
+   successor to RFC 1036.  For email messages, it is RFC 2822 [RFC2822].
+
+   Of course, any article transmitted via NNTP needs to conform to this
+   specification as well.
+
+   Restricting newsgroup names to UTF-8 is not a complete solution.  In
+   particular, when new newsgroup names are created or a user is asked
+   to enter a newsgroup name, some scheme of canonicalisation will need
+   to take place.  This specification does not attempt to define that
+
+
+
+Feather                     Standards Track                   [Page 102]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   canonicalization; further work is needed in this area, in conjunction
+   with the article format specifications.  Until such specifications
+   are published, implementations SHOULD match newsgroup names octet by
+   octet.  It is anticipated that any approved scheme will be applied
+   "at the edges", and therefore octet-by-octet comparison will continue
+   to apply to most, if not all, uses of newsgroup names in NNTP.
+
+   In the meantime, any implementation experimenting with UTF-8
+   newsgroup names is strongly cautioned that a future specification may
+   require that those names be canonicalized when used with NNTP in a
+   way that is not compatible with their experiments.
+
+   Since the primary use of NNTP is with Netnews, and since newsgroup
+   descriptions are normally distributed through specially formatted
+   articles, it is recommended that the internationalisation issues
+   related to them be addressed in any successor to RFC 1036.
+
+11.  IANA Considerations
+
+   This specification requires IANA to keep a registry of capability
+   labels.  The initial contents of this registry are specified in
+   Section 3.3.4.  As described in Section 3.3.3, labels beginning with
+   X are reserved for private use, while all other names are expected to
+   be associated with a specification in an RFC on the standards track
+   or defining an IESG-approved experimental protocol.
+
+   Different entries in the registry MUST use different capability
+   labels.
+
+   Different entries in the registry MUST NOT use the same command name.
+   For this purpose, variants distinguished by a second or subsequent
+   keyword (e.g., "LIST HEADERS" and "LIST OVERVIEW.FMT") count as
+   different commands.  If there is a need for two extensions to use the
+   same command, a single harmonised specification MUST be registered.
+
+12.  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 include definitive
+   solutions to the problems revealed, though it does make some
+   suggestions for reducing security risks.
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 103]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+12.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 that personal and/or proprietary information in
+   material that is added automatically to articles (e.g., in headers)
+   is not disclosed inadvertently.  Additionally, effective and easily
+   understood mechanisms to manage the distribution of news articles
+   SHOULD be provided to NNTP Server administrators, so that they are
+   able to report with confidence the likely spread of any particular
+   set of news articles.
+
+12.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 this 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.
+
+12.3.  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 NNTP for such purposes; one such extension
+   is [NNTP-AUTH].  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.
+
+12.4.  DNS Spoofing
+
+   Many existing NNTP implementations authorize incoming connections by
+   checking the IP address of that connection against the IP addresses
+   obtained via DNS lookups of lists of domain names given in local
+   configuration files.  Servers that use this type of authentication
+   and clients that find a server by doing a DNS lookup of the server
+   name rely very heavily on the Domain Name Service, and are thus
+
+
+
+Feather                     Standards Track                   [Page 104]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   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 cache 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.
+
+   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 increase.  Observing this requirement thus reduces this
+   potential security vulnerability.
+
+   This requirement also improves the load-balancing behaviour 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.
+
+12.5.  UTF-8 Issues
+
+   UTF-8 [RFC3629] permits only certain sequences of octets and
+   designates others as either malformed or "illegal".  The Unicode
+   standard identifies a number of security issues related to illegal
+   sequences and forbids their generation by conforming implementations.
+
+   Implementations of this specification MUST NOT generate malformed or
+   illegal sequences and SHOULD detect them and take some appropriate
+   action.  This could include the following:
+
+   o  Generating a 501 response code.
+
+   o  Replacing such sequences by the sequence %xEF.BF.BD, which encodes
+      the "replacement character" U+FFFD.
+
+   o  Closing the connection.
+
+   o  Replacing such sequences by a "guessed" valid sequence (based on
+      properties of the UTF-8 encoding).
+
+
+
+Feather                     Standards Track                   [Page 105]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   In the last case, the implementation MUST ensure that any replacement
+   cannot be used to bypass validity or security checks.  For example,
+   the illegal sequence %xC0.A0 is an over-long encoding for space
+   (%x20).  If it is replaced by the correct encoding in a command line,
+   this needs to happen before the command line is parsed into
+   individual arguments.  If the replacement came after parsing, it
+   would be possible to generate an argument with an embedded space,
+   which is forbidden.  Use of the "replacement character" does not have
+   this problem, since it is permitted wherever non-US-ASCII characters
+   are.  Implementations SHOULD use one of the first two solutions where
+   the general structure of the NNTP stream remains intact and SHOULD
+   close the connection if it is no longer possible to parse it
+   sensibly.
+
+12.6.  Caching of Capability Lists
+
+   The CAPABILITIES command provides a capability list, which is
+   information about the current capabilities of the server.  Whenever
+   there is a relevant change to the server state, the results of this
+   command are required to change accordingly.
+
+   In most situations, the capabilities list in a given server state
+   will not change from session to session; for example, a given
+   extension will be installed permanently on a server.  Some clients
+   may therefore wish to remember which extensions a server supports to
+   avoid the delay of an additional command and response, particularly
+   if they open multiple connections in the same session.
+
+   However, information about extensions related to security and privacy
+   MUST NOT be cached, since this could allow a variety of attacks.
+
+   For example, consider a server that permits the use of cleartext
+   passwords on links that are encrypted but not otherwise:
+
+      [Initial connection set-up completed.]
+      [S] 200 NNTP Service Ready, posting permitted
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] NEWNEWS
+      [S] POST
+      [S] XENCRYPT
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] .
+      [C] XENCRYPT
+      [Client and server negotiate encryption on the link]
+      [S] 283 Encrypted link established
+
+
+
+Feather                     Standards Track                   [Page 106]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] NEWNEWS
+      [S] POST
+      [S] XSECRET
+      [S] LIST ACTIVE NEWSGROUPS
+      [S] .
+      [C] XSECRET fred flintstone
+      [S] 290 Password for fred accepted
+
+   If the client caches the last capabilities list, then on the next
+   session it will attempt to use XSECRET on an unencrypted link:
+
+      [Initial connection set-up completed.]
+      [S] 200 NNTP Service Ready, posting permitted
+      [C] XSECRET fred flintstone
+      [S] 483 Only permitted on secure links
+
+   This exposes the password to any eavesdropper.  While the primary
+   cause of this is passing a secret without first checking the security
+   of the link, caching of capability lists can increase the risk.
+
+   Any security extension should include requirements to check the
+   security state of the link in a manner appropriate to that extension.
+
+   Caching should normally only be considered for anonymous clients that
+   do not use any security or privacy extensions and for which the time
+   required for an additional command and response is a noticeable
+   issue.
+
+13.  Acknowledgements
+
+   This document is the result of much effort by the present and past
+   members of the NNTP Working Group, chaired by Russ Allbery and Ned
+   Freed.  It could not have been produced without them.
+
+   The author acknowledges the original authors of NNTP as documented in
+   RFC 977 [RFC977]: Brian Kantor and Phil Lapsey.
+
+   The author gratefully acknowledges the following:
+
+   o  The work of the NNTP committee chaired by Eliot Lear.  The
+      organization of this document was influenced by the last available
+      version from this working group.  A special thanks to Eliot for
+      generously providing the original machine-readable sources for
+      that document.
+
+
+
+Feather                     Standards Track                   [Page 107]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   o  The work of the DRUMS working group, specifically RFC 1869
+      [RFC1869], that drove the original thinking that led to the
+      CAPABILITIES command and the extensions mechanism detailed in this
+      document.
+
+   o  The authors of RFC 2616 [RFC2616] 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.
+
+   o  The comments and additional information provided by the following
+      individuals in preparing one or more of the progenitors of this
+      document:
+
+         Russ Allbery <rra@stanford.edu>
+         Wayne Davison <davison@armory.com>
+         Chris Lewis <clewis@bnr.ca>
+         Tom Limoncelli <tal@mars.superlink.net>
+         Eric Schnoebelen <eric@egsner.cirr.com>
+         Rich Salz <rsalz@osf.org>
+
+   This work was motivated by the work of various news reader authors
+   and news server authors, including 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.
+
+
+
+
+
+Feather                     Standards Track                   [Page 108]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   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.
+
+   Other people who contributed to this document include:
+
+      Matthias Andree
+      Greg Andruk
+      Daniel Barclay
+      Maurizio Codogno
+      Mark Crispin
+      Andrew Gierth
+      Juergen Helbing
+      Scott Hollenbeck
+      Urs Janssen
+      Charles Lindsey
+      Ade Lovett
+      David Magda
+      Ken Murchison
+      Francois Petillon
+      Peter Robinson
+      Rob Siemborski
+      Howard Swinehart
+      Ruud van Tol
+      Jeffrey Vinocur
+      Erik Warmelink
+
+   The author thanks them all and apologises to anyone omitted.
+
+   Finally, the present author gratefully acknowledges the vast amount
+   of work put into previous versions by the previous author:
+
+      Stan Barber <sob@academ.com>
+
+
+
+
+Feather                     Standards Track                   [Page 109]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+14.  References
+
+14.1.  Normative References
+
+   [ANSI1986]    American National Standards Institute, "Coded Character
+                 Set - 7-bit American Standard Code for Information
+                 Interchange", ANSI X3.4, 1986.
+
+   [RFC977]      Kantor, B. and P. Lapsley, "Network News Transfer
+                 Protocol", RFC 977, February 1986.
+
+   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) Part One: Format of Internet
+                 Message Bodies", RFC 2045, November 1996.
+
+   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
+                 Extensions) Part Three: Message Header Extensions for
+                 Non-ASCII Text", RFC 2047, November 1996.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
+                 Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4648]     Josefsson, S., "The Base16, Base32, and Base64 Data
+                 Encodings", RFC 4648, October 2006.
+
+   [TF.686-1]    International Telecommunications Union - Radio,
+                 "Glossary, ITU-R Recommendation TF.686-1",
+                 ITU-R Recommendation TF.686-1, October 1997.
+
+14.2.  Informative References
+
+   [NNTP-AUTH]   Vinocur, J., Murchison, K., and C. Newman, "Network
+                 News Transfer Protocol (NNTP) Extension for
+                 Authentication",
+                 RFC 4643, October 2006.
+
+   [NNTP-STREAM] Vinocur, J. and K. Murchison, "Network News Transfer
+                 Protocol (NNTP) Extension for Streaming Feeds",
+                 RFC 4644, October 2006.
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 110]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   [NNTP-TLS]    Murchison, K., Vinocur, J., and C. Newman, "Using
+                 Transport Layer Security (TLS) with Network News
+                 Transfer Protocol (NNTP)", RFC 4642, October 2006.
+
+   [RFC1036]     Horton, M. and R. Adams, "Standard for interchange of
+                 USENET messages", RFC 1036, December 1987.
+
+   [RFC1305]     Mills, D., "Network Time Protocol (Version 3)
+                 Specification, Implementation and Analysis", RFC 1305,
+                 March 1992.
+
+   [RFC1869]     Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
+                 Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+                 November 1995.
+
+   [RFC2616]     Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
+                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2629]     Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+                 June 1999.
+
+   [RFC2822]     Resnick, P., "Internet Message Format", RFC 2822, April
+                 2001.
+
+   [RFC2980]     Barber, S., "Common NNTP Extensions", RFC 2980, October
+                 2000.
+
+   [ROBE1995]    Robertson, R., "FAQ: Overview database / NOV General
+                 Information", January 1995.
+
+                 There is no definitive copy of this document known to
+                 the author.  It was previously posted as the Usenet
+                 article <news:nov-faq-1-930909720@agate.Berkeley.EDU>
+
+   [SALZ1992]    Salz, R., "Manual Page for wildmat(3) from the INN 1.4
+                 distribution, Revision 1.10", April 1992.
+
+                 There is no definitive copy of this document known to
+                 the author.
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 111]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+Appendix A.  Interaction with Other Specifications
+
+   NNTP is most often used for transferring articles that conform to
+   RFC 1036 [RFC1036] (such articles are called "Netnews articles"
+   here).  It is also sometimes used for transferring email messages
+   that conform to RFC 2822 [RFC2822] (such articles are called "email
+   articles" here).  In this situation, articles must conform both to
+   this specification and to that other one; this appendix describes
+   some relevant issues.
+
+A.1.  Header Folding
+
+   NNTP allows a header line to be folded (by inserting a CRLF pair)
+   before any space or TAB character.
+
+   Both email and Netnews articles are required to have at least one
+   octet other than space or TAB on each header line.  Thus, folding can
+   only happen at one point in each sequence of consecutive spaces or
+   TABs.  Netnews articles are further required to have the header name,
+   colon, and following space all on the first line; folding may only
+   happen beyond that space.  Finally, some non-conforming software will
+   remove trailing spaces and TABs from a line.  Therefore, it might be
+   inadvisable to fold a header after a space or TAB.
+
+   For maximum safety, header lines SHOULD conform to the following
+   syntax rather than to that in Section 9.7.
+
+
+     header = header-name ":" SP [header-content] CRLF
+     header-content = [WS] token *( [CRLF] WS token )
+
+A.2.  Message-IDs
+
+   Every article handled by an NNTP server MUST have a unique
+   message-id.  For the purposes of this specification, a message-id is
+   an arbitrary opaque string that merely needs to meet certain
+   syntactic requirements and is just a way to refer to the article.
+
+   Because there is a significant risk that old articles will be
+   reinjected into the global Usenet system, RFC 1036 [RFC1036] requires
+   that message-ids are globally unique for all time.
+
+   This specification states that message-ids are the same if and only
+   if they consist of the same sequence of octets.  Other specifications
+   may define two different sequences as being equal because they are
+   putting an interpretation on particular characters.  RFC 2822
+   [RFC2822] has a concept of "quoted" and "escaped" characters.  It
+   therefore considers the three message-ids:
+
+
+
+Feather                     Standards Track                   [Page 112]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+      <ab.cd@example.com>
+      <"ab.cd"@example.com>
+      <"ab.\cd"@example.com>
+
+   as being identical.  Therefore, an NNTP implementation handing email
+   articles must ensure that only one of these three appears in the
+   protocol and that the other two are converted to it as and when
+   necessary, such as when a client checks the results of a NEWNEWS
+   command against an internal database of message-ids.  Note that
+   RFC 1036 [RFC1036] never treats two different strings as being
+   identical.  Its successor (as of the time of writing) restricts the
+   syntax of message-ids so that, whenever RFC 2822 would treat two
+   strings as equivalent, only one of them is valid (in the above
+   example, only the first string is valid).
+
+   This specification does not describe how the message-id of an article
+   is determined; it may be deduced from the contents of the article or
+   derived from some external source.  If the server is also conforming
+   to another specification that contains a definition of message-id
+   compatible with this one, the server SHOULD use those message-ids.  A
+   common approach, and one that SHOULD be used for email and Netnews
+   articles, is to extract the message-id from the contents of a header
+   with name "Message-ID".  This may not be as simple as copying the
+   entire header contents; it may be necessary to strip off comments and
+   undo quoting, or to reduce "equivalent" message-ids to a canonical
+   form.
+
+   If an article is obtained through the IHAVE command, there will be a
+   message-id provided with the command.  The server MAY either use it
+   or determine one from the article contents.  However, whichever it
+   does, it SHOULD ensure that, if the IHAVE command is repeated with
+   the same argument and article, it will be recognized as a duplicate.
+
+   If an article does not contain a message-id that the server can
+   identify, it MUST synthesize one.  This could, for example, be a
+   simple sequence number or be based on the date and time when the
+   article arrived.  When email or Netnews articles are handled, a
+   Message-ID header SHOULD be added to ensure global consistency and
+   uniqueness.
+
+   Note that, because the message-id might not have been derived from
+   the Message-ID header in the article, the following example is
+   legitimate (though unusual):
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 113]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+      [C] HEAD <45223423@example.com>
+      [S] 221 0 <45223423@example.com>
+      [S] Path: pathost!demo!whitehouse!not-for-mail
+      [S] Message-ID: <1234@example.net>
+      [S] From: "Demo User" <nobody@example.net>
+      [S] Newsgroups: misc.test
+      [S] Subject: I am just a test article
+      [S] Date: 6 Oct 1998 04:38:40 -0500
+      [S] Organization: An Example Net, Uncertain, Texas
+      [S] .
+
+A.3.  Article Posting
+
+   As far as NNTP is concerned, the POST and IHAVE commands provide the
+   same basic facilities in a slightly different way.  However, they
+   have rather different intentions.
+
+   The IHAVE command is intended for transmitting conforming articles
+   between a system of NNTP servers, with all articles perhaps also
+   conforming to another specification (e.g., all articles are Netnews
+   articles).  It is expected that the client will already have done any
+   necessary validation (or that it has in turn obtained the article
+   from a third party that has done so); therefore, the contents SHOULD
+   be left unchanged.
+
+   In contrast, the POST command is intended for use when an end-user is
+   injecting a newly created article into a such a system.  The article
+   being transferred might not be a conforming email or Netnews article,
+   and the server is expected to validate it and, if necessary, to
+   convert it to the right form for onward distribution.  This is often
+   done by a separate piece of software on the server installation; if
+   so, the NNTP server SHOULD pass the incoming article to that software
+   unaltered, making no attempt to filter characters, to fold or limit
+   lines, or to process the incoming text otherwise.
+
+   The POST command can fail in various ways, and clients should be
+   prepared to re-send an article.  When doing so, however, it is often
+   important to ensure (as far as possible) that the same message-id is
+   allocated to both attempts so that the server, or other servers, can
+   recognize the two articles as duplicates.  In the case of email or
+   Netnews articles, therefore, the posted article SHOULD contain a
+   header with the name "Message-ID", and the contents of this header
+   SHOULD be identical on each attempt.  The server SHOULD ensure that
+   two POSTed articles with the same contents for this header are
+   recognized as identical and that the same message-id is allocated,
+   whether or not those contents are suitable for use as the message-id.
+
+
+
+
+
+Feather                     Standards Track                   [Page 114]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+Appendix B.  Summary of Commands
+
+   This section contains a list of every command defined in this
+   document, ordered by command name and by indicating capability.
+
+                         Ordered by command name:
+
+       +-------------------+-----------------------+---------------+
+       | Command           | Indicating capability | Definition    |
+       +-------------------+-----------------------+---------------+
+       | ARTICLE           | READER                | Section 6.2.1 |
+       | BODY              | READER                | Section 6.2.3 |
+       | CAPABILITIES      | mandatory             | Section 5.2   |
+       | DATE              | READER                | Section 7.1   |
+       | GROUP             | READER                | Section 6.1.1 |
+       | HDR               | HDR                   | Section 8.5   |
+       | HEAD              | mandatory             | Section 6.2.2 |
+       | HELP              | mandatory             | Section 7.2   |
+       | IHAVE             | IHAVE                 | Section 6.3.2 |
+       | LAST              | READER                | Section 6.1.3 |
+       | LIST              | LIST                  | Section 7.6.1 |
+       | LIST ACTIVE.TIMES | LIST                  | Section 7.6.4 |
+       | LIST ACTIVE       | LIST                  | Section 7.6.3 |
+       | LIST DISTRIB.PATS | LIST                  | Section 7.6.5 |
+       | LIST HEADERS      | HDR                   | Section 8.6   |
+       | LIST NEWSGROUPS   | LIST                  | Section 7.6.6 |
+       | LIST OVERVIEW.FMT | OVER                  | Section 8.4   |
+       | LISTGROUP         | READER                | Section 6.1.2 |
+       | MODE READER       | MODE-READER           | Section 5.3   |
+       | NEWGROUPS         | READER                | Section 7.3   |
+       | NEWNEWS           | NEWNEWS               | Section 7.4   |
+       | NEXT              | READER                | Section 6.1.4 |
+       | OVER              | OVER                  | Section 8.3   |
+       | POST              | POST                  | Section 6.3.1 |
+       | QUIT              | mandatory             | Section 5.4   |
+       | STAT              | mandatory             | Section 6.2.4 |
+       +-------------------+-----------------------+---------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 115]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+                     Ordered by indicating capability:
+
+       +-------------------+-----------------------+---------------+
+       | Command           | Indicating capability | Definition    |
+       +-------------------+-----------------------+---------------+
+       | CAPABILITIES      | mandatory             | Section 5.2   |
+       | HEAD              | mandatory             | Section 6.2.2 |
+       | HELP              | mandatory             | Section 7.2   |
+       | QUIT              | mandatory             | Section 5.4   |
+       | STAT              | mandatory             | Section 6.2.4 |
+       | HDR               | HDR                   | Section 8.5   |
+       | LIST HEADERS      | HDR                   | Section 8.6   |
+       | IHAVE             | IHAVE                 | Section 6.3.2 |
+       | LIST              | LIST                  | Section 7.6.1 |
+       | LIST ACTIVE       | LIST                  | Section 7.6.3 |
+       | LIST ACTIVE.TIMES | LIST                  | Section 7.6.4 |
+       | LIST DISTRIB.PATS | LIST                  | Section 7.6.5 |
+       | LIST NEWSGROUPS   | LIST                  | Section 7.6.6 |
+       | MODE READER       | MODE-READER           | Section 5.3   |
+       | NEWNEWS           | NEWNEWS               | Section 7.4   |
+       | OVER              | OVER                  | Section 8.3   |
+       | LIST OVERVIEW.FMT | OVER                  | Section 8.4   |
+       | POST              | POST                  | Section 6.3.1 |
+       | ARTICLE           | READER                | Section 6.2.1 |
+       | BODY              | READER                | Section 6.2.3 |
+       | DATE              | READER                | Section 7.1   |
+       | GROUP             | READER                | Section 6.1.1 |
+       | LAST              | READER                | Section 6.1.3 |
+       | LISTGROUP         | READER                | Section 6.1.2 |
+       | NEWGROUPS         | READER                | Section 7.3   |
+       | NEXT              | READER                | Section 6.1.4 |
+       +-------------------+-----------------------+---------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 116]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+Appendix C.  Summary of Response Codes
+
+   This section contains a list of every response code defined in this
+   document and indicates whether it is multi-line, which commands can
+   generate it, what arguments it has, and what its meaning is.
+
+   Response code 100 (multi-line)
+      Generated by: HELP
+      Meaning: help text follows.
+
+   Response code 101 (multi-line)
+      Generated by: CAPABILITIES
+      Meaning: capabilities list follows.
+
+   Response code 111
+      Generated by: DATE
+      1 argument: yyyymmddhhmmss
+      Meaning: server date and time.
+
+   Response code 200
+      Generated by: initial connection, MODE READER
+      Meaning: service available, posting allowed.
+
+   Response code 201
+      Generated by: initial connection, MODE READER
+      Meaning: service available, posting prohibited.
+
+   Response code 205
+      Generated by: QUIT
+      Meaning: connection closing (the server immediately closes the
+      connection).
+
+   Response code 211
+      The 211 response code has two completely different forms,
+      depending on which command generated it:
+
+         (not multi-line)
+         Generated by: GROUP
+         4 arguments: number low high group
+         Meaning: group selected.
+
+         (multi-line)
+         Generated by: LISTGROUP
+         4 arguments: number low high group
+         Meaning: article numbers follow.
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 117]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Response code 215 (multi-line)
+      Generated by: LIST
+      Meaning: information follows.
+
+   Response code 220 (multi-line)
+      Generated by: ARTICLE
+      2 arguments: n message-id
+      Meaning: article follows.
+
+   Response code 221 (multi-line)
+      Generated by: HEAD
+      2 arguments: n message-id
+      Meaning: article headers follow.
+
+   Response code 222 (multi-line)
+      Generated by: BODY
+      2 arguments: n message-id
+      Meaning: article body follows.
+
+   Response code 223
+      Generated by: LAST, NEXT, STAT
+      2 arguments: n message-id
+      Meaning: article exists and selected.
+
+   Response code 224 (multi-line)
+      Generated by: OVER
+      Meaning: overview information follows.
+
+   Response code 225 (multi-line)
+      Generated by: HDR
+      Meaning: headers follow.
+
+   Response code 230 (multi-line)
+      Generated by: NEWNEWS
+      Meaning: list of new articles follows.
+
+   Response code 231 (multi-line)
+      Generated by: NEWGROUPS
+      Meaning: list of new newsgroups follows.
+
+   Response code 235
+      Generated by: IHAVE (second stage)
+      Meaning: article transferred OK.
+
+   Response code 240
+      Generated by: POST (second stage)
+      Meaning: article received OK.
+
+
+
+
+Feather                     Standards Track                   [Page 118]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Response code 335
+      Generated by: IHAVE (first stage)
+      Meaning: send article to be transferred.
+
+   Response code 340
+      Generated by: POST (first stage)
+      Meaning: send article to be posted.
+
+   Response code 400
+      Generic response and generated by initial connection
+      Meaning: service not available or no longer available (the server
+      immediately closes the connection).
+
+   Response code 401
+      Generic response
+      1 argument: capability-label
+      Meaning: the server is in the wrong mode; the indicated capability
+      should be used to change the mode.
+
+   Response code 403
+      Generic response
+      Meaning: internal fault or problem preventing action being taken.
+
+   Response code 411
+      Generated by: GROUP, LISTGROUP
+      Meaning: no such newsgroup.
+
+   Response code 412
+      Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP,
+      NEXT, OVER, STAT
+      Meaning: no newsgroup selected.
+
+   Response code 420
+      Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT
+      Meaning: current article number is invalid.
+
+   Response code 421
+      Generated by: NEXT
+      Meaning: no next article in this group.
+
+   Response code 422
+      Generated by: LAST
+      Meaning: no previous article in this group.
+
+   Response code 423
+      Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT
+      Meaning: no article with that number or in that range.
+
+
+
+
+Feather                     Standards Track                   [Page 119]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Response code 430
+      Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT
+      Meaning: no article with that message-id.
+
+   Response code 435
+      Generated by: IHAVE (first stage)
+      Meaning: article not wanted.
+
+   Response code 436
+      Generated by: IHAVE (either stage)
+      Meaning: transfer not possible (first stage) or failed (second
+      stage); try again later.
+
+   Response code 437
+      Generated by: IHAVE (second stage)
+      Meaning: transfer rejected; do not retry.
+
+   Response code 440
+      Generated by: POST (first stage)
+      Meaning: posting not permitted.
+
+   Response code 441
+      Generated by: POST (second stage)
+      Meaning: posting failed.
+
+   Response code 480
+      Generic response
+      Meaning: command unavailable until the client has authenticated
+      itself.
+
+   Response code 483
+      Generic response
+      Meaning: command unavailable until suitable privacy has been
+      arranged.
+
+   Response code 500
+      Generic response
+      Meaning: unknown command.
+
+   Response code 501
+      Generic response
+      Meaning: syntax error in command.
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 120]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   Response code 502
+      Generic response and generated by initial connection
+
+      Meaning for the initial connection and the MODE READER command:
+      service permanently unavailable (the server immediately closes the
+      connection).
+
+      Meaning for all other commands: command not permitted (and there
+      is no way for the client to change this).
+
+   Response code 503
+      Generic response
+      Meaning: feature not supported.
+
+   Response code 504
+      Generic response
+      Meaning: error in base64-encoding [RFC4648] of an argument.
+
+Appendix D.  Changes from RFC 977
+
+   In general every attempt has been made to ensure that the protocol
+   specification in this document is compatible with the version
+   specified in RFC 977 [RFC977] and the various facilities adopted from
+   RFC 2980 [RFC2980].  However, there have been a number of changes,
+   some compatible and some not.
+
+   This appendix lists these changes.  It is not guaranteed to be
+   exhaustive or correct and MUST NOT be relied on.
+
+   o  A formal syntax specification (Section 9) has been added.
+
+   o  The default character set is changed from US-ASCII [ANSI1986] to
+      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8).  This
+      matter is discussed further in Section 10.
+
+   o  All articles are required to have a message-id, eliminating the
+      "<0>" placeholder used in RFC 977 in some responses.
+
+   o  The newsgroup name matching capabilities already documented in
+      RFC 977 ("wildmats", Section 4) are clarified and extended.  The
+      new facilities (e.g., the use of commas and exclamation marks) are
+      allowed wherever wildmats appear in the protocol.
+
+   o  Support for pipelining of commands (Section 3.5) is made
+      mandatory.
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 121]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   o  The principles behind response codes (Section 3.2) have been
+      tidied up.  In particular:
+
+      *  the x8x response code family, formerly used for private
+         extensions, is now reserved for authentication and privacy
+         extensions;
+
+      *  the x9x response code family, formerly intended for debugging
+         facilities, are now reserved for private extensions;
+
+      *  the 502 and 503 generic response codes (Section 3.2.1) have
+         been redefined;
+
+      *  new 401, 403, 480, 483, and 504 generic response codes have
+         been added.
+
+   o  The rules for article numbering (Section 6) have been clarified
+      (also see Section 6.1.1.2).
+
+   o  The SLAVE command (which was ill-defined) is removed from the
+      protocol.
+
+   o  Four-digit years are permitted in the NEWNEWS (Section 7.4) and
+      NEWGROUPS (Section 7.3) commands (two-digit years are still
+      permitted).  The optional distribution parameter to these commands
+      has been removed.
+
+   o  The LIST command (Section 7.6.1) is greatly extended; the original
+      is available as LIST ACTIVE, while new variants include
+      ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS.  A new "m" status flag
+      is added to the LIST ACTIVE response.
+
+   o  A new CAPABILITIES command (Section 5.2) allows clients to
+      determine what facilities are supported by a server.
+
+   o  The DATE command (Section 7.1) is adopted from RFC 2980
+      effectively unchanged.
+
+   o  The LISTGROUP command (Section 6.1.2) is adopted from RFC 2980.
+      An optional range argument has been added, and the 211 initial
+      response line now has the same format as the 211 response from the
+      GROUP command.
+
+   o  The MODE READER command (Section 5.3) is adopted from RFC 2980 and
+      its meaning and effects clarified.
+
+   o  The XHDR command in RFC 2980 has been formalised as the new HDR
+      (Section 8.5) and LIST HEADERS (Section 8.6) commands.
+
+
+
+Feather                     Standards Track                   [Page 122]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+   o  The XOVER command in RFC 2980 has been formalised as the new OVER
+      (Section 8.3) and LIST OVERVIEW.FMT (Section 8.4) commands.  The
+      former can be applied to a message-id as well as to a range.
+
+   o  The concept of article metadata (Section 8.1) has been formalised,
+      allowing the Bytes and Lines pseudo-headers to be deprecated.
+
+   Client authors should note in particular that lack of support for the
+   CAPABILITIES command is a good indication that the server does not
+   support this specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 123]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+Author's Address
+
+   Clive D.W. Feather
+   THUS plc
+   322 Regents Park Road
+   London
+   N3  2QQ
+   United Kingdom
+
+   Phone: +44 20 8495 6138
+   Fax:   +44 870 051 9937
+   EMail: clive@demon.net
+   URI:   http://www.davros.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 124]
+
+RFC 3977         Network News Transfer Protocol (NNTP)      October 2006
+
+
+Full Copyright Statement
+
+Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Feather                     Standards Track                   [Page 125]
+