Internet Engineering Task Force J. Elie Internet-Draft November 14, 2009 Updates: 2980, 3977 (if approved) Intended status: Standards Track Expires: May 18, 2010 Network News Transfer Protocol (NNTP) Additions to LIST Command draft-elie-nntp-list-additions-00 Abstract This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allows a client to request extended information maintained by NNTP servers as for local use and distribution policy. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977. This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST MODERATORS and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 18, 2010. Elie Expires May 18, 2010 [Page 1]
Internet-Draft Additions to NNTP LIST Command November 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Elie Expires May 18, 2010 [Page 2]
Internet-Draft Additions to NNTP LIST Command November 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. New LIST Variants . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Advertising the New LIST Variants . . . . . . . . . . . . 4 2.2. LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Description . . . . . . . . . . . . . . . . . . . . . 5 2.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. LIST MODERATORS . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Description . . . . . . . . . . . . . . . . . . . . . 7 2.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. LIST MOTD . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.2. Description . . . . . . . . . . . . . . . . . . . . . 9 2.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. LIST SUBSCRIPTIONS . . . . . . . . . . . . . . . . . . . . 10 2.5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. Description . . . . . . . . . . . . . . . . . . . . . 11 2.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11 3. Additions to LIST ACTIVE . . . . . . . . . . . . . . . . . . . 12 3.1. New status fields . . . . . . . . . . . . . . . . . . . . 12 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Augmented BNF Syntax for These Additions to the LIST Command . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Internationalisation Considerations . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 Elie Expires May 18, 2010 [Page 3]
Internet-Draft Additions to NNTP LIST Command November 2009 1. Introduction The NNTP specification [RFC3977] defines the LIST capability and a few keywords which can be used with that command: ACTIVE, ACTIVE.TIMES, DISTRIB.PATS, HEADERS, NEWSGROUPS, and OVERVIEW.FMT. As other widely used variants of the LIST command currently exist, they are formalized in this document. The DISTRIBUTIONS and SUBSCRIPTIONS variants have originally been documented in [RFC2980]. The LIST DISTRIBUTIONS command is sent by a news client to obtain a list of relevant distributions known by a news server along with their descriptions. The LIST SUBSCRIPTIONS command is sent by a news client when first connecting to a news server so as to obtain a list of recommended newsgroups available on it. Both of these commands are intended to be used in place of hard- coding news clients to use specific distributions or look for specific default newsgroups. The MOTD variant has originally been documented in [I-D.draft-hernacki-nntplist] (which also defines the SUBSCRIPTIONS variant). The LIST MOTD command is sent by a news client to obtain a "message of the day" containing useful information regarding the current state of a news server. The MODERATORS variant had not been documented before. The LIST MODERATORS command is sent by a news client to obtain a list of associations between a moderated newsgroup and its submission address. The ACTIVE variant has already been documented in [RFC3977] but the meaning of only three status fields in response to the LIST ACTIVE command has been specified: "y", "n", and "m". These status are particularly useful for readers since they describe local posting rights. This memo defines three other widespread values for the status field: "j", "x", and "=" followed by the name of a newsgroup. These new status are particularly useful for peers since they mainly describe how remote articles coming from peers are locally handled by the news server. This specification is to be read in conjunction with the NNTP base specification [RFC3977]. Except where specifically stated otherwise, in the case of a conflict between these two documents, [RFC3977] takes precedence over this one. 1.1. Conventions Used in This Document The notational conventions used in this document are the same as those in [RFC3977], and any term not defined in this document has the Elie Expires May 18, 2010 [Page 4]
Internet-Draft Additions to NNTP LIST Command November 2009 same meaning as it does in that one. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119]. In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S]. The client is the initiator of the NNTP connection; the server is the other endpoint. 2. New LIST Variants The LIST capability is defined in Section 7.6 of [RFC3977]. It allows the server to provide blocks of useful information to the client. This document provides four new keywords to the LIST capability: DISTRIBUTIONS, MODERATORS, MOTD, and SUBSCRIPTIONS. All these keywords are optional and correspond to an eponymous variant of the LIST command. 2.1. Advertising the New LIST Variants When a news server implements a variant of the LIST command as described in this specification, it advertises the corresponding feature in the LIST capability. Where one of these new LIST keywords is advertised, it MUST have the meaning given in this specification. For instance, if a news server implements the SUBSCRIPTIONS variant, it will add the SUBSCRIPTIONS keyword to the LIST capability in response to the CAPABILITIES command (see Section 5.2 of [RFC3977]): [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS SUBSCRIPTIONS [S] . [C] LIST SUBSCRIPTIONS [S] 215 List of recommended newsgroups follows [S] local.welcome [S] local.test [S] news.newusers.questions [S] news.announce.newusers [S] . For all the new LIST variants described in this specification, an empty response can be sent to the client: Elie Expires May 18, 2010 [Page 5]
Internet-Draft Additions to NNTP LIST Command November 2009 [C] LIST SUBSCRIPTIONS [S] 215 List of recommended newsgroups follows [S] . It means that the information is maintained by the news server but that it is voluntarily empty. As often as not, the news server maintains the information in a configuration file. This file can be empty or contain only commented or blank lines, which leads to a voluntary absence of information. When the news server does not maintain the information (for instance when the configuration file does not exist), the 503 response code MUST be returned: [C] LIST SUBSCRIPTIONS [S] 503 No list of recommended newsgroups available 2.2. LIST DISTRIBUTIONS 2.2.1. Usage Syntax LIST DISTRIBUTIONS Responses 215 Distributions list follows (multi-line) 2.2.2. Description See Section 7.6.1 of [RFC3977] for general requirements of the LIST command. The distributions list is maintained by some NNTP servers to contain the name of each distribution that is known by the news server and a short description about the meaning of the distribution. The information is returned as a multi-line data block following the 215 response code and contains one line per distribution. Each line of this list MUST consist of two fields separated from each other by one or more space or TAB characters (the usual pratice is a single TAB). The first field is the name of the distribution, and the second field is a short description of the distribution. There are no leading or trailing whitespaces in a line. The description MAY contain whitespaces. The order of distributions in the list is not significant; the server need not even consistently return the same order or the same results if this command is used more than once in a session. Elie Expires May 18, 2010 [Page 6]
Internet-Draft Additions to NNTP LIST Command November 2009 The same distribution SHOULD NOT appear twice in the output of this command. The description MUST be in UTF-8. The distributions list is not newsgroup-based, and an argument MUST NOT be specified. Otherwise, a 501 response code MUST be returned. The distributions list MAY be empty. If the server does not maintain the information, a 503 response code MUST be returned. The client MAY use this information to provide the user with a list of known distributions he can use. If the news server implements the LIST DISTRIBUTIONS command, it SHOULD also implement the LIST DISTRIB.PATS command and describe in the distributions list at least all the distributions present in the distrib.pats list so that the client can use both of these commands jointly. The distrib.pats list is defined in Section 7.6.5 of [RFC3977]; it assists clients to choose a value for the content of the Distribution header of a news article being posted (see Section 3.2.4 of [RFC5536] for the definition of this header). 2.2.3. Example Example of a joint use of LIST DISTRIB.PATS and LIST DISTRIBUTIONS: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE DISTRIB.PATS DISTRIBUTIONS NEWSGROUPS [S] . [C] LIST DISTRIB.PATS [S] 215 Information follows [S] 10:local.*:local [S] 5:france.*:fr [S] 20:local.here.*:thissite [S] . [C] LIST DISTRIBUTIONS [S] 215 List of distributions follows [S] fr Local to France. [S] local Local to this news server. [S] thissite Local to this site. [S] . Elie Expires May 18, 2010 [Page 7]
Internet-Draft Additions to NNTP LIST Command November 2009 2.3. LIST MODERATORS 2.3.1. Usage Syntax LIST MODERATORS Responses 215 Moderators list follows (multi-line) 2.3.2. Description See Section 7.6.1 of [RFC3977] for general requirements of the LIST command. The moderators list is maintained by some NNTP servers to make clients aware of the submission address the news server will use when an article is locally posted to a moderated newsgroup. The information is returned as a multi-line data block following the 215 response code. Each line of this list MUST consist of two fields separated from each other by a colon (":" or %x3A). The first field is a wildmat (which may be a simple newsgroup name), and the second field is the submission address for newsgroups matching that wildmat. There are no leading or trailing whitespaces in a line. The submission address MAY contain colons (":"). The order of lines in the list is significant: the first matching line is used. Consequently, specific patterns should be listed before general patterns. When an unapproved article is locally posted to a moderated newsgroup, it is forwarded to a moderator (see Section 3.5.1 of [RFC5537]), using the submission address for that newsgroup. This submission address is the second field of the first matching line in the moderators list. It is an e-mail address with one exception: at most one occurrence of the case-sensitive string "%s" (%x25.73) may occur anywhere in the address. If present, the news server will replace it, when forwarding the article to the moderator, with the name of the matching newsgroup, with all periods ("." or %x2E) in the name changed to dashes ("-" or %x2D). If there is a literal "%" in the submission address, it MUST be written as "%%", even if not followed by an "s". NOTE: How submission addresses are created and maintained is outside the scope of this specification. The moderators list is not newsgroup-based, and an argument MUST NOT Elie Expires May 18, 2010 [Page 8]
Internet-Draft Additions to NNTP LIST Command November 2009 be specified. Otherwise, a 501 response code MUST be returned. The moderators list MAY be empty. If the server does not maintain the information, a 503 response code MUST be returned, though these two cases SHOULD NOT occur if the news server is an injecting agent that carries moderated newsgroups. 2.3.3. Example Example of output: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] POST [S] LIST ACTIVE MODERATORS NEWSGROUPS [S] . [C] LIST MODERATORS [S] 215 List of submission addresses follows [S] foo.bar:announce@example.com [S] local.*:%s@localhost [S] *:%s@moderators.example.com [S] . The following table describes a few examples of associations between a moderated newsgroup and its submission address on a news server whose moderators list is the one of the previous example: +-----------------------------+-------------------------------------+ | Name of the moderated | Submission address | | newsgroup | | +-----------------------------+-------------------------------------+ | foo.bar | announce@example.com | | local.test | local-test@localhost | | alt.dev.null | alt-dev-null@moderators.example.com | | alt.test-me | alt-test-me@moderators.example.com | +-----------------------------+-------------------------------------+ NOTE: Periods are changed to dashes, and dashes are left alone. It implies that two moderated newsgroups whose names differ only by changing a period to a dash would go to the same address. Therefore, such moderated newsgroup pairs SHOULD NOT be created on a news server. Similarly, a news server SHOULD NOT carry two moderated newsgroups whose names differ only by the case of their characters. Elie Expires May 18, 2010 [Page 9]
Internet-Draft Additions to NNTP LIST Command November 2009 [[Editorial comment 1: Do we have possible issues with the syntax of generated e-mail addresses? I read in RFC 3696 and its errata that the local part of an e-mail address is limited to 64 characters, and the whole address to 256 characters. Section 7.2 of USEAGE mentions that a newsgroup name is limited to 66 characters, which may cause problems. --JE]] [[Editorial comment 2: Do we have possible issues with the use of "+" in e-mail addresses? It sometimes have special meaning. We have newsgroups whose names contain "c++". --JE]] 2.4. LIST MOTD 2.4.1. Usage Syntax LIST MOTD Responses 215 Information follows (multi-line) 2.4.2. Description See Section 7.6.1 of [RFC3977] for general requirements of the LIST command. The motd list contains a "message of the day" relevant to the news server. It is intended to provide notification and communication between the news administrator and the news user. For instance, notification of upcoming downtime or information about new facilities available on the news server can be advertised via this means of communication. The information is returned as a multi-line data block following the 215 response code. This text is not guaranteed to be in any particular format although, like all multi-line data blocks, it is "dot-stuffed". The server need not return the same information if this command is used more than once in a session. It MAY indeed send a different message of the day depending on the state of the session. For instance, on a mode-switching news server, the information can be different between its transit mode and its reader mode, or between an authenticated session and an unauthenticated session. The information MUST be in UTF-8. The motd list is not newsgroup-based, and an argument MUST NOT be Elie Expires May 18, 2010 [Page 10]
Internet-Draft Additions to NNTP LIST Command November 2009 specified. Otherwise, a 501 response code MUST be returned. The motd list MAY be empty. If the server does not maintain the information, a 503 response code MUST be returned. It is up to the client to decide when and how to display this message to the user. No timestamp or date of last modification date is provided. The client may want to keep some state if it wishes to show the message only upon modification. 2.4.3. Example Example of output: [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE MOTD NEWSGROUPS [S] . [C] LIST MOTD [S] 215 Message of the day follows [S] Attention all users, [S] [S] This server will be down for scheduled upgrades on February, 1st. [S] It should be back up by 8:00 a.m. February, 2nd. [S] Any questions should be e-mailed to <newsmaster@example.com>. [S] [S] Apologies for the disturbance. [S] . 2.5. LIST SUBSCRIPTIONS 2.5.1. Usage Syntax LIST SUBSCRIPTIONS [wildmat] Responses 215 Subscriptions list follows (multi-line) Parameters wildmat Groups of interest Elie Expires May 18, 2010 [Page 11]
Internet-Draft Additions to NNTP LIST Command November 2009 2.5.2. Description See Section 7.6.1 of [RFC3977] for general requirements of the LIST command. The subscriptions list is maintained by some NNTP servers to provide the client with a list of recommended newsgroups. The information is returned as a multi-line data block following the 215 response code. Each line of this list MUST consist of a newsgroup name. There are no leading or trailing whitespaces in a line. The order of newsgroups in the list is significant: they are listed by order of importance, the first newsgroup being the most important to subscribe to. The same newsgroup name SHOULD NOT appear twice in the output of this command. The list SHOULD contain only newsgroups the news server carries. The subscriptions list is newsgroup-based, and a wildmat MAY be specified, in which case the response is limited to only the groups, if any, whose names match the wildmat. Note that the wildmat argument is a new feature in this specification and servers that do not support CAPABILITIES or do not advertise the SUBSCRIPTIONS keyword in the LIST capability (and therefore do not conform to this specification) are unlikely to support it. The subscriptions list MAY be empty. If the server does not maintain the information, a 503 response code MUST be returned. The client MAY use this information the first time it connects to the news server so as to initialize the list of default subscribed newsgroups. This list should therefore contain groups intended for new users on the news server or Usenet in general. For instance newsgroups dedicated to testing, support, annoucement, or FAQs. The client MAY present the groups in the order of appearance in the list to the user. When the subscriptions list is maintained and non empty, the news client SHOULD use it, instead of a hard-coded default list, if any. 2.5.3. Example Example of output with no argument: Elie Expires May 18, 2010 [Page 12]
Internet-Draft Additions to NNTP LIST Command November 2009 [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] LIST ACTIVE NEWSGROUPS SUBSCRIPTIONS [S] . [C] LIST SUBSCRIPTIONS [S] 215 List of recommended newsgroups follows [S] local.welcome [S] local.test [S] news.newusers.questions [S] news.announce.newusers [S] . Example of output with a wildmat: [C] LIST SUBSCRIPTIONS local.* [S] 215 List of recommended newsgroups follows [S] local.welcome [S] local.test [S] . 3. Additions to LIST ACTIVE This document specifies three new status fields that can be used in the answers to LIST ACTIVE: "j", "x", and "=" followed by the name of a newsgroup. [[Editorial comment 3: How can we define new status? Should a new capability or keyword be provided? We have to make sure that if for instance "x" is returned by a compliant news server, it has the meaning specified in this document. RFC 3977 mentions that "Other values for the status may exist; the definition of these other values and the circumstances under which they are returned may be specified in an extension or may be private to the server." And also that "Each extension MUST define at least one new capability label (this will often, but need not, be the name of one of these new commands)." A capability label, then... But it seems overkill! Unless we do not speak about an extension for that, but something else? --JE]] 3.1. New status fields The LIST ACTIVE command is defined in Section 7.6.3 of [RFC3977]. The fourth field of each line of this list indicates the current status of the newsgroup whose name is specified in the first field. Three status are defined in [RFC3977]: Elie Expires May 18, 2010 [Page 13]
Internet-Draft Additions to NNTP LIST Command November 2009 "y" Posting is permitted. "n" Posting is not permitted. "m" Postings will be forwarded to the newsgroup moderator. This document defines three other status which can also be used: "j" Articles are filed under the "junk" newsgroup. "x" Postings and articles from peers are not permitted. "=other.group" Articles are filed under the newsgroup named "other.group". The server SHOULD use these values when these meanings are required and MUST NOT use them with any other meaning. [[Editorial comment 4: Should other status be standardized? I suggest one for "local postings only" ("l" status) which I believe should be defined because "n" exists. Another one that might be useful would be an "r" status for a to-be-removed newsgroup. For instance, when an rmgroup control article arrives for a newsgroup (see Section 5.2.2 of RFC 5537), its status could be changed to "r" instead of just being removed. No more articles could then be filed under that newsgroup which would be bound to expire when all the articles it contains have been expired. (Or we could have an "r" followed by the number of seconds since January 1st, 1970. The corresponding date would specify when the newsgroup has been marked as to-be-removed, which could allow to really remove it after a certain number of days.) This way, people would have some time to read last postings in the newsgroup. And it would also permit to easily fix possible mistakes made by hierarchy maintainers who could inadvertently remove a group in a checkgroups, and then reinstate it. My only concern is that users may try to post an article to the newsgroup, without success (but the case is already present with other status -- and it is a client implementation design). --JE]] The difference between a newsgroup with status "n" and a newsgroup with status "x" is that articles from peers are accepted for the former, and rejected for the latter. A newsgroup with status "x" is considered as closed: no new articles will arrive in such a group. On the contrary, articles from peers will arrive in a newsgroup with status "n". Local postings are not allowed in a newsgroup with one of these two status. No articles will be filed in a newsgroup with status "j". If an article is locally posted to such a group or is received from a peer, Elie Expires May 18, 2010 [Page 14]
Internet-Draft Additions to NNTP LIST Command November 2009 and in case it is not crossposted to some other valid groups, it will be filed into the "junk" newsgroup instead. Otherwise, it is filed only into the valid newsgroups it is crossposted to. NOTE: The status "j" is used only by news servers on which the newsgroup "junk" exists. This group has special meaning. It usually contains all the postings which cannot file under a newsgroup name. Instead of rejecting an article which contains an invalid Newsgroups header or which is posted to newsgroups it does not carry, a news server may accept such an article and file it under a generic newsgroup named "junk". This newsgroup may be available to news readers and is often used by a news server as a way to locally store an article with the view to transmitting it to its peers (which may carry some of the newsgroups the article was posted to). Depending on the configuration of the news server, mentioning a newsgroup with status "j" is different than simply not listing the group, since articles arriving in unknown newsgroups MAY be rejected. When the status field begins with an equal sign ("=" or %x3D), the name of an existing newsgroup on the news server MUST immediately follow the sign. If the status field of "foo.bar" is "=other.group", it means that "foo.bar" is an alias for "other.group". These two newsgroups are distinct; they do not share their articles or their article numbers. Local postings to "foo.bar" are not allowed, but articles from peers are accepted for "foo.bar" and treated as though they were actually posted to "other.group" (that is to say according to the meaning of the status field of "other.group"). The contents of their Newsgroups headers MUST NOT be altered. Alias groups are typically used during a transition between two newsgroups. An alias MUST NOT point to another alias group. The newsgroup an alias points to SHOULD exist on the news server. If an alias is listed in the active list, the newsgroup it points to is not also listed in the active list when a wildmat is given to the LIST ACTIVE command, and the name of the newsgroup the alias points to does not match the wildmat. The following table summarizes what usually happens to an article posted to only the newsgroup "foo.bar", depending on its status field on the news server: Elie Expires May 18, 2010 [Page 15]
Internet-Draft Additions to NNTP LIST Command November 2009 +--------------+-----------+------------+------------+--------------+ | Status field | Accepted | Accepted | Moderation | Destination | | of "foo.bar" | if local | from | needed? | if accepted? | | | posting? | peers? | | | +--------------+-----------+------------+------------+--------------+ | y | Yes | Yes | No | foo.bar | | n | No | Yes | No | foo.bar | | m | Yes | Yes | Yes | foo.bar | | j | Yes | Yes | No | junk | | x | No | No | No | | | =other.group | No | Yes | No | other.group | +--------------+-----------+------------+------------+--------------+ The following table summarizes what usually happens to an article crossposted to the newsgroup "foo.bar" and a valid newsgroup "misc.test" (whose status field is "y") known by the news server, depending on the status field of "foo.bar" on the news server: +--------------+-----------+------------+------------+--------------+ | Status field | Accepted | Accepted | Moderation | Destination | | of "foo.bar" | if local | from | needed? | if accepted? | | | posting? | peers? | | | +--------------+-----------+------------+------------+--------------+ | y | Yes | Yes | No | foo.bar, | | | | | | misc.test | | n | No | Yes | No | foo.bar, | | | | | | misc.test | | m | Yes | Yes | Yes | foo.bar, | | | | | | misc.test | | j | Yes | Yes | No | misc.test | | x | No | Yes | No | misc.test | | =other.group | No | Yes | No | other.group, | | | | | | misc.test | +--------------+-----------+------------+------------+--------------+ NOTE: The status of a newsgroup only indicates how articles arriving to that newsgroup are normally processed; news servers MAY provide clients with special privileges to allow or disallow some rights in these newsgroups. This specification defines neither these rights nor whether or not articles posted to these groups should be propagated to other peers. If the news server may accept articles from the client during the session (possibly after successful authentication), it SHOULD NOT return a status like "n" or "x" which suggests that articles are not accepted in the corresponding newsgroup. Elie Expires May 18, 2010 [Page 16]
Internet-Draft Additions to NNTP LIST Command November 2009 3.2. Example Example of an article posted to an alias group by a peer: [C] LIST ACTIVE [S] 215 List of newsgroups follows [S] foo.bar 21 12 y [S] misc.test 3002322 3000234 =foo.bar [S] . [C] IHAVE <for.misc.test@example.com> [S] 335 Send it; end with <CR-LF>.<CR-LF> [C] Path: demo!.POSTED.somewhere!not-for-mail [C] From: "Demo User" <nobody@example.com> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Date: 18 Oct 2009 04:48:12 +0200 [C] Organization: An example, Paris, FR. [C] Message-ID: <for.misc.test@example.com> [C] [C] This is just a test article. [C] . [S] 235 Article transferred OK [C] LIST ACTIVE [S] 215 List of newsgroups follows [S] foo.bar 22 12 y [S] misc.test 3002322 3000234 =foo.bar [S] . [C] HDR Xref <for.misc.test@example.com> [S] 225 Header information follows [S] 0 news.server.com foo.bar:22 [S] . [C] HDR Newsgroups <for.misc.test@example.com> [S] 225 Header information follows [S] 0 misc.test [S] . The Newsgroups header of this article is kept untouched. This article is filed under "foo.bar" even though it has originally been posted, and still propagates to other peers, to the newsgroup "misc.test". 4. Augmented BNF Syntax for These Additions to the LIST Command This section describes the formal syntax of the new LIST variants defined in this document using [RFC5234]. It extends the syntax in Section 9 of [RFC3977], and non-terminals not defined in this document are defined there. The [RFC3977] ABNF should be imported first before attempting to validate these rules. Elie Expires May 18, 2010 [Page 17]
Internet-Draft Additions to NNTP LIST Command November 2009 4.1. Commands This syntax extends the non-terminal <list-arguments> which represents the variants of the LIST command. ; distributions, moderators, motd list-arguments =/ "DISTRIBUTIONS" / "MODERATORS" / "MOTD" ; subscriptions list-arguments =/ "SUBSCRIPTIONS" [WS wildmat] 4.2. Responses This syntax extends the non-terminals <newsgroup-status> and <list- content> which respectively represent the status field returned by the LIST ACTIVE command and the response contents for the LIST command. ; active newsgroup-status =/ %x6A / %x78 / ; case-sensitive "j" and "x" newsgroup-alias newsgroup-alias = "=" newsgroup-name ; distributions list-content =/ list-distributions-content list-distributions-content = *(distribution WS distribution-description CRLF) distribution-description = S-TEXT ; moderators list-content =/ list-moderators-content list-moderators-content = *(wildmat ":" moderators-address CRLF) moderators-address = S-TEXT ; motd list-content =/ list-motd-content list-motd-content = *(*U-CHAR CRLF) ; subscriptions list-content =/ list-subscriptions-content list-subscriptions-content = *(newsgroup-name CRLF) 5. Internationalisation Considerations No new internationalisation considerations are introduced by this extension, beyond those already described in the core specification [RFC3977]. Elie Expires May 18, 2010 [Page 18]
Internet-Draft Additions to NNTP LIST Command November 2009 In particular, newsgroup names SHOULD be restricted to US-ASCII until a successor to [RFC5536] standardises another approach. Distribution descriptions and the message of the day MUST be in UTF-8. 6. Security Considerations No new security considerations are introduced by this extension, beyond those already described in the core specification [RFC3977] and the Netnews Architecture and Protocol [RFC5537] (especially distribution leakage and e-mail Denial of Service during the moderation process). 7. IANA Considerations This section gives a formal definition of this extension as required by Section 3.3.3 of [RFC3977] for the IANA registry. o This extension provides additional keywords to the existing LIST capability defined in Section 7.6 of [RFC3977]. New status are also added to the ACTIVE variant of the LIST command. o The capability label that this extension extends is "LIST". o This extension adds four optional arguments to the "LIST" capability label: "DISTRIBUTIONS", "MODERATORS", "MOTD", and "SUBSCRIPTIONS", indicating which new variants of the LIST command are supported. o This extension defines four new commands, LIST DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS, whose behaviour, arguments, and responses are defined in Sections 2.2, 2.3, 2.4, and 2.5 respectively. o This extension does not associate any new responses with pre- existing NNTP commands. o This extension does not affect the maximum length of commands or initial response lines. o This extension does not alter pipelining, and the LIST DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS commands can be pipelined. o Use of this extension does not alter the capabilities list. Elie Expires May 18, 2010 [Page 19]
Internet-Draft Additions to NNTP LIST Command November 2009 o This extension does not cause any pre-existing command to produce a 401, 480, or 483 response. o This extension is unaffected by any use of the MODE READER command. o This extension does not affect the overall behaviour of a server or client than via the new commands. o Published Specification: This document. o Contact for Further Information: Author of this document. 8. Acknowledgements The author gratefully acknowledges the comments and additional information provided by Russ Allbery and Urs Janssen on a few elements described in this document. Special thanks are due to: Stan Barber, whose [RFC2980] served as the initial basis for the DISTRIBUTIONS and SUBSCRIPTIONS variants of the LIST command; Brian Hernacki, whose [I-D.draft-hernacki-nntplist] draft served as the initial basis for the MOTD and also SUBSCRIPTIONS variants of the LIST command; the authors of the documentation of a few InterNetNews sample files ("active", "distributions", "moderators", "motd.news", and "subscriptions"): Russ Allbery, Bettina Fink, Rich Salz and a few other people to whom I am also grateful. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Elie Expires May 18, 2010 [Page 20]
Internet-Draft Additions to NNTP LIST Command November 2009 9.2. Informative References [I-D.draft-hernacki-nntplist] Hernacki, B., "NNTP LIST Additions", draft-hernacki-nntplist-02 (work in progress), July 2007. [RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000. [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536. [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and Protocols", RFC 5537, April 2009. [I-D.ietf-usefor-useage] Lindsey, C., "Usenet Best Practice", draft-ietf-usefor-useage-01 (work in progress), March 2005. Author's Address Julien Elie 13 rue Marx Dormoy Noisy-le-Grand 93160 France EMail: julien@trigofacile.com URI: http://www.trigofacile.com/ Elie Expires May 18, 2010 [Page 21]
