idnits 2.17.1 draft-elie-nntp-list-additions-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC2980, but the abstract doesn't seem to directly say this. It does mention RFC2980 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2980, updated by this document, for RFC5378 checks: 1997-10-13) -- 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 13, 2010) is 5005 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: 'C' is mentioned on line 926, but not defined == Missing Reference: 'S' is mentioned on line 927, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Elie 3 (IETF) August 13, 2010 4 Internet-Draft 5 Updates: 2980, 3977 6 (if approved) 7 Intended status: Standards Track 8 Expires: February 14, 2011 10 Network News Transfer Protocol (NNTP) Additions to LIST Command 11 draft-elie-nntp-list-additions-05 13 Abstract 15 This document defines a set of enhancements to the Network News 16 Transfer Protocol (NNTP) that allows a client to request extended 17 information from NNTP servers regarding server status, policy, and 18 other aspects of local configuration. These enhancements are made as 19 new keywords to the existing LIST capability described in RFC 3977. 21 This memo updates and formalizes the LIST DISTRIBUTIONS and LIST 22 SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST 23 COUNTS, LIST MODERATORS and LIST MOTD commands, and specifies 24 additional values returned by the existing LIST ACTIVE command for 25 the status of a newsgroup. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 14, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 63 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 5 64 2. New LIST Variants . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. Advertising the New LIST Variants . . . . . . . . . . . . 5 66 2.2. LIST COUNTS . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.3. LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . . 9 71 2.3.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.3.2. Description . . . . . . . . . . . . . . . . . . . . . 9 73 2.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 10 74 2.4. LIST MODERATORS . . . . . . . . . . . . . . . . . . . . . 11 75 2.4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 11 76 2.4.2. Description . . . . . . . . . . . . . . . . . . . . . 11 77 2.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 78 2.5. LIST MOTD . . . . . . . . . . . . . . . . . . . . . . . . 13 79 2.5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 13 80 2.5.2. Description . . . . . . . . . . . . . . . . . . . . . 13 81 2.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14 82 2.6. LIST SUBSCRIPTIONS . . . . . . . . . . . . . . . . . . . . 15 83 2.6.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 84 2.6.2. Description . . . . . . . . . . . . . . . . . . . . . 15 85 2.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 16 86 3. Additions to LIST ACTIVE . . . . . . . . . . . . . . . . . . . 17 87 3.1. New status fields . . . . . . . . . . . . . . . . . . . . 17 88 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 4. Augmented BNF Syntax for These Additions to the LIST 90 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 22 93 5. Internationalization Considerations . . . . . . . . . . . . . 23 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 100 Appendix A. Document History (to be removed by RFC Editor 101 before publication) . . . . . . . . . . . . . . . . 26 102 Appendix A.1. Changes from -04 . . . . . . . . . . . . . . . . . . 26 103 Appendix A.2. Changes from -03 . . . . . . . . . . . . . . . . . . 27 104 Appendix A.3. Changes from -02 . . . . . . . . . . . . . . . . . . 27 105 Appendix A.4. Changes from -01 . . . . . . . . . . . . . . . . . . 28 106 Appendix A.5. Changes from -00 . . . . . . . . . . . . . . . . . . 28 108 1. Introduction 110 The NNTP specification [RFC3977] defines the LIST capability and a 111 few keywords which can be used with that command: ACTIVE, 112 ACTIVE.TIMES, DISTRIB.PATS, HEADERS, NEWSGROUPS, and OVERVIEW.FMT. 113 Other variants of the LIST command are in use, but with limited or 114 absent documentation. These variants are formalized in this 115 document. 117 The DISTRIBUTIONS and SUBSCRIPTIONS variants were originally 118 documented in [RFC2980]. The LIST DISTRIBUTIONS command is sent by a 119 news client to obtain a list of relevant distributions known by a 120 news server along with their descriptions. The LIST SUBSCRIPTIONS 121 command is sent by a news client when first connecting to a news 122 server so as to obtain a list of recommended newsgroups available on 123 it. Both of these commands are intended to be used in place of hard- 124 coding news clients to use specific distributions or look for 125 specific default newsgroups. 127 The MOTD variant was originally documented in 128 [I-D.draft-hernacki-nntplist] (which also describes the SUBSCRIPTIONS 129 variant). The LIST MOTD command is sent by a news client to obtain a 130 "message of the day" from the server administrator regarding the 131 current state of a news server. 133 The COUNTS and MODERATORS variants have not been documented before. 134 The LIST COUNTS command is similar to LIST ACTIVE, except that it 135 also returns an estimated number of articles in each newsgroup. The 136 LIST MODERATORS command is sent by a news client to obtain a list of 137 associations between a moderated newsgroup and its submission address 138 template. 140 The ACTIVE variant was formalized in [RFC3977] but the meanings of 141 only three status fields in LIST ACTIVE responses have been 142 specified: "y", "n", and "m". These status field values are 143 particularly useful for readers since they describe local posting 144 rights. However, several other values are in use that are primarily 145 useful for peers as they mainly describe how remote articles coming 146 from peers are locally handled by a given news server. This memo 147 defines three other values for status field in LIST ACTIVE responses: 148 "x", "j", and "=" followed by the name of a newsgroup. 150 This specification should be read in conjunction with the NNTP base 151 specification [RFC3977]. Except where specifically stated otherwise, 152 in the case of a conflict between these two documents, [RFC3977] 153 takes precedence. 155 1.1. Conventions Used in This Document 157 The notational conventions used in this document are the same as 158 those in [RFC3977], and any term not defined in this document has the 159 same meaning as it does in that one. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 When a hexadecimal correspondence is given to an octet in this 166 document, the value is in US-ASCII [ASCII] (for instance ".", noted 167 %x2E). 169 In the examples, commands from the client are indicated with [C], and 170 responses from the server are indicated with [S]. The client is the 171 initiator of the NNTP connection; the server is the other endpoint. 173 1.2. Author's Note 175 Please write the first letter of "Elie" with an acute accent wherever 176 possible -- it is U+00C9, that is to say "É" in XML. 178 2. New LIST Variants 180 The LIST capability is defined in Section 7.6 of [RFC3977]. It 181 allows the server to provide useful information to the client in 182 multi-line blocks. 184 This document provides five new keywords to the LIST capability: 185 COUNTS, DISTRIBUTIONS, MODERATORS, MOTD, and SUBSCRIPTIONS. 187 Each keyword is OPTIONAL and corresponds to the same-named variant of 188 the LIST command. 190 2.1. Advertising the New LIST Variants 192 When a news server implements a variant of the LIST command as 193 described in this specification, it advertises the corresponding 194 feature in the LIST capability. Where one of these new LIST keywords 195 is advertised, it MUST have the meaning given in this specification. 197 For instance, if a news server implements the SUBSCRIPTIONS variant, 198 it will add the SUBSCRIPTIONS keyword to the LIST capability in 199 response to the CAPABILITIES command (see Section 5.2 of [RFC3977]): 201 [C] CAPABILITIES 202 [S] 101 Capability list: 203 [S] VERSION 2 204 [S] READER 205 [S] LIST ACTIVE NEWSGROUPS SUBSCRIPTIONS 206 [S] . 207 [C] LIST SUBSCRIPTIONS 208 [S] 215 List of recommended newsgroups follows 209 [S] local.welcome 210 [S] local.test 211 [S] news.newusers.questions 212 [S] news.announce.newusers 213 [S] . 215 For each of the new LIST variants described in this specification, an 216 empty response can be sent to the client: 218 [C] LIST SUBSCRIPTIONS 219 [S] 215 List of recommended newsgroups follows 220 [S] . 222 This means that the information is maintained by the news server but 223 that it is voluntarily empty. Frequently, the news server maintains 224 the information in a configuration file. This file can be empty or 225 contain only commented or blank lines, indicating a voluntary absence 226 of information. 228 When the news server software implements one of these LIST variants 229 but a particular server does not maintain the information (for 230 instance when the configuration file does not exist), the 503 231 response code MUST be returned: 233 [C] LIST SUBSCRIPTIONS 234 [S] 503 No list of recommended newsgroups available 236 2.2. LIST COUNTS 238 2.2.1. Usage 240 Syntax 241 LIST COUNTS [wildmat] 243 Responses 244 215 List of newsgroups follows (multi-line) 246 Parameters 247 wildmat Groups of interest 249 2.2.2. Description 251 See Section 7.6.1 of [RFC3977] for general requirements of the LIST 252 command. 254 The LIST COUNTS command returns a list of valid newsgroups carried by 255 the news server along with associated information, the "counts list", 256 and is similar to LIST ACTIVE. 258 The information is returned as a multi-line data block following the 259 215 response code and contains one line per newsgroup. Each line of 260 this list MUST consist of five fields separated from each other by 261 one or more spaces (the usual practice is a single space) in the 262 following order: 264 o The name of the newsgroup. 266 o The reported high water mark for the group. 268 o The reported low water mark for the group. 270 o The estimated number of articles in the group. 272 o The current status of the group on this server. 274 The reported high and low water marks, and the estimated number of 275 articles are as described in the GROUP command (see Section 6.1.1 of 276 [RFC3977]), but note that they are in the opposite order to the 211 277 response to that command. The current status of the group is as 278 described in the LIST ACTIVE command (see Section 7.6.3 of [RFC3977], 279 as well as Section 2.2 of this document). Also note that, similarly 280 to the LIST ACTIVE command, TAB characters are not valid separators 281 for the LIST COUNTS command. 283 The order of newsgroups in the list is not significant. The server 284 need not consistently return the same order or the same results if 285 this command is used more than once in a session. 287 The same newsgroup SHOULD NOT appear twice in the output of this 288 command. 290 The counts list is newsgroup-based, and a wildmat MAY be specified, 291 in which case the response is limited to only the groups, if any, 292 whose names match the wildmat. If no wildmat is specified, the 293 server MUST include every newsgroup that the client is permitted to 294 select with the GROUP command (see Section 6.1.1 of [RFC3977]). 296 The counts list MAY be empty. If the server does not maintain the 297 information, a 503 response code MUST be returned. (However, note 298 that a news server that supports this command usually maintains the 299 information.) 301 The client MAY use LIST COUNTS in order to obtain an estimate of the 302 number of articles in every newsgroup the server carries, which 303 enables it to provide the end user with this information. This 304 provides a simpler mechanism for a client to obtain the estimated 305 number of articles in newsgroups, compared with a sequence of 306 individual GROUP commands. 308 2.2.3. Examples 310 Example of output with no argument: 312 [C] CAPABILITIES 313 [S] 101 Capability list: 314 [S] VERSION 2 315 [S] READER 316 [S] LIST ACTIVE COUNTS NEWSGROUPS 317 [S] . 318 [C] LIST COUNTS 319 [S] 215 List of newsgroups follows 320 [S] misc.test 3002322 3000234 1234 y 321 [S] comp.risks 442001 441099 742 m 322 [S] rec.food.drink.tea 221176 220685 351 y 323 [S] local.empty 7 8 0 y 324 [S] local.tea 2004 1504 301 y 325 [S] . 327 Example of output with a wildmat: 329 [C] LIST COUNTS *.tea,misc.*,!local.* 330 [S] 215 List of newsgroups follows 331 [S] misc.test 3002322 3000234 1234 y 332 [S] rec.food.drink.tea 221176 220685 351 y 333 [S] . 335 Example of output on an implementation that includes leading zeroes: 337 [C] LIST COUNTS 338 [S] 215 List of newsgroups follows 339 [S] misc.test 0003002322 0003000234 1234 y 340 [S] comp.risks 0000442001 0000441099 742 m 341 [S] rec.food.drink.tea 0000221176 0000220685 351 y 342 [S] local.empty 0000000007 0000000008 0 y 343 [S] local.tea 0000002004 0000001504 301 y 344 [S] . 346 The estimated number of articles usually does not start with leading 347 zeroes, but MAY have them. 349 2.3. LIST DISTRIBUTIONS 351 2.3.1. Usage 353 Syntax 354 LIST DISTRIBUTIONS 356 Responses 357 215 Distributions list follows (multi-line) 359 2.3.2. Description 361 See Section 7.6.1 of [RFC3977] for general requirements of the LIST 362 command. 364 A "distributions list" is maintained by some NNTP servers to contain 365 the name of each distribution that is known by the news server and a 366 short description about the meaning of the distribution. 367 Distributions are used by clients as potential values for the 368 Distribution header field body of a news article being posted (see 369 Section 3.2.4 of [RFC5536] for the definition of this header field). 371 The information is returned as a multi-line data block following the 372 215 response code and contains one line per distribution. Each line 373 of this list MUST consist of two fields separated from each other by 374 one or more space or TAB characters (the usual practice is a single 375 TAB). The first field is the name of the distribution, and the 376 second field is a short description of the distribution. There are 377 no leading or trailing whitespaces in a line. The description MAY 378 contain whitespaces. 380 The order of distributions in the list is not significant; the server 381 need not consistently return the same order or the same results if 382 this command is used more than once in a session. 384 The same distribution SHOULD NOT appear twice in the output of this 385 command. 387 The description MUST be in UTF-8 [RFC3629]. 389 The distributions list is not newsgroup-based, and an argument MUST 390 NOT be specified. Otherwise, a 501 response code MUST be returned. 392 The distributions list MAY be empty. If the server does not maintain 393 the information, a 503 response code MUST be returned. 395 The client MAY use this information to generate or supplement a list 396 of known distributions provided to the user. If the news server 397 implements the LIST DISTRIBUTIONS command, it SHOULD also implement 398 the LIST DISTRIB.PATS command (defined in Section 7.6.5 of [RFC3977]) 399 and describe in the distributions list all the distributions present 400 in the distrib.pats list so that the client can use both of these 401 commands jointly (naturally, the distributions list can also describe 402 distributions that are not present in the distrib.pats list). Note 403 that the two commands need not return distributions in the same 404 order. 406 2.3.3. Example 408 Example of a joint use of LIST DISTRIB.PATS and LIST DISTRIBUTIONS: 410 [C] CAPABILITIES 411 [S] 101 Capability list: 412 [S] VERSION 2 413 [S] READER 414 [S] LIST ACTIVE DISTRIB.PATS DISTRIBUTIONS NEWSGROUPS 415 [S] . 416 [C] LIST DISTRIB.PATS 417 [S] 215 Information follows 418 [S] 10:local.*:local 419 [S] 5:france.*:fr 420 [S] 20:local.here.*:thissite 421 [S] . 422 [C] LIST DISTRIBUTIONS 423 [S] 215 List of distributions follows 424 [S] fr Local to France. 425 [S] local Local to this news server. 426 [S] thissite Local to this site. 427 [S] usa Local to the United States of America. 428 [S] . 430 2.4. LIST MODERATORS 432 2.4.1. Usage 434 Syntax 435 LIST MODERATORS 437 Responses 438 215 Moderators list follows (multi-line) 440 2.4.2. Description 442 See Section 7.6.1 of [RFC3977] for general requirements of the LIST 443 command. 445 The "moderators list" is maintained by some NNTP servers to make 446 clients aware of how the news server will generate a submission 447 e-mail address when an article is locally posted to a moderated 448 newsgroup. 450 The information is returned as a multi-line data block following the 451 215 response code. Each line of this list MUST consist of two fields 452 separated from each other by a colon (":" or %x3A). The first field 453 is a wildmat (which may be a simple newsgroup name), and the second 454 field is the submission address template for newsgroups matching that 455 wildmat. There are no leading or trailing whitespaces in a line. 456 The submission template MAY contain colons (":"). 458 The submission template is essentially an e-mail address (see the 459 definition of "addr-spec" in Section 3.4.1 of [RFC5322]), except with 460 certain modifications. The case-sensitive string "%s" (%x25.73) MUST 461 occur either zero or one time in the template. If there is to be a 462 literal "%" in the submission address, it MUST be written as "%%" in 463 the template, even if not followed by an "s". The character "%" MUST 464 NOT occur in the submission template except as part of "%s" or "%%". 466 The order of lines in the moderators list is significant: the first 467 matching line is used. Consequently, specific patterns should be 468 listed before general patterns. Every moderated newsgroup name 469 SHOULD be matched by at least one line in the list; often this is 470 achieved by having a default pattern at the bottom, but other 471 approaches are acceptable and news server software MAY leave this up 472 to the server administrator rather than enforcing it 473 programmatically. 475 When an unapproved article is locally posted to a moderated newsgroup 476 (see Section 3.5.1 of [RFC5537]), the server generates a submission 477 address from the corresponding submission template (that is, the 478 second field of the first matching line in the moderators list) by 479 replacing the "%s", if present, with the name of the matching 480 newsgroup after each period ("." or %x2E) in the name is changed to a 481 dash ("-" or %x2D). In addition, any "%%" is changed back to "%". 482 The server then forwards the submitted article to moderator at the 483 resulting submission address. 485 NOTE: The creation and maintenance of submission addresses is 486 outside the scope of this specification. 488 The moderators list is not newsgroup-based, and an argument MUST NOT 489 be specified. Otherwise, a 501 response code MUST be returned. 491 The moderators list MAY be empty. If the server does not maintain 492 the information, a 503 response code MUST be returned, although these 493 situations should not occur if the news server is an injecting agent 494 that carries moderated newsgroups. 496 2.4.3. Example 498 Example of output: 500 [C] CAPABILITIES 501 [S] 101 Capability list: 502 [S] VERSION 2 503 [S] READER 504 [S] POST 505 [S] LIST ACTIVE MODERATORS NEWSGROUPS 506 [S] . 507 [C] LIST MODERATORS 508 [S] 215 List of submission address templates follows 509 [S] foo.bar:announce@example.com 510 [S] local.*:%s@localhost 511 [S] *:%s@moderators.example.com 512 [S] . 514 The following table describes a few examples associating a moderated 515 newsgroup and its submission address on a news server whose 516 moderators list is the one of the previous example: 518 +-----------------------------+-------------------------------------+ 519 | Name of the moderated | Submission address | 520 | newsgroup | | 521 +-----------------------------+-------------------------------------+ 522 | foo.bar | announce@example.com | 523 | local.test | local-test@localhost | 524 | alt.dev.null | alt-dev-null@moderators.example.com | 525 | alt.test-me | alt-test-me@moderators.example.com | 526 +-----------------------------+-------------------------------------+ 528 NOTE: When "%s" is used, periods are changed to dashes, and 529 dashes are left alone. This implies that two moderated newsgroups 530 whose names differ only by changing a period to a dash would have 531 the same submission address. Therefore, if a server carries such 532 moderated newsgroup pairs but posts should go to different 533 submission addresses, a "%s" pattern template cannot be used for 534 the moderation submission addresses for those groups, and explicit 535 entries without a pattern will be required. 537 Similarly, it is not recommended to use a "%s" pattern rule for 538 the moderation submission template for two moderated newsgroups 539 whose names differ only by the case of their characters, because 540 e-mail systems frequently treat the left-hand-side of e-mail 541 addresses as case-sensitive. See also Section 3.1.4 of [RFC5536] 542 and Section 7.2 of [I-D.ietf-usefor-useage] for the syntax of a 543 newsgroup name. 545 2.5. LIST MOTD 547 2.5.1. Usage 549 Syntax 550 LIST MOTD 552 Responses 553 215 Information follows (multi-line) 555 2.5.2. Description 557 See Section 7.6.1 of [RFC3977] for general requirements of the LIST 558 command. 560 The "motd" contains a "message of the day" relevant to the news 561 server. It is intended to provide notification and communication 562 between the news administrator and the news user. For instance, 563 notification of upcoming downtime or information about new facilities 564 available on the news server can be communicated via the LIST MOTD 565 command. 567 The information is returned as a multi-line data block following the 568 215 response code. This text is not guaranteed to be in any 569 particular format although, like all multi-line data blocks, it is 570 "dot-stuffed". 572 The server need not return the same information if this command is 573 used more than once in a session. It MAY indeed send a different 574 message of the day depending on the state of the session. For 575 instance, on a mode-switching news server, the information can be 576 different between its transit mode and its reader mode, or between an 577 authenticated session and an unauthenticated session. 579 The information MUST be in UTF-8 [RFC3629]. 581 The motd is not newsgroup-based, and an argument MUST NOT be 582 specified. Otherwise, a 501 response code MUST be returned. 584 The motd MAY be empty. If the server does not maintain the 585 information, a 503 response code MUST be returned. 587 It is up to the client to decide when and how to display this message 588 to the user. No timestamp or date of last modification is provided 589 programmatically, although the news administrator may include one in 590 the text of the motd. The client MAY cache a local copy or 591 fingerprint of the motd so that it can display the message to the 592 user only upon modification. If the client caches the information, 593 it MAY take into account only the motd obtained after reaching the 594 intended state of the session. Nonetheless, in case a privacy 595 extension is used, the client MUST NOT cache any motd obtained before 596 that extension took effect. 598 NOTE: Though the client MAY cache the results of this command, it 599 MUST NOT rely on the correctness of any cached results, whether 600 from earlier in the session or from a previous session. If the 601 motd is cached, the client SHOULD provide a way to force the 602 cached information to be refreshed. 604 2.5.3. Example 606 Example of output: 608 [C] CAPABILITIES 609 [S] 101 Capability list: 610 [S] VERSION 2 611 [S] READER 612 [S] LIST ACTIVE MOTD NEWSGROUPS 613 [S] . 614 [C] LIST MOTD 615 [S] 215 Message of the day follows 616 [S] Attention all users, 617 [S] 618 [S] This server will be down for scheduled upgrades on February, 1st. 619 [S] It should be back up by 8:00 a.m. February, 2nd. 620 [S] Any questions should be e-mailed to . 621 [S] 622 [S] Apologies for the disturbance. 623 [S] . 625 2.6. LIST SUBSCRIPTIONS 627 2.6.1. Usage 629 Syntax 630 LIST SUBSCRIPTIONS [wildmat] 632 Responses 633 215 Subscriptions list follows (multi-line) 635 Parameters 636 wildmat Groups of interest 638 2.6.2. Description 640 See Section 7.6.1 of [RFC3977] for general requirements of the LIST 641 command. 643 The "subscriptions list" is maintained by some NNTP servers to 644 provide the client with a list of recommended newsgroups. 646 The information is returned as a multi-line data block following the 647 215 response code. Each line of this list MUST consist of a 648 newsgroup name. There are no leading or trailing whitespaces in a 649 line. 651 The order of newsgroups in the list is significant: they are listed 652 by order of importance, the first newsgroup being the most important 653 to subscribe to. 655 The same newsgroup name SHOULD NOT appear twice in the output of this 656 command. The list SHOULD contain only newsgroups the news server 657 carries. 659 The subscriptions list is newsgroup-based, and a wildmat MAY be 660 specified, in which case the response is limited to only the groups, 661 if any, whose names match the wildmat. Note that the wildmat 662 argument is a new feature in this specification and servers that do 663 not support CAPABILITIES or do not advertise the SUBSCRIPTIONS 664 keyword in the LIST capability (and therefore do not conform to this 665 specification) are unlikely to support it. 667 The subscriptions list MAY be empty. If the server does not maintain 668 the information, a 503 response code MUST be returned. 670 The client MAY use this information the first time it connects to the 671 news server so as to initialize the list of default subscribed 672 newsgroups. This list should therefore contain groups intended for 673 new users on the news server or Usenet in general. For instance 674 newsgroups dedicated to testing, support, announcement, or FAQs. The 675 client MAY present the groups in the order of appearance in the list 676 to the user. When the subscriptions list is maintained and non 677 empty, the news client SHOULD use it, instead of a hard-coded default 678 list, if any. 680 2.6.3. Examples 682 Example of output with no argument: 684 [C] CAPABILITIES 685 [S] 101 Capability list: 686 [S] VERSION 2 687 [S] READER 688 [S] LIST ACTIVE NEWSGROUPS SUBSCRIPTIONS 689 [S] . 690 [C] LIST SUBSCRIPTIONS 691 [S] 215 List of recommended newsgroups follows 692 [S] local.welcome 693 [S] local.test 694 [S] news.newusers.questions 695 [S] news.announce.newusers 696 [S] . 698 Example of output with a wildmat: 700 [C] LIST SUBSCRIPTIONS local.* 701 [S] 215 List of recommended newsgroups follows 702 [S] local.welcome 703 [S] local.test 705 [S] . 707 3. Additions to LIST ACTIVE 709 This document specifies three new status fields that can be used in 710 the answers to LIST ACTIVE: "x", "j", and "=" followed by the name 711 of a newsgroup. 713 3.1. New status fields 715 The LIST ACTIVE command is defined in Section 7.6.3 of [RFC3977]. 716 The fourth field of each line of this list indicates the current 717 status of the newsgroup whose name is specified in the first field. 718 Three status are defined in [RFC3977]: 720 "y" Posting is permitted. 722 "n" Posting is not permitted. 724 "m" Postings will be forwarded to the newsgroup moderator. 726 This document defines three other case-sensitive status which can 727 also be used: 729 "x" Postings and articles from peers are not permitted. 731 "j" Only articles from peers are permitted; no articles are locally 732 filed. 734 "=other.group" Only articles from peers are permitted, and are filed 735 under the newsgroup named "other.group". 737 The server SHOULD use these values when these meanings are required 738 and MUST NOT use them with any other meaning. 740 A newsgroup with status "x" is a newsgroup with status "n" except 741 that articles from peers are not accepted. A newsgroup with status 742 "x" is considered as closed: no new articles will arrive in such a 743 group. On the contrary, articles from peers will arrive in a 744 newsgroup with status "n". Local postings are not allowed in a 745 newsgroup of either these two status. 747 A newsgroup with status "j" is a newsgroup with status "y" except 748 that (1) local postings are not accepted, (2) articles received from 749 a peer that are crossposted to one or more valid groups are filed 750 only into those valid groups, (3) articles received from a peer that 751 are not crossposted to any valid groups are not filed into any 752 newsgroup, but are still propagated to other peers, if appropriate. 754 NOTE: Instead of not filing at all an article posted to a 755 newsgroup with status "j", a news server MAY file it under a 756 catch-all group if no valid group is applicable. When a news 757 server uses a catch-all group to file the articles posted to 758 newsgroups with status "j", this catch-all group SHOULD be named 759 "junk". (The first letter of the "junk" newsgroup explains why 760 this status has been called "j".) 762 Consequently, when a news server carries the "junk" newsgroup and 763 uses it for the purpose of the "j" status, the "junk" newsgroup 764 contains all postings not filed under another newsgroup, 765 regardless of the status of the "junk" newsgroup. (However, an 766 article posted explicitly to "junk" is treated according to the 767 status of the "junk" newsgroup.) 769 The "junk" newsgroup may be available to news readers and is often 770 used by a news server as a way to locally store an article that 771 will be transmitted to peers (which may carry some of the 772 newsgroups the article was posted to even if the local server does 773 not). In addition, instead of rejecting an article that contains 774 an invalid Newsgroups header field or that is posted to newsgroups 775 it does not carry, a news server may accept such an article and 776 file it under the catch-all newsgroup. 778 Depending on the configuration of the news server, mentioning a 779 newsgroup with status "j" is different than simply not listing the 780 group, since articles arriving for unknown newsgroups may be 781 rejected. 783 When the status field begins with an equal sign ("=" or %x3D), the 784 name of an existing newsgroup on the news server MUST immediately 785 follow the sign. If the status field of "foo.bar" is "=other.group", 786 it means that "foo.bar" is an alias for "other.group". These two 787 newsgroups are distinct; they do not share their articles or their 788 article numbers. Local postings to "foo.bar" are not allowed, but 789 articles from peers are accepted for "foo.bar" and filed into 790 "other.group", regardless of the status of "other.group". The 791 contents of their Newsgroups header fields MUST NOT be altered. 793 Alias groups are typically used during a transition between two 794 newsgroups, including but not limited to a renaming of a group, or a 795 correction of a misspelled group name. 797 The status of the newsgroup an alias points to MUST NOT be taken into 798 account when an article arrives in an alias newsgroup. In 799 particular, it means that unapproved articles arriving from peers in 800 an alias pointing to a moderated newsgroup are accepted and filed 801 into this moderated newsgroup. Therefore, an alias SHOULD NOT point 802 to a moderated newsgroup since it allows bypassing of the moderation. 804 An alias SHOULD NOT point to itself or another alias group. The 805 newsgroup an alias points to SHOULD exist on the news server, and be 806 visible to any client that can see the original group. However, when 807 a client issues a LIST ACTIVE command with a wildmat including the 808 original group, the newsgroup it points to is not listed in the 809 response (unless of course the second newsgroup also matches the 810 wildmat). 812 NOTE: If a server files newsgroups with status "j" into "junk", a 813 newsgroup with status "j" and a newsgroup with status "=junk" are 814 different. An article fed by a peer, and crossposted to a group 815 with status "j", will result in the article being filed only in 816 "junk" if there are no other groups with which to file it, or 817 otherwise only in other valid newsgroups it is crossposted to. 818 Whereas an article fed by a peer, and crossposted to a group with 819 status "=junk", will result in the article being filed in "junk" 820 and in other valid newsgroups it is crossposted to. 822 The following table summarizes what usually happens to an article 823 posted to only the newsgroup "foo.bar", depending on its status field 824 on the news server: 826 +--------------+-----------+------------+------------+--------------+ 827 | Status field | Accepted | Accepted | Moderation | Destination | 828 | of "foo.bar" | if local | from | needed? | if accepted? | 829 | | posting? | peers? | | | 830 +--------------+-----------+------------+------------+--------------+ 831 | y | Yes | Yes | No | foo.bar | 832 | n | No | Yes | No | foo.bar | 833 | m | Yes | Yes | Yes | foo.bar | 834 | x | No | No | No | | 835 | j | No | Yes | No | junk (if | 836 | | | | | filed) | 837 | =other.group | No | Yes | No | other.group | 838 +--------------+-----------+------------+------------+--------------+ 840 The following table summarizes what usually happens to an article 841 crossposted to the newsgroup "foo.bar" and a valid newsgroup 842 "misc.test" (whose status field is "y") known by the news server, 843 depending on the status field of "foo.bar" on the news server: 845 +--------------+-----------+------------+------------+--------------+ 846 | Status field | Accepted | Accepted | Moderation | Destination | 847 | of "foo.bar" | if local | from | needed? | if accepted? | 848 | | posting? | peers? | | | 849 +--------------+-----------+------------+------------+--------------+ 850 | y | Yes | Yes | No | foo.bar, | 851 | | | | | misc.test | 852 | n | No | Yes | No | foo.bar, | 853 | | | | | misc.test | 854 | m | Yes | Yes | Yes | foo.bar, | 855 | | | | | misc.test | 856 | x | No | Yes | No | misc.test | 857 | j | No | Yes | No | misc.test | 858 | =other.group | No | Yes | No | other.group, | 859 | | | | | misc.test | 860 +--------------+-----------+------------+------------+--------------+ 862 NOTE: The status of a newsgroup only indicates how articles 863 arriving for that newsgroup are normally processed; news servers 864 MAY provide clients with special privileges to allow or disallow 865 some rights in these newsgroups. This specification defines 866 neither these rights nor whether or not articles posted to these 867 groups should be propagated to other peers. 869 3.2. Examples 871 Example of an article posted to an alias group by a peer: 873 [C] LIST ACTIVE 874 [S] 215 List of newsgroups follows 875 [S] foo.bar 21 12 y 876 [S] misc.test 3002322 3000234 =foo.bar 877 [S] . 878 [C] IHAVE 879 [S] 335 Send it; end with . 880 [C] Path: demo!.POSTED.somewhere!not-for-mail 881 [C] From: "Demo User" 882 [C] Newsgroups: misc.test 883 [C] Subject: I am just a test article 884 [C] Date: 18 Oct 2008 16:02:45 +0200 885 [C] Organization: An example, Paris, FR. 886 [C] Message-ID: 887 [C] MIME-Version: 1.0 888 [C] 889 [C] This is just a test article. 890 [C] . 891 [S] 235 Article transferred OK 892 [C] LIST ACTIVE 893 [S] 215 List of newsgroups follows 894 [S] foo.bar 22 12 y 895 [S] misc.test 3002322 3000234 =foo.bar 896 [S] . 897 [C] HDR Xref 898 [S] 225 Header information follows 899 [S] 0 news.example.com foo.bar:22 900 [S] . 901 [C] HDR Newsgroups 902 [S] 225 Header information follows 903 [S] 0 misc.test 904 [S] . 906 The Newsgroups header field of this article is kept untouched. This 907 article is filed under "foo.bar" even though it has originally been 908 posted, and still propagates to other peers, to the newsgroup 909 "misc.test". 911 Example of an article locally posted to an alias group: 913 [C] LIST ACTIVE 914 [S] 215 List of newsgroups follows 915 [S] foo.bar 22 12 y 916 [S] misc.test 3002322 3000234 =foo.bar 917 [S] . 918 [C] POST 919 [S] 340 Input article; end with . 920 [C] From: "Demo User" 921 [C] Newsgroups: misc.test 922 [C] Subject: I am just a test article 923 [C] MIME-Version: 1.0 924 [C] 925 [C] This is just a test article. 926 [C] . 927 [S] 441 Newsgroup "misc.test" has been renamed to "foo.bar" 929 The article is rejected, with a detailed error. 931 4. Augmented BNF Syntax for These Additions to the LIST Command 933 This section describes the formal syntax of the new LIST variants 934 defined in this document using [RFC5234]. It extends the syntax in 935 Section 9 of [RFC3977], and non-terminals not defined in this 936 document are defined there. The [RFC3977] ABNF should be imported 937 first before attempting to validate these rules. 939 4.1. Commands 941 This syntax extends the non-terminal which 942 represents the variants of the LIST command. 944 ; counts 945 list-arguments =/ "COUNTS" [WS wildmat] 947 ; distributions, moderators, motd 948 list-arguments =/ "DISTRIBUTIONS" / "MODERATORS" / "MOTD" 950 ; subscriptions 951 list-arguments =/ "SUBSCRIPTIONS" [WS wildmat] 953 4.2. Responses 955 This syntax extends the non-terminals and which respectively represent the status field returned by 957 the LIST ACTIVE command and the response contents for the LIST 958 command. 960 ; active 961 newsgroup-status =/ newsgroup-alias / 962 %x78 / %x6a ; case-sensitive "x" and "j" 963 newsgroup-alias = "=" newsgroup-name 965 ; counts 966 list-content =/ list-counts-content 967 list-counts-content = 968 *(newsgroup-name 3(SPA article-number) 969 SPA newsgroup-status CRLF) 971 ; distributions 972 list-content =/ list-distributions-content 973 list-distributions-content = 974 *(distribution WS distribution-description CRLF) 975 distribution-description = S-TEXT 977 ; moderators 978 list-content =/ list-moderators-content 979 list-moderators-content = 980 *(wildmat ":" moderators-address CRLF) 981 moderators-address = S-TEXT 983 ; motd 984 list-content =/ list-motd-content 985 list-motd-content = *(*U-CHAR CRLF) 987 ; subscriptions 988 list-content =/ list-subscriptions-content 989 list-subscriptions-content = *(newsgroup-name CRLF) 991 5. Internationalization Considerations 993 No new internationalization considerations are introduced by this 994 extension, beyond those already described in the core specification 995 [RFC3977]. 997 In particular, newsgroup names SHOULD be restricted to US-ASCII 998 [ASCII] until a successor to [RFC5536] standardizes another approach. 1000 Distribution descriptions and the message of the day MUST be in UTF-8 1001 [RFC3629]. 1003 6. Security Considerations 1005 No new security considerations are introduced by this extension, 1006 beyond those already described in the core specification [RFC3977] 1007 and the Netnews Architecture and Protocol [RFC5537] (especially 1008 distribution leakage and e-mail Denial of Service during the 1009 moderation process). 1011 7. IANA Considerations 1013 This section gives a formal definition of this extension as required 1014 by Section 3.3.3 of [RFC3977] for the IANA registry. It extends the 1015 LIST capability label defined in Section 7.6 of [RFC3977]. 1017 o This extension provides additional keywords to the pre-existing 1018 LIST capability defined in Section 7.6 of [RFC3977]. New status 1019 are also added to the ACTIVE variant of the LIST command. 1021 o The capability label that this extension extends is "LIST". 1023 o This extension adds five optional arguments to the "LIST" 1024 capability label: "COUNTS", "DISTRIBUTIONS", "MODERATORS", 1025 "MOTD", and "SUBSCRIPTIONS", indicating which new variants of the 1026 LIST command are supported. Consequently, this extension 1027 associates these new arguments with the pre-existing "LIST" NNTP 1028 command. 1030 o This extension defines five new commands, LIST COUNTS, LIST 1031 DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS, 1032 whose behaviour, arguments, and responses are defined in Sections 1033 2.2, 2.3, 2.4, 2.5, and 2.6 respectively. 1035 o This extension does not associate any new responses with pre- 1036 existing NNTP commands. 1038 o This extension does not affect the maximum length of commands or 1039 initial response lines. 1041 o This extension does not alter pipelining. The LIST COUNTS, LIST 1042 DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS 1043 commands can be pipelined. 1045 o Use of this extension does not alter the capabilities list. 1047 o This extension does not cause any pre-existing command to produce 1048 a 401, 480, or 483 response. 1050 o This extension is unaffected by any use of the MODE READER 1051 command. 1053 o This extension does not affect the overall behaviour of a server 1054 or client other than via the new commands. 1056 o Published Specification: This document. 1058 o Contact for Further Information: Author of this document. 1060 o Change Controller: IESG . 1062 8. Acknowledgements 1064 The author gratefully acknowledges the comments and additional 1065 information provided by Russ Allbery, Urs Janssen, Antti-Juhani 1066 Kaijanaho, Alexey Melnikov, Peter Saint-Andre, Dieter Stussy, and 1067 Sean Turner on this document. 1069 The author would particularly like to thank Jeffrey M. Vinocur for 1070 having reread, improved, and patiently fixed the English wording and 1071 the quality of this document. 1073 Special thanks are due to: 1075 Stan Barber, whose [RFC2980] served as the initial basis for the 1076 DISTRIBUTIONS and SUBSCRIPTIONS variants of the LIST command. 1078 Brian Hernacki, whose [I-D.draft-hernacki-nntplist] draft served 1079 as the initial basis for the MOTD and also SUBSCRIPTIONS variants 1080 of the LIST command. 1082 The authors of the documentation of a few sample files of the 1083 InterNetNews news server ("active", "distributions", "moderators", 1084 "motd.news", and "subscriptions"): Russ Allbery, Bettina Fink, 1085 Rich Salz, and a few other people to whom I am also grateful. 1087 9. References 1089 9.1. Normative References 1091 [RFC2119] Bradner, S., "Key words for use in 1092 RFCs to Indicate Requirement Levels", 1093 BCP 14, RFC 2119, March 1997. 1095 [RFC3629] Yergeau, F., "UTF-8, a transformation 1096 format of ISO 10646", STD 63, 1097 RFC 3629, November 2003. 1099 [RFC3977] Feather, C., "Network News Transfer 1100 Protocol (NNTP)", RFC 3977, 1101 October 2006. 1103 [RFC5234] Crocker, D. and P. Overell, "Augmented 1104 BNF for Syntax Specifications: ABNF", 1105 STD 68, RFC 5234, January 2008. 1107 [RFC5322] Resnick, P., Ed., "Internet Message 1108 Format", RFC 5322, October 2008. 1110 9.2. Informative References 1112 [ASCII] American National Standards Institute, 1113 "Coded Character Sets - 7-Bit American 1114 Standard Code for Information 1115 Interchange (7-Bit ASCII), ANSI X3.4", 1116 1986. 1118 [I-D.draft-hernacki-nntplist] Hernacki, B., "NNTP LIST Additions", 1119 draft-hernacki-nntplist-02 (work in 1120 progress), July 2007. 1122 [RFC2980] Barber, S., "Common NNTP Extensions", 1123 RFC 2980, October 2000. 1125 [RFC5536] Murchison, K., Lindsey, C., and D. 1126 Kohn, "Netnews Article Format", 1127 RFC 5536, November 2009. 1129 [RFC5537] Allbery, R. and C. Lindsey, "Netnews 1130 Architecture and Protocols", RFC 5537, 1131 November 2009. 1133 [I-D.ietf-usefor-useage] Lindsey, C., "Usenet Best Practice", 1134 draft-ietf-usefor-useage-01 (work in 1135 progress), March 2005. 1137 Appendix A. Document History (to be removed by RFC Editor before 1138 publication) 1140 Appendix A.1. Changes from -04 1142 o Fix a few nits which were found during IESG Evaluation. The most 1143 important are: in Section 2, "optional" is changed to "OPTIONAL"; 1144 in Section 2.4.2, "SHOULD NOT occur" is changed to "should not 1145 occur". Thanks to Sean Turner and Peter Saint-Andre. 1147 o Show in the example of LIST DISTRIBUTIONS that descriptions of 1148 distributions not present in the distrib.pats list can be 1149 mentioned in the distributions list. 1151 Appendix A.2. Changes from -03 1153 o This document is no longer an independent submission. It is now 1154 sponsored by an Area Director, Alexey Melnikov. Many thanks to 1155 him! 1157 o Modify the note about the "%s" pattern rule for the moderation 1158 submission template for two moderated newsgroups whose names 1159 differ only by the case of their characters: mention the reason 1160 and the fact that it is only a recommendation. 1162 o Mention that TAB characters are not valid separators for the LIST 1163 COUNTS command. 1165 o Add an example of wildmat preceded by "!". 1167 o Re-work the BNF syntax for "newsgroup-alias" because it could be a 1168 little confusing. Thanks to Gen-ART for the remark during Last 1169 Call. 1171 o Add a MIME-Version: header field in the examples of postings. 1172 They now comply with [RFC5536]. 1174 o Clarify what is expected from IANA (add a reference to this 1175 document for the LIST NNTP extension). 1177 o Use "news.example.com" instead of "news.server.com" in an Xref: 1178 header field so as to have a compliant FQDN. 1180 o Use the right boilerplate for [RFC2119]. 1182 o Add a reference to [RFC5322] for the submission template. 1184 Appendix A.3. Changes from -02 1186 o No longer document the "Y" and "M" status. It is better to stick 1187 with status that already have an implementation for Proposed 1188 Standard. 1190 o Mention that the status of the newsgroup an alias points to MUST 1191 NOT be taken into account when an article arrives in an alias 1192 newsgroup. Also point out the fact that it can lead to file 1193 unapproved articles into moderated newsgroups. 1195 o Clarify that the catch-all group MAY be used when no valid group 1196 is applicable. 1198 o Add a reference to [RFC3629]. 1200 Appendix A.4. Changes from -01 1202 o Acknowledge Jeffrey M. Vinocur's wording fixes and remarks. 1204 o Add a note about how the client should cache the motd. 1206 o Mention that a news server need not consistently return the same 1207 order or the same results if the LIST COUNTS command is used more 1208 than once in a session. 1210 o Mention that a news server need not return distributions in the 1211 same order between the DISTRIB.PATS and DISTRIBUTIONS variants of 1212 the LIST command. 1214 o Introduce the notion of "template" in LIST MODERATORS responses. 1216 o Use MUST for the presence of "%s" in submission templates. 1218 o Use the right "header field" and "header field body" terminology. 1220 Appendix A.5. Changes from -00 1222 o Add this appendix. 1224 o Acknowledge Antti-Juhani Kaijanaho's and D. Stussy's remarks. 1226 o Refer to USEFOR ([RFC5536]) and USEAGE ([I-D.ietf-usefor-useage]) 1227 instead of putting a SHOULD requirement on the name of newsgroups 1228 in the example of the LIST MODERATORS command. Besides, the note 1229 was only related to the presence of "%s" in the submission address 1230 template. 1232 o Mention that every moderated newsgroup name SHOULD have a matching 1233 line in LIST MODERATORS, if no default entry exists. 1235 o The presence of "+" in the name of a moderated newsgroup is a 1236 matter of configuration and should not be dealt with in this memo. 1237 If any special interpretation is applied by the mail system of the 1238 receiving site, and if they want to host a submission address for 1239 a moderated group determined by a "%s" pattern rule, they will 1240 need to suppress that interpretation. 1242 o Lowercase a "MAY" for the reject of articles arriving for unknown 1243 newsgroups. 1245 o The meaning of the "j" status flag has changed: the "junk" 1246 newsgroup is no longer required. A group with status "j" now only 1247 means that no articles are filed under it. Moreover, local 1248 postings to "j" newsgroups are not accepted. 1250 o Add an explanation about how the status of the "junk" newsgroup 1251 affects articles posted to "junk" or newsgroups with status "j". 1253 o Add a note about the difference between the "j" and "=junk" 1254 status. 1256 o The status of the newsgroup to which an alias group points is no 1257 longer checked. An article is directly filed under it. Besides, 1258 the requirement for an alias not pointing to another alias group 1259 becomes a SHOULD NOT instead of a MUST NOT. 1261 o Add an example of article locally posted to an alias group. 1263 o Remove the fact that if a news server may accept articles from a 1264 client during the session (possibly after successful 1265 authentication), it SHOULD NOT return a status like "n" or "x" 1266 which suggests that articles are not accepted in the corresponding 1267 newsgroup. 1269 o Document the "Y" and "M" status. 1271 o Document the COUNTS variant for the LIST command. 1273 o The "r" status flag will be documented in another (experimental) 1274 draft. A new REMOVALS variant for the LIST command is needed. 1276 o Add a reference to [ASCII]. 1278 Author's Address 1280 Julien Elie 1281 13 rue Marx Dormoy 1282 Noisy-le-Grand 93160 1283 France 1285 EMail: julien@trigofacile.com 1286 URI: http://www.trigofacile.com/