rfc2980.txt

中、英文RFC文档大全打包下载完全版 .

   question mark (?) to match any single character.  The third specifies
   a specific set of characters.  The set is specified as a list of
   characters, or as a range of characters where the beginning and end
   of the range are separated by a minus (or dash) character, or as any
   combination of lists and ranges.  The dash can also be included in
   the set as a character it if is the beginning or end of the set.
   This set is enclosed in square brackets.  The close square bracket
   (]) may be used in a set if it is the first character in the set.
   The fourth operation is the same as the logical not of the third
   operation and is specified the same way as the third with the
   addition of a caret character (^) at the beginning of the test string
   just inside the open square bracket.  The final operation uses the
   backslash character to invalidate the special meaning of the a open
   square bracket ([), the asterisk, backslash or the question mark.
   Two backslashes in sequence will result in the evaluation of the
   backslash as a character with no special meaning.

3.3.1 Examples

   a. [^]-] -- matches any single character other than a close square
               bracket or a minus sign/dash.

   b. *bdc  -- matches any string that ends with the string "bdc"
               including the string "bdc" (without quotes).

   c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
               character.

   d. a??d  --  matches any four character string which begins
                with a and ends with d.










Barber                       Informational                     [Page 21]

RFC 2980                 Common NNTP Extensions             October 2000


3.4 Additional Headers

   Many NNTP implementations add headers to Usenet articles when then
   are POSTed via NNTP.  These headers are discussed in this section.
   None of these headers conflict with those specified in RFC 1036 and
   should be passed unchanged by Usenet transports conforming to RFC
   1036.

3.4.1 NNTP-Posting-Host

   This line is added to the header of a posted article by the server.
   The contents of the header is either the IP address or the fully
   qualified domain name of the client host posting the article.  The
   fully qualified domain name should be determined by doing a reverse
   lookup in the DNS on the IP address of the client.  If the client
   article contains this line, it is removed by the server before
   acceptance of the article by the Usenet transport system.

   This header provides some idea of the actual host posting the article
   as opposed to information in the Sender or From lines that may be
   present in the article.  This is not a fool-proof methodology since
   reverse lookups in the DNS are vulnerable to certain types of
   spoofing, but such discussions are outside the scope of this
   document.

3.4.2 X-Newsreader and others


   There are other lines that are added by clients as well.  Most of
   these indicate the type of newsreader software that is posting the
   article.

4.0 Common Implementation Issues

   Many NNTP implementations do not follow the specifications in RFC
   977.  In this section, some common implementation issues are
   summarized.

4.1 The Response to the LIST command

   RFC 977 says that the fourth field of the "list of valid newsgroups
   associated information" returned must be "either 'y' or 'n'
   indicating whether posting to this newsgroup is allowed ('y') or
   prohibited ('n').  Most implementations simply output the exact
   contents of the transport system's active newsgroup list.  For more
   implementations, the fourth field usually has more values that 'y' or
   'n'.




Barber                       Informational                     [Page 22]

RFC 2980                 Common NNTP Extensions             October 2000


4.2 The Required Headers in an Article and the POST command

   RFC 977 notes in section 3.10.1 that articles presented "should
   include all required header lines." In fact, modern implementations
   only require From, Subject, and Newsgroups header lines and will
   supply the rest; further, many implementers believe that it is best
   for clients to generate as few headers as possible, since clients
   often do not format other headers correctly.

   This implementation behavior is consistent with both Bnews and Cnews
   which would supply missing headers for articles directly submitted to
   them.

4.3 Article Numbering

   RFC 977 does not directly address the rules concerning articles
   number.  However, the current practice is simple: article numbers are
   monotonically increasing, articles may disappear, and therefore the
   high and low water marks returned in a GROUP command should be
   treated as maximum minima, and minimum maxima, respectively.

4.4 Availability of commands defined in RFC 977

   Some implementations permit administrators to disable commands
   defined RFC 977.  Some implementations have some set of commands
   disabled by default.  This means that client implementations cannot
   depend on the availability of the disabled set of commands.  This
   increases the complexity of the client and does not encourage
   implementors to optimize the implementation of commands that don't
   perform well.

   NEWNEWS is one of the commands frequently disabled.

4.5 The Distribution header and NEWNEWS

   In section 12.4 of RFC 977, the optional distributions argument is
   described.  This argument, according to RFC 977, would limit the
   responses to articles that were in newsgroups with prefixes that
   matched the optional distributions argument.

   Some implementations implement this by matching the Distributions
   header in articles to the distribution argument.  Others do the match
   against segments of the newsgroup's name.

   This variation is probably best explained by the evolution of the
   USENET article format.  At the time RFC 977 was specified, the
   newsgroup name defined how the group was distributed throughout
   USENET.  RFC 1036 changed this convention.  So, those that are



Barber                       Informational                     [Page 23]

RFC 2980                 Common NNTP Extensions             October 2000


   strictly implementing RFC 977 would match the newsgroup name prefix
   against the distribution argument and only display matches.  Those
   that implement against the intent of the command (as modified by the
   redefinition of the article format)would match the Distributions
   header against the distribution argument and only display those
   matches.

5.0 Further Work

   With the continued use of NNTP on the Internet, there remains an
   interest in creating an optimized transport protocol for server-to-
   server transfers and an optimized client protocol for client-to-
   server interactions.  There is also considerable interest is building
   better mechanisms to provide audit information on which news groups
   are being read by which users.

   An IETF working group has been formed and it is the hope of this
   author that these issues will be addressed in that forum.

6.0 Security Considerations

   The use of the AUTHINFO is optional.  This command as documented has
   a number of security implications.  In the original and simple forms,
   all passwords are passed in plaintext and could be discovered by
   various forms of network or system surveillance.  The AUTHINFO
   GENERIC command has the potential for the same problems if a
   mechanism is used that also passes cleartext passwords.  RFC 1731 [8]
   discusses these issues in greater detail.

7.0 References

   [1]  Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC
        977, February 1986.

   [2]  Limoncelli, Tom, "Read This Before You Write a Newsreader",
        http://mars.superlink.net/tal/news-software-authors.html, June,
        1996.

   [3]  Horton, M. and R. Adams, "Standard for interchange of USENET
        messages",  RFC 1036, December 1987.

   [4]  Salz, Rich, Manual Page for wildmat(3) from the INN 1.4
        distribution, UUNET Technologies, Revision 1.10, April, 1992.

   [5]  Robertson, Rob, "FAQ: Overview database / NOV General
        Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-
        nov.Z, January, 1995.




Barber                       Informational                     [Page 24]

RFC 2980                 Common NNTP Extensions             October 2000


   [6]  Lea, Iain, "FAQ about the TIN newsreader",
        http://www.cs.unca.edu/~davidson/handouts/tinfaq.html

   [7]  Kappesser, Peter, "[news.software.readers] trn newsreader FAQ",
        2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/
        software/readers/%5Bnews.software.readers%5D_trn_newsreader
        _FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by
        -hierarchy/news/software/readers/%5Bnews.software.readers
        %5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.

   [8]  Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
        December 1994.

   [9]  Mills, D., "Network Time Protocol (Version 3), Specification,
        Implementation and Analysis", RFC 1305, March 1992.

8.0 Notes

   DEC is a registered trademark of Compaq Computer Corporation.  UNIX
   is a registered trademark of The Open Group.  VMS is a registered
   trademark of Compaq Computer Corporation.

9.0 Acknowledgments

   The author gratefully acknowledges the comments and additional
   information provided by the following individuals:

   Wayne Davison <[e-mail]>
   Chris Lewis <[e-mail]>
   Tom Limoncelli <[e-mail]>
   Eric Schnoebelen <[e-mail]>
   Rich Salz <[e-mail]>

   This work was precipitated by the work of various newsreader authors
   and newsserver authors which includes those listed below:

   Rick Adams    -- Original author of the NNTP extensions to the RN
                    newsreader and last maintainer of Bnews
   Stan Barber   -- Original author of the NNTP extensions to the
                    newsreaders that are part of Bnews.
   Geoff Collyer -- Original author of the OVERVIEW database proposal and
                    one of the original authors of CNEWS
   Dan Curry     -- Original author of the xvnews newsreader
   Wayne Davison -- Author of the first threading extensions to the
                    RN newsreader (commonly called TRN).
   Geoff Huston  -- Original author of ANU NEWS





Barber                       Informational                     [Page 25]

RFC 2980                 Common NNTP Extensions             October 2000


   Phil Lapsey   -- Original author of the UNIX reference
                    implementation
   Iain Lea      -- Original maintainer of the TIN newsreader
   Chris Lewis   -- First known implementor of the AUTHINFO GENERIC
                    extension
   Rich Salz     -- Original author of INN
   Henry Spencer -- One of the original authors of CNEWS
   Kim Storm     -- Original author of the NN newsreader

10.0 Author's Address

   Stan Barber
   P.O. Box 300481
   Houston, Texas, 77230

   EMail: [e-mail]



































Barber                       Informational                     [Page 26]

RFC 2980                 Common NNTP Extensions             October 2000


11.0 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barber                       Informational                     [Page 27]