idnits 2.17.1 draft-ietf-nntpext-base-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 14. Security Considerations' ) ** 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 document seems to lack an Authors' Addresses Section. ** There are 303 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [0-9a-zA-Z], [6], [7], [GMT], [XX], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 10 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '... or more of the MUST requirements for...' RFC 2119 keyword, line 97: '...atisfies all the MUST and all the SHOU...' RFC 2119 keyword, line 99: '...atisfies all the MUST requirements but...' RFC 2119 keyword, line 100: '... not all the SHOULD requirements f...' RFC 2119 keyword, line 109: '...ery NNTP session MUST involve the foll...' (133 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: The default character set for all NNTP commands is US-ASCII[2]. Commands in the NNTP MUST consist of a case-insensitive keyword, which MAY be followed by one or more arguments. All commands MUST be terminated by a CRLF pair. Multiple commands MUST not be permitted on the same line. Keywords MUST consist of printable US-ASCII characters. Unless otherwise noted elsewhere in this document, Arguments SHOULD consist of printable US-ASCII characters. Keywords and arguments MUST be each separated by one or more SPACE or TAB characters. Keywords MUST be at least three characters and MUST NOT exceed 12 characters. Command lines MUST not exceed 512 characters, which includes the terminating CRLF pair. == 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: Each response MUST start with a three-digit status indicator that is sufficient to distinguish all responses. Responses to certain commands MAY be multi-line. In these cases, which are clearly indicated below, after sending the first line of the response and a CRLF, any additional lines are sent, each terminated by a CRLF pair. When all lines of the response have been sent, a final line MUST be sent, consisting of a termination octet (ASCII decimal code 046, ".") and a CRLF pair. If any line of the multi-line response begins with the termination octet, the line MUST be "byte-stuffed" by pre-pending the termination octet to that line of the response. Hence, a multi-line response is terminated with the five octets "CRLF.CRLF". When examining a multi-line response, the client MUST check to see if the line begins with the termination octet. If so and if octets other than CRLF follow, the first octet of the line (the termination octet) MUST be stripped away. If so and if CRLF immediately follows the termination character, then the response from the NNTP server is ended and the line containing ".CRLF" MUST not considered part of the multi-line response. == 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: Parameters MUST be separated from the numeric response code and from each other by a single space. All numeric parameters MUST be in base 10 (decimal) format, and may have leading zeros. All string parameters MUST begin after the separating space, and MUST end before the following separating space or the CR-LF pair at the end of the line. (Therefore, string parameters MUST not contain spaces.) All text, if any, in the response which is not a parameter of the response must follow and be separated from the last parameter by a space. Also, note that the text following a response number may vary in different implementations of the server. The 3-digit numeric code should be used to determine what response was sent. == 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: This command MAY be issued at anytime during a session. It is not required that the client issues this command before attempting to make use of any extension. The response generated by this command MAY change during a session because of other state information (e.g. authentication or server administration). However, a client NNTP MUST not cache (for use in another session) any information returned if the LIST EXTENSIONS command succeeds. That is, a client NNTP MUST issue the LIST EXTENSIONS command at least once during each session to get the current and correct information concerning available extensions during that session. == 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: When a valid group is selected by means of this command, the internally maintained "current article pointer" MUST be set to the first article in the group and the name of the current news group MUST be set to the selected news group name. If an invalid group is specified, the previously selected group and article MUST remain selected. If an empty news group is selected, the "current article pointer" is in an indeterminate state and MUST not be used. == 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: Note that only argument processing is affected by the character set. The server MUST not translate any part of any multi-line response returned to the client based on the current character set. -- 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 (September 1997) is 9691 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) -- Missing reference section? '1' on line 1545 looks like a reference -- Missing reference section? '2' on line 1548 looks like a reference -- Missing reference section? '3' on line 1551 looks like a reference -- Missing reference section? '0-9a-zA-Z' on line 298 looks like a reference -- Missing reference section? 'GMT' on line 1405 looks like a reference -- Missing reference section? '4' on line 1554 looks like a reference -- Missing reference section? '5' on line 1558 looks like a reference -- Missing reference section? '6' on line 1561 looks like a reference -- Missing reference section? '7' on line 1565 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Barber 3 Expires: February 5, 1998 Academ Consulting Services 4 September 1997 6 Network News Transport Protocol 8 draft-ietf-nntpext-base-02.txt 10 1. Status of this Document 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or made obsolete by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To learn the current status of any Internet-Draft, please 25 check the "1id-abstracts.txt" listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 27 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 28 ds.internic.net (US East Coast), or ftp.isi.edu (US West 29 Coast). 31 This document is a product of the NNTP Working Group, chaired 32 by Ned Freed and Stan Barber. 34 2. Abstract 35 The Network News Transport Protocol has been in use in the 36 Internet for a decade and remains one of the most popular 37 protocols (by volume) in use today. This document is a 38 replacement for RFC 977 and officially updates the protocol 39 specification. It clarifies some vagueness in RFC 977, 40 includes some new base functionality and provides a specific 41 mechanism to add standardized extensions to NNTP. 43 3. Introduction 44 This document specifies the Network News Transport Protocol 45 (NNTP), which is used for the distribution, inquiry, 46 retrieval, and posting of Usenet articles using a reliable 47 stream-based mechanism. For news reading clients, NNTP enables 48 retrieval of news articles that are stored in a central 49 database, giving subscribers the ability to select only those 50 articles they wish to read. 52 The netnews model provides for indexing, cross-referencing, 53 and expiration of aged messages. For server-to-server 54 interaction, NNTP is designed for efficient transmission of 55 Usenet articles over a reliable full duplex communication 56 method. 58 Every attempt is made to insure that the protocol 59 specification in this document is compatible with the version 60 specified in RFC 977[1]. 62 Generally, new functionality is available using new keywords. 63 Part of that new functionality involves a mechanism to 64 discover what new functionality is available to clients from a 65 server. 67 This mechanism can also be used to add more functionality as 68 needs merit such additions. 70 In this document, the words that are used to define the 71 significance of each particular requirement are capitalized. 73 These words are: 75 . "MUST" 77 This word or the adjective "REQUIRED" means that the item is 78 an absolute requirement of the specification. 80 . "SHOULD" 82 This word or the adjective "RECOMMENDED" means that there may 83 exist valid reasons in particular circumstances to ignore this 84 item, but the full implications should be understood and the 85 case carefully weighed before choosing a different course. 87 . "MAY" 89 This word or the adjective "OPTIONAL" means that this item is 90 truly optional. One vendor may choose to include the item 91 because a particular marketplace requires it or because it 92 enhances the product, for example; another vendor may omit the 93 same item. 95 An implementation is not compliant if it fails to satisfy one 96 or more of the MUST requirements for this protocol. An 97 implementation that satisfies all the MUST and all the SHOULD 98 requirements for its protocols is said to be "unconditionally 99 compliant"; one that satisfies all the MUST requirements but 100 not all the SHOULD requirements for NNTP is said to be 101 "conditionally compliant". 103 For the remainder of this memo, the term "client host" refers 104 to a host making use of the NNTP service, while the term 105 "server host" refers to a host that offers the NNTP service. 107 4. Basic Operation. 109 Every NNTP session MUST involve the following in this order: 111 CONNECTION 112 GREETING 113 DISCONNECTION 115 Other steps may occur between the GREETING and DISCONNECTION 116 step. They are: 118 CAPABILITIES DISCOVERY 119 AUTHENTICATION 120 NEWS TRANSFER 121 CONCLUSION 123 NNTP operates over any reliable data stream 8-bit-wide 124 channel. When running over TCP/IP, the official port for the 125 NNTP service is 119. Initially, the server host starts the 126 NNTP service by listening on a TCP port. When a client host 127 wishes to make use of the service, it MUST establish a TCP 128 connection with the server host by connecting to that host on 129 the same port on which the server is listening. This is the 130 CONNECTION step. When the connection is established, the NNTP 131 server host MUST send a greeting. This is the GREETING step. 132 The client host and server host then SHOULD then exchange 133 commands and responses (respectively) until the connection is 134 closed or aborted. This final step is called the DISCONNECTION 135 step. 137 If there is a CONCLUSION step, it MUST immediately precede the 138 DISCONNECTION step. There MUST be only one CONNECTION, 139 CONCLUSION and DISCONNECTION step for each NNTP session. All 140 other steps MAY be repeated as needed. 142 The default character set for all NNTP commands is US- 143 ASCII[2]. Commands in the NNTP MUST consist of a case- 144 insensitive keyword, which MAY be followed by one or more 145 arguments. All commands MUST be terminated by a CRLF pair. 146 Multiple commands MUST not be permitted on the same line. 147 Keywords MUST consist of printable US-ASCII characters. 148 Unless otherwise noted elsewhere in this document, Arguments 149 SHOULD consist of printable US-ASCII characters. Keywords and 150 arguments MUST be each separated by one or more SPACE or TAB 151 characters. Keywords MUST be at least three characters and 152 MUST NOT exceed 12 characters. Command lines MUST not exceed 153 512 characters, which includes the terminating CRLF pair. 155 Each response MUST start with a three-digit status indicator 156 that is sufficient to distinguish all responses. Responses to 157 certain commands MAY be multi-line. In these cases, which are 158 clearly indicated below, after sending the first line of the 159 response and a CRLF, any additional lines are sent, each 160 terminated by a CRLF pair. When all lines of the response have 161 been sent, a final line MUST be sent, consisting of a 162 termination octet (ASCII decimal code 046, ".") and a CRLF 163 pair. If any line of the multi-line response begins with the 164 termination octet, the line MUST be "byte-stuffed" by pre- 165 pending the termination octet to that line of the response. 166 Hence, a multi-line response is terminated with the five 167 octets "CRLF.CRLF". When examining a multi-line response, the 168 client MUST check to see if the line begins with the 169 termination octet. If so and if octets other than CRLF follow, 170 the first octet of the line (the termination octet) MUST be 171 stripped away. If so and if CRLF immediately follows the 172 termination character, then the response from the NNTP server 173 is ended and the line containing ".CRLF" MUST not considered 174 part of the multi-line response. 176 A NNTP server MAY have an inactivity autologout timer. Such a 177 timer MUST be of at least 10 minutes duration. The receipt of 178 any command from the client during that interval should 179 suffice to reset the autologout timer. When the timer 180 expires, the server should close the TCP connection without 181 sending any response to the client. 183 4.1 Responses Codes 185 Each response MUST begin with a three-digit response code. 186 These are status reports from the server and indicate the 187 response to the last command received from the client. 189 The first digit of the response broadly indicates the success, 190 failure, or progress of the previous command. 192 1xx - Informative message 193 2xx - Command ok 194 3xx - Command ok so far, send the rest of it. 195 4xx - Command was correct, but couldn't be performed for some 196 reason. 197 5xx - Command unimplemented, or incorrect, or a serious 198 program error occurred. 199 The next digit in the code indicates the function response 200 category. 202 x0x - Connection, setup, and miscellaneous messages 203 x1x - Newsgroup selection 204 x2x - Article selection 205 x3x - Distribution functions 206 x4x - Posting 207 x5x - Authentication and Authorization 208 x8x - Nonstandard (private implementation) extensions 209 x9x - Debugging output 210 The exact response codes that MUST be expected from each 211 command are detailed in the description of the keyword that is 212 the first part of the command. In addition, below is listed a 213 general set of response codes that MAY be received at any 214 time. 216 Certain status responses contain parameters such as numbers 217 and names. The number and type of such parameters SHOULD be 218 fixed for each response code to simplify interpretation of the 219 response. 221 Parameters MUST be separated from the numeric response code 222 and from each other by a single space. All numeric parameters 223 MUST be in base 10 (decimal) format, and may have leading 224 zeros. All string parameters MUST begin after the separating 225 space, and MUST end before the following separating space or 226 the CR-LF pair at the end of the line. (Therefore, string 227 parameters MUST not contain spaces.) All text, if any, in the 228 response which is not a parameter of the response must follow 229 and be separated from the last parameter by a space. Also, 230 note that the text following a response number may vary in 231 different implementations of the server. The 3-digit numeric 232 code should be used to determine what response was sent. 234 Response codes not specified in this standard MAY be used for 235 any installation-specific additional commands also not 236 specified. These SHOULD be chosen to fit the pattern of x8x 237 specified above. (Note that debugging is provided for 238 explicitly in the x9x response codes.) 240 The use of unspecified response codes for a standard command 241 is prohibited. 243 The response pattern x9x is provided for debugging. Since 244 much debugging output may be classed as "informative 245 messages", it MUST be the case that responses 190 through 199 246 WILL be used for various debugging outputs. There is no 247 requirement in this specification for debugging output. 248 However, if such is provided over the connected stream, it 249 MUST use these response codes. If appropriate to a specific 250 implementation, other x9x codes MAY be used for debugging. 251 (For example, response code 290 could be used to acknowledge a 252 remote debugging request.) 254 A server MUST respond to an unrecognized, unimplemented, or 255 syntactically invalid command with a negative status indicator 256 (response codes of the form 5XX). A server MUST respond to a 257 command issued when the session is in an incorrect state by 258 responding with a negative status indicator. This may be from 259 either the 4XX or 5XX group as appropriate. 261 5. The WILDMAT format 263 The WILDMAT format[3] was first developed by Rich Salz based 264 on the format used in the UNIX "find" command to articulate 265 file names. It was developed to provide a uniform mechanism 266 for matching patterns in the same manner that the UNIX shell 267 matches filenames. Patterns are implicitly anchored at the 268 beginning and end of each string when testing for a match. 269 There are five pattern-matching operations other than a strict 270 one-to-one match between the pattern and the source to be 271 checked for a match. The first is an asterisk (*) to match any 272 sequence of zero or more characters. The second is a question 273 mark (?) to match any single character. The third specifies a 274 specific set of characters. The set is specified as a list of 275 characters, or as a range of characters where the beginning 276 and end of the range are separated by a minus (or dash) 277 character, or as any combination of lists and ranges. The dash 278 can also be included in the set as a character if it is the 279 beginning or end of the set. This set is enclosed in square 280 brackets. The close square bracket (]) may be used in a set if 281 it is the first character in the set. The fourth operation is 282 the same as the logical not of the third operation and is 283 specified the same way as the third with the addition of a 284 caret character (^) at the beginning of the test string just 285 inside the open square bracket. The final operation uses the 286 backslash character to invalidate the special meaning of the 287 open square bracket ([), the asterisk, backslash or the 288 question mark. Two backslashes in sequence will result in the 289 evaluation of the backslash as a character with no special 290 meaning. 292 5.1 Examples 294 a) [^]-] -- matches any single character other than a 295 close square bracket or a minus sign/dash. 296 b) *bdc -- matches any string that ends with the string 297 "bdc" including the string "bdc" (without quotes). 298 c) [0-9a-zA-Z] -- matches any single printable alphanumeric 299 ASCII character. 300 d) a??d -- matches any four character string which 301 begins with a and ends with d. 303 6. Format for Keyword Descriptions 305 On the following pages are descriptions of each keyword 306 recognized by the NNTP server and the responses that will be 307 returned by those commands. These keywords are grouped by the 308 functional step in which they are used. 310 Each keyword is shown in upper case for clarity, although case 311 is ignored in the interpretation of commands by the NNTP 312 server. Any parameters are shown in lower case. A parameter 313 shown in [square brackets] is optional. For example, [GMT] 314 indicates that the triglyph GMT may present or omitted. A 315 parameter that may be repeated is followed by an ellipsis. 316 Mutually exclusive parameters are separated by a vertical bar 317 (|) character. For example, ggg| indicates that a 318 group name or a may be specified, but not both. 319 Some parameters may be case or language specific. See RFC 320 1036[4] for these details. 322 In addition, certain commands make use of a pattern for 323 selection of multiple news groups. The pattern in all cases is 324 based on the WILDMAT format introduced by Rich Salz in 1986. 325 Arguments expected to be in wildmat format will be represented 326 by the string wildmat. This format is discussed in detail in 327 section 5 of this memo. 329 7. The GREETING Step 331 7.1 Initial Connection 333 There is no keyword presented by the client upon initial 334 connection to the server. The server MUST present an 335 appropriate response code as a greeting to the client. This 336 response informs the client about what steps the client should 337 take to reach the news exchange step. 339 The server must present a 200 greeting code if the client is 340 authorized to post articles through the use of the POST keyword 341 on this server. 343 The server must present a 201 greeting code if the client is 344 not authorized to post articles using the POST keyword, but no 345 other authentication is required. 347 The server must present a 205 greeting code if the client is 348 required to present authentication before it is permitted to 349 use any keywords available in the news exchange step. 351 The server must present a 502 greeting code if the client is 352 not permitted under any circumstances from interacting with 353 the server. The server should immediately close the connection 354 with the client after presenting this code. 356 In all other cases, the server must present a 400 greeting 357 code. 359 7.1.1 MODE READER 360 MODE READER 362 MODE READER MAY be used by the client to indicate to the 363 server that it is a news reading client. This command may be 364 entered at any time. The server must present a greeting code 365 (as described in section 7.1) appropriate to the server's 366 ability to provide service to this client in this mode. 368 7.1.1.1 Responses 370 200 Hello, you can post 371 201 Hello, you can't post 372 205 Authentication required 373 400 Service temporarily unavailable 374 502 Service unavailable 376 8. The CAPABILITIES DISCOVERY Step 378 A client NNTP supporting NNTP service extensions should query 379 a server early in the session for extensions session by 380 issuing the LIST EXTENSIONS command. If the NNTP server 381 supports the NNTP service extensions it MUST give a successful 382 response (see section 8.1.1), a failure response (see section 383 8.1.2), or an error response (see section 8.1.3). If the NNTP 384 server does not support any NNTP service extensions, it MUST 385 generate an error response (see section 8.1.4). 387 8.1 LIST EXTENSIONS 389 If successful, the server NNTP MUST respond with code 202. On 390 failure, the server NNTP MUST respond with code 503. On error, 391 the server NNTP MUST respond with one of codes 400, 402, 500 392 and 501. 394 This command MAY be issued at anytime during a session. It is 395 not required that the client issues this command before 396 attempting to make use of any extension. The response 397 generated by this command MAY change during a session because 398 of other state information (e.g. authentication or server 399 administration). However, a client NNTP MUST not cache (for 400 use in another session) any information returned if the LIST 401 EXTENSIONS command succeeds. That is, a client NNTP MUST issue 402 the LIST EXTENSIONS command at least once during each session 403 to get the current and correct information concerning 404 available extensions during that session. 406 8.1.1 Successful response 408 If the server NNTP implements and is able to perform the LIST 409 EXTENSIONS command, it MUST return code 202. 411 This response MUST be a multi-line reply. Each line of the 412 response MUST contain a supported keyword and, optionally, one 413 or more parameters. The list MUST end with a period on a line 414 by itself. 416 Although LIST EXTENSIONS keywords may be specified in upper, 417 lower, or mixed case, they must always be recognized and 418 processed in a case-insensitive manner. 420 8.1.2 Failure response 422 If for some reason the server NNTP is unable to list the 423 service extensions it supports, it MUST return code 503. 425 In the case of a failure response, the client NNTP may try the 426 extensions either as the need arises or configure itself for 427 the basic NNTP functionality defined in this document. 429 8.1.3 Error responses from extended servers 431 If the server NNTP recognizes the LIST EXTENSIONS command, but 432 due to various conditions cannot make any extensions available 433 to the client at the time the client issued the LIST 434 EXTENSIONS command, it MUST return code 402. No list (even an 435 empty one) will be returned. 437 The client NNTP should configure itself for the basic NNTP 438 functionality defined in this document, or issue commands that 439 might change the state of the server (authentication, for 440 example), or issue the QUIT command (see section 11.1) if a 441 particular extension is required for the client to properly 442 operate. 444 If the server NNTP determines that the NNTP service is no 445 longer available (e.g., due to imminent system shutdown), it 446 must return code 400. 448 In the case of an error response, the client NNTP should issue 449 the QUIT command (see section 11.1). 451 8.1.4 Responses from servers without extensions 452 A server NNTP that conforms to this memo but does not support 453 the extensions specified here will not recognize the LIST 454 EXTENSIONS command and MUST consequently return code 500 or 455 code 501. The server NNTP SHALL stay in the same state after 456 returning this code. The client NNTP may try the extensions 457 either as the need arises or configure itself for the basic 458 NNTP functionality defined in this document. 460 8.1.5 Responses from improperly implemented servers 462 A server NNTP that improperly implements the LIST EXTENSIONS 463 command may return an empty list. Clients SHALL accommodate 464 this protocol violation and interpret it as a response code 465 402. 467 9. The AUTHENTICATION Step 469 9.1 AUTHINFO 471 AUTHINFO is used to inform a server about the identity of a 472 user of the server. In all cases, clients MUST provide this 473 information when requested by the server. Servers are not 474 required to accept authentication information that is 475 volunteered by the client. Clients MUST accommodate servers 476 that reject any authentication information volunteered by the 477 client. 479 9.1.1 AUTHINFO 481 AUTHINFO USER username 483 AUTHINFO PASS password 485 When authorization is required, the server MUST send a 450 486 response requesting authorization from the client. The client 487 MUST enter AUTHINFO USER username in order to make use of the 488 AUTHINFO authentication step. If the server will accept this 489 form of authentication and a password is required to complete 490 the authentication step, the server MUST respond with a 350 491 response. The client MUST then send AUTHINFO PASS followed by 492 one or more space characters followed by the password. If the 493 username/password combination is valid or no password is 494 required, the server MUST return a 250 response and the client 495 should then retry the original command to which the server 496 responded with the 450 response. The command SHALL then be 497 processed by the server normally. If the combination is not 498 valid, the server MUST return a 452 response. 500 If the server returns 501, this means that the authenticator 501 invocation was syntactically incorrect, or that this form of 502 AUTHINFO is not supported. 504 If the requested authenticator capability is not found or 505 there is some other unspecified server program error, the 506 server MUST return the 503 response code. 508 9.1.1.1 Responses 510 250 Authorization accepted 511 350 Continue with authorization sequence 512 450 Authorization required for this command 513 452 Authorization rejected 514 501 Command not supported or Command Syntax Error 515 502 Program error, function not performed 517 9.1.2 AUTHINFO GENERIC 519 AUTHINFO GENERIC authenticator arguments... 521 AUTHINFO GENERIC is used to identify a specific entity to the 522 server using arbitrary authentication or identification 523 protocols. The desired protocol is indicated by the 524 authenticator parameter, and any number of parameters can be 525 passed to the authenticator. 527 When authorization is required, the server will send a 350 528 response requesting authorization from the client. 530 The client should enter AUTHINFO GENERIC followed by the 531 authenticator name and the arguments if any. The 532 authenticator and arguments must not contain the sequence 533 "..". 535 The server will attempt to engage the server end 536 authenticator; similarly, the client should engage the client 537 end authenticator. The server end authenticator will then 538 initiate authentication using the NNTP sockets (if appropriate 539 for that authentication protocol), using the protocol 540 specified by the authenticator name. These authentication 541 protocols are not included in this document, but are similar 542 in structure to those referenced in RFC 1731[5] for the IMAP-4 543 protocol. 545 If the server returns 501, this means that the authenticator 546 invocation was syntactically incorrect, or that AUTHINFO 547 GENERIC is not supported. The client should retry using the 548 regular AUTHINFO command. 550 If the requested authenticator capability is not found or 551 there is some other unspecified server program error, the 552 server returns the 503 response code. 554 The authenticators converse using their protocol until 555 complete. If the authentication succeeds, the server 556 authenticator will terminate with a 250, and the client can 557 continue by reissuing the command that prompted the 350. If 558 the authentication fails, the server will respond with a 452. 560 The client must provide authentication when requested by the 561 server. The server may request authentication at any time. 562 Servers may request authentication more than once during a 563 single session. 565 When the server authenticator completes, it provides to the 566 server (by a mechanism herein undefined) the email address of 567 the user, and potentially what the user is allowed to access. 568 Once authenticated, the server shall generate a Sender: line 569 using the email address provided by the authenticator if it 570 does not match the user-supplied From: line. Additionally, the 571 server should log the event, including the user's 572 authenticated email address (if available). This will provide 573 a means by which subsequent statistics generation can 574 associate news group references with unique entities - not 575 necessarily by name. 577 9.1.2.1 Responses 578 250 Authorization accepted 579 350 Continue with authorization sequence 580 450 Authorization required for this command 581 452 Authorization rejected 582 501 Command not supported or Command Syntax Error 583 502 Program error, function not performed 584 nnn authenticator-specific protocol. 586 9.1.3 Transition Issues 587 The implementations of AUTHINFO commonly in use prior to the 588 release of this memo have a difference response code set. The 589 code 281 was used in place of 250, 381 was used in place of 590 350, 480 was used in place of 450 and 482 was used in place of 591 452. Client coded to be compliant with this spec may also want 592 to be able to accommodate the older codes to lessen the impact 593 of the transition to this specification. 595 10. The NEWS EXCHANGE Step 597 During this step, two basic types of transactions occur: 599 article retrieval from the server and article posting to the 600 server. 602 10.1 Article Retrieval 604 News reading clients have available a variety of mechanisms to 605 retrieve articles via NNTP. The news articles are stored and 606 indexed using three types of keys. One key is the message id 607 of an article. According to RFC 1036, this identifier should 608 be globally unique. Another key is composed of the news group 609 name and the article number within that news group. That key 610 MUST be unique to a particular server (there will be only one 611 article with that number within a particular news group), but 612 is not required to be globally unique. Additionally, because 613 the same article can be cross-posted to multiple news groups, 614 there may be multiple keys that point to the same article on 615 the same server. The final key is the arrival timestamp, 616 giving the time that the article arrived at the server. 618 The server MUST ensure that article numbers are issued in 619 order of arrival timestamp; that is, articles arriving later 620 MUST have higher numbers than those that arrive earlier. The 621 server SHOULD allocate the first unused number to each new 622 article. 624 Article numbers MUST lie between 1 and 4,294,967,295 625 inclusive. The client and server SHOULD NOT use leading zeroes 626 in specifying article numbers, and MUST NOT use more than 16 627 digits. In some situations, the value zero replaces an article 628 number to show some special situation 630 10.1.1 Article Retrieval by News Group Name and Article Number 632 The following commands are used to set the current news group 633 name and the "current article pointer" which is used by other 634 commands for article retrieval. 636 10.1.1.1 GROUP 638 GROUP ggg 640 The required parameter ggg is the name of the news group to be 641 selected (e.g. "news.software.b"). A list of valid news groups 642 may be obtained by using the LIST keyword. See section 10.4 for 643 more information on the LIST keyword. 645 The successful selection response will return the article 646 numbers of the first and last articles in the group at the 647 moment of selection (these numbers are referred to as the 648 "reported low water mark" and the "reported high water mark"), 649 and an estimate of the number of articles on file in the 650 group. 652 If the group is not empty, the estimate MUST be at least the 653 actual number of articles available, and MUST be no greater 654 than one more than the difference between the reported low and 655 high water marks. (Some implementations will actually count 656 the number of articles on file. Others will just subtract the 657 low water mark from the high water mark and add one to get an 658 estimate.) 660 If the group is empty, one of the following three situations 661 will occur. Clients MUST accept all three cases; servers MUST 662 NOT represent an empty group in any other way. 664 . The high water mark will be one less than the low water mark, 665 and the estimated article count will be zero. Servers SHOULD 666 use this method to show an empty group. This is the only time 667 that the high water mark can be less than the low water mark. 668 . All three numbers will be zero. 669 . The high water mark is greater than or equal to the low water 670 mark; the estimated article count might be zero or non-zero; 671 if non- zero, the same requirements apply as for a non-empty 672 group. 674 The set of articles in a group may change after the GROUP 675 command is carried out. That is: 677 . articles may be removed from the group; 678 . articles may be reinstated in the group with the same article 679 number, but those articles MUST have numbers no less than the 680 reported low water mark (note that this is a reinstatement of 681 the previous article, not a new article reusing the number); 682 . new articles may be added with article numbers greater than 683 the reported high water mark (if an article that was the one 684 with the highest number has been removed, the next new article 685 will not have the number one greater than the reported high 686 water mark). 687 Except when the group is empty and all three numbers are zero, 688 whenever a subsequent GROUP command for the same news group is 689 issued, either by the same client or a different client, the 690 reported low water mark in the response MUST be no less than 691 that in any previous response for that news group sent to any 692 client. The client may make use of the low water mark to 693 remove all remembered information about articles with lower 694 numbers, as these will never recur. This includes the 695 situation when the high water mark is one less than the low 696 water mark. 698 No similar assumption can be made about the high water mark, 699 as this can decrease if an article is removed, and then 700 increase again if it is reinstated or if new articles arrive. 702 When a valid group is selected by means of this command, the 703 internally maintained "current article pointer" MUST be set to 704 the first article in the group and the name of the current 705 news group MUST be set to the selected news group name. If an 706 invalid group is specified, the previously selected group and 707 article MUST remain selected. If an empty news group is 708 selected, the "current article pointer" is in an indeterminate 709 state and MUST not be used. 711 The GROUP keyword MUST be used by a client and a successful 712 response received before the any other command is used that 713 depends on having the "current article pointer" be valid. 715 10.1.1.1.1 Responses 717 211 n f l s group selected 718 (n = estimated number of articles in group, f = first 719 article number in the group, l = last article number in 720 the group, s = name of the group.) 721 411 no such news group 723 10.1.1.2 LAST 725 LAST 727 The internally maintained "current article pointer" MUST be 728 set to the previous article in the current news group. If 729 already positioned at the first article of the news group, an 730 error message MUST be returned and the current article MUST 731 remain selected. 733 There MAY be no previous article in the group, although the 734 current article number is not the reported low water mark. 735 There MUST NOT be a previous article when the current article 736 number is the reported low water mark. 738 Because articles can be removed and added, the results of 739 multiple LAST and NEXT commands MAY not be consistent over the 740 life of a particular NNTP session. 742 The internally-maintained "current article pointer" MUST be 743 set by this command. 745 A response indicating the current article number and a 746 message-id string MUST be returned. No text is sent in 747 response to this command. 749 10.1.1.2.1 Responses 751 223 n a article retrieved - request text separately (n = 752 article number, a = unique article id) 753 412 no news group selected 754 420 no current article has been selected 755 422 no previous article in this group 757 10.1.1.3 NEXT 759 NEXT 761 The internally maintained "current article pointer" MUST be 762 advanced to the next article in the current news group. If no 763 more articles remain in the current group, an error message 764 MUST be returned and the current article MUST remain selected. 766 The internally-maintained "current article pointer" MUST be 767 set by this command. 769 A response indicating the current article number and the 770 message-id string MUST be returned. No text is sent in 771 response to this command. 773 10.1.1.3.1 Responses 775 223 n a article retrieved - request text separately (n = 776 article number, a = unique article id) 777 412 no news group selected 778 420 no current article has been selected 779 421 no next article in this group 781 10.2 Retrieval of Articles and Article Sections 783 There are two forms to the ARTICLE command (and the related 784 BODY, HEAD, and STAT commands), each using a different method 785 of specifying which article is to be retrieved. When the 786 ARTICLE keyword is followed by a message-id in angle brackets 787 ("<" and ">"), the first form of the command MUST be used; 788 when a numeric parameter or no parameter is supplied, the 789 second form MUST be invoked. 791 An article, as defined by RFC 1036, consists of two parts: the 792 article headers and the article body. When responding to an 793 article command, the server returns the entire article 794 contents and does not attempt to alter or translate them in 795 any way. 797 The HEAD and BODY commands are identical to the ARTICLE 798 command except that they respectively return only the article 799 headers or the article body of the article. 801 The STAT command is similar to the ARTICLE command except that 802 no text is returned. When selecting by message number within 803 a group, the STAT command MUST set the current article pointer 804 without sending text. The returned acknowledgment response 805 MUST contain the message-id, which may be of some value. 806 Using the STAT command to select by message-id is valid but of 807 questionable value, since a selection by message-id MUST NOT 808 alter the "current article pointer". 810 10.2.1 ARTICLE 812 ARTICLE [|nnn] 814 This response displays the header, a blank line, then the body 815 (text) of the specified article. The optional parameter nnn is 816 the numeric id of an article in the current news group and 817 MUST be chosen from the range of articles provided when the 818 news group was selected. If it is omitted, the current 819 article is assumed. Message-id is the message id of an article 820 as shown in that article's header. 822 Please note that the internally-maintained "current article 823 pointer" MUST NOT be altered when the message-id argument is 824 used. This is both to facilitate the presentation of articles 825 that may be referenced within an article being read, and 826 because of the semantic difficulties of determining the proper 827 sequence and membership of an article which may have been 828 posted to more than one news group. 830 The internally-maintained "current article pointer" MUST be 831 set when a valid article number is specified as the argument. 832 This includes the case when an article number is implied by 833 the use of no argument. 835 A previously valid article number MAY not remain valid if the 836 article has been removed. A previously invalid article number 837 MAY become valid if the article has been reinstated, but such 838 an article number MUST be no less than the reported low water 839 mark for that group. 841 A response indicating the current article number, a message-id 842 string, and that text is to follow MUST be returned. 844 The message-id string returned is an identification string 845 contained within angle brackets ("<" and ">"), which is 846 derived from the header of the article itself. The Message-ID 847 header line (required by RFC 1036) from the article must be 848 used to supply this information. If the message-id header line 849 is missing from the article, a single digit "0" (zero) should 850 be supplied within the angle brackets. 852 Since the message-id field is unique for each article, it may 853 be used by a news reading program to skip duplicate displays 854 of articles that have been posted more than once, or to more 855 than one news group. 857 10.2.1.1 Responses 859 220 n article retrieved - head and body follow (n = 860 article number, = message-id) 861 221 n article retrieved - head follows 862 222 n article retrieved - body follows 863 223 n article retrieved - request text separately 864 412 no news group has been selected 865 420 no current article has been selected 866 423 no such article number in this group 867 430 no such article found 869 10.3 Article Posting 871 Article posting is done in one of two modes: individual 872 article posting from news reading clients and article transfer 873 from other news servers. 875 10.3.1 POST 877 POST 879 If posting is allowed, response code 340 MUST be returned to 880 indicate that the article to be posted should be sent. 881 Response code 440 MUST be sent if that posting is prohibited 882 for some installation-dependent reason. 884 If posting is permitted, the article MUST be presented in the 885 format specified by RFC 1036, and MUST include all required 886 header lines. After the article's header and body have been 887 completely sent by the client to the server, a further 888 response code MUST be returned to indicate success or failure 889 of the posting attempt. 891 The text forming the header and body of the message to be 892 posted MUST be sent by the client using the conventions for 893 text received from the news server: A single period (".") on a 894 line indicates the end of the text, with lines starting with a 895 period in the original text having that period doubled during 896 transmission. 898 No attempt shall be made by the server to filter characters, 899 fold or limit lines, or otherwise process incoming text. The 900 intent is that the server just passes the incoming message to 901 be posted to the server installation's news posting software, 902 which is not part of this specification. 904 10.3.1.1 Responses 906 240 article posted ok 907 340 send article to be posted. End with . 908 440 posting not allowed 909 441 posting failed 911 10.3.2 IHAVE 913 IHAVE 915 The IHAVE command informs the server that the client has an 916 article whose id is . If the server desires a copy 917 of that article, it MUST return a response instructing the 918 client to send the entire article. If the server does not want 919 the article (if, for example, the server already has a copy of 920 it), a response indicating that the article is not wanted MUST 921 be returned. 923 If transmission of the article is requested, the client MUST 924 send the entire article, including header and body, in the 925 manner specified for text transmission from the server. A 926 response code indicating success or failure of the transferal 927 of the article MUST be returned by the server. 929 This function differs from the POST command in that it is 930 intended for use in transferring already-posted articles 931 between hosts. Normally it will not be used when the client is 932 a personal news reading program. In particular, this function 933 will invoke the server's news posting program with the 934 appropriate settings (flags, options, etc.) to indicate that 935 the forthcoming article is being forwarded from another host. 937 However, the server may elect not to post or forward the 938 article if after further examination of the article it deems 939 it inappropriate to do so. The 436 or 437 error codes MUST be 940 returned as appropriate to the situation. 942 Reasons for such subsequent rejection of an article may 943 include such problems as inappropriate news groups or 944 distributions, disk space limitations, article lengths, 945 garbled headers, and the like. These are typically 946 restrictions enforced by the server host's news software and 947 not necessarily the NNTP server itself. 949 10.3.2.1 Responses 951 235 article transferred ok 952 335 send article to be transferred. End with . 954 435 article not wanted - do not send it 955 436 transfer failed - try again later 956 437 article rejected - do not try again 958 Because some host news posting software may not be able to 959 immediately render status on the whether an article is 960 inappropriate for posting or forwarding, an NNTP server MAY 961 acknowledge the successful transfer of the article and later 962 silently discard it. Thus an NNTP server may return the 235 963 acknowledgment code and later discard the received article. 965 10.4 The LIST Keyword 967 10.4.1 LIST 969 LIST [ACTIVE [wildmat]] 971 The response to the LIST keyword with no parameters returns a 972 list of valid news groups and associated information. Each 973 news group is sent as a line of text in the following format: 975 group last first status 977 where is the name of the news group, is the 978 number of the last known article currently in that news group, 979 is the number of the first article currently in the 980 news group, and indicates the current status of the 981 group on this server. Typically, the will be consist 982 of the ASCII character `y' where posting is permitted, `n' 983 where posting is not permitted and `m' where postings will be 984 forwarded to the news group moderator by the news server. 985 Other status strings exist and their definition is outside the 986 scope of this specification. 988 The and fields will always be numeric. They 989 may have leading zeros. If the field evaluates to less 990 than the field, there are no articles currently on 991 file in the news group. 993 Note that posting may still be prohibited to a client although 994 the LIST command indicates that posting is permitted to a 995 particular news group. See the POST command for an explanation 996 of client prohibitions. The posting flag exists for each news 997 group because some news groups are moderated or are digests, 998 and therefore cannot be posted to; that is, articles posted to 999 them must be mailed to a moderator who will post them for the 1000 original poster. This is independent of the posting 1001 permission granted to a client by the NNTP server. 1003 Please note that an empty list (i.e., the text body returned 1004 by this command consists only of the terminating period) is a 1005 possible valid response, and indicates that there are 1006 currently no valid news groups. 1008 If the optional matching parameter is specified, the list is 1009 limited to only the groups that match the pattern. 1011 Specifying a single group is usually very efficient for the 1012 server, and multiple groups may be specified by using wildmat 1013 patterns (described in section 5), not regular expressions. 1015 10.4.1.1 Responses 1016 215 list of news groups follows 1018 10.4.2 LIST ACTIVE.TIMES 1020 LIST ACTIVE.TIMES [wildmat] 1022 The active.times file is maintained by some news transports 1023 systems to contain information about the when and who created 1024 a particular news group. The format of this file generally 1025 includes three fields. The first field is the name of the news 1026 group. The second is the time when this group was created on 1027 this news server measured in seconds since January 1, 1970. 1028 The third is the email address of the entity that created the 1029 news group. When executed, the information is displayed 1030 following the 215 response. When display is completed, the 1031 server will send a period on a line by itself. If the 1032 information is not available, the server will return the 503 1033 error response. 1035 If the optional matching parameter is specified, the list is 1036 limited to only the groups that match the pattern. 1038 Specifying a single group is usually very efficient for the 1039 server, and multiple groups may be specified by using wildmat 1040 patterns (described in section 5), not regular expression 1042 10.4.2.1 Responses 1044 215 information follows 1045 503 program error, function not performed 1047 10.4.3 LIST DISTRIBUTIONS 1048 LIST DISTRIBUTIONS 1050 The distributions file is maintained by some news transport 1051 systems to contain information about valid values for the 1052 Distribution: line in a news article header and about what the 1053 values mean. Each line contains two fields, the value and a 1054 short explanation on the meaning of the value. When executed, 1055 the information is displayed following the 215 response. When 1056 display is completed, the server will send a period on a line 1057 by itself. If the information is not available, the server 1058 will return the 503 error response. 1060 10.4.3.1 Responses 1062 215 information follows 1063 503 program error, function not performed 1065 10.4.4 LIST DISTRIB.PATS 1067 LIST DISTRIB.PATS 1069 The distrib.pats file is maintained by some news transport 1070 systems to contain default values for the Distribution: line 1071 in a news article header when posting to particular news 1072 groups. This information could be used to provide a default 1073 value for the Distribution: line in the header when posting an 1074 article. The information returned contains three fields 1075 separated by colons. The first column is a weight. The second 1076 is a group name or a wildmat pattern that can be used to match 1077 a group name. The third is the value of the Distribution: 1078 line that should be used when the group name matches and the 1079 weight value is the highest. All this processing is done by 1080 the news posting client and not by the server itself. The 1081 server provides this information to the client for it to use 1082 or ignore as it chooses. When executed, the information is 1083 displayed following the 215 response. When display is 1084 completed, the server will send a period on a line by itself. 1085 If the information is not available, the server will return 1086 the 503 error response. 1088 10.4.4.1 Responses 1090 215 information follows 1091 503 program error, function not performed 1093 10.4.5 LIST NEWSGROUPS 1095 LIST NEWSGROUPS [wildmat] 1096 The newsgroups file is maintained by some news transport 1097 systems to contain the name of each news group that is 1098 active on the server and a short description about the 1099 purpose of each news group. Each line in the file contains 1100 two fields, the news group name and a short explanation of 1101 the purpose of that news group. When executed, the 1102 information is displayed following the 215 response. When 1103 display is completed, the server will send a period on a 1104 line by itself. If the information is not available, the 1105 server will return the 503 response. If the optional 1106 matching parameter is specified, the list is limited to only 1107 the groups that match the pattern (no matching is done on 1108 the group descriptions). Specifying a single group is 1109 usually very efficient for the server, and multiple groups 1110 may be specified by using wildmat patterns (see section 5), 1111 not regular expressions. If nothing is matched an empty list 1112 is returned, not an error. 1114 10.4.5.1 Responses 1116 215 information follows 1117 503 program error, function not performed 1119 10.4.6 LIST OVERVIEW.FMT 1121 LIST OVERVIEW.FMT 1123 The overview.fmt file is maintained by some news transport 1124 systems to contain the order in which header information is 1125 stored in the overview databases for each news group. When 1126 executed, news article header fields are displayed one line at 1127 a time in the order in which they are stored in the overview 1128 database[6] following the 215 response. When display is 1129 completed, the server will send a period on a line by itself. 1130 If the information is not available, the server will return 1131 the 503 response. 1133 Please note that if the header has the word "full" (without 1134 quotes) after the colon, the header's name is prepended to its 1135 field in the output returned by the server. 1137 10.4.6.1 Responses 1139 215 information follows 1140 503 program error, function not performed 1142 10.4.7 LIST SUBSCRIPTIONS 1144 LIST SUBSCRIPTIONS 1145 This command is used to get a default subscription list for 1146 new users of this server. The order of groups is significant. 1148 When this list is available, it is preceded by the 215 1149 response and followed by a period on a line by itself. When 1150 this list is not available, the server returns a 503 response 1151 code. 1153 10.4.7.1 Responses 1155 215 information follows 1156 503 program error, function not performed 1158 10.4.8 LISTGROUP 1160 LISTGROUP [ggg] 1162 The LISTGROUP command is used to get a listing of all the 1163 article numbers in a particular news group. 1165 The optional parameter ggg is the name of the news group to 1166 be selected (e.g. "news.software.b"). A list of valid news 1167 groups may be obtained from the LIST command. If no group is 1168 specified, the current group is used as the default 1169 argument. 1171 The successful selection response will be a list of the 1172 article numbers in the group followed by a period on a line 1173 by itself. 1175 When a valid group is selected by means of this command, the 1176 internally maintained "current article pointer" MUST be set 1177 to the first article in the group. If an invalid group is 1178 specified, the previously selected group and article remain 1179 selected. If an empty news group is selected, the "current 1180 article pointer" may be in an indeterminate state and should 1181 not be used. 1183 Note that the name of the news group is not case-dependent. 1184 It must otherwise match a news group obtained from the LIST 1185 command or an error will result. 1187 10.4.8.1 Responses 1189 211 list of article numbers follow 1190 412 Not currently in news group 1192 10.4.9 OVER 1194 OVER [range] 1195 The OVER command returns information from the overview 1196 database for the article(s) specified. The information 1197 returned in the response to this command can be used by 1198 clients to follow discussion threads. 1200 The optional range argument may be any of the following: 1202 . an article number 1203 . an article number followed by a dash to indicate all following 1204 . an article number followed by a dash followed by another 1205 article number 1206 If no argument is specified, then information from the current 1207 article is displayed. Successful responses start with a 224 1208 response followed by the overview information for all matched 1209 messages. Once the output is complete, a period is sent on a 1210 line by itself. If no argument is specified, the information 1211 for the current article is returned. A news group must have 1212 been selected earlier, else a 412 error response is returned. 1213 If no articles are in the range specified, a 420 error 1214 response is returned by the server. A 502 response will be 1215 returned if the client only has permission to transfer 1216 articles. 1218 Each line of output MUST be formatted with the article number, 1219 followed by each of the headers in the overview database or 1220 the article itself (when the data is not available in the 1221 overview database) for that article separated by a tab 1222 character. The sequence of fields must be in this order: 1223 subject, author, date, message-id, references, byte count, and 1224 line count. Other optional fields may follow line count. Where 1225 no data exists, a null field must be provided (i.e. the output 1226 will have two tab characters adjacent to each other). Servers 1227 should not output fields for articles that have been removed 1228 since the overview database was created. 1230 10.4.9.1 Responses 1232 224 Overview information follows 1233 412 No news group current selected 1234 420 No article(s) selected 1235 502 no permission 1237 10.4.10 PAT 1239 PAT header range| [pat [pat...]] 1241 The PAT command is used to retrieve specific headers from 1242 specific articles, based on pattern matching on the contents 1243 of the header. 1245 The required header parameter is the name of a header line 1246 (e.g. "subject") in a news group article. See RFC-1036 for a 1247 list of valid header lines. The required range argument may be 1248 any of the following: 1250 . an article number 1251 . an article number followed by a dash to indicate all following 1252 . an article number followed by a dash followed by another 1253 article number. 1254 The required message-id argument indicates a specific article. 1255 The range and message-id arguments are mutually exclusive. If 1256 there are additional arguments, they are joined together 1257 separated by a single space to form one complete pattern. If 1258 there are no additional arguments, a wildmat "*" is the 1259 default. Successful responses start with a 221 response 1260 followed by the headers from all messages in which the pattern 1261 matched the contents of the specified header line. This 1262 includes an empty list. Once the output is complete, a period 1263 is sent on a line by itself. If the optional argument is a 1264 message-id and no such article exists, the 430 error response 1265 shall be returned. A 502 response shall be returned if the 1266 client only has permission to transfer articles. 1268 10.4.10.1 Responses 1270 221 Header follows 1271 430 no such article 1272 502 no permission 1274 11. The CONCLUSION Step 1276 11.1 QUIT 1278 QUIT 1280 The server process MUST acknowledge the QUIT command and then 1281 closes the connection to the client. This is the preferred 1282 method for a client to indicate that it has finished all its 1283 transactions with the NNTP server. 1285 If a client simply disconnects (or the connection times out or 1286 some other fault occurs), the server SHALL gracefully cease 1287 its attempts to service the client. 1289 11.1.1 Responses 1291 205 closing connection - goodbye! 1293 12. Other Keywords 1294 There are other Keywords that may be used at any time between 1295 the beginning of a session and its termination. Using these 1296 keywords do not alter any state information, but the response 1297 generated from the use of these keywords may provide useful 1298 information to clients that use them. 1300 12.1 CHARSET 1302 CHARSET [charset] 1304 The CHARSET command is used to change the default character 1305 set for certain types of arguments: group names and the 1306 contents of article headers. The argument must be the name of 1307 a character set registered with the IANA. The server MUST 1308 return 204 if the specified character set is supported. 1309 Otherwise, the server MUST return 404. 1311 When used as arguments to commands, group names and the 1312 contents of article headers MUST be decoded before comparing 1313 text in a character set other than US-ASCII. US-ASCII must be 1314 supported; other character sets may be supported. 1316 The use of CHARSET with no argument will reset the default 1317 character set to US-ASCII. 1319 Note that only argument processing is affected by the 1320 character set. The server MUST not translate any part of any 1321 multi-line response returned to the client based on the 1322 current character set. 1324 12.1.1 Responses 1325 204 Character set is now charset 1326 404 Character set charset is not supported by this 1327 server 1328 500 Command not supported 1330 12.2 DATE 1332 DATE 1334 This command exists to help clients find out the current time 1335 from the server's perspective. This command should not be 1336 used as a substitute for NTP[7], but to provide information 1337 that might be useful when using the NEWNEWS command (see 1338 section 12.5). 1340 This command returns a one-line response code of 111 followed 1341 by the GMT date and time on the server in the form 1342 YYYYMMDDhhmmss. 1344 12.2.1 Responses 1346 111 YYYYMMDDhhmmss 1348 12.3 The HELP Command 1350 HELP 1352 This command provides a short summary of commands that are 1353 understood by this implementation of the server. The help text 1354 will be presented as a textual response terminated by a single 1355 period on a line by itself. 1357 This text is not guaranteed to be in any particular format and 1358 shall not be used by clients as a replacement for the LIST 1359 EXTENSIONS command described in section 8. 1361 12.3.1 Responses 1363 100 help text follows 1365 12.4 NEWGROUPS 1367 NEWGROUPS date time [GMT] [] 1369 A list of newsgroups created since MUST be 1370 listed in the same format as the LIST command. 1372 The date is sent as 6 or 8 digits in the format [XX]YYMMDD, 1373 where XX is the first two digits of the year, YY is the last two 1374 digits of the year, MM is the two digits of the month (with 1375 leading zero, if appropriate), and DD is the day of the month 1376 (with leading zero, if appropriate). If the first two digits 1377 of the year are not specified, the closest century is assumed 1378 as part of the year (i.e., 86 specifies 1986, 30 specifies 1379 2030, 99 is 1999, 00 is 2000). 1381 Time must also be specified. It must be as 6 digits HHMMSS 1382 with HH being hours on the 24-hour clock, MM minutes 00-59, 1383 and SS seconds 00-59. The time is assumed to be in the 1384 server's timezone unless the token "GMT" appears in which case 1385 both time and date are evaluated at the 0 meridian. 1387 An optional parameter may be specified at the end of the 1388 command line consisting of a wildmat pattern against which new 1389 newsgroup names can be matched enclosed in angle brackets. 1390 Only those news groups that have names that match the pattern 1391 (and any other criteria specified in the command) will be 1392 returned. 1394 Please note that an empty list (i.e., the text body returned 1395 by this command consists only of the terminating period) is a 1396 possible valid response, and indicates that there are 1397 currently no new newsgroups. 1399 12.4.1 Responses 1401 231 list of new newsgroups follows 1403 12.5 NEWNEWS 1405 NEWNEWS newsgroups date time [GMT] [] 1407 A list of message-ids of articles posted or received to the 1408 specified news group since "date" will be listed. The format 1409 of the listing will be one message-id per line, as though text 1410 were being sent. A single line consisting solely of one 1411 period followed by CR-LF will terminate the list. 1413 Date and time are in the same format as the NEWGROUPS command. 1414 The newsgroups parameter must be in wildmat format. 1416 The optional parameter "distributions" is a list of 1417 distribution groups, enclosed in angle brackets. If 1418 specified, the distribution portion of an article's header 1419 will be examined for a match with the distribution categories 1420 listed, and only those articles which have a distribution in 1421 the list will be listed. If more than one distribution is to 1422 be supplied, they must be separated by commas within the angle 1423 brackets. 1425 The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to 1426 distribute news is discussed in an earlier part of this 1427 document. 1429 Please note that an empty list (i.e., the text body returned 1430 by this command consists only of the terminating period) is a 1431 possible valid response, and indicates that there is currently 1432 no new news. 1434 12.5.1 Responses 1436 230 list of new articles by message-id follows 1437 13. Framework for NNTP Extensions 1439 Although NNTP is widely and robustly deployed, some parts of 1440 the Internet community might wish to extend the NNTP service. 1441 This memo defines a means whereby an extended NNTP client may 1442 query the server to determine the service extensions that it 1443 supports. 1445 It must be emphasized that any extension to the NNTP service 1446 should not be considered lightly. NNTP's strength comes 1447 primarily from its simplicity. Experience with many protocols 1448 has shown that: 1450 Protocols with few options tend towards ubiquity, whilst 1451 protocols with many options tend towards obscurity. 1453 This means that each and every extension, regardless of its 1454 benefits, must be carefully scrutinized with respect to its 1455 implementation, deployment, and interoperability costs. In 1456 many cases, the cost of extending the NNTP service will likely 1457 outweigh the benefit. 1459 Given this environment, the framework for the extensions 1460 described in this memo consists of: 1462 a) a mechanism for clients to determine a server's available 1463 extensions 1464 b) a registry of NNTP service extensions 1466 The LIST EXTENSIONS command is described in section 8 of this 1467 memo and is the mechanism for clients to use to determine what 1468 extensions are available for client use. 1470 The IANA shall maintain a registry of NNTP service extensions. 1472 Associated with each such extension is a corresponding NNTP 1473 keyword value. Each service extension registered with the IANA 1474 MUST be defined in an RFC. Such RFCs either must be on the 1475 standards-track or must define an IESG-approved experimental 1476 protocol. The definition must include: 1478 . the textual name of the NNTP service extension; 1479 . the NNTP keyword value associated with the extension; 1480 . the syntax and possible values of parameters associated with 1481 the NNTP keyword value; 1482 . any additional NNTP verbs associated with the extension 1483 . (additional verbs will usually be, but are not required to be, 1484 the same as the NNTP keyword value); 1485 . any new parameters the extension associated with any other 1486 NNTP verbs; 1487 . how support for the extension affects the behavior of a server 1488 and client NNTP; and, 1489 . the increment by which the extension is increasing the maximum 1490 length of the any commands over that specified in this 1491 document. 1492 In addition, any NNTP keyword value that starts with an upper 1493 or lower case "X" refers to a local NNTP service extension, 1494 which is used through bilateral, rather than standardized, 1495 agreement. Keywords beginning with "X" may not be used in a 1496 registered service extension. 1498 Any keyword values presented in the NNTP response that do not 1499 begin with "X" must correspond to a standard, standards-track, 1500 or IESG-approved experimental NNTP service extension 1501 registered with IANA. A conforming server must not offer non 1502 "X" prefixed keyword values that are not described in a 1503 registered extension. 1505 Additional verbs are bound by the same rules as NNTP keywords; 1506 specifically, verbs beginning with "X" are local extensions 1507 that may not be registered or standardized and verbs not 1508 beginning with "X" must always be registered. 1510 13.1 Initial IANA Registry 1512 The IANA's initial registry of NNTP service extensions 1513 consists of these entries: 1515 Service Extension NNTP Keyword(s) Added Behavior 1517 Overview Support OVER Defined in this 1518 LIST OVERVIEW.FMT document 1520 Specific Article LISTGROUP Defined in this 1521 Numbers document 1523 Identification and AUTHINFO Defined in this 1524 Authentication AUTHINFO GENERIC document 1526 Character Set CHARSET Defined in this 1527 Selection document 1529 Header Pattern PAT Defined in this 1530 Matching document 1532 14. Security Considerations 1534 The use of the AUTHINFO is optional. This command as 1535 documented has a number of security implications. In the 1536 original and simple forms, all passwords are passed in plain 1537 text and could be discovered by various forms of network or 1538 system surveillance. The AUTHINFO GENERIC command has the 1539 potential for the same problems if a mechanism is used that 1540 also passes clear text passwords. RFC 1731 discusses these 1541 issues in greater detail. 1543 15. References 1545 [1] Kantor, B and P. Lapsley, "Network News Transfer 1546 Protocol", RFC-977, U.C. San Diego and U.C. Berkeley. 1548 [2] Coded Character Set"7-bit American Standard Code for 1549 Information Interchange, ANSI x3.4-1986. 1551 [3] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 1552 distribution, UUNET Technologies, Revision 1.10, April, 1992. 1554 [4] Horton, M.R. and R. Adams, "Standard for interchange of 1555 USENET messages", RFC-1036, AT&T Bell Laboratories and Center 1556 for Seismic Studies, December, 1987. 1558 [5] Meyers, J, "IMAP4 Authentication Mechanisms", RFC-1731, 1559 Carnegie Mellon, December, 1994. 1561 [6] Robertson, Rob, "FAQ: Overview database / NOV General 1562 Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq- 1563 nov.Z, January, 1995. 1565 [7] Mills, David L., "Network Time Protocol (Version 3), 1566 Specification,Implementation and Analysis", RFC-1305, 1567 University of Delaware, March 1992. 1569 15.1 Notes 1571 DEC is a registered trademark of Digital Equipment 1572 Corporation. 1574 UNIX is a registered trademark of the Open Group. 1576 VMS is a registered trademark of Digital Equipment 1577 Corporation. 1579 15.2 Acknowledgments 1581 The author acknowledges the original authors of NNTP as 1582 documented in RFC 977: Brian Kantor and Phil Lapsey. 1584 The author gratefully acknowledges the work of the NNTP 1585 committee chaired by Eliot Lear. The organization of this 1586 document was influenced by the last available draft from this 1587 working group. A special thanks to Eliot for generously 1588 providing the original machine readable sources for that 1589 document. 1591 The author gratefully acknowledges the work of the Marshall 1592 Rose & John G. Meyers in RFC 1939 and the work of the DRUMS 1593 working group, specifically RFC 1869, which is the basis of 1594 the NNTP extensions mechanism detailed in this document. 1596 The author gratefully acknowledges the comments and additional 1597 information provided by the following individuals in preparing 1598 one of the progenitors of this document: 1600 . Wayne Davison 1601 . Clive D.W. Feather 1602 . Chris Lewis 1603 . Tom Limoncelli 1604 . Eric Schnoebelen 1605 . Rich Salz 1607 This work was precipitated by the work of various newsreader 1608 authors and newsserver authors, which includes those listed 1609 below: 1611 . Rick Adams -- Original author of the NNTP extensions to the RN 1612 newsreader and last maintainer of Bnews 1613 . Stan Barber -- Original author of the NNTP extensions to the 1614 newsreaders that are part of Bnews. 1615 . Geoff Collyer -- Original author of the OVERVIEW database 1616 proposal and one of the original authors of CNEWS 1617 . Dan Curry -- Original author of the xvnews newsreader 1618 . Wayne Davision -- Author of the first threading extensions to the 1619 RN newsreader (commonly called TRN). 1620 . Geoff Huston -- Original author of ANU NEWS 1621 . Phil Lapsey -- Original author of the UNIX reference 1622 implementation 1623 . Ian Lea -- Maintainer of the TIN newsreader 1624 . Chris Lewis -- First known implementor of the AUTHINFO GENERIC 1625 extension 1626 . Rich Salz -- Original author of INN 1627 . Henry Spencer -- One of the original authors of CNEWS 1628 . Kim Storm -- Original author of the NN newsreader 1630 15.3 Author's Address 1632 Stan Barber 1633 P.O. Box 300481 1634 Houston, Texas, 77230 1635 Email: 1637 This document expires February 5, 1998.