2.1.9 NNTP Extensions (nntpext)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98


Ned Freed <ned@innosoft.com>
Stan Barber <sob@academ.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

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 be transmitted 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 supported by all clients and servers 3. defines a procedure for extending the set of NNTP commands 4. defines a negotiation mechanism by which the NNTP client can learn

Dec 97


Begin review of accepted candidate extensions

Dec 97


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

Feb 98


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


No Request For Comments

Current Meeting Report

Minutes of the NNTP Extensions (nntpext) Working Group

There are three working group documents currently in development. Comments about these documents plus a new draft submitted by Brian Court were the core of the scheduled discussions at the meeting of the NNTP Extensions working group at IETF 41.

Stan Barber outlined the agenda for the meeting and summarized the status of the various drafts that would be discussed during the meeting. The "common practices" draft is in the 12th release and there have been few comments on it since the last meeting. Stan expects that this draft will be the basis for the final version that will be submitted to IESG. The "rfc977bis" document is in the 9th release. There have been many comments on this draft since its last release, but most of them have centered on AUTHINFO. More about this later in these minutes. There has been an update to the NNTP SRCH extension draft. There have been very few comments on the draft since its previous release. Finally, Brian Court submitted a new extensions draft to allow a dynamic feed adjustments.

There were very few comments from the group about the need to make adjustments to the "common practices" documents. Stan proposed that the draft be revised to include some examples and a table of contents and presented for a WG last call before next IETF. Assuming there are no last minute problems, the draft will be moved forward for consideration by the IESG for publication as an informational RFC.

During the discussion about the "rfc977bis" draft, there was a lengthy discussion about excluding the AUTHINFO command from this document and doing it in a separate extensions document. This was proposed as a tactical move to help get the "rfc977bis" document wrapped up and publishable. There was some concern there would be problems with this since it would mean that the base protocol would not include any form of authentication/identification command. However, other folks noted that the original NNTP spec didn't have this and most folks don't depend on these features. So, AUTHINFO will be removed from this draft and put into an extensions document of its own. There was a volunteer to create this new document. Unfortunately, I didn't capture the name of that individual.

There was also significant discussion about how to represent the "end" of a posting that has a body that is all binary. The current spec says that the end of posting is signified by a period on a line by itself. Does this mean that the end of a body is CRLF.CRLF or just .CRLF. Folks pointed out that NNTP was not really designed to support binary postings. I don't know that we really came to a consensus on this. I do know that we want to avoid specifying anything about the format of the article. That's really the purpose of RFC 1036 and any update to that document.

In discussions about the SRCH extension, the group noted that the keyword in the draft was still SEARCH not SRCH. The authors noted that was an error and would fix that. There was a significant discussion about the internationalization of the search terms. The authors intended to specify that the SRCH term was to be encoded in UTF-8. It was argued that there might be a need to support other encodings since the article body may support other encodings. The authors said they would consider this.

Finally, Brian Court presented more about his draft about a process he named "dynafeed." The core idea is to permit a downstream to inform the upstream of changes in a feed it is receiving from the upstream as it is occurring. While there is merit in the idea, the direction of the communication as expressed in the draft is not supported by the NNTP model. The downstream is supposed to respond with response codes, not commands. Brian will take his idea and revise it for future consideration.


NNTPEXT - Status Summary

Attendees List

go to list