NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Ned Freed <email@example.com>
Stan Barber <firstname.lastname@example.org>
Applications Area Director(s):
Keith Moore <email@example.com>
Patrik Faltstrom <firstname.lastname@example.org>
Applications Area Advisor:
Keith Moore <email@example.com>
To Subscribe: firstname.lastname@example.org
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
No Request For Comments
Minutes from the meeting of the NNTPEXT working group at IETF41
Notes taken by Brian Hernacki and edited by Stan Barber.
About 30 people attended this working group session. Stan Barber outlined the
planned discussion topics:
- draft-ietf-nntp-imp-11.txt is in 17th release
- draft-ietf-nntp-base-05.txt is in 10th release
- drafts on searching, dynamic feeding, and authentication
- authinfo is being seperated to avoid getting the base bogged down in security stuff
The group decided that it was time to advance draft-ietf-nntp-imp-11.txt to the ADs
and IESG with the recommendation to publish it as an informational RFC.
For draft-ietf-nntp-base-05.txt, there were a number of areas of discussion:
Should the negate operator (!) be added to wildmat? Dave Lawrence wants in since
it's useful and implemented. The group decided that it should added and MUST be
required. This will be reflected in the next version of the draft.
Should the distributions operator be dropped from the NEWNEWS command? Since
most people don't use this correctly anyways, folks at the meeting believe that it's pretty
useless. It is already described in the draft-ietf-nntp-imp-0X.txt document. It could
always be added as an extension later. The group decided to drop it from the next draft.
Should 502 be added as a valid response to the ARTICLE/STAT/BODY group of
commands? Folks at the meeting said that it sounds like a good thing. There was
concern over how older clients would handle getting this response code. There is
already text in the current draft on how to handle unexpected codes, so new clients
written to comply with the new draft would already be able to handle unexpected
response codes. The group decided to add it.
How should adminstration infrastructure for extensions be managed? At the previous
IETF, someone suggested using the same type of management infrastructure IMAP is
using. That would permit X-prefixed local extensions, standards track extensions and
experimental extensions. To get the latter two classifications would require that a
document defining the extension be submitted to IESG. To facilitate moving this
forward, Ned Freed will provide Stan with some text on this. Under this method,
experimental extension would take about 2 months to get through the IESG. For
standard extensions, one shot working groups could be created for large batches of
standard extensions. Other standards extensions would be handled over the mailing list.
An open question: Should this group provide a list of reviewers for the IESG?
For draft-ietf-nntpext-srch-0X.txt, there were a couple of items discussed:
At IETF41, there was considerable discussion concering UTF-8 that's not yet in the
document. When will it be there? Brian/Stephen will add some text to deal with UTF8
in the next draft. Once that happens, the group will make a last call. Hopefully, that
can happen on or before next IETF.
Brian Court came back to discussion draft-court-dynfeed-01.txt. This draft addressed
all the concerns brought up at IETF 41. There were some open discussion about how
long dfeed parameters should last (currently they are per session) and about how
efficient the dynafeed process is compared to existing mechanisms. However, the
group decided to move this item forward as a working group work item.
Concering draft-newman-nntpext-auth-00.txt, Chris Newman talked about what he
was trying to do: take what was in the base document and make a few modifications.
The group discussed the use of AUTHINFO GENERIC going forward. Should we
be documented and then deprecated? The draft defines AUTHINFO GENERIC
differently than current use. The group decided that Chris should remove AUTHINFO
GENERIC. It will remain in the current practices document. For the new
authenication mechansmi, what is minimum to implement? Right now, the document
has CRAM-MD5 (just like IMAP). There was a concern that we want to swap this for
something better later. The group decided to leave CRAM-MD5 in as is. What about
merging this back into the base document? The group decided to leave them as is.
Keith Moore likes this in particular and would like to see this document worked
though the group.
go to list