doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc6048.txt b/doc/rfc/rfc6048.txt
new file mode 100644
index 0000000..96249e6
--- /dev/null
+++ b/doc/rfc/rfc6048.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           J. Elie
+Request for Comments: 6048                                 November 2010
+Updates: 2980, 3977
+Category: Standards Track
+ISSN: 2070-1721
+
+
+    Network News Transfer Protocol (NNTP) Additions to LIST Command
+
+Abstract
+
+   This document defines a set of enhancements to the Network News
+   Transfer Protocol (NNTP) that allow a client to request extended
+   information from NNTP servers regarding server status, policy, and
+   other aspects of local configuration.  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
+   COUNTS, 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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6048.
+
+Copyright Notice
+
+   Copyright (c) 2010 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
+
+
+
+Elie                         Standards Track                    [Page 1]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   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.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
+     1.2.  Author's Note  . . . . . . . . . . . . . . . . . . . . . .  4
+   2.  New LIST Variants  . . . . . . . . . . . . . . . . . . . . . .  4
+     2.1.  Advertising the New LIST Variants  . . . . . . . . . . . .  4
+     2.2.  LIST COUNTS  . . . . . . . . . . . . . . . . . . . . . . .  5
+       2.2.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . .  5
+       2.2.2.  Description  . . . . . . . . . . . . . . . . . . . . .  6
+       2.2.3.  Examples . . . . . . . . . . . . . . . . . . . . . . .  7
+     2.3.  LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . .  8
+       2.3.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . .  8
+       2.3.2.  Description  . . . . . . . . . . . . . . . . . . . . .  8
+       2.3.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 10
+     2.4.  LIST MODERATORS  . . . . . . . . . . . . . . . . . . . . . 10
+       2.4.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . 10
+       2.4.2.  Description  . . . . . . . . . . . . . . . . . . . . . 10
+       2.4.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 12
+     2.5.  LIST MOTD  . . . . . . . . . . . . . . . . . . . . . . . . 13
+       2.5.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . 13
+       2.5.2.  Description  . . . . . . . . . . . . . . . . . . . . . 13
+       2.5.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 14
+     2.6.  LIST SUBSCRIPTIONS . . . . . . . . . . . . . . . . . . . . 14
+       2.6.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . 14
+       2.6.2.  Description  . . . . . . . . . . . . . . . . . . . . . 15
+       2.6.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . 16
+   3.  Additions to LIST ACTIVE . . . . . . . . . . . . . . . . . . . 16
+     3.1.  New Status Field Values  . . . . . . . . . . . . . . . . . 16
+     3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   4.  Augmented BNF Syntax for These Additions to the LIST
+       Command  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     4.1.  Commands . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     4.2.  Responses  . . . . . . . . . . . . . . . . . . . . . . . . 21
+   5.  Internationalization Considerations  . . . . . . . . . . . . . 22
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 2]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+1.  Introduction
+
+   The NNTP specification [RFC3977] defines the LIST capability and a
+   few keywords that can be used with that command: ACTIVE,
+   ACTIVE.TIMES, DISTRIB.PATS, HEADERS, NEWSGROUPS, and OVERVIEW.FMT.
+   Other variants of the LIST command are in use, but with limited or
+   absent documentation.  These variants are formalized in this
+   document.
+
+   The DISTRIBUTIONS and SUBSCRIPTIONS variants were originally
+   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 was originally documented in [NNTP_LIST] (which also
+   describes the SUBSCRIPTIONS variant).  The LIST MOTD command is sent
+   by a news client to obtain a "message of the day" from the server
+   administrator regarding the current state of a news server.
+
+   The COUNTS and MODERATORS variants have not been documented before.
+   The LIST COUNTS command is similar to LIST ACTIVE, except that it
+   also returns an estimated number of articles in each newsgroup.  The
+   LIST MODERATORS command is sent by a news client to obtain a list of
+   associations between a moderated newsgroup and its submission address
+   template.
+
+   The ACTIVE variant was formalized in [RFC3977], but the meanings of
+   only three status field values in LIST ACTIVE responses have been
+   specified: "y", "n", and "m".  These statuses are particularly useful
+   for readers, since they describe local posting rights.  However,
+   several other statuses are in use that are primarily useful for peers
+   as they mainly describe how remote articles coming from peers are
+   locally handled by a given news server.  This memo defines three
+   other values for the status field in LIST ACTIVE responses: "x", "j",
+   and "=" followed by the name of a newsgroup.
+
+   This specification should be read in conjunction with the NNTP base
+   specification [RFC3977].  In the case of a conflict between these two
+   documents, [RFC3977] takes precedence.
+
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 3]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+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
+   same meaning as it does in that one.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   When a hexadecimal correspondence is given to an octet in this
+   document, the value is in US-ASCII [ASCII] (for instance, ".", noted
+   %x2E).
+
+   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.
+
+1.2.  Author's Note
+
+   Please write the first letter of "Elie" with an acute accent wherever
+   possible -- it is U+00C9, that is to say "É" in XML.
+
+2.  New LIST Variants
+
+   The LIST capability is defined in Section 7.6 of [RFC3977].  It
+   allows the server to provide useful information to the client in
+   multi-line blocks.
+
+   This document provides five new keywords to the LIST capability:
+   COUNTS, DISTRIBUTIONS, MODERATORS, MOTD, and SUBSCRIPTIONS.
+
+   Each keyword is OPTIONAL and corresponds to the same-named 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]):
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 4]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+      [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 each of the new LIST variants described in this specification, an
+   empty response can be sent to the client:
+
+      [C] LIST SUBSCRIPTIONS
+      [S] 215 List of recommended newsgroups follows
+      [S] .
+
+   This means that the information is maintained by the news server but
+   that it is voluntarily empty.  Frequently, the news server maintains
+   the information in a configuration file.  This file can be empty or
+   contain only commented or blank lines, indicating a voluntary absence
+   of information.
+
+   When the news server software implements one of these LIST variants
+   but a particular 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 COUNTS
+
+2.2.1.  Usage
+
+   Syntax
+      LIST COUNTS [wildmat]
+
+   Responses
+      215    List of newsgroups follows (multi-line)
+
+   Parameters
+      wildmat    Groups of interest
+
+
+
+
+Elie                         Standards Track                    [Page 5]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+2.2.2.  Description
+
+   See Section 7.6.1 of [RFC3977] for general requirements of the LIST
+   command.
+
+   The LIST COUNTS command returns a list of valid newsgroups carried by
+   the news server along with associated information, the "counts list",
+   and is similar to LIST ACTIVE.
+
+   The information is returned as a multi-line data block following the
+   215 response code and contains one line per newsgroup.  Each line of
+   this list MUST consist of five fields separated from each other by
+   one or more spaces (the usual practice is a single space) in the
+   following order:
+
+   o  The name of the newsgroup.
+
+   o  The reported high water mark for the group.
+
+   o  The reported low water mark for the group.
+
+   o  The estimated number of articles in the group.
+
+   o  The current status of the group on this server.
+
+   The reported high and low water marks, and the estimated number of
+   articles, are as described in the GROUP command (see Section 6.1.1 of
+   [RFC3977]), but note that they are in the opposite order to the 211
+   response (that is, number low high group) to the GROUP command.  The
+   current status of the group is as described in the LIST ACTIVE
+   command (see Section 7.6.3 of [RFC3977], as well as Section 3 of this
+   document).  Also note that, similarly to the LIST ACTIVE command, TAB
+   characters are not valid separators for the LIST COUNTS command.
+
+   The order of newsgroups in the counts list is not significant.  The
+   server need not consistently return the same order or the same
+   results if this command is used more than once in a session.
+
+   The same newsgroup SHOULD NOT appear twice in the output of this
+   command.
+
+   The counts 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.  If no wildmat is specified, the
+   server MUST include every newsgroup that the client is permitted to
+   select with the GROUP command (see Section 6.1.1 of [RFC3977]).
+
+
+
+
+
+Elie                         Standards Track                    [Page 6]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   The counts list MAY be empty.  If the server does not maintain the
+   information, a 503 response code MUST be returned.  (However, note
+   that a news server that supports this command usually maintains the
+   information.)
+
+   The client MAY use LIST COUNTS in order to obtain an estimate of the
+   number of articles in every newsgroup the server carries, which
+   enables it to provide the end user with this information.  This
+   provides a simpler mechanism for a client to obtain the estimated
+   number of articles in newsgroups, compared with a sequence of
+   individual GROUP commands.
+
+2.2.3.  Examples
+
+   Example of output with no argument:
+
+      [C] CAPABILITIES
+      [S] 101 Capability list:
+      [S] VERSION 2
+      [S] READER
+      [S] LIST ACTIVE COUNTS NEWSGROUPS
+      [S] .
+      [C] LIST COUNTS
+      [S] 215 List of newsgroups follows
+      [S] misc.test 3002322 3000234 1234 y
+      [S] comp.risks 442001 441099 742 m
+      [S] rec.food.drink.tea 100 51 3 y
+      [S] local.empty 7 8 0 y
+      [S] local.tea 2004 1504 301 y
+      [S] .
+
+   Example of output with a wildmat:
+
+      [C] LIST COUNTS *.tea,misc.*,!local.*
+      [S] 215 List of newsgroups follows
+      [S] misc.test 3002322 3000234 1234 y
+      [S] rec.food.drink.tea 100 51 3 y
+      [S] .
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 7]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   Example of output on an implementation that includes leading zeroes:
+
+      [C] LIST COUNTS
+      [S] 215 List of newsgroups follows
+      [S] misc.test 0003002322 0003000234 1234 y
+      [S] comp.risks 0000442001 0000441099 742 m
+      [S] rec.food.drink.tea 0000000100 0000000051 3 y
+      [S] local.empty 0000000007 0000000008 0 y
+      [S] local.tea 0000002004 0000001504 301 y
+      [S] .
+
+   The estimated number of articles usually does not start with leading
+   zeroes, but MAY start with such zeroes.
+
+2.3.  LIST DISTRIBUTIONS
+
+2.3.1.  Usage
+
+   Syntax
+      LIST DISTRIBUTIONS
+
+   Responses
+      215    Distributions list follows (multi-line)
+
+2.3.2.  Description
+
+   See Section 7.6.1 of [RFC3977] for general requirements of the LIST
+   command.
+
+   A "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.
+   Distributions are used by clients as potential values for the
+   Distribution header field body of a news article being posted (see
+   Section 3.2.4 of [RFC5536] for the definition of this header field).
+
+   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 practice 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.
+
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 8]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   The order of distributions in the distributions list is not
+   significant; the server need not consistently return the same order
+   or the same results if this command is used more than once in a
+   session.
+
+   The same distribution SHOULD NOT appear twice in the output of this
+   command.
+
+   The description MUST be in UTF-8 [RFC3629].
+
+   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 generate or supplement a list
+   of known distributions provided to the user.  If the news server
+   implements the LIST DISTRIBUTIONS command, it SHOULD also implement
+   the LIST DISTRIB.PATS command (defined in Section 7.6.5 of [RFC3977])
+   and describe in the distributions list all the distributions present
+   in the distrib.pats list so that the client can use both of these
+   commands jointly (naturally, the distributions list can also describe
+   distributions that are not present in the distrib.pats list).  Note
+   that the two commands need not return distributions in the same
+   order.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                    [Page 9]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+2.3.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] usa Local to the United States of America.
+      [S] .
+
+2.4.  LIST MODERATORS
+
+2.4.1.  Usage
+
+   Syntax
+      LIST MODERATORS
+
+   Responses
+      215    Moderators list follows (multi-line)
+
+2.4.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 how the news server will generate a submission
+   e-mail address 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
+
+
+
+Elie                         Standards Track                   [Page 10]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   field is the submission address template for newsgroups matching that
+   wildmat.  There are no leading or trailing whitespaces in a line.
+   The submission template MAY contain colons (":").
+
+   The submission template is essentially an e-mail address (see the
+   definition of "addr-spec" in Section 3.4.1 of [RFC5322]), except with
+   certain modifications.  The case-sensitive string "%s" (%x25.73) MUST
+   occur either zero or one time in the template.  If there is to be a
+   literal "%" in the submission address, it MUST be written as "%%" in
+   the template, even if not followed by an "s".  The character "%" MUST
+   NOT occur in the submission template, except as part of "%s" or "%%".
+
+   The order of lines in the moderators list is significant: the first
+   matching line is used.  Consequently, specific patterns should be
+   listed before general patterns.  Every moderated newsgroup name
+   SHOULD be matched by at least one line in the list; often this is
+   achieved by having a default pattern at the bottom, but other
+   approaches are acceptable, and news server software MAY leave this up
+   to the server administrator rather than enforcing it
+   programmatically.
+
+   When an article without an Approved header field is locally posted to
+   a moderated newsgroup, the server generates a submission address from
+   the corresponding submission template (that is, the second field of
+   the first matching line in the moderators list) by replacing the
+   "%s", if present, with the name of the matching newsgroup after each
+   period ("." or %x2E) in the name has been changed to a dash ("-" or
+   %x2D).  In addition, any "%%" is changed back to "%".  The server
+   then forwards the submitted article to the moderator at the resulting
+   submission address (see Section 3.5.1 of [RFC5537]).
+
+      NOTE: The creation and maintenance of submission addresses is
+      outside the scope of this specification.
+
+   The moderators list is not newsgroup-based, and an argument MUST NOT
+   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, although these
+   situations should not occur if the news server is an injecting agent
+   that carries moderated newsgroups.
+
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 11]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+2.4.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 address templates follows
+      [S] foo.bar:announce@example.com
+      [S] local.*:%s@localhost
+      [S] *:%s@moderators.example.com
+      [S] .
+
+   The following table describes a few examples associating a moderated
+   newsgroup and its submission address on a news server whose
+   moderators list is the one in 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: When "%s" is used, periods are changed to dashes, and dashes
+      are left alone.  This implies that two moderated newsgroups whose
+      names differ only by changing a period to a dash would have the
+      same submission address.  Therefore, if a server carries such
+      moderated newsgroup pairs but posts should go to different
+      submission addresses, a "%s" pattern template cannot be used for
+      the moderation submission addresses for those groups, and explicit
+      entries without a pattern will be required.
+
+      Similarly, it is not recommended to use a "%s" pattern rule for
+      the moderation submission template for two moderated newsgroups
+      whose names differ only by the case of their characters, because
+      e-mail systems frequently treat the left-hand side of e-mail
+      addresses as case-sensitive.  See also Section 3.1.4 of [RFC5536]
+      and Section 7.2 of [USEAGE] for the syntax of a newsgroup name.
+
+
+
+
+Elie                         Standards Track                   [Page 12]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+2.5.  LIST MOTD
+
+2.5.1.  Usage
+
+   Syntax
+      LIST MOTD
+
+   Responses
+      215    Information follows (multi-line)
+
+2.5.2.  Description
+
+   See Section 7.6.1 of [RFC3977] for general requirements of the LIST
+   command.
+
+   The "motd" 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 communicated via the LIST MOTD
+   command.
+
+   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 [RFC3629].
+
+   The motd is not newsgroup-based, and an argument MUST NOT be
+   specified.  Otherwise, a 501 response code MUST be returned.
+
+   The motd 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 is provided
+   programmatically, although the news administrator may include one in
+   the text of the motd.  The client MAY cache a local copy or
+   fingerprint of the motd so that it can display the message to the
+   user only upon modification.  If the client caches the information,
+
+
+
+Elie                         Standards Track                   [Page 13]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   it MAY take into account only the motd obtained after reaching the
+   intended state of the session.  Nonetheless, in case a privacy
+   extension is used, the client MUST NOT cache any motd obtained before
+   that extension took effect.
+
+      NOTE: Though the client MAY cache the results of this command, it
+      MUST NOT rely on the correctness of any cached results, whether
+      from earlier in the session or from a previous session.  If the
+      motd is cached, the client SHOULD provide a way to force the
+      cached information to be refreshed.
+
+2.5.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.6.  LIST SUBSCRIPTIONS
+
+2.6.1.  Usage
+
+   Syntax
+      LIST SUBSCRIPTIONS [wildmat]
+
+   Responses
+      215    Subscriptions list follows (multi-line)
+
+   Parameters
+      wildmat    Groups of interest
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 14]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+2.6.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 subscriptions 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 subscriptions 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, announcement, 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.
+
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 15]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+2.6.3.  Examples
+
+   Example of output with no argument:
+
+      [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 field values that can be
+   used in the answers to LIST ACTIVE: "x", "j", and "=" followed by the
+   name of a newsgroup.
+
+3.1.  New Status Field Values
+
+   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 field values are defined in [RFC3977]:
+
+   "y"  Posting is permitted.
+
+   "n"  Posting is not permitted.
+
+   "m"  Postings will be forwarded to the newsgroup moderator.
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 16]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   This document defines three other case-sensitive status field values
+   that can also be used:
+
+   "x"  Postings and articles from peers are not permitted.
+
+   "j"  Only articles from peers are permitted; no articles are locally
+      filed.
+
+   "=other.group"  Only articles from peers are permitted, and 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.
+
+   A newsgroup with status "x" is a newsgroup with status "n", except
+   that articles from peers are not accepted.  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 either of these two status field values.
+
+   A newsgroup with status "j" is a newsgroup with status "y", except
+   that (1) local postings are not accepted, (2) articles received from
+   a peer that are crossposted to one or more valid groups are filed
+   only into those valid groups, and (3) articles received from a peer
+   that are not crossposted to any valid groups are not filed into any
+   newsgroup, but are still propagated to other peers, if appropriate.
+
+      NOTE: Instead of not filing at all an article posted to a
+      newsgroup with status "j", a news server MAY file it under a
+      catch-all group if no valid group is applicable.  When a news
+      server uses a catch-all group to file the articles posted to
+      newsgroups with status "j", this catch-all group SHOULD be named
+      "junk".  (The first letter of the "junk" newsgroup explains why
+      this status has been called "j".)
+
+      Consequently, when a news server carries the "junk" newsgroup and
+      uses it for the purpose of the "j" status, the "junk" newsgroup
+      contains all postings not filed under another newsgroup,
+      regardless of the status of the "junk" newsgroup.  (However, an
+      article posted explicitly to "junk" is treated according to the
+      status of the "junk" newsgroup.)
+
+      The "junk" newsgroup may be available to news readers and is often
+      used by a news server as a way to locally store an article that
+      will be transmitted to peers (which may carry some of the
+      newsgroups the article was posted to even if the local server does
+      not).  In addition, instead of rejecting an article that contains
+
+
+
+Elie                         Standards Track                   [Page 17]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+      an invalid Newsgroups header field or that is posted to newsgroups
+      it does not carry, a news server may accept such an article and
+      file it under the catch-all newsgroup.
+
+      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 for unknown newsgroups may be
+      rejected.
+
+   When the status field value begins with an equal sign ("=" or %x3D),
+   a newsgroup name on the news server MUST immediately follow the sign.
+   If the status 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 filed into "other.group", regardless of
+   the status of "other.group".  The contents of their Newsgroups header
+   fields MUST NOT be altered.
+
+   Alias groups are typically used during a transition between two
+   newsgroups, including but not limited to a renaming of a group, or a
+   correction of a misspelled group name.
+
+   The status of the newsgroup an alias points to MUST NOT be taken into
+   account when an article arrives in an alias newsgroup.  In
+   particular, it means that unapproved articles arriving from peers in
+   an alias pointing to a moderated newsgroup are accepted and filed
+   into this moderated newsgroup.  Therefore, an alias SHOULD NOT point
+   to a moderated newsgroup, since it allows bypassing of the
+   moderation.
+
+   An alias SHOULD NOT point to itself or another alias group.  The
+   newsgroup an alias points to SHOULD exist on the news server, and be
+   visible to any client that can see the original group.  However, when
+   a client issues a LIST ACTIVE command with a wildmat including the
+   original group, the newsgroup it points to is not listed in the
+   response (unless of course the second newsgroup also matches the
+   wildmat).
+
+      NOTE: If a server files newsgroups with status "j" into "junk", a
+      newsgroup with status "j" and a newsgroup with status "=junk" are
+      different.  An article fed by a peer, and crossposted to a group
+      with status "j", will result in the article being filed only in
+      "junk" if there are no other groups with which to file it, or
+      otherwise only in other valid newsgroups it is crossposted to.  On
+      the other hand, an article fed by a peer, and crossposted to a
+      group with status "=junk", will result in the article being filed
+      in "junk" and in other valid newsgroups it is crossposted to.
+
+
+
+Elie                         Standards Track                   [Page 18]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   The following table summarizes what usually happens to an article
+   posted to only the newsgroup "foo.bar", depending on its status field
+   value on the news server:
+
+   +---------------+------------+-----------+------------+-------------+
+   | Status field  | Accepted   | Accepted  | Moderation | Destination |
+   | value of      | if local   | from      | needed?    | if accepted |
+   | "foo.bar"     | posting?   | peers?    |            |             |
+   +---------------+------------+-----------+------------+-------------+
+   | y             | Yes        | Yes       | No         | foo.bar     |
+   | n             | No         | Yes       | No         | foo.bar     |
+   | m             | Yes        | Yes       | Yes        | foo.bar     |
+   | x             | No         | No        | No         |             |
+   | j             | No         | Yes       | No         | junk (if    |
+   |               |            |           |            | filed)      |
+   | =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 value of "foo.bar" on the news server:
+
+   +---------------+-----------+-----------+------------+--------------+
+   | Status field  | Accepted  | Accepted  | Moderation | Destination  |
+   | value of      | if local  | from      | needed?    | if accepted  |
+   | "foo.bar"     | 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    |
+   | x             | No        | Yes       | No         | misc.test    |
+   | j             | 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 for 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.
+
+
+
+
+
+Elie                         Standards Track                   [Page 19]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+3.2.  Examples
+
+   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 2008 16:02:45 +0200
+      [C] Organization: An example, Paris, FR.
+      [C] Message-ID: <for.misc.test@example.com>
+      [C] MIME-Version: 1.0
+      [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.example.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 field of this article is kept untouched.  This
+   article is filed under "foo.bar" even though it has originally been
+   posted to the newsgroup "misc.test".  Yet, it still propagates to
+   peers that have been configured to receive articles posted to
+   "misc.text".
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 20]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   Example of an article locally posted to an alias group:
+
+      [C] LIST ACTIVE
+      [S] 215 List of newsgroups follows
+      [S] foo.bar 22 12 y
+      [S] misc.test 3002322 3000234 =foo.bar
+      [S] .
+      [C] POST
+      [S] 340 Input article; end with <CR-LF>.<CR-LF>
+      [C] From: "Demo User" <nobody@example.com>
+      [C] Newsgroups: misc.test
+      [C] Subject: I am just a test article
+      [C] MIME-Version: 1.0
+      [C]
+      [C] This is just a test article.
+      [C] .
+      [S] 441 Newsgroup "misc.test" has been renamed to "foo.bar"
+
+   The article is rejected, with a detailed error.
+
+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.
+
+4.1.  Commands
+
+   This syntax extends the non-terminal <list-arguments>, which
+   represents the variants of the LIST command.
+
+     ; counts
+     list-arguments =/ "COUNTS" [WS wildmat]
+
+     ; 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 represent the status field value returned by
+   the LIST ACTIVE command and the response contents for the LIST
+   command, respectively.
+
+
+
+Elie                         Standards Track                   [Page 21]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+     ; active
+     newsgroup-status =/ newsgroup-alias /
+           %x78 / %x6a  ; case-sensitive "x" and "j"
+     newsgroup-alias =  "=" newsgroup-name
+
+     ; counts
+     list-content =/ list-counts-content
+     list-counts-content =
+           *(newsgroup-name 3(SPA article-number)
+           SPA newsgroup-status CRLF)
+
+     ; distributions
+     list-content =/ list-distributions-content
+     list-distributions-content =
+           *(distribution WS distribution-description CRLF)
+     distribution-description = U-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.  Internationalization Considerations
+
+   No new internationalization considerations are introduced by this
+   extension, beyond those already described in the core specification
+   [RFC3977].
+
+   In particular, newsgroup names SHOULD be restricted to US-ASCII
+   [ASCII] until a successor to [RFC5536] standardizes another approach.
+
+   Distribution descriptions and the message of the day MUST be in UTF-8
+   [RFC3629].
+
+
+
+
+
+
+
+
+
+Elie                         Standards Track                   [Page 22]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+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 Protocols specification [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.  It extends the
+   LIST capability label defined in Section 7.6 of [RFC3977].
+
+   o  This extension provides additional keywords to the pre-existing
+      LIST capability defined in Section 7.6 of [RFC3977].  New status
+      field values 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 five optional arguments to the "LIST"
+      capability label: "COUNTS", "DISTRIBUTIONS", "MODERATORS", "MOTD",
+      and "SUBSCRIPTIONS", indicating which new variants of the LIST
+      command are supported.  Consequently, this extension associates
+      these new arguments with the pre-existing "LIST" NNTP command.
+
+   o  This extension defines five new commands, LIST COUNTS, LIST
+      DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS,
+      whose behavior, arguments, and responses are defined in
+      Sections 2.2, 2.3, 2.4, 2.5, and 2.6, 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.  The LIST COUNTS, LIST
+      DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS
+      commands can be pipelined.
+
+   o  Use of this extension does not alter the capabilities list.
+
+   o  This extension does not cause any pre-existing command to produce
+      a 401, 480, or 483 response.
+
+
+
+
+
+Elie                         Standards Track                   [Page 23]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   o  This extension is unaffected by any use of the MODE READER
+      command.
+
+   o  This extension does not affect the overall behavior of a server or
+      client other than via the new commands.
+
+   o  Published Specification: This document.
+
+   o  Contact for Further Information: Author of this document.
+
+   o  Change Controller: IESG <iesg@ietf.org>.
+
+8.  Acknowledgements
+
+   The author gratefully acknowledges the comments and additional
+   information provided by Russ Allbery, Urs Janssen, Antti-Juhani
+   Kaijanaho, Alexey Melnikov, Peter Saint-Andre, Dieter Stussy, and
+   Sean Turner on this document.
+
+   The author would particularly like to thank Jeffrey M. Vinocur for
+   having reread, improved, and patiently fixed the English wording and
+   the quality of this document.
+
+   Special thanks are due to:
+
+      Stan Barber, whose text in [RFC2980] served as the initial basis
+      for the DISTRIBUTIONS and SUBSCRIPTIONS variants of the LIST
+      command.
+
+      Brian Hernacki, whose text in [NNTP_LIST] served as the initial
+      basis for the MOTD and also the SUBSCRIPTIONS variants of the LIST
+      command.
+
+      The authors of the documentation of a few sample files of the
+      InterNetNews news server ("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.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+
+
+
+Elie                         Standards Track                   [Page 24]
+
+RFC 6048             NNTP Additions to LIST Command        November 2010
+
+
+   [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.
+
+   [RFC5322]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
+                October 2008.
+
+9.2.  Informative References
+
+   [ASCII]      American National Standards Institute, "Coded Character
+                Sets - 7-Bit American Standard Code for Information
+                Interchange (7-Bit ASCII), ANSI X3.4", 1986.
+
+   [NNTP_LIST]  Hernacki, B., "NNTP LIST Additions", Work in Progress,
+                July 1997.
+
+   [RFC2980]    Barber, S., "Common NNTP Extensions", RFC 2980,
+                October 2000.
+
+   [RFC5536]    Murchison, K., Lindsey, C., and D. Kohn, "Netnews
+                Article Format", RFC 5536, November 2009.
+
+   [RFC5537]    Allbery, R. and C. Lindsey, "Netnews Architecture and
+                Protocols", RFC 5537, November 2009.
+
+   [USEAGE]     Lindsey, C., "Usenet Best Practice", 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                         Standards Track                   [Page 25]
+