NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Chair(s):
Ned Freed <ned@innosoft.com>
Stan Barber <sob@academ.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore+iesg@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 that 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 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 |
Internet-Drafts:
· Network News Transport Protocol
· Common NNTP Extensions
No Request For Comments
Minutes of the NNTP Extensions (NNTPEXT) WG
Reported by Stan Barber
[Note: Thanks to Brian Hernacki of Netscape for submitting his notes to help me develop this summary.]
I. Introduction of the New WG Chairs
This was the first meeting of the WG with the new co-chairs, Ned Freed of Innosoft and Stan Barber of Academ Consulting Services. Previously, Stan had been serving as document editor and principle author of the initial two documents from the group. He will continue in this role and serve as "lead" chair. Ned will arbitrate problems concerning the initial two documents and keep Stan from making mistakes. All decisions concerning documents will go through both of them before going to the AD's and IESG.
If anyone wants the WG to consider any particular extension, it must be submitted through the IETF Internet-Drafts mechanism. Sending it to the extensions list is a good way to get some discussion, but it won't officially be considered by NNTPEXT unless it is in the Internet-Drafts repository.
II. Current Status
The "common practices" document is in its 11th release. There have been no major show-stopping comments about this draft in the last three months. Those that have come in will be included (along with a table of contents and some examples) in the 12th release that should come out around the 15th of December. It is expected that this document will go to WG last call around that time. If there are no other problems found, this document will go to the AD's in early January with a recommendation for publication as an Informational RFC.
In the current practices draft, there are references to certain things like "moderated groups" that are not fully defined and not fully referenced. Stan said that he intended to keep those types of things out of the common practices draft and reference RFC 1036. He will comb through the document for the next release and see that such ambiguities are clarified. He welcomes any specific references that anyone would care to point out. Please send them to the list (ietf-nntp@academ.com).
III. RFC977bis
The "RFC977bis" document is in the 8th release and has gone through significant changes since the last IETF. The main revisions have been in adding internationalization features. Initially, there was the addition of a CHARSET command. After considerable discussion in the newsgroup (and input from the unofficial RFC1036bis group), the CHARSET idea was replaced by the notion of changing the default character set in NNTP from US-ASCII to UTF-8. This change is reflected in the most recent draft. There was some discussion about setting the language for certain kinds of response text, but it was decided that should probably be put into a language extension.
There was a suggestion to provide a mechanism for getting the various AUTHINFO GENERIC mechanisms supported. Chris Lewis was not at the meeting, but his input will be solicited. Such information could be returned as part of a LIST EXTENSIONS response or another command or as a response to AUTHINFO GENERIC without any arguments. There was also a request to clarify which commands are subject to authorization and to clarify the difference between the 450, 452 and 502 responses when doing various forms of access control. 502 was not included in AUTHINFO section of the current draft except in the "transition issues" section. It was strongly suggested that 502 be used when there is no access to this command irrespective of authorization credentials. There was also some confusion about the requirement to log the email address in the AUTHINFO GENERIC section. Since this was included based on information from Chris Lewis, he will need to be polled about this as well. Finally, there was discussion about how information made available to a client may change depending on the change in authentication credentials. There was a general discussion about how the response from LIST might differ depending on the current state of credentials. RFC 977 was not clear on this. Many implementations do not do restrictions on the response to LIST, but when individual GROUP commands are issued for groups for which the client does not have adequate credentials, access may be denied.
There was a lengthy discussion about various modifications to WILDMAT. The main area was in how to specify WILDMAT in the context of UTF-8. The current draft specifies that WILDMAT would work on characters (not octets). There is also concern about how to match on text elements for which multiple equivalent character sequences are possible (i.e., both precomposed forms and a dynamically composed forms exist).There was also a discussion about adding a "not" (!) operator to WILDMAT, but there was no strong consensus on this. There was also no consensus about using the WILDMAT format to specify distributions in those commands where distributions can be specified.
Discussion continued on what format the response from LIST EXTENSIONS should take. Stan suggested that folks look at the format outlined in a draft from the FTP extensions group. See "draft-ietf-ftpext-feat-02.txt" for the details. More discussion on this will be done on the list. There was also some discussion of how the LIST EXTENSIONS response might change given a client's authorization status. The IMAP4 folks had already been down this path and their conclusions was that all capabilities should be listed even if some of them are not available to a particular authenticated user. This seems reasonable. There might be more discussion about this on the list as well.
The group decided:
· That the response for OVER will compress any string of non-printing US-ASCII white space to a single white space in a response.
· That DATE will continue to response using GMT/UTC. NEWGROUPS and NEWNEWS would continue to use time based on the server's local timezone. These two commands will also support GMT/UTC when specified. The group also wants to see that clients do all queries in GMT/UTC going forward. Servers will continue to accept both.
· That the BODY command would not be modified to display the MIME-type and there continue to be no specific limit on the total size of any response, single or multi-lined.
· Not to put SLAVE back into the spec. The group decided not to put in a VERSION command.
· To require that response codes be restricted to three digits and that leading zeros should not be permitted.
The group requested that referenced to Usenet be replaced by references to netnews.
There was a discussion of modifying the specifics of the response from LIST NEWSGROUPS command to permit that URLs providing information about the newsgroup. There is nothing specific that prohibits this from being done presently.
The group also wants better language concerning the specifics of the fourth field returned by LIST/LIST ACTIVE. The current idea is to define y n and m and acknowledge that there may be other flags added via the standard extensions mechanism.
The new version of this document with the changes decided by the WG at IETF should be available before the end of January 1998.
IV. GET/LIST EXTENSIONS
These were not discussed in the WG. They will be discussed more on the extensions list.
V. SEARCH EXTENSION
The group decided to rename this to SRCH. The next version of the draft will reflect the internationalization steps in the RFC977bis document. There was also some discussion on moving the PAT :TEXT stuff into the basic definition of PAT. This will be discussed further on the ietf-nntp mailing list. Will SRCH interpret MIME body types before searching them. The group decided that this was a bad idea, mostly based on IMAP4's experience in this area. There was also a request for the authors to better define how to search for non-existent (as opposed to blank) headers (e.g., Search for articles that don't have a MIME-Version: line).