NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Ned Freed <ned.freed@innosoft.com>
Stan Barber <sob@academ.com>
Applications Area Director(s):
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@innosoft.com>
Mailing Lists:
General Discussion:ietf-nntp@academ.com
To Subscribe: ietf-nntp-request@academ.com
Archive: http://www.academ.com/academ/nntp/ietf
Description of Working Group:
Network News Transfer Protocol (NNTP), defined in RFC 977, was released to the world in March 1986. It was designed to do two things for the "netnews" computer conferencing system:
1. Provide access to the netnews article database on a network server for "reader" client programs.
The situation everyone wanted was access to netnews throughout a network, without having to actually run the netnews server software and keep a local copy of the article database (a sizeable resource commitment, even then).
2. Provide the means for interactive server to server article transfer over the Internet.
The netnews system uses a "flood broadcast" mechanism to distribute articles to all sites, which as a consequence of its operation, creates many duplicate copies of any given article. These duplicates account for the netnews system's high reliability and speed in distributing articles, but they must be each eliminated at the receiving site, to avoid infinite replication.
Originally, netnews was developed by the UUCP Network community, and used "batched" file transfer over modems and telephone lines to transmit articles from site to site. This mechanism did not allow for interrogating the remote system's database to see if the articles to betransmitted were already at the destination (a common case). NNTP's principal server to server article transfer mechanism allows for this interrogation of the receiver, and thus saves both network bandwidth and processing time on the remote.
Unfortunately, NNTP's original design had limitations which have become apparent over the decade since its release. For example, NNTP's server to server article transfer performance over the wide area Internet suffers because there are at least two protocol round-trips per article transfer, which does not allow two NNTP servers to continuously stream the articles that must be transferred between them, and thereby make full use of the available bandwidth (moderated by TCP's congestion control mechanisms).
Also, a number of extensions to the protocol are now in common use (and yet more have been proposed), but most such extensions are only documented in the source code that implements them, or in associated release notes - not in the NNTP standard. Such extensions would benefit from IETF community review, and proper specification. Where there is widespread interest in a particular kind of extension, the internet user community would benefit from consensus among implementors prior to deployment, as to the particulars of that extension.
The IETF NNTP extensions Working Group shall:
1. Revise and publish a standards-track successor to RFC 977 that removes ambiguities from the original document, defines a mechanism for adding extensions to the protocol, and provides a mechanism for the server to inform the client of the extensions which it supports.
2. Include in the same document some reasonable group of existing commonly used extensions forming a new base functionality for NNTP.
3. Upon completion of the RFC977 successor document, and presuming that proposals for extensions to the NNTP protocol have been submitted for consideration by IESG, the working group may be asked by the IESG Applications Area Directors to review one or more extensions for NNTP.
Part of the purpose of such a review will be to test the newly established mechanism for adding protocol extensions.
The first concern of this working group shall be for the interoperability of the various NNTP implementations, and therefore for clear and explicit specification of the protocol. It is very important that we document the existing situation before taking up any new work.
Goals and Milestones:
Done |
|
produce a revised internet-draft of the NNTP protocol |
Done |
|
produce an internet-draft which 1. Describes the current practice of the NNTP protocol 2. recommends which features of the protocol should (or should not) be suppored by all clients and servers 3. defines a procedure for extending the set of NNTP commands 4. defines a negotation mechanism by which the NNTP client can learn |
Done |
|
Begin review of accepted candidate extensions |
Jul 99 |
|
Submit the revised NNTP spec to the IESG for Proposed Standard status |
Nov 99 |
|
provide list of new extensions that should be considered to the IESG for charter update consideration |
Internet-Drafts:
No Request For Comments
The summary of what happened...
Stan Barber, Co-Chairperson and Editor
Prologue
The draft came out in time to be processed by Internet Drafts prior to the meeting. There was 300 messages posted to the list over the course of the time between the publishing of the list and the meeting. This was 1/5 of the traffic on the list since the group started. There was good attendance at the WG meeting, but only three active participants: Stan Barber and Ned Freed as co-chairpersons and David Riley from software.com. This was unfortunate, but the work of the group was conducted and those results are discussed in this document. While it is hard to call this consensus, the chairpersons agree that these decisions are now made and it's time to move on to other matters.
Summary of Current Work
The Base draft has been updated and published by Internet Drafts. There needs to be an update to the authentication draft. Ned will query the current author to see if he will do an update. If not, Ned suggests that the draft be reassigned. I say that I will await work from Ned before seeking another to work on this draft.
Clarification of the wildmat format
There were two sets of text submitted for consideration other than that which is in the current draft. Clive Feather adds "\u" and "\U" to make it possible to do raw encoded strings. Russ Alberry offered the documentation he is writing for the version of wildmat he is refining for INN. The group decided that Russ' text should be used as a basis for the next draft.
Clarification of wildmat usage in various commands
There has been some discussion about how to deal with compound wildmats versus multiple wildmats. The group decided that commas can be used to link together wildmats to form a compound wildmat. A space would separate multiple wildmats. Spaces can be embedded in a wildmat if preceded by a backslash. If a command can have multiple wildmats (or compound wildmats), the evaluation of each wildmat is treated independently (i.e. a logical OR).
MODE READER
There was no consensus here. The group discussed that it could be used to partition commands between a "reader" server and a "feeder" server. This does parallel certain vendor products. David Riley is supposed to propose some text on the list for further discussion.
Replacing me as editor
There was no support for removing me as editor. I will release the next draft by the end of August and will do my best to release a new draft each month in which there is evidence of substantial changes.
Other business
Effective immediately and until the work of this group is completed, suggested changes to any of drafts (other than those that have to do with spelling and grammar) must be accompanied by replacement text. The text does not have to be super polished, but it must be clear enough to support the point-of-view of the advocate(s) for change. Expressions of support for changes must be explicit as well as expressions of support for no change. The final decision on what gets changed remains that of the chair.
The draft relating to current practices will be considered by the IESG real soon now.
The charter of the group is primarily to clarify RFC977, not to invent a new protocol. Additions, even those that are codifying current practice, have to be added only as a last resort. These things can always be proposed as extensions.
David Riley believes that CHECK/TAKETHIS is important and should be considered for the base draft or as a specific extension. He will work on some text.
Respectfully submitted,
STAN BARBER
None received.