idnits 2.17.1 draft-ietf-nntpext-base-03.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-18) 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 36 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: ' 15. 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 363 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], [0-9a-zA-Z], [5], [6], [7], [8], [9], [GMT], [10], [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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 1997) is 9621 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 1801 looks like a reference -- Missing reference section? '2' on line 1804 looks like a reference -- Missing reference section? '3' on line 1807 looks like a reference -- Missing reference section? '4' on line 1810 looks like a reference -- Missing reference section? '5' on line 1813 looks like a reference -- Missing reference section? '0-9a-zA-Z' on line 289 looks like a reference -- Missing reference section? 'GMT' on line 1541 looks like a reference -- Missing reference section? '6' on line 1816 looks like a reference -- Missing reference section? '7' on line 1820 looks like a reference -- Missing reference section? '8' on line 1823 looks like a reference -- Missing reference section? '9' on line 1827 looks like a reference -- Missing reference section? '10' on line 1831 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Barber 3 Expires: June 1, 1998 Academ Consulting Services 4 December 1997 6 Network News Transport Protocol 8 draft-ietf-nntpext-base-03.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]. However, this version does not 61 support the ill-defined SLAVE command and permits four digit 62 years to be specified in the NEWNEWS and NEWGROUPS commands. 63 It changes the default character set to UTF-8[2] instead of 64 US-ASCII[3]. It also makes extends the newsgroup name matching 65 capabilities already documented in RFC 977. 67 Generally, new functionality is available using new keywords. 68 Part of that new functionality involves a mechanism to 69 discover what new functionality is available to clients from a 70 server. 72 This mechanism can also be used to add more functionality as 73 needs merit such additions. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 76 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described 78 in RFC 2119[4]. 80 An implementation is not compliant if it fails to satisfy one 81 or more of the MUST requirements for this protocol. An 82 implementation that satisfies all the MUST and all the SHOULD 83 requirements for its protocols is said to be "unconditionally 84 compliant"; one that satisfies all the MUST requirements but 85 not all the SHOULD requirements for NNTP is said to be 86 "conditionally compliant". 88 For the remainder of this memo, the term "client host" refers 89 to a host making use of the NNTP service, while the term 90 "server host" refers to a host that offers the NNTP service. 92 4. Basic Operation. 94 Every NNTP session MUST involve the following in this order: 96 CONNECTION 97 GREETING 98 DISCONNECTION 100 Other steps may occur between the GREETING and DISCONNECTION 101 step. They are: 103 CAPABILITIES DISCOVERY 104 AUTHENTICATION 105 NEWS TRANSFER 106 CONCLUSION 108 NNTP operates over any reliable data stream 8-bit-wide 109 channel. When running over TCP/IP, the official port for the 110 NNTP service is 119. Initially, the server host starts the 111 NNTP service by listening on a TCP port. When a client host 112 wishes to make use of the service, it MUST establish a TCP 113 connection with the server host by connecting to that host on 114 the same port on which the server is listening. This is the 115 CONNECTION step. When the connection is established, the NNTP 116 server host MUST send a greeting. This is the GREETING step. 117 The client host and server host then SHOULD then exchange 118 commands and responses (respectively) until the connection is 119 closed or aborted. This final step is called the DISCONNECTION 120 step. 122 If there is a CONCLUSION step, it MUST immediately precede the 123 DISCONNECTION step. There MUST be only one CONNECTION, 124 CONCLUSION and DISCONNECTION step for each NNTP session. All 125 other steps MAY be repeated as needed. 127 The character set for all NNTP commands is UTF-8. Commands in 128 the NNTP MUST consist of a US-ASCII case-insensitive keyword, 129 which MAY be followed by one or more arguments. All commands 130 MUST be terminated by a US-ASCII CRLF pair. Multiple commands 131 MUST NOT be permitted on the same line. Keywords MUST consist 132 of printable US-ASCII characters. Unless otherwise noted 133 elsewhere in this document, Arguments SHOULD consist of 134 printable US-ASCII characters. Keywords and arguments MUST be 135 each separated by one or more US-ASCII SPACE or US-ASCII TAB 136 characters. Keywords MUST be at least three US-ASCII 137 characters and MUST NOT exceed 12 US-ASCII characters. 138 Command lines MUST NOT exceed 512 octets, which includes the 139 terminating US-ASCII CRLF pair. 141 Each response MUST start with a three-digit status indicator 142 that is sufficient to distinguish all responses. Responses to 143 certain commands MAY be multi-line. In these cases, which are 144 clearly indicated below, after sending the first line of the 145 response and a US-ASCII CRLF, any additional lines are sent, 146 each terminated by a US-ASCII CRLF pair. When all lines of the 147 response have been sent, a final line MUST be sent, consisting 148 of a termination octet (US-ASCII decimal code 046, ".") and a 149 US-ASCII CRLF pair. If any line of the multi-line response 150 begins with the termination octet, the line MUST be "byte- 151 stuffed" by pre-pending the termination octet to that line of 152 the response. Hence, a multi-line response is terminated with 153 the five octets "CRLF.CRLF" (in US-ASCII). When examining a 154 multi-line response, the client MUST check to see if the line 155 begins with the termination octet. If so and if octets other 156 than US-ASCII CRLF follow, the first octet of the line (the 157 termination octet) MUST be stripped away. If so and if US- 158 ASCII CRLF immediately follows the termination character, then 159 the response from the NNTP server is ended and the line 160 containing ".CRLF" (in US-ASCII) MUST NOT considered part of 161 the multi-line response. 163 A NNTP server MAY have an inactivity autologout timer. Such a 164 timer MUST be of at least three minutes duration. The receipt 165 of any command from the client during that interval should 166 suffice to reset the autologout timer. When the timer 167 expires, the server should close the TCP connection without 168 sending any response to the client. 170 4.1 Responses Codes 172 Each response MUST begin with a three-digit response code. 173 These are status reports from the server and indicate the 174 response to the last command received from the client. 176 The first digit of the response broadly indicates the success, 177 failure, or progress of the previous command. 179 1xx - Informative message 180 2xx - Command ok 181 3xx - Command ok so far, send the rest of it. 182 4xx - Command was correct, but couldn't be performed for some 183 reason. 184 5xx - Command unimplemented, or incorrect, or a serious 185 program error occurred. 186 The next digit in the code indicates the function response 187 category. 189 x0x - Connection, setup, and miscellaneous messages 190 x1x - Newsgroup selection 191 x2x - Article selection 192 x3x - Distribution functions 193 x4x - Posting 194 x5x - Authentication and Authorization 195 x8x - Nonstandard (private implementation) extensions 196 x9x - Debugging output 198 The exact response codes that MUST be expected from each 199 command are detailed in the description of the keyword that is 200 the first part of the command. In addition, below is listed a 201 general set of response codes that MAY be received at any 202 time. 204 Certain status responses contain parameters such as numbers 205 and names. In those cases, the number and type of such 206 parameters MUST be fixed for each response code to simplify 207 interpretation of the response. In all other cases, the client 208 MUST only use the response code itself to determine the nature 209 of the response. 211 Parameters MUST be separated from the numeric response code 212 and from each other by a single US-ASCII space. All numeric 213 parameters MUST be in base 10 (decimal) format, and may have 214 leading zeros. All string parameters MUST begin after the 215 separating space, and MUST end before the following separating 216 space or the US-ASCII CRLF pair at the end of the line. 217 (Therefore, string parameters MUST NOT contain US-ASCII 218 spaces.) All text, if any, in the response which is not a 219 parameter of the response must follow and be separated from 220 the last parameter by a US-ASCII space. Also, note that the 221 text following a response number may vary in different 222 implementations of the server. The 3-digit numeric code should 223 be used to determine what response was sent. 225 Response codes not specified in this standard MAY be used for 226 any installation-specific additional commands also not 227 specified. These SHOULD be chosen to fit the pattern of x8x 228 specified above. (Note that debugging is provided for 229 explicitly in the x9x response codes.) 231 The use of unspecified response codes for a standard command 232 is prohibited. 234 The response pattern x9x is provided for debugging. Since 235 much debugging output may be classed as "informative 236 messages", it MUST be the case that responses 190 through 199 237 WILL be used for various debugging outputs. There is no 238 requirement in this specification for debugging output. 239 However, if such is provided over the connected stream, it 240 MUST use these response codes. If appropriate to a specific 241 implementation, other x9x codes MAY be used for debugging. 242 (For example, response code 290 could be used to acknowledge a 243 remote debugging request.) 245 A server MUST respond to an unrecognized, unimplemented, or 246 syntactically invalid command with a negative status indicator 247 (response codes of the form 5XX). A server MUST respond to a 248 command issued when the session is in an incorrect state by 249 responding with a negative status indicator. This may be from 250 either the 4XX or 5XX group as appropriate. 252 5. The WILDMAT format 254 The WILDMAT format[5] was first developed by Rich Salz based 255 on the format used in the UNIX "find" command to articulate 256 file names. It was developed to provide a uniform mechanism 257 for matching patterns in the same manner that the UNIX shell 258 matches filenames. Patterns are implicitly anchored at the 259 beginning and end of each string when testing for a match. 260 There are five pattern-matching operations other than a strict 261 one-to-one match between the pattern and the source to be 262 checked for a match. The first is an asterisk (*) to match any 263 sequence of zero or more UTF-8 characters. The second is a 264 question mark (?) to match any single UTF-8 character. The 265 third specifies a specific set of characters. The set is 266 specified as a list of characters, or as a range of characters 267 where the beginning and end of the range are separated by a 268 minus (or dash) character, or as any combination of lists and 269 ranges. The dash can also be included in the set as a 270 character it if is the beginning or end of the set. This set 271 is enclosed in square brackets. The close square bracket (]) 272 may be used in a set if it is the first character in the set. 273 The fourth operation is the same as the logical not of the 274 third operation and is specified the same way as the third 275 with the addition of a caret character (^) at the beginning of 276 the test string just inside the open square bracket. The final 277 operation uses the backslash character to invalidate the 278 special meaning of the open square bracket ([), the asterisk, 279 backslash or the question mark. Two backslashes in sequence 280 will result in the evaluation of the backslash as a character 281 with no special meaning. 283 5.1 Examples 285 a) [^]-] -- matches any single character other than a 286 close square bracket or a minus sign/dash. 287 b) *bdc -- matches any string that ends with the string 288 "bdc" including the string "bdc" (without quotes). 289 c) [0-9a-zA-Z] -- matches any single printable 290 alphanumeric ASCII character. 291 d) a??d -- matches any four character string which 292 begins with a and ends with d. 294 6. Format for Keyword Descriptions 295 On the following pages are descriptions of each keyword 296 recognized by the NNTP server and the responses that will be 297 returned by those commands. These keywords are grouped by the 298 functional step in which they are used. 300 Each keyword is shown in upper case for clarity, although case 301 is ignored in the interpretation of commands by the NNTP 302 server. Any parameters are shown in lower case. A parameter 303 shown in [square brackets] is optional. For example, [GMT] 304 indicates that the triglyph GMT may present or omitted. A 305 parameter that may be repeated is followed by an ellipsis. 306 Mutually exclusive parameters are separated by a vertical bar 307 (|) character. For example, ggg| indicates that a 308 group name or a may be specified, but not both. 309 Some parameters may be case or language specific. See RFC 310 1036[6] for these details. 312 In addition, certain commands make use of a pattern for 313 selection of multiple news groups. The pattern in all cases is 314 based on the WILDMAT format introduced by Rich Salz in 1986. 315 Arguments expected to be in wildmat format will be represented 316 by the string wildmat. This format is discussed in detail in 317 section 5 of this memo. 319 7. The GREETING Step 321 7.1 Initial Connection 323 There is no keyword presented by the client upon initial 324 connection to the server. The server MUST present an 325 appropriate response code as a greeting to the client. This 326 response informs the client about what steps the client should 327 take to reach the news exchange step. 329 The server must present a 200 greeting code if the client is 330 authorized to post articles though the use of the POST keyword 331 on this server. 333 The server must present a 201 greeting code if the client is 334 not authorized to post articles using the POST keyword, but no 335 other authentication is required. 337 The server must present a 205 greeting code if the client is 338 required to present authentication before it is permitted to 339 use any keywords available in the news exchange step. 341 The server must present a 502 greeting code if the client is 342 not permitted under any circumstances from interacting with 343 the server. The server should immediately close the connection 344 with the client after presenting this code. 346 In all other cases, the server must present a 400 greeting 347 code. 349 7.1.1 MODE READER 351 MODE READER 353 MODE READER MAY be used by the client to indicate to the 354 server that it is a news reading client. This command may be 355 entered at any time. The server must present a greeting code 356 (as described in section 7.1.1.1) appropriate to the server's 357 ability to provide service to this client in this mode. 359 7.1.1.1 Responses 360 200 Hello, you can post 361 201 Hello, you can't post 362 205 Authentication required 363 400 Service temporarily unavailable 364 502 Service unavailable 366 8. The CAPABILITIES DISCOVERY Step 368 A client NNTP supporting NNTP service extensions should query 369 a server early in the session for extensions session by 370 issuing the LIST EXTENSIONS command. If the NNTP server 371 supports the NNTP service extensions it MUST give a successful 372 response (see section 8.1.1), a failure response (see section 373 8.1.2), or an error response (see section 8.1.3). If the NNTP 374 server does not support any NNTP service extensions, it MUST 375 generate an error response (see section 8.1.4). 377 8.1 LIST EXTENSIONS 379 If successful, the server NNTP MUST respond with code 202. On 380 failure, the server NNTP MUST respond with code 503. On error, 381 the server NNTP MUST respond with one of codes 400, 402, 500 382 and 501. 384 This command MAY be issued at anytime during a session. It is 385 not required that the client issues this command before 386 attempting to make use of any extension. The response 387 generated by this command MAY change during a session because 388 of other state information (e.g. authentication or server 389 administration). However, a client NNTP MUST NOT cache (for 390 use in another session) any information returned if the LIST 391 EXTENSIONS command succeeds. That is, a client NNTP MUST issue 392 the LIST EXTENSIONS command at least once during each session 393 to get the current and correct information concerning 394 available extensions during that session. 396 8.1.1 Successful response 398 If the server NNTP implements and is able to perform the LIST 399 EXTENSIONS command, it MUST return code 202. 401 This response MUST be a multi-line reply. Each line of the 402 response MUST contain a supported keyword and, if required, 403 one or more verbs that fully specify a single supported 404 extension. Extensions that are specified by multiple keywords 405 or multiple keyword/verb combination MUST have each of those 406 keywords and/or keyword/verb combinations in the list to 407 correctly and fully indicate support for a particular 408 extension. The list MUST end with a period on a line by 409 itself. 411 Although LIST EXTENSIONS keywords may be specified in upper, 412 lower, or mixed case, they must always be recognized and 413 processed in a case-insensitive manner. 415 8.1.2 Failure response 417 If for some reason the server NNTP is unable to list the 418 service extensions it supports, it MUST return code 503. 420 In the case of a failure response, the client NNTP may try the 421 extensions either as the need arises or configure itself for 422 the basic NNTP functionality defined in this document. 424 8.1.3 Error responses from extended servers 426 If the server NNTP recognizes the LIST EXTENSIONS command, but 427 due to various conditions cannot make any extensions available 428 to the client at the time the client issued the LIST 429 EXTENSIONS command, it MUST return code 402. No list (even an 430 empty one) will be returned. 432 The client NNTP should configure itself for the basic NNTP 433 functionality defined in this document, or issue commands that 434 might change the state of the server (authentication, for 435 example), or issue the QUIT command (see section 11.1) if a 436 particular extension is required for the client to properly 437 operate. 439 If the server NNTP determines that the NNTP service is no 440 longer available (e.g., due to imminent system shutdown), it 441 must return code 400. 443 In the case of an error response, the client NNTP should issue 444 the QUIT command (see section 11.1). 446 8.1.4 Responses from servers without extensions 448 A server NNTP that conforms to this memo but does not support 449 the extensions specified here will not recognize the LIST 450 EXTENSIONS command and MUST consequently return code 500 or 451 code 501. The server NNTP SHALL stay in the same state after 452 returning this code. The client NNTP may try the extensions 453 either as the need arises or configure itself for the basic 454 NNTP functionality defined in this document. 456 8.1.5 Responses from improperly implemented servers 458 A server NNTP that improperly implements the LIST EXTENSIONS 459 command may return an empty list. Clients SHALL accommodate 460 this protocol violation and interpret it as a response code 461 402. 463 9. The AUTHENTICATION Step 465 9.1 AUTHINFO 467 AUTHINFO is used to inform a server about the identity of a 468 user of the server. In all cases, clients MUST provide this 469 information when requested by the server. Servers are not 470 required to accept authentication information that is 471 volunteered by the client. Clients MUST accommodate servers 472 that reject any authentication information volunteered by the 473 client. 475 9.1.1 AUTHINFO 477 AUTHINFO USER username 479 AUTHINFO PASS password 481 When authorization is required, the server MUST send a 450 482 response requesting authorization from the client. The client 483 MUST enter AUTHINFO USER username in order to make use of the 484 AUTHINFO authentication step. If the server will accept this 485 form of authentication and a password is required to complete 486 the authentication step, the server MUST respond with a 350 487 response. The client MUST then send AUTHINFO PASS followed by 488 one or more space characters followed by the password. If the 489 username/password combination is valid or no password is 490 required, the server MUST return a 250 response and the client 491 should then retry the original command to which the server 492 responded with the 450 response. The command SHALL then be 493 processed by the server normally. If the combination is not 494 valid, the server MUST return a 452 response. 496 If the server returns 501, this means that the authenticator 497 invocation was syntactically incorrect, or that this form of 498 AUTHINFO is not supported. 500 If the requested authenticator capability is not found or 501 there is some other unspecified server program error, the 502 server MUST return the 503 response code. 504 9.1.1.1 Responses 506 250 Authorization accepted 507 350 Continue with authorization sequence 508 450 Authorization required for this command 509 452 Authorization rejected 510 501 Command not supported or Command Syntax Error 511 503 Program error, function not performed 513 9.1.2 AUTHINFO GENERIC 514 AUTHINFO GENERIC authenticator arguments... 516 AUTHINFO GENERIC is used to identify a specific entity to the 517 server using arbitrary authentication or identification 518 protocols. The desired protocol is indicated by the 519 authenticator parameter, and any number of parameters can be 520 passed to the authenticator. 522 When authorization is required, the server will send a 450 523 response requesting authorization from the client. 525 The client should enter AUTHINFO GENERIC followed by the 526 authenticator name and the arguments if any. The 527 authenticator and arguments must not contain the sequence 528 "..". 530 The server will attempt to engage the server end 531 authenticator; similarly, the client should engage the client 532 end authenticator. The server end authenticator will then 533 initiate authentication using the NNTP sockets (if appropriate 534 for that authentication protocol), using the protocol 535 specified by the authenticator name. These authentication 536 protocols are not included in this document, but are similar 537 in structure to those referenced in RFC 1731[7] for the IMAP-4 538 protocol. 540 If the server returns 501, this means that the authenticator 541 invocation was syntactically incorrect, or that AUTHINFO 542 GENERIC is not supported. The client should retry using the 543 AUTHINFO GENERIC command. 545 If the requested authenticator capability is not found or 546 there is some other unspecified server program error, the 547 server returns the 503 response code. 549 The authenticators converse using their protocol until 550 complete. If the authentication succeeds, the server 551 authenticator will terminate with a 250, and the client can 552 continue by reissuing the command that prompted the 350. If 553 the authentication fails, the server will respond with a 452. 555 The client must provide authentication when requested by the 556 server. The server may request authentication at any time. 557 Servers may request authentication more than once during a 558 single session. 560 When the server authenticator completes, it provides to the 561 server (by a mechanism herein undefined) the email address of 562 the user, and potentially what the user is allowed to access. 563 Once authenticated and if the email address provided by the 564 authenticator does not match the user-supplied From: line, the 565 server SHALL insert a Sender: line into any posted articles 566 using the email address provided by the authenticator. 568 Additionally, the server should log the event, including the 569 user's authenticated email address (if available). This will 570 provide a means by which subsequent statistics generation can 571 associate news group references with unique entities - not 572 necessarily by name. 574 9.1.2.1 Responses 575 250 Authorization accepted 576 450 Authorization required for this command 577 452 Authorization rejected 578 501 Command not supported or Command Syntax Error 579 503 Program error, function not performed 580 nnn authenticator-specific protocol. 582 9.1.3 Transition Issues 583 The implementations of AUTHINFO commonly in use prior to the 584 release of this memo have a different response code set. The 585 code 281 was used in place of 250, 381 and 480 were used in 586 place of 450 and 482 and 502 were used in place of 452. Client 587 coded to be compliant with this spec may also want to be able 588 to accommodate the older codes to lessen the impact of the 589 transition to this specification. 591 10. The NEWS EXCHANGE Step 593 During this step, two basic types of transactions occur: 595 article retrieval from the server and article posting to the 596 server. 598 10.1 Article Retrieval 600 News reading clients have available a variety of mechanisms to 601 retrieve articles via NNTP. The news articles are stored and 602 indexed using three types of keys. One key is the message id 603 of an article. According to RFC 1036, this identifier should 604 be globally unique. Another key is composed of the news group 605 name and the article number within that news group. That key 606 MUST be unique to a particular server (there will be only one 607 article with that number within a particular news group), but 608 is not required to be globally unique. Additionally, because 609 the same article can be cross-posted to multiple news groups, 610 there may be multiple keys that point to the same article on 611 the same server. The final key is the arrival timestamp, 612 giving the time that the article arrived at the server. 614 The server MUST ensure that article numbers are issued in 615 order of arrival timestamp; that is, articles arriving later 616 MUST have higher numbers than those that arrive earlier. The 617 server SHOULD allocate the next sequential unused number to 618 each new article. 620 Article numbers MUST lie between 1 and 4,294,967,295 621 inclusive. The client and server SHOULD NOT use leading zeroes 622 in specifying article numbers, and MUST NOT use more than 16 623 digits. In some situations, the value zero replaces an article 624 number to show some special situation. One case involves 625 responses to the ARTICLE, STAT, BODY and HEAD commands where a 626 is specified as the argument. In those cases, the 627 "current article pointer" is not changed. 629 10.1.1 Article Retrieval by News Group Name and Article Number 631 The following commands are used to set the current news group 632 name and the "current article pointer" which is used by other 633 commands for article retrieval. 635 10.1.1.1 GROUP 637 GROUP ggg 639 The required parameter ggg is the name of the news group to be 640 selected (e.g. "news.software.b"). A list of valid news groups 641 may be obtained by using the LIST keyword. See section 10.4 642 for more information on the LIST keyword. 644 The successful selection response will return the article 645 numbers of the first and last articles in the group at the 646 moment of selection (these numbers are referred to as the 647 "reported low water mark" and the "reported high water mark"), 648 and an estimate of the number of articles on file in the 649 group. 651 If the group is not empty, the estimate MUST be at least the 652 actual number of articles available, and MUST be no greater 653 than one more than the difference between the reported low and 654 high water marks. (Some implementations will actually count 655 the number of articles on file. Others will just subtract the 656 low water mark from the high water mark and add one to get an 657 estimate.) 659 If the group is empty, one of the following three situations 660 will occur. Clients MUST accept all three cases; servers MUST 661 NOT represent an empty group in any other way. 663 . The high water mark will be one less than the low water mark, 664 and the estimated article count will be zero. Servers SHOULD 665 use this method to show an empty group. This is the only time 666 that the high water mark can be less than the low water mark. 667 . 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. In the cases where the argument 790 is a message-id, the article number specified in the response 791 must be zero. This is one of the special cases described in 792 section 10.1. 794 An article, as defined by RFC 1036, consists of two parts: the 795 article headers and the article body. When responding to an 796 article command, the server returns the entire article 797 contents and does not attempt to alter or translate them in 798 any way. 800 10.2.1 ARTICLE 802 ARTICLE [|nnn] 804 This response displays the header, a blank line, then the body 805 (text) of the specified article. The optional parameter nnn is 806 the numeric id of an article in the current news group and 807 SHOULD be chosen from the range of articles provided when the 808 news group was selected. If it is omitted, the current 809 article is assumed. Message-id is the message id of an article 810 as shown in that article's header. 812 Please note that the internally-maintained "current article 813 pointer" MUST NOT be altered when the message-id argument is 814 used. This is both to facilitate the presentation of articles 815 that may be referenced within an article being read, and 816 because of the semantic difficulties of determining the proper 817 sequence and membership of an article which may have been 818 posted to more than one news group. 820 The internally-maintained "current article pointer" MUST be 821 set when a valid article number is specified as the argument. 822 This includes the case when an article number is implied by 823 the use of no argument. 825 A previously valid article number MAY not remain valid if the 826 article has been removed. A previously invalid article number 827 MAY become valid if the article has been reinstated, but such 828 an article number MUST be no less than the reported low water 829 mark for that group. 831 If there is a valid article to present in a reply to this 832 command, a response indicating the current article number (or 833 zero when the message-id argument is used), a message-id 834 string, and that text is to follow MUST be returned. 836 The message-id string returned is an identification string 837 contained within angle brackets ("<" and ">"), which is 838 derived from the header of the article itself. The Message-ID 839 header line (required by RFC 1036) from the article must be 840 used to supply this information. If the message-id header line 841 is missing from the article, a single digit "0" (zero) should 842 be supplied within the angle brackets. 844 Since the message-id field is unique for each article, it may 845 be used by a news reading program to skip duplicate displays 846 of articles that have been posted more than once, or to more 847 than one news group. 849 10.2.1.1 Responses 850 220 n article retrieved - head and body follow (n = 851 article number, = message-id) 852 412 no news group has been selected 853 420 no current article has been selected 854 423 no such article number in this group 855 430 no such article found 857 10.2.2 HEAD 858 HEAD [|nnn] 860 This response displays the header of the specified article. 861 The optional parameter nnn is the numeric id of an article in 862 the current news group and SHOULD be chosen from the range of 863 articles provided when the news group was selected. If it is 864 omitted, the current article is assumed. Message-id is the 865 message id of an article as shown in that article's header. 867 Please note that the internally-maintained "current article 868 pointer" MUST NOT be altered when the message-id argument is 869 used. This is both to facilitate the presentation of articles 870 that may be referenced within an article being read, and 871 because of the semantic difficulties of determining the proper 872 sequence and membership of an article which may have been 873 posted to more than one news group. 875 The internally-maintained "current article pointer" MUST be 876 set when a valid article number is specified as the argument. 877 This includes the case when an article number is implied by 878 the use of no argument. 880 A previously valid article number MAY not remain valid if the 881 article has been removed. A previously invalid article number 882 MAY become valid if the article has been reinstated, but such 883 an article number MUST be no less than the reported low water 884 mark for that group. 886 If there is a valid article to present in a reply to this 887 command, a response indicating the current article number (or 888 zero when the message-id argument is used), a message-id 889 string, and that text is to follow MUST be returned. 891 The message-id string returned is an identification string 892 contained within angle brackets ("<" and ">"), which is 893 derived from the header of the article itself. The Message-ID 894 header line (required by RFC 1036) from the article must be 895 used to supply this information. If the message-id header line 896 is missing from the article, a single digit "0" (zero) should 897 be supplied within the angle brackets. 899 Since the message-id field is unique for each article, it may 900 be used by a news reading program to skip duplicate displays 901 of articles that have been posted more than once, or to more 902 than one news group. 904 10.2.2.1 Responses 905 221 n article retrieved - head follows 906 412 no news group has been selected 907 420 no current article has been selected 908 423 no such article number in this group 909 430 no such article found 911 10.2.3 BODY 912 BODY [|nnn] 914 This response displays the body (text) of the specified 915 article. The optional parameter nnn is the numeric id of an 916 article in the current news group and SHOULD be chosen from 917 the range of articles provided when the news group was 918 selected. If it is omitted, the current article is assumed. 919 Message-id is the message id of an article as shown in that 920 article's header. 922 Please note that the internally-maintained "current article 923 pointer" MUST NOT be altered when the message-id argument is 924 used. This is both to facilitate the presentation of articles 925 that may be referenced within an article being read, and 926 because of the semantic difficulties of determining the proper 927 sequence and membership of an article which may have been 928 posted to more than one news group. 930 The internally-maintained "current article pointer" MUST be 931 set when a valid article number is specified as the argument. 932 This includes the case when an article number is implied by 933 the use of no argument. 935 A previously valid article number MAY not remain valid if the 936 article has been removed. A previously invalid article number 937 MAY become valid if the article has been reinstated, but such 938 an article number MUST be no less than the reported low water 939 mark for that group. 941 If there is a valid article to present in a reply to this 942 command, a response indicating the current article number (or 943 zero when the message-id argument is used), a message-id 944 string, and that text is to follow MUST be returned. 946 The message-id string returned is an identification string 947 contained within angle brackets ("<" and ">"), which is 948 derived from the header of the article itself. The Message-ID 949 header line (required by RFC 1036) from the article must be 950 used to supply this information. If the message-id header line 951 is missing from the article, a single digit "0" (zero) should 952 be supplied within the angle brackets. 954 Since the message-id field is unique for each article, it may 955 be used by a news reading program to skip duplicate displays 956 of articles that have been posted more than once, or to more 957 than one news group. 959 10.2.3.1 Responses 960 222 n article retrieved - body follows 961 412 no news group has been selected 962 420 no current article has been selected 963 423 no such article number in this group 964 430 no such article found 966 10.2.4 STAT 967 STAT [|nnn] 969 This response returns only status information; no article 970 contents are returned. The optional parameter nnn is the 971 numeric id of an article in the current news group and SHOULD 972 be chosen from the range of articles provided when the news 973 group was selected. If it is omitted, the current article is 974 assumed. Message-id is the message id of an article as shown 975 in that article's header. 977 Please note that the internally-maintained "current article 978 pointer" MUST NOT be altered when the message-id argument is 979 used. This is both to facilitate the presentation of articles 980 that may be referenced within an article being read, and 981 because of the semantic difficulties of determining the proper 982 sequence and membership of an article which may have been 983 posted to more than one news group. 985 The internally-maintained "current article pointer" MUST be 986 set when a valid article number is specified as the argument. 987 This includes the case when an article number is implied by 988 the use of no argument. 990 A previously valid article number MAY not remain valid if the 991 article has been removed. A previously invalid article number 992 MAY become valid if the article has been reinstated, but such 993 an article number MUST be no less than the reported low water 994 mark for that group. 996 If there is a valid article to present in a reply to this 997 command, a response indicating the current article number (or 998 zero when the message-id argument is used) and a message-id 999 string MUST be returned. 1001 The message-id string returned is an identification string 1002 contained within angle brackets ("<" and ">"), which is 1003 derived from the header of the article itself. The Message-ID 1004 header line (required by RFC 1036) from the article must be 1005 used to supply this information. If the message-id header line 1006 is missing from the article, a single digit "0" (zero) should 1007 be supplied within the angle brackets. 1009 Since the message-id field is unique for each article, it may 1010 be used by a news reading program to skip duplicate displays 1011 of articles that have been posted more than once, or to more 1012 than one news group. 1014 10.2.4.1 Responses 1015 223 n article retrieved - request text separately 1016 412 no news group has been selected 1017 420 no current article has been selected 1018 423 no such article number in this group 1019 430 no such article found 1021 10.3 Article Posting 1023 Article posting is done in one of two modes: individual 1024 article posting from news reading clients and article transfer 1025 from other news servers. 1027 10.3.1 POST 1029 POST 1031 If posting is allowed, response code 340 MUST be returned to 1032 indicate that the article to be posted should be sent. 1033 Response code 440 MUST be sent if that posting is prohibited 1034 for some installation-dependent reason. 1036 If posting is permitted, the article MUST be presented to the 1037 server by the client in the format specified by RFC 1036. The 1038 text forming the header and body of the message to be posted 1039 MUST be sent by the client using the conventions for text 1040 received from the news server: A single period (".") on a line 1041 indicates the end of the text, with lines starting with a 1042 period in the original text having that period doubled during 1043 transmission. 1045 Following the presentation of the termination sequence by the 1046 client, the server MUST return a response code indicating 1047 success or failure of the article transfer. 1049 No attempt shall be made by the server to filter characters, 1050 fold or limit lines, or otherwise process incoming text. The 1051 intent is that the server just passes the incoming message to 1052 be posted to the server installation's news posting software, 1053 which is not part of this specification. 1055 10.3.1.1 Responses 1057 240 article received ok 1058 340 send article to be posted. End with . 1059 440 posting not allowed 1060 441 posting failed 1062 10.3.2 IHAVE 1064 IHAVE 1066 The IHAVE command informs the server that the client has an 1067 article whose id is . If the server desires a copy 1068 of that article, it MUST return a response instructing the 1069 client to send the entire article. If the server does not want 1070 the article (if, for example, the server already has a copy of 1071 it), a response indicating that the article is not wanted MUST 1072 be returned. 1074 If transmission of the article is requested, the client MUST 1075 send the entire article, including header and body, in the 1076 manner specified for text transmission from the server. A 1077 response code indicating success or failure of the transferal 1078 of the article MUST be returned by the server. 1080 This function differs from the POST command in that it is 1081 intended for use in transferring already-posted articles 1082 between hosts. Normally it will not be used when the client is 1083 a personal news reading program. In particular, this function 1084 will invoke the server's news posting program with the 1085 appropriate settings (flags, options, etc.) to indicate that 1086 the forthcoming article is being forwarded from another host. 1088 However, the server may elect not to post or forward the 1089 article if after further examination of the article it deems 1090 it inappropriate to do so. Reasons for such subsequent 1091 rejection of an article may include such problems as 1092 inappropriate news groups or distributions, disk space 1093 limitations, article lengths, garbled headers, and the like. 1094 These are typically restrictions enforced by the server host's 1095 news software and not necessarily the NNTP server itself. 1097 10.3.2.1 Responses 1099 235 article transferred ok 1100 335 send article to be transferred. End with . 1102 435 article not wanted - do not send it 1103 436 transfer failed - try again later 1104 437 article rejected - do not try again 1106 Because some host news posting software may not be able to 1107 immediately render status on the whether an article is 1108 inappropriate for posting or forwarding, an NNTP server MAY 1109 acknowledge the successful transfer of the article and later 1110 silently discard it. Thus an NNTP server may return the 235 1111 acknowledgment code and later discard the received article. 1113 10.4 The LIST Keyword 1115 10.4.1 LIST 1117 LIST [ACTIVE [wildmat]] 1119 The response to the LIST keyword with no parameters returns a 1120 list of valid news groups and associated information. Each 1121 news group is sent as a line of text in the following format: 1123 group last first status 1125 where is the name of the news group, is the 1126 number of the last known article currently in that news group, 1127 is the number of the first article currently in the 1128 news group, and indicates the current status of the 1129 group on this server. Typically, the will be consist 1130 of the ASCII character `y' where posting is permitted, `n' 1131 where posting is not permitted and `m' where postings will be 1132 forwarded to the news group moderator by the news server. 1133 Other status strings exist and their definition is outside the 1134 scope of this specification. 1136 The and fields will always be numeric. They 1137 may have leading zeros. If the field evaluates to less 1138 than the field, there are no articles currently on 1139 file in the news group. 1141 Note that posting may still be prohibited to a client although 1142 the LIST command indicates that posting is permitted to a 1143 particular news group. See the POST command for an explanation 1144 of client prohibitions. The posting flag exists for each news 1145 group because some news groups are moderated or are digests, 1146 and therefore cannot be posted to; that is, articles posted to 1147 them must be mailed to a moderator who will post them for the 1148 original poster. This is independent of the posting 1149 permission granted to a client by the NNTP server. 1151 Please note that an empty list (i.e., the text body returned 1152 by this command consists only of the terminating period) is a 1153 possible valid response, and indicates that there are 1154 currently no valid news groups. 1156 If the optional matching parameter is specified, the list is 1157 limited to only the groups that match the pattern. 1159 Specifying a single group is usually very efficient for the 1160 server, and multiple groups may be specified by using wildmat 1161 patterns (described in section 5), not regular expressions. 1163 10.4.1.1 Responses 1164 215 list of news groups follows 1166 10.4.2 LIST ACTIVE.TIMES 1168 LIST ACTIVE.TIMES [wildmat] 1170 The active.times file is maintained by some news transports 1171 systems to contain information about the when and who created 1172 a particular news group. The format of this file generally 1173 includes three fields. The first field is the name of the news 1174 group. The second is the time when this group was created on 1175 this news server measured in seconds since January 1, 1970. 1176 The third is the email address of the entity that created the 1177 news group. When executed, the information is displayed 1178 following the 215 response. When display is completed, the 1179 server will send a period on a line by itself. If the 1180 information is not available, the server will return the 503 1181 error response. 1183 If the optional matching parameter is specified, the list is 1184 limited to only the groups that match the pattern. 1186 Specifying a single group is usually very efficient for the 1187 server, and multiple groups may be specified by using wildmat 1188 patterns (described in section 5), not regular expression 1190 10.4.2.1 Responses 1192 215 information follows 1193 503 program error, function not performed 1195 10.4.3 LIST DISTRIBUTIONS 1197 LIST DISTRIBUTIONS 1199 The distributions file is maintained by some news transport 1200 systems to contain information about valid values for the 1201 Distribution: line in a news article header and about what the 1202 values mean. Each line contains two fields, the value and a 1203 short explanation on the meaning of the value. When executed, 1204 the information is displayed following the 215 response. When 1205 display is completed, the server will send a period on a line 1206 by itself. If the information is not available, the server 1207 will return the 503 error response. 1209 10.4.3.1 Responses 1211 215 information follows 1212 503 program error, function not performed 1214 10.4.4 LIST DISTRIB.PATS 1216 LIST DISTRIB.PATS 1218 The distrib.pats file is maintained by some news transport 1219 systems to contain default values for the Distribution: line 1220 in a news article header when posting to particular news 1221 groups. This information could be used to provide a default 1222 value for the Distribution: line in the header when posting an 1223 article. The information returned contains three fields 1224 separated by colons. The first column is a weight. The second 1225 is a group name or a wildmat pattern that can be used to match 1226 a group name. The third is the value of the Distribution: 1227 line that should be used when the group name matches and the 1228 weight value is the highest. All this processing is done by 1229 the news posting client and not by the server itself. The 1230 server provides this information to the client for it to use 1231 or ignore as it chooses. When executed, the information is 1232 displayed following the 215 response. When display is 1233 completed, the server will send a period on a line by itself. 1235 If the information is not available, the server will return 1236 the 503 error response. 1238 10.4.4.1 Responses 1240 215 information follows 1241 503 program error, function not performed 1243 10.4.5 LIST NEWSGROUPS 1245 LIST NEWSGROUPS [wildmat] 1247 The newsgroups file is maintained by some news transport 1248 systems to contain the name of each news group that is 1249 active on the server and a short description about the 1250 purpose of each news group. Each line in the file contains 1251 two fields, the news group name and a short explanation of 1252 the purpose of that news group. When executed, the 1253 information is displayed following the 215 response. When 1254 display is completed, the server will send a period on a 1255 line by itself. If the information is not available, the 1256 server will return the 503 response. If the optional 1257 matching parameter is specified, the list is limited to only 1258 the groups that match the pattern (no matching is done on 1259 the group descriptions). Specifying a single group is 1260 usually very efficient for the server, and multiple groups 1261 may be specified by using wildmat patterns (see section 5), 1262 not regular expressions. If nothing is matched an empty list 1263 is returned, not an error. 1265 10.4.5.1 Responses 1267 215 information follows 1268 503 program error, function not performed 1270 10.4.6 LIST OVERVIEW.FMT 1272 LIST OVERVIEW.FMT 1274 The overview.fmt file is maintained by some news transport 1275 systems to contain the order in which header information is 1276 stored in the overview databases for each news group. When 1277 executed, news article header fields are displayed one line at 1278 a time in the order in which they are stored in the overview 1279 database[8] following the 215 response. When display is 1280 completed, the server will send a period on a line by itself. 1281 If the information is not available, the server will return 1282 the 503 response. 1284 Please note that if the header has the word "full" (without 1285 quotes) after the colon, the header's name is prepended to its 1286 field in the output returned by the server. 1288 10.4.6.1 Responses 1290 215 information follows 1291 503 program error, function not performed 1293 10.4.7 LIST SUBSCRIPTIONS 1295 LIST SUBSCRIPTIONS 1297 This command is used to get a default subscription list for 1298 new users of this server. The order of groups is significant. 1300 When this list is available, it is preceded by the 215 1301 response and followed by a period on a line by itself. When 1302 this list is not available, the server returns a 503 response 1303 code. 1305 10.4.7.1 Responses 1307 215 information follows 1308 503 program error, function not performed 1310 10.4.8 LISTGROUP 1312 LISTGROUP [ggg] 1314 The LISTGROUP command is used to get a listing of all the 1315 article numbers in a particular news group. 1317 The optional parameter ggg is the name of the news group to 1318 be selected (e.g. "news.software.b"). A list of valid news 1319 groups may be obtained from the LIST command. If no group is 1320 specified, the current group is used as the default 1321 argument. 1323 The successful selection response will be a list of the 1324 article numbers in the group followed by a period on a line 1325 by itself. 1327 When a valid group is selected by means of this command, the 1328 internally maintained "current article pointer" MUST be set 1329 to the first article in the group. If an invalid group is 1330 specified, the previously selected group and article remain 1331 selected. If an empty news group is selected, the "current 1332 article pointer" may be in an indeterminate state and should 1333 not be used. 1335 The group name MUST match a news group obtained from the 1336 LIST command or an error will result, else the server will 1337 response with the 411 error code. 1339 10.4.8.1 Responses 1341 211 list of article numbers follow 1342 411 No such group 1343 412 Not currently in news group 1345 10.4.9 OVER 1347 OVER [range] 1349 The OVER command returns information from the overview 1350 database for the article(s) specified. The information 1351 returned in the response to this command can be used by 1352 clients to follow discussion threads. 1354 The optional range argument may be any of the following: 1356 . an article number 1357 . an article number followed by a dash to indicate all following 1358 . an article number followed by a dash followed by another 1359 article number 1360 If no argument is specified, then information from the current 1361 article is displayed. Successful responses start with a 224 1362 response followed by the overview information for all matched 1363 messages. Once the output is complete, a period is sent on a 1364 line by itself. If no argument is specified, the information 1365 for the current article is returned. A news group must have 1366 been selected earlier, else a 412 error response is returned. 1367 If no articles are in the range specified, a 420 error 1368 response is returned by the server. A 502 response will be 1369 returned if the client only has permission to transfer 1370 articles. 1372 Each line of output MUST be formatted with the article number, 1373 followed by each of the headers in the overview database or 1374 the article itself (when the data is not available in the 1375 overview database) for that article separated by a US-ASCII 1376 tab character. The sequence of fields must be in this order: 1377 subject, author, date, message-id, references, byte count, and 1378 line count. Other optional fields may follow line count. These 1379 fields are specified by examining the response to the LIST 1380 OVERVIEW.FMT command. Where no data exists, a null field must 1381 be provided (i.e. the output will have two tab characters 1382 adjacent to each other). Servers should not output fields for 1383 articles that have been removed since the overview database 1384 was created. 1386 Note that all US-ASCII tab characters in any header data that 1387 is returned will be converted to a single US-ASCII space 1388 character. 1390 10.4.9.1 Responses 1392 224 Overview information follows 1393 412 No news group current selected 1394 420 No article(s) selected 1395 502 no permission 1397 10.4.10 PAT 1399 PAT header range| [pat [pat...]] 1401 The PAT command is used to retrieve specific headers from 1402 specific articles, based on pattern matching on the contents 1403 of the header. 1405 The required header parameter is the name of a header line 1406 (e.g. "subject") in a news group article. See RFC-1036 for a 1407 list of valid header lines. The required range argument may be 1408 any of the following: 1410 . an article number 1411 . an article number followed by a dash to indicate all following 1412 . an article number followed by a dash followed by another 1413 article number. 1414 The required message-id argument indicates a specific article. 1415 The range and message-id arguments are mutually exclusive. If 1416 there are additional arguments, they are joined together 1417 separated by a single space to form one complete pattern. If 1418 there are no additional arguments, a wildmat "*" is the 1419 default. Successful responses start with a 221 response 1420 followed by article number, a US-ASCII space, and the header 1421 from that message in which the pattern matched the contents of 1422 the specified header line. A valid response includes an empty 1423 list (indicating that there was no matches). Once the output 1424 is complete, a period is sent on a line by itself. If the 1425 optional argument is a message-id and no such article exists, 1426 the 430 error response shall be returned. A 502 response shall 1427 be returned if the client only has permission to transfer 1428 articles. 1430 10.4.10.1 Responses 1432 221 Header follows 1433 430 no such article 1434 502 no permission 1436 11. The CONCLUSION Step 1438 11.1 QUIT 1440 QUIT 1442 The server process MUST acknowledge the QUIT command and then 1443 closes the connection to the client. This is the preferred 1444 method for a client to indicate that it has finished all its 1445 transactions with the NNTP server. 1447 If a client simply disconnects (or the connection times out or 1448 some other fault occurs), the server SHALL gracefully cease 1449 its attempts to service the client. 1451 11.1.1 Responses 1453 205 closing connection - goodbye! 1455 12. Other Keywords 1457 There are other Keywords that may be used at any time between 1458 the beginning of a session and its termination. Using these 1459 keywords do not alter any state information, but the response 1460 generated from the use of these keywords may provide useful 1461 information to clients that use them. 1463 12.1 DATE 1465 DATE 1467 This command exists to help clients find out the current time 1468 from the server's perspective. This command should not be 1469 used as a substitute for NTP[9], but to provide information 1470 that might be useful when using the NEWNEWS command (see 1471 section 12.4). 1473 This command returns a one-line response code of 111 followed 1474 by the UTC (or GMT) date and time on the server in the form 1475 YYYYMMDDhhmmss. 1477 12.1.1 Responses 1479 111 YYYYMMDDhhmmss 1481 12.2 The HELP Command 1483 HELP 1484 This command provides a short summary of commands that are 1485 understood by this implementation of the server. The help text 1486 will be presented as a textual response terminated by a single 1487 period on a line by itself. 1489 This text is not guaranteed to be in any particular format and 1490 shall not be used by clients as a replacement for the LIST 1491 EXTENSIONS command described in section 8.1. 1493 12.2.1 Responses 1495 100 help text follows 1497 12.3 NEWGROUPS 1499 NEWGROUPS date time [GMT|UTC] [] 1501 A list of newsgroups created since MUST be 1502 listed in the same format as the LIST command. 1504 The date is sent as 6 or 8 digits in the format [XX]YYMMDD, 1505 where XX is the first two digits of the year, YY is the last 1506 two digits of the year, MM is the two digits of the month 1507 (with leading zero, if appropriate), and DD is the day of the 1508 month (with leading zero, if appropriate). If the first two 1509 digits of the year are not specified, the year is taken to be 1510 in the range 1951 to 2050 inclusive. 1512 Time must also be specified. It must be as 6 digits HHMMSS 1513 with HH being hours in the 24-hour clock 00-23, MM minutes 00- 1514 59, and SS seconds 00-60, which allows for leap seconds. The 1515 tokens "GMT" and "UTC" specifies that the date and time are 1516 given in UTC. If the tokens "GMT" and "UTC" are omitted then 1517 the date and time are specified in the server's local 1518 timezone. Note that there is no way within this specification 1519 of NNTP to establish the server's local timezone. 1521 The optional parameter "distributions" is a list of 1522 distribution groups, enclosed in angle brackets. If 1523 specified, the distribution portion of an article's header 1524 will be examined for a match with the distribution categories 1525 listed, and only those articles which have a distribution in 1526 the list will be listed. If more than one distribution is to 1527 be supplied, they must be separated by commas within the angle 1528 brackets.. 1530 Note that an empty list (i.e., the text body returned by this 1531 command consists only of the terminating period) is a possible 1532 valid response, and indicates that there are currently no new 1533 newsgroups. 1535 12.3.1 Responses 1537 231 list of new newsgroups follows 1539 12.4 NEWNEWS 1541 NEWNEWS newsgroups date time [GMT] [] 1543 A list of message-ids of articles posted or received to the 1544 specified news group since "date" will be listed. The format 1545 of the listing will be one message-id per line, as though text 1546 were being sent. A single line consisting solely of one 1547 period followed by CR-LF will terminate the list. 1549 Date and time are in the same format as the NEWGROUPS command. 1550 The newsgroups parameter must be in wildmat format and may 1551 consist of multiple wildmat constructs separated by a US-ASCII 1552 comma character. 1554 The optional parameter "distributions" is a list of 1555 distribution groups, enclosed in angle brackets. If 1556 specified, the distribution portion of an article's header 1557 will be examined for a match with the distribution categories 1558 listed, and only those articles which have a distribution in 1559 the list will be listed. If more than one distribution is to 1560 be supplied, they must be separated by commas within the angle 1561 brackets. 1563 The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to 1564 distribute news is discussed in an earlier part of this 1565 document. 1567 Note that an empty list (i.e., the text body returned by this 1568 command consists only of the terminating period) is a possible 1569 valid response, and indicates that there is currently no new 1570 news. 1572 12.4.1 Responses 1574 230 list of new articles by message-id follows 1576 13. Framework for NNTP Extensions 1578 Although NNTP is widely and robustly deployed, some parts of 1579 the Internet community might wish to extend the NNTP service. 1580 This memo defines a means whereby an extended NNTP client may 1581 query the server to determine the service extensions that it 1582 supports. 1584 It must be emphasized that any extension to the NNTP service 1585 should not be considered lightly. NNTP's strength comes 1586 primarily from its simplicity. Experience with many protocols 1587 has shown that: 1589 Protocols with few options tend towards ubiquity, whilst 1590 protocols with many options tend towards obscurity. 1592 This means that each and every extension, regardless of its 1593 benefits, must be carefully scrutinized with respect to its 1594 implementation, deployment, and interoperability costs. In 1595 many cases, the cost of extending the NNTP service will likely 1596 outweigh the benefit. 1598 Given this environment, the framework for the extensions 1599 described in this memo consists of: 1601 a) a mechanism for clients to determine a server's available 1602 extensions 1603 b) a registry of NNTP service extensions 1605 The LIST EXTENSIONS command is described in section 8.1 of 1606 this memo and is the mechanism for clients to use to determine 1607 what extensions are available for client use. 1609 The IANA shall maintain a registry of NNTP service extensions. 1611 Associated with each such extension is a corresponding NNTP 1612 keyword value. Each service extension registered with the IANA 1613 MUST be defined in an RFC. Such RFCs either must be on the 1614 standards-track or must define an IESG-approved experimental 1615 protocol. The definition must include: 1617 . the textual name of the NNTP service extension; 1618 . the NNTP keyword value associated with the extension; 1619 . the syntax and possible values of parameters associated with 1620 the NNTP keyword value; 1621 . any additional NNTP verbs associated with the extension 1622 . (additional verbs will usually be, but are not required to be, 1623 the same as the NNTP keyword value); 1624 . any new parameters the extension associates with any other 1625 NNTP verbs; 1626 . how support for the extension affects the behavior of a server 1627 and client NNTP; and, 1628 . the increment by which the extension is increasing the maximum 1629 length of the any commands over that specified in this 1630 document. 1631 In addition, any NNTP keyword value that starts with an upper 1632 or lower case "X" refers to a local NNTP service extension, 1633 which is used through bilateral, rather than standardized, 1634 agreement. Keywords beginning with "X" may not be used in a 1635 registered service extension. 1637 Any keyword values presented in the NNTP response that do not 1638 begin with "X" must correspond to a standard, standards-track, 1639 or IESG-approved experimental NNTP service extension 1640 registered with IANA. A conforming server must not offer non 1641 "X" prefixed keyword values that are not described in a 1642 registered extension. 1644 Additional verbs are bound by the same rules as NNTP keywords; 1645 specifically, verbs beginning with "X" are local extensions 1646 that may not be registered or standardized and verbs not 1647 beginning with "X" must always be registered. 1649 13.1 Initial IANA Registry 1651 The IANA's initial registry of NNTP service extensions 1652 consists of these entries: 1654 Service Extension NNTP Keyword(s) Added Behavior 1656 Overview Support OVER Defined in this 1657 LIST OVERVIEW.FMT document 1659 Specific Article LISTGROUP Defined in this 1660 Numbers document 1662 Identification and AUTHINFO Defined in this 1663 Authentication AUTHINFO GENERIC document 1665 Character Set CHARSET Defined in this 1666 Selection document 1668 Header Pattern PAT Defined in this 1669 Matching document 1671 14. Augmented BNF[10] Syntax for NNTP Commands 1673 This syntax defines the non-terminal "command". The non-terminal 1674 "parameter" is used for command parameters whose syntax is 1675 specified elsewhere. The syntax is in alphabetical order. Note 1676 that ABNF strings are case insensitive. 1678 article-command = "ARTICLE" [1*WSP (msg-id / article-number)] 1679 *WSP CRLF 1680 article-number = 1*16DIGIT 1681 augument = parameter ; excluding sequence ".." 1682 authenticator = parameter ; excluding sequence ".." 1683 authinfo-generic-command = "AUTHINFO" 1*WSP "GENERIC" 1*WSP 1684 authenticator *(1*WSP argument) *WSP CRLF 1685 authinfo-pass-command = "AUTHINFO" 1*WSP "PASS" 1*WSP password 1686 *WSP CRLF 1687 authinfo-user-command = "AUTHINFO" 1*WSP "USER" 1*WSP username 1688 *WSP CRLF 1690 body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP 1691 CRLL 1692 command = article-command / 1693 authinfo-generic-command / 1694 authinfo-pass-command / 1695 authinfo-user-command / 1696 body-command / 1697 date-command / 1698 group-command / 1699 head-command / 1700 help-command / 1701 ihave-command / 1702 last-command / 1703 list-active-times-command / 1704 list-distrib-pats-command / 1705 list-distributions-command / 1706 list-extensions-command / 1707 list-newsgroups-command / 1708 list-overview-fmt-command / 1709 list-subscriptions-command / 1710 list-command / 1711 listgroup-command / 1712 mode-reader-command / 1713 newgroups-command / 1714 newnews-command / 1715 next-command / 1716 over-command / 1717 pat-command / 1718 post-command / 1719 quit-command / 1720 stat-command 1721 CR = %x0D 1722 CRLF = CR LF 1723 date-command = "DATE" *WSP CRLF 1724 date = 6*8DIGIT 1725 DIGIT = %x30-39 1726 distribution = parameter 1727 group-command = "GROUP" 1*WSP newsgroup *WSP CRLF 1728 head-command = "HEAD" [1*WSP (msg-id / article-number)] *WSP 1729 CRLF 1730 header = parameter 1731 help-command = "HELP" *WSP CRLF 1732 HT = %x09 1733 ihave-command = "IHAVE" 1*WSP msg-id *WSP CRLF 1734 last-command = "LAST" *WSP CRLF 1735 LF = %x0A 1736 list-active-times-command = "LIST" 1*WSP "ACTIVE.TIMES" 1737 [1*WSP wildmat] *WSP CRLF 1738 list-command = "LIST" [1*WSP "ACTIVE" [1*WSP wildmat]] *WSP 1739 CRLF 1740 list-distrib-pats-command = "LIST" 1*WSP "DISTRIB.PATS" *WSP 1741 CRLF 1742 list-distributions-command = "LIST" 1*WSP "DISTRIBUTIONS" *WSP 1743 CRLF 1745 list-extensions-command = "LIST" 1*WSP "EXTENSIONS" *WSP CRLF 1746 list-newsgroups-command = "LIST" 1*WSP "NEWSGROUPS" [1*WSP 1747 wildmat] 1748 *WSP CRLF 1749 list-overview-fmt-command = "LIST" 1*WSP "OVERVIEW.FMT" *WSP 1750 CRLF 1751 list-subscriptions-command = "LIST" 1*WSP "SUBSCRIPTIONS" *WSP 1752 CRLF 1753 listgroup-command = "LISTGROUP" [1*WSP newsgroup] *WSP CRLF 1754 mode-reader-command = "MODE" 1*WSP "READER" *WSP CRLF 1755 msg-id = 1756 newgroups-command = "NEWGROUPS" 1*WSP date 1*WSP time [1*WSP 1757 "GMT"/"UTC"][1*WSP "<" distribution *("," distribution) 1758 ">"] *WSP CRLF 1759 newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup) 1760 1*WSP date 1*WSP time [1*WSP "GMT"/"UTC"] 1761 [1*WSP "<" distribution *("," distribution) ">"] 1762 *WSP CRLF 1763 newsgroup = parameter 1764 next-command = "NEXT" *WSP CRLF 1765 over-command = "OVER" [1*WSP range] *WSP CRLF 1766 parameter = 1*(%x21-FF) ; generic command parameter 1767 password = parameter 1768 pat-command = "PAT" 1*WSP header 1*WSP (range / msg-id) 1769 *(1*WSP wildmat) *WSP CRLF 1770 post-command = "POST" *WSP CRLF 1771 quit-command = "QUIT" *WSP CRLF 1772 range = article-number ["-" [article-number]] 1773 SP = %x20 1774 stat-command = "STAT" [1*WSP (msg-id / article-number)] *WSP 1775 CRLF 1776 time = 6DIGIT 1777 username = parameter 1778 wildmat = 1*("*" / "?" / wildmat-exact / wildmat-set / "\" 1779 %x21-FF) 1780 wildmat-exact = %x21-29 / %x2B-3E / %x40-5A / %x5D-FF 1781 ; exclude space * ? [ \ 1782 wildmat-non-hyphen = %x21-2C / %x2E-FF ; exclude space - 1783 wildmat-set = "[" ["^"] ["]" / "-"] 1784 *(wildmat-non-hyphen ["-" wildmat-non-hyphen]) 1785 ["-"] "]" 1786 WSP = SP / HT 1788 15. Security Considerations 1790 The use of the AUTHINFO is optional. This command as 1791 documented has a number of security implications. In the 1792 original form, all passwords are passed in plain text and 1793 could be discovered by various forms of network or system 1794 surveillance. The AUTHINFO GENERIC command has the potential 1795 for the same problems if a mechanism is used that also passes 1796 clear text passwords. RFC 1731 discusses these issues in 1797 greater detail. 1799 16. References 1801 [1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", 1802 RFC-977, U.C. San Diego and U.C. Berkeley. 1804 [2] Yergeau, F., "UTF-8, a transformation format of Unicode and 1805 ISO 10646", RFC 2044, Alis Technologies. 1807 [3] Coded Character Set-7-bit American Standard Code for 1808 Information Interchange, ANSI x3.4-1986. 1810 [4] Bradner, Scott, "Key words for use in RFCs to Indicate 1811 Requirement Levels", RFC-2119, Harvard University. 1813 [5] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 1814 distribution, UUNET Technologies, Revision 1.10, April, 1992. 1816 [6] Horton, M.R. and R. Adams, "Standard for interchange of 1817 USENET messages", RFC-1036, AT&T Bell Laboratories and Center 1818 for Seismic Studies, December, 1987. 1820 [7] Meyers, J, "IMAP4 Authentication Mechanisms", RFC-1731, 1821 Carnegie Mellon, December, 1994. 1823 [8] Robertson, Rob, "FAQ: Overview database / NOV General 1824 Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq- 1825 nov.Z, January, 1995. 1827 [9] Mills, David L., "Network Time Protocol (Version 3), 1828 Specification,Implementation and Analysis", RFC-1305, 1829 University of Delaware, March 1992. 1831 [10] Crocker, D. and Overell, P., "Augmented BNF for Syntax 1832 Specifications: ABNF", RFC-2234, Internet Mail Consortium and 1833 Demon Internet, Ltd. 1835 The author gratefully acknowledges the work of the Marshall 1836 Rose & John G. Meyers in RFC 1939 and the work of the DRUMS 1837 working group, specifically RFC 1869, which is the basis of 1838 the NNTP extensions mechanism detailed in this document. 1840 The author gratefully acknowledges the comments and additional 1841 information provided by the following individuals in preparing 1842 one of the progenitors of this document: 1844 . Wayne Davison 1845 . Clive D.W. Feather 1846 . Chris Lewis 1847 . Tom Limoncelli 1848 . Eric Schnoebelen 1849 . Rich Salz 1850 This work was precipitated by the work of various newsreader 1851 authors and newsserver authors, which includes those listed 1852 below: 1854 . Rick Adams -- Original author of the NNTP extensions to the RN 1855 newsreader and last maintainer of Bnews 1856 . Stan Barber -- Original author of the NNTP extensions to the 1857 newsreaders that are part of Bnews. 1858 . Geoff Collyer -- Original author of the OVERVIEW database 1859 proposal and one of the original authors of CNEWS 1860 . Dan Curry -- Original author of the xvnews newsreader 1861 . Wayne Davision -- Author of the first threading extensions to the 1862 RN newsreader (commonly called TRN). 1863 . Geoff Huston -- Original author of ANU NEWS 1864 . Phil Lapsey -- Original author of the UNIX reference 1865 implementation 1866 . Ian Lea -- Maintainer of the TIN newsreader 1867 . Chris Lewis -- First known implementor of the AUTHINFO GENERIC 1868 extension 1869 . Rich Salz -- Original author of INN 1870 . Henry Spencer -- One of the original authors of CNEWS 1871 . Kim Storm -- Original author of the NN newsreader 1873 19. Author's Address 1875 Stan Barber 1876 P.O. Box 300481 1877 Houston, Texas, 77230 1878 Email: 1880 This document expires June 1, 1998.