diff -r ed84c8bdd87b -r c404a87db5b7 RFC3977
--- a/RFC3977 Sun Aug 29 17:28:58 2010 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,6998 +0,0 @@
-
-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]
-