idnits 2.17.1 draft-barber-nntp-news-00.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-04-24) 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 30 longer pages, the longest (page 2) 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 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [GMT], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 98: '...e or more of the MUST requirements for...' RFC 2119 keyword, line 99: '...hat satisfies all the MUST and all the...' RFC 2119 keyword, line 100: '... SHOULD requirements for...' RFC 2119 keyword, line 102: '... MUST requirements but n...' RFC 2119 keyword, line 112: '...ery NNTP session MUST involve the foll...' (116 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 326 has weird spacing: '...es that a gro...' == Line 414 has weird spacing: '...st once durin...' == Line 529 has weird spacing: '...ication or...' == 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: 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 and arguments MUST consist of printable 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 a total of 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 which 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.(String parameters MUST not, therefore, 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 issue 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, 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. -- 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 1996) is 10083 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 1450 looks like a reference -- Missing reference section? '2' on line 1452 looks like a reference -- Missing reference section? 'GMT' on line 1308 looks like a reference -- Missing reference section? '3' on line 1455 looks like a reference -- Missing reference section? '4' on line 1458 looks like a reference -- Missing reference section? '5' on line 1059 looks like a reference -- Missing reference section? '6' on line 1464 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT S.Barber 2 Expires: February 1, 1997 Academ Consulting Services 3 September 1996 5 Network News Transport Protocol 6 8 1. Status of this Document 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as 14 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum 17 of six months and may be updated, replaced, or made 18 obsolete by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please 24 check the ``1id-abstracts.txt'' listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za 26 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 27 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 28 West Coast). 30 This document is the first product of the NNTP Working 31 Group, chaired by Erik Fair. 33 2. Abstract 35 The Network News Transport Protocol has been in use in 36 the Internet for a decade and remains one of the most 37 popular protocols (by volume) in use today. This document 38 is a replacement for RFC 977 and officially updates the 39 protocol specification. It clarifies some vagueness in 40 RFC 977, includes some new base functionality and 41 provides a specific mechanism to add standardized 42 extensions to NNTP. 44 3. Introduction 46 This document specifies the Network News Transport 47 Protocol (NNTP), which is used for the distribution, 48 inquiry, retrieval, and posting of Usenet articles using 49 a reliable stream-based mechanism. For news reading 50 clients, NNTP enables retrieval of news articles that are 51 stored in a central database, giving subscribers the 52 The netnews model provides for indexing, cross- 53 referencing, and expiration of aged messages. For server- 54 to-server interaction, NNTP is designed for efficient 55 transmission of Usenet articles over a reliable full 56 duplex communication method. 58 Every attempt is made to insure that the protocol 59 specification in this document is compatible with the 60 version specified in RFC 977[1]. 62 Generally, new functionality is available through the use 63 of new keywords. Part of that new functionality involves 64 a mechanism to discover what new functionality is 65 available to clients from a server. 67 This mechanism can also be used to add more functionality 68 as needs merit such additions. 70 In this document, the words that are used to define the 71 significance of each particular requirement are 72 capitalized. 74 These words are: 76 . "MUST" 78 This word or the adjective "REQUIRED" means that the 79 item is an absolute requirement of the specification. 81 . "SHOULD" 83 This word or the adjective "RECOMMENDED" means that 84 there may exist valid reasons in particular 85 circumstances to ignore this item, but the full 86 implications should be understood and the case 87 carefully weighed before choosing a different course. 89 . "MAY" 91 This word or the adjective "OPTIONAL" means that this 92 item is truly optional. One vendor may choose to 93 include the item because a particular marketplace 94 requires it or because it enhances the product, for 95 example; another vendor may omit the same item. 97 An implementation is not compliant if it fails to satisfy 98 one or more of the MUST requirements for this protocol. 99 An implementation that satisfies all the MUST and all the 100 SHOULD requirements for its protocols is said to be 101 "unconditionally compliant"; one that satisfies all the 102 MUST requirements but not all the SHOULD requirements for 103 NNTP is said to be "conditionally compliant". 105 For the remainder of this memo, the term "client host" 106 refers to a host making use of the NNTP service, while 107 the term "server host" refers to a host which offers the 108 NNTP service. 110 4. Basic Operation. 112 Every NNTP session MUST involve the following steps, 113 though possibly not in this order: 115 CONNECTION 116 GREETING 117 CAPABILITIES DISCOVERY 118 AUTHENTICATION 119 NEWS TRANSFER 120 CONCLUSION 121 DISCONNECTION 123 Initially, the server host MUST start the NNTP service by 124 listening on TCP port 119. When a client host wishes to 125 make use of the service, it MUST establish a TCP 126 connection with the server host. This is the CONNECTION 127 step. When the connection is established, the NNTP 128 server host MUST send a greeting. This is the GREETING 129 step. The client host and server host then MUST exchange 130 commands and responses (respectively)until the connection 131 is closed or aborted. This is the DISCONNECTION step. An 132 NNTP session MUST be started by a CONNECTION step 133 followed by a GREETING step and MUST be terminated by a 134 DISCONNECTION step. 136 If there is a CONCLUSION step, it MUST immediately 137 precede the DISCONNECTION step. There MUST be only one 138 CONNECTION, CONCLUSION and DISCONNECTION step for each 139 NNTP session. All other steps MAY be repeated as needed. 141 Commands in the NNTP MUST consist of a case-insensitive 142 keyword, which MAY be followed by one or more arguments. 143 All commands MUST be terminated by a CRLF pair. Multiple 144 commands MUST not be permitted on the same line. Keywords 145 and arguments MUST consist of printable ASCII characters. 146 Keywords and arguments MUST be each separated by one or 147 more SPACE or TAB characters. Keywords MUST be at least 148 three characters and MUST NOT exceed 12 characters. 149 Command lines MUST not exceed a total of 512 characters 150 which includes the terminating CRLF pair. 152 Each response MUST start with a three digit status 153 indicator which is sufficient to distinguish all 154 responses. Responses to certain commands MAY be multi- 155 line. In these cases, which are clearly indicated below, 156 after sending the first line of the response and a CRLF, 157 any additional lines are sent, each terminated by a CRLF 158 pair. When all lines of the response have been sent, a 159 final line MUST be sent, consisting of a termination 160 octet (ASCII decimal code 046, ".") and a CRLF pair. If 161 any line of the multi-line response begins with the 162 termination octet, the line MUST be "byte-stuffed" by 163 pre-pending the termination octet to that line of the 164 response. Hence a multi-line response is terminated with 165 the five octets "CRLF.CRLF". When examining a multi-line 166 response, the client MUST check to see if the line begins 167 with the termination octet. If so and if octets other 168 than CRLF follow, the first octet of the line (the 169 termination octet) MUST be stripped away. If so and if 170 CRLF immediately follows the termination character, then 171 the response from the NNTP server is ended and the line 172 containing ".CRLF" MUST not considered part of the multi- 173 line response. 175 A NNTP server MAY have an inactivity autologout timer. 176 Such a timer MUST be of at least 10 minutes' duration. 177 The receipt of any command from the client during that 178 interval should suffice to reset the autologout timer. 179 When the timer expires, the server should close the TCP 180 connection without sending any response to the client. 182 4.1 Responses Codes 184 Each response MUST begin with a three digit response 185 code. These are status reports from the server and 186 indicate the response to the last command received from 187 the client. 189 The first digit of the response broadly indicates the 190 success, 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 196 some reason. 197 5xx - Command unimplemented, or incorrect, or a serious 198 program error occurred. 200 The next digit in the code indicates the function 201 response category. 203 x0x - Connection, setup, and miscellaneous messages 204 x1x - Newsgroup selection 205 x2x - Article selection 206 x3x - Distribution functions 207 x4x - Posting 208 x5x - Authentication and Authorization 209 x8x - Nonstandard (private implementation) extensions 210 x9x - Debugging output 212 The exact response codes that MUST be expected from each 213 command are detailed in the description of the keyword 214 that is the first part of the command. In addition, below 215 is listed a general set of response codes that MAY be 216 received at any time. 218 Certain status responses contain parameters such as 219 numbers and names. The number and type of such parameters 220 is fixed for each response code to simplify 221 interpretation of the response. 223 Parameters MUST be separated from the numeric response 224 code and from each other by a single space. All numeric 225 parameters MUST be in base 10 (decimal) format, and may 226 have leading zeros. All string parameters MUST begin 227 after the separating space, and MUST end before the 228 following separating space or the CR-LF pair at the end 229 of the line.(String parameters MUST not, therefore, 230 contain spaces.) All text, if any, in the response which 231 is not a parameter of the response must follow and be 232 separated from the last parameter by a space. Also, note 233 that the text following a response number may vary in 234 different implementations of the server. The 3-digit 235 numeric code should be used to determine what response 236 was sent. 238 Response codes not specified in this standard MAY be used 239 for any installation-specific additional commands also 240 not specified. These SHOULD be chosen to fit the pattern 241 of x8x specified above.(Note that debugging is provided 242 for explicitly in the x9x response codes.) 244 The use of unspecified response codes for standard 245 commands is prohibited. 247 The response pattern x9x is provided for debugging. 248 Since much debugging output may be classed as 249 "informative messages", it MUST be the case that 250 responses 190 through 199 WILL be used for various 251 debugging outputs. There is no requirement in this 252 specification for debugging output, but if such is 253 provided over the connected stream, it MUST use these 254 response codes. If appropriate to a specific 255 implementation, other x9x codes MAY be used for 256 debugging. (An example MAY be to use e.g., 290 to 257 acknowledge a remote debugging request.) 259 A server MUST respond to an unrecognized, unimplemented, 260 or syntactically invalid command by responding with a 261 negative status indicator (response codes of the form 262 5XX). A server MUST respond to a command issued when the 263 session is in an incorrect state by responding with a 264 negative status indicator. This may be from either the 265 4XX or 5XX group as appropriate. 267 5. The WILDMAT format 269 The WILDMAT format[2] was first developed by Rich Salz 270 based on the format used in the UNIX "find" command to 271 articulate file names. It was developed to provide a 272 uniform mechanism for matching patterns in the same 273 manner that the UNIX shell matches filenames. Patterns 274 are implicitly anchored at the beginning and end of each 275 string when testing for a match. There are five pattern 276 matching operations other than a strict one-to-one match 277 between the pattern and the source to be checked for a 278 match. The first is an asterisk (*) to match any sequence 279 of zero or more characters. The second is a question mark 280 (?) to match any single character. The third specifies a 281 specific set of characters. The set is specified as a 282 list of characters, or as a range of characters where the 283 beginning and end of the range are separated by a minus 284 (or dash) character, or as any combination of lists and 285 ranges. The dash can also be included in the set as a 286 character it if is the beginning or end of the set. This 287 set is enclosed in square brackets. The close square 288 bracket (]) may be used in a set if it is the first 289 character in the set. The fourth operation is the same as 290 the logical not of the third operation and is specified 291 the same way as the third with the addition of a caret 292 character (^) at the beginning of the test string just 293 inside the open square bracket. The final operation uses 294 the backslash character to invalidate the special meaning 295 of the a open square bracket ([), the asterisk, backslash 296 or the question mark. Two backslashes in sequence will 297 result in the evaluation of the backslash as a character 298 with no special meaning. 300 5.1.1 Examples 302 a) [^]-] -- matches any single character other than a 303 close square bracket or a minus sign/dash. 304 b) *bdc -- matches any string that ends with the string 305 "bdc" including the string "bdc" (without quotes). 306 c) 0-9a-zA-Z] -- matches any single printable alphanumeric 307 ASCII character. 308 d) a??d -- matches any four character string which 309 begins with a and ends with d. 311 6. Format for Keyword Descriptions 313 On the following pages are descriptions of each keyword 314 recognized by the NNTP server and the responses which 315 will be returned by those commands. These keywords are 316 grouped by the functional step in which they are used. 318 Each keyword is shown in upper case for clarity, although 319 case is ignored in the interpretation of commands by the 320 NNTP server. Any parameters are shown in lower case. A 321 parameter shown in [square brackets] is optional. For 322 example, [GMT] indicates that the triglyph GMT may 323 present or omitted. A parameter that may be repeated is 324 followed by an ellipsis. Mutually exclusive parameters 325 are separated by a vertical bar (|) character. For 326 example, ggg| indicates that a group name or 327 a may be specified, but not both. Some 328 parameters, notably , are case specific. See 329 RFC 1036[3] for these details. 331 Also, certain commands make use of a pattern for 332 selection of multiple news groups. The pattern in all 333 cases is based on the WILDMAT format introduced by Rich 334 Salz in 1986. Arguments expected to be in wildmat format 335 will be represented by the string wildmat. This format is 336 discussed in detail in section 3.3 of this memo. 338 7. The GREETING Step 340 7.1 Initial Connection 342 There is no keyword presented by the client upon initial 343 connection to the server. The server MUST present an 344 appropriate response code as a greeting to the client. 345 This response informs the client about what steps the 346 client should take to reach the news exchange step. 348 The server must present a 200 greeting code if the client 349 is authorized to post articles though the use of the POST 350 keyword on this server. 352 The server must present a 201 greeting code if the client 353 is not authorized to post articles through the use of the 354 POST keyword, but no other authentication is required. 356 The server must present a 205 greeting code if the client 357 is required to present authentication before it is 358 permitted to use any keywords available in the news 359 exchange step. 361 The server must present a 502 greeting code if the client 362 is not permitted under any circumstances from interacting 363 with the server. The server should immediately close the 364 connection with the client after presenting this code. 366 In all other cases, the server must present a 400 367 greeting code. 369 7.1.1 MODE READER 370 MODE READER 371 MODE READER MAY be used by the client to indicate to the 372 server that it is a news reading client. This command may 373 be entered at any time. The server must present a 374 greeting code (as described in section 5.1) appropriate 375 to the server's ability to provide service to this client 376 in this mode. 378 7.1.1.1 Responses 380 200 Hello, you can post 381 201 Hello, you can't post 382 205 Authentication required 383 400 Service temporarily unavailable 384 502 Service unavailable 386 8. The CAPABILITIES DISCOVERY Step 388 A client NNTP supporting NNTP service extensions should 389 query a server early in the session for extensions 390 session by issuing the LIST EXTENSIONS command. If the 391 NNTP server supports the NNTP service extensions it MUST 392 give a successful response (see section 8.1.1), a failure 393 response (see section 8.1.2), or an error response ( see 394 section 8.1.3). If the NNTP server does not support any 395 NNTP service extensions it MUST generate an error 396 response (see section 8.1.4). 398 8.1 LIST EXTENSIONS 400 If successful, the server NNTP MUST respond with code 401 205. On failure, the server NNTP MUST respond with code 402 503. On error, the server NNTP MUST respond with one of 403 codes 400, 405, 500 and 501. 405 This command MAY be issued at anytime during a session. 406 It is not required that the client issue this command 407 before attempting to make use of any extension. The 408 response generated by this command MAY change during a 409 session because of other state information (e.g. 410 authentication or server administration). However, client 411 NNTP MUST not cache (for use in another session) any 412 information returned if the LIST EXTENSIONS command 413 succeeds. That is, a client NNTP MUST issue the LIST 414 EXTENSIONS command at least once during each session to 415 get the current and correct information concerning 416 available extensions during that session. 418 8.1.1 Successful response 419 If the server NNTP implements and is able to perform the 420 LIST EXTENSIONS command, it MUST return code 205. 422 This response MUST be a multi-line reply. Each line of 423 the response MUST contain a keyword and, optionally, one 424 or more parameters. The list MUST end with a period on a 425 line by itself. 427 Although LIST EXTENSIONS keywords may be specified in 428 upper, lower, or mixed case, they must always be 429 recognized and processed in a case-insensitive manner. 431 8.1.2 Failure response 432 If for some reason the server NNTP is unable to list the 433 service extensions it supports, it MUST return code 503. 435 In the case of a failure response, the client NNTP may 436 either try the extensions as the need arises or configure 437 itself for the basic NNTP functionality defined in this 438 document. 440 8.1.3 Error responses from extended servers 441 If the server NNTP recognizes the LIST EXTENSIONS 442 command, but due to various conditions cannot make any 443 extensions available to the client at the time the client 444 issued the LIST EXTENSIONS command, it MUST return code 445 405. No list (even an empty one) will be returned. 447 The client NNTP should configure itself for the basic 448 NNTP functionality defined in this document, or issue 449 commands that might change the state of the server 450 (authentication, for example), or issue the QUIT command 451 (see section 11.1) if a particular extension is required 452 for the client to properly operate. 454 If the server NNTP determines that the NNTP service is no 455 longer available (e.g., due to imminent system shutdown), 456 it must return code 400. 458 In the case of a error response, the client NNTP should 459 issue the QUIT command (see section 11.1). 461 8.1.4 Responses from servers without extensions 462 A server NNTP that conforms to this RFC but does not 463 support the extensions specified here will not recognize 464 the LIST EXTENSIONS command and MUST consequently return 465 code 500 or code 501. The server NNTP SHALL stay in the 466 same state after returning this code. The client NNTP may 467 either try the extensions as the need arises or configure 468 itself for the basic NNTP functionality defined in this 469 document. 471 8.1.5 Responses from improperly implemented servers 472 A server NNTP that improperly implements the LIST 473 EXTENSIONS command may return an empty list. Clients 474 SHALL accommodate this protocol violation and interpret 475 it as a response code 405. 477 9. The AUTHENTICATION Step 479 9.1 AUTHINFO 481 AUTHINFO is used to inform a server about the identity of 482 a user of the server. In all cases, clients MUST provide 483 this information when requested by the server. Servers 484 are not required to accept authentication information 485 that is volunteered by the client. Clients MUST 486 accommodate servers that reject any authentication 487 information volunteered by the client 489 9.1.1 AUTHINFO SIMPLE 490 AUTHINFO SIMPLE 491 user password 493 When authorization is required, the server MUST send a 494 450 response requesting authorization from the client. 495 The client MUST enter AUTHINFO SIMPLE in order to make 496 use of the AUTHINFO SIMPLE authentication step. If the 497 server will accept this form of authentication, the 498 server MUST respond with a 350 response. The client must 499 then send the username followed by one or more space 500 characters followed by the password. If accepted, the 501 server MUST return a 250 response and the client should 502 then retry the original command to which the server 503 responded with the 450 response. The command SHALL then 504 be processed by the server normally. If the combination 505 is not valid, the server MUST return a 452 response. 507 If the server returns 501, this means that the 508 authenticator invocation was syntactically incorrect, or 509 that AUTHINFO SIMPLE is not supported. 511 If the requested authenticator capability is not found or 512 there is some other unspecified server program error, the 513 server MUST return the 503 response code. 515 9.1.1.1 Responses 517 250 Authorization accepted 518 350 Continue with authorization sequence 519 450 Authorization required for this command 520 452 Authorization rejected 521 501 Command not supported or Command Syntax Error 522 502 Program error, function not performed 524 9.1.2 AUTHINFO GENERIC 526 AUTHINFO GENERIC authenticator arguments... 528 AUTHINFO GENERIC is used to identify a specific entity to 529 the server using arbitrary authentication or 530 identification protocols. The desired protocol is 531 indicated by the authenticator parameter, and any number 532 of parameters can be passed to the authenticator. 534 When authorization is required, the server will send a 535 350 response requesting authorization from the client. 536 The client should enter AUTHINFO GENERIC followed by the 537 authenticator name, and the arguments if any. The 538 authenticator and arguments must not contain the sequence 539 "..". 541 The server will attempt to engage the server end 542 authenticator, similarly, the client should engage the 543 client end authenticator. The server end authenticator 544 will then initiate authentication using the NNTP sockets 545 (if appropriate for that authentication protocol), using 546 the protocol specified by the authenticator name. These 547 authentication protocols are not included in this 548 document, but are similar in structure to those 549 referenced in RFC 1731[4] for the IMAP-4 protocol. 551 If the server returns 501, this means that the 552 authenticator invocation was syntactically incorrect, or 553 that AUTHINFO GENERIC is not supported. The client 554 should retry using the AUTHINFO SIMPLE command. 556 If the requested authenticator capability is not found or 557 there is some other unspecified server program error, the 558 server returns the 503 response code. 560 The authenticators converse using their protocol until 561 complete. If the authentication succeeds, the server 562 authenticator will terminate with a 250, and the client 563 can continue by reissuing the command that prompted the 564 350. If the authentication fails, the server will respond 565 with a 452. 567 The client must provide authentication when requested by 568 the server. The server may request authentication at any 569 time. Servers may request authentication more than once 570 during a single session. 572 When the server authenticator completes, it provides to 573 the server (by a mechanism herein undefined) the email 574 address of the user, and potentially what the user is 575 allowed to access. Once authenticated, the server shall 576 generate a Sender: line using the email address provided 577 by the authenticator if it does not match the user- 578 supplied From: line. Additionally, the server should log 579 the event, including the user's authenticated email 580 address (if available). This will provide a means by 581 which subsequent statistics generation can associate news 582 group references with unique entities - not necessarily 583 by name. 585 9.1.2.1 Responses 586 250 Authorization accepted 587 350 Continue with authorization sequence 588 450 Authorization required for this command 589 452 Authorization rejected 590 501 Command not supported or Command Syntax Error 591 502 Program error, function not performed 592 nnn authenticator-specific protocol. 594 10. The NEWS EXCHANGE Step 596 During this step, two basic types of transactions occur: 597 article retrieval from the server and article posting to 598 the server. 600 10.1 Article Retrieval 602 News reading clients have available a wide variety of 603 mechanisms to retrieve articles via NNTP. The news 604 articles are stored and indexed using two types of keys. 605 One key is the message id of an article. 607 According to RFC 1036, this identifier should be globally 608 unique. The other key is composed of the news group name 609 and the article number within that news group. That key 610 will be unique to a particular server(there will be only 611 one article with that number within a particular news 612 group), but is not required to be globally unique. 613 Additionally, because the same article can be cross- 614 posted to multiple news groups, there may be multiple 615 keys that point to the same article on the same server. 617 10.1.1 Article Retrieval by News Group Name and Article 618 Number 619 The following commands are used to set the current news 620 group name and the "current article pointer" which is 621 used by other commands for article retrieval. 623 10.1.1.1 GROUP 624 GROUP ggg 626 The required parameter ggg is the name of the news group 627 to be selected (e.g. "news.software.b").A list of valid 628 news groups may be obtained by using the LIST keyword. 629 See section 10.4 for more information on the LIST 630 keyword. 632 The successful selection response MUST return the article 633 numbers of the first and last articles in the group, and 634 an estimate of the number of articles on file in the 635 group. It is not necessary that the estimate be correct, 636 although that is helpful; it must only be equal to or 637 larger than the actual number of articles on file. 639 When a valid group is selected by means of this command, 640 the internally maintained "current article pointer" MUST 641 be set to the first article in the group and the name of 642 the current news group MUST be set to the selected news 643 group name. If an invalid group is specified, the 644 previously selected group and article MUST remain 645 selected. If an empty news group is selected, the 646 "current article pointer" is in an indeterminate state 647 and MUST not be used. 649 The GROUP keyword MUST be used by a client and a 650 successful response received before the any other command 651 is used that depends on having the "current article 652 pointer" be valid. 654 Note that the name of the news group is not case- 655 dependent. It must otherwise match a news group obtained 656 from the LIST keyword or an error will result. 658 10.1.1.1.1 Responses 659 211 n f l s group selected 660 (n = estimated number of articles in group, 661 f = first article number in the group, 662 l = last article number in the group, 663 s = name of the group.) 664 411 no such news group 666 10.1.1.2 LAST 667 LAST 668 The internally maintained "current article pointer" MUST 669 be set to the previous article in the current news group. 670 If already positioned at the first article of the news 671 group, an error message MUST be returned and the current 672 article MUST remain selected. 674 The internally-maintained "current article pointer" MUST 675 be set by this command. 677 A response indicating the current article number, and a 678 message-id string MUST be returned. No text is sent in 679 response to this command. 681 10.1.1.2.1 Responses 683 223 n a article retrieved - request text separately 684 (n = article number, a = unique article id) 685 412 no news group selected 686 420 no current article has been selected 687 422 no previous article in this group 689 10.1.1.3 NEXT 690 NEXT 692 The internally maintained "current article pointer" MUST 693 be advanced to the next article in the current news 694 group. If no more articles remain in the current group, 695 an error message MUST be returned and the current article 696 MUST remain selected. 698 The internally-maintained "current article pointer" MUST 699 be set by this command. 701 A response indicating the current article number, and the 702 message-id string MUST be returned. No text is sent in 703 response to this command. 705 10.1.1.3.1 Responses 707 223 n a article retrieved - request text separately 708 (n = article number, a = unique article id) 709 412 no news group selected 710 420 no current article has been selected 711 421 no next article in this group 713 10.2 Retrieval of Articles and Article Sections 715 There are two forms to the ARTICLE command (and the 716 related BODY, HEAD, and STAT commands), each using a 717 different method of specifying which article is to be 718 retrieved. When the ARTICLE keyword is followed by a 719 message-id in angle brackets ("<" and ">"), the first 720 form of the command MUST be used; when a numeric 721 parameter or no parameter is supplied, the second form 722 MUST be invoked. 724 The text of the article MUST be returned as a textual 725 response, as described earlier in this document. 727 The HEAD and BODY commands are identical to the ARTICLE 728 command except that they respectively return only the 729 header lines or text body of the article. 731 The STAT command is similar to the ARTICLE command except 732 that no text is returned. When selecting by message 733 number within a group, the STAT command MUST set the 734 current article pointer without sending text. The 735 returned acknowledgment response MUST contain the 736 message-id, which may be of some value. Using the STAT 737 command to select by message-id is valid but of 738 questionable value, since a selection by message-id MUST 739 NOT alter the "current article pointer". 741 10.2.1 ARTICLE 742 ARTICLE [|nnn] 744 This response displays the header, a blank line, then the 745 body (text) of the specified article. The optional 746 parameter nnn is the numeric id of an article in the 747 current news group and MUST be chosen from the range of 748 articles provided when the news group was selected. If 749 it is omitted, the current article is assumed. Message-id 750 is the message id of an article as shown in that 751 article's header. 753 Please note that the internally-maintained "current 754 article pointer" MUST NOT be altered when the message-id 755 argument is used. This is both to facilitate the 756 presentation of articles that may be referenced within an 757 article being read, and because of the semantic 758 difficulties of determining the proper sequence and 759 membership of an article which may have been posted to 760 more than one news group. 762 The internally-maintained "current article pointer" MUST 763 be set when a valid article number is specified as the 764 argument. This includes the case when a article number is 765 implied by the use of no argument. 767 A response indicating the current article number, a 768 message-id string, and that text is to follow MUST be 769 returned. 771 The message-id string returned is an identification 772 string contained within angle brackets ("<" and ">"), 773 which is derived from the header of the article itself. 774 The Message-ID header line (required by RFC 1036) from 775 the article must be used to supply this information. If 776 the message-id header line is missing from the article, a 777 single digit "0" (zero) should be supplied within the 778 angle brackets. 780 Since the message-id field is unique with each article, 781 it may be used by a news reading program to skip 782 duplicate displays of articles that have been posted more 783 than once, or to more than one news group. 785 10.2.1.1 Responses 787 220 n article retrieved - head and body follow 788 (n = article number, = message-id) 789 221 n article retrieved - head follows 790 222 n article retrieved - body follows 791 223 n article retrieved - request text separately 792 412 no news group has been selected 793 420 no current article has been selected 794 423 no such article number in this group 795 430 no such article found 797 10.3 Article Posting 799 Article posting is done in one of two modes: individual 800 article posting from news reading clients and article 801 transfer from other news servers. 803 10.3.1 POST 804 POST 806 If posting is allowed, response code 340 MUST be returned 807 to indicate that the article to be posted should be sent. 808 Response code 440 MUST be sent if that posting is 809 prohibited for some installation-dependent reason. 811 If posting is permitted, the article MUST be presented in 812 the format specified by RFC 1036, and MUST include all 813 required header lines. After the article's header and 814 body have been completely sent by the client to the 815 server, a further response code MUST be returned to 816 indicate success or failure of the posting attempt. 818 The text forming the header and body of the message to be 819 posted MUST be sent by the client using the conventions 820 for text received from the news server: A single period 821 (".") on a line indicates the end of the text, with lines 822 starting with a period in the original text having that 823 period doubled during transmission. 825 No attempt shall be made by the server to filter 826 characters, fold or limit lines, or otherwise process 827 incoming text. The intent is that the server just pass 828 the incoming message to be posted to the server 829 installation's news posting software, which is not part 830 of this specification. 832 10.3.1.1 Responses 834 240 article posted ok 835 340 send article to be posted. End with . 836 440 posting not allowed 837 441 posting failed 839 10.3.2 IHAVE 840 IHAVE 842 The IHAVE command informs the server that the client has 843 an article whose id is . If the server 844 desires a copy of that article, it MUST return a response 845 instructing the client to send the entire article. If the 846 server does not want the article (if, for example, the 847 server already has a copy of it), a response indicating 848 that the article is not wanted MUST be returned. 850 If transmission of the article is requested, the client 851 MUST send the entire article, including header and body, 852 in the manner specified for text transmission from the 853 server. A response code indicating success or failure of 854 the transferal of the article MUST be returned by the 855 server. 857 This function differs from the POST command in that it is 858 intended for use in transferring already-posted articles 859 between hosts. Normally it will not be used when the 860 client is a personal news reading program. In particular, 861 this function will invoke the server's news posting 862 program with the appropriate settings (flags, options, 863 etc.) to indicate that the forthcoming article is being 864 forwarded from another host. 866 The server may, however, elect not to post or forward the 867 article if after further examination of the article it 868 deems it inappropriate to do so. The 436 or 437 error 869 codes MUST be returned as appropriate to the situation. 871 Reasons for such subsequent rejection of an article may 872 include such problems as inappropriate news groups or 873 distributions, disk space limitations, article lengths, 874 garbled headers, and the like. These are typically 875 restrictions enforced by the server host's news software 876 and not necessarily the NNTP server itself. 878 10.3.2.1 Responses 880 235 article transferred ok 881 335 send article to be transferred. End with . 883 435 article not wanted - do not send it 884 436 transfer failed - try again later 885 437 article rejected - do not try again 887 Because some host news posting software may not be able 888 to immediately render status on the whether an article is 889 inappropriate for posting or forwarding, an NNTP server 890 MAY acknowledge the successful transfer of the article 891 and later silently discard it. Thus an NNTP server may 892 return the 235 acknowledgment code and later discard the 893 received article. 895 10.4 The LIST Keyword 897 10.4.1 LIST 898 LIST [ACTIVE [wildmat]] 900 The response to the LIST keyword with no parameters 901 returns a list of valid news groups and associated 902 information. Each news group is sent as a line of text 903 in the following format: 905 group last first status 907 where is the name of the news group, is 908 the number of the last known article currently in that 909 news group, is the number of the first article 910 currently in the news group, and indicates the 911 current status of the group on this server. Typically, 912 the will be consist of the ASCII character `y' 913 where posting is permitted, `n' where posting is not 914 permitted and `m' where postings will be forwarded to the 915 news group moderator by the news server. Other status 916 strings exist and their definition is outside the scope 917 of this specification. 919 The and fields will always be numeric. 920 They may have leading zeros. If the field 921 evaluates to less than the field, there are no 922 articles currently on file in the news group. 924 Note that posting may still be prohibited to a client 925 even though the LIST command indicates that posting is 926 permitted to a particular news group. See the POST 927 command for an explanation of client prohibitions. The 928 posting flag exists for each news group because some news 929 groups are moderated or are digests, and therefore cannot 930 be posted to; that is, articles posted to them must be 931 mailed to a moderator who will post them for the original 932 poster. This is independent of the posting permission 933 granted to a client by the NNTP server. 935 Please note that an empty list (i.e., the text body 936 returned by this command consists only of the terminating 937 period) is a possible valid response, and indicates that 938 there are currently no valid news groups. 940 If the optional matching parameter is specified, the list 941 is limited to only the groups that match the pattern. 942 Specifying a single group is usually very efficient for 943 the server, and multiple groups may be specified by using 944 wildmat patterns (described in section 5), not regular 945 expression 947 10.4.1.1 Responses 949 215 list of news groups follows 951 10.4.2 LIST ACTIVE.TIMES 952 LIST ACTIVE.TIMES [wildmat] 954 The active.times file is maintained by some news 955 transports systems to contain information about the when 956 and who created a particular news group. The format of 957 this file generally include three fields. The first field 958 is the name of the news group. The second is the time 959 when this group was created on this news server measured 960 in seconds since January 1, 1970. The third is the email 961 address of the entity that created the news group. When 962 executed, the information is displayed following the 215 963 response. When display is completed, the server will send 964 a period on a line by itself. If the information is not 965 available, the server will return the 503 error response. 967 If the optional matching parameter is specified, the list 968 is limited to only the groups that match the pattern. 969 Specifying a single group is usually very efficient for 970 the server, and multiple groups may be specified by using 971 wildmat patterns (described in section 5), not regular 972 expression 973 10.4.2.1 Responses 975 215 information follows 976 503 program error, function not performed 978 10.4.3 LIST DISTRIBUTIONS 979 LIST DISTRIBUTIONS 981 The distributions file is maintained by some news 982 transport systems to contain information about valid 983 values for the Distribution: line in a news article 984 header and about what the values mean. Each line contains 985 two fields, the value and a short explanation on the 986 meaning of the value. When executed, the information is 987 displayed following the 215 response. When display is 988 completed, the server will send a period on a line by 989 itself. If the information is not available, the server 990 will return the 503 error response. 992 10.4.3.1 Responses 994 215 information follows 995 503 program error, function not performed 997 10.4.4 LIST DISTRIB.PATS 998 LIST DISTRIB.PATS 1000 The distrib.pats file is maintained by some news 1001 transport systems to contain default values for the 1002 Distribution: line in a news article header when posting 1003 to particular news groups. This information could be used 1004 to provide a default value for the Distribution: line in 1005 the header when posting an article. The information 1006 returned contains three fields separated by colons. The 1007 first column is a weight. The second is a group name or 1008 a wildmat pattern that can be used to match a group name. 1009 The third is the value of the Distribution: line that 1010 should be used when the group name matches and the weight 1011 value is the highest. All this processing is done by the 1012 news posting client and not by the server itself. The 1013 server provides this information to the client for it to 1014 use or ignore as it chooses. When executed, the 1015 information is displayed following the 215 response. 1016 When display is completed, the server will send a period 1017 on a line by itself. If the information is not available, 1018 the server will return the 503 error response. 1020 10.4.4.1 Responses 1022 215 information follows 1023 503 program error, function not performed 1024 10.4.5 LIST NEWSGROUPS 1025 LIST NEWSGROUPS [wildmat] 1027 The newsgroups file is maintained by some news transport 1028 systems to contain the name of each news group which is 1029 active on the server and a short description about the 1030 purpose of each news group. Each line in the file 1031 contains two fields, the news group name and a short 1032 explanation of the purpose of that news group. When 1033 executed, the information is displayed following the 215 1034 response. When display is completed, the server will send 1035 a period on a line by itself. If the information is not 1036 available, the server will return the 503 response. If 1037 the optional matching parameter is specified, the list is 1038 limited to only the groups that match the pattern (no 1039 matching is done on the group descriptions). Specifying 1040 a single group is usually very efficient for the server, 1041 and multiple groups may be specified by using wildmat 1042 patterns (see section 5), not regular expressions. If 1043 nothing is matched an empty list is returned, not an 1044 error. 1046 10.4.5.1 Responses 1048 215 information follows 1049 503 program error, function not performed 1051 10.4.6 LIST OVERVIEW.FMT 1052 LIST OVERVIEW.FMT 1054 The overview.fmt file is maintained by some news 1055 transport systems to contain the order in which header 1056 information is stored in the overview databases for each 1057 news group. When executed, news article header fields 1058 are displayed one line at a time in the order in which 1059 they are stored in the overview database[5] following the 1060 215 response. When display is completed, the server will 1061 send a period on a line by itself. If the information is 1062 not available, the server will return the 503 response. 1064 Please note that if the header has the word "full" 1065 (without quotes) after the colon, the header's name is 1066 prepended to its field in the output returned by the 1067 server. 1069 10.4.6.1 Responses 1071 215 information follows 1072 503 program error, function not performed 1074 10.4.7 LIST SUBSCRIPTIONS 1075 LIST SUBSCRIPTIONS 1076 This command is used to get a default subscription list 1077 for new users of this server. The order of groups is 1078 significant. 1080 When this list is available, it is preceded by the 215 1081 response and followed by a period on a line by itself. 1082 When this list is not available, the server returns a 503 1083 response code. 1085 10.4.7.1 Responses 1087 215 information follows 1088 503 program error, function not performed 1090 10.4.8 LISTGROUP 1091 LISTGROUP [ggg] 1093 The LISTGROUP command is used to get a listing of all the 1094 article numbers in a particular news group. 1096 The optional parameter ggg is the name of the news group 1097 to be selected (e.g. "news.software.b"). A list of valid 1098 news groups may be obtained from the LIST command. If no 1099 group is specified, the current group is used as the 1100 default argument. 1102 The successful selection response will be a list of the 1103 article numbers in the group followed by a period on a 1104 line by itself. 1106 When a valid group is selected by means of this command, 1107 the internally maintained "current article pointer" MUST 1108 be set to the first article in the group. If an invalid 1109 group is specified, the previously selected group and 1110 article remain selected. If an empty news group is 1111 selected, the "current article pointer" is in an 1112 indeterminate state and should not be used. 1114 Note that the name of the news group is not case- 1115 dependent. It must otherwise match a news group obtained 1116 from the LIST command or an error will result. 1118 10.4.8.1 Responses 1120 211 list of article numbers follow 1121 412 Not currently in news group 1122 502 no permission 1123 10.4.9 OVER 1124 OVER [range] 1126 The OVER command returns information from the overview 1127 database for the article(s) specified. The information 1128 returned in the response to this command can be used by 1129 clients to follow discussion threads. 1131 The optional range argument may be any of the following: 1133 . an article number 1134 . an article number followed by a dash to indicate all 1135 following 1136 . an article number followed by a dash followed by 1137 another article number 1139 If no argument is specified, then information from the 1140 current article is displayed. Successful responses start 1141 with a 224 response followed by the overview information 1142 for all matched messages. Once the output is complete, a 1143 period is sent on a line by itself. If no argument is 1144 specified, the information for the current article is 1145 returned. A news group must have been selected earlier, 1146 else a 412 error response is returned. If no articles are 1147 in the range specified, a 420 error response is returned 1148 by the server. A 502 response will be returned if the 1149 client only has permission to transfer articles. 1151 Each line of output MUST be formatted with the article 1152 number, followed by each of the headers in the overview 1153 database or the article itself (when the data is not 1154 available in the overview database) for that article 1155 separated by a tab character. The sequence of fields 1156 must be in this order: subject, author, date, message-id, 1157 references, byte count, and line count. Other optional 1158 fields may follow line count. Where no data exists, a 1159 null field must be provided (i.e. the output will have 1160 two tab characters adjacent to each other). Servers 1161 should not output fields for articles that have been 1162 removed since the overview database was created. 1164 10.4.9.1 Responses 1166 224 Overview information follows 1167 412 No news group current selected 1168 420 No article(s) selected 1169 502 no permission 1171 10.4.10 PAT 1172 PAT header range| pat [pat...] 1173 The PAT command is used to retrieve specific headers from 1174 specific articles, based on pattern matching on the 1175 contents of the header. 1177 The required header parameter is the name of a header 1178 line (e.g. "subject") in a news group article. See RFC- 1179 1036 for a list of valid header lines. The required range 1180 argument may be any of the following: 1182 . an article number 1183 . an article number followed by a dash to indicate all 1184 following 1185 . an article number followed by a dash followed by 1186 another article number. 1188 The required message-id argument indicates a specific 1189 article. The range and message-id arguments are mutually 1190 exclusive. At least one pattern in wildmat must be 1191 specified as well. If there are additional arguments the 1192 are joined together separated by a single space to form 1193 one complete pattern. Successful responses start with a 1194 221 response followed by the headers from all messages in 1195 which the pattern matched the contents of the specified 1196 header line. This includes an empty list. Once the output 1197 is complete, a period is sent on a line by itself. If the 1198 optional argument is a message-id and no such article 1199 exists, the 430 error response shall be returned. A 502 1200 response shall be returned if the client only has 1201 permission to transfer articles. 1203 10.4.10.1 Responses 1205 221 Header follows 1206 430 no such article 1207 502 no permission 1209 11. The CONCLUSION Step 1211 11.1 QUIT 1213 QUIT 1215 The server process MUST acknowledge the QUIT command and 1216 then closes the connection to the client. This is the 1217 preferred method for a client to indicate that it has 1218 finished all its transactions with the NNTP server. 1220 If a client simply disconnects (or the connection times 1221 out, or some other fault occurs), the server SHALL 1222 gracefully cease its attempts to service the client. 1224 11.1.1 Responses 1226 205 closing connection - goodbye! 1228 12. Other Keywords 1230 There are other Keywords that may be used at any time 1231 between the beginning of a session and its termination. 1232 Using these keywords do not alter any state information, 1233 but the response generated from the use of these keywords 1234 may provide useful information to clients that use them. 1236 12.1 DATE 1238 DATE 1240 This command exists to help clients find out the current 1241 time from the server's perspective. This command should 1242 not be used as a substitute for NTP[6], but to provide 1243 information that might be useful when using the NEWNEWS 1244 command (see section 12.4). 1246 This command returns a one-line response code of 111 1247 followed by the GMT date and time on the server in the 1248 form YYYYMMDDhhmmss. 1250 12.1.1 Responses 1251 111 YYYYMMDDhhmmss 1253 12.2 The HELP Command 1255 HELP 1257 This command provides a short summary of commands that 1258 are understood by this implementation of the server. The 1259 help text will be presented as a textual response, 1260 terminated by a single period on a line by itself. 1262 This text is not guaranteed to be in any particular 1263 format and shall not be used by clients as a replacement 1264 for the LIST EXTENSIONS command described in section 8.1. 1266 12.2.1 Responses 1267 100 help text follows 1269 12.3 NEWGROUPS 1271 NEWGROUPS date time [GMT] [] 1272 A list of newsgroups created since MUST 1273 be listed in the same format as the LIST command. 1275 The date is sent as 6 digits in the format YYMMDD, where 1276 YY is the last two digits of the year, MM is the two 1277 digits of the month (with leading zero, if appropriate), 1278 and DD is the day of the month (with leading zero, if 1279 appropriate). The closest century is assumed as part of 1280 the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 1281 is 1999, 00 is 2000). 1283 Time must also be specified. It must be as 6 digits 1284 HHMMSS with HH being hours on the 24-hour clock, MM 1285 minutes 00-59, and SS seconds 00-59. The time is assumed 1286 to be in the server's timezone unless the token "GMT" 1287 appears, in which case both time and date are evaluated 1288 at the 0 meridian. 1290 An optional parameter may be specified at the end of the 1291 command line consisting of a wildmat pattern against 1292 which new newsgroup names can be matched enclosed in 1293 angle brackets. Only those news groups which have names 1294 that match the pattern (and any other criteria specified 1295 in the command) will be returned. 1297 Please note that an empty list (i.e., the text body 1298 returned by this command consists only of the terminating 1299 period) is a possible valid response, and indicates that 1300 there are currently no new newsgroups. 1302 12.3.1 Responses 1304 231 list of new newsgroups follows 1306 12.4 NEWNEWS 1308 NEWNEWS newsgroups date time [GMT] [] 1310 A list of message-ids of articles posted or received to 1311 the specified news group since "date" will be listed. The 1312 format of the listing will be one message-id per line, as 1313 though text were being sent. A single line consisting 1314 solely of one period followed by CR-LF will terminate the 1315 list. 1317 Date and time are in the same format as the NEWGROUPS 1318 command. The newsgroups parameter must be in wildmat 1319 format. 1321 The optional parameter "distributions" is a list of 1322 distribution groups, enclosed in angle brackets. If 1323 specified, the distribution portion of an article's 1324 header will be examined for a match with the distribution 1325 categories listed, and only those articles which have a 1326 distribution in the list will be listed. If more than 1327 one distribution is to be supplied, they must be 1328 separated by commas within the angle brackets. 1330 The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to 1331 distribute news is discussed in an earlier part of this 1332 document. 1334 Please note that an empty list (i.e., the text body 1335 returned by this command consists only of the terminating 1336 period) is a possible valid response, and indicates that 1337 there is currently no new news. 1339 12.4.1 Responses 1340 230 list of new articles by message-id follows 1342 13. Framework for NNTP Extensions 1344 Although NNTP is widely and robustly deployed, some parts 1345 of the Internet community might wish to extend the NNTP 1346 service. This memo defines a means whereby both an 1347 extended NNTP client may query the server to determine 1348 the service extensions that it supports. 1350 It must be emphasized that any extension to the NNTP 1351 service should not be considered lightly. NNTP's strength 1352 comes primarily from its simplicity. Experience with 1353 many protocols has shown that: 1355 protocols with few options tend towards ubiquity, whilst 1356 protocols with many options tend towards obscurity. 1358 This means that each and every extension, regardless of 1359 its benefits, must be carefully scrutinized with respect 1360 to its implementation, deployment, and interoperability 1361 costs. In many cases, the cost of extending the NNTP 1362 service will likely outweigh the benefit. 1364 Given this environment, the framework for the extensions 1365 described in this memo consists of: 1367 a) a mechanism for clients to determine a server's 1368 available extensions 1369 b) a registry of NNTP service extensions 1371 The LIST EXTENSIONS command was described in section 6.1 1372 of this memo and is the mechanism used for clients to 1373 determine what extensions are available for client use. 1375 The IANA shall maintains a registry of NNTP service 1376 extensions. 1378 Associated with each such extension is a corresponding 1379 NNTP keyword value. Each service extension registered 1380 with the IANA MUST be defined in an RFC. Such RFCs must 1381 either be on the standards-track or must define an IESG- 1382 approved experimental protocol. The definition must 1383 include: 1385 1. the textual name of the NNTP service extension; 1386 2. the NNTP keyword value associated with the extension; 1387 3. the syntax and possible values of parameters associated 1388 with the NNTP keyword value; 1389 4.any additional NNTP verbs associated with the extension 1390 (additional verbs will usually be, but are not required 1391 to be, the same as the NNTP keyword value); 1392 5. any new parameters the extension associated with any 1393 other NNTP verbs; 1394 6. how support for the extension affects the behavior of a 1395 server and client NNTP; and, 1396 7. the increment by which the extension is increasing the 1397 maximum length of the any commands over that specified 1398 in this document. 1400 In addition, any NNTP keyword value that starts with an 1401 upper or lower case "X" refers to a local NNTP service 1402 extension, which is used through bilateral, rather than 1403 standardized, agreement. Keywords beginning with "X" may 1404 not be used in a registered service extension. 1406 Any keyword values presented in the NNTP response that do 1407 not begin with "X" must correspond to a standard, 1408 standards-track, or IESG-approved experimental NNTP 1409 service extension registered with IANA. A conforming 1410 server must not offer non "X" prefixed keyword values 1411 that are not described in a registered extension. 1413 Additional verbs are bound by the same rules as NNTP 1414 keywords; specifically, verbs beginning with "X" are 1415 local extensions that may not be registered or 1416 standardized and verbs not beginning with "X" must always 1417 be registered. 1419 13.1 Initial IANA Registry 1421 The IANA's initial registry of NNTP service extensions 1422 consists of these entries: 1424 Service Extension NNTP Keyword(s) Added Behavior 1425 ------------------ -------------- -------------- 1426 Overview Support OVER defined in this 1427 document 1428 LIST OVERVIEW.FMT 1429 Service Extension NNTP Keyword(s) Added Behavior 1430 ----------------- --------------- -------------- 1431 Specific Article LISTGROUP defined in this 1432 Numbers document 1434 Header Pattern PAT defined in this 1435 Matching document 1437 14. Security Considerations 1439 The use of the AUTHINFO is optional. This command as 1440 documented has a number of security implications. In the 1441 original and simple forms, all passwords are passed in 1442 plain text and could be discovered by various forms of 1443 network or system surveillance. The AUTHINFO GENERIC 1444 command has the potential for the same problems if a 1445 mechanism is used that also passes clear text passwords. 1446 RFC 1731 discusses these issues in greater detail. 1448 15. References 1450 [1] Kantor, B and P. Lapsley, "Network News Transfer 1451 Protocol", RFC-977, U.C. San Diego and U.C. Berkeley, 1452 [2] Salz, Rich, Manual Page for wildmat(3) from the INN 1453 1.4 distribution, UUNET Technologies, Revision 1.10, 1454 April, 1992. 1455 [3] Horton, M.R. and R. Adams, "Standard for interchange 1456 of USENET messages", RFC-1036, AT&T Bell Laboratories 1457 and Center for Seismic Studies, December, 1987. 1458 [4] Meyers, J, "IMAP4 Authentication Mechanisms", RFC- 1459 1731, Carnegie Mellon, December, 1994. 1460 [5]Robertson, Rob, "FAQ: Overview database / NOV General 1461 Information", 1462 ftp://ftp.uu.net/networking/news/nntp/inn/faq-nov.Z, 1463 January, 1995. 1464 [6] Mills, David L., "Network Time Protocol (Version 3), 1465 Specification,Implementation and Analysis", RFC-1305, 1466 University of Delaware, March 1992. 1468 15.1 Notes 1470 DEC is a registered trademark of Digital Equipment 1471 Corporation. 1473 UNIX is a registered trademark of the X/Open Consortium. 1475 VMS is a registered trademark of Digital Equipment 1476 Corporation. 1478 15.2 Acknowledgments 1480 The author acknowledges the original authors of NNTP as 1481 documented in RFC 977: Brian Kantor and Phil Lapsey. 1483 The author gratefully acknowledges the work of the NNTP 1484 committee chaired by Eliot Lear. The organization of this 1485 document was influenced by the last available draft from 1486 this working group. A special thanks to Eliot for 1487 generously providing the original machine sources for 1488 that document. 1490 The author gratefully acknowledges the work of the 1491 Marshall Rose & John G. Meyers in RFC 1939 and the work 1492 of the DRUMS working group, specifically RFC 1869, which 1493 is the basis of the NNTP extensions mechanism detailed in 1494 this document. 1496 The author gratefully acknowledges the comments and 1497 additional information provided by the following 1498 individuals in preparing one of the progenitors of this 1499 document: 1501 . Wayne Davison 1502 . Chris Lewis 1503 . Tom Limoncelli 1504 . Eric Schnoebelen 1505 . Rich Salz 1507 This work was precipitated by the work of various 1508 newsreader authors and newsserver authors which includes 1509 those listed below: 1511 . Rick Adams -- Original author of the NNTP extensions to 1512 the RN newsreader and last maintainer of Bnews 1513 . Stan Barber -- Original author of the NNTP extensions 1514 to the newsreaders that are part of Bnews. 1515 . Geoff Collyer -- Original author of the OVERVIEW 1516 database proposal and one of the original authors of 1517 CNEWS 1518 . Dan Curry -- Original author of the xvnews newsreader 1519 . Wayne Davision -- Author of the first threading 1520 extensions to the RN newsreader (commonly called TRN). 1521 . Geoff Huston -- Original author of ANU NEWS 1522 . Phil Lapsey -- Original author of the UNIX reference 1523 implementation 1524 . Ian Lea -- Maintainer of the TIN newsreader 1525 . Chris Lewis -- First known implementor of the AUTHINFO 1526 GENERIC extension 1527 . Rich Salz -- Original author of INN 1528 . Henry Spencer -- One of the original authors of CNEWS 1529 . Kim Storm -- Original author of the NN newsreader 1530 15.3 Author's Address 1532 Stan Barber 1533 P.O. Box 300481 1534 Houston, Texas, 77230 1535 Email: 1537 This document expires February 1, 1997.