home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / nntpext / nntpext-charter.txt < prev   
Text File  |  1997-10-28  |  6KB  |  135 lines
  1.  
  2. NNTP Extensions (nntpext)
  3. -------------------------
  4.  
  5.  Charter 
  6.  Last Modified: 27-Oct-97
  7.  
  8.  Current Status: Active Working Group
  9.  
  10.  Chair(s):
  11.      Ned Freed <ned@innosoft.com>
  12.      Stan Barber <sob@academ.com>
  13.  
  14.  Applications Area Director(s): 
  15.      Keith Moore  <moore+iesg@cs.utk.edu>
  16.      Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
  17.  
  18.  Applications Area Advisor: 
  19.      Keith Moore  <moore+iesg@cs.utk.edu>
  20.  
  21.  Mailing Lists: 
  22.      General Discussion:ietf-nntp@academ.com
  23.      To Subscribe:      ietf-nntp-request@academ.com
  24.      Archive:           http://www.academ.com/academ/nntp/ietf
  25.  
  26. Description of Working Group:
  27.  
  28. Network News Transfer Protocol (NNTP), defined in RFC 977, was released
  29. to the world in March 1986. It was designed to do two things for the
  30. "netnews" computer conferencing system:
  31.  
  32. 1. Provide access to the netnews article database on a network server
  33.    for "reader" client programs.
  34.  
  35.    The situation everyone wanted was access to netnews throughout a
  36.    network, without having to actually run the netnews server software
  37.    and keep a local copy of the article database (a sizeable resource
  38.    commitment, even then).
  39.  
  40. 2. Provide the means for interactive server to server article transfer
  41.    over the Internet.
  42.  
  43.    The netnews system uses a "flood broadcast" mechanism to distribute
  44.    articles to all sites, which as a consequence of its operation,
  45.    creates many duplicate copies of any given article. These duplicates
  46.    account for the netnews system's high reliability and speed in
  47.    distributing articles, but they must be each eliminated at the
  48.    receiving site, to avoid infinite replication.
  49.  
  50. Originally, netnews was developed by the UUCP Network community, and
  51. used "batched" file transfer over modems and telephone lines to
  52. transmit articles from site to site. This mechanism did not allow for
  53. interrogating the remote system's database to see if the articles to
  54. betransmitted were already at the destination (a common case). NNTP's
  55. principal server to server article transfer mechanism allows for this
  56. interrogation of the receiver, and thus saves both network bandwidth
  57. and processing time on the remote.
  58.  
  59. Unfortunately, NNTP's original design had limitations which have become
  60. apparent over the decade since its release. For example, NNTP's server
  61. to server article transfer performance over the wide area Internet
  62. suffers because there are at least two protocol round-trips per article
  63. transfer, which does not allow two NNTP servers to continuously stream
  64. the articles that must be transferred between them, and thereby make
  65. full use of the available bandwidth (moderated by TCP's congestion
  66. control mechanisms).
  67.  
  68. Also, a number of extensions to the protocol are now in common use (and
  69. yet more have been proposed), but most such extensions are only
  70. documented in the source code that implements them, or in associated
  71. release notes - not in the NNTP standard. Such extensions would benefit
  72. from IETF community review, and proper specification. Where there is
  73. widespread interest in a particular kind of extension, the internet
  74. user community would benefit from consensus among implementors prior to
  75. deployment, as to the particulars of that extension.
  76.  
  77. The IETF NNTP extensions Working Group shall:
  78.  
  79. 1. Revise and publish a standards-track successor to RFC 977 that
  80.    removes ambiguities from the original document, defines a mechanism
  81.    for adding extensions to the protocol, and provides a mechanism for
  82.    the server to inform the client of the extensions which it
  83.    supports.
  84.  
  85. 2. Include in the same document some reasonable group of existing
  86.    commonly used extensions forming a new base functionality for NNTP.
  87.  
  88. 3. Upon completion of the RFC977 successor document, and presuming that
  89.    proposals for extensions to the NNTP protocol have been submitted
  90.    for consideration by IESG, the working group may be asked by the
  91.    IESG Applications Area Directors to review one or more extensions  
  92.    for NNTP.
  93.  
  94.    Part of the purpose of such a review will be to test the newly
  95.    established mechanism for adding protocol extensions.
  96.  
  97. The first concern of this working group shall be for the
  98. interoperability of the various NNTP implementations, and therefore for
  99. clear and explicit specification of the protocol. It is very important
  100. that we document the existing situation before taking up any new work.
  101.  
  102.  Goals and Milestones: 
  103.  
  104.      Done       produce a revised internet-draft of the NNTP protocol          
  105.  
  106.      Done       produce an internet-draft which 1. describes the current 
  107.                 practice of the NNTP protocol 2. recommends which features of 
  108.                 the protocol should (or should not) be suppored by all clients 
  109.                 and servers 3. defines a procedure for extending the set of 
  110.                 NNTP commands 4. defines a negotation mechanism by which the 
  111.                 NNTP client can learn                                          
  112.  
  113.    Dec 97       Begin review of accepted candidate extensions                  
  114.  
  115.    Dec 97       Submit the revised NNTP spec to the IESG for Proposed Standard 
  116.                 status                                                         
  117.  
  118.    Feb 98       provide list of new extensions that should be considered to the
  119.                 IESG for charter update consideration                          
  120.  
  121.  
  122.  Internet-Drafts:
  123.  
  124. Posted Revised       I-D Title  <Filename>
  125. ------ ------- ------------------------------------------
  126.  Sep 97 Sep 97  <draft-ietf-nntpext-base-02.txt> 
  127.                 Network News Transport Protocol                                
  128.  
  129.  Oct 97 New     <draft-ietf-nntpext-imp-00.txt> 
  130.                 Common NNTP Extensions                                         
  131.  
  132.  Request For Comments:
  133.  
  134.   None to date.
  135.