[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 6048

Internet Engineering Task Force                                  J. Elie
(IETF)                                                   August 13, 2010
Internet-Draft
Updates:  2980, 3977
(if approved)
Intended status:  Standards Track
Expires:  February 14, 2011


    Network News Transfer Protocol (NNTP) Additions to LIST Command
                   draft-elie-nntp-list-additions-05

Abstract

   This document defines a set of enhancements to the Network News
   Transfer Protocol (NNTP) that allows 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on February 14, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Elie                    Expires February 14, 2011               [Page 1]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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 Simplified BSD License.










































Elie                    Expires February 14, 2011               [Page 2]

Internet-Draft       NNTP Additions to LIST Command          August 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  5
     1.2.  Author's Note  . . . . . . . . . . . . . . . . . . . . . .  5
   2.  New LIST Variants  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Advertising the New LIST Variants  . . . . . . . . . . . .  5
     2.2.  LIST COUNTS  . . . . . . . . . . . . . . . . . . . . . . .  6
       2.2.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.2.2.  Description  . . . . . . . . . . . . . . . . . . . . .  7
       2.2.3.  Examples . . . . . . . . . . . . . . . . . . . . . . .  8
     2.3.  LIST DISTRIBUTIONS . . . . . . . . . . . . . . . . . . . .  9
       2.3.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.3.2.  Description  . . . . . . . . . . . . . . . . . . . . .  9
       2.3.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . 10
     2.4.  LIST MODERATORS  . . . . . . . . . . . . . . . . . . . . . 11
       2.4.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . 11
       2.4.2.  Description  . . . . . . . . . . . . . . . . . . . . . 11
       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 . . . . . . . . . . . . . . . . . . . . 15
       2.6.1.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . 15
       2.6.2.  Description  . . . . . . . . . . . . . . . . . . . . . 15
       2.6.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . 16
   3.  Additions to LIST ACTIVE . . . . . . . . . . . . . . . . . . . 17
     3.1.  New status fields  . . . . . . . . . . . . . . . . . . . . 17
     3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.  Augmented BNF Syntax for These Additions to the LIST
       Command  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.1.  Commands . . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.2.  Responses  . . . . . . . . . . . . . . . . . . . . . . . . 22
   5.  Internationalization Considerations  . . . . . . . . . . . . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.   Document History (to be removed by RFC Editor
                 before publication)  . . . . . . . . . . . . . . . . 26
   Appendix A.1. Changes from -04 . . . . . . . . . . . . . . . . . . 26
   Appendix A.2. Changes from -03 . . . . . . . . . . . . . . . . . . 27
   Appendix A.3. Changes from -02 . . . . . . . . . . . . . . . . . . 27
   Appendix A.4. Changes from -01 . . . . . . . . . . . . . . . . . . 28
   Appendix A.5. Changes from -00 . . . . . . . . . . . . . . . . . . 28



Elie                    Expires February 14, 2011               [Page 3]

Internet-Draft       NNTP Additions to LIST Command          August 2010


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.
   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
   [I-D.draft-hernacki-nntplist] (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 fields in LIST ACTIVE responses have been
   specified:  "y", "n", and "m".  These status field values are
   particularly useful for readers since they describe local posting
   rights.  However, several other values 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 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].  Except where specifically stated otherwise,
   in the case of a conflict between these two documents, [RFC3977]
   takes precedence.





Elie                    Expires February 14, 2011               [Page 4]

Internet-Draft       NNTP Additions to LIST Command          August 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                    Expires February 14, 2011               [Page 5]

Internet-Draft       NNTP Additions to LIST Command          August 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)







Elie                    Expires February 14, 2011               [Page 6]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   Parameters
      wildmat    Groups of interest

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 to that 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 2.2 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 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



Elie                    Expires February 14, 2011               [Page 7]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   select with the GROUP command (see Section 6.1.1 of [RFC3977]).

   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 221176 220685 351 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 221176 220685 351 y
      [S] .

   Example of output on an implementation that includes leading zeroes:









Elie                    Expires February 14, 2011               [Page 8]

Internet-Draft       NNTP Additions to LIST Command          August 2010


      [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 0000221176 0000220685 351 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 have them.

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.

   The order of distributions in the 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



Elie                    Expires February 14, 2011               [Page 9]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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.

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] .







Elie                    Expires February 14, 2011              [Page 10]

Internet-Draft       NNTP Additions to LIST Command          August 2010


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
   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 unapproved article is locally posted to a moderated newsgroup
   (see Section 3.5.1 of [RFC5537]), the server generates a submission
   address from the corresponding submission template (that is, the



Elie                    Expires February 14, 2011              [Page 11]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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 is changed to a
   dash ("-" or %x2D).  In addition, any "%%" is changed back to "%".
   The server then forwards the submitted article to moderator at the
   resulting submission address.

      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.

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 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 |




Elie                    Expires February 14, 2011              [Page 12]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   | 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 [I-D.ietf-usefor-useage] for the syntax of a
      newsgroup name.

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



Elie                    Expires February 14, 2011              [Page 13]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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,
   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:

















Elie                    Expires February 14, 2011              [Page 14]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   [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

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 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



Elie                    Expires February 14, 2011              [Page 15]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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, 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.

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



Elie                    Expires February 14, 2011              [Page 16]

Internet-Draft       NNTP Additions to LIST Command          August 2010


      [S] .

3.  Additions to LIST ACTIVE

   This document specifies three new status fields that can be used in
   the answers to LIST ACTIVE:  "x", "j", and "=" followed by the name
   of a newsgroup.

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]:

   "y"  Posting is permitted.

   "n"  Posting is not permitted.

   "m"  Postings will be forwarded to the newsgroup moderator.

   This document defines three other case-sensitive status which 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 of either these two status.

   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, (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.



Elie                    Expires February 14, 2011              [Page 17]

Internet-Draft       NNTP Additions to LIST Command          August 2010


      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
      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 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 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



Elie                    Expires February 14, 2011              [Page 18]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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.
      Whereas 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.

   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:

   +--------------+-----------+------------+------------+--------------+
   | 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      |
   | 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 of "foo.bar" on the news server:









Elie                    Expires February 14, 2011              [Page 19]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   +--------------+-----------+------------+------------+--------------+
   | 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    |
   | 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.

3.2.  Examples

   Example of an article posted to an alias group by a peer:
























Elie                    Expires February 14, 2011              [Page 20]

Internet-Draft       NNTP Additions to LIST Command          August 2010


      [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, and still propagates to other peers, to the newsgroup
   "misc.test".

   Example of an article locally posted to an alias group:












Elie                    Expires February 14, 2011              [Page 21]

Internet-Draft       NNTP Additions to LIST Command          August 2010


      [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 respectively represent the status field returned by
   the LIST ACTIVE command and the response contents for the LIST
   command.





Elie                    Expires February 14, 2011              [Page 22]

Internet-Draft       NNTP Additions to LIST Command          August 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 = 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.  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].

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



Elie                    Expires February 14, 2011              [Page 23]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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
      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 behaviour, 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.

   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 other than via the new commands.




Elie                    Expires February 14, 2011              [Page 24]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   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 [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 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.

   [RFC3977]                      Feather, C., "Network News Transfer
                                  Protocol (NNTP)", RFC 3977,
                                  October 2006.

   [RFC5234]                      Crocker, D. and P. Overell, "Augmented



Elie                    Expires February 14, 2011              [Page 25]

Internet-Draft       NNTP Additions to LIST Command          August 2010


                                  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.

   [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., 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.

   [I-D.ietf-usefor-useage]       Lindsey, C., "Usenet Best Practice",
                                  draft-ietf-usefor-useage-01 (work in
                                  progress), March 2005.

Appendix A.  Document History (to be removed by RFC Editor before
             publication)

Appendix A.1.  Changes from -04

   o  Fix a few nits which were found during IESG Evaluation.  The most
      important are:  in Section 2, "optional" is changed to "OPTIONAL";
      in Section 2.4.2, "SHOULD NOT occur" is changed to "should not
      occur".  Thanks to Sean Turner and Peter Saint-Andre.

   o  Show in the example of LIST DISTRIBUTIONS that descriptions of
      distributions not present in the distrib.pats list can be
      mentioned in the distributions list.





Elie                    Expires February 14, 2011              [Page 26]

Internet-Draft       NNTP Additions to LIST Command          August 2010


Appendix A.2.  Changes from -03

   o  This document is no longer an independent submission.  It is now
      sponsored by an Area Director, Alexey Melnikov.  Many thanks to
      him!

   o  Modify the note about the "%s" pattern rule for the moderation
      submission template for two moderated newsgroups whose names
      differ only by the case of their characters:  mention the reason
      and the fact that it is only a recommendation.

   o  Mention that TAB characters are not valid separators for the LIST
      COUNTS command.

   o  Add an example of wildmat preceded by "!".

   o  Re-work the BNF syntax for "newsgroup-alias" because it could be a
      little confusing.  Thanks to Gen-ART for the remark during Last
      Call.

   o  Add a MIME-Version:  header field in the examples of postings.
      They now comply with [RFC5536].

   o  Clarify what is expected from IANA (add a reference to this
      document for the LIST NNTP extension).

   o  Use "news.example.com" instead of "news.server.com" in an Xref:
      header field so as to have a compliant FQDN.

   o  Use the right boilerplate for [RFC2119].

   o  Add a reference to [RFC5322] for the submission template.

Appendix A.3.  Changes from -02

   o  No longer document the "Y" and "M" status.  It is better to stick
      with status that already have an implementation for Proposed
      Standard.

   o  Mention that the status of the newsgroup an alias points to MUST
      NOT be taken into account when an article arrives in an alias
      newsgroup.  Also point out the fact that it can lead to file
      unapproved articles into moderated newsgroups.

   o  Clarify that the catch-all group MAY be used when no valid group
      is applicable.





Elie                    Expires February 14, 2011              [Page 27]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   o  Add a reference to [RFC3629].

Appendix A.4.  Changes from -01

   o  Acknowledge Jeffrey M. Vinocur's wording fixes and remarks.

   o  Add a note about how the client should cache the motd.

   o  Mention that a news server need not consistently return the same
      order or the same results if the LIST COUNTS command is used more
      than once in a session.

   o  Mention that a news server need not return distributions in the
      same order between the DISTRIB.PATS and DISTRIBUTIONS variants of
      the LIST command.

   o  Introduce the notion of "template" in LIST MODERATORS responses.

   o  Use MUST for the presence of "%s" in submission templates.

   o  Use the right "header field" and "header field body" terminology.

Appendix A.5.  Changes from -00

   o  Add this appendix.

   o  Acknowledge Antti-Juhani Kaijanaho's and D. Stussy's remarks.

   o  Refer to USEFOR ([RFC5536]) and USEAGE ([I-D.ietf-usefor-useage])
      instead of putting a SHOULD requirement on the name of newsgroups
      in the example of the LIST MODERATORS command.  Besides, the note
      was only related to the presence of "%s" in the submission address
      template.

   o  Mention that every moderated newsgroup name SHOULD have a matching
      line in LIST MODERATORS, if no default entry exists.

   o  The presence of "+" in the name of a moderated newsgroup is a
      matter of configuration and should not be dealt with in this memo.
      If any special interpretation is applied by the mail system of the
      receiving site, and if they want to host a submission address for
      a moderated group determined by a "%s" pattern rule, they will
      need to suppress that interpretation.

   o  Lowercase a "MAY" for the reject of articles arriving for unknown
      newsgroups.





Elie                    Expires February 14, 2011              [Page 28]

Internet-Draft       NNTP Additions to LIST Command          August 2010


   o  The meaning of the "j" status flag has changed:  the "junk"
      newsgroup is no longer required.  A group with status "j" now only
      means that no articles are filed under it.  Moreover, local
      postings to "j" newsgroups are not accepted.

   o  Add an explanation about how the status of the "junk" newsgroup
      affects articles posted to "junk" or newsgroups with status "j".

   o  Add a note about the difference between the "j" and "=junk"
      status.

   o  The status of the newsgroup to which an alias group points is no
      longer checked.  An article is directly filed under it.  Besides,
      the requirement for an alias not pointing to another alias group
      becomes a SHOULD NOT instead of a MUST NOT.

   o  Add an example of article locally posted to an alias group.

   o  Remove the fact that if a news server may accept articles from a
      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.

   o  Document the "Y" and "M" status.

   o  Document the COUNTS variant for the LIST command.

   o  The "r" status flag will be documented in another (experimental)
      draft.  A new REMOVALS variant for the LIST command is needed.

   o  Add a reference to [ASCII].

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 February 14, 2011              [Page 29]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/