Section 14. References

14.1.  Normative References
   [ANSI1986]    American National Standards Institute, "Coded Character
                 Set - 7-bit American Standard Code for Information
                 Interchange", ANSI X3.4, 1986.
   [RFC977]      Kantor, B. and P. Lapsley, "Network News Transfer
   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
                 Mail Extensions (MIME) Part One: Format of Internet
   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
                 Extensions) Part Three: Message Header Extensions for
   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
   [RFC4234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
   [RFC4648]     Josefsson, S., "The Base16, Base32, and Base64 Data
   [TF.686-1]    International Telecommunications Union - Radio,
                 "Glossary, ITU-R Recommendation TF.686-1",
                 ITU-R Recommendation TF.686-1, October 1997.
14.2.  Informative References
   [NNTP-AUTH]   Vinocur, J., Murchison, K., and C. Newman, "Network
                 News Transfer Protocol (NNTP) Extension for
                 Authentication",
   [NNTP-STREAM] Vinocur, J. and K. Murchison, "Network News Transfer
                 Protocol (NNTP) Extension for Streaming Feeds",
   [NNTP-TLS]    Murchison, K., Vinocur, J., and C. Newman, "Using
                 Transport Layer Security (TLS) with Network News
   [RFC1036]     Horton, M. and R. Adams, "Standard for interchange of
   [RFC1305]     Mills, D., "Network Time Protocol (Version 3)
                 Specification, Implementation and Analysis", RFC 1305,
                 March 1992.
   [RFC1869]     Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
                 Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
                 November 1995.
   [RFC2616]     Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
   [RFC2629]     Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
                 June 1999.
   [RFC2822]     Resnick, P., "Internet Message Format", RFC 2822, April
                 2001.
   [RFC2980]     Barber, S., "Common NNTP Extensions", RFC 2980, October
                 2000.
   [ROBE1995]    Robertson, R., "FAQ: Overview database / NOV General
                 Information", January 1995.
                 There is no definitive copy of this document known to
                 the author.  It was previously posted as the Usenet
                 article <news:nov-faq-1-930909720@agate.Berkeley.EDU>
   [SALZ1992]    Salz, R., "Manual Page for wildmat(3) from the INN 1.4
                 distribution, Revision 1.10", April 1992.
                 There is no definitive copy of this document known to
                 the author.
Appendix A.  Interaction with Other Specifications
   NNTP is most often used for transferring articles that conform to
   RFC 1036 [RFC1036] (such articles are called "Netnews articles"
   here).  It is also sometimes used for transferring email messages
   that conform to RFC 2822 [RFC2822] (such articles are called "email
   articles" here).  In this situation, articles must conform both to
   this specification and to that other one; this appendix describes
   some relevant issues.
A.1.  Header Folding
   NNTP allows a header line to be folded (by inserting a CRLF pair)
   before any space or TAB character.
   Both email and Netnews articles are required to have at least one
   octet other than space or TAB on each header line.  Thus, folding can
   only happen at one point in each sequence of consecutive spaces or
   TABs.  Netnews articles are further required to have the header name,
   colon, and following space all on the first line; folding may only
   happen beyond that space.  Finally, some non-conforming software will
   remove trailing spaces and TABs from a line.  Therefore, it might be
   inadvisable to fold a header after a space or TAB.
   For maximum safety, header lines SHOULD conform to the following
   syntax rather than to that in Section 9.7.
     header = header-name ":" SP [header-content] CRLF
     header-content = [WS] token *( [CRLF] WS token )
A.2.  Message-IDs
   Every article handled by an NNTP server MUST have a unique
   message-id.  For the purposes of this specification, a message-id is
   an arbitrary opaque string that merely needs to meet certain
   syntactic requirements and is just a way to refer to the article.
   Because there is a significant risk that old articles will be
   reinjected into the global Usenet system, RFC 1036 [RFC1036] requires
   that message-ids are globally unique for all time.
   This specification states that message-ids are the same if and only
   if they consist of the same sequence of octets.  Other specifications
   may define two different sequences as being equal because they are
   putting an interpretation on particular characters.  RFC 2822
   [RFC2822] has a concept of "quoted" and "escaped" characters.  It
   therefore considers the three message-ids:
      <ab.cd@example.com>
      <"ab.cd"@example.com>
      <"ab.\cd"@example.com>
   as being identical.  Therefore, an NNTP implementation handing email
   articles must ensure that only one of these three appears in the
   protocol and that the other two are converted to it as and when
   necessary, such as when a client checks the results of a NEWNEWS
   command against an internal database of message-ids.  Note that
   RFC 1036 [RFC1036] never treats two different strings as being
   identical.  Its successor (as of the time of writing) restricts the
   syntax of message-ids so that, whenever RFC 2822 would treat two
   strings as equivalent, only one of them is valid (in the above
   example, only the first string is valid).
   This specification does not describe how the message-id of an article
   is determined; it may be deduced from the contents of the article or
   derived from some external source.  If the server is also conforming
   to another specification that contains a definition of message-id
   compatible with this one, the server SHOULD use those message-ids.  A
   common approach, and one that SHOULD be used for email and Netnews
   articles, is to extract the message-id from the contents of a header
   with name "Message-ID".  This may not be as simple as copying the
   entire header contents; it may be necessary to strip off comments and
   undo quoting, or to reduce "equivalent" message-ids to a canonical
   form.
   If an article is obtained through the IHAVE command, there will be a
   message-id provided with the command.  The server MAY either use it
   or determine one from the article contents.  However, whichever it
   does, it SHOULD ensure that, if the IHAVE command is repeated with
   the same argument and article, it will be recognized as a duplicate.
   If an article does not contain a message-id that the server can
   identify, it MUST synthesize one.  This could, for example, be a
   simple sequence number or be based on the date and time when the
   article arrived.  When email or Netnews articles are handled, a
   Message-ID header SHOULD be added to ensure global consistency and
   uniqueness.
   Note that, because the message-id might not have been derived from
   the Message-ID header in the article, the following example is
   legitimate (though unusual):
      [C] HEAD <45223423@example.com>
      [S] 221 0 <45223423@example.com>
      [S] Path: pathost!demo!whitehouse!not-for-mail
      [S] Message-ID: <1234@example.net>
      [S] From: "Demo User" <nobody@example.net>
      [S] Newsgroups: misc.test
      [S] Subject: I am just a test article
      [S] Date: 6 Oct 1998 04:38:40 -0500
      [S] Organization: An Example Net, Uncertain, Texas
      [S] .
A.3.  Article Posting
   As far as NNTP is concerned, the POST and IHAVE commands provide the
   same basic facilities in a slightly different way.  However, they
   have rather different intentions.
   The IHAVE command is intended for transmitting conforming articles
   between a system of NNTP servers, with all articles perhaps also
   conforming to another specification (e.g., all articles are Netnews
   articles).  It is expected that the client will already have done any
   necessary validation (or that it has in turn obtained the article
   from a third party that has done so); therefore, the contents SHOULD
   be left unchanged.
   In contrast, the POST command is intended for use when an end-user is
   injecting a newly created article into a such a system.  The article
   being transferred might not be a conforming email or Netnews article,
   and the server is expected to validate it and, if necessary, to
   convert it to the right form for onward distribution.  This is often
   done by a separate piece of software on the server installation; if
   so, the NNTP server SHOULD pass the incoming article to that software
   unaltered, making no attempt to filter characters, to fold or limit
   lines, or to process the incoming text otherwise.
   The POST command can fail in various ways, and clients should be
   prepared to re-send an article.  When doing so, however, it is often
   important to ensure (as far as possible) that the same message-id is
   allocated to both attempts so that the server, or other servers, can
   recognize the two articles as duplicates.  In the case of email or
   Netnews articles, therefore, the posted article SHOULD contain a
   header with the name "Message-ID", and the contents of this header
   SHOULD be identical on each attempt.  The server SHOULD ensure that
   two POSTed articles with the same contents for this header are
   recognized as identical and that the same message-id is allocated,
   whether or not those contents are suitable for use as the message-id.
Appendix B.  Summary of Commands
   This section contains a list of every command defined in this
   document, ordered by command name and by indicating capability.
                         Ordered by command name:
       +-------------------+-----------------------+---------------+
       | Command           | Indicating capability | Definition    |
       +-------------------+-----------------------+---------------+
       | ARTICLE           | READER                | Section 6.2.1 |
       | BODY              | READER                | Section 6.2.3 |
       | CAPABILITIES      | mandatory             | Section 5.2   |
       | DATE              | READER                | Section 7.1   |
       | GROUP             | READER                | Section 6.1.1 |
       | HDR               | HDR                   | Section 8.5   |
       | HEAD              | mandatory             | Section 6.2.2 |
       | HELP              | mandatory             | Section 7.2   |
       | IHAVE             | IHAVE                 | Section 6.3.2 |
       | LAST              | READER                | Section 6.1.3 |
       | LIST              | LIST                  | Section 7.6.1 |
       | LIST ACTIVE.TIMES | LIST                  | Section 7.6.4 |
       | LIST ACTIVE       | LIST                  | Section 7.6.3 |
       | LIST DISTRIB.PATS | LIST                  | Section 7.6.5 |
       | LIST HEADERS      | HDR                   | Section 8.6   |
       | LIST NEWSGROUPS   | LIST                  | Section 7.6.6 |
       | LIST OVERVIEW.FMT | OVER                  | Section 8.4   |
       | LISTGROUP         | READER                | Section 6.1.2 |
       | MODE READER       | MODE-READER           | Section 5.3   |
       | NEWGROUPS         | READER                | Section 7.3   |
       | NEWNEWS           | NEWNEWS               | Section 7.4   |
       | NEXT              | READER                | Section 6.1.4 |
       | OVER              | OVER                  | Section 8.3   |
       | POST              | POST                  | Section 6.3.1 |
       | QUIT              | mandatory             | Section 5.4   |
       | STAT              | mandatory             | Section 6.2.4 |
       +-------------------+-----------------------+---------------+
                     Ordered by indicating capability:
       +-------------------+-----------------------+---------------+
       | Command           | Indicating capability | Definition    |
       +-------------------+-----------------------+---------------+
       | CAPABILITIES      | mandatory             | Section 5.2   |
       | HEAD              | mandatory             | Section 6.2.2 |
       | HELP              | mandatory             | Section 7.2   |
       | QUIT              | mandatory             | Section 5.4   |
       | STAT              | mandatory             | Section 6.2.4 |
       | HDR               | HDR                   | Section 8.5   |
       | LIST HEADERS      | HDR                   | Section 8.6   |
       | IHAVE             | IHAVE                 | Section 6.3.2 |
       | LIST              | LIST                  | Section 7.6.1 |
       | LIST ACTIVE       | LIST                  | Section 7.6.3 |
       | LIST ACTIVE.TIMES | LIST                  | Section 7.6.4 |
       | LIST DISTRIB.PATS | LIST                  | Section 7.6.5 |
       | LIST NEWSGROUPS   | LIST                  | Section 7.6.6 |
       | MODE READER       | MODE-READER           | Section 5.3   |
       | NEWNEWS           | NEWNEWS               | Section 7.4   |
       | OVER              | OVER                  | Section 8.3   |
       | LIST OVERVIEW.FMT | OVER                  | Section 8.4   |
       | POST              | POST                  | Section 6.3.1 |
       | ARTICLE           | READER                | Section 6.2.1 |
       | BODY              | READER                | Section 6.2.3 |
       | DATE              | READER                | Section 7.1   |
       | GROUP             | READER                | Section 6.1.1 |
       | LAST              | READER                | Section 6.1.3 |
       | LISTGROUP         | READER                | Section 6.1.2 |
       | NEWGROUPS         | READER                | Section 7.3   |
       | NEXT              | READER                | Section 6.1.4 |
       +-------------------+-----------------------+---------------+
Appendix C.  Summary of Response Codes
   This section contains a list of every response code defined in this
   document and indicates whether it is multi-line, which commands can
   generate it, what arguments it has, and what its meaning is.
   Response code 100 (multi-line)
      Generated by: HELP
      Meaning: help text follows.
   Response code 101 (multi-line)
      Generated by: CAPABILITIES
      Meaning: capabilities list follows.
   Response code 111
      Generated by: DATE
      1 argument: yyyymmddhhmmss
      Meaning: server date and time.
   Response code 200
      Generated by: initial connection, MODE READER
      Meaning: service available, posting allowed.
   Response code 201
      Generated by: initial connection, MODE READER
      Meaning: service available, posting prohibited.
   Response code 205
      Generated by: QUIT
      Meaning: connection closing (the server immediately closes the
      connection).
   Response code 211
      The 211 response code has two completely different forms,
      depending on which command generated it:
         (not multi-line)
         Generated by: GROUP
         4 arguments: number low high group
         Meaning: group selected.
         (multi-line)
         Generated by: LISTGROUP
         4 arguments: number low high group
         Meaning: article numbers follow.
   Response code 215 (multi-line)
      Generated by: LIST
      Meaning: information follows.
   Response code 220 (multi-line)
      Generated by: ARTICLE
      2 arguments: n message-id
      Meaning: article follows.
   Response code 221 (multi-line)
      Generated by: HEAD
      2 arguments: n message-id
      Meaning: article headers follow.
   Response code 222 (multi-line)
      Generated by: BODY
      2 arguments: n message-id
      Meaning: article body follows.
   Response code 223
      Generated by: LAST, NEXT, STAT
      2 arguments: n message-id
      Meaning: article exists and selected.
   Response code 224 (multi-line)
      Generated by: OVER
      Meaning: overview information follows.
   Response code 225 (multi-line)
      Generated by: HDR
      Meaning: headers follow.
   Response code 230 (multi-line)
      Generated by: NEWNEWS
      Meaning: list of new articles follows.
   Response code 231 (multi-line)
      Generated by: NEWGROUPS
      Meaning: list of new newsgroups follows.
   Response code 235
      Generated by: IHAVE (second stage)
      Meaning: article transferred OK.
   Response code 240
      Generated by: POST (second stage)
      Meaning: article received OK.
   Response code 335
      Generated by: IHAVE (first stage)
      Meaning: send article to be transferred.
   Response code 340
      Generated by: POST (first stage)
      Meaning: send article to be posted.
   Response code 400
      Generic response and generated by initial connection
      Meaning: service not available or no longer available (the server
      immediately closes the connection).
   Response code 401
      Generic response
      1 argument: capability-label
      Meaning: the server is in the wrong mode; the indicated capability
      should be used to change the mode.
   Response code 403
      Generic response
      Meaning: internal fault or problem preventing action being taken.
   Response code 411
      Generated by: GROUP, LISTGROUP
      Meaning: no such newsgroup.
   Response code 412
      Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP,
      NEXT, OVER, STAT
      Meaning: no newsgroup selected.
   Response code 420
      Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT
      Meaning: current article number is invalid.
   Response code 421
      Generated by: NEXT
      Meaning: no next article in this group.
   Response code 422
      Generated by: LAST
      Meaning: no previous article in this group.
   Response code 423
      Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT
      Meaning: no article with that number or in that range.
   Response code 430
      Generated by: ARTICLE, BODY, HDR, HEAD, OVER, STAT
      Meaning: no article with that message-id.
   Response code 435
      Generated by: IHAVE (first stage)
      Meaning: article not wanted.
   Response code 436
      Generated by: IHAVE (either stage)
      Meaning: transfer not possible (first stage) or failed (second
      stage); try again later.
   Response code 437
      Generated by: IHAVE (second stage)
      Meaning: transfer rejected; do not retry.
   Response code 440
      Generated by: POST (first stage)
      Meaning: posting not permitted.
   Response code 441
      Generated by: POST (second stage)
      Meaning: posting failed.
   Response code 480
      Generic response
      Meaning: command unavailable until the client has authenticated
      itself.
   Response code 483
      Generic response
      Meaning: command unavailable until suitable privacy has been
      arranged.
   Response code 500
      Generic response
      Meaning: unknown command.
   Response code 501
      Generic response
      Meaning: syntax error in command.
   Response code 502
      Generic response and generated by initial connection
      Meaning for the initial connection and the MODE READER command:
      service permanently unavailable (the server immediately closes the
      connection).
      Meaning for all other commands: command not permitted (and there
      is no way for the client to change this).
   Response code 503
      Generic response
      Meaning: feature not supported.
   Response code 504
      Generic response
      Meaning: error in base64-encoding [RFC4648] of an argument.
Appendix D.  Changes from RFC 977
   In general every attempt has been made to ensure that the protocol
   specification in this document is compatible with the version
   specified in RFC 977 [RFC977] and the various facilities adopted from
   RFC 2980 [RFC2980].  However, there have been a number of changes,
   some compatible and some not.
   This appendix lists these changes.  It is not guaranteed to be
   exhaustive or correct and MUST NOT be relied on.
   o  A formal syntax specification (Section 9) has been added.
   o  The default character set is changed from US-ASCII [ANSI1986] to
      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8).  This
      matter is discussed further in Section 10.
   o  All articles are required to have a message-id, eliminating the
      "<0>" placeholder used in RFC 977 in some responses.
   o  The newsgroup name matching capabilities already documented in
      RFC 977 ("wildmats", Section 4) are clarified and extended.  The
      new facilities (e.g., the use of commas and exclamation marks) are
      allowed wherever wildmats appear in the protocol.
   o  Support for pipelining of commands (Section 3.5) is made
      mandatory.
   o  The principles behind response codes (Section 3.2) have been
      tidied up.  In particular:
      *  the x8x response code family, formerly used for private
         extensions, is now reserved for authentication and privacy
         extensions;
      *  the x9x response code family, formerly intended for debugging
         facilities, are now reserved for private extensions;
      *  the 502 and 503 generic response codes (Section 3.2.1) have
         been redefined;
      *  new 401, 403, 480, 483, and 504 generic response codes have
         been added.
   o  The rules for article numbering (Section 6) have been clarified
      (also see Section 6.1.1.2).
   o  The SLAVE command (which was ill-defined) is removed from the
      protocol.
   o  Four-digit years are permitted in the NEWNEWS (Section 7.4) and
      NEWGROUPS (Section 7.3) commands (two-digit years are still
      permitted).  The optional distribution parameter to these commands
      has been removed.
   o  The LIST command (Section 7.6.1) is greatly extended; the original
      is available as LIST ACTIVE, while new variants include
      ACTIVE.TIMES, DISTRIB.PATS, and NEWSGROUPS.  A new "m" status flag
      is added to the LIST ACTIVE response.
   o  A new CAPABILITIES command (Section 5.2) allows clients to
      determine what facilities are supported by a server.
   o  The DATE command (Section 7.1) is adopted from RFC 2980
      effectively unchanged.
   o  The LISTGROUP command (Section 6.1.2) is adopted from RFC 2980.
      An optional range argument has been added, and the 211 initial
      response line now has the same format as the 211 response from the
      GROUP command.
   o  The MODE READER command (Section 5.3) is adopted from RFC 2980 and
      its meaning and effects clarified.
   o  The XHDR command in RFC 2980 has been formalised as the new HDR
      (Section 8.5) and LIST HEADERS (Section 8.6) commands.
   o  The XOVER command in RFC 2980 has been formalised as the new OVER
      (Section 8.3) and LIST OVERVIEW.FMT (Section 8.4) commands.  The
      former can be applied to a message-id as well as to a range.
   o  The concept of article metadata (Section 8.1) has been formalised,
      allowing the Bytes and Lines pseudo-headers to be deprecated.
   Client authors should note in particular that lack of support for the
   CAPABILITIES command is a good indication that the server does not
   support this specification.
Author's Address
   Clive D.W. Feather
   THUS plc
   322 Regents Park Road
   London
   N3  2QQ
   United Kingdom
   Phone: +44 20 8495 6138
   Fax:   +44 870 051 9937
   EMail: clive@demon.net
   URI:   http://www.davros.org/
Full Copyright Statement
Copyright (C) The Internet Society (2006).
   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
Acknowledgement
   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).