idnits 2.17.1 draft-ietf-nntpext-base-06.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-27) 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 63 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 362 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [0-9a-zA-Z], [5], [6], [C], [7], [8], [9], [GMT], [S], [XX], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (August 1998) is 9387 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 60 looks like a reference -- Missing reference section? '2' on line 63 looks like a reference -- Missing reference section? '3' on line 64 looks like a reference -- Missing reference section? '4' on line 79 looks like a reference -- Missing reference section? '5' on line 256 looks like a reference -- Missing reference section? '0-9a-zA-Z' on line 291 looks like a reference -- Missing reference section? 'GMT' on line 1468 looks like a reference -- Missing reference section? '6' on line 312 looks like a reference -- Missing reference section? 'C' on line 442 looks like a reference -- Missing reference section? 'S' on line 452 looks like a reference -- Missing reference section? '7' on line 1200 looks like a reference -- Missing reference section? '8' on line 1391 looks like a reference -- Missing reference section? '9' on line 1591 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Barber 3 Expires: January 7, 1999 Academ Consulting Services 4 August 1998 6 Network News Transport Protocol 8 draft-ietf-nntpext-base-06.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 ftp.ietf.org (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 net news 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 net news 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 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. 91 In addition, where examples of interactions between a client 92 host and a server host are provided a "[C]" will be used to 93 represent the client host and a "[S]" will be used to 94 represent the server host. 96 4. Basic Operation. 98 Every NNTP session MUST involve the following in this order: 100 CONNECTION 101 GREETING 102 DISCONNECTION 104 Other steps may occur between the GREETING and DISCONNECTION 105 step. They are: 107 CAPABILITIES DISCOVERY 108 NEWS EXCHANGE 109 CONCLUSION 111 NNTP operates over any reliable data stream 8-bit-wide 112 channel. When running over TCP/IP, the official port for the 113 NNTP service is 119. Initially, the server host starts the 114 NNTP service by listening on a TCP port. When a client host 115 wishes to make use of the service, it MUST establish a TCP 116 connection with the server host by connecting to that host on 117 the same port on which the server is listening. This is the 118 CONNECTION step. When the connection is established, the NNTP 119 server host MUST send a greeting. This is the GREETING step. 120 The client host and server host SHOULD then exchange commands 121 and responses (respectively) until the connection is closed or 122 aborted. This final step is called the DISCONNECTION step. 124 If there is a CONCLUSION step, it MUST immediately precede the 125 DISCONNECTION step. There MUST be only one CONNECTION, 126 CONCLUSION and DISCONNECTION step for each NNTP session. All 127 other steps MAY be repeated as needed. 129 The character set for all NNTP commands is UTF-8. Commands in 130 the NNTP MUST consist of an US-ASCII case-insensitive keyword, 131 which MAY be followed by one or more arguments. An US-ASCII 132 CRLF pair MUST terminate all commands. Multiple commands MUST 133 NOT be permitted on the same line. Keywords MUST consist of 134 printable US-ASCII characters. Unless otherwise noted 135 elsewhere in this document, Arguments SHOULD consist of 136 printable US-ASCII characters. Keywords and arguments MUST be 137 each separated by one or more US-ASCII SPACE or US-ASCII TAB 138 characters. Keywords MUST be at least three US-ASCII 139 characters and MUST NOT exceed 12 US-ASCII characters. 140 Command lines MUST NOT exceed 512 octets, which includes the 141 terminating US-ASCII CRLF pair. Arguments must not exceed 497 142 octets. 144 Each response MUST start with a three-digit status indicator 145 that is sufficient to distinguish all responses. Responses to 146 certain commands MAY be multi-line. In these cases, which are 147 clearly indicated below, after sending the first line of the 148 response and an US-ASCII CRLF, any additional lines are sent, 149 each terminated by an US-ASCII CRLF pair. When all lines of 150 the response have been sent, a final line MUST be sent, 151 consisting of a termination octet (US-ASCII decimal code 046, 152 ".") and an US-ASCII CRLF pair. If any line of the multi-line 153 response begins with the termination octet, the line MUST be 154 "byte-stuffed" by pre-pending the termination octet to that 155 line of the response. Hence, a multi-line response is 156 terminated with the five octets "CRLF.CRLF" (in US-ASCII). 157 When examining a multi-line response, the client MUST check to 158 see if the line begins with the termination octet. If so and 159 if octets other than US-ASCII CRLF follow, the first octet of 160 the line (the termination octet) MUST be stripped away. If so 161 and if US-ASCII CRLF immediately follows the termination 162 character, then the response from the NNTP server is ended and 163 the line containing ".CRLF" (in US-ASCII) MUST NOT considered 164 part of the multi-line response. 166 A NNTP server MAY have an inactivity autologout timer. Such a 167 timer MUST be of at least three minutes duration. The receipt 168 of any command from the client during that interval should 169 suffice to reset the autologout timer. When the timer 170 expires, the server should close the TCP connection without 171 sending any response to the client. 173 4.1 Responses Codes 175 Each response MUST begin with a three-digit response code. 176 These are status reports from the server and indicate the 177 response to the last command received from the client. 179 The first digit of the response broadly indicates the success, 180 failure, or progress of the previous command. 182 1xx - Informative message 183 2xx - Command ok 184 3xx - Command ok so far, send the rest of it. 185 4xx - Command was correct, but couldn't be performed for some 186 reason. 187 5xx - Command unimplemented, or incorrect, or a serious 188 program error occurred. 189 The next digit in the code indicates the function response 190 category. 192 x0x - Connection, setup, and miscellaneous messages 193 x1x - Newsgroup selection 194 x2x - Article selection 195 x3x - Distribution functions 196 x4x - Posting 197 x8x - Nonstandard (private implementation) extensions 198 x9x - Debugging output 200 The exact response codes that MUST be expected from each 201 command are detailed in the description of the keyword that is 202 the first part of the command. In addition, below is listed a 203 general set of response codes that MAY be received at any 204 time. 206 Certain status responses contain parameters such as numbers 207 and names. In those cases, the number and type of such 208 parameters MUST be fixed for each response code to simplify 209 interpretation of the response. In all other cases, the client 210 MUST only use the response code itself to determine the nature 211 of the response. 213 Parameters MUST be separated from the numeric response code 214 and from each other by a single US-ASCII space. All numeric 215 parameters MUST be in base 10 (decimal) format, and may have 216 leading zeros. All string parameters MUST begin after the 217 separating space, and MUST end before the following separating 218 space or the US-ASCII CRLF pair at the end of the line. 219 (Therefore, string parameters MUST NOT contain US-ASCII 220 spaces.) All text, if any, in the response which is not a 221 parameter of the response must follow and be separated from 222 the last parameter by an US-ASCII space. Also, note that the 223 text following a response number may vary in different 224 implementations of the server. The 3-digit numeric code should 225 be used to determine what response was sent. 227 Response codes not specified in this standard MAY be used for 228 any installation-specific additional commands also not 229 specified. These SHOULD be chosen to fit the pattern of x8x 230 specified above. (Note that debugging is provided for 231 explicitly in the x9x response codes.) 233 The use of unspecified response codes for a standard command 234 is prohibited. 236 The response pattern x9x is provided for debugging. Since 237 much debugging output may be classed as "informative 238 messages", it MUST be the case that responses 190 through 199 239 WILL be used for various debugging outputs. There is no 240 requirement in this specification for debugging output. 241 However, if such is provided over the connected stream, it 242 MUST use these response codes. If appropriate to a specific 243 implementation, other x9x codes MAY be used for debugging. 244 (For example, response code 290 could be used to acknowledge a 245 remote debugging request.) 247 A server MUST respond to an unrecognized, unimplemented, or 248 syntactically invalid command with a negative status indicator 249 (response codes of the form 5XX). A server MUST respond to a 250 command issued when the session is in an incorrect state by 251 responding with a negative status indicator. This may be from 252 either the 4XX or 5XX group as appropriate. 254 5. The WILDMAT format 256 The WILDMAT format[5] was first developed by Rich Salz based 257 on the format used in the UNIX "find" command to articulate 258 file names. It was developed to provide a uniform mechanism 259 for matching patterns in the same manner that the UNIX shell 260 matches filenames. Patterns are implicitly anchored at the 261 beginning and end of each string when testing for a match. 262 There are five pattern-matching operations other than a strict 263 one-to-one match between the pattern and the source to be 264 checked for a match. The first is an asterisk (*) to match any 265 sequence of zero or more UTF-8 characters. The second is a 266 question mark (?) to match any single UTF-8 character. The 267 third specifies a specific set of characters. The set is 268 specified as a list of characters, or as a range of characters 269 where the beginning and end of the range are separated by a 270 minus (or dash) character, or as any combination of lists and 271 ranges. The dash can also be included in the set as a 272 character it if is the beginning or end of the set. This set 273 is enclosed in square brackets. The close square bracket (]) 274 may be used in a set if it is the first character in the set. 275 The fourth operation is the same as the logical not of the 276 third operation and is specified the same way as the third 277 with the addition of a caret character (^) at the beginning of 278 the test string just inside the open square bracket. The final 279 operation uses the backslash character to invalidate the 280 special meaning of the open square bracket ([), the asterisk, 281 backslash or the question mark. Two backslashes in sequence 282 will result in the evaluation of the backslash as a character 283 with no special meaning. 285 5.1 Examples 287 a) [^]-] -- matches any single character other than a 288 close square bracket or a minus sign/dash. 289 b) *bdc -- matches any string that ends with the string 290 "bdc" including the string "bdc" (without quotes). 291 c) [0-9a-zA-Z] -- matches any single printable 292 alphanumeric ASCII character. 293 d) a??d -- matches any four character string which 294 begins with a and ends with d. 296 6. Format for Keyword Descriptions 297 On the following pages are descriptions of each keyword 298 recognized by the NNTP server and the responses that will be 299 returned by those commands. These keywords are grouped by the 300 functional step in which they are used. 302 Each keyword is shown in upper case for clarity, although the 303 NNTP server ignores case in the interpretation of commands. 304 Any parameters are shown in lower case. A parameter shown in 305 [square brackets] is optional. For example, [GMT] indicates 306 that the triglyph GMT may be present or omitted. A parameter 307 that may be repeated is followed by an ellipsis. Mutually 308 exclusive parameters are separated by a vertical bar (|) 309 character. For example, ggg| indicates that a 310 group name or a may be specified, but not both. 311 Some parameters may be case or language specific. See RFC 312 1036[6] for these details. 314 In addition, certain commands make use of a pattern for 315 selection of multiple news groups. The pattern in all cases is 316 based on the WILDMAT format introduced by Rich Salz in 1986. 317 Arguments expected to be in wildmat format will be represented 318 by the string wildmat. This format is discussed in detail in 319 section 5 of this memo. 321 7. The GREETING Step 323 7.1 Initial Connection 325 There is no keyword presented by the client upon initial 326 connection to the server. The server MUST present an 327 appropriate response code as a greeting to the client. This 328 response informs the client about what steps the client should 329 take to reach the news exchange step. 331 The server must present a 200 greeting code if the client is 332 authorized to post articles though the use of the POST keyword 333 on this server. 335 The server must present a 201 greeting code if the client is 336 not authorized to post articles using the POST keyword. 338 The server must present a 502 greeting code if the client is 339 not permitted under any circumstances from interacting with 340 the server. The server should immediately close the connection 341 with the client after presenting this code. 343 In all other cases, the server must present a 400 greeting 344 code. 346 7.1.1 MODE READER 348 MODE READER 350 MODE READER MAY be used by the client to indicate to the 351 server that it is a news reading client. This command may be 352 entered at any time. The server must present a greeting code 353 (as described in section 7.1.1.1) appropriate to the server's 354 ability to provide service to this client in this mode. 356 7.1.1.1 Responses 357 200 Hello, you can post 358 201 Hello, you can't post 359 400 Service temporarily unavailable 360 502 Service unavailable 362 8. The CAPABILITIES DISCOVERY Step 364 A client NNTP supporting NNTP service extensions should query 365 a server early in the session for extensions session by 366 issuing the LIST EXTENSIONS command. If the NNTP server 367 supports the NNTP service extensions it MUST give a successful 368 response (see section 8.1.1), a failure response (see section 369 8.1.2), or an error response (see section 8.1.3). If the NNTP 370 server does not support any NNTP service extensions, it MUST 371 generate an error response (see section 8.1.4). 373 8.1 LIST EXTENSIONS 375 If successful, the server NNTP MUST respond with code 202. On 376 failure, the server NNTP MUST respond with code 503. On error, 377 the server NNTP MUST respond with one of codes 400, 402, 500, 378 501 and 502. 380 This command MAY be issued at anytime during a session. It is 381 not required that the client issues this command before 382 attempting to make use of any extension. The response 383 generated by this command MAY change during a session because 384 of other state information (e.g. server administration). 385 However, a client NNTP MUST NOT cache (for use in another 386 session) any information returned if the LIST EXTENSIONS 387 command succeeds. That is, a client NNTP MUST issue the LIST 388 EXTENSIONS command at least once during each session to get 389 the current and correct information concerning available 390 extensions during that session. 392 8.1.1 Successful response 394 If the server NNTP implements and is able to perform the LIST 395 EXTENSIONS command, it MUST return code 202. 397 Text following the return code on the first line of the reply 398 is free form, and not interpreted, and has no practical use, 399 as this text is not expected to be revealed to end users. The 400 syntax of other reply lines is precisely defined, and if 401 present, MUST be exactly as specified. 403 Each line listing an extension in the extension-listing begins 404 with a single space. That space is not optional, nor does it 405 indicate general white space. This space guarantees that the 406 line can never be misinterpreted as the end of the extension- 407 listing, but is required even where there is no possibility of 408 ambiguity. 410 Each extension supported must be listed on a separate line to 411 facilitate the possible inclusion of parameters supported by 412 each extension command. The extension-label to be used in the 413 response to the LIST EXTENSIONS command will be specified as 414 each new extension is added to the NNTP command set. Often it 415 will be the name of a new command added; however this is not 416 required. In fact it is not required that a new feature 417 actually add a new command. Any parameters included are to be 418 specified with the definition of the command concerned. 420 That specification shall also specify how any parameters 421 present are to be interpreted. 423 The extension-label is nominally case sensitive, however the 424 definitions of specific labels and parameters specify the 425 precise interpretation, and it is to be expected that those 426 definitions will usually specify the label in a case 427 independent manner. Where this is done, implementations are 428 recommended to use upper case letters when transmitting the 429 extension response. 431 The LIST EXTENISONS command itself is not included in the list 432 of features supported, support for the LIST EXTENSIONS command 433 is indicated by return of a reply other than a 500 or 502 434 reply. 436 The end of the list is defined by the usual period on a line 437 by itself. 439 A typical example reply to the LIST EXTENSIONS command might 440 be a multiline reply of the form: 442 [C] LIST EXTENSIONS 444 [S] 202-Extensions supported: 446 [S] OVER 448 [S] PAT 450 [S] LISTGROUP 452 [S] . 454 The particular extensions shown here are simply examples of 455 what may be defined in other places, no particular meaning 456 should be attributed to them. Recall also, that the extension 457 names returned are not command names, as such, but simply 458 indications that the server possesses some attribute or other. 460 The order in which the extensions are returned is of no 461 importance, NNTP Servers processes are not required to 462 implement any particular order, or even to consistently return 463 the same order when the command is repeated. 465 8.1.2 Failure response 467 If for some reason the server NNTP is unable to list the 468 service extensions it supports, it MUST return code 503. 470 In the case of a failure response, the client NNTP may try the 471 extensions either as the need arises or configure itself for 472 the basic NNTP functionality defined in this document. 474 8.1.3 Error responses from extended servers 476 If the server NNTP recognizes the LIST EXTENSIONS command, but 477 due to various conditions cannot make any extensions available 478 to the client at the time the client issued the LIST 479 EXTENSIONS command, it MUST return code 402. No list (not even 480 an empty one) will be returned. 482 The client NNTP should configure itself for the basic NNTP 483 functionality defined in this document, or issue commands that 484 might change the state of the server, or issue the QUIT 485 command (see section 10.1) if a particular extension is 486 required for the client to properly operate. 488 If the server NNTP determines that the NNTP service is no 489 longer available (e.g., due to imminent system shutdown), it 490 must return code 400. Note that this is response code should 491 not be generated due to an inactivity timeout as described in 492 section 4. 494 In the case of an error response, the client NNTP should issue 495 the QUIT command (see section 10.1). 497 8.1.4 Responses from servers without extensions 499 A server NNTP that conforms to this memo but does not support 500 the extensions specified here will not recognize the LIST 501 EXTENSIONS command and MUST consequently return code 500 or 502 code 501. The server NNTP SHALL stay in the same state after 503 returning this code. The client NNTP may try the extensions 504 either as the need arises or configure itself for the basic 505 NNTP functionality defined in this document. 507 8.1.5 Responses from improperly implemented servers 509 A server NNTP that improperly implements the LIST EXTENSIONS 510 command may return an empty list. Clients SHALL accommodate 511 this protocol violation and interpret it as a response code 512 402. 514 9. The NEWS EXCHANGE Step 516 During this step, two basic types of transactions occur: 518 article retrieval from the server and article posting to the 519 server. 521 9.1 Article Retrieval 523 News reading clients have available a variety of mechanisms to 524 retrieve articles via NNTP. The news articles are stored and 525 indexed using three types of keys. One key is the message id 526 of an article. According to RFC 1036, this identifier should 527 be globally unique. Another key is composed of the news group 528 name and the article number within that news group. That key 529 MUST be unique to a particular server (there will be only one 530 article with that number within a particular news group), but 531 is not required to be globally unique. Additionally, because 532 the same article can be cross-posted to multiple news groups, 533 there may be multiple keys that point to the same article on 534 the same server. The final key is the arrival timestamp, 535 giving the time that the article arrived at the server. 537 The server MUST ensure that article numbers are issued in 538 order of arrival timestamp; that is, articles arriving later 539 MUST have higher numbers than those that arrive earlier. The 540 server SHOULD allocate the next sequential unused number to 541 each new article. 543 Article numbers MUST lie between 1 and 4,294,967,295 544 inclusive. The client and server SHOULD NOT use leading zeroes 545 in specifying article numbers, and MUST NOT use more than 16 546 digits. In some situations, the value zero replaces an article 547 number to show some special situation. One case involves 548 responses to the ARTICLE, STAT, BODY and HEAD commands where a 549 is specified as the argument. In those cases, the 550 "current article pointer" is not changed. 552 9.1.1 Article Retrieval by News Group Name and Article Number 554 The following commands are used to set the current news group 555 name and the "current article pointer" which is used by other 556 commands for article retrieval. 558 9.1.1.1 GROUP 560 GROUP ggg 562 The required parameter ggg is the name of the news group to be 563 selected (e.g. "news.software.b"). A list of valid news groups 564 may be obtained by using the LIST keyword. See section 9.4 565 for more information on the LIST keyword. 567 The successful selection response will return the article 568 numbers of the first and last articles in the group at the 569 moment of selection (these numbers are referred to as the 570 "reported low water mark" and the "reported high water mark"), 571 and an estimate of the number of articles on file in the 572 group. 574 If the group is not empty, the estimate MUST be at least the 575 actual number of articles available, and MUST be no greater 576 than one more than the difference between the reported low and 577 high water marks. (Some implementations will actually count 578 the number of articles on file. Others will just subtract the 579 low water mark from the high water mark and add one to get an 580 estimate.) 582 If the group is empty, one of the following three situations 583 will occur. Clients MUST accept all three cases; servers MUST 584 NOT represent an empty group in any other way. 586 . The high water mark will be one less than the low water mark, 587 and the estimated article count will be zero. Servers SHOULD 588 use this method to show an empty group. This is the only time 589 that the high water mark can be less than the low water mark. 590 . All three numbers will be zero. 591 . The high water mark is greater than or equal to the low water 592 mark; the estimated article count might be zero or non-zero; 593 if non-zero, the same requirements apply as for a non-empty 594 group. 596 The set of articles in a group may change after the GROUP 597 command is carried out. That is: 599 . articles may be removed from the group; 600 . articles may be reinstated in the group with the same article 601 number, but those articles MUST have numbers no less than the 602 reported low water mark (note that this is a reinstatement of 603 the previous article, not a new article reusing the number); 604 . new articles may be added with article numbers greater than 605 the reported high water mark (if an article that was the one 606 with the highest number has been removed, the next new article 607 will not have the number one greater than the reported high 608 water mark). 609 Except when the group is empty and all three numbers are zero, 610 whenever a subsequent GROUP command for the same news group is 611 issued, either by the same client or a different client, the 612 reported low water mark in the response MUST be no less than 613 that in any previous response for that news group sent to any 614 client. The client may make use of the low water mark to 615 remove all remembered information about articles with lower 616 numbers, as these will never recur. This includes the 617 situation when the high water mark is one less than the low 618 water mark. 620 No similar assumption can be made about the high water mark, 621 as this can decrease if an article is removed, and then 622 increase again if it is reinstated or if new articles arrive. 624 When a valid group is selected by means of this command, the 625 internally maintained "current article pointer" MUST be set to 626 the first article in the group and the name of the current 627 news group MUST be set to the selected news group name. If an 628 invalid group is specified, the previously selected group and 629 article MUST remain selected. If an empty news group is 630 selected, the "current article pointer" is in an indeterminate 631 state and MUST NOT be used. 633 The GROUP keyword MUST be used by a client and a successful 634 response received before the any other command is used that 635 depends on having the "current article pointer" be valid. 637 9.1.1.1.1 Responses 639 211 n f l s group selected 640 (n = estimated number of articles in group, f = first 641 article number in the group, l = last article number in 642 the group, s = name of the group.) 643 411 no such news group 645 9.1.1.2 LAST 647 LAST 649 The internally maintained "current article pointer" MUST be 650 set to the previous article in the current news group. If 651 already positioned at the first article of the news group, an 652 error message MUST be returned and the current article MUST 653 remain selected. 655 There MAY be no previous article in the group, although the 656 current article number is not the reported low water mark. 657 There MUST NOT be a previous article when the current article 658 number is the reported low water mark. 660 Because articles can be removed and added, the results of 661 multiple LAST and NEXT commands MAY not be consistent over the 662 life of a particular NNTP session. 664 The internally-maintained "current article pointer" MUST be 665 set by this command. 667 A response indicating the current article number and a 668 message-id string MUST be returned. No text is sent in 669 response to this command. 671 9.1.1.2.1 Responses 673 223 n a article retrieved - request text separately (n = 674 article number, a = unique article id) 675 412 no news group selected 676 420 no current article has been selected 677 422 no previous article in this group 679 9.1.1.3 NEXT 681 NEXT 683 The internally maintained "current article pointer" MUST be 684 advanced to the next article in the current news group. If no 685 more articles remain in the current group, an error message 686 MUST be returned and the current article MUST remain selected. 688 The internally-maintained "current article pointer" MUST be 689 set by this command. 691 A response indicating the current article number and the 692 message-id string MUST be returned. No text is sent in 693 response to this command. 695 9.1.1.3.1 Responses 697 223 n a article retrieved - request text separately (n = 698 article number, a = unique article id) 699 412 no news group selected 700 420 no current article has been selected 701 421 no next article in this group 703 9.2 Retrieval of Articles and Article Sections 705 There are two forms to the ARTICLE command (and the related 706 BODY, HEAD, and STAT commands), each using a different method 707 of specifying which article is to be retrieved. When the 708 ARTICLE keyword is followed by a message-id in angle brackets 709 ("<" and ">"), the first form of the command MUST be used; 710 when a numeric parameter or no parameter is supplied, the 711 second form MUST be invoked. In the cases where the argument 712 is a message-id, the article number specified in the response 713 must be zero. This is one of the special cases described in 714 section 9.1. 716 An article, as defined by RFC 1036, consists of two parts: the 717 article headers and the article body. When responding to an 718 article command, the server returns the entire article 719 contents and does not attempt to alter or translate them in 720 any way. 722 9.2.1 ARTICLE 724 ARTICLE [|nnn] 726 This response displays the header, a blank line, then the body 727 (text) of the specified article. The optional parameter nnn is 728 the numeric id of an article in the current news group and 729 SHOULD be chosen from the range of articles provided when the 730 news group was selected. If it is omitted, the current 731 article is assumed. Message-id is the message id of an article 732 as shown in that article's header. 734 Please note that the internally-maintained "current article 735 pointer" MUST NOT be altered when the message-id argument is 736 used. This is both to facilitate the presentation of articles 737 that may be referenced within an article being read, and 738 because of the semantic difficulties of determining the proper 739 sequence and membership of an article which may have been 740 posted to more than one news group. 742 The internally-maintained "current article pointer" MUST be 743 set when a valid article number is specified as the argument. 744 This includes the case when an article number is implied by 745 the use of no argument. 747 A previously valid article number MAY not remain valid if the 748 article has been removed. A previously invalid article number 749 MAY become valid if the article has been reinstated, but such 750 an article number MUST be no less than the reported low water 751 mark for that group. 753 If there is a valid article to present in a reply to this 754 command, a response indicating the current article number (or 755 zero when the message-id argument is used), a message-id 756 string, and that text is to follow MUST be returned. 758 The message-id string returned is an identification string 759 contained within angle brackets ("<" and ">"), which is 760 derived from the header of the article itself. The Message-ID 761 header line (required by RFC 1036) from the article must be 762 used to supply this information. If the message-id header line 763 is missing from the article, a single digit "0" (zero) should 764 be supplied within the angle brackets. 766 Since the message-id field is unique for each article, it may 767 be used by a news reading program to skip duplicate displays 768 of articles that have been posted more than once, or to more 769 than one news group. 771 9.2.1.1 Responses 772 220 n article retrieved - head and body follow (n = 773 article number, = message-id) 774 412 no news group has been selected 775 420 no current article has been selected 776 423 no such article number in this group 777 430 no such article found 779 9.2.2 HEAD 780 HEAD [|nnn] 782 This response displays the header of the specified article. 783 The optional parameter nnn is the numeric id of an article in 784 the current news group and SHOULD be chosen from the range of 785 articles provided when the news group was selected. If it is 786 omitted, the current article is assumed. Message-id is the 787 message id of an article as shown in that article's header. 789 Please note that the internally-maintained "current article 790 pointer" MUST NOT be altered when the message-id argument is 791 used. This is both to facilitate the presentation of articles 792 that may be referenced within an article being read, and 793 because of the semantic difficulties of determining the proper 794 sequence and membership of an article which may have been 795 posted to more than one news group. 797 The internally-maintained "current article pointer" MUST be 798 set when a valid article number is specified as the argument. 799 This includes the case when an article number is implied by 800 the use of no argument. 802 A previously valid article number MAY not remain valid if the 803 article has been removed. A previously invalid article number 804 MAY become valid if the article has been reinstated, but such 805 an article number MUST be no less than the reported low water 806 mark for that group. 808 If there is a valid article to present in a reply to this 809 command, a response indicating the current article number (or 810 zero when the message-id argument is used), a message-id 811 string, and that text is to follow MUST be returned. 813 The message-id string returned is an identification string 814 contained within angle brackets ("<" and ">"), which is 815 derived from the header of the article itself. The Message-ID 816 header line (required by RFC 1036) from the article must be 817 used to supply this information. If the message-id header line 818 is missing from the article, a single digit "0" (zero) should 819 be supplied within the angle brackets. 821 Since the message-id field is unique for each article, it may 822 be used by a news reading program to skip duplicate displays 823 of articles that have been posted more than once, or to more 824 than one news group. 826 9.2.2.1 Responses 827 221 n article retrieved - head follows 828 412 no news group has been selected 829 420 no current article has been selected 830 423 no such article number in this group 831 430 no such article found 833 9.2.3 BODY 834 BODY [|nnn] 836 This response displays the body (text) of the specified 837 article. The optional parameter nnn is the numeric id of an 838 article in the current news group and SHOULD be chosen from 839 the range of articles provided when the news group was 840 selected. If it is omitted, the current article is assumed. 841 Message-id is the message id of an article as shown in that 842 article's header. 844 Please note that the internally-maintained "current article 845 pointer" MUST NOT be altered when the message-id argument is 846 used. This is both to facilitate the presentation of articles 847 that may be referenced within an article being read, and 848 because of the semantic difficulties of determining the proper 849 sequence and membership of an article which may have been 850 posted to more than one news group. 852 The internally-maintained "current article pointer" MUST be 853 set when a valid article number is specified as the argument. 854 This includes the case when an article number is implied by 855 the use of no argument. 857 A previously valid article number MAY not remain valid if the 858 article has been removed. A previously invalid article number 859 MAY become valid if the article has been reinstated, but such 860 an article number MUST be no less than the reported low water 861 mark for that group. 863 If there is a valid article to present in a reply to this 864 command, a response indicating the current article number (or 865 zero when the message-id argument is used), a message-id 866 string, and that text is to follow MUST be returned. 868 The message-id string returned is an identification string 869 contained within angle brackets ("<" and ">"), which is 870 derived from the header of the article itself. The Message-ID 871 header line (required by RFC 1036) from the article must be 872 used to supply this information. If the message-id header line 873 is missing from the article, a single digit "0" (zero) should 874 be supplied within the angle brackets. 876 Since the message-id field is unique for each article, it may 877 be used by a news reading program to skip duplicate displays 878 of articles that have been posted more than once, or to more 879 than one news group. 881 9.2.3.1 Responses 882 222 n article retrieved - body follows 883 412 no news group has been selected 884 420 no current article has been selected 885 423 no such article number in this group 886 430 no such article found 888 9.2.4 STAT 889 STAT [|nnn] 891 This response returns only status information; no article 892 contents are returned. The optional parameter nnn is the 893 numeric id of an article in the current news group and SHOULD 894 be chosen from the range of articles provided when the news 895 group was selected. If it is omitted, the current article is 896 assumed. Message-id is the message id of an article as shown 897 in that article's header. 899 Please note that the internally-maintained "current article 900 pointer" MUST NOT be altered when the message-id argument is 901 used. This is both to facilitate the presentation of articles 902 that may be referenced within an article being read, and 903 because of the semantic difficulties of determining the proper 904 sequence and membership of an article which may have been 905 posted to more than one news group. 907 The internally-maintained "current article pointer" MUST be 908 set when a valid article number is specified as the argument. 909 This includes the case when an article number is implied by 910 the use of no argument. 912 A previously valid article number MAY not remain valid if the 913 article has been removed. A previously invalid article number 914 MAY become valid if the article has been reinstated, but such 915 an article number MUST be no less than the reported low water 916 mark for that group. 918 If there is a valid article to present in a reply to this 919 command, a response indicating the current article number (or 920 zero when the message-id argument is used) and a message-id 921 string MUST be returned. 923 The message-id string returned is an identification string 924 contained within angle brackets ("<" and ">"), which is 925 derived from the header of the article itself. The Message-ID 926 header line (required by RFC 1036) from the article must be 927 used to supply this information. If the message-id header line 928 is missing from the article, a single digit "0" (zero) should 929 be supplied within the angle brackets. 931 Since the message-id field is unique for each article, it may 932 be used by a news reading program to skip duplicate displays 933 of articles that have been posted more than once, or to more 934 than one news group. 936 9.2.4.1 Responses 937 223 n article retrieved - request text separately 938 412 no news group has been selected 939 420 no current article has been selected 940 423 no such article number in this group 941 430 no such article found 943 9.3 Article Posting 945 Article posting is done in one of two modes: individual 946 article posting from news reading clients and article transfer 947 from other news servers. 949 9.3.1 POST 951 POST 953 If posting is allowed, response code 340 MUST be returned to 954 indicate that the article to be posted should be sent. 955 Response code 440 MUST be sent if that posting is prohibited 956 for some installation-dependent reason. 958 If posting is permitted, the article MUST be presented to the 959 server by the client in the format specified by RFC 1036. The 960 text forming the header and body of the message to be posted 961 MUST be sent by the client using the conventions for text 962 received from the news server: A single period (".") on a line 963 indicates the end of the text, with lines starting with a 964 period in the original text having that period doubled during 965 transmission. 967 Following the presentation of the termination sequence by the 968 client, the server MUST return a response code indicating 969 success or failure of the article transfer. 971 No attempt shall be made by the server to filter characters, 972 fold or limit lines, or otherwise process incoming text. The 973 intent is that the server just passes the incoming message to 974 be posted to the server installation's news posting software, 975 which is not part of this specification. 977 9.3.1.1 Responses 979 240 article received ok 980 340 send article to be posted. End with . 981 440 posting not allowed 982 441 posting failed 984 9.3.2 IHAVE 986 IHAVE 988 The IHAVE command informs the server that the client has an 989 article whose id is . If the server desires a copy 990 of that article, it MUST return a response instructing the 991 client to send the entire article. If the server does not want 992 the article (if, for example, the server already has a copy of 993 it), a response indicating that the article is not wanted MUST 994 be returned. 996 If transmission of the article is requested, the client MUST 997 send the entire article, including header and body, in the 998 manner specified for text transmission from the server. The 999 server MUST return a response code indicating success or 1000 failure of the transferal of the article. 1002 This function differs from the POST command in that it is 1003 intended for use in transferring already-posted articles 1004 between hosts. Normally it will not be used when the client is 1005 a personal news reading program. In particular, this function 1006 will invoke the server's news posting program with the 1007 appropriate settings (flags, options, etc.) to indicate that 1008 the forthcoming article is being forwarded from another host. 1010 However, the server may elect not to post or forward the 1011 article if after further examination of the article it deems 1012 it inappropriate to do so. Reasons for such subsequent 1013 rejection of an article may include such problems as 1014 inappropriate news groups or distributions, disk space 1015 limitations, article lengths, garbled headers, and the like. 1016 These are typically restrictions enforced by the server host's 1017 news software and not necessarily the NNTP server itself. 1019 9.3.2.1 Responses 1021 235 article transferred ok 1022 335 send article to be transferred. End with . 1024 435 article not wanted - do not send it 1025 436 transfer failed - try again later 1026 437 article rejected - do not try again 1028 Because some host news posting software may not be able to 1029 immediately render status on the whether an article is 1030 inappropriate for posting or forwarding, an NNTP server MAY 1031 acknowledge the successful transfer of the article and later 1032 silently discard it. Thus an NNTP server may return the 235 1033 acknowledgment code and later discard the received article. 1035 9.4 The LIST Keyword 1037 9.4.1 LIST 1039 LIST [ACTIVE [wildmat]] 1041 The response to the LIST keyword with no parameters returns a 1042 list of valid news groups and associated information. Each 1043 news group is sent as a line of text in the following format: 1045 group last first status 1047 where is the name of the news group, is the 1048 number of the last known article currently in that news group, 1049 is the number of the first article currently in the 1050 news group, and indicates the current status of the 1051 group on this server. Typically, the will be consist 1052 of the US-ASCII character `y' where posting is permitted, `n' 1053 where posting is not permitted and `m' where postings will be 1054 forwarded to the news group moderator by the news server. 1055 Other status strings may exist. The definition of these other 1056 values are covered in other specifications. 1058 The and fields will always be numeric. They 1059 may have leading zeros. If the field evaluates to less 1060 than the field, there are no articles currently on 1061 file in the news group. 1063 Note that posting may still be prohibited to a client although 1064 the LIST command indicates that posting is permitted to a 1065 particular news group. See the POST command for an explanation 1066 of client prohibitions. The posting flag exists for each news 1067 group because some news groups are moderated or are digests, 1068 and therefore cannot be posted to; that is, articles posted to 1069 them must be mailed to a moderator who will post them for the 1070 original poster. This is independent of the posting 1071 permission granted to a client by the NNTP server. 1073 Please note that an empty list (i.e., the text body returned 1074 by this command consists only of the terminating period) is a 1075 possible valid response, and indicates that there are 1076 currently no valid news groups. 1078 If the optional matching parameter is specified, the list is 1079 limited to only the groups that match the pattern. 1081 Specifying a single group is usually very efficient for the 1082 server, and multiple groups may be specified by using wildmat 1083 patterns (described in section 5), not regular expressions. 1085 9.4.1.1 Responses 1086 215 list of news groups follows 1088 9.4.2 LIST ACTIVE.TIMES 1090 LIST ACTIVE.TIMES [wildmat] 1092 The active.times file is maintained by some news transport 1093 systems to contain information about when and who created a 1094 particular news group. The format of this file generally 1095 includes three fields. The first field is the name of the news 1096 group. The second is the time when this group was created on 1097 this news server measured in seconds since January 1, 1970. 1098 The third is the email address of the entity that created the 1099 news group. When executed, the information is displayed 1100 following the 215 response. When display is completed, the 1101 server will send a period on a line by itself. If the 1102 information is not available, the server will return the 503 1103 error response. 1105 If the optional matching parameter is specified, the list is 1106 limited to only the groups that match the pattern. 1108 Specifying a single group is usually very efficient for the 1109 server, and multiple groups may be specified by using wildmat 1110 patterns (described in section 5), not regular expression 1112 9.4.2.1 Responses 1114 215 information follows 1115 503 program error, function not performed 1117 9.4.3 LIST DISTRIBUTIONS 1119 LIST DISTRIBUTIONS 1121 The distributions file is maintained by some news transport 1122 systems to contain information about valid values for the 1123 Distribution: line in a news article header and about what the 1124 values mean. Each line contains two fields, the value and a 1125 short explanation on the meaning of the value. When executed, 1126 the information is displayed following the 215 response. When 1127 display is completed, the server will send a period on a line 1128 by itself. If the information is not available, the server 1129 will return the 503 error response. 1131 9.4.3.1 Responses 1133 215 information follows 1134 503 program error, function not performed 1136 9.4.4 LIST DISTRIB.PATS 1138 LIST DISTRIB.PATS 1140 The distrib.pats file is maintained by some news transport 1141 systems to contain default values for the Distribution: line 1142 in a news article header when posting to particular news 1143 groups. This information could be used to provide a default 1144 value for the Distribution: line in the header when posting an 1145 article. The information returned contains three fields 1146 separated by colons. The first column is a weight. The second 1147 is a group name or a wildmat pattern that can be used to match 1148 a group name. The third is the value of the Distribution: 1149 line that should be used when the group name matches and the 1150 weight value is the highest. All this processing is done by 1151 the news posting client and not by the server itself. The 1152 server provides this information to the client for it to use 1153 or ignore as it chooses. When executed, the information is 1154 displayed following the 215 response. When display is 1155 completed, the server will send a period on a line by itself. 1156 If the information is not available, the server will return 1157 the 503 error response. 1159 9.4.4.1 Responses 1161 215 information follows 1162 503 program error, function not performed 1164 9.4.5 LIST NEWSGROUPS 1166 LIST NEWSGROUPS [wildmat] 1168 The newsgroups file is maintained by some news transport 1169 systems to contain the name of each news group that is 1170 active on the server and a short description about the 1171 purpose of each news group. Each line in the file contains 1172 two fields, the news group name and a short explanation of 1173 the purpose of that news group. When executed, the 1174 information is displayed following the 215 response. When 1175 display is completed, the server will send a period on a 1176 line by itself. If the information is not available, the 1177 server will return the 503 response. If the optional 1178 matching parameter is specified, the list is limited to only 1179 the groups that match the pattern (no matching is done on 1180 the group descriptions). Specifying a single group is 1181 usually very efficient for the server, and multiple groups 1182 may be specified by using wildmat patterns (see section 5), 1183 not regular expressions. If nothing is matched an empty list 1184 is returned, not an error. 1186 9.4.5.1 Responses 1188 215 information follows 1189 503 program error, function not performed 1191 9.4.6 LIST OVERVIEW.FMT 1193 LIST OVERVIEW.FMT 1195 The overview.fmt file is maintained by some news transport 1196 systems to contain the order in which header information is 1197 stored in the overview databases for each news group. When 1198 executed, news article header fields are displayed one line at 1199 a time in the order in which they are stored in the overview 1200 database[7] following the 215 response. When display is 1201 completed, the server will send a period on a line by itself. 1202 If the information is not available, the server will return 1203 the 503 response. 1205 Please note that if the header has the word "full" (without 1206 quotes) after the colon, the header's name is prepended to its 1207 field in the output returned by the server. 1209 9.4.6.1 Responses 1211 215 information follows 1212 503 program error, function not performed 1214 9.4.7 LIST SUBSCRIPTIONS 1216 LIST SUBSCRIPTIONS 1218 This command is used to get a default subscription list for 1219 new users of this server. The order of groups is significant. 1221 When this list is available, it is preceded by the 215 1222 response and followed by a period on a line by itself. When 1223 this list is not available, the server returns a 503 response 1224 code. 1226 9.4.7.1 Responses 1228 215 information follows 1229 503 program error, function not performed 1231 9.4.8 LISTGROUP 1233 LISTGROUP [ggg] 1235 The LISTGROUP command is used to get a listing of all the 1236 article numbers in a particular news group. 1238 The optional parameter ggg is the name of the news group to 1239 be selected (e.g. "news.software.b"). A list of valid news 1240 groups may be obtained from the LIST command. If no group is 1241 specified, the current group is used as the default 1242 argument. 1244 The successful selection response will be a list of the 1245 article numbers in the group followed by a period on a line 1246 by itself. 1248 When a valid group is selected by means of this command, the 1249 internally maintained "current article pointer" MUST be set 1250 to the first article in the group. If an invalid group is 1251 specified, the previously selected group and article remain 1252 selected. If an empty news group is selected, the "current 1253 article pointer" may be in an indeterminate state and should 1254 not be used. 1256 The group name MUST match a news group obtained from the 1257 LIST command or an error will result, else the server will 1258 response with the 411 error code. 1260 9.4.8.1 Responses 1262 211 list of article numbers follow 1263 411 No such group 1264 412 Not currently in news group 1266 9.4.9 OVER 1268 OVER [range] 1270 The OVER command returns information from the overview 1271 database for the article(s) specified. The information 1272 returned in the response to this command can be used by 1273 clients to follow discussion threads. 1275 The optional range argument may be any of the following: 1277 . an article number 1278 . an article number followed by a dash to indicate all following 1279 . an article number followed by a dash followed by another 1280 article number 1281 If no argument is specified, then information from the current 1282 article is displayed. Successful responses start with a 224 1283 response followed by the overview information for all matched 1284 messages. Once the output is complete, a period is sent on a 1285 line by itself. If no argument is specified, the information 1286 for the current article is returned. A news group must have 1287 been selected earlier, else a 412 error response is returned. 1288 If no articles are in the range specified, the server returns 1289 a 420 error response. A 502 response will be returned if the 1290 client only has permission to transfer articles. 1292 Each line of output MUST be formatted with the article number, 1293 followed by each of the headers in the overview database or 1294 the article itself (when the data is not available in the 1295 overview database) for that article separated by a US-ASCII 1296 tab character. The sequence of fields must be in this order: 1297 subject, author, date, message-id, references, byte count, and 1298 line count. Other optional fields may follow line count. These 1299 fields are specified by examining the response to the LIST 1300 OVERVIEW.FMT command. Where no data exists, a null field must 1301 be provided (i.e. the output will have two tab characters 1302 adjacent to each other). Servers should not output fields for 1303 articles that have been removed since the overview database 1304 was created. 1306 Note that all US-ASCII tab characters in any header data that 1307 is returned will be converted to a single US-ASCII space 1308 character. A contiguous sequence of US-ASCII non-printing 1309 characters will be compressed to a single US-ASCII space 1310 character in any output response. 1312 9.4.9.1 Responses 1314 224 Overview information follows 1315 412 No news group current selected 1316 420 No article(s) selected 1317 502 no permission 1319 9.4.10 PAT 1321 PAT header range| [pat [pat...]] 1323 The PAT command is used to retrieve specific headers from 1324 specific articles, based on pattern matching on the contents 1325 of the header. 1327 The required header parameter is the name of a header line 1328 (e.g. "subject") in a news group article. See RFC-1036 for a 1329 list of valid header lines. The required range argument may be 1330 any of the following: 1332 . an article number 1333 . an article number followed by a dash to indicate all following 1334 . an article number followed by a dash followed by another 1335 article number. 1336 The required message-id argument indicates a specific article. 1337 The range and message-id arguments are mutually exclusive. If 1338 there are additional arguments, they are joined together 1339 separated by a single space to form one complete pattern. If 1340 there are no additional arguments, a wildmat "*" is the 1341 default. Successful responses start with a 221 response 1342 followed by article number, an US-ASCII space, and the header 1343 from that message in which the pattern matched the contents of 1344 the specified header line. A valid response includes an empty 1345 list (indicating that there was no matches). Once the output 1346 is complete, a period is sent on a line by itself. If the 1347 optional argument is a message-id and no such article exists, 1348 the 430 error response shall be returned. A 502 response shall 1349 be returned if the client only has permission to transfer 1350 articles. 1352 9.4.10.1 Responses 1354 221 Header follows 1355 430 no such article 1356 502 no permission 1358 10. The CONCLUSION Step 1360 10.1 QUIT 1362 QUIT 1364 The server process MUST acknowledge the QUIT command and then 1365 closes the connection to the client. This is the preferred 1366 method for a client to indicate that it has finished all its 1367 transactions with the NNTP server. 1369 If a client simply disconnects (or the connection times out or 1370 some other fault occurs), the server SHALL gracefully cease 1371 its attempts to service the client. 1373 10.1.1 Responses 1375 205 closing connection - goodbye! 1377 11. Other Keywords 1379 There are other Keywords that may be used at any time between 1380 the beginning of a session and its termination. Using these 1381 keywords do not alter any state information, but the response 1382 generated from the use of these keywords may provide useful 1383 information to clients that use them. 1385 11.1 DATE 1387 DATE 1389 This command exists to help clients find out the current time 1390 from the server's perspective. This command should not be 1391 used as a substitute for NTP[8], but to provide information 1392 that might be useful when using the NEWNEWS command (see 1393 section 11.4). 1395 This command returns a one-line response code of 111 followed 1396 by the UTC (or GMT) date and time on the server in the form 1397 YYYYMMDDhhmmss. 1399 11.1.1 Responses 1401 111 YYYYMMDDhhmmss 1403 11.2 The HELP Command 1405 HELP 1407 This command provides a short summary of commands that are 1408 understood by this implementation of the server. The help text 1409 will be presented as a textual response terminated by a single 1410 period on a line by itself. 1412 This text is not guaranteed to be in any particular format and 1413 shall not be used by clients as a replacement for the LIST 1414 EXTENSIONS command described in section 8.1. 1416 11.2.1 Responses 1418 100 help text follows 1420 11.3 NEWGROUPS 1422 NEWGROUPS date time [GMT|UTC] [] 1424 A list of newsgroups created since MUST be 1425 listed in the same format as the LIST command. 1427 The date is sent as 6 or 8 digits in the format [XX]YYMMDD, 1428 where XX is the first two digits of the year, YY is the last 1429 two digits of the year, MM is the two digits of the month 1430 (with leading zero, if appropriate), and DD is the day of the 1431 month (with leading zero, if appropriate). If the first two 1432 digits of the year are not specified, the year is to be taken 1433 from the current century if YY is smaller than or equal to the 1434 current year, otherwise the year is from the previous century. 1436 Time must also be specified. It must be as 6 digits HHMMSS 1437 with HH being hours in the 24-hour clock 00-23, MM minutes 00- 1438 59, and SS seconds 00-60, which allows for leap seconds. The 1439 tokens "GMT" and "UTC" specifies that the date and time are 1440 given in UTC. If the tokens "GMT" and "UTC" are omitted then 1441 the date and time are specified in the server's local 1442 timezone. Note that there is no way within this specification 1443 of NNTP to establish the server's local timezone. 1445 The optional parameter "distributions" is a list of 1446 distribution groups, enclosed in angle brackets. If 1447 specified, the distribution portion of an article's header 1448 will be examined for a match with the distribution categories 1449 listed, and only those articles which have a distribution in 1450 the list will be listed. If more than one distribution is to 1451 be supplied, they must be separated by commas within the angle 1452 brackets. 1454 Note that an empty list (i.e., the text body returned by this 1455 command consists only of the terminating period) is a possible 1456 valid response, and indicates that there are currently no new 1457 newsgroups. 1459 Clients SHOULD make all queries using GMT/UTC time when 1460 possible. 1462 11.3.1 Responses 1464 231 list of new newsgroups follows 1466 11.4 NEWNEWS 1468 NEWNEWS newsgroups date time [GMT] [] 1470 A list of message-ids of articles posted or received to the 1471 specified news group since "date" will be listed. The format 1472 of the listing will be one message-id per line, as though text 1473 were being sent. A single line consisting solely of one 1474 period followed by CR-LF will terminate the list. 1476 Date and time are in the same format as the NEWGROUPS command. 1477 The newsgroups parameter must be in wildmat format and may 1478 consist of multiple wildmat constructs separated by an US- 1479 ASCII comma character. 1481 The optional parameter "distributions" is a list of 1482 distribution groups, enclosed in angle brackets. If 1483 specified, the distribution portion of an article's header 1484 will be examined for a match with the distribution categories 1485 listed, and only those articles which have a distribution in 1486 the list will be listed. If more than one distribution is to 1487 be supplied, they must be separated by commas within the angle 1488 brackets. 1490 Note that an empty list (i.e., the text body returned by this 1491 command consists only of the terminating period) is a possible 1492 valid response, and indicates that there is currently no new 1493 news. 1495 Clients SHOULD make all queries in GMT/UTC time when possible. 1497 11.4.1 Responses 1499 230 list of new articles by message-id follows 1501 12. Framework for NNTP Extensions 1503 Although NNTP is widely and robustly deployed, some parts of 1504 the Internet community might wish to extend the NNTP service. 1505 This memo defines a means whereby an extended NNTP client may 1506 query the server to determine the service extensions that it 1507 supports. 1509 It must be emphasized that any extension to the NNTP service 1510 should not be considered lightly. NNTP's strength comes 1511 primarily from its simplicity. Experience with many protocols 1512 has shown that: 1514 Protocols with few options tend towards ubiquity, whilst 1515 protocols with many options tend towards obscurity. 1517 This means that each and every extension, regardless of its 1518 benefits, must be carefully scrutinized with respect to its 1519 implementation, deployment, and interoperability costs. In 1520 many cases, the cost of extending the NNTP service will likely 1521 outweigh the benefit. 1523 Given this environment, the framework for the extensions 1524 described in this memo consists of: 1526 a) a mechanism for clients to determine a server's available 1527 extensions 1528 b) a registry of NNTP service extensions 1530 The LIST EXTENSIONS command is described in section 8.1 of 1531 this memo and is the mechanism for clients to use to determine 1532 what extensions are available for client use. 1534 The IANA shall maintain a registry of NNTP service extensions. 1536 Associated with each such extension is a corresponding NNTP 1537 keyword value. Each service extension registered with the IANA 1538 MUST be defined in an RFC. Such RFCs either must be on the 1539 standards-track or must define an IESG-approved experimental 1540 protocol. The definition must include: 1542 . the textual name of the NNTP service extension; 1543 . the label that is returned by LIST EXTENSIONS that would 1544 indicate to the client that the server supports this 1545 particular extension. 1546 . any new NNTP keywords associated with the extension; 1547 . the syntax and possible values of parameters associated with 1548 the new NNTP keywords; 1549 . any new parameters the extension associates with any other 1550 pre-existing NNTP verbs; 1552 . how support for the extension affects the behavior of a server 1553 and client NNTP; and, 1554 . the increment by which the extension is increasing the maximum 1555 length of the any commands over that specified in this 1556 document. 1557 In addition, any NNTP keyword value that starts with an upper 1558 or lower case "X" refers to a local NNTP service extension, 1559 which is used through bilateral, rather than standardized, 1560 agreement. Keywords beginning with "X" may not be used in a 1561 registered service extension. 1563 Any keyword values presented in the NNTP response that do not 1564 begin with "X" must correspond to a standard, standards-track, 1565 or IESG-approved experimental NNTP service extension 1566 registered with IANA. A conforming server must not offer non 1567 "X" prefixed keyword values that are not described in a 1568 registered extension. 1570 Additional verbs are bound by the same rules as NNTP keywords; 1571 specifically, verbs beginning with "X" are local extensions 1572 that may not be registered or standardized and verbs not 1573 beginning with "X" must always be registered. 1575 12.1 Initial IANA Registry 1577 The IANA's initial registry of NNTP service extensions 1578 consists of these entries: 1580 Service Extension NNTP Extension Label Added Behavior 1582 Overview Support OVER Defined in this 1583 document 1585 Specific Article LISTGROUP Defined in this 1586 Numbers document 1588 Header Pattern PAT Defined in this 1589 Matching document 1591 13. Augmented BNF[9] Syntax for NNTP Commands 1593 This syntax defines the non-terminal "command". The non-terminal 1594 "parameter" is used for command parameters whose syntax is 1595 specified elsewhere. The syntax is in alphabetical order. Note 1596 that ABNF strings are case insensitive. 1598 article-command = "ARTICLE" [1*WSP (msg-id / article-number)] 1599 *WSP CRLF 1601 article-number = 1*16DIGIT 1602 augument = parameter ; excluding sequence ".." 1603 body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP 1604 CRLF 1605 command = article-command / 1606 body-command / 1607 date-command / 1608 group-command / 1609 head-command / 1610 help-command / 1611 ihave-command / 1612 last-command / 1613 list-active-times-command / 1614 list-distrib-pats-command / 1615 list-distributions-command / 1616 list-extensions-command / 1617 list-newsgroups-command / 1618 list-overview-fmt-command / 1619 list-subscriptions-command / 1620 list-command / 1621 listgroup-command / 1622 mode-reader-command / 1623 newgroups-command / 1624 newnews-command / 1625 next-command / 1626 over-command / 1627 pat-command / 1628 post-command / 1629 quit-command / 1630 stat-command 1631 CR = %x0D 1632 CRLF = CR LF 1633 date-command = "DATE" *WSP CRLF 1634 date = 6*8DIGIT 1635 DIGIT = %x30-39 1636 distribution = parameter 1637 group-command = "GROUP" 1*WSP newsgroup *WSP CRLF 1638 head-command = "HEAD" [1*WSP (msg-id / article-number)] *WSP 1639 CRLF 1640 header = parameter 1641 help-command = "HELP" *WSP CRLF 1642 HT = %x09 1643 ihave-command = "IHAVE" 1*WSP msg-id *WSP CRLF 1644 last-command = "LAST" *WSP CRLF 1645 LF = %x0A 1646 list-active-times-command = "LIST" 1*WSP "ACTIVE.TIMES" 1647 [1*WSP wildmat] *WSP CRLF 1648 list-command = "LIST" [1*WSP "ACTIVE" [1*WSP wildmat]] *WSP 1649 CRLF 1650 list-distrib-pats-command = "LIST" 1*WSP "DISTRIB.PATS" *WSP 1651 CRLF 1652 list-distributions-command = "LIST" 1*WSP "DISTRIBUTIONS" *WSP 1653 CRLF 1654 list-extensions-command = "LIST" 1*WSP "EXTENSIONS" *WSP CRLF 1655 list-newsgroups-command = "LIST" 1*WSP "NEWSGROUPS" [1*WSP 1656 wildmat] 1657 *WSP CRLF 1658 list-overview-fmt-command = "LIST" 1*WSP "OVERVIEW.FMT" *WSP 1659 CRLF 1660 list-subscriptions-command = "LIST" 1*WSP "SUBSCRIPTIONS" *WSP 1661 CRLF 1662 listgroup-command = "LISTGROUP" [1*WSP newsgroup] *WSP CRLF 1663 mode-reader-command = "MODE" 1*WSP "READER" *WSP CRLF 1664 msg-id = 1665 newgroups-command = "NEWGROUPS" 1*WSP date 1*WSP time [1*WSP 1666 "GMT"/"UTC"][1*WSP "<" distribution *("," distribution) 1667 ">"] *WSP CRLF 1668 newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup) 1669 1*WSP date 1*WSP time [1*WSP "GMT"/"UTC"] 1670 [1*WSP "<" distribution *("," distribution) ">"] 1671 *WSP CRLF 1672 newsgroup = parameter 1673 next-command = "NEXT" *WSP CRLF 1674 over-command = "OVER" [1*WSP range] *WSP CRLF 1675 parameter = 1*(%x21-FF) ; generic command parameter 1676 pat-command = "PAT" 1*WSP header 1*WSP (range / msg-id) 1677 *(1*WSP wildmat) *WSP CRLF 1678 post-command = "POST" *WSP CRLF 1679 quit-command = "QUIT" *WSP CRLF 1680 range = article-number ["-" [article-number]] 1681 SP = %x20 1682 stat-command = "STAT" [1*WSP (msg-id / article-number)] *WSP 1683 CRLF 1684 time = 6DIGIT 1685 UTF-8-non-ascii = %xC0-FF 1*(%x80-BF) ; UTF-8 encoding of non- 1686 ASCII character 1687 wildmat = 1*("*" / "?" / wildmat-exact / wildmat-set / 1688 "\" (%x21-7F / UTF-8-non-ascii)) 1689 wildmat-exact = %x21-29 / %x2B-3E / %x40-5A / %x5D-7F / UTF-8- 1690 non-ascii 1691 ; exclude space * ? [ \ 1692 wildmat-non-hyphen = %x21-2C / %x2E-7F / UTF-8-non-ascii ; 1693 exclude space - 1694 wildmat-set = "[" ["^"] ["]" / "-"] *(wildmat-non-hyphen ["-" 1695 WSP = SP / HT 1697 14. Security Considerations 1699 There are no specific security mechanisms proposed in this standard, 1700 though such mechanisms may be added via the extensions process. 1702 15. References 1703 1 Kantor, B and P. Lapsley, "Network News Transfer Protocol", 1704 RFC-977, U.C. San Diego and U.C. Berkeley. 1706 2 Yergeau, F., "UTF-8, a transformation format of Unicode and 1707 ISO 10646", RFC 2044, Alis Technologies. 1709 3 Coded Character Set-7-bit American Standard Code for 1710 Information Interchange, ANSI x3.4-1986. 1712 4 Bradner, Scott, "Key words for use in RFCs to Indicate 1713 Requirement Levels", RFC-2119, Harvard University. 1715 5 Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 1716 distribution, UUNET Technologies, Revision 1.10, April, 1992. 1718 6 Horton, M.R. and R. Adams, "Standard for interchange of 1719 USENET messages", RFC-1036, AT&T Bell Laboratories and Center 1720 for Seismic Studies, December, 1987. 1722 7 Robertson, Rob, "FAQ: Overview database / NOV General 1723 Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq- 1724 nov.Z, January, 1995. 1726 8 Mills, David L., "Network Time Protocol (Version 3), 1727 Specification, Implementation and Analysis", RFC-1305, 1728 University of Delaware, March 1992. 1730 9 Crocker, D. and Overell, P., "Augmented BNF for Syntax 1731 Specifications: ABNF", RFC-2234, Internet Mail Consortium and 1732 Demon Internet, Ltd. 1734 16. Notes 1736 DEC is a registered trademark of Compaq Computer Corporation. 1738 UNIX is a registered trademark of the X/Open Consortium. 1740 VMS is a registered trademark of Compaq Equipment Corporation. 1742 17. Acknowledgments 1744 The author acknowledges the original authors of NNTP as 1745 documented in RFC 977: Brian Kantor and Phil Lapsey. 1747 The author gratefully acknowledges the work of the NNTP 1748 committee chaired by Eliot Lear. The organization of this 1749 document was influenced by the last available draft from this 1750 working group. A special thanks to Eliot for generously 1751 providing the original machine readable sources for that 1752 document. 1754 The author gratefully acknowledges the work of the Marshall 1755 Rose & John G. Meyers in RFC 1939 and the work of the DRUMS 1756 working group, specifically RFC 1869, which is the basis of 1757 the NNTP extensions mechanism detailed in this document. 1759 The author gratefully acknowledges the comments and additional 1760 information provided by the following individuals in preparing 1761 one of the progenitors of this document: 1763 . Wayne Davison 1764 . Clive D.W. Feather 1765 . Chris Lewis 1766 . Tom Limoncelli 1767 . Eric Schnoebelen 1768 . Rich Salz 1770 This work was precipitated by the work of various newsreader 1771 authors and newsserver authors, which includes those listed 1772 below: 1774 . Rick Adams -- Original author of the NNTP extensions to the RN 1775 newsreader and last maintainer of Bnews 1776 . Stan Barber -- Original author of the NNTP extensions to the 1777 newsreaders that are part of Bnews. 1778 . Geoff Collyer -- Original author of the OVERVIEW database 1779 proposal and one of the original authors of CNEWS 1780 . Dan Curry -- Original author of the xvnews newsreader 1781 . Wayne Davision -- Author of the first threading extensions to the 1782 RN newsreader (commonly called TRN). 1783 . Geoff Huston -- Original author of ANU NEWS 1784 . Phil Lapsey -- Original author of the UNIX reference 1785 implementation 1786 . Ian Lea -- Maintainer of the TIN newsreader 1787 . Rich Salz -- Original author of INN 1788 . Henry Spencer -- One of the original authors of CNEWS 1789 . Kim Storm -- Original author of the NN newsreader 1791 18. Author's Address 1793 Stan Barber 1794 P.O. Box 300481 1795 Houston, Texas, 77230 1796 Email: 1798 This document expires January 7, 1999.