idnits 2.17.1 draft-ietf-nntpext-base-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([3], [12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 36 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 289 has weird spacing: '...cal|bar indic...' == Line 830 has weird spacing: '...abc,def the t...' == Line 2065 has weird spacing: '...dhhmmss serv...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: These are the only valid response codes for the initial greeting; the server MUST not return any other generic response code. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2003) is 7727 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'C' on line 3330 -- Looks like a reference, but probably isn't: 'S' on line 3331 -- Looks like a reference, but probably isn't: 'GMT' on line 2185 ** Obsolete normative reference: RFC 977 (ref. '1') (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 2279 (ref. '2') (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1036 (ref. '6') (Obsoleted by RFC 5536, RFC 5537) ** Obsolete normative reference: RFC 2822 (ref. '7') (Obsoleted by RFC 5322) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. '12') (Obsoleted by RFC 7749) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NNTP C. Feather 3 Internet-Draft Thus plc 4 Expires: August 30, 2003 March 1, 2003 6 Network News Transport Protocol 7 draft-ietf-nntpext-base-17 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 30, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The Network News Transport Protocol has been in use in the Internet 39 for a decade and remains one of the most popular protocols (by 40 volume) in use today. This document is a replacement for RFC 977 and 41 officially updates the protocol specification. It clarifies some 42 vagueness in RFC 977, includes some new base functionality and 43 provides a specific mechanism to add standardized extensions to NNTP. 45 Administration 47 This document is a product of the NNTP Working Group, chaired by Russ 48 Allbery. 50 This is draft 17 pre-publication version 2. 52 Outstanding issues 54 Outstanding substantive (as opposed to editorial) issues in the text 55 are shown as in the following case. 57 OUTSTANDING ISSUE 59 Reference consistency: should every RFC that is mentioned be 60 included in the references? Where the same document is referred to 61 in more than one place, should every occasion have a reference 62 number (that is, "RFC 977 [3]" or similar), or only the first one, 63 or only the first one in each section? 65 Author's Note 67 This draft is the first produced using a new formatting process. It 68 therefore may contain unintentional layout or formatting changes 69 compared with previous drafts. The author would appreciate being 70 informed of any problems this has caused. 72 This draft is written in XML using an NNTP-specific DTD. Custom 73 software is used to convert this to RFC 2629 [12] format, and then 74 the public "xml2rfc" package to further reduce this to text, nroff 75 source, and HTML. 77 No perl was used in producing this draft. 79 Rights 81 UNIX is a registered trademark of the X/Open Company Ltd. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 86 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 87 3. Basic Operation . . . . . . . . . . . . . . . . . . . . 9 88 3.1 Response Codes . . . . . . . . . . . . . . . . . . . . . 11 89 3.1.1 Generic Response Codes . . . . . . . . . . . . . . . . . 13 90 3.1.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 15 91 3.2 Pipelining . . . . . . . . . . . . . . . . . . . . . . . 16 92 3.2.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 93 4. The WILDMAT format . . . . . . . . . . . . . . . . . . . 18 94 4.1 Wildmat syntax . . . . . . . . . . . . . . . . . . . . . 18 95 4.2 Wildmat semantics . . . . . . . . . . . . . . . . . . . 18 96 4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . 19 97 4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 98 5. The GREETING Step . . . . . . . . . . . . . . . . . . . 21 99 5.1 Initial Connection . . . . . . . . . . . . . . . . . . . 21 100 5.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 5.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 21 102 5.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 21 103 5.2 MODE READER . . . . . . . . . . . . . . . . . . . . . . 22 104 5.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 5.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 22 106 5.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 107 6. The CAPABILITIES DISCOVERY step . . . . . . . . . . . . 25 108 6.1 LIST EXTENSIONS . . . . . . . . . . . . . . . . . . . . 25 109 6.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 25 110 6.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 25 111 6.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 26 112 7. Article posting and retrieval . . . . . . . . . . . . . 27 113 7.1 Group and article selection . . . . . . . . . . . . . . 27 114 7.1.1 GROUP . . . . . . . . . . . . . . . . . . . . . . . . . 27 115 7.1.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 28 116 7.1.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 28 117 7.1.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 29 118 7.1.2 LAST . . . . . . . . . . . . . . . . . . . . . . . . . . 30 119 7.1.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 30 120 7.1.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 30 121 7.1.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 31 122 7.1.3 NEXT . . . . . . . . . . . . . . . . . . . . . . . . . . 32 123 7.1.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 32 124 7.1.3.2 Description . . . . . . . . . . . . . . . . . . . . . . 32 125 7.1.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 32 126 7.2 Retrieval of articles and article sections . . . . . . . 33 127 7.2.1 ARTICLE . . . . . . . . . . . . . . . . . . . . . . . . 33 128 7.2.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 33 129 7.2.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 34 130 7.2.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 35 131 7.2.2 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 7.2.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 36 133 7.2.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 37 134 7.2.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 37 135 7.2.3 BODY . . . . . . . . . . . . . . . . . . . . . . . . . . 39 136 7.2.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 39 137 7.2.3.2 Description . . . . . . . . . . . . . . . . . . . . . . 39 138 7.2.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 39 139 7.2.4 STAT . . . . . . . . . . . . . . . . . . . . . . . . . . 40 140 7.2.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 40 141 7.2.4.2 Description . . . . . . . . . . . . . . . . . . . . . . 41 142 7.2.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 41 143 7.3 Article posting . . . . . . . . . . . . . . . . . . . . 42 144 7.3.1 POST . . . . . . . . . . . . . . . . . . . . . . . . . . 42 145 7.3.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 42 146 7.3.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 43 147 7.3.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 44 148 7.3.2 IHAVE . . . . . . . . . . . . . . . . . . . . . . . . . 44 149 7.3.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 44 150 7.3.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 45 151 7.3.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 46 152 8. Information commands . . . . . . . . . . . . . . . . . . 48 153 8.1 DATE . . . . . . . . . . . . . . . . . . . . . . . . . . 48 154 8.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 48 155 8.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 48 156 8.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 48 157 8.2 HELP . . . . . . . . . . . . . . . . . . . . . . . . . . 48 158 8.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 48 159 8.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 49 160 8.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 49 161 8.3 NEWGROUPS . . . . . . . . . . . . . . . . . . . . . . . 49 162 8.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 49 163 8.3.2 Description . . . . . . . . . . . . . . . . . . . . . . 49 164 8.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 50 165 8.4 NEWNEWS . . . . . . . . . . . . . . . . . . . . . . . . 50 166 8.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 51 167 8.4.2 Description . . . . . . . . . . . . . . . . . . . . . . 51 168 8.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 51 169 8.5 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 52 170 8.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 52 171 8.6 The LIST commands . . . . . . . . . . . . . . . . . . . 53 172 8.6.1 LIST ACTIVE . . . . . . . . . . . . . . . . . . . . . . 53 173 8.6.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 53 174 8.6.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 53 175 8.6.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 54 176 8.6.2 LIST ACTIVE.TIMES . . . . . . . . . . . . . . . . . . . 55 177 8.6.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 55 178 8.6.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 55 179 8.6.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 55 180 8.6.3 LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . 56 181 8.6.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 56 182 8.6.3.2 Description . . . . . . . . . . . . . . . . . . . . . . 56 183 8.6.3.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 57 184 8.6.4 LIST DISTRIB.PATS . . . . . . . . . . . . . . . . . . . 57 185 8.6.4.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 57 186 8.6.4.2 Description . . . . . . . . . . . . . . . . . . . . . . 57 187 8.6.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 58 188 8.6.5 LIST NEWSGROUPS . . . . . . . . . . . . . . . . . . . . 58 189 8.6.5.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 58 190 8.6.5.2 Description . . . . . . . . . . . . . . . . . . . . . . 59 191 8.6.5.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 59 192 9. The CONCLUSION step . . . . . . . . . . . . . . . . . . 60 193 9.1 QUIT . . . . . . . . . . . . . . . . . . . . . . . . . . 60 194 9.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 60 195 9.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 60 196 9.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 60 197 10. Framework for NNTP extensions . . . . . . . . . . . . . 61 198 10.1 Initial IANA registry . . . . . . . . . . . . . . . . . 63 199 10.2 Standard extensions . . . . . . . . . . . . . . . . . . 63 200 10.3 The LISTGROUP extension . . . . . . . . . . . . . . . . 63 201 10.3.1 LISTGROUP . . . . . . . . . . . . . . . . . . . . . . . 63 202 10.3.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 63 203 10.3.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 64 204 10.3.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 64 205 10.4 Article metadata . . . . . . . . . . . . . . . . . . . . 65 206 10.4.1 The :bytes metadata item . . . . . . . . . . . . . . . . 65 207 10.4.2 The :lines metadata item . . . . . . . . . . . . . . . . 66 208 10.5 The OVER extension . . . . . . . . . . . . . . . . . . . 66 209 10.5.1 OVER . . . . . . . . . . . . . . . . . . . . . . . . . . 66 210 10.5.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 66 211 10.5.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 67 212 10.5.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 68 213 10.5.2 LIST OVERVIEW.FMT . . . . . . . . . . . . . . . . . . . 69 214 10.5.2.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 69 215 10.5.2.2 Description . . . . . . . . . . . . . . . . . . . . . . 70 216 10.5.2.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 71 217 10.6 The HDR extension . . . . . . . . . . . . . . . . . . . 72 218 10.6.1 HDR . . . . . . . . . . . . . . . . . . . . . . . . . . 72 219 10.6.1.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . 72 220 10.6.1.2 Description . . . . . . . . . . . . . . . . . . . . . . 72 221 10.6.1.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 74 222 11. Augmented BNF Syntax for NNTP Commands . . . . . . . . . 76 223 12. Security Considerations . . . . . . . . . . . . . . . . 79 224 12.1 Personal and Proprietary Information . . . . . . . . . . 79 225 12.2 Abuse of Server Log Information . . . . . . . . . . . . 79 226 12.3 Weak Authentication and Access Control . . . . . . . . . 79 227 12.4 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 80 228 12.5 UTF-8 issues . . . . . . . . . . . . . . . . . . . . . . 80 229 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 82 230 Normative References . . . . . . . . . . . . . . . . . . 84 231 Informative References . . . . . . . . . . . . . . . . . 85 232 Author's Address . . . . . . . . . . . . . . . . . . . . 85 233 Intellectual Property and Copyright Statements . . . . . 86 235 1. Introduction 237 This document specifies the Network News Transport Protocol (NNTP), 238 which is used for the distribution, inquiry, retrieval, and posting 239 of net news articles using a reliable stream-based mechanism. For 240 news reading clients, NNTP enables retrieval of news articles that 241 are stored in a central database, giving subscribers the ability to 242 select only those articles they wish to read. 244 The net news model provides for indexing, cross-referencing, and 245 expiration of aged messages. For server-to-server interaction, NNTP 246 is designed for efficient transmission of net news articles over a 247 reliable full duplex communication channel. 249 Every attempt is made to ensure that the protocol specification in 250 this document is compatible with the version specified in RFC 977 251 [1]. However, this version does not support the ill-defined SLAVE 252 command and permits four digit years to be specified in the NEWNEWS 253 and NEWGROUPS commands. It changes the default character set to 254 UTF-8 [2] instead of US-ASCII [3]. It also extends the newsgroup 255 name matching capabilities already documented in RFC 977. 257 Generally, new functionality is made available using new commands. 258 Part of that new functionality involves a mechanism to discover what 259 new functionality is available to clients from a server. 261 This mechanism can also be used to add more functionality as needs 262 merit such additions. 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 266 document are to be interpreted as described in RFC 2119 [4]. 268 An implementation is not compliant if it fails to satisfy one or more 269 of the MUST requirements for this protocol. An implementation that 270 satisfies all the MUST and all the SHOULD requirements for its 271 protocols is said to be "unconditionally compliant"; one that 272 satisfies all the MUST requirements but not all the SHOULD 273 requirements for NNTP is said to be "conditionally compliant". 275 For the remainder of this document, the term "client host" refers to 276 a host making use of the NNTP service, while the term "server host" 277 refers to a host that offers the NNTP service. 279 2. Notation 281 The following notational conventions are used in this document. 283 UPPERCASE indicates literal text to be included in the 284 command; 285 lowercase indicates a token described elsewhere; 286 [brackets] indicate that the parameter is optional; 287 ellipsis... indicates that the parameter may be repeated any 288 number of times (it must occur at least once); 289 vertical|bar indicates a choice of two mutually exclusive 290 parameters (exactly one must be provided). 292 The name "message-id" for a command or response parameter indicates 293 that it is the message-id of an article as described in Section 7. 294 The actual parameter MUST include the angle brackets. 296 The name "wildmat" for a parameter indicates that it is a wildmat as 297 defined in Section 4. If the parameter does not meet the 298 requirements of that section (for example, if it does not fit the 299 grammar of Section 4.1) the NNTP server MAY place some interpretation 300 on it (not specified by this document) or otherwise MUST treat it as 301 a syntax error. 303 Responses for each command will be described in tables listing the 304 required format of a response followed by the meaning that should be 305 ascribed to that response. 307 Examples in this document are not normative but serve to illustrate 308 usages, arguments, and responses. In the examples, a "[C]" will be 309 used to represent the client host and a "[S]" will be used to 310 represent the server host. Most of the examples do not rely on a 311 particular server state. In some cases, however, they do assume that 312 the current selected newsgroup (see the GROUP command (Section 313 7.1.1)) is invalid; when so, this is indicated at the start of the 314 example. 316 3. Basic Operation 318 Every NNTP session MUST involve the following in this order: 320 CONNECTION 321 GREETING 322 DISCONNECTION 324 Other steps may occur between the GREETING and DISCONNECTION step. 325 They are: 327 CAPABILITIES DISCOVERY 328 NEWS EXCHANGE 329 CONCLUSION 331 NNTP operates over any reliable data stream 8-bit-wide channel. When 332 running over TCP/IP, the official port for the NNTP service is 119. 333 Initially, the server host starts the NNTP service by listening on a 334 TCP port. When a client host wishes to make use of the service, it 335 MUST establish a TCP connection with the server host by connecting to 336 that host on the same port on which the server is listening. This is 337 the CONNECTION step. When the connection is established, the NNTP 338 server host MUST send a greeting. This is the GREETING step. The 339 client host and server host SHOULD then exchange commands and 340 responses (respectively) until the connection is closed or aborted. 341 This final step is called the DISCONNECTION step. 343 If there is a CONCLUSION step, it MUST immediately precede the 344 DISCONNECTION step. There MUST be only one CONNECTION, CONCLUSION 345 and DISCONNECTION step for each NNTP session. All other steps MAY be 346 repeated as needed. For example, the GREETING step may be repeated 347 if the client makes use of the MODE READER command (see Section 5.2 348 for more on the MODE READER command). 350 OUTSTANDING ISSUE 352 Do we actually need this GREETING / NEWS EXCHANGE / DISCONNECTION 353 type stuff? I don't see that it buys us anything compared with 354 simply saying that there's the initial greeting and a set of 355 commands. 357 The character set for all NNTP commands is UTF-8. Commands in the 358 NNTP MUST consist of a keyword, which MAY be followed by one or more 359 arguments. An US-ASCII CRLF pair MUST terminate all commands. 360 Multiple commands MUST NOT be on the same line. Keywords MUST 361 consist of printable US-ASCII characters. Unless otherwise noted 362 elsewhere in this document, arguments SHOULD consist of printable 363 US-ASCII characters. Keywords and arguments MUST be each separated 364 by one or more US-ASCII SPACE or US-ASCII TAB characters. Keywords 365 MUST be at least three US-ASCII characters and MUST NOT exceed 12 366 US-ASCII characters. Command lines MUST NOT exceed 512 octets, which 367 includes the terminating US-ASCII CRLF pair. The arguments MUST NOT 368 exceed 497 octets. 370 Commands may have variants, using a second keyword immediately after 371 the first to indicate which variant is required. The only such 372 commands in this specification are LIST and MODE. 374 Keywords are case-insensitive; the case of keywords for commands MUST 375 be ignored by the server. Command and response parameters are case 376 or language specific only when specified (either in this document or 377 in RFC 1036 [6]). 379 An NNTP server MUST implement all the commands in this specification 380 except for those marked as optional and those in extensions. 382 Each response MUST start with a three-digit response code that is 383 sufficient to distinguish all responses. Certain valid responses are 384 defined to be multi-line; for all others, the response is contained 385 in a single line. 387 OUTSTANDING ISSUE 389 Should the initial response line be limited to 512 octets as well? 390 Possible text: 392 The first or only line of the response MUST NOT exceed 512 octets, 393 which includes the response code and the terminating US-ASCII CRLF 394 pair. 396 The text further down about "does not place any limit on the 397 length" would need equivalent edits. 399 All multi-line responses MUST adhere to the following format: 401 1. The response consists of a sequence of one or more "lines", each 402 being a stream of octets ending with 0x0D 0x0A (US-ASCII CRLF). 403 Apart from those line endings, the stream MUST NOT include the 404 octets 0x00, 0x0A, or 0x0D (US-ASCII NUL, LF, and CR). 406 2. The first such line contains the response code as with a single 407 line response. 409 3. If any subsequent line begins with the "termination octet" (0x2E 410 or US_ASCII "."), that line MUST be "byte-stuffed" by pre-pending 411 an additional termination octet (0x2E) to that line of the 412 response. 414 4. The lines of the response MUST be followed by a terminating line 415 consisting of a single termination octet (0x2E or US_ASCII ".") 416 followed by CRLF in the normal way. Thus a multi-line response 417 is always terminated with the five octets CRLF "." CRLF (in 418 US-ASCII). 420 5. When interpreting a multi-line response, the "byte stuffing" MUST 421 be undone; i.e. the client MUST ensure that, in any line 422 beginning with the termination octet followed by octets other 423 than US-ASCII CRLF, that initial termination octet is 424 disregarded. 426 6. Likewise, the terminating line "." CRLF (in US-ASCII) MUST NOT be 427 considered part of the multi-line response; i.e. the client MUST 428 ensure that any line beginning with the termination octet 429 followed immediately by US-ASCII CRLF is disregarded; (the first 430 CRLF of the terminating CRLF "." CRLF is, of course, part of the 431 last line of the response). 433 Note that texts using an encoding (such as UTF-16 or UTF-32) that may 434 contain the NUL octet or the CR or LF octets in contexts other than 435 the CRLF line ending cannot be reliably conveyed in the above format. 437 This document does not place any limit on the length of a line. 438 However, the standards that define the format of articles may do so. 440 An NNTP server MAY have an inactivity autologout timer. Such a timer 441 SHOULD be of at least three minutes duration, with the exception that 442 there MAY be a shorter limit on how long the server is willing to 443 wait for the first command from the client. The receipt of any 444 command from the client during the timer interval SHOULD suffice to 445 reset the autologout timer. Similarly, the receipt of any 446 significant amount of data from the client while in the midst of 447 sending a multi-line message to the server (such as during a POST or 448 IHAVE command) SHOULD suffice to reset the autologout timer. When 449 the timer expires, the server SHOULD close the TCP connection without 450 sending any response to the client, including when the client is in 451 the middle of sending a multi-line message to the server. 453 3.1 Response Codes 455 Each response MUST begin with a three-digit status indicator. These 456 are status reports from the server and indicate the response to the 457 last command received from the client. 459 The first digit of the response broadly indicates the success, 460 failure, or progress of the previous command. 462 1xx - Informative message. 463 2xx - Command completed OK. 464 3xx - Command OK so far; send the rest of it. 465 4xx - Command was correct, but couldn't be performed for some 466 reason. 467 5xx - Command unimplemented, or incorrect, or a serious program 468 error occurred. 470 The next digit in the code indicates the function response category. 472 x0x - Connection, setup, and miscellaneous messages 473 x1x - Newsgroup selection 474 x2x - Article selection 475 x3x - Distribution functions 476 x4x - Posting 477 x8x - Reserved for authentication and authorization extensions 478 x9x - Reserved for private use (non-standard extensions) 480 Certain responses contain parameters such as numbers and names in 481 addition to the status indicator. In those cases, to simplify 482 interpretation by the client the number and type of such parameters 483 is fixed for each response code, as is whether or not the code 484 introduces a multi-line response. Any extension MUST follow this 485 principle as well, but note that, for historical reasons, the 211 486 response code is an exception to this. In all other cases, the 487 client MUST only use the status indicator itself to determine the 488 nature of the response. The exact response codes that can be 489 returned by any given command are detailed in the description of that 490 command. 492 Parameters MUST be separated from the numeric status indicator and 493 from each other by a single US-ASCII space. All numeric parameters 494 MUST be in base 10 (decimal) format, and MAY have leading zeros. 495 String parameters MUST contain at least one character and MUST NOT 496 contain US-ASCII spaces, CR, LF, or tab. The server MAY add any text 497 after the response code or last parameter as appropriate, and the 498 client MUST NOT make decisions based on this text. Such text MUST be 499 separated from the numeric status indicator or the last parameter by 500 at least one US-ASCII space. 502 The server MUST respond to any command with the appropriate generic 503 response (given in Section 3.1.1) if it represents the situation. 504 Otherwise, each recognized command MUST return one of the response 505 codes specifically listed in its description or in an extension. A 506 server MAY provide extensions to this specification, including new 507 commands, new variants or features of existing commands, and other 508 ways of changing the internal state of the server. However, the 509 server MUST NOT produce any other responses to a client that does not 510 invoke any of the additional features. (Therefore a client that 511 restricts itself to this specification will only receive the 512 responses that are listed.) 514 If a client receives an unexpected response, it SHOULD use the first 515 digit of the response to determine the result. For example, an 516 unexpected 2xx should be taken as success and an unexpected 4xx or 517 5xx as failure. 519 Response codes not specified in this document MAY be used for any 520 installation-specific additional commands also not specified. These 521 SHOULD be chosen to fit the pattern of x9x specified above. 523 Neither this document nor any extension registered with IANA (see 524 Section 10) will specify any response codes of the x9x pattern. 525 (Implementers of extensions are accordingly cautioned not to use such 526 responses for extensions that may subsequently be submitted for 527 registration.) 529 3.1.1 Generic Response Codes 531 The server MUST respond to any command with the appropriate one of 532 the following generic responses if it represents the situation. 534 If the command is not recognized, or it is an optional command or 535 extension that is not implemented by the server, the response code 536 500 MUST be returned. 538 If there is a syntax error in the arguments of a recognized command, 539 including the case where more arguments are provided than the command 540 specifies, the response code 501 MUST be returned. Note that where a 541 command has variants depending on a second keyword (e.g. LIST ACTIVE 542 and LIST NEWSGROUPS), then 501 MUST be used when the requested 543 variant is not implemented but the base command is. 545 If the client is not authorized to use the specified facility when 546 the server is in its current state, the response code 502 MUST be 547 returned. A different command might change the server state and 548 permit the command if it is retried. 550 If the server does not provide an optional feature, then the response 551 code 403 MUST be returned if the omission is temporary (e.g. because 552 a necessary facility is unavailable) and the code 503 if it is 553 permanent (e.g. because the server does not store the required 554 information). 556 OUTSTANDING ISSUE 558 Is anyone aware of a server that implements 403, or is it an 559 invention of our own? If the latter, do we want to keep it? INN 560 apparently uses 503 for temporary errors; someone suggested adding 561 the text: 563 If the server encounters an unexpected internal error that 564 prevents it from completing a command, the response code 503 565 MAY be returned. 567 Some servers return 503 for things like "can't contact a posting 568 server" or "can't execute external authenticator". 570 OUTSTANDING ISSUE 572 The 503 response seems to have three separate meanings: 574 1. LIST ACTIVE.TIMES etc. use it for "this data isn't stored". 575 HDR uses it for "this header can't be requested", which is 576 consistent. Are there other commands that can reasonably 577 return such a thing? If not, is this kind of 503 really a 578 generic response? 580 2. Temporary errors, the kind that 403 is supposed to represent. 582 3. It's apparently returned by LIST EXTENSIONS, but what does it 583 mean in this case? Not "there are no extensions", because 584 that's 402. Is this also an invention of our own? Again, 585 would a different code be better? 587 If the server has to terminate the connection for some reason, it 588 MUST give a 400 response code to the next command and then 589 immediately close the TCP connection. It MAY give a 401 response 590 code to any command to indicate that termination is imminent 591 (following a 401 response, it MUST NOT close the TCP connection 592 immediately). 594 OUTSTANDING ISSUE 596 Since the 401 doesn't terminate the session, what about commands 597 that change the status? For example, if GROUP returns 401 what 598 happens to the current selected newsgroup. 600 With the exception of mandatory commands and the 500 response, the 601 client MUST be prepared to receive any of these responses for any 602 command. 604 3.1.1.1 Examples 606 Example of an unknown command: 608 [C] MAIL 609 [S] 500 Unknown command 611 Example of an unsupported extension: 613 [C] LIST EXTENSIONS 614 [S] 202 Extensions supported: 615 [S] LISTGROUP 616 [S] . 617 [C] OVER 618 [S] 500 Unknown command 620 Example of an unsupported variant: 622 [C] MODE POSTER 623 [S] 501 Unknown MODE option 625 Example of a syntax error: 627 [C] ARTICLE a.message.id@no.angle.brackets 628 [S] 501 Syntax error 630 Example of an overlong command line: 632 [C] HEAD 53 54 55 633 [S] 501 Too many arguments 635 Example of a bad wildmat: 637 [C] LIST ACTIVE u[ks].* 638 [S] 501 Syntax error 640 Example of an attempt to access a restricted facility: 642 [C] GROUP secret.group 643 [S] 502 Permission denied 645 followed by a successful attempt following authentication: 647 [C] XSECRET fred flintstone 648 [S] 290 Password for fred accepted. 649 [C] GROUP secret.group 650 [S] 211 5 1 20 secret.group selected 652 Example of a temporary failure: 654 [C] GROUP archive.local 655 [S] 403 Archive server temporarily offline 657 Example of the server needing to close down immediately: 659 [C] ARTICLE 123 660 [S] 400 Power supply failed, running on UPS 661 [Server closes connection.] 663 Example of imminent termination of the server: 665 [C] STAT 123 666 [S] 401 Pre-payment expired, you have 10 seconds 667 [C] STAT 123 668 [S] 423 No such article number in this group 669 [C] NEXT 670 [S] 400 Time expired 671 [Server closes connection.] 673 3.2 Pipelining 675 NNTP is designed to operate over a reliable bi-directional connection 676 such as TCP. Therefore, if a command does not depend on the response 677 to the previous one, it should not matter if it is sent before that 678 response is received. Doing this is called "pipelining". However, 679 certain server implementations throw away all text received from the 680 client following certain commands before sending their response. If 681 this happens, pipelining will be affected because one or more 682 commands will have been ignored or misinterpreted, and the client 683 will be matching the wrong responses to each command. Since there 684 are significant benefits to pipelining, but also circumstances where 685 it is reasonable or common for servers to behave in the above manner, 686 this document puts certain requirements on both clients and servers. 688 Except where stated otherwise, a client MAY use pipelining. That is, 689 it may send a command before receiving the response for the previous 690 command. The server MUST allow pipelining and MUST NOT throw away 691 any text received after a command. Irrespective of whether or not 692 pipelining is used, the server MUST process commands in the order 693 they are sent. 695 If the specific description of a command say it "MUST NOT be 696 pipelined", that command MUST end any pipeline of commands. That is, 697 the client MUST NOT send any following command until receiving the 698 CRLF at the end of the response from the command. The server MAY 699 ignore any data received after the command and before the CRLF at the 700 end of the response is sent to the client. 702 The initial connection must not be part of a pipeline; that is, the 703 client MUST NOT send any command until receiving the CRLF at the end 704 of the greeting. 706 If the client uses blocking system calls to send commands, it MUST 707 ensure that the amount of text sent in pipelining does not cause a 708 deadlock between transmission and reception. The amount of text 709 involved will depend on window sizes in the transmission layer, and 710 is typically 4k octets for TCP. 712 3.2.1 Examples 714 Example of correct use of pipelining: 716 [C] GROUP misc.test 717 [C] STAT 718 [C] NEXT 719 [S] 211 1234 3000234 3002322 misc.test 720 [S] 223 3000234 <45223423@example.com> retrieved 721 [S] 223 3000237 <668929@example.org> retrieved 723 Example of incorrect use of pipelining (the LIST EXTENSIONS command 724 may not be pipelined): 726 [C] GROUP misc.test 727 [C] LIST EXTENSIONS 728 [C] DATE 729 [C] NEXT 730 [S] 211 1234 3000234 3002322 misc.test 731 [S] 402 server has no extensions 732 [S] 223 3000237 <668929@example.org> retrieved 734 The DATE command has been thrown away by the server and so there is 735 no 111 response to match it. 737 4. The WILDMAT format 739 The WILDMAT format described here is based on the version first 740 developed by Rich Salz [11], which in turn was derived from the 741 format used in the UNIX "find" command to articulate file names. It 742 was developed to provide a uniform mechanism for matching patterns in 743 the same manner that the UNIX shell matches filenames. 745 4.1 Wildmat syntax 747 A wildmat is described by the following augmented BNF [5] syntax 748 (note that this syntax contains ambiguities and special cases 749 described at the end): 751 wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) 753 wildmat-pattern = 1*wildmat-item 755 wildmat-item = wildmat-exact / wildmat-wild 757 wildmat-exact = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / 758 UTF-8-non-ascii ; exclude * , ? [ \ ] 760 wildmat-wild = "*" / "?" 762 UTF-8-non-ascii is defined in Section 11 764 This syntax must be interpreted subject to the following rule: 766 Where a wildmat-pattern is not immediately preceded by "!", it shall 767 not begin with a "!". 769 Note: the characters \ , [ and ] are not allowed in wildmats, while * 770 and ? are always wildcards. This should not be a problem since these 771 characters cannot occur in newsgroup names, which is the only current 772 use of wildmats. Backslash is commonly used to supress the special 773 meaning of characters and brackets to introduce sets, but there is no 774 existing standard practice for these in wildmats and so they were 775 omitted from this specification. A future extension to this 776 specification may provide semantics for these characters. 778 4.2 Wildmat semantics 780 A wildmat is tested against a string, and either matches or does not 781 match. To do this, each constituent wildmat-pattern is matched 782 against the string and the rightmost pattern that matches is 783 identified. If that wildmat-pattern is not preceded with "!", the 784 whole wildmat matches. If it is preceded by "!", or if no 785 wildmat-pattern matches, the whole wildmat does not match. 787 For example, consider the wildmat "a*,!*b,*c*": 789 the string "aaa" matches because the rightmost match is with "a*" 791 the string "abb" does not match because the rightmost match is 792 with "*b" 794 the string "ccb" matches because the rightmost match is with "*c*" 796 the string "xxx" does not match because no wildmat-pattern matches 798 A wildmat-pattern matches a string if the string can be broken into 799 components, each of which matches the corresponding wildmat-item in 800 the pattern; the matches must be in the same order, and the whole 801 string must be used in the match. The pattern is "anchored"; that 802 is, the first and last characters in the string must match the first 803 and last item respectively (unless that item is an asterisk matching 804 zero characters). 806 A wildmat-exact matches the same character (which may be more than 807 one octet in UTF-8). 809 "?" matches exactly one character (which may be more than one octet). 811 "*" matches zero or more characters. It can match an empty string, 812 but it cannot match a subsequence of a UTF-8 sequence that is not 813 aligned to the character boundaries. 815 4.3 Extensions 817 An NNTP server or extension MAY extend the syntax or semantics of 818 wildmats provided that all wildmats that meet the requirements of 819 Section 4.1 have the meaning ascribed to them by Section 4.2. Future 820 editions of this document may also extend wildmats. 822 4.4 Examples 824 In these examples, $ and @ are used to represent the two octets 0xC2 825 and 0xA3 respectively; $@ is thus the UTF-8 encoding for the pound 826 sterling symbol, shown as # in the descriptions. 828 Wildmat Description of strings that match 829 abc the one string "abc" 830 abc,def the two strings "abc" and "def" 831 $@ the one character string "#" 832 a* any string that begins with "a" 833 a*b any string that begins with "a" and ends with "b" 834 a*,*b any string that begins with "a" or ends with "b" 835 a*,!*b any string that begins with "a" and does not end with 836 "b" 837 a*,!*b,c* any string that begins with "a" and does not end with 838 "b", and any string that begins with "c" no matter 839 what it ends with 840 a*,c*,!*b any string that begins with "a" or "c" and does not 841 end with "b" 842 ?a* any string with "a" as its second character 843 ??a* any string with "a" as its third character 844 *a? any string with "a" as its penultimate character 845 *a?? any string with "a" as its antepenultimate character 847 5. The GREETING Step 849 5.1 Initial Connection 851 5.1.1 Usage 853 Responses 854 200 Service available, posting allowed 855 201 Service available, posting prohibited 856 400 Service temporarily unavailable [1] 857 502 Service permanently unavailable [1] 859 These are the only valid response codes for the initial greeting; 860 the server MUST not return any other generic response code. 862 [1] Following a 400 or 502 response the server MUST immediately close 863 the connection. 865 5.1.2 Description 867 There is no command presented by the client upon initial connection 868 to the server. The server MUST present an appropriate response code 869 as a greeting to the client. This response informs the client about 870 what steps the client should take to reach the news exchange step. 872 If the server will accept further commands from the client including 873 POST, the server MUST present a 200 greeting code. If the server 874 will accept further commands from the client, but it is not 875 authorized to post articles using the POST command, the server MUST 876 present a 201 greeting code. 878 Otherwise the server MUST present a 400 or 502 greeting code and then 879 immediately close the connection. 502 MUST be used if the client is 880 not permitted under any circumstances to interact with the server and 881 400 otherwise. 883 5.1.3 Examples 885 Example of a normal connection from an authorized client which then 886 jumps directly to the conclusion step (see Section 9): 888 [Initial TCP connection setup completed.] 889 [S] 200 NNTP Service Ready, posting permitted 890 [C] QUIT 891 [S] 205 NNTP Service exits normally 892 [Server closes connection.] 894 Example of a normal connection from an authorized client that is not 895 permitted to post; it also jumps directly to the conclusion step: 897 [Initial TCP connection setup completed.] 898 [S] 201 NNTP Service Ready, posting prohibited 899 [C] QUIT 900 [S] 205 NNTP Service exits normally 901 [Server closes connection.] 903 Example of a normal connection from an unauthorized client: 905 [Initial TCP connection setup completed.] 906 [S] 502 NNTP Service permanently unavailable 907 [Server closes connection.] 909 Example of a connection from a client where the server is unable to 910 provide service: 912 [Initial TCP connection setup completed.] 913 [S] 400 NNTP Service temporarily unavailable 914 [Server closes connection.] 916 5.2 MODE READER 918 5.2.1 Usage 920 This command MUST NOT be pipelined. 922 Syntax 923 MODE READER 925 Responses 926 200 Posting allowed 927 201 Posting prohibited 928 400 Service temporarily unavailable [1] 929 502 Service permanently unavailable [1] 931 [1] Following a 400 or 502 response the server MUST immediately close 932 the connection. 934 5.2.2 Description 936 MODE READER SHOULD be sent by any client that intends to use any 937 command other than IHAVE, HEAD, STAT, LIST ACTIVE, LIST EXTENSIONS, 938 or commands advertised by the server as available via LIST 939 EXTENSIONS. 941 Servers MAY require that this command be issued before any other 942 commands are sent and MAY reject any other commands until after a 943 MODE READER command has been sent. 945 The server MUST return a response using the same codes as the initial 946 greeting (as described in Section 5.1.1) to indicate its ability to 947 provide reading service to the client. Note that the response need 948 not be the same as the one presented during the initial greeting. 950 Once MODE READER is sent, IHAVE (and any extensions intended for 951 peer-to-peer article transfer) MAY no longer be permitted, even if it 952 were permitted before the MODE READER command. The results of LIST 953 EXTENSIONS MAY be different following a MODE READER command than 954 prior to the issuing of that command. 956 Servers are encouraged to not require this command even though 957 clients SHOULD send it when appropriate. It is present to support 958 some news architectures that switch between modes based on whether a 959 given connection is a peer-to-peer connection with another server or 960 a news reading client. 962 5.2.3 Examples 964 Example of use of the MODE READER command by an authorized client 965 which then jumps directly to the conclusion step (see Section 9): 967 [C] MODE READER 968 [S] 200 NNTP Service Ready, posting permitted 969 [C] QUIT 970 [S] 205 NNTP Service exits normally 971 [Server closes connection.] 973 Example of use of the MODE READER command by an authorized client 974 that is not permitted to post; it also jumps directly to the 975 conclusion step: 977 [C] MODE READER 978 [S] 201 NNTP Service Ready, posting prohibited 979 [C] QUIT 980 [S] 205 NNTP Service exits normally 981 [Server closes connection.] 983 Example of use of MODE READER by a client not authorized to receive 984 service from the server as a news reader: 986 [C] MODE READER 987 [S] 502 NNTP Service permanently unavailable 988 [Server closes connection.] 990 Example of a connection from any client where the server is unable to 991 provide news reader service: 993 [C] QUIT 994 [S] 400 NNTP Service temporarily unavailable 995 [Server closes connection.] 997 6. The CAPABILITIES DISCOVERY step 999 To discover what extensions are available, an NNTP client can query 1000 the server with the LIST EXTENSIONS command. If a particular 1001 extension is unavailable, the client can attempt to work around it or 1002 it may wish to terminate the session. 1004 See Section 10 for further discussion of extensions. 1006 6.1 LIST EXTENSIONS 1008 6.1.1 Usage 1010 This command is optional. 1012 This command MUST NOT be pipelined. 1014 Syntax 1015 LIST EXTENSIONS 1017 Responses 1018 202 Extension list follows (multiline) 1019 402 Server has no extensions 1020 503 Extension information not available 1022 6.1.2 Description 1024 The LIST EXTENSIONS command allows a client to determine which 1025 extensions are supported by the server. This command MUST be 1026 implemented by any server that implements any extensions defined in 1027 this document. 1029 To discover what extensions are available, an NNTP client SHOULD 1030 query the server early in the session for extensions information by 1031 issuing the LIST EXTENSIONS command. This command MAY be issued at 1032 anytime during a session. It is not required that the client issues 1033 this command before attempting to make use of any extension. The 1034 response generated by this command MAY change during a session 1035 because of other state information. However, an NNTP client MUST NOT 1036 cache (for use in another session) any information returned if the 1037 LIST EXTENSIONS command succeeds. That is, an NNTP client is only 1038 able to get the current and correct information concerning available 1039 extensions during a session by issuing a LIST EXTENSIONS command 1040 during that session and processing that response. 1042 The list of extensions is returned as a multi-line response following 1043 the 202 response code. Each extension is listed on a separate line; 1044 the line MUST begin with an extension-label and optionally one or 1045 more parameters (separated by single spaces). The extension-label 1046 and the meaning of the parameters are specified as part of the 1047 definition of the extension. The extension-label MUST be in 1048 uppercase. 1050 The server MUST NOT list the same extension twice in the response, 1051 and MUST list all supported extensions. The order in which the 1052 extensions are listed is not significant. The server need not even 1053 consistently return the same order. If the server does not support 1054 any extensions, a 402 response SHOULD be returned, but it MAY instead 1055 return an empty list. 1057 Following a 503 response an extension might still be available, and 1058 the client MAY attempt to use it. 1060 6.1.3 Examples 1062 Example of a successful response: 1064 [C] LIST EXTENSIONS 1065 [S] 202 Extensions supported: 1066 [S] OVER 1067 [S] HDR 1068 [S] LISTGROUP 1069 [S] . 1071 The particular extensions shown here are simply examples of what 1072 might be defined in other places, and no particular meaning should be 1073 attributed to them. 1075 Example where no extensions are available, using preferred format: 1077 [C] LIST EXTENSIONS 1078 [S] 402 Server has no extensions 1080 Example where no extensions are available, using an empty list: 1082 [C] LIST EXTENSIONS 1083 [S] 202 Extensions supported: 1084 [S] . 1086 7. Article posting and retrieval 1088 News reading clients have available a variety of mechanisms to 1089 retrieve articles via NNTP. The news articles are stored and indexed 1090 using three types of keys. One key is the message-id of an article. 1091 According to RFC 1036, this identifier should be globally unique. 1092 Another key is composed of the newsgroup name and the article number 1093 within that newsgroup. That key MUST be unique to a particular 1094 server (there will be only one article with that number within a 1095 particular newsgroup), but is not required to be globally unique. 1096 Additionally, because the same article can be cross-posted to 1097 multiple newsgroups, there may be multiple keys that point to the 1098 same article on the same server. The final key is the arrival 1099 timestamp, giving the time that the article arrived at the server. 1101 The server MUST ensure that article numbers are issued in order of 1102 arrival timestamp; that is, articles arriving later MUST have higher 1103 numbers than those that arrive earlier. The server SHOULD allocate 1104 the next sequential unused number to each new article. 1106 Article numbers MUST lie between 1 and 4,294,967,295 inclusive. The 1107 client and server SHOULD NOT use leading zeroes in specifying article 1108 numbers, and MUST NOT use more than 16 digits. In some situations, 1109 the value zero replaces an article number to show some special 1110 situation. 1112 Message-ids are as defined in RFC 2822 [7] with the following 1113 modifications: 1115 o A message-id MUST NOT contain a US-ASCII space within any 1116 quoted-pair. 1118 o A message-id MUST NOT be longer than 250 octets. 1120 o RFC 2822 obsolete syntax for message-ids is not supported by the 1121 protocol specified in this document. 1123 7.1 Group and article selection 1125 The following commands are used to set the "current selected 1126 newsgroup" and the "current article number", which are used by 1127 various commands. At the start of an NNTP session, both of these 1128 values are set to the special value "invalid". 1130 7.1.1 GROUP 1131 7.1.1.1 Usage 1133 Syntax 1134 GROUP ggg 1136 Responses 1137 211 n l h ggg Group successfully selected 1138 411 No such newsgroup 1140 Parameters 1141 ggg = name of newsgroup 1142 n = estimated number of articles in the group 1143 l = reported low water mark 1144 h = reported high water mark 1146 7.1.1.2 Description 1148 The required parameter ggg is the name of the newsgroup to be 1149 selected (e.g. "news.software.b"). A list of valid newsgroups may 1150 be obtained by using the LIST ACTIVE command (see Section 8.6.1). 1152 The successful selection response will return the article numbers of 1153 the first and last articles in the group at the moment of selection 1154 (these numbers are referred to as the "reported low water mark" and 1155 the "reported high water mark"), and an estimate of the number of 1156 articles on file in the group. 1158 If the group is not empty, the estimate MUST be at least the actual 1159 number of articles available, and MUST be no greater than one more 1160 than the difference between the reported low and high water marks. 1161 (Some implementations will actually count the number of articles on 1162 file. Others will just subtract the low water mark from the high 1163 water mark and add one to get an estimate.) 1165 If the group is empty, one of the following three situations will 1166 occur. Clients MUST accept all three cases; servers MUST NOT 1167 represent an empty group in any other way. 1169 o The high water mark will be one less than the low water mark, and 1170 the estimated article count will be zero. Servers SHOULD use this 1171 method to show an empty group. This is the only time that the 1172 high water mark can be less than the low water mark. 1174 o All three numbers will be zero. 1176 o The high water mark is greater than or equal to the low water 1177 mark. The estimated article count might be zero or non-zero; if 1178 non-zero, the same requirements apply as for a non-empty group. 1180 The set of articles in a group may change after the GROUP command is 1181 carried out. That is: 1183 o articles may be removed from the group 1185 o articles may be reinstated in the group with the same article 1186 number, but those articles MUST have numbers no less than the 1187 reported low water mark (note that this is a reinstatement of the 1188 previous article, not a new article reusing the number) 1190 o new articles may be added with article numbers greater than the 1191 reported high water mark (if an article that was the one with the 1192 highest number has been removed, the next new article will not 1193 have the number one greater than the reported high water mark) 1195 Except when the group is empty and all three numbers are zero, 1196 whenever a subsequent GROUP command for the same newsgroup is issued, 1197 either by the same client or a different client, the reported low 1198 water mark in the response MUST be no less than that in any previous 1199 response for that newsgroup sent to any client. The client may make 1200 use of the low water mark to remove all remembered information about 1201 articles with lower numbers, as these will never recur. This 1202 includes the situation when the high water mark is one less than the 1203 low water mark. 1205 No similar assumption can be made about the high water mark, as this 1206 can decrease if an article is removed, and then increase again if it 1207 is reinstated or if new articles arrive. When a valid group is 1208 selected by means of this command, the current selected newsgroup 1209 MUST be set to that group and the current article number MUST be set 1210 to the first article in the group. If an empty newsgroup is 1211 selected, the current article pointer is made invalid. If an invalid 1212 group is specified, the current selected newsgroup and current 1213 article number MUST NOT be changed. 1215 The GROUP command (or the LISTGROUP command, if implemented) MUST be 1216 used by a client and a successful response received before the any 1217 other command is used that depends on the value of the current 1218 selected newsgroup or current article number. 1220 If the group specified is not available on the server, a 411 response 1221 MUST be returned. 1223 7.1.1.3 Examples 1225 Example for a group known to the server: 1227 [C] GROUP misc.test 1228 [S] 211 1234 3000234 3002322 misc.test 1230 Example for a group unknown to the server: 1232 [C] GROUP example.is.sob.bradner.or.barber 1233 [S] 411 example.is.sob.bradner.or.barber is unknown 1235 Example of an empty group using the preferred response: 1237 [C] GROUP example.currently.empty.newsgroup 1238 [S] 211 0 4000 3999 example.currently.empty.newsgroup 1240 Example of an empty group using an alternative response: 1242 [C] GROUP example.currently.empty.newsgroup 1243 [S] 211 0 0 0 example.currently.empty.newsgroup 1245 Example of an empty group using a different alternative response: 1247 [C] GROUP example.currently.empty.newsgroup 1248 [S] 211 0 4000 4321 example.currently.empty.newsgroup 1250 7.1.2 LAST 1252 7.1.2.1 Usage 1254 Syntax 1255 LAST 1257 Responses 1258 223 n message-id Article found 1259 412 No newsgroup selected 1260 420 Current article number is invalid 1261 422 No previous article in this group 1263 Parameters 1264 n = article number 1265 message-id = article message-id 1267 7.1.2.2 Description 1269 If the current selected newsgroup is valid, the current article 1270 number MUST be set to the previous article in that newsgroup (that 1271 is, the highest existing article number less than the current article 1272 number). If successful, a response indicating the new current 1273 article number and the message-id of that article MUST be returned. 1274 No article text is sent in response to this command. 1276 There MAY be no previous article in the group, although the current 1277 article number is not the reported low water mark. There MUST NOT be 1278 a previous article when the current article number is the reported 1279 low water mark. 1281 Because articles can be removed and added, the results of multiple 1282 LAST and NEXT commands MAY not be consistent over the life of a 1283 particular NNTP session. 1285 If the current article number is already the first article of the 1286 newsgroup, a 422 response MUST be returned. If the current article 1287 number is invalid, a 420 response MUST be returned. If the current 1288 selected newsgroup is invalid, a 412 response MUST be returned. In 1289 all three cases the current selected newsgroup and current article 1290 number MUST NOT be altered. 1292 7.1.2.3 Examples 1294 Example of a successful article retrieval using LAST: 1296 [C] GROUP misc.test 1297 [S] 211 1234 3000234 3002322 misc.test 1298 [C] NEXT 1299 [S] 223 3000237 <668929@example.org> retrieved 1300 [C] LAST 1301 [S] 223 3000234 <45223423@example.com> retrieved 1303 Example of an attempt to retrieve an article without having selected 1304 a group (via the GROUP command) first: 1306 [Assumes current selected newsgroup is invalid.] 1307 [C] LAST 1308 [S] 412 no newsgroup selected 1310 Example of an attempt to retrieve an article using the LAST command 1311 when the current article number is that of the first article in the 1312 group: 1314 [C] GROUP misc.test 1315 [S] 211 1234 3000234 3002322 misc.test 1316 [C] LAST 1317 [S] 422 No previous article to retrieve 1319 Example of an attempt to retrieve an article using the LAST command 1320 when the current selected newsgroup is empty: 1322 [C] GROUP example.empty.newsgroup 1323 [S] 211 0 0 0 example.empty.newsgroup 1324 [C] LAST 1325 [S] 420 No current article selected 1327 7.1.3 NEXT 1329 7.1.3.1 Usage 1331 Syntax 1332 NEXT 1334 Responses 1335 223 n message-id Article found 1336 412 No newsgroup selected 1337 420 Current article number is invalid 1338 421 No next article in this group 1340 Parameters 1341 n = article number 1342 message-id = article message-id 1344 7.1.3.2 Description 1346 If the current selected newsgroup is valid, the current article 1347 number MUST be set to the next article in that newsgroup (that is, 1348 the lowest existing article number greater than the current article 1349 number). If successful, a response indicating the new current 1350 article number and the message-id of that article MUST be returned. 1351 No article text is sent in response to this command. 1353 If the current article number is already the last article of the 1354 newsgroup, a 421 response MUST be returned. In all other aspects 1355 (apart, of course, from the lack of 422 response) this command is 1356 identical to the LAST command (Section 7.1.2). 1358 7.1.3.3 Examples 1360 Example of a successful article retrieval using NEXT: 1362 [C] GROUP misc.test 1363 [S] 211 1234 3000234 3002322 misc.test 1364 [C] NEXT 1365 [S] 223 3000237 <668929@example.org> retrieved 1367 Example of an attempt to retrieve an article without having selected 1368 a group (via the GROUP command) first: 1370 [Assumes current selected newsgroup is invalid.] 1371 [C] NEXT 1372 [S] 412 no newsgroup selected 1374 Example of an attempt to retrieve an article using the NEXT command 1375 when the current article number is that of the last article in the 1376 group: 1378 [C] GROUP misc.test 1379 [S] 211 1234 3000234 3002322 misc.test 1380 [C] STAT 3002322 1381 [S] 223 3002322 <411@example.net> retrieved 1382 [C] NEXT 1383 [S] 421 No next article to retrieve 1385 Example of an attempt to retrieve an article using the NEXT command 1386 when the current selected newsgroup is empty: 1388 [C] GROUP example.empty.newsgroup 1389 [S] 211 0 0 0 example.empty.newsgroup 1390 [C] NEXT 1391 [S] 420 No current article selected 1393 7.2 Retrieval of articles and article sections 1395 The ARTICLE, BODY, HEAD, and STAT commands are very similar. They 1396 differ only in the parts of the article that are presented to the 1397 client and in the successful response code. The ARTICLE command is 1398 described here in full, while the other commands are described in 1399 terms of the differences. An article, as defined by RFC 1036, 1400 consists of two parts: the article headers and the article body. 1401 When responding to one of these commands, the server presents the 1402 entire article or appropriate part and does not attempt to alter or 1403 translate it in any way. 1405 7.2.1 ARTICLE 1407 7.2.1.1 Usage 1409 Syntax 1410 ARTICLE message-id 1411 ARTICLE [number] 1413 Responses 1415 First form (message-id specified) 1416 220 0 message-id Article follows (multiline) 1417 430 No article found with that message-id 1419 Second form (optional article number specified) 1420 220 n message-id Article follows (multiline) 1421 412 No newsgroup selected 1422 420 Current article number is invalid [1] 1423 423 No such article in this newsgroup 1425 Parameters 1426 number = Requested article number 1427 n = Returned article number 1428 message-id = Article message-id 1430 [1] The 420 response can only occur if no article number has been 1431 specified. 1433 7.2.1.2 Description 1435 The ARTICLE command selects an article based on the arguments and 1436 presents the header, a blank line, and the body of that article. The 1437 command has two forms. 1439 In the first form, a message-id is specified (including the angle 1440 brackets), and the server presents the article with that message-id 1441 in its headers. In this case, the server MUST NOT alter the current 1442 selected newsgroup or current article number. This is both to 1443 facilitate the presentation of articles that may be referenced within 1444 another article being read, and because of the semantic difficulties 1445 of determining the proper sequence and membership of an article that 1446 may have been crossposted to more than one newsgroup. 1448 In the response, the article number is replaced with zero (that is, 1449 the server is not required to determine whether the article is in the 1450 current group or what article number(s) it has). 1452 In the second form, an article number may be specified. If so, and 1453 if there is an article with that number in the currently selected 1454 newsgroup, the server MUST set the current article number to that 1455 number. 1457 Then, whether or not a number was specified, the article indicated by 1458 the current article number is presented to the client. 1460 Note that a previously valid article number MAY become invalid if the 1461 article has been removed. A previously invalid article number MAY 1462 become valid if the article has been reinstated, but such an article 1463 number MUST be no less than the reported low water mark for that 1464 group. 1466 The server MUST NOT change the current selected newsgroup as a result 1467 of this command. The server MUST NOT change the current article 1468 number except when an article number argument was provided and the 1469 article exists; in particular, it MUST NOT change it following an 1470 unsuccessful response. 1472 The message-id of the article is taken from the message-id header 1473 line of the article (required by RFC 1036). If there is no such 1474 line, the message-id "<0>" MUST be used instead (without the double 1475 quotes). 1477 Since the message-id field is unique for each article, it may be used 1478 by a client to skip duplicate displays of articles that have been 1479 posted more than once, or to more than one newsgroup. 1481 The article headers and body are returned as a multi-line response 1482 following the 220 response code. 1484 If the current article number is invalid, a 420 response MUST be 1485 returned. If there is no article with the specified number, a 423 1486 response MUST be returned. If the current selected newsgroup is 1487 invalid, a 412 response MUST be returned. 1489 7.2.1.3 Examples 1491 Example of a successful retrieval of an article (using no article 1492 number): 1494 [C] GROUP misc.test 1495 [S] 211 1234 3000234 3002322 misc.test 1496 [C] ARTICLE 1497 [S] 220 3000234 <45223423@example.com> 1498 [S] Path: pathost!demo!whitehouse!not-for-mail 1499 [S] From: "Demo User" 1500 [S] Newsgroups: misc.test 1501 [S] Subject: I am just a test article 1502 [S] Date: 6 Oct 1998 04:38:40 -0500 1503 [S] Organization: An Example Net, Uncertain, Texas 1504 [S] Message-ID: <411@example.net> 1505 [S] 1506 [S] This is just a test article. 1507 [S] . 1509 Example of a successful retrieval of an article by message-id: 1511 [C] ARTICLE <45223423@example.com> 1512 [S] 220 0 <45223423@example.com> 1513 [S] Path: pathost!demo!whitehouse!not-for-mail 1514 [S] From: "Demo User" 1515 [S] Newsgroups: misc.test 1516 [S] Subject: I am just a test article 1517 [S] Date: 6 Oct 1998 04:38:40 -0500 1518 [S] Organization: An Example Net, Uncertain, Texas 1519 [S] Message-ID: <411@example.net> 1520 [S] 1521 [S] This is just a test article. 1522 [S] . 1524 Example of an unsuccessful retrieval of an article by message-id: 1526 [C] ARTICLE 1527 [S] 430 No Such Article Found 1529 Example of an unsuccessful retrieval of an article by number: 1531 [C] GROUP misc.test 1532 [S] 211 1234 3000234 3002322 news.groups 1533 [C] ARTICLE 300256 1534 [S] 423 No such article number in this group 1536 Example of an unsuccessful retrieval of an article by number because 1537 no newsgroup was selected first: 1539 [Assumes current selected newsgroup is invalid.] 1540 [C] ARTICLE 300256 1541 [S] 412 No newsgroup selected 1543 Example of an attempt to retrieve an article when the current 1544 selected newsgroup is empty: 1546 [C] GROUP example.empty.newsgroup 1547 [S] 211 0 0 0 example.empty.newsgroup 1548 [C] ARTICLE 1549 [S] 420 No current article selected 1551 7.2.2 HEAD 1553 7.2.2.1 Usage 1554 Syntax 1555 HEAD message-id 1556 HEAD [number] 1558 Responses 1560 First form (message-id specified) 1561 221 0 message-id Headers follow (multiline) 1562 430 No article found with that message-id 1564 Second form (optional article number specified) 1565 221 n message-id Headers follow (multiline) 1566 412 No newsgroup selected 1567 420 Current article number is invalid [1] 1568 423 No such article in this newsgroup 1570 Parameters 1571 number = Requested article number 1572 n = Returned article number 1573 message-id = Article message-id 1575 [1] The 420 response can only occur if no article number has been 1576 specified. 1578 7.2.2.2 Description 1580 The HEAD command behaves identically to the ARTICLE command except 1581 that, if the article exists, the response code is 221 instead of 220 1582 and only the headers are presented (the blank line separating the 1583 headers and body MUST NOT be included). 1585 7.2.2.3 Examples 1587 Example of a successful retrieval of the headers in an article (using 1588 no article number): 1590 [C] GROUP misc.test 1591 [S] 211 1234 3000234 3002322 misc.test 1592 [C] HEAD 1593 [S] 221 3000234 <45223423@example.com> 1594 [S] Path: pathost!demo!whitehouse!not-for-mail 1595 [S] From: "Demo User" 1596 [S] Newsgroups: misc.test 1597 [S] Subject: I am just a test article 1598 [S] Date: 6 Oct 1998 04:38:40 -0500 1599 [S] Organization: An Example Net, Uncertain, Texas 1600 [S] Message-ID: <411@example.net> 1602 [S] . 1604 Example of a successful retrieval of the headers in an article by 1605 message-id: 1607 [C] HEAD <45223423@example.com> 1608 [S] 221 0 <45223423@example.com> 1609 [S] Path: pathost!demo!whitehouse!not-for-mail 1610 [S] From: "Demo User" 1611 [S] Newsgroups: misc.test 1612 [S] Subject: I am just a test article 1613 [S] Date: 6 Oct 1998 04:38:40 -0500 1614 [S] Organization: An Example Net, Uncertain, Texas 1615 [S] Message-ID: <411@example.net> 1616 [S] . 1618 Example of an unsuccessful retrieval of the header of an article by 1619 message-id: 1621 [C] HEAD 1622 [S] 430 No Such Article Found 1624 Example of an unsuccessful retrieval of the header of an article by 1625 number: 1627 [C] GROUP misc.test 1628 [S] 211 1234 3000234 3002322 misc.test 1629 [C] HEAD 300256 1630 [S] 423 No such article number in this group 1632 Example of an unsuccessful retrieval the header of an article by 1633 number because no newsgroup was selected first: 1635 [Assumes current selected newsgroup is invalid.] 1636 [C] HEAD 300256 1637 [S] 412 No newsgroup selected 1639 Example of an attempt to retrieve the header of an article when the 1640 current selected newsgroup is empty: 1642 [C] GROUP example.empty.newsgroup 1643 [S] 211 0 0 0 example.empty.newsgroup 1644 [C] HEAD 1645 [S] 420 No current article selected 1647 7.2.3 BODY 1649 7.2.3.1 Usage 1651 Syntax 1652 BODY message-id 1653 BODY [number] 1655 Responses 1657 First form (message-id specified) 1658 222 0 message-id Body follows (multiline) 1659 430 No article found with that message-id 1661 Second form (optional article number specified) 1662 222 n message-id Body follows (multiline) 1663 412 No newsgroup selected 1664 420 Current article number is invalid [1] 1665 423 No such article in this newsgroup 1667 Parameters 1668 number = Requested article number 1669 n = Returned article number 1670 message-id = Article message-id 1672 [1] The 420 response can only occur if no article number has been 1673 specified. 1675 7.2.3.2 Description 1677 The BODY command behaves identically to the ARTICLE command except 1678 that, if the article exists, the response code is 222 instead of 220 1679 and only the body is presented (the blank line separating the headers 1680 and body MUST NOT be included). 1682 7.2.3.3 Examples 1684 Example of a successful retrieval of the body of an article (using no 1685 article number): 1687 [C] GROUP misc.test 1688 [S] 211 1234 3000234 3002322 misc.test 1689 [C] BODY 1690 [S] 222 3000234 <45223423@example.com> 1691 [S] This is just a test article. 1692 [S] . 1694 Example of a successful retrieval of the body of an article by 1695 message-id: 1697 [C] BODY <45223423@example.com> 1698 [S] 222 0 <45223423@example.com> 1699 [S] This is just a test article. 1700 [S] . 1702 Example of an unsuccessful retrieval of the body of an article by 1703 message-id: 1705 [C] BODY 1706 [S] 430 No Such Article Found 1708 Example of an unsuccessful retrieval of the body of an article by 1709 number: 1711 [C] GROUP misc.test 1712 [S] 211 1234 3000234 3002322 misc.test 1713 [C] BODY 300256 1714 [S] 423 No such article number in this group 1716 Example of an unsuccessful retrieval of the body of an article by 1717 number because no newsgroup was selected first: 1719 [Assumes current selected newsgroup is invalid.] 1720 [C] BODY 300256 1721 [S] 412 No newsgroup selected 1723 Example of an attempt to retrieve the body of an article when the 1724 current selected newsgroup is empty: 1726 [C] GROUP example.empty.newsgroup 1727 [S] 211 0 0 0 example.empty.newsgroup 1728 [C] BODY 1729 [S] 420 No current article selected 1731 7.2.4 STAT 1733 7.2.4.1 Usage 1735 Syntax 1736 STAT message-id 1737 STAT [number] 1739 Responses 1741 First form (message-id specified) 1742 223 0 message-id Article exists 1743 430 No article found with that message-id 1745 Second form (optional article number specified) 1746 223 n message-id Article exists 1747 412 No newsgroup selected 1748 420 Current article number is invalid [1] 1749 423 No such article in this newsgroup 1751 Parameters 1752 number = Requested article number 1753 n = Returned article number 1754 message-id = Article message-id 1756 [1] The 420 response can only occur if no article number has been 1757 specified. 1759 7.2.4.2 Description 1761 The STAT command behaves identically to the ARTICLE command except 1762 that, if the article exists, it is NOT presented to the client and 1763 the response code is 223 instead of 220. Note that the response is 1764 NOT multi-line. 1766 This command allows the client to determine whether an article 1767 exists, and in the second form what its message-id is, without having 1768 to process an arbitrary amount of text. 1770 7.2.4.3 Examples 1772 Example of STAT on an existing article (using no article number): 1774 [C] GROUP misc.test 1775 [S] 211 1234 3000234 3002322 misc.test 1776 [C] STAT 1777 [S] 223 3000234 <45223423@example.com> 1779 Example of a STAT of an existing article by message-id: 1781 [C] STAT <45223423@example.com> 1782 [S] 223 0 <45223423@example.com> 1784 Example of an STAT of an article not on the server by message-id: 1786 [C] STAT 1787 [S] 430 No Such Article Found 1789 Example of STAT of an article not in the server by number: 1791 [C] GROUP misc.test 1792 [S] 211 1234 3000234 3002322 misc.test 1793 [C] STAT 300256 1794 [S] 423 No such article number in this group 1796 Example of STAT of an article by number when no newsgroup was 1797 selected first: 1799 [Assumes current selected newsgroup is invalid.] 1800 [C] STAT 300256 1801 [S] 412 No newsgroup selected 1803 Example of STAT of an article when the current selected newsgroup is 1804 empty: 1806 [C] GROUP example.empty.newsgroup 1807 [S] 211 0 0 0 example.empty.newsgroup 1808 [C] STAT 1809 [S] 420 No current article selected 1811 7.3 Article posting 1813 Article posting is done in one of two modes: individual article 1814 posting from news reading clients using POST, and article transfer 1815 from other news servers using IHAVE. 1817 7.3.1 POST 1819 7.3.1.1 Usage 1821 This command MUST NOT be pipelined. 1823 Syntax 1824 POST 1826 Responses 1828 Initial responses 1829 340 Send article to be posted 1830 440 Posting not permitted 1832 Subsequent responses 1833 240 Article received OK 1834 441 Posting failed 1836 7.3.1.2 Description 1838 If posting is allowed, a 340 response MUST be returned to indicate 1839 that the article to be posted should be sent. If posting is 1840 prohibited for some installation-dependent reason, a 440 response 1841 MUST be returned. 1843 If posting is permitted, the article MUST be presented to the server 1844 by the client in the format specified by RFC 1036 (or by any of its 1845 successors or extensions). The text forming the header and body of 1846 the message to be posted MUST be sent by the client in the format 1847 defined above (Section 3) for multi-line responses (except that there 1848 is no initial line containing a response code). Thus a single dot 1849 (".") on a line indicates the end of the text, and lines starting 1850 with a dot in the original text have that dot doubled during 1851 transmission. 1853 Following the presentation of the termination sequence by the client, 1854 the server MUST return a response indicating success or failure of 1855 the article transfer. Note that response codes 340 and 440 are used 1856 in direct response to the POST command. Others are returned 1857 following the sending of the article. 1859 A response of 240 SHOULD indicate that, barring unforseen server 1860 errors, the posted article will be made available on the server and/ 1861 or transferred to other servers as appropriate. In other words, 1862 articles not wanted by the server SHOULD be rejected with a 411 1863 response and not accepted and silently discarded. 1865 No attempt shall be made by the server to filter characters, fold or 1866 limit lines, or otherwise process incoming text. The intent is that 1867 the server just passes the incoming message to be posted to the 1868 server installation's news posting software, which is not defined by 1869 this document. 1871 The client SHOULD NOT assume that the article has been successfully 1872 transferred unless it receives an affirmative response from the 1873 server. If the session is interrupted before the response is 1874 received, it is possible that an affirmative response was sent but 1875 has been lost. Therefore, in any subsequent session the client 1876 SHOULD use the same message-id in the article when resending it or 1877 check whether the article was successfully posted before resending it 1878 to ensure that the resend will not result in a duplicate article. 1880 7.3.1.3 Examples 1882 Example of a successful posting: 1884 [C] POST 1885 [S] 340 Input article; end with . 1886 [C] From: "Demo User" 1887 [C] Newsgroups: misc.test 1888 [C] Subject: I am just a test article 1889 [C] Organization: An Example Net 1890 [C] 1891 [C] This is just a test article. 1892 [C] . 1893 [S] 240 Article received OK 1895 Example of an unsuccessful posting: 1897 [C] POST 1898 [S] 340 Input article; end with . 1899 [C] From: "Demo User" 1900 [C] Newsgroups: misc.test 1901 [C] Subject: I am just a test article 1902 [C] Organization: An Example Net 1903 [C] 1904 [C] This is just a test article. 1905 [C] . 1906 [S] 441 Posting failed 1908 Example of an attempt to post when posting is not allowed: 1910 [C] MODE READER 1911 [S] 201 NNTP Service Ready, posting prohibited 1912 [C] POST 1913 [S] 440 Posting not permitted 1915 7.3.2 IHAVE 1917 7.3.2.1 Usage 1919 This command MUST NOT be pipelined. 1921 Syntax 1922 IHAVE message-id 1924 Responses 1925 Initial responses 1926 335 Send article to be transferred 1927 435 Article not wanted 1928 436 Transfer not possible; try again later 1930 Subsequent responses 1931 235 Article transferred OK 1932 436 Transfer failed; try again later 1933 437 Transfer rejected; do not retry 1935 Parameters 1936 message-id = Article message-id 1938 7.3.2.2 Description 1940 The IHAVE command informs the server that the client has an article 1941 with the specified message-id. If the server desires a copy of that 1942 article a 335 response MUST be returned, instructing the client to 1943 send the entire article. If the server does not want the article 1944 (if, for example, the server already has a copy of it), a 435 1945 response MUST be returned, indicating that the article is not wanted. 1946 Finally, if the article isn't wanted immediately but the client 1947 should retry later if possible (if, for example, another client is in 1948 the process of sending the same article to the server), a 436 1949 response MUST be returned. 1951 If transmission of the article is requested, the client MUST send the 1952 entire article, including header and body, in the format defined 1953 above (Section 3) for multi-line responses (except that there is no 1954 initial line containing a response code). Thus a single dot (".") on 1955 a line indicates the end of the text, and lines starting with a dot 1956 in the original text have that dot doubled during transmission. The 1957 server MUST return either a 235 response, indicating that the article 1958 was successfully transferred, a 436 response, indicating that the 1959 transfer failed but should be tried again later, or a 437 response, 1960 indicating that the article was rejected. 1962 This function differs from the POST command in that it is intended 1963 for use in transferring already-posted articles between hosts. It 1964 SHOULD NOT be used when the client is a personal news reading 1965 program, since this command indicates that the forthcoming article 1966 has already been posted at another site and is being forwarded from 1967 another host. However, the server MAY elect not to post or forward 1968 the article if after further examination of the article it deems it 1969 inappropriate to do so. Reasons for such subsequent rejection of an 1970 article may include such problems as inappropriate newsgroups or 1971 distributions, disc space limitations, article lengths, garbled 1972 headers, and the like. These are typically restrictions enforced by 1973 the server host's news software and not necessarily the NNTP server 1974 itself. 1976 The client SHOULD NOT assume that the article has been successfully 1977 transferred unless it receives an affirmative response from the 1978 server. A lack of response (such as a dropped network connection or 1979 a network timeout) SHOULD be treated the same as a 436 response. 1981 Because some news server software may not be able immediately to 1982 determine whether or not an article is suitable for posting or 1983 forwarding, an NNTP server MAY acknowledge the successful transfer of 1984 the article (with a 235 response) but later silently discard it. 1986 7.3.2.3 Examples 1988 Example of successfully sending an article to another site: 1990 [C] IHAVE 1991 [S] 335 Send it; end with . 1992 [C] Path: pathost!demo!somewhere!not-for-mail 1993 [C] From: "Demo User" 1994 [C] Newsgroups: misc.test 1995 [C] Subject: I am just a test article 1996 [C] Date: 6 Oct 1998 04:38:40 -0500 1997 [C] Organization: An Example Com, San Jose, CA 1998 [C] Message-ID: 1999 [C] 2000 [C] This is just a test article. 2001 [C] . 2002 [S] 235 Article transferred OK 2004 Example of sending an article to another site that rejects it: 2006 [C] IHAVE 2007 [S] 335 Send it; end with . 2008 [C] Path: pathost!demo!somewhere!not-for-mail 2009 [C] From: "Demo User" 2010 [C] Newsgroups: misc.test 2011 [C] Subject: I am just a test article 2012 [C] Date: 6 Oct 1998 04:38:40 -0500 2013 [C] Organization: An Example Com, San Jose, CA 2014 [C] Message-ID: 2015 [C] 2016 [C] This is just a test article. 2017 [C] . 2018 [S] 437 Article rejected; don't send again 2020 Example of sending an article to another site where the transfer 2021 fails: 2023 [C] IHAVE 2024 [S] 335 Send it; end with . 2025 [C] Path: pathost!demo!somewhere!not-for-mail 2026 [C] From: "Demo User" 2027 [C] Newsgroups: misc.test 2028 [C] Subject: I am just a test article 2029 [C] Date: 6 Oct 1998 04:38:40 -0500 2030 [C] Organization: An Example Com, San Jose, CA 2031 [C] Message-ID: 2032 [C] 2033 [C] This is just a test article. 2034 [C] . 2035 [S] 436 Transfer failed 2037 Example of sending an article to a site that already has it: 2039 [C] IHAVE 2040 [S] 435 Duplicate 2042 Example of sending an article to a site that requests the article be 2043 tried again later: 2045 [C] IHAVE 2046 [S] 436 Retry later 2048 8. Information commands 2050 This section lists other commands that may be used at any time 2051 between the beginning of a session and its termination. Using these 2052 commands does not alter any state information, but the response 2053 generated from their use may provide useful information to clients. 2055 All servers MUST implement these commands. 2057 8.1 DATE 2059 8.1.1 Usage 2061 Syntax 2062 DATE 2064 Responses 2065 111 yyyymmddhhmmss server date and time 2067 Parameters 2068 yyyymmddHHmmss = Current UTC date and time on server 2070 8.1.2 Description 2072 This command exists to help clients find out the current Coordinated 2073 Universal Time [9] from the server's perspective. This command MUST 2074 NOT be used as a substitute for NTP [10], but to provide information 2075 that might be useful when using the NEWNEWS command (see Section 2076 8.4). A system providing NNTP service SHOULD implement NTP for the 2077 purposes of keeping the system clock as accurate as possible. 2079 The server MUST return a 111 response specifying the date and time on 2080 the server in the form yyyymmddhhmmss. This date and time is in 2081 Coordinated Universal Time. 2083 8.1.3 Examples 2085 [C] DATE 2086 [S] 111 19990623135624 2088 8.2 HELP 2090 8.2.1 Usage 2091 Syntax 2092 HELP 2094 Responses 2095 100 Help text follows (multiline) 2097 8.2.2 Description 2099 This command provides a short summary of commands that are understood 2100 by this implementation of the server. The help text will be 2101 presented as a multiline response following the 100 response code. 2103 This text is not guaranteed to be in any particular format and MUST 2104 NOT be used by clients as a replacement for the LIST EXTENSIONS 2105 command described in Section 6.1 2107 8.2.3 Examples 2109 [C] HELP 2110 [S] 100 Help text follows 2111 [S] This is some help text. There is no specific 2112 [S] formatting requirement for this test, though 2113 [S] it is customary for it to list the valid commands 2114 [S] and give a brief definition of what they do 2115 [S] . 2117 8.3 NEWGROUPS 2119 8.3.1 Usage 2121 Syntax 2122 NEWGROUPS date time [GMT] 2124 Responses 2125 231 List of new newsgroups follows (multiline) 2127 Parameters 2128 date = Date in yymmdd or yyyymmdd format 2129 time = Time in hhmmss format 2131 8.3.2 Description 2133 This command returns a list of newsgroups created on the server since 2134 the specified date and time. The results are in the same format as 2135 the LIST ACTIVE command (see Section 8.6.1). 2137 OUTSTANDING ISSUE 2139 Does the output include high/low/status or not? If so, the 2140 examples are wrong. If not, the above text is wrong. 2142 The date is specified as 6 or 8 digits in the format [xx]yymmdd, 2143 where xx is the first two digits of the year (19-99), yy is the last 2144 two digits of the year (00-99), mm is the month (01-12), and dd is 2145 the day of the month (01-31). If the first two digits of the year 2146 are not specified, the year is to be taken from the current century 2147 if yy is smaller than or equal to the current year, otherwise the 2148 year is from the previous century. 2150 The time is specified as 6 digits in the format hhmmss, where hh is 2151 the hours in the 24-hour clock (00-23), mm is the minutes (00-59), 2152 and ss is the seconds (00-60, to allow for leap seconds). The token 2153 "GMT" specifies that the date and time are given in Coordinated 2154 Universal Time; if it is omitted then the date and time are specified 2155 in the server's local timezone. Note that there is no way using the 2156 protocol specified in this document to establish the server's local 2157 timezone. 2159 Note that an empty list is a possible valid response and indicates 2160 that there are no new newsgroups since that date-time. 2162 Clients SHOULD make all queries using Coordinated Universal Time 2163 (i.e. by including the "GMT" parameter) when possible. 2165 8.3.3 Examples 2167 Example where there are new groups: 2169 [C] NEWGROUPS 19990624 000000 GMT 2170 [S] 231 list of new newsgroups follows 2171 [S] alt.rfc-writers.recovery 2172 [S] tx.natives.recovery 2173 [S] . 2175 Example where there are no new groups: 2177 [C] NEWGROUPS 19990624 000000 GMT 2178 [S] 231 list of new newsgroups follows 2179 [S] . 2181 8.4 NEWNEWS 2182 8.4.1 Usage 2184 Syntax 2185 NEWNEWS wildmat date time [GMT] 2187 Responses 2188 230 List of new articles follows (multiline) 2190 Parameters 2191 wildmat = Newsgroups of interest 2192 date = Date in yymmdd or yyyymmdd format 2193 time = Time in hhmmss format 2195 8.4.2 Description 2197 This command returns a list of message-ids of articles posted or 2198 received on the server, in the newsgroups whose names match the 2199 wildmat, since the specified date and time. One message-id is sent 2200 on each line; the order of the response has no specific significance 2201 and may vary from response to response in the same session. A 2202 message-id MAY appear more than once; if it does so, it has the same 2203 meaning as if it appeared only once. 2205 Date and time are in the same format as the NEWGROUPS command (see 2206 Section 8.3). 2208 Note that an empty list is a possible valid response and indicates 2209 that there is currently no new news in the relevant groups. 2211 Clients SHOULD make all queries in Coordinated Universal Time (i.e. 2212 by using the "GMT" parameter) when possible. 2214 8.4.3 Examples 2216 Example where there are new articles: 2218 [C] NEWNEWS news.*,sci.* 19990624 000000 GMT 2219 [S] 230 list of new articles by message-id follows 2220 [S] 2221 [S] 2222 [S] . 2224 Example where there are no new articles: 2226 [C] NEWNEWS alt.* 19990624 000000 GMT 2227 [S] 230 list of new articles by message-id follows 2228 [S] . 2230 8.5 Time 2232 As described in Section 7, each article has an arrival timestamp. 2233 Each newsgroup also has a creation timestamp. These timestamps are 2234 used by the NEWNEWS and NEWGROUP commands to construct their 2235 reponses. 2237 The DATE command MUST return a timestamp from the same clock as is 2238 used for determining article arrival and group creation times. This 2239 clock SHOULD be monotonic, and adjustments SHOULD be made by running 2240 it fast or slow compared to "real" time rather than by making sudden 2241 jumps. 2243 Clients can ensure that they do not have gaps in lists of articles or 2244 groups by using the DATE command in the following manner: 2246 First session: 2247 Issue DATE command and record result 2248 Issue NEWNEWS command using a previously chosen timestamp 2250 Subsequent sessions: 2251 Issue DATE command and hold result in temporary storage 2252 Issue NEWNEWS command using timestamp saved from previous session 2253 Overwrite saved timestamp with that currently in temporary storage 2255 In order to allow for minor errors, clients MAY want to adjust the 2256 timestamp back by two or three minutes before using it in NEWNEWS. 2258 8.5.1 Examples 2260 First session: 2262 [C] DATE 2263 [S] 111 20010203112233 2264 [C] NEWNEWS local.chat 20001231 235959 GMT 2265 [S] 230 list follows 2266 [S] 2267 [S] 2268 [S] 2269 [S] . 2271 Second session (the client has subtracted 3 minutes from the 2272 timestamp returned previously): 2274 [C] DATE 2275 [S] 111 20010204003344 2276 [C] NEWNEWS local.chat 20010203 111933 GMT 2277 [S] 230 list follows 2279 [S] 2280 [S] 2281 [S] 2282 [S] . 2284 Note how arrived in the 3 minute gap and so 2285 is listed in both responses. 2287 8.6 The LIST commands 2289 8.6.1 LIST ACTIVE 2291 8.6.1.1 Usage 2293 Syntax 2294 LIST ACTIVE [wildmat] 2296 Responses 2297 215 Information follows (multiline) 2299 Parameters 2300 wildmat = groups of interest 2302 8.6.1.2 Description 2304 The LIST ACTIVE command with no parameters returns a list of valid 2305 newsgroups and associated information. Each newsgroup is sent as a 2306 line of text in the following format: 2308 group first last status 2310 where: 2312 "group" is the name of the newsgroup; 2314 "first" is the current low water mark for the group; 2316 "last" is the current high water mark for the group; 2318 "status" is the current status of the group on this server; typically 2319 this is one of: 2321 "y" posting is permitted 2323 "n" posting is not permitted 2324 "m" postings will be forwarded to the newsgroup moderator 2326 Other status strings may exist. The definition of these other 2327 values and the circumstances under which they are returned is 2328 covered in other specifications. 2330 OUTSTANDING ISSUE 2332 Is the order "group first last status" or "group last first 2333 status"? The examples match the description above, but they 2334 don't match the news server I have tested. 2336 Each field in the line is separated from its neighboring fields by 2337 one or more US-ASCII spaces. 2339 The "first" and "last" fields correspond to the high and low water 2340 marks described in the GROUP command (see Section 7.1.1). 2342 The status of a newsgroup only indicates how posts to that newsgroup 2343 are processed. It does not indicate if the current client is 2344 permitted to post. That is indicated by the status code returned as 2345 part of the greeting. Note that an empty list is a possible valid 2346 response, and indicates that there are currently no valid newsgroups. 2348 If the optional wildmat parameter is specified, the list is limited 2349 to only the groups whose names match the wildmat. If no wildmat is 2350 specified, the keyword ACTIVE MAY be omitted without altering the 2351 effect of the command. 2353 8.6.1.3 Examples 2355 Example of LIST ACTIVE returning a list of newsgroups: 2357 [C] LIST ACTIVE 2358 [S] 215 list of newsgroups follows 2359 [S] misc.test 3000234 3002322 y 2360 [S] alt.fc-writers.recovery 1 4 y 2361 [S] tx.natives.recovery 56 89 y 2362 [S] . 2364 Example of LIST ACTIVE omitting the second keyword and returning no 2365 newsgroups: 2367 [C] LIST 2368 [S] 215 list of newsgroups follows 2369 [S] . 2371 Example of LIST ACTIVE with a wildmat: 2373 [C] LIST ACTIVE *.recovery 2374 [S] 215 list of newsgroups follows 2375 [S] alt.fc-writers.recovery 1 4 y 2376 [S] tx.natives.recovery 56 89 y 2377 [S] . 2379 8.6.2 LIST ACTIVE.TIMES 2381 8.6.2.1 Usage 2383 This command is optional. 2385 Syntax 2386 LIST ACTIVE.TIMES [wildmat] 2388 Responses 2389 215 Information follows (multiline) 2390 503 Facility not available 2392 Parameters 2393 wildmat = groups of interest 2395 8.6.2.2 Description 2397 The active.times file is maintained by some news transport systems to 2398 contain information about who created a particular newsgroup and 2399 when. Each line of this file consists of three fields separated from 2400 each other by one or more US-ASCII space characters. The first field 2401 is the name of the newsgroup. The second is the time when this group 2402 was created on this news server, measured in seconds since the start 2403 of January 1, 1970. The third is the email address of the entity 2404 that created the newsgroup, and must be a mailbox as defined in RFC 2405 2822 [7]. 2407 If the information is available, it is returned as a multi-line 2408 response following the 215 response code. If the information is not 2409 available, a 503 response MUST be returned. If the server does not 2410 recognize the command, a 501 response MUST be returned. 2412 If the optional wildmat parameter is specified, the list is limited 2413 to only the groups whose names match the wildmat (and therefore may 2414 be empty). 2416 8.6.2.3 Examples 2418 Example of LIST ACTIVE.TIMES returning a list of newsgroups: 2420 [C] LIST ACTIVE.TIMES 2421 [S] 215 information follows 2422 [S] misc.test 930445408 2423 [S] alt.rfc-writers.recovery 930562309 2424 [S] tx.natives.recovery 930678923 2425 [S] . 2427 Example of LIST ACTIVE.TIMES returning an error where the command is 2428 recognised but the software does not maintain this information: 2430 [C] LIST ACTIVE.TIMES 2431 [S] 503 program error, function not performed 2433 Example of LIST ACTIVE.TIMES sent to a server that does not recognize 2434 this command: 2436 [C] LIST ACTIVE.TIMES 2437 [S] 501 Syntax Error 2439 8.6.3 LIST DISTRIBUTIONS 2441 8.6.3.1 Usage 2443 This command is optional. 2445 Syntax 2446 LIST DISTRIBUTIONS 2448 Responses 2449 215 Information follows (multiline) 2450 503 Facility not available 2452 8.6.3.2 Description 2454 The distributions file is maintained by some news transport systems 2455 to contain information about valid values for the Distribution: line 2456 in a news article header and about what the values mean. Each line 2457 of this file consists of two fields separated from each other by one 2458 or more US-ASCII space characters. The first field is a value and 2459 the second is a short explanation of the meaning of that value. 2461 If the information is available, it is returned as a multi-line 2462 response following the 215 response code. If the information is not 2463 available, a 503 response MUST be returned. If the server does not 2464 recognize the command, a 501 response MUST be returned. 2466 8.6.3.3 Examples 2468 Example of LIST DISTRIBUTIONS returning a list of distributions: 2470 [C] LIST DISTRIBUTIONS 2471 [S] 215 information follows 2472 [S] usa United States of America 2473 [S] na North America 2474 [S] world All over the World 2475 [S] . 2477 Example of LIST DISTRIBUTIONS returning an error where the command is 2478 recognised but the software does not maintain this information: 2480 [C] LIST DISTRIBUTIONS 2481 [S] 503 program error, function not performed 2483 Example of LIST DISTRIBUTIONS sent to a server that does not 2484 recognize this command: 2486 [C] LIST DISTRIBUTIONS 2487 [S] 501 Syntax Error 2489 8.6.4 LIST DISTRIB.PATS 2491 8.6.4.1 Usage 2493 This command is optional. 2495 Syntax 2496 LIST DISTRIB.PATS 2498 Responses 2499 215 Information follows (multiline) 2500 503 Facility not available 2502 8.6.4.2 Description 2504 The distrib.pats file is maintained by some news transport systems to 2505 choose a value for the Distribution: line in the header of a news 2506 article being posted. Each line of this file consists of three 2507 fields separated from each other by a US-ASCII colon. The first 2508 field is a weight, the second field is a wildmat (which may be a 2509 simple group name), and the third field is a value for the 2510 Distribution: header. 2512 The client MAY use this information to select a Distribution: value 2513 based on the name of a newsgroup. To do so, it should determine the 2514 lines whose second field matches the newsgroup name, select from 2515 among them the line with the highest weight (with 0 being the 2516 lowest), and use the value of the third field to construct the 2517 Distribution: header. 2519 If the information is available, it is returned as a multi-line 2520 response following the 215 response code. If the information is not 2521 available, a 503 response MUST be returned. If the server does not 2522 recognize the command, a 501 response MUST be returned. 2524 8.6.4.3 Examples 2526 Example of LIST DISTRIB.PATS returning a list of newsgroups: 2528 [C] LIST DISTRIB.PATS 2529 [S] 215 information follows 2530 [S] 10:local.*:local 2531 [S] 5:*:world 2532 [S] 20:local.here.*:thissite 2533 [S] . 2535 Example of LIST DISTRIB.PATS returning an error where the command is 2536 recognised but the software does not maintain this information: 2538 [C] LIST DISTRIB.PATS 2539 [S] 503 program error, function not performed 2541 Example of LIST DISTRIB.PATS sent to a server that does not recognize 2542 this command: 2544 [C] LIST DISTRIB.PATS 2545 [S] 501 Syntax Error 2547 8.6.5 LIST NEWSGROUPS 2549 8.6.5.1 Usage 2551 This command is optional. 2553 Syntax 2554 LIST NEWSGROUPS [wildmat] 2556 Responses 2557 215 Information follows (multiline) 2558 503 Facility not available 2560 Parameters 2561 wildmat = groups of interest 2563 8.6.5.2 Description 2565 The newsgroups file is maintained by some news transport systems to 2566 contain the name of each newsgroup that is available on the server 2567 and a short description about the purpose of the group. Each line of 2568 this file consists of two fields separated from each other by one or 2569 more US-ASCII space characters. The first field is the name of the 2570 newsgroup and the second is a short description of the group. Note 2571 that an empty list is a possible valid response, and indicates that 2572 there are currently no valid newsgroups. 2574 If the information is available, it is returned as a multi-line 2575 response following the 215 response code. If the information is not 2576 available, a 503 response MUST be returned. If the server does not 2577 recognize the command, a 501 response MUST be returned. 2579 If the optional wildmat parameter is specified, the list is limited 2580 to only the groups whose names match the wildmat. 2582 8.6.5.3 Examples 2584 Example of LIST NEWSGROUPS returning a list of newsgroups: 2586 [C] LIST NEWSGROUPS 2587 [S] 215 information follows 2588 [S] misc.test General Usenet testing 2589 [S] alt.rfc-writers.recovery RFC Writers Recovery 2590 [S] tx.natives.recovery Texas Natives Recovery 2591 [S] . 2593 Example of LIST NEWSGROUPS returning an error where the command is 2594 recognised but the software does not maintain this information: 2596 [C] LIST NEWSGROUPS 2597 [S] 503 program error, function not performed 2599 Example of LIST NEWSGROUPS sent to a server that does not recognize 2600 this command: 2602 [C] LIST NEWSGROUPS 2603 [S] 501 Syntax error 2605 9. The CONCLUSION step 2607 9.1 QUIT 2609 9.1.1 Usage 2611 Syntax 2612 QUIT 2614 Responses 2615 205 Connection closing 2617 9.1.2 Description 2619 The server process MUST acknowledge the QUIT command and then close 2620 the connection to the client. This is the preferred method for a 2621 client to indicate that it has finished all its transactions with the 2622 NNTP server. 2624 If a client simply disconnects (or the connection times out or some 2625 other fault occurs), the server MUST gracefully cease its attempts to 2626 service the client, disconnecting from its end if necessary. 2628 9.1.3 Examples 2630 [C] QUIT 2631 [S] 205 closing connection 2632 [Server closes connection.] 2634 10. Framework for NNTP extensions 2636 Although NNTP is widely and robustly deployed, some parts of the 2637 Internet community might wish to extend the NNTP service. This 2638 document defines a means whereby an extended NNTP client can query 2639 the server to determine the service extensions that it supports. 2641 It must be emphasized that any extension to the NNTP service should 2642 not be considered lightly. NNTP's strength comes primarily from its 2643 simplicity. Experience with many protocols has shown that: 2645 Protocols with few options tend towards ubiquity, whilst protocols 2646 with many options tend towards obscurity. 2648 This means that each and every extension, regardless of its benefits, 2649 must be carefully scrutinized with respect to its implementation, 2650 deployment, and interoperability costs. In many cases, the cost of 2651 extending the NNTP service will likely outweigh the benefit. 2653 Given this environment, the framework for extensions described in 2654 this document consists of: 2656 o a mechanism for clients to determine a server's available 2657 extensions 2659 o a registry of NNTP service extensions 2661 The LIST EXTENSIONS command is described in this document (see 2662 Section 6.1) and is the mechanism for clients to use to determine 2663 what extensions are available. 2665 The IANA shall maintain a registry of NNTP service extensions. 2667 An extension is identified by a unique extension-label, which is a 2668 string of 1 to 12 uppercase letters. The extension-label will often 2669 be the name of a new command that the extension adds. However this 2670 is not a requirement: an extension might not add any new commands or 2671 keywords. 2673 An extension is either a private extension or else it is included in 2674 the IANA registry and is defined in an RFC. Such RFCs either must be 2675 on the standards-track or must define an IESG-approved experimental 2676 protocol. 2678 The definition of an extension must include: 2680 o a descriptive name for the extension 2681 o the extension-label (which is returned by LIST EXTENSIONS to 2682 indicate to the client that the server supports this particular 2683 extension) 2685 o the syntax, values, and meanings of any parameters following the 2686 extension-label in the output of LIST EXTENSIONS 2688 o any new NNTP commands associated with the extension 2690 o the syntax and possible values of parameters associated with the 2691 new NNTP commands 2693 o any new parameters the extension associates with any other 2694 pre-existing NNTP commands 2696 o how support for the extension affects the behavior of a server and 2697 NNTP client 2699 o any increase in the maximum length of commands over the value 2700 specified in this document 2702 o a specific statement about the effect on pipelining this extension 2703 may have (if any) 2705 The extension-label of private extensions MUST begin with "X". The 2706 extension-label of registered extensions MUST NOT begin with "X". 2708 A server MUST NOT provide any extension, whether or not listed in the 2709 output from LIST EXTENSIONS, unless it is either a registered 2710 extension or a private extension. 2712 Except where stated otherwise, the commands in this document are 2713 understood (even if not supported) by all servers and are not 2714 described in the list of features returned by the LIST EXTENSIONS 2715 command. 2717 A server MAY provide additional keywords - either for new commands or 2718 new variants of existing commands - as part of a private extension. 2719 These new keywords MUST begin with "X". 2721 A server MUST NOT send different response codes to basic NNTP 2722 commands documented here or commands documented in registered 2723 extensions in response to the availability or use of a private 2724 extension. 2726 10.1 Initial IANA registry 2728 The IANA's initial registry of NNTP service extensions consists of 2729 these entries: 2731 Extension Label Added behavior 2732 Specific article numbers LISTGROUP Defined in this document 2733 Overview support OVER Defined in this document 2734 Header pattern matching HDR Defined in this document 2736 10.2 Standard extensions 2738 Each of the following sections describes an extension that a server 2739 MAY provide. If the server provides the extension, it MUST include 2740 the appropriate extension label in the response to LIST EXTENSIONS. 2741 If it does not provide it, it MUST NOT include the appropriate 2742 extension label. The descriptions of facilities in each section are 2743 written as if the extension is provided. If it is not provided, the 2744 entire section should be ignored. 2746 If the server provides an extension, it MUST implement all of the 2747 commands in the specification of the extension except for those 2748 marked as optional. If it does not provide an extension, it MUST NOT 2749 implement any of the commands in the specification of that extension. 2751 10.3 The LISTGROUP extension 2753 This extension provides one command and has the extension label 2754 LISTGROUP. 2756 10.3.1 LISTGROUP 2758 10.3.1.1 Usage 2760 Syntax 2761 LISTGROUP [ggg] 2763 Responses 2764 211 Article numbers follow (multiline) 2765 411 No such newsgroup 2766 412 No newsgroup selected [1] 2768 Parameters 2769 ggg = name of newsgroup 2771 [1] The 412 response can only occur if no group has been specified. 2773 10.3.1.2 Description 2775 The LISTGROUP command is used to get a listing of all the article 2776 numbers in a particular newsgroup. 2778 The optional parameter ggg is the name of the newsgroup to be 2779 selected (e.g. "news.software.misc"). A list of valid newsgroups 2780 may be obtained from the LIST ACTIVE command. If no group is 2781 specified, the current selected newsgroup is used. 2783 OUTSTANDING ISSUE 2785 On at least some servers the 211 response line is the same as with 2786 GROUP. Should this be a requirement? 2788 The list of article numbers is returned as a multi-line response 2789 following the 211 response code. It contains one number per line, is 2790 in numerical order, and lists precisely those articles that exist in 2791 the group. 2793 When a valid group is selected by means of this command, the current 2794 selected newsgroup MUST be set to that group and the current article 2795 number MUST be set to the first article in the group. If an empty 2796 newsgroup is selected, the current article pointer is made invalid. 2797 If an invalid group is specified, the current selected newsgroup and 2798 current article number MUST NOT be changed. 2800 The LISTGROUP command MAY be used by a client as a replacement for 2801 the GROUP command in establishing a valid current selected newsgroup 2802 and current article number. 2804 If the group specified is not available on the server, a 411 response 2805 MUST be returned. If no group is specified and the current selected 2806 newsgroup is invalid, a 412 response MUST be returned. 2808 10.3.1.3 Examples 2810 Example of LISTGROUP on an empty group: 2812 [C] LISTGROUP example.empty.newsgroup 2813 [S] 211 list of article numbers follows 2814 [S] . 2816 Example of LISTGROUP on a valid current selected newsgroup: 2818 [C] GROUP misc.test 2819 [S] 211 2000 3000234 3002322 misc.test selected 2820 [C] LISTGROUP 2821 [S] 211 list follows 2822 [S] 3000234 2823 [S] 3000237 2824 [S] 3000238 2825 [S] 3000239 2826 [S] 3002322 2827 [S] . 2829 Example of LISTGROUP failing because no group has been selected: 2831 [Assumes current selected newsgroup is invalid.] 2832 [C] LISTGROUP 2833 [S] 412 no current group 2834 [C] GROUP example.is.sob.bradner.or.barber 2835 [S] 411 no such group 2836 [C] LISTGROUP 2837 [S] 412 no current group 2839 10.4 Article metadata 2841 The OVER and HDR extensions refer to the concept of "article 2842 metadata". This is data about articles that does not occur within 2843 the article itself. Each metadata item has a name which MUST begin 2844 with a colon. Note that a historical feature of the LIST 2845 OVERVIEW.FMT command means that metadata names SHOULD NOT end with 2846 ":full". 2848 When generating a metadata item, the server MUST compute it for 2849 itself and MUST NOT trust any related value provided in the article. 2850 (In particular, a Lines: or Bytes: header in the article MUST NOT be 2851 assumed to specify the correct number of lines or bytes in the 2852 article.) 2854 This specification defines two metadata items: ":bytes" and ":lines". 2855 Implementations and other extensions may define other metadata items. 2857 10.4.1 The :bytes metadata item 2859 The :bytes metadata item for an article is a decimal integer. It 2860 MUST equal the number of octets in the entire article - headers, 2861 body, and separating blank line - except that the US-ASCII CRLF at 2862 the end of each line MAY (but SHOULD NOT) be counted as a single 2863 octet. 2865 OUTSTANDING ISSUE 2867 Should this be called ":octets" instead? Or should it be a count 2868 of UTF characters rather than octets? 2870 10.4.2 The :lines metadata item 2872 The :lines metadata item for an article is a decimal integer. It 2873 MUST equal the number of lines in the article body (excluding the 2874 blank line separating headers and body); equivalently, it is two less 2875 than the number of US-ASCII CRLF pairs that the BODY command would 2876 return for that article (the extra two are those following the 2877 response code and the termination octet). 2879 10.5 The OVER extension 2881 This extension provides two commands, OVER and LIST OVERVIEW.FMT. 2882 The label for this extension is OVER. 2884 The OVER extension provides access to the overview database [8], 2885 which is a database of header lines extracted from incoming articles. 2886 Only certain headers are included in the database. The database also 2887 includes some article metadata. 2889 The information stored in the database may change over time. The 2890 LIST OVERVIEW.FMT command describes the information that would be 2891 stored for an article arriving at the same time as the command was 2892 executed. 2894 10.5.1 OVER 2896 10.5.1.1 Usage 2898 Syntax 2899 OVER [range] 2901 Responses 2902 224 Overview information follows (multiline) 2903 412 No newsgroup selected 2904 420 Current article number is invalid 2905 423 No articles in that range 2907 Parameters 2908 range = Article(s) to return information for 2910 10.5.1.2 Description 2912 The OVER command returns the contents of the headers and metadata in 2913 the database for the article(s) specified from the current selected 2914 newsgroup. 2916 The optional range argument may be any of the following: 2918 o an article number 2920 o an article number followed by a dash to indicate all following 2922 o an article number followed by a dash followed by another article 2923 number 2925 If no argument is specified, then the current article number is used. 2927 If the information is available, it is returned as a multi-line 2928 response following the 224 response code. If the current selected 2929 newsgroup is invalid, a 412 response MUST be returned. If there are 2930 no articles in the range specified, a 423 response MUST be returned. 2931 If OVER is sent without any arguments and the current article number 2932 is invalid, a 420 response MUST be returned. If the client does not 2933 have permission to access the overview database, a 502 response MUST 2934 be returned. 2936 OUTSTANDING ISSUE 2938 Should this be 502 ("not permitted") or 503 ("there is no overview 2939 database")? In which case, why provide the command? 2941 For a successful response, the output consists of one line per 2942 article, sorted in numerical order of article number. Each line 2943 consists of a number of fields separated by an US-ASCII TAB 2944 character. A field may be empty (in which case there will be two 2945 adjacent US-ASCII TABs), and a sequence of trailing US-ASCII TABs may 2946 be omitted. 2948 The first 8 fields MUST be the following, in order: 2950 article number 2951 "Subject" header 2952 "From" header 2953 "Date" header 2954 "Message-ID" header 2955 "References" header 2956 :bytes metadata item 2957 :lines metadata item 2959 Any subsequent fields are the contents of the other headers and 2960 metadata held in the database. 2962 For the five mandatory headers, the content of each field MUST be 2963 based on the original header with the header name and following colon 2964 and space removed. If the article does not contain that header, or 2965 if there is nothing following the colon and space, the field MUST be 2966 empty. For the two mandatory metadata items, the content of the 2967 field MUST be just the value, with no other text. 2969 For all subsequent fields that contain headers, the content MUST be 2970 based on the entire header including the name. For all subsequent 2971 fields that contain metadata, the field consists of the metadata 2972 name, a single US-ASCII space, and then the value. 2974 For all fields, the value is processed by first removing all US-ASCII 2975 CRLF pairs and then replacing each remaining US-ASCII NUL, TAB, CR, 2976 or LF character with a single US-ASCII space (for example, CR LF LF 2977 TAB will become two spaces). If there is no such header in the 2978 article, or no such metadata item, or no header or item stored in the 2979 database for that article, the corresponding field MUST be empty. 2981 The server SHOULD NOT produce output for articles that no longer 2982 exist. 2984 10.5.1.3 Examples 2986 In the first two examples, US-ASCII tab has been replaced by vertical 2987 bar and some lines have been folded for readability. 2989 Example of a successful retrieval of overview information for an 2990 article (using no article number): 2992 [C] GROUP misc.test 2993 [S] 211 1234 3000234 3002322 misc.test 2994 [C] OVER 2995 [S] 224 Overview information follows 2996 [S] 300234|I am just a test article|"Demo User" 2997 |6 Oct 1998 04:38:40 -0500| 2998 <45223423@example.com>|<45454@example.net>|1234| 2999 17|Xref: news.example.com misc.test:3000363 3000 [S] . 3002 Example of a successful retrieval of overview information for a range 3003 of articles: 3005 [C] GROUP misc.test 3006 [S] 211 1234 3000234 3002322 misc.test 3008 [C] OVER 3000234-3000240 3009 [S] 224 Overview information follows 3010 [S] 300234|I am just a test article|"Demo User" 3011 |6 Oct 1998 04:38:40 -0500| 3012 <45223423@example.com>|<45454@example.net>|1234| 3013 17|Xref: news.example.com misc.test:3000363 3014 [S] 3000235|Another test article|nobody@nowhere.to 3015 (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425@to.to>|| 3016 4818|37||Distribution: fi 3017 [S] 3000238|Re: I am just a test article|somebody@elsewhere.to| 3018 7 Oct 1998 11:38:40 +1200|| 3019 <45223423@to.to>|9234|51 3020 [S] . 3022 Note the missing "References" and Xref headers in the second line, 3023 the missing trailing field(s) in the first and last lines, and that 3024 there are only results for those articles that still exist. 3026 Example of an unsuccessful retrieval of overview information on an 3027 article by number: 3029 [C] GROUP misc.test 3030 [S] 211 1234 3000234 3002322 misc.test 3031 [C] OVER 300256 3032 [S] 420 No such article in this group 3034 Example of an unsuccessful retrieval of overview information by 3035 number because no newsgroup was selected first: 3037 [Assumes current selected newsgroup is invalid.] 3038 [C] OVER 3039 [S] 412 No newsgroup selected 3041 Example of an attempt to retrieve information when the current 3042 selected newsgroup is empty: 3044 [C] GROUP example.empty.newsgroup 3045 [S] 211 0 0 0 example.empty.newsgroup 3046 [C] OVER 3047 [S] 420 No current article selected 3049 10.5.2 LIST OVERVIEW.FMT 3051 10.5.2.1 Usage 3052 Syntax 3053 LIST OVERVIEW.FMT 3055 Responses 3056 215 Information follows (multiline) 3057 503 Facility not available 3059 10.5.2.2 Description 3061 OUTSTANDING ISSUE 3063 Should this be optional even when the OVER extension is provided? 3064 If so, is there a point in the 503 response? 3066 The LIST OVERVIEW.FMT command returns a description of the fields in 3067 the database. The fields MUST be listed in the order that they will 3068 be returned by the OVER command for a newly-received article (the 3069 information stored for articles may change over time). 3071 If the information is available, it is returned as a multi-line 3072 response following the 215 response code. If the information is not 3073 available, a 503 response MUST be returned. The information contains 3074 one line per field in the order they are returned by the OVER 3075 command; he first 7 lines MUST be exactly: 3077 Subject: 3078 From: 3079 Date: 3080 Message-ID: 3081 References: 3082 :bytes 3083 :lines 3085 except that, for compatibility with existing implementations, the 3086 last two lines MAY instead be: 3088 Bytes: 3089 Lines: 3091 even though they refer to metadata, not headers. 3093 All subsequent lines MUST consist of either a header name followed by 3094 ":full", or the name of a piece of metadata. 3096 There are no leading or trailing spaces in the output. 3098 Note that the 7 fixed lines describe the 2nd to 8th fields of the 3099 OVER output. The "full" suffix is a reminder that the corresponding 3100 fields include the header name. 3102 This command MAY generate different results if used more than once in 3103 a session. 3105 10.5.2.3 Examples 3107 Example of LIST OVERVIEW.FMT output corresponding to the example OVER 3108 output above, using the preferred format: 3110 [C] LIST OVERVIEW.FMT 3111 [S] 215 Order of fields in overview database. 3112 [S] Subject: 3113 [S] From: 3114 [S] Date: 3115 [S] Message-ID: 3116 [S] References: 3117 [S] :bytes 3118 [S] :lines 3119 [S] Xref:full 3120 [S] Distribution:full 3121 [S] . 3123 Example of LIST OVERVIEW.FMT output corresponding to the example OVER 3124 output above, using the alternative format: 3126 [C] LIST OVERVIEW.FMT 3127 [S] 215 Order of fields in overview database. 3128 [S] Subject: 3129 [S] From: 3130 [S] Date: 3131 [S] Message-ID: 3132 [S] References: 3133 [S] Bytes: 3134 [S] Lines: 3135 [S] Xref:full 3136 [S] Distribution:full 3137 [S] . 3139 Example of LIST OVERVIEW.FMT returning an error: 3141 [C] LIST OVERVIEW.FMT 3142 [S] 503 overview.fmt not available 3144 10.6 The HDR extension 3146 This extension provides one new command: HDR. The label for this 3147 extension is HDR. 3149 10.6.1 HDR 3151 10.6.1.1 Usage 3153 Syntax 3154 HDR header range 3155 HDR header message-id 3156 HDR header 3158 Responses 3160 First form (range specified) 3161 225 Headers follow (multiline) 3162 412 No newsgroup selected 3163 423 No articles in that range 3165 Second form (message-id specified) 3166 225 Headers follow (multiline) 3167 430 No article with that message-id 3169 Third form (current article number used) 3170 225 Headers follow (multiline) 3171 412 No newsgroup selected 3172 420 Current article number is invalid 3174 Parameters 3175 header = name of header, without the colon 3176 range = number(s) of articles 3177 message-id = message-id of article 3179 10.6.1.2 Description 3181 The HDR command retrieves specific headers from an article or 3182 specified range of articles in the current selected newsgroup, or 3183 from an article specified by message-id. It can also return certain 3184 metadata about the article or articles. 3186 The required header parameter is the name of a header (e.g. 3187 "subject") in an article, or the name of a metadata item, and is 3188 case-insensitive. See RFC 1036 [6] for a list of valid header lines. 3189 Names of metadata items always include a colon. Except where stated 3190 otherwise, metadata items are treated as if they were header values, 3191 and references to headers in this description apply equally to 3192 metadata items. 3194 OUTSTANDING ISSUE 3196 Should this be changed to require the name to *begin* with a 3197 colon? 3199 The range parameter may be any of the following: 3201 o an article number 3203 o an article number followed by a dash to indicate all following 3205 o an article number followed by a dash followed by another article 3206 number 3208 The message-id argument indicates a specific article. As shown by 3209 the syntax, the range and message-id arguments are mutually 3210 exclusive; if neither are specified, the current article number is 3211 used. 3213 If the information is available, it is returned as a multi-line 3214 response following the 225 response code and contains one line for 3215 each article where the relevant header line exists. The line 3216 consists of the article number, a US-ASCII space, and then the 3217 contents of the header (without the header name or the colon and 3218 space that follow it) or metadata item. If the article is specified 3219 by message-id rather than by article range, the article number is 3220 given as "0". 3222 Header contents are modified as follows: all US-ASCII CRLF pairs are 3223 removed, and then each remaining US-ASCII NUL, TAB, CR, or LF 3224 character is replaced with a single US-ASCII space. (Note that this 3225 is the same transformation as is performed by the OVER extension.) 3227 The header content is in all cases taken from the article. This 3228 means that, for example, a request for the header "Lines" returns the 3229 contents of the "Lines" header of the specified articles, if any, not 3230 the line count metadata or any other server-generated value. If the 3231 header occurs in a given article multiple times, only the value of 3232 the first occurrence is returned by HDR. 3234 If the requested header is not present in the article or if it is 3235 present but empty, a line for that article is included in the output 3236 but the header content portion of the line is empty (the space after 3237 the article number MAY be retained or omitted). If any article 3238 number in the provided range does not exist in the group, no line for 3239 that article number is included in the output. 3241 If the optional argument is a message-id and no such article exists, 3242 a 430 response MUST be returned. If the optional argument is not a 3243 message-id and the current selected newsgroup is invalid, a 412 3244 response MUST be returned. If the optional argument is an article 3245 number or number range and no article with that number or in that 3246 number range exists in the current selected newsgroup, a 423 response 3247 MUST be returned. If HDR is sent without any arguments and the 3248 current article number is invalid, a 420 response MUST be returned. 3249 A server MAY only allow HDR commands for a limited set of headers and 3250 metadata items (such as those present in the overview database). If 3251 so, it MUST respond with a 503 response to attempts to request other 3252 headers, rather than returning erroneous results such as a successful 3253 empty response. 3255 10.6.1.3 Examples 3257 Example of a successful retrieval of subject lines from a range of 3258 articles (3000235 has no Subject header, and 3000236 is missing): 3260 [C] GROUP misc.test 3261 [S] 211 1234 3000234 3002322 misc.test 3262 [C] HDR Subject 3000234-300238 3263 [S] 225 Headers follow 3264 [S] 3000234 I am just a test article 3265 [S] 3000235 3266 [S] 3000237 Re: I am just a test article 3267 [S] 3000238 Ditto 3268 [S] . 3270 Example of a successful retrieval of line counts from a range of 3271 articles: 3273 [C] GROUP misc.test 3274 [S] 211 1234 3000234 3002322 misc.test 3275 [C] HDR :lines 3000234-300238 3276 [S] 225 Headers follow 3277 [S] 3000234 42 3278 [S] 3000235 5 3279 [S] 3000237 11 3280 [S] 3000238 2378 3281 [S] . 3283 Example of a successful retrieval of the subject line from an article 3284 by message-id: 3286 [C] GROUP misc.test 3288 [S] 211 1234 3000234 3002322 misc.test 3289 [C] HDR subject 3290 [S] 225 Header information follows 3291 [S] 0 I am just a test article 3292 [S] . 3294 Example of a successful retrieval of the subject line from the 3295 current article: 3297 [C] GROUP misc.test 3298 [S] 211 1234 3000234 3002322 misc.test 3299 [C] HDR subject 3300 [S] 225 Header information follows 3301 [S] 3000234 I am just a test article 3302 [S] . 3304 Example of an unsuccessful retrieval of a header from an article by 3305 message-id: 3307 [C] HDR subject 3308 [S] 430 No Such Article Found 3310 Example of an unsuccessful retrieval of headers from articles by 3311 number because no newsgroup was selected first: 3313 [Assumes current selected newsgroup is invalid.] 3314 [C] HDR subject 300256- 3315 [S] 412 No newsgroup selected 3317 Example of an unsuccessful retrieval of headers because the current 3318 selected newsgroup is empty: 3320 [C] GROUP example.empty.newsgroup 3321 [S] 211 0 0 0 example.empty.newsgroup 3322 [C] HDR subject 1- 3323 [S] 423 No articles in that range 3325 Example of an unsuccessful retrieval of headers because the server 3326 does not allow HDR commands for that header: 3328 [C] GROUP misc.test 3329 [S] 211 1234 3000234 3002322 misc.test 3330 [C] HDR Content-Type 3000234-300238 3331 [S] 503 HDR not permitted on Content-Type 3333 11. Augmented BNF Syntax for NNTP Commands 3335 This syntax defines the non-terminal "command-line". Note that ABNF 3336 strings are case insensitive. 3338 command-line = command EOL 3339 command = article-command / 3340 body-command / 3341 date-command / 3342 group-command / 3343 hdr-command / 3344 head-command / 3345 help-command / 3346 ihave-command / 3347 last-command / 3348 list-active-command / 3349 list-active-times-command / 3350 list-distrib-pats-command / 3351 list-distributions-command / 3352 list-extensions-command / 3353 list-newsgroups-command / 3354 list-overview-fmt-command / 3355 listgroup-command / 3356 mode-reader-command / 3357 newgroups-command / 3358 newnews-command / 3359 next-command / 3360 over-command / 3361 post-command / 3362 quit-command / 3363 stat-command / 3364 x-command 3365 article-command = "ARTICLE" [article-ref] 3366 body-command = "BODY" [article-ref] 3367 date-command = "DATE" 3368 group-command = "GROUP" WS newsgroup-name 3369 hdr-command = "HDR" WS header-meta-name [range-ref] 3370 head-command = "HEAD" [article-ref] 3371 help-command = "HELP" 3372 ihave-command = "IHAVE" WS message-id 3373 last-command = "LAST" 3374 list-active-command = "LIST" [WS "ACTIVE" [WS wildmat]] 3375 list-active-times-command = "LIST" WS "ACTIVE.TIMES" [WS wildmat] 3376 list-distrib-pats-command = "LIST" WS "DISTRIB.PATS" 3377 list-distributions-command = "LIST" WS "DISTRIBUTIONS" 3378 list-extensions-command = "LIST" WS "EXTENSIONS" 3379 list-newsgroups-command = "LIST" WS "NEWSGROUPS" [WS wildmat] 3380 list-overview-fmt-command = "LIST" WS "OVERVIEW.FMT" 3381 listgroup-command = "LISTGROUP" [WS newsgroup-name] 3382 mode-reader-command = "MODE" WS "READER" 3383 newgroups-command = "NEWGROUPS" WS date-time 3384 newnews-command = "NEWNEWS" WS wildmat WS date-time 3385 next-command = "NEXT" 3386 over-command = "OVER" [WS range] 3387 post-command = "POST" 3388 quit-command = "QUIT" 3389 stat-command = "STAT" [article-ref] 3390 x-command = x-command-name *(WS x-argument) 3391 ; Each extension command is specified fully elsewhere 3392 article-ref = WS (article-number / message-id) 3393 article-number = 1*16DIGIT 3394 date = [2DIGIT] 6DIGIT 3395 date-time = date WS time [WS "GMT"] 3396 header-meta-name = header-name / metadata-name 3397 header-name = 1*header-name-char 3398 header-name-char = %x21-39 / %x3B-7E ; exclude SP and : 3399 message-id = "<" 1*248message-id-char ">" 3400 ; subject to requirements in 3401 Section 7 3402 > 3403 message-id-char = %x21-3B / %x3C / %x3E-7E ; exclude SP < > 3404 metadata-name = ":" 1*header-name-char 3405 newsgroup-name = 1*wildmat-exact 3406 range = article-number ["-" [article-number]] 3407 range-ref = WS (range / message-id) 3408 time = 6DIGIT 3409 x-command-name = 3*12%x21-7E 3410 x-argument = 1*(%x21-7E / UTF-8-non-ascii) 3411 wildmat = wildmat-pattern *("," ["!"] wildmat-pattern) 3412 wildmat-pattern = 1*wildmat-item 3413 wildmat-item = wildmat-exact / wildmat-wild 3414 wildmat-exact = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E / 3415 UTF-8-non-ascii ; exclude * , ? [ \ ] 3416 wildmat-wild = "*" / "?" 3417 CR = %x0D 3418 CRLF = CR LF 3419 DIGIT = %x30-39 3420 EOL = *(SP / HT) CRLF 3421 HT = %x09 3422 LF = %x0A 3423 SP = %x20 3424 UTF-8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 3425 UTF8-1 = %x80-BF 3426 UTF8-2 = %xC2-DF UTF8-1 3427 UTF8-3 = %xE0 %A0-BF UTF8-1 / %xE1-EC 2UTF8-1 / 3428 %xED %80-9F UTF8-1 / %xEE-EF 2UTF8-1 3430 UTF8-4 = %xF0 %90-BF 2UTF8-1 / %xF1-F7 3UTF8-1 3431 UTF8-5 = %xF8 %88-BF 3UTF8-1 / %xF9-FB 4UTF8-1 3432 UTF8-6 = %xFC %84-BF 4UTF8-1 / %xFD 5UTF8-1 3433 WS = 1*(SP / HT) 3435 12. Security Considerations 3437 This section is meant to inform application developers, information 3438 providers, and users of the security limitations in NNTP as described 3439 by this document. The discussion does not include definitive 3440 solutions to the problems revealed, though it does make some 3441 suggestions for reducing security risks. 3443 12.1 Personal and Proprietary Information 3445 NNTP, because it was created to distribute network news articles, 3446 will forward whatever information is stored in those articles. 3447 Specification of that information is outside this scope of this 3448 document, but it is likely that some personal and/or proprietary 3449 information is available in some of those articles. It is very 3450 important that designers and implementers provide informative 3451 warnings to users so personal and/or proprietary information in 3452 material that is added automatically to articles (e.g. in headers) 3453 is not disclosed inadvertently. Additionally, effective and easily 3454 understood mechanisms to manage the distribution of news articles 3455 SHOULD be provided to NNTP Server administrators, so that they are 3456 able to report with confidence the likely spread of any particular 3457 set of news articles. 3459 12.2 Abuse of Server Log Information 3461 A server is in the position to save session data about a user's 3462 requests that might identify their reading patterns or subjects of 3463 interest. This information is clearly confidential in nature and its 3464 handling can be constrained by law in certain countries. People 3465 using the NNTP protocol to provide data are responsible for ensuring 3466 that such material is not distributed without the permission of any 3467 individuals that are identifiable by the published results. 3469 12.3 Weak Authentication and Access Control 3471 There is no user-based or token-based authentication in the basic 3472 NNTP specification. Access is normally controlled by server 3473 configuration files. Those files specify access by using domain 3474 names or IP addresses. However, this specification does permit the 3475 creation of extensions to the NNTP protocol itself for such purposes. 3476 While including such mechanisms is optional, doing so is strongly 3477 encouraged. 3479 Other mechanisms are also available. For example, a proxy server 3480 could be put in place that requires authentication before connecting 3481 via the proxy to the NNTP server. 3483 12.4 DNS Spoofing 3485 Many existing NNTP implementations authorize incoming connections by 3486 checking the IP address of that connection against the IP addresses 3487 obtained via DNS lookups of lists of domain names given in local 3488 configuration files. Servers that use this type of authentication, 3489 and clients that find a server by doing a DNS lookup of the server 3490 name, rely very heavily on the Domain Name Service, and are thus 3491 generally prone to security attacks based on the deliberate 3492 misassociation of IP addresses and DNS names. Clients and servers 3493 need to be cautious in assuming the continuing validity of an IP 3494 number/DNS name association. 3496 In particular, NNTP clients and servers SHOULD rely on their name 3497 resolver for confirmation of an IP number/DNS name association, 3498 rather than caching the result of previous host name lookups. Many 3499 platforms already can cache host name lookups locally when 3500 appropriate, and they SHOULD be configured to do so. It is proper 3501 for these lookups to be cached, however, only when the TTL (Time To 3502 Live) information reported by the name server makes it likely that 3503 the cached information will remain useful. 3505 If NNTP clients or servers cache the results of host name lookups in 3506 order to achieve a performance improvement, they MUST observe the TTL 3507 information reported by DNS. If NNTP clients or servers do not 3508 observe this rule, they could be spoofed when a previously accessed 3509 server's IP address changes. As network renumbering is expected to 3510 become increasingly common, the possibility of this form of attack 3511 will grow. Observing this requirement thus reduces this potential 3512 security vulnerability. 3514 This requirement also improves the load-balancing behavior of clients 3515 for replicated servers using the same DNS name and reduces the 3516 likelihood of a user's experiencing failure in accessing sites that 3517 use that strategy. 3519 12.5 UTF-8 issues 3521 The UTF-8 specification [2] permits only certain sequences of octets 3522 and designates others as either malformed or "illegal". The Unicode 3523 standard identifies a number of security issues related to illegal 3524 sequences and forbids their generation by conforming implementations. 3526 Implementations of this specification MUST NOT generate malformed or 3527 illegal sequences and SHOULD detect them and take some appropriate 3528 action. This could include: 3530 o replacing such sequences by a "guessed" valid sequence (based on 3531 properties of the UTF-8 encoding); 3533 o replacing such sequences by the sequence %xEF.BF.BD, which encodes 3534 the "replacement character"; 3536 o closing the connection; 3538 o generating a 501 response code. 3540 13. Acknowledgments 3542 The author acknowledges the original authors of NNTP as documented in 3543 RFC 977: Brian Kantor and Phil Lapsey. 3545 The author gratefully acknowledges the work of the NNTP committee 3546 chaired by Eliot Lear. The organization of this document was 3547 influenced by the last available draft from this working group. A 3548 special thanks to Eliot for generously providing the original 3549 machine-readable sources for that document. 3551 The author gratefully acknowledges the work of Marshall Rose & John 3552 G. Meyers in RFC 1939 and the work of the DRUMS working group, 3553 specifically RFC 1869, which is the basis of the NNTP extensions 3554 mechanism detailed in this document. 3556 OUTSTANDING ISSUE 3558 Why RFC 1939? 3560 The author gratefully acknowledges the authors of RFC 2616 for 3561 providing specific and relevant examples of security issues that 3562 should be considered for HTTP. Since many of the same considerations 3563 exist for NNTP, those examples that are relevant have been included 3564 here with some minor rewrites. 3566 The author gratefully acknowledges the comments and additional 3567 information provided by the following individuals in preparing one or 3568 more of the progenitors of this document: 3570 Russ Allbery 3571 Wayne Davison 3572 Chris Lewis 3573 Tom Limoncelli 3574 Eric Schnoebelen 3575 Rich Salz 3577 This work was motivated by the work of various news reader authors 3578 and news server authors, which includes those listed below: 3580 Rick Adams 3581 Original author of the NNTP extensions to the RN news reader and 3582 last maintainer of Bnews 3584 Stan Barber 3585 Original author of the NNTP extensions to the news readers that 3586 are part of Bnews 3588 Geoff Collyer 3589 Original author of the OVERVIEW database proposal and one of the 3590 original authors of CNEWS 3592 Dan Curry 3593 Original author of the xvnews news reader 3595 Wayne Davison 3596 Author of the first threading extensions to the RN news reader 3597 (commonly called TRN) 3599 Geoff Huston 3600 Original author of ANU NEWS 3602 Phil Lapsey 3603 Original author of the UNIX reference implementation for NNTP 3605 Iain Lea 3606 Original maintainer of the TIN news reader 3608 Chris Lewis 3609 First known implementer of the AUTHINFO GENERIC extension 3611 Rich Salz 3612 Original author of INN 3614 Henry Spencer 3615 One of the original authors of CNEWS 3617 Kim Storm 3618 Original author of the NN news reader 3620 Finally, the present author gratefully acknowledges the vast amount 3621 of work put into previous drafts by the previous author: 3623 Stan Barber 3625 Normative References 3627 [1] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", 3628 RFC 977, February 1986. 3630 [2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3631 2279, January 1998. 3633 [3] American National Standards Institute, "Coded Character Set - 3634 7-bit American Standard Code for Information Interchange", ANSI 3635 X3.4, 1986. 3637 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3638 Levels", BCP 14, RFC 2119, March 1997. 3640 [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax 3641 Specifications: ABNF", RFC 2234, November 1997. 3643 [6] Horton, M. and R. Adams, "Standard for interchange of USENET 3644 messages", RFC 1036, December 1987. 3646 [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 3648 [8] Robertson, R., "FAQ: Overview database / NOV General 3649 Information", January 1995. 3651 [9] International Telecommunications Union - Radio, "Glossary, 3652 ITU-R Recommendation TF.686-1", ITU-R Recommendation TF.686-1, 3653 October 1997. 3655 [10] Mills, D., "Network Time Protocol (Version 3) Specification, 3656 Implementation", RFC 1305, March 1992. 3658 Informative References 3660 [11] Salz, R., "Manual Page for wildmat(3) from the INN 1.4 3661 distribution, Revision 1.10", April 1992. 3663 [12] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 3664 1999. 3666 Author's Address 3668 Clive D.W. Feather 3669 Thus plc 3670 322 Regents Park Road 3671 London N3 2QQ 3672 GB 3674 Phone: +44 20 8371 1138 3675 Fax: +44 870 051 9937 3676 URI: http://www.davros.org/ 3678 Intellectual Property Statement 3680 The IETF takes no position regarding the validity or scope of any 3681 intellectual property or other rights that might be claimed to 3682 pertain to the implementation or use of the technology described in 3683 this document or the extent to which any license under such rights 3684 might or might not be available; neither does it represent that it 3685 has made any effort to identify any such rights. Information on the 3686 IETF's procedures with respect to rights in standards-track and 3687 standards-related documentation can be found in BCP-11. Copies of 3688 claims of rights made available for publication and any assurances of 3689 licenses to be made available, or the result of an attempt made to 3690 obtain a general license or permission for the use of such 3691 proprietary rights by implementors or users of this specification can 3692 be obtained from the IETF Secretariat. 3694 The IETF invites any interested party to bring to its attention any 3695 copyrights, patents or patent applications, or other proprietary 3696 rights which may cover technology that may be required to practice 3697 this standard. Please address the information to the IETF Executive 3698 Director. 3700 Full Copyright Statement 3702 Copyright (C) The Internet Society (2003). All Rights Reserved. 3704 This document and translations of it may be copied and furnished to 3705 others, and derivative works that comment on or otherwise explain it 3706 or assist in its implementation may be prepared, copied, published 3707 and distributed, in whole or in part, without restriction of any 3708 kind, provided that the above copyright notice and this paragraph are 3709 included on all such copies and derivative works. However, this 3710 document itself may not be modified in any way, such as by removing 3711 the copyright notice or references to the Internet Society or other 3712 Internet organizations, except as needed for the purpose of 3713 developing Internet standards in which case the procedures for 3714 copyrights defined in the Internet Standards process must be 3715 followed, or as required to translate it into languages other than 3716 English. 3718 The limited permissions granted above are perpetual and will not be 3719 revoked by the Internet Society or its successors or assignees. 3721 This document and the information contained herein is provided on an 3722 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3723 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3724 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3725 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3726 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3728 Acknowledgement 3730 Funding for the RFC Editor function is currently provided by the 3731 Internet Society.