idnits 2.17.1 draft-ietf-nntpext-base-04.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-19) 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 39 longer pages, the longest (page 38) being 71 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 389 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [0-9a-zA-Z], [5], [6], [C], [7], [8], [9], [GMT], [S], [10], [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 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 (March 1998) is 9532 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 258 looks like a reference -- Missing reference section? '0-9a-zA-Z' on line 294 looks like a reference -- Missing reference section? 'GMT' on line 1604 looks like a reference -- Missing reference section? '6' on line 314 looks like a reference -- Missing reference section? 'C' on line 451 looks like a reference -- Missing reference section? 'S' on line 465 looks like a reference -- Missing reference section? '7' on line 600 looks like a reference -- Missing reference section? '8' on line 1336 looks like a reference -- Missing reference section? '9' on line 1527 looks like a reference -- Missing reference section? '10' on line 1737 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Barber 3 Expires: September 30, 1998 Academ Consulting Services 4 March 1998 6 Network News Transport Protocol 8 draft-ietf-nntpext-base-04.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 view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West 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 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. 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 AUTHENTICATION 109 NEWS EXCHANGE 110 CONCLUSION 112 NNTP operates over any reliable data stream 8-bit-wide 113 channel. When running over TCP/IP, the official port for the 114 NNTP service is 119. Initially, the server host starts the 115 NNTP service by listening on a TCP port. When a client host 116 wishes to make use of the service, it MUST establish a TCP 117 connection with the server host by connecting to that host on 118 the same port on which the server is listening. This is the 119 CONNECTION step. When the connection is established, the NNTP 120 server host MUST send a greeting. This is the GREETING step. 121 The client host and server host then SHOULD then exchange 122 commands and responses (respectively) until the connection is 123 closed or aborted. This final step is called the DISCONNECTION 124 step. 126 If there is a CONCLUSION step, it MUST immediately precede the 127 DISCONNECTION step. There MUST be only one CONNECTION, 128 CONCLUSION and DISCONNECTION step for each NNTP session. All 129 other steps MAY be repeated as needed. 131 The character set for all NNTP commands is UTF-8. Commands in 132 the NNTP MUST consist of an US-ASCII case-insensitive keyword, 133 which MAY be followed by one or more arguments. An US-ASCII 134 CRLF pair MUST terminate all commands. Multiple commands MUST 135 NOT be permitted on the same line. Keywords MUST consist of 136 printable US-ASCII characters. Unless otherwise noted 137 elsewhere in this document, Arguments SHOULD consist of 138 printable US-ASCII characters. Keywords and arguments MUST be 139 each separated by one or more US-ASCII SPACE or US-ASCII TAB 140 characters. Keywords MUST be at least three US-ASCII 141 characters and MUST NOT exceed 12 US-ASCII characters. 142 Command lines MUST NOT exceed 512 octets, which includes the 143 terminating US-ASCII CRLF pair. 145 Each response MUST start with a three-digit status indicator 146 that is sufficient to distinguish all responses. Responses to 147 certain commands MAY be multi-line. In these cases, which are 148 clearly indicated below, after sending the first line of the 149 response and an US-ASCII CRLF, any additional lines are sent, 150 each terminated by an US-ASCII CRLF pair. When all lines of 151 the response have been sent, a final line MUST be sent, 152 consisting of a termination octet (US-ASCII decimal code 046, 153 ".") and an US-ASCII CRLF pair. If any line of the multi-line 154 response begins with the termination octet, the line MUST be 155 "byte-stuffed" by pre-pending the termination octet to that 156 line of the response. Hence, a multi-line response is 157 terminated with the five octets "CRLF.CRLF" (in US-ASCII). 158 When examining a multi-line response, the client MUST check to 159 see if the line begins with the termination octet. If so and 160 if octets other than US-ASCII CRLF follow, the first octet of 161 the line (the termination octet) MUST be stripped away. If so 162 and if US-ASCII CRLF immediately follows the termination 163 character, then the response from the NNTP server is ended and 164 the line containing ".CRLF" (in US-ASCII) MUST NOT considered 165 part of the multi-line response. 167 A NNTP server MAY have an inactivity autologout timer. Such a 168 timer MUST be of at least three minutes duration. The receipt 169 of any command from the client during that interval should 170 suffice to reset the autologout timer. When the timer 171 expires, the server should close the TCP connection without 172 sending any response to the client. 174 4.1 Responses Codes 176 Each response MUST begin with a three-digit response code. 177 These are status reports from the server and indicate the 178 response to the last command received from the client. 180 The first digit of the response broadly indicates the success, 181 failure, or progress of the previous command. 183 1xx - Informative message 184 2xx - Command ok 185 3xx - Command ok so far, send the rest of it. 186 4xx - Command was correct, but couldn't be performed for some 187 reason. 188 5xx - Command unimplemented, or incorrect, or a serious 189 program error occurred. 190 The next digit in the code indicates the function response 191 category. 193 x0x - Connection, setup, and miscellaneous messages 194 x1x - Newsgroup selection 195 x2x - Article selection 196 x3x - Distribution functions 197 x4x - Posting 198 x5x - Authentication and Authorization 199 x8x - Nonstandard (private implementation) extensions 200 x9x - Debugging output 202 The exact response codes that MUST be expected from each 203 command are detailed in the description of the keyword that is 204 the first part of the command. In addition, below is listed a 205 general set of response codes that MAY be received at any 206 time. 208 Certain status responses contain parameters such as numbers 209 and names. In those cases, the number and type of such 210 parameters MUST be fixed for each response code to simplify 211 interpretation of the response. In all other cases, the client 212 MUST only use the response code itself to determine the nature 213 of the response. 215 Parameters MUST be separated from the numeric response code 216 and from each other by a single US-ASCII space. All numeric 217 parameters MUST be in base 10 (decimal) format, and may have 218 leading zeros. All string parameters MUST begin after the 219 separating space, and MUST end before the following separating 220 space or the US-ASCII CRLF pair at the end of the line. 221 (Therefore, string parameters MUST NOT contain US-ASCII 222 spaces.) All text, if any, in the response which is not a 223 parameter of the response must follow and be separated from 224 the last parameter by an US-ASCII space. Also, note that the 225 text following a response number may vary in different 226 implementations of the server. The 3-digit numeric code should 227 be used to determine what response was sent. 229 Response codes not specified in this standard MAY be used for 230 any installation-specific additional commands also not 231 specified. These SHOULD be chosen to fit the pattern of x8x 232 specified above. (Note that debugging is provided for 233 explicitly in the x9x response codes.) 235 The use of unspecified response codes for a standard command 236 is prohibited. 238 The response pattern x9x is provided for debugging. Since 239 much debugging output may be classed as "informative 240 messages", it MUST be the case that responses 190 through 199 241 WILL be used for various debugging outputs. There is no 242 requirement in this specification for debugging output. 243 However, if such is provided over the connected stream, it 244 MUST use these response codes. If appropriate to a specific 245 implementation, other x9x codes MAY be used for debugging. 246 (For example, response code 290 could be used to acknowledge a 247 remote debugging request.) 249 A server MUST respond to an unrecognized, unimplemented, or 250 syntactically invalid command with a negative status indicator 251 (response codes of the form 5XX). A server MUST respond to a 252 command issued when the session is in an incorrect state by 253 responding with a negative status indicator. This may be from 254 either the 4XX or 5XX group as appropriate. 256 5. The WILDMAT format 258 The WILDMAT format[5] was first developed by Rich Salz based 259 on the format used in the UNIX "find" command to articulate 260 file names. It was developed to provide a uniform mechanism 261 for matching patterns in the same manner that the UNIX shell 262 matches filenames. Patterns are implicitly anchored at the 263 beginning and end of each string when testing for a match. 265 There are five pattern-matching operations other than a strict 266 one-to-one match between the pattern and the source to be 267 checked for a match. The first is an asterisk (*) to match any 268 sequence of zero or more UTF-8 characters. The second is a 269 question mark (?) to match any single UTF-8 character. The 270 third specifies a specific set of characters. The set is 271 specified as a list of characters, or as a range of characters 272 where the beginning and end of the range are separated by a 273 minus (or dash) character, or as any combination of lists and 274 ranges. The dash can also be included in the set as a 275 character it if is the beginning or end of the set. This set 276 is enclosed in square brackets. The close square bracket (]) 277 may be used in a set if it is the first character in the set. 278 The fourth operation is the same as the logical not of the 279 third operation and is specified the same way as the third 280 with the addition of a caret character (^) at the beginning of 281 the test string just inside the open square bracket. The final 282 operation uses the backslash character to invalidate the 283 special meaning of the open square bracket ([), the asterisk, 284 backslash or the question mark. Two backslashes in sequence 285 will result in the evaluation of the backslash as a character 286 with no special meaning. 288 5.1 Examples 290 a) [^]-] -- matches any single character other than a 291 close square bracket or a minus sign/dash. 292 b) *bdc -- matches any string that ends with the string 293 "bdc" including the string "bdc" (without quotes). 294 c) [0-9a-zA-Z] -- matches any single printable 295 alphanumeric ASCII character. 296 d) a??d -- matches any four character string which 297 begins with a and ends with d. 299 6. Format for Keyword Descriptions 300 On the following pages are descriptions of each keyword 301 recognized by the NNTP server and the responses that will be 302 returned by those commands. These keywords are grouped by the 303 functional step in which they are used. 305 Each keyword is shown in upper case for clarity, although the 306 NNTP server ignores case in the interpretation of commands. 307 Any parameters are shown in lower case. A parameter shown in 308 [square brackets] is optional. For example, [GMT] indicates 309 that the triglyph GMT may present or omitted. A parameter that 310 may be repeated is followed by an ellipsis. Mutually exclusive 311 parameters are separated by a vertical bar (|) character. For 312 example, ggg| indicates that a group name or a 313 may be specified, but not both. Some parameters 314 may be case or language specific. See RFC 1036[6] for these 315 details. 317 In addition, certain commands make use of a pattern for 318 selection of multiple news groups. The pattern in all cases is 319 based on the WILDMAT format introduced by Rich Salz in 1986. 320 Arguments expected to be in wildmat format will be represented 321 by the string wildmat. This format is discussed in detail in 322 section 5 of this memo. 324 7. The GREETING Step 326 7.1 Initial Connection 328 There is no keyword presented by the client upon initial 329 connection to the server. The server MUST present an 330 appropriate response code as a greeting to the client. This 331 response informs the client about what steps the client should 332 take to reach the news exchange step. 334 The server must present a 200 greeting code if the client is 335 authorized to post articles though the use of the POST keyword 336 on this server. 338 The server must present a 201 greeting code if the client is 339 not authorized to post articles using the POST keyword, but no 340 other authentication is required. 342 The server must present a 205 greeting code if the client is 343 required to present authentication before it is permitted to 344 use any keywords available in the news exchange step. 346 The server must present a 502 greeting code if the client is 347 not permitted under any circumstances from interacting with 348 the server. The server should immediately close the connection 349 with the client after presenting this code. 351 In all other cases, the server must present a 400 greeting 352 code. 354 7.1.1 MODE READER 356 MODE READER 358 MODE READER MAY be used by the client to indicate to the 359 server that it is a news reading client. This command may be 360 entered at any time. The server must present a greeting code 361 (as described in section 7.1.1.1) appropriate to the server's 362 ability to provide service to this client in this mode. 364 7.1.1.1 Responses 365 200 Hello, you can post 366 201 Hello, you can't post 367 205 Authentication required 368 400 Service temporarily unavailable 369 502 Service unavailable 371 8. The CAPABILITIES DISCOVERY Step 373 A client NNTP supporting NNTP service extensions should query 374 a server early in the session for extensions session by 375 issuing the LIST EXTENSIONS command. If the NNTP server 376 supports the NNTP service extensions it MUST give a successful 377 response (see section 8.1.1), a failure response (see section 378 8.1.2), or an error response (see section 8.1.3). If the NNTP 379 server does not support any NNTP service extensions, it MUST 380 generate an error response (see section 8.1.4). 382 8.1 LIST EXTENSIONS 384 If successful, the server NNTP MUST respond with code 202. On 385 failure, the server NNTP MUST respond with code 503. On error, 386 the server NNTP MUST respond with one of codes 400, 402, 500 387 and 501. 389 This command MAY be issued at anytime during a session. It is 390 not required that the client issues this command before 391 attempting to make use of any extension. The response 392 generated by this command MAY change during a session because 393 of other state information (e.g. authentication or server 394 administration). However, a client NNTP MUST NOT cache (for 395 use in another session) any information returned if the LIST 396 EXTENSIONS command succeeds. That is, a client NNTP MUST issue 397 the LIST EXTENSIONS command at least once during each session 398 to get the current and correct information concerning 399 available extensions during that session. 401 8.1.1 Successful response 403 If the server NNTP implements and is able to perform the LIST 404 EXTENSIONS command, it MUST return code 202. 406 Text following the return code on the first line of the reply 407 is free form, and not interpreted, and has no practical use, 408 as this text is not expected to be revealed to end users. The 409 syntax of other reply lines is precisely defined, and if 410 present, MUST be exactly as specified. 412 Each line listing an extension in the extension-listing begins 413 with a single space. That space is not optional, nor does it 414 indicate general white space. This space guarantees that the 415 line can never be misinterpreted as the end of the extension- 416 listing, but is required even where there is no possibility of 417 ambiguity. 419 Each extension supported must be listed on a separate line to 420 facilitate the possible inclusion of parameters supported by 421 each extension command. The extension-label to be used in the 422 response to the LIST EXTENSIONS command will be specified as 423 each new extension is added to the NNTP command set. Often it 424 will be the name of a new command added; however this is not 425 required. In fact it is not required that a new feature 426 actually add a new command. Any parameters included are to be 427 specified with the definition of the command concerned. 429 That specification shall also specify how any parameters 430 present are to be interpreted. 432 The extension-label is nominally case sensitive, however the 433 definitions of specific labels and parameters specify the 434 precise interpretation, and it is to be expected that those 435 definitions will usually specify the label in a case 436 independent manner. Where this is done, implementations are 437 recommended to use upper case letters when transmitting the 438 extension response. 440 The LIST EXTENISONS command itself is not included in the list 441 of features supported, support for the LIST EXTENSIONS command 442 is indicated by return of a reply other than a 500 or 502 443 reply. 445 The end of the list is defined by the usual period on a line 446 by itself. 448 A typical example reply to the LIST EXTENSIONS command might 449 be a multiline reply of the form: 451 [C] LIST EXTENSIONS 453 [S] 202-Extensions supported: 455 [S] OVER 457 [S] AUTHINFO-GENERIC 459 [S] PAT 461 [S] LISTGROUP 463 [S] AUTHINFO 465 [S] . 467 The particular extensions shown here are simply examples of 468 what may be defined in other places, no particular meaning 469 should be attributed to them. Recall also, that the extension 470 names returned are not command names, as such, but simply 471 indications that the server possesses some attribute or other. 473 The order in which the extensions are returned is of no 474 importance, NNTP Servers processes are not required to 475 implement any particular order, or even to consistently return 476 the same order when the command is repeated. 478 8.1.2 Failure response 480 If for some reason the server NNTP is unable to list the 481 service extensions it supports, it MUST return code 503. 483 In the case of a failure response, the client NNTP may try the 484 extensions either as the need arises or configure itself for 485 the basic NNTP functionality defined in this document. 487 8.1.3 Error responses from extended servers 489 If the server NNTP recognizes the LIST EXTENSIONS command, but 490 due to various conditions cannot make any extensions available 491 to the client at the time the client issued the LIST 492 EXTENSIONS command, it MUST return code 402. No list (even an 493 empty one) will be returned. 495 The client NNTP should configure itself for the basic NNTP 496 functionality defined in this document, or issue commands that 497 might change the state of the server (authentication, for 498 example), or issue the QUIT command (see section 11.1) if a 499 particular extension is required for the client to properly 500 operate. 502 If the server NNTP determines that the NNTP service is no 503 longer available (e.g., due to imminent system shutdown), it 504 must return code 400. 506 In the case of an error response, the client NNTP should issue 507 the QUIT command (see section 11.1). 509 8.1.4 Responses from servers without extensions 511 A server NNTP that conforms to this memo but does not support 512 the extensions specified here will not recognize the LIST 513 EXTENSIONS command and MUST consequently return code 500 or 514 code 501. The server NNTP SHALL stay in the same state after 515 returning this code. The client NNTP may try the extensions 516 either as the need arises or configure itself for the basic 517 NNTP functionality defined in this document. 519 8.1.5 Responses from improperly implemented servers 521 A server NNTP that improperly implements the LIST EXTENSIONS 522 command may return an empty list. Clients SHALL accommodate 523 this protocol violation and interpret it as a response code 524 402. 526 9. The AUTHENTICATION Step 528 9.1 AUTHINFO 530 AUTHINFO is used to inform a server about the identity of a 531 user of the server. In all cases, clients MUST provide this 532 information when requested by the server. Servers are not 533 required to accept authentication information that is 534 volunteered by the client. Clients MUST accommodate servers 535 that reject any authentication information volunteered by the 536 client. 538 9.1.1 AUTHINFO 540 AUTHINFO USER username 542 AUTHINFO PASS password 544 When authorization is required, the server MUST send a 450 545 response requesting authorization from the client. The client 546 MUST enter AUTHINFO USER username in order to make use of the 547 AUTHINFO authentication step. If the server will accept this 548 form of authentication and a password is required to complete 549 the authentication step, the server MUST respond with a 350 550 response. The client MUST then send AUTHINFO PASS followed by 551 one or more space characters followed by the password. If the 552 username/password combination is valid or no password is 553 required, the server MUST return a 250 response and the client 554 should then retry the original command to which the server 555 responded with the 450 response. The server SHALL then process 556 the command normally. If the combination is not valid, the 557 server MUST return a 452 response. 559 If the server returns 501, this means that the authenticator 560 invocation was syntactically incorrect, or that this form of 561 AUTHINFO is not supported. 563 If the requested authenticator capability is not found or 564 there is some other unspecified server program error, the 565 server MUST return the 503 response code. 567 9.1.1.1 Responses 569 250 Authorization accepted 570 350 Continue with authorization sequence 571 450 Authorization required for this command 572 452 Authorization rejected 573 501 Command not supported or Command Syntax Error 574 503 Program error, function not performed 576 9.1.2 AUTHINFO GENERIC 577 AUTHINFO GENERIC authenticator arguments... 579 AUTHINFO GENERIC is used to identify a specific entity to the 580 server using arbitrary authentication or identification 581 protocols. The desired protocol is indicated by the 582 authenticator parameter, and any number of parameters can be 583 passed to the authenticator. 585 When authorization is required, the server will send a 450 586 response requesting authorization from the client. 588 The client should enter AUTHINFO GENERIC followed by the 589 authenticator name and the arguments if any. The 590 authenticator and arguments must not contain the sequence 591 "..". 593 The server will attempt to engage the server end 594 authenticator; similarly, the client should engage the client 595 end authenticator. The server end authenticator will then 596 initiate authentication using the NNTP sockets (if appropriate 597 for that authentication protocol), using the protocol 598 specified by the authenticator name. These authentication 599 protocols are not included in this document, but are similar 600 in structure to those referenced in RFC 1731[7] for the IMAP-4 601 protocol. 603 If the server returns 501, this means that the authenticator 604 invocation was syntactically incorrect, or that AUTHINFO 605 GENERIC is not supported. The client should retry using the 606 AUTHINFO USER command. 608 If the requested authenticator capability is not found or 609 there is some other unspecified server program error, the 610 server returns the 503 response code. 612 The authenticators converse using their protocol until 613 complete. If the authentication succeeds, the server 614 authenticator will terminate with a 250, and the client can 615 continue by reissuing the command that prompted the 350. If 616 the authentication fails, the server will respond with a 452. 618 The client must provide authentication when requested by the 619 server. The server may request authentication at any time. 620 Servers may request authentication more than once during a 621 single session. 623 When the server authenticator completes, it provides to the 624 server (by a mechanism herein undefined) the email address of 625 the user, and potentially what the user is allowed to access. 626 Once authenticated and if the email address provided by the 627 authenticator does not match the user-supplied From: line, the 628 server SHALL insert a Sender: line into any posted articles 629 using the email address provided by the authenticator. 630 Additionally, the server should log the event, including the 631 user's authenticated email address (if available). This will 632 provide a means by which subsequent statistics generation can 633 associate news group references with unique entities - not 634 necessarily by name. 636 9.1.2.1 Responses 637 250 Authorization accepted 638 450 Authorization required for this command 639 452 Authorization rejected 640 501 Command not supported or Command Syntax Error 641 503 Program error, function not performed 642 nnn authenticator-specific protocol. 644 9.1.3 Transition Issues 645 The implementations of AUTHINFO commonly in use prior to the 646 release of this memo have a different response code set. The 647 code 281 was used in place of 250, 381 and 480 were used in 648 place of 450 and 482 and 502 were used in place of 452. Client 649 coded to be compliant with this spec may also want to be able 650 to accommodate the older codes to lessen the impact of the 651 transition to this specification. 653 10. The NEWS EXCHANGE Step 655 During this step, two basic types of transactions occur: 657 article retrieval from the server and article posting to the 658 server. 660 10.1 Article Retrieval 662 News reading clients have available a variety of mechanisms to 663 retrieve articles via NNTP. The news articles are stored and 664 indexed using three types of keys. One key is the message id 665 of an article. According to RFC 1036, this identifier should 666 be globally unique. Another key is composed of the news group 667 name and the article number within that news group. That key 668 MUST be unique to a particular server (there will be only one 669 article with that number within a particular news group), but 670 is not required to be globally unique. Additionally, because 671 the same article can be cross-posted to multiple news groups, 672 there may be multiple keys that point to the same article on 673 the same server. The final key is the arrival timestamp, 674 giving the time that the article arrived at the server. 676 The server MUST ensure that article numbers are issued in 677 order of arrival timestamp; that is, articles arriving later 678 MUST have higher numbers than those that arrive earlier. The 679 server SHOULD allocate the next sequential unused number to 680 each new article. 682 Article numbers MUST lie between 1 and 4,294,967,295 683 inclusive. The client and server SHOULD NOT use leading zeroes 684 in specifying article numbers, and MUST NOT use more than 16 685 digits. In some situations, the value zero replaces an article 686 number to show some special situation. One case involves 687 responses to the ARTICLE, STAT, BODY and HEAD commands where a 688 is specified as the argument. In those cases, the 689 "current article pointer" is not changed. 691 10.1.1 Article Retrieval by News Group Name and Article Number 693 The following commands are used to set the current news group 694 name and the "current article pointer" which is used by other 695 commands for article retrieval. 697 10.1.1.1 GROUP 699 GROUP ggg 701 The required parameter ggg is the name of the news group to be 702 selected (e.g. "news.software.b"). A list of valid news groups 703 may be obtained by using the LIST keyword. See section 10.4 704 for more information on the LIST keyword. 706 The successful selection response will return the article 707 numbers of the first and last articles in the group at the 708 moment of selection (these numbers are referred to as the 709 "reported low water mark" and the "reported high water mark"), 710 and an estimate of the number of articles on file in the 711 group. 713 If the group is not empty, the estimate MUST be at least the 714 actual number of articles available, and MUST be no greater 715 than one more than the difference between the reported low and 716 high water marks. (Some implementations will actually count 717 the number of articles on file. Others will just subtract the 718 low water mark from the high water mark and add one to get an 719 estimate.) 721 If the group is empty, one of the following three situations 722 will occur. Clients MUST accept all three cases; servers MUST 723 NOT represent an empty group in any other way. 725 . The high water mark will be one less than the low water mark, 726 and the estimated article count will be zero. Servers SHOULD 727 use this method to show an empty group. This is the only time 728 that the high water mark can be less than the low water mark. 729 . All three numbers will be zero. 730 . The high water mark is greater than or equal to the low water 731 mark; the estimated article count might be zero or non-zero; 732 if non-zero, the same requirements apply as for a non-empty 733 group. 735 The set of articles in a group may change after the GROUP 737 command is carried out. That is: 739 . articles may be removed from the group; 740 . articles may be reinstated in the group with the same article 741 number, but those articles MUST have numbers no less than the 742 reported low water mark (note that this is a reinstatement of 743 the previous article, not a new article reusing the number); 744 . new articles may be added with article numbers greater than 745 the reported high water mark (if an article that was the one 746 with the highest number has been removed, the next new article 747 will not have the number one greater than the reported high 748 water mark). 749 Except when the group is empty and all three numbers are zero, 750 whenever a subsequent GROUP command for the same news group is 751 issued, either by the same client or a different client, the 752 reported low water mark in the response MUST be no less than 753 that in any previous response for that news group sent to any 754 client. The client may make use of the low water mark to 755 remove all remembered information about articles with lower 756 numbers, as these will never recur. This includes the 757 situation when the high water mark is one less than the low 758 water mark. 760 No similar assumption can be made about the high water mark, 761 as this can decrease if an article is removed, and then 762 increase again if it is reinstated or if new articles arrive. 764 When a valid group is selected by means of this command, the 765 internally maintained "current article pointer" MUST be set to 766 the first article in the group and the name of the current 767 news group MUST be set to the selected news group name. If an 768 invalid group is specified, the previously selected group and 769 article MUST remain selected. If an empty news group is 770 selected, the "current article pointer" is in an indeterminate 771 state and MUST NOT be used. 773 The GROUP keyword MUST be used by a client and a successful 774 response received before the any other command is used that 775 depends on having the "current article pointer" be valid. 777 10.1.1.1.1 Responses 779 211 n f l s group selected 780 (n = estimated number of articles in group, f = first 781 article number in the group, l = last article number in 782 the group, s = name of the group.) 783 411 no such news group 785 10.1.1.2 LAST 787 LAST 789 The internally maintained "current article pointer" MUST be 790 set to the previous article in the current news group. If 791 already positioned at the first article of the news group, an 792 error message MUST be returned and the current article MUST 793 remain selected. 795 There MAY be no previous article in the group, although the 796 current article number is not the reported low water mark. 797 There MUST NOT be a previous article when the current article 798 number is the reported low water mark. 800 Because articles can be removed and added, the results of 801 multiple LAST and NEXT commands MAY not be consistent over the 802 life of a particular NNTP session. 804 The internally-maintained "current article pointer" MUST be 805 set by this command. 807 A response indicating the current article number and a 808 message-id string MUST be returned. No text is sent in 809 response to this command. 811 10.1.1.2.1 Responses 813 223 n a article retrieved - request text separately (n = 814 article number, a = unique article id) 815 412 no news group selected 816 420 no current article has been selected 817 422 no previous article in this group 819 10.1.1.3 NEXT 821 NEXT 823 The internally maintained "current article pointer" MUST be 824 advanced to the next article in the current news group. If no 825 more articles remain in the current group, an error message 826 MUST be returned and the current article MUST remain selected. 828 The internally-maintained "current article pointer" MUST be 829 set by this command. 831 A response indicating the current article number and the 832 message-id string MUST be returned. No text is sent in 833 response to this command. 835 10.1.1.3.1 Responses 837 223 n a article retrieved - request text separately (n = 838 article number, a = unique article id) 839 412 no news group selected 840 420 no current article has been selected 841 421 no next article in this group 843 10.2 Retrieval of Articles and Article Sections 845 There are two forms to the ARTICLE command (and the related 846 BODY, HEAD, and STAT commands), each using a different method 847 of specifying which article is to be retrieved. When the 848 ARTICLE keyword is followed by a message-id in angle brackets 849 ("<" and ">"), the first form of the command MUST be used; 850 when a numeric parameter or no parameter is supplied, the 851 second form MUST be invoked. In the cases where the argument 852 is a message-id, the article number specified in the response 853 must be zero. This is one of the special cases described in 854 section 10.1. 856 An article, as defined by RFC 1036, consists of two parts: the 857 article headers and the article body. When responding to an 858 article command, the server returns the entire article 859 contents and does not attempt to alter or translate them in 860 any way. 862 10.2.1 ARTICLE 864 ARTICLE [|nnn] 866 This response displays the header, a blank line, then the body 867 (text) of the specified article. The optional parameter nnn is 868 the numeric id of an article in the current news group and 869 SHOULD be chosen from the range of articles provided when the 870 news group was selected. If it is omitted, the current 871 article is assumed. Message-id is the message id of an article 872 as shown in that article's header. 874 Please note that the internally-maintained "current article 875 pointer" MUST NOT be altered when the message-id argument is 876 used. This is both to facilitate the presentation of articles 877 that may be referenced within an article being read, and 878 because of the semantic difficulties of determining the proper 879 sequence and membership of an article which may have been 880 posted to more than one news group. 882 The internally-maintained "current article pointer" MUST be 883 set when a valid article number is specified as the argument. 884 This includes the case when an article number is implied by 885 the use of no argument. 887 A previously valid article number MAY not remain valid if the 888 article has been removed. A previously invalid article number 889 MAY become valid if the article has been reinstated, but such 890 an article number MUST be no less than the reported low water 891 mark for that group. 893 If there is a valid article to present in a reply to this 894 command, a response indicating the current article number (or 895 zero when the message-id argument is used), a message-id 896 string, and that text is to follow MUST be returned. 898 The message-id string returned is an identification string 899 contained within angle brackets ("<" and ">"), which is 900 derived from the header of the article itself. The Message-ID 901 header line (required by RFC 1036) from the article must be 902 used to supply this information. If the message-id header line 903 is missing from the article, a single digit "0" (zero) should 904 be supplied within the angle brackets. 906 Since the message-id field is unique for each article, it may 907 be used by a news reading program to skip duplicate displays 908 of articles that have been posted more than once, or to more 909 than one news group. 911 10.2.1.1 Responses 912 220 n article retrieved - head and body follow (n = 913 article number, = message-id) 914 412 no news group has been selected 915 420 no current article has been selected 916 423 no such article number in this group 917 430 no such article found 919 10.2.2 HEAD 920 HEAD [|nnn] 921 This response displays the header of the specified article. 922 The optional parameter nnn is the numeric id of an article in 923 the current news group and SHOULD be chosen from the range of 924 articles provided when the news group was selected. If it is 925 omitted, the current article is assumed. Message-id is the 926 message id of an article as shown in that article's header. 928 Please note that the internally-maintained "current article 929 pointer" MUST NOT be altered when the message-id argument is 930 used. This is both to facilitate the presentation of articles 931 that may be referenced within an article being read, and 932 because of the semantic difficulties of determining the proper 933 sequence and membership of an article which may have been 934 posted to more than one news group. 936 The internally-maintained "current article pointer" MUST be 937 set when a valid article number is specified as the argument. 938 This includes the case when an article number is implied by 939 the use of no argument. 941 A previously valid article number MAY not remain valid if the 942 article has been removed. A previously invalid article number 943 MAY become valid if the article has been reinstated, but such 944 an article number MUST be no less than the reported low water 945 mark for that group. 947 If there is a valid article to present in a reply to this 948 command, a response indicating the current article number (or 949 zero when the message-id argument is used), a message-id 950 string, and that text is to follow MUST be returned. 952 The message-id string returned is an identification string 953 contained within angle brackets ("<" and ">"), which is 954 derived from the header of the article itself. The Message-ID 955 header line (required by RFC 1036) from the article must be 956 used to supply this information. If the message-id header line 957 is missing from the article, a single digit "0" (zero) should 958 be supplied within the angle brackets. 960 Since the message-id field is unique for each article, it may 961 be used by a news reading program to skip duplicate displays 962 of articles that have been posted more than once, or to more 963 than one news group. 965 10.2.2.1 Responses 966 221 n article retrieved - head follows 967 412 no news group has been selected 968 420 no current article has been selected 969 423 no such article number in this group 970 430 no such article found 972 10.2.3 BODY 973 BODY [|nnn] 975 This response displays the body (text) of the specified 976 article. The optional parameter nnn is the numeric id of an 977 article in the current news group and SHOULD be chosen from 978 the range of articles provided when the news group was 979 selected. If it is omitted, the current article is assumed. 980 Message-id is the message id of an article as shown in that 981 article's header. 983 Please note that the internally-maintained "current article 984 pointer" MUST NOT be altered when the message-id argument is 985 used. This is both to facilitate the presentation of articles 986 that may be referenced within an article being read, and 987 because of the semantic difficulties of determining the proper 988 sequence and membership of an article which may have been 989 posted to more than one news group. 991 The internally-maintained "current article pointer" MUST be 992 set when a valid article number is specified as the argument. 993 This includes the case when an article number is implied by 994 the use of no argument. 996 A previously valid article number MAY not remain valid if the 997 article has been removed. A previously invalid article number 998 MAY become valid if the article has been reinstated, but such 999 an article number MUST be no less than the reported low water 1000 mark for that group. 1002 If there is a valid article to present in a reply to this 1003 command, a response indicating the current article number (or 1004 zero when the message-id argument is used), a message-id 1005 string, and that text is to follow MUST be returned. 1007 The message-id string returned is an identification string 1008 contained within angle brackets ("<" and ">"), which is 1009 derived from the header of the article itself. The Message-ID 1010 header line (required by RFC 1036) from the article must be 1011 used to supply this information. If the message-id header line 1012 is missing from the article, a single digit "0" (zero) should 1013 be supplied within the angle brackets. 1015 Since the message-id field is unique for each article, it may 1016 be used by a news reading program to skip duplicate displays 1017 of articles that have been posted more than once, or to more 1018 than one news group. 1020 10.2.3.1 Responses 1021 222 n article retrieved - body follows 1022 412 no news group has been selected 1023 420 no current article has been selected 1024 423 no such article number in this group 1025 430 no such article found 1027 10.2.4 STAT 1028 STAT [|nnn] 1030 This response returns only status information; no article 1031 contents are returned. The optional parameter nnn is the 1032 numeric id of an article in the current news group and SHOULD 1033 be chosen from the range of articles provided when the news 1034 group was selected. If it is omitted, the current article is 1035 assumed. Message-id is the message id of an article as shown 1036 in that article's header. 1038 Please note that the internally-maintained "current article 1039 pointer" MUST NOT be altered when the message-id argument is 1040 used. This is both to facilitate the presentation of articles 1041 that may be referenced within an article being read, and 1042 because of the semantic difficulties of determining the proper 1043 sequence and membership of an article which may have been 1044 posted to more than one news group. 1046 The internally-maintained "current article pointer" MUST be 1047 set when a valid article number is specified as the argument. 1048 This includes the case when an article number is implied by 1049 the use of no argument. 1051 A previously valid article number MAY not remain valid if the 1052 article has been removed. A previously invalid article number 1053 MAY become valid if the article has been reinstated, but such 1054 an article number MUST be no less than the reported low water 1055 mark for that group. 1057 If there is a valid article to present in a reply to this 1058 command, a response indicating the current article number (or 1059 zero when the message-id argument is used) and a message-id 1060 string MUST be returned. 1062 The message-id string returned is an identification string 1063 contained within angle brackets ("<" and ">"), which is 1064 derived from the header of the article itself. The Message-ID 1065 header line (required by RFC 1036) from the article must be 1066 used to supply this information. If the message-id header line 1067 is missing from the article, a single digit "0" (zero) should 1068 be supplied within the angle brackets. 1070 Since the message-id field is unique for each article, it may 1071 be used by a news reading program to skip duplicate displays 1072 of articles that have been posted more than once, or to more 1073 than one news group. 1075 10.2.4.1 Responses 1076 223 n article retrieved - request text separately 1077 412 no news group has been selected 1078 420 no current article has been selected 1079 423 no such article number in this group 1080 430 no such article found 1082 10.3 Article Posting 1084 Article posting is done in one of two modes: individual 1085 article posting from news reading clients and article transfer 1086 from other news servers. 1088 10.3.1 POST 1090 POST 1092 If posting is allowed, response code 340 MUST be returned to 1093 indicate that the article to be posted should be sent. 1094 Response code 440 MUST be sent if that posting is prohibited 1095 for some installation-dependent reason. 1097 If posting is permitted, the article MUST be presented to the 1098 server by the client in the format specified by RFC 1036. The 1099 text forming the header and body of the message to be posted 1100 MUST be sent by the client using the conventions for text 1101 received from the news server: A single period (".") on a line 1102 indicates the end of the text, with lines starting with a 1103 period in the original text having that period doubled during 1104 transmission. 1106 Following the presentation of the termination sequence by the 1107 client, the server MUST return a response code indicating 1108 success or failure of the article transfer. 1110 No attempt shall be made by the server to filter characters, 1111 fold or limit lines, or otherwise process incoming text. The 1112 intent is that the server just passes the incoming message to 1113 be posted to the server installation's news posting software, 1114 which is not part of this specification. 1116 10.3.1.1 Responses 1118 240 article received ok 1119 340 send article to be posted. End with . 1120 440 posting not allowed 1121 441 posting failed 1123 10.3.2 IHAVE 1125 IHAVE 1126 The IHAVE command informs the server that the client has an 1127 article whose id is . If the server desires a copy 1128 of that article, it MUST return a response instructing the 1129 client to send the entire article. If the server does not want 1130 the article (if, for example, the server already has a copy of 1131 it), a response indicating that the article is not wanted MUST 1132 be returned. 1134 If transmission of the article is requested, the client MUST 1135 send the entire article, including header and body, in the 1136 manner specified for text transmission from the server. The 1137 server MUST return a response code indicating success or 1138 failure of the transferal of the article. 1140 This function differs from the POST command in that it is 1141 intended for use in transferring already-posted articles 1142 between hosts. Normally it will not be used when the client is 1143 a personal news reading program. In particular, this function 1144 will invoke the server's news posting program with the 1145 appropriate settings (flags, options, etc.) to indicate that 1146 the forthcoming article is being forwarded from another host. 1148 However, the server may elect not to post or forward the 1149 article if after further examination of the article it deems 1150 it inappropriate to do so. Reasons for such subsequent 1151 rejection of an article may include such problems as 1152 inappropriate news groups or distributions, disk space 1153 limitations, article lengths, garbled headers, and the like. 1154 These are typically restrictions enforced by the server host's 1155 news software and not necessarily the NNTP server itself. 1157 10.3.2.1 Responses 1159 235 article transferred ok 1160 335 send article to be transferred. End with . 1162 435 article not wanted - do not send it 1163 436 transfer failed - try again later 1164 437 article rejected - do not try again 1166 Because some host news posting software may not be able to 1167 immediately render status on the whether an article is 1168 inappropriate for posting or forwarding, an NNTP server MAY 1169 acknowledge the successful transfer of the article and later 1170 silently discard it. Thus an NNTP server may return the 235 1171 acknowledgment code and later discard the received article. 1173 10.4 The LIST Keyword 1174 10.4.1 LIST 1176 LIST [ACTIVE [wildmat]] 1178 The response to the LIST keyword with no parameters returns a 1179 list of valid news groups and associated information. Each 1180 news group is sent as a line of text in the following format: 1182 group last first status 1184 where is the name of the news group, is the 1185 number of the last known article currently in that news group, 1186 is the number of the first article currently in the 1187 news group, and indicates the current status of the 1188 group on this server. Typically, the will be consist 1189 of the US-ASCII character `y' where posting is permitted, `n' 1190 where posting is not permitted and `m' where postings will be 1191 forwarded to the news group moderator by the news server. 1192 Other status strings may exist. The definition of these other 1193 values are covered in other specifications. 1195 The and fields will always be numeric. They 1196 may have leading zeros. If the field evaluates to less 1197 than the field, there are no articles currently on 1198 file in the news group. 1200 Note that posting may still be prohibited to a client although 1201 the LIST command indicates that posting is permitted to a 1202 particular news group. See the POST command for an explanation 1203 of client prohibitions. The posting flag exists for each news 1204 group because some news groups are moderated or are digests, 1205 and therefore cannot be posted to; that is, articles posted to 1206 them must be mailed to a moderator who will post them for the 1207 original poster. This is independent of the posting 1208 permission granted to a client by the NNTP server. 1210 Please note that an empty list (i.e., the text body returned 1211 by this command consists only of the terminating period) is a 1212 possible valid response, and indicates that there are 1213 currently no valid news groups. 1215 If the optional matching parameter is specified, the list is 1216 limited to only the groups that match the pattern. 1218 Specifying a single group is usually very efficient for the 1219 server, and multiple groups may be specified by using wildmat 1220 patterns (described in section 5), not regular expressions. 1222 10.4.1.1 Responses 1223 215 list of news groups follows 1225 10.4.2 LIST ACTIVE.TIMES 1227 LIST ACTIVE.TIMES [wildmat] 1229 The active.times file is maintained by some news transports 1230 systems to contain information about the when and who created 1231 a particular news group. The format of this file generally 1232 includes three fields. The first field is the name of the news 1233 group. The second is the time when this group was created on 1234 this news server measured in seconds since January 1, 1970. 1235 The third is the email address of the entity that created the 1236 news group. When executed, the information is displayed 1237 following the 215 response. When display is completed, the 1238 server will send a period on a line by itself. If the 1239 information is not available, the server will return the 503 1240 error response. 1242 If the optional matching parameter is specified, the list is 1243 limited to only the groups that match the pattern. 1245 Specifying a single group is usually very efficient for the 1246 server, and multiple groups may be specified by using wildmat 1247 patterns (described in section 5), not regular expression 1249 10.4.2.1 Responses 1251 215 information follows 1252 503 program error, function not performed 1254 10.4.3 LIST DISTRIBUTIONS 1256 LIST DISTRIBUTIONS 1258 The distributions file is maintained by some news transport 1259 systems to contain information about valid values for the 1260 Distribution: line in a news article header and about what the 1261 values mean. Each line contains two fields, the value and a 1262 short explanation on the meaning of the value. When executed, 1263 the information is displayed following the 215 response. When 1264 display is completed, the server will send a period on a line 1265 by itself. If the information is not available, the server 1266 will return the 503 error response. 1268 10.4.3.1 Responses 1270 215 information follows 1271 503 program error, function not performed 1273 10.4.4 LIST DISTRIB.PATS 1275 LIST DISTRIB.PATS 1276 The distrib.pats file is maintained by some news transport 1277 systems to contain default values for the Distribution: line 1278 in a news article header when posting to particular news 1279 groups. This information could be used to provide a default 1280 value for the Distribution: line in the header when posting an 1281 article. The information returned contains three fields 1282 separated by colons. The first column is a weight. The second 1283 is a group name or a wildmat pattern that can be used to match 1284 a group name. The third is the value of the Distribution: 1285 line that should be used when the group name matches and the 1286 weight value is the highest. All this processing is done by 1287 the news posting client and not by the server itself. The 1288 server provides this information to the client for it to use 1289 or ignore as it chooses. When executed, the information is 1290 displayed following the 215 response. When display is 1291 completed, the server will send a period on a line by itself. 1292 If the information is not available, the server will return 1293 the 503 error response. 1295 10.4.4.1 Responses 1297 215 information follows 1298 503 program error, function not performed 1300 10.4.5 LIST NEWSGROUPS 1302 LIST NEWSGROUPS [wildmat] 1304 The newsgroups file is maintained by some news transport 1305 systems to contain the name of each news group that is 1306 active on the server and a short description about the 1307 purpose of each news group. Each line in the file contains 1308 two fields, the news group name and a short explanation of 1309 the purpose of that news group. When executed, the 1310 information is displayed following the 215 response. When 1311 display is completed, the server will send a period on a 1312 line by itself. If the information is not available, the 1313 server will return the 503 response. If the optional 1314 matching parameter is specified, the list is limited to only 1315 the groups that match the pattern (no matching is done on 1316 the group descriptions). Specifying a single group is 1317 usually very efficient for the server, and multiple groups 1318 may be specified by using wildmat patterns (see section 5), 1319 not regular expressions. If nothing is matched an empty list 1320 is returned, not an error. 1322 10.4.5.1 Responses 1324 215 information follows 1325 503 program error, function not performed 1327 10.4.6 LIST OVERVIEW.FMT 1329 LIST OVERVIEW.FMT 1331 The overview.fmt file is maintained by some news transport 1332 systems to contain the order in which header information is 1333 stored in the overview databases for each news group. When 1334 executed, news article header fields are displayed one line at 1335 a time in the order in which they are stored in the overview 1336 database[8] following the 215 response. When display is 1337 completed, the server will send a period on a line by itself. 1338 If the information is not available, the server will return 1339 the 503 response. 1341 Please note that if the header has the word "full" (without 1342 quotes) after the colon, the header's name is prepended to its 1343 field in the output returned by the server. 1345 10.4.6.1 Responses 1347 215 information follows 1348 503 program error, function not performed 1350 10.4.7 LIST SUBSCRIPTIONS 1352 LIST SUBSCRIPTIONS 1354 This command is used to get a default subscription list for 1355 new users of this server. The order of groups is significant. 1357 When this list is available, it is preceded by the 215 1358 response and followed by a period on a line by itself. When 1359 this list is not available, the server returns a 503 response 1360 code. 1362 10.4.7.1 Responses 1364 215 information follows 1365 503 program error, function not performed 1367 10.4.8 LISTGROUP 1369 LISTGROUP [ggg] 1371 The LISTGROUP command is used to get a listing of all the 1372 article numbers in a particular news group. 1374 The optional parameter ggg is the name of the news group to 1375 be selected (e.g. "news.software.b"). A list of valid news 1376 groups may be obtained from the LIST command. If no group is 1377 specified, the current group is used as the default 1378 argument. 1380 The successful selection response will be a list of the 1381 article numbers in the group followed by a period on a line 1382 by itself. 1384 When a valid group is selected by means of this command, the 1385 internally maintained "current article pointer" MUST be set 1386 to the first article in the group. If an invalid group is 1387 specified, the previously selected group and article remain 1388 selected. If an empty news group is selected, the "current 1389 article pointer" may be in an indeterminate state and should 1390 not be used. 1392 The group name MUST match a news group obtained from the 1393 LIST command or an error will result, else the server will 1394 response with the 411 error code. 1396 10.4.8.1 Responses 1398 211 list of article numbers follow 1399 411 No such group 1400 412 Not currently in news group 1402 10.4.9 OVER 1404 OVER [range] 1406 The OVER command returns information from the overview 1407 database for the article(s) specified. The information 1408 returned in the response to this command can be used by 1409 clients to follow discussion threads. 1411 The optional range argument may be any of the following: 1413 . an article number 1414 . an article number followed by a dash to indicate all following 1415 . an article number followed by a dash followed by another 1416 article number 1417 If no argument is specified, then information from the current 1418 article is displayed. Successful responses start with a 224 1419 response followed by the overview information for all matched 1420 messages. Once the output is complete, a period is sent on a 1421 line by itself. If no argument is specified, the information 1422 for the current article is returned. A news group must have 1423 been selected earlier, else a 412 error response is returned. 1424 If no articles are in the range specified, the server returns 1425 a 420 error response. A 502 response will be returned if the 1426 client only has permission to transfer articles. 1428 Each line of output MUST be formatted with the article number, 1429 followed by each of the headers in the overview database or 1430 the article itself (when the data is not available in the 1431 overview database) for that article separated by a US-ASCII 1432 tab character. The sequence of fields must be in this order: 1433 subject, author, date, message-id, references, byte count, and 1434 line count. Other optional fields may follow line count. These 1435 fields are specified by examining the response to the LIST 1436 OVERVIEW.FMT command. Where no data exists, a null field must 1437 be provided (i.e. the output will have two tab characters 1438 adjacent to each other). Servers should not output fields for 1439 articles that have been removed since the overview database 1440 was created. 1442 Note that all US-ASCII tab characters in any header data that 1443 is returned will be converted to a single US-ASCII space 1444 character. A contiguous sequence of US-ASCII non-printing 1445 characters will be compressed to a single US-ASCII space 1446 character in any output response. 1448 10.4.9.1 Responses 1450 224 Overview information follows 1451 412 No news group current selected 1452 420 No article(s) selected 1453 502 no permission 1455 10.4.10 PAT 1457 PAT header range| [pat [pat...]] 1459 The PAT command is used to retrieve specific headers from 1460 specific articles, based on pattern matching on the contents 1461 of the header. 1463 The required header parameter is the name of a header line 1464 (e.g. "subject") in a news group article. See RFC-1036 for a 1465 list of valid header lines. The required range argument may be 1466 any of the following: 1468 . an article number 1469 . an article number followed by a dash to indicate all following 1470 . an article number followed by a dash followed by another 1471 article number. 1472 The required message-id argument indicates a specific article. 1473 The range and message-id arguments are mutually exclusive. If 1474 there are additional arguments, they are joined together 1475 separated by a single space to form one complete pattern. If 1476 there are no additional arguments, a wildmat "*" is the 1477 default. Successful responses start with a 221 response 1478 followed by article number, an US-ASCII space, and the header 1479 from that message in which the pattern matched the contents of 1480 the specified header line. A valid response includes an empty 1481 list (indicating that there was no matches). Once the output 1482 is complete, a period is sent on a line by itself. If the 1483 optional argument is a message-id and no such article exists, 1484 the 430 error response shall be returned. A 502 response shall 1485 be returned if the client only has permission to transfer 1486 articles. 1488 10.4.10.1 Responses 1490 221 Header follows 1491 430 no such article 1492 502 no permission 1494 11. The CONCLUSION Step 1496 11.1 QUIT 1498 QUIT 1500 The server process MUST acknowledge the QUIT command and then 1501 closes the connection to the client. This is the preferred 1502 method for a client to indicate that it has finished all its 1503 transactions with the NNTP server. 1505 If a client simply disconnects (or the connection times out or 1506 some other fault occurs), the server SHALL gracefully cease 1507 its attempts to service the client. 1509 11.1.1 Responses 1511 205 closing connection - goodbye! 1513 12. Other Keywords 1515 There are other Keywords that may be used at any time between 1516 the beginning of a session and its termination. Using these 1517 keywords do not alter any state information, but the response 1518 generated from the use of these keywords may provide useful 1519 information to clients that use them. 1521 12.1 DATE 1523 DATE 1525 This command exists to help clients find out the current time 1526 from the server's perspective. This command should not be 1527 used as a substitute for NTP[9], but to provide information 1528 that might be useful when using the NEWNEWS command (see 1529 section 12.4). 1531 This command returns a one-line response code of 111 followed 1532 by the UTC (or GMT) date and time on the server in the form 1533 YYYYMMDDhhmmss. 1535 12.1.1 Responses 1537 111 YYYYMMDDhhmmss 1539 12.2 The HELP Command 1541 HELP 1543 This command provides a short summary of commands that are 1544 understood by this implementation of the server. The help text 1545 will be presented as a textual response terminated by a single 1546 period on a line by itself. 1548 This text is not guaranteed to be in any particular format and 1549 shall not be used by clients as a replacement for the LIST 1550 EXTENSIONS command described in section 8.1. 1552 12.2.1 Responses 1554 100 help text follows 1556 12.3 NEWGROUPS 1558 NEWGROUPS date time [GMT|UTC] [] 1560 A list of newsgroups created since MUST be 1561 listed in the same format as the LIST command. 1563 The date is sent as 6 or 8 digits in the format [XX]YYMMDD, 1564 where XX is the first two digits of the year, YY is the last 1565 two digits of the year, MM is the two digits of the month 1566 (with leading zero, if appropriate), and DD is the day of the 1567 month (with leading zero, if appropriate). If the first two 1568 digits of the year are not specified, the year is to be taken 1569 from the current century if YY is smaller than or equal to the 1570 current year, otherwise the year is from the previous century. 1572 Time must also be specified. It must be as 6 digits HHMMSS 1573 with HH being hours in the 24-hour clock 00-23, MM minutes 00- 1574 59, and SS seconds 00-60, which allows for leap seconds. The 1575 tokens "GMT" and "UTC" specifies that the date and time are 1576 given in UTC. If the tokens "GMT" and "UTC" are omitted then 1577 the date and time are specified in the server's local 1578 timezone. Note that there is no way within this specification 1579 of NNTP to establish the server's local timezone. 1581 The optional parameter "distributions" is a list of 1582 distribution groups, enclosed in angle brackets. If 1583 specified, the distribution portion of an article's header 1584 will be examined for a match with the distribution categories 1585 listed, and only those articles which have a distribution in 1586 the list will be listed. If more than one distribution is to 1587 be supplied, they must be separated by commas within the angle 1588 brackets. 1590 Note that an empty list (i.e., the text body returned by this 1591 command consists only of the terminating period) is a possible 1592 valid response, and indicates that there are currently no new 1593 newsgroups. 1595 Clients SHOULD make all queries using GMT/UTC time when 1596 possible. 1598 12.3.1 Responses 1600 231 list of new newsgroups follows 1602 12.4 NEWNEWS 1604 NEWNEWS newsgroups date time [GMT] [] 1606 A list of message-ids of articles posted or received to the 1607 specified news group since "date" will be listed. The format 1608 of the listing will be one message-id per line, as though text 1609 were being sent. A single line consisting solely of one 1610 period followed by CR-LF will terminate the list. 1612 Date and time are in the same format as the NEWGROUPS command. 1613 The newsgroups parameter must be in wildmat format and may 1614 consist of multiple wildmat constructs separated by an US- 1615 ASCII comma character. 1617 The optional parameter "distributions" is a list of 1618 distribution groups, enclosed in angle brackets. If 1619 specified, the distribution portion of an article's header 1620 will be examined for a match with the distribution categories 1621 listed, and only those articles which have a distribution in 1622 the list will be listed. If more than one distribution is to 1623 be supplied, they must be separated by commas within the angle 1624 brackets. 1626 The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to 1627 distribute news is discussed in an earlier part of this 1628 document. 1630 Note that an empty list (i.e., the text body returned by this 1631 command consists only of the terminating period) is a possible 1632 valid response, and indicates that there is currently no new 1633 news. 1635 Clients SHOULD make all queries in GMT/UTC time when possible. 1637 12.4.1 Responses 1639 230 list of new articles by message-id follows 1641 13. Framework for NNTP Extensions 1643 Although NNTP is widely and robustly deployed, some parts of 1644 the Internet community might wish to extend the NNTP service. 1645 This memo defines a means whereby an extended NNTP client may 1646 query the server to determine the service extensions that it 1647 supports. 1649 It must be emphasized that any extension to the NNTP service 1650 should not be considered lightly. NNTP's strength comes 1651 primarily from its simplicity. Experience with many protocols 1652 has shown that: 1654 Protocols with few options tend towards ubiquity, whilst 1655 protocols with many options tend towards obscurity. 1657 This means that each and every extension, regardless of its 1658 benefits, must be carefully scrutinized with respect to its 1659 implementation, deployment, and interoperability costs. In 1660 many cases, the cost of extending the NNTP service will likely 1661 outweigh the benefit. 1663 Given this environment, the framework for the extensions 1664 described in this memo consists of: 1666 a) a mechanism for clients to determine a server's available 1667 extensions 1668 b) a registry of NNTP service extensions 1670 The LIST EXTENSIONS command is described in section 8.1 of 1671 this memo and is the mechanism for clients to use to determine 1672 what extensions are available for client use. 1674 The IANA shall maintain a registry of NNTP service extensions. 1676 Associated with each such extension is a corresponding NNTP 1677 keyword value. Each service extension registered with the IANA 1678 MUST be defined in an RFC. Such RFCs either must be on the 1679 standards-track or must define an IESG-approved experimental 1680 protocol. The definition must include: 1682 . the textual name of the NNTP service extension; 1683 . the label that is returned by LIST EXTENSIONS that would 1684 indicate to the client that the server supports this 1685 particular extension. 1686 . any new NNTP keywords associated with the extension; 1687 . the syntax and possible values of parameters associated with 1688 the new NNTP keywords; 1689 . any new parameters the extension associates with any other 1690 pre-existing NNTP verbs; 1691 . how support for the extension affects the behavior of a server 1692 and client NNTP; and, 1693 . the increment by which the extension is increasing the maximum 1694 length of the any commands over that specified in this 1695 document. 1696 In addition, any NNTP keyword value that starts with an upper 1697 or lower case "X" refers to a local NNTP service extension, 1698 which is used through bilateral, rather than standardized, 1699 agreement. Keywords beginning with "X" may not be used in a 1700 registered service extension. 1702 Any keyword values presented in the NNTP response that do not 1703 begin with "X" must correspond to a standard, standards-track, 1704 or IESG-approved experimental NNTP service extension 1705 registered with IANA. A conforming server must not offer non 1706 "X" prefixed keyword values that are not described in a 1707 registered extension. 1709 Additional verbs are bound by the same rules as NNTP keywords; 1710 specifically, verbs beginning with "X" are local extensions 1711 that may not be registered or standardized and verbs not 1712 beginning with "X" must always be registered. 1714 13.1 Initial IANA Registry 1716 The IANA's initial registry of NNTP service extensions 1717 consists of these entries: 1719 Service Extension NNTP Extension Label Added Behavior 1721 Overview Support OVER Defined in this 1722 document 1724 Specific Article LISTGROUP Defined in this 1725 Numbers document 1726 Simple AUTHINFO Defined in this 1727 Identification and document 1728 Authentication 1730 Generic AUTHINFO-GENERIC Defined in this 1731 Identification and document 1732 Authentication 1734 Header Pattern PAT Defined in this 1735 Matching document 1737 14. Augmented BNF[10] Syntax for NNTP Commands 1739 This syntax defines the non-terminal "command". The non-terminal 1740 "parameter" is used for command parameters whose syntax is 1741 specified elsewhere. The syntax is in alphabetical order. Note 1742 that ABNF strings are case insensitive. 1744 article-command = "ARTICLE" [1*WSP (msg-id / article-number)] 1745 *WSP CRLF 1746 article-number = 1*16DIGIT 1747 augument = parameter ; excluding sequence ".." 1748 authenticator = parameter ; excluding sequence ".." 1749 authinfo-generic-command = "AUTHINFO" 1*WSP "GENERIC" 1*WSP 1750 authenticator *(1*WSP argument) *WSP CRLF 1751 authinfo-pass-command = "AUTHINFO" 1*WSP "PASS" 1*WSP password 1752 *WSP CRLF 1753 authinfo-user-command = "AUTHINFO" 1*WSP "USER" 1*WSP username 1754 *WSP CRLF 1755 body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP 1756 CRLF 1757 command = article-command / 1758 authinfo-generic-command / 1759 authinfo-pass-command / 1760 authinfo-user-command / 1761 body-command / 1762 date-command / 1763 group-command / 1764 head-command / 1765 help-command / 1766 ihave-command / 1767 last-command / 1768 list-active-times-command / 1769 list-distrib-pats-command / 1770 list-distributions-command / 1771 list-extensions-command / 1772 list-newsgroups-command / 1773 list-overview-fmt-command / 1774 list-subscriptions-command / 1775 list-command / 1776 listgroup-command / 1777 mode-reader-command / 1778 newgroups-command / 1779 newnews-command / 1780 next-command / 1781 over-command / 1782 pat-command / 1783 post-command / 1784 quit-command / 1785 stat-command 1786 CR = %x0D 1787 CRLF = CR LF 1788 date-command = "DATE" *WSP CRLF 1789 date = 6*8DIGIT 1790 DIGIT = %x30-39 1791 distribution = parameter 1792 group-command = "GROUP" 1*WSP newsgroup *WSP CRLF 1793 head-command = "HEAD" [1*WSP (msg-id / article-number)] *WSP 1794 CRLF 1795 header = parameter 1796 help-command = "HELP" *WSP CRLF 1797 HT = %x09 1798 ihave-command = "IHAVE" 1*WSP msg-id *WSP CRLF 1799 last-command = "LAST" *WSP CRLF 1800 LF = %x0A 1801 list-active-times-command = "LIST" 1*WSP "ACTIVE.TIMES" 1802 [1*WSP wildmat] *WSP CRLF 1803 list-command = "LIST" [1*WSP "ACTIVE" [1*WSP wildmat]] *WSP 1804 CRLF 1805 list-distrib-pats-command = "LIST" 1*WSP "DISTRIB.PATS" *WSP 1806 CRLF 1807 list-distributions-command = "LIST" 1*WSP "DISTRIBUTIONS" *WSP 1808 CRLF 1809 list-extensions-command = "LIST" 1*WSP "EXTENSIONS" *WSP CRLF 1810 list-newsgroups-command = "LIST" 1*WSP "NEWSGROUPS" [1*WSP 1811 wildmat] 1812 *WSP CRLF 1813 list-overview-fmt-command = "LIST" 1*WSP "OVERVIEW.FMT" *WSP 1814 CRLF 1815 list-subscriptions-command = "LIST" 1*WSP "SUBSCRIPTIONS" *WSP 1816 CRLF 1817 listgroup-command = "LISTGROUP" [1*WSP newsgroup] *WSP CRLF 1818 mode-reader-command = "MODE" 1*WSP "READER" *WSP CRLF 1819 msg-id = 1820 newgroups-command = "NEWGROUPS" 1*WSP date 1*WSP time [1*WSP 1821 "GMT"/"UTC"][1*WSP "<" distribution *("," distribution) 1822 ">"] *WSP CRLF 1823 newnews-command = "NEWNEWS" 1*WSP newsgroup *("," newsgroup) 1824 1*WSP date 1*WSP time [1*WSP "GMT"/"UTC"] 1825 [1*WSP "<" distribution *("," distribution) ">"] 1826 *WSP CRLF 1827 newsgroup = parameter 1828 next-command = "NEXT" *WSP CRLF 1829 over-command = "OVER" [1*WSP range] *WSP CRLF 1830 parameter = 1*(%x21-FF) ; generic command parameter 1831 password = parameter 1832 pat-command = "PAT" 1*WSP header 1*WSP (range / msg-id) 1833 *(1*WSP wildmat) *WSP CRLF 1834 post-command = "POST" *WSP CRLF 1835 quit-command = "QUIT" *WSP CRLF 1836 range = article-number ["-" [article-number]] 1837 SP = %x20 1838 stat-command = "STAT" [1*WSP (msg-id / article-number)] *WSP 1839 CRLF 1840 time = 6DIGIT 1841 username = parameter 1842 UTF-8-non-ascii = %xC0-FF 1*(%x80-BF) ; UTF-8 encoding of non- 1843 ASCII character 1844 wildmat = 1*("*" / "?" / wildmat-exact / wildmat-set / 1845 "\" (%x21-7F / UTF-8-non-ascii)) 1846 wildmat-exact = %x21-29 / %x2B-3E / %x40-5A / %x5D-7F / UTF-8- 1847 non-ascii 1848 ; exclude space * ? [ \ 1849 wildmat-non-hyphen = %x21-2C / %x2E-7F / UTF-8-non-ascii ; 1850 exclude space - 1851 wildmat-set = "[" ["^"] ["]" / "-"] *(wildmat-non-hyphen ["-" 1852 WSP = SP / HT 1854 15. Security Considerations 1856 The use of the AUTHINFO is optional. This command as 1857 documented has a number of security implications. In the 1858 original form, all passwords are passed in plain text and 1859 could be discovered by various forms of network or system 1860 surveillance. The AUTHINFO GENERIC command has the potential 1861 for the same problems if a mechanism is used that also passes 1862 clear text passwords. RFC 1731 discusses these issues in 1863 greater detail. 1865 16. References 1867 1 Kantor, B and P. Lapsley, "Network News Transfer Protocol", 1868 RFC-977, U.C. San Diego and U.C. Berkeley. 1870 2 Yergeau, F., "UTF-8, a transformation format of Unicode and 1871 ISO 10646", RFC 2044, Alis Technologies. 1873 3 Coded Character Set-7-bit American Standard Code for 1874 Information Interchange, ANSI x3.4-1986. 1876 4 Bradner, Scott, "Key words for use in RFCs to Indicate 1877 Requirement Levels", RFC-2119, Harvard University. 1879 5 Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 1880 distribution, UUNET Technologies, Revision 1.10, April, 1992. 1882 6 Horton, M.R. and R. Adams, "Standard for interchange of 1883 USENET messages", RFC-1036, AT&T Bell Laboratories and Center 1884 for Seismic Studies, December, 1987. 1886 7 Meyers, J, "IMAP4 Authentication Mechanisms", RFC-1731, 1887 Carnegie Mellon, December, 1994. 1889 8 Robertson, Rob, "FAQ: Overview database / NOV General 1890 Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq- 1891 nov.Z, January, 1995. 1893 9 Mills, David L., "Network Time Protocol (Version 3), 1894 Specification, Implementation and Analysis", RFC-1305, 1895 University of Delaware, March 1992. 1897 10 Crocker, D. and Overell, P., "Augmented BNF for Syntax 1898 Specifications: ABNF", RFC-2234, Internet Mail Consortium and 1899 Demon Internet, Ltd. 1901 17. Notes 1903 DEC is a registered trademark of Digital Equipment 1904 Corporation. 1906 UNIX is a registered trademark of the X/Open Consortium. 1908 VMS is a registered trademark of Digital Equipment 1909 Corporation. 1911 18. Acknowledgments 1913 The author acknowledges the original authors of NNTP as 1914 documented in RFC 977: Brian Kantor and Phil Lapsey. 1916 The author gratefully acknowledges the work of the NNTP 1917 committee chaired by Eliot Lear. The organization of this 1918 document was influenced by the last available draft from this 1919 working group. A special thanks to Eliot for generously 1920 providing the original machine readable sources for that 1921 document. 1923 The author gratefully acknowledges the work of the Marshall 1924 Rose & John G. Meyers in RFC 1939 and the work of the DRUMS 1925 working group, specifically RFC 1869, which is the basis of 1926 the NNTP extensions mechanism detailed in this document. 1928 The author gratefully acknowledges the comments and additional 1929 information provided by the following individuals in preparing 1930 one of the progenitors of this document: 1932 . Wayne Davison 1933 . Clive D.W. Feather 1934 . Chris Lewis 1935 . Tom Limoncelli 1936 . Eric Schnoebelen 1937 . Rich Salz 1939 This work was precipitated by the work of various newsreader 1940 authors and newsserver authors, which includes those listed 1941 below: 1943 . Rick Adams-Original author of the NNTP extensions to the RN 1944 newsreader and last maintainer of Bnews 1945 . Stan Barber-Original author of the NNTP extensions to the 1946 newsreaders that are part of Bnews. 1948 . Geoff Collyer-Original author of the OVERVIEW database 1949 proposal and one of the original authors of CNEWS 1950 . Dan Curry-Original author of the xvnews newsreader 1951 . Wayne Davision"Author of the first threading extensions to the 1952 RN newsreader (commonly called TRN). 1953 . Geoff Huston-Original author of ANU NEWS 1954 . Phil Lapsey-Original author of the UNIX reference 1955 implementation 1956 . Ian Lea-Former Maintainer of the TIN newsreader 1957 . Chris Lewis-First known implementor of the AUTHINFO GENERIC 1958 extension 1959 . Rich Salz-Original author of INN 1960 . Henry Spencer-One of the original authors of CNEWS 1961 . Kim Storm-Original author of the NN newsreader 1963 19. Author's Address 1965 Stan Barber 1966 P.O. Box 300481 1967 Houston, Texas, 77230 1968 Email: 1970 This document expires September 30, 1998.