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