2.1.11 NNTP Extensions (nntpext)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 16-Oct-00


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:



produce a revised internet-draft of the NNTP protocol



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



Begin review of accepted candidate extensions



Submit the revised NNTP spec to the IESG for Proposed Standard status



provide list of new extensions that should be considered to the IESG for charter update consideration


Request For Comments:






Common NNTP Extensions

Current Meeting Report

NNTPEXT at the 49th IETF

Notes prepared by Stan Barber, Co-Chairman

At this meeting of the working group, the main draft, draft-ietf-nntpext-base-11.txt, was the only draft discussed in detail. Most of the discussion was centered on relatively small changes to the document. The most significant changes were to remove PAT from the base document and to replace it with HDR. The HDR text will be based on the XHDR text in RFC 2980. There was also an agreement to use the BNF suggested by Clive Feather to replace the current text in section 5 (along with small changes in other parts of the document that reference information in section 5). This will hopefully clarify wildmat sufficiently, so there is no remaining big issues left in the draft.

The only other issue of significance discussed was the ongoing debate on the use of "UTC" or "GMT" in the date command (and others) that clients can use to indicate to the server that the time stamp used in the command should have no time zone offset associated with it. It has always been the case that NNTP was never to be used as any kind of time protocol. However, it is important that the notion of time be consistent enough that clients won't miss articles due to time stamp skewing. The group decided that the second should be rewritten to indicate that the usage of "GMT" or "UTC" was syntactically equal and that the intent was for the server to drop a time zone offset in doing whatever time comparison was required. In addition, this section would carry a specific recommendation (a SHOULD) that all server operators use NTP to synchronize their server clocks with other clocks on the Internet.

There was some discussion on specifying streaming in the draft. Some felt that it should be specified because of issues that had come up in DRUMS. However, the group did not have a clear idea of exactly how that should be done. There were others that felt it could be pushed off into an extension. Whatever the case, it will be important for all commands to indicate if they can be "streamed" or not.

MODE READER was discussed, but no one in the group felt that its use should be required. A reader can choose to use it or not. It was not clear that the group thought that the current discussion of the command in the draft was in need of further refinement. There was no intent in the group to invalidate a dual daemon architecture (e.g. INN), just not require MODE READER to demarc the switch from one daemon to another.

There was a proposal from the mailing list to do some significant document reorganization. Those present at the meeting didn't think such a reorganization was warranted at this time.