INTERNET-DRAFT Brian Court Expires: May 22, 1998 California State University An NNTP Extension for Dynamic Feed Adjustment draft-ietf-nntpext-dynfeed-00.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document describes an extension to the Network News Transport Protocol[RFC977] that allows NNTP peers to dynamically adjust their criteria for sending network news articles to one another. This extension provides only for the addition of "negative" criteria, i.e., criteria for articles that are not to be sent. It is believed that a more comprehensive scheme allowing for "positive" criteria, while desirable, would not receive wide deployment in the Internet because of concerns about security and intellectual property. The extension described in this document does not present these concerns and allows for gains in network efficiency. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. INTERNET-DRAFT An NNTP Extension for Dynamic Feed Adjustment 4. Introduction The Network News Transport Protocol[RFC977] defines a mechanism (IHAVE) that allows news clients to determine that a particular article has already been sent to a particular server, so there is no need to send it again. However, this is the only defined mechanism for restricting which news articles go to a particular server. In practice, it is valuable to make many such restrictions, based on the size of the news article or the values of its various headers (Newsgroups:, Distribution:, etc.) A site wishing to implement restrictions on which news articles may be sent to it must request each of its (potentially many) news peers to make the appropriate adjustments to its feed, a request that typically requires manual configuration. If even one sending site fails to make the needed change, then the receiving site, in order to implement the desired restriction, is forced to receive and immediately discard the unwanted articles, of which there may be a great many. This results in a substantial waste of network bandwidth and computing power. The extension specified in this document is intended to allow a sending site to learn of such restrictions from information sent to it by the receiving site. While it may still be desirable for a sending site to be pre-configured with its peers' restrictions, this extension provides a means by which the restrictions may, entirely or in part, be learned even if no such configuration is done. 5. Extension Overview This document defines a new operand for the LIST command: DONTSEND. A client issues LIST DONTSEND to a server to request that the server return a list of criteria for articles that the server wishes not to be sent. 6. Use of NNTP Extension Mechanism The availability of the extension described in this document is advertised by the mechanism described in [NNTP-NEW]. INTERNET-DRAFT An NNTP Extension for Dynamic Feed Adjustment 7. LIST DONTSEND Command If successful, the LIST DONTSEND command returns response code 230, followed by zero or more lines of the following form: MAXARTSIZE nnn MINARTSIZE nnn MAXGROUPS nnn GROUP wildmat[,wildmat][...] XPOSTGROUP wildmat[,wildmat][...] DIST string[,string][...] PATHHOST string[,string][...] followed by a period on a line by itself. The lines may occur in any order, and each keyword (MAXARTSIZE, GROUP, etc.) may occur on multiple lines. The interpretation of a response with multiple MAXARTSIZE, MINARTSIZE, or MAXGROUPS keywords is implementation-dependent; in other cases, multiple occurrences of a keyword should be logically AND'd together. The values associated with the keywords are as follows: GROUP wildmat[,wildmat][...] Argument: A comma-delimited group of wildmat[NNTP-NEW] patterns specifying one or more newsgroups this site wishes not to receive. This response allows a server to inform a client that it wishes not to be sent articles that are posted to newsgroups matching the specified pattern. If an article is cross-posted, a client implementing this restriction MAY send the article to the server if at least one newsgroup to which the article is posted is one that the server wishes to receive. XPOSTGROUP wildmat[,wildmat][...] Argument: A comma-delimited group of wildmat[NNTP-NEW] patterns specifying one or more newsgroups this site wishes not to receive. This response allows a server to inform a client that it wishes not to be sent articles that are posted to newsgroups matching the specified pattern. This response differs from the DONTSEND GROUP response in that it requests that the article not be sent even if it is cross-posted to an unrestricted newsgroup. ^L INTERNET-DRAFT An NNTP Extension for Dynamic Feed Adjustment MAXARTSIZE nnn Argument: A positive integer specifying the largest article size (in octets) this site is willing to receive. This response allows a server to inform a client that it wishes not to be sent articles larger than the specified number of octets. MINARTSIZE nnn Argument: A positive integer specifying the smallest article size (in octets) this site wishes to receive. This response allows a server to inform a client that it wishes not to be sent articles smaller than the specified number of octets. MAXGROUPS nnn Argument: A positive integer specifying the maximum number of newsgroups to which an article may be posted for the site to be willing to receive it. This response allows a server to inform a client that it wishes not to be sent articles that are posted to more than the specified number of newsgroups. MAXHOPS nnn Argument: A positive integer specifying the largest number of sites, as indicated in the Path: header, that an article may have traversed for the site to be willing to receive it. This response allows a server to inform a client that it wishes not to be sent articles that have traversed more than the specified number of sites. INTERNET-DRAFT An NNTP Extension for Dynamic Feed Adjustment PATHHOST string[,string][...] Argument: A comma-delimited list of strings specifying one or more Path: values that, if found in the Path: header of a given article, indicate that the site does not wish to receive that article. This response allows a server to inform a client that it wishes not to be sent articles that have traversed a specified site or sites. In addition to the 230 response code, other possible response codes to LIST DONTSEND include 450 Authentication required 452 No permission 503 Program error, function not performed 8. Implementation Notes Client implementations successfully issuing a LIST DONTSEND command SHOULD refrain from sending to the server articles that do not satisfy the desired restrictions. Implementers should note that this requires "backend" feeder programs to more closely parse article headers than may be necessary without this extension. Server implementations SHOULD make use of the globbing capability of wildmat[NNTP-NEW] to send the smallest number of response lines to LIST DONTSEND that will describe the desired restriction. Client implementations SHOULD issue a LIST DONTSEND near the beginning of an NNTP session with a peer, and SHOULD issue a LIST DONTSEND periodically through the life of the NNTP session. The RECOMMENDED default periodicity of this polling is once every 120 minutes. Implementations MAY allow this value to be configurable. Client implementations MAY issue a LIST DONTSEND at times other than their regular polling time. For example, implementations might choose to issue a LIST DONTSEND after receiving a 437 code in response to an IHAVE/SENDME transaction. Client implementations SHOULD treat the restrictions requested by a response to LIST DONTSEND as valid only for the duration of the NNTP session in which they were learned. In addition, clients MUST treat those restrictions as valid only until another LIST DONTSEND is issued and successfully responded to, and servers MUST return the entire list of desired restrictions in response to each LIST DONTSEND. In other words, the restrictions learned from the response to one LIST DONTSEND are entirely replaced by those learned from the response to the next LIST DONTSEND. The MAXARTSIZE and MINARTSIZE keywords should not be relied upon to precisely control news flow, since sites may modify articles in transit and thereby change their size. Similarly, the MAXHOPS keyword should not be relied upon to precisely control news flow, since the number of sites in the Path: header may not accurately reflect the number of hops the article has traversed. INTERNET-DRAFT An NNTP Extension for Dynamic Feed Adjustment 9. Example session A: B: A: LIST EXTENSIONS B: 215 Extensions supported by server: LIST DONTSEND . A: LIST DONTSEND B: 230 Criteria list follows: GROUP clari.*,alt.* GROUP misc.test,misc.jobs.* DIST clari PATHHOST cyberspam MAXARTSIZE 100000 MAXGROUPS 8 . 10. Security Considerations The extension defined in this document allows the set of articles to be sent from one peer to another to be decreased but not increased. Therefore it cannot be used to cause leakage of articles to a site that would otherwise not receive them. A denial of service attack is possible if an attacker exploits existing weaknesses in the TCP/IP protocol suite to send unauthorized DONTSEND commands. 11. References [RFC977], Kantor, B., Lapsley, P., Network News Transfer Protocol, Request for Comments (RFC) 977, February 1986. [RFC2119], Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, Request for Comments (RFC) 2119, March 1997 [NNTP-NEW], Barber, S., Network News Transfer Protocol, Internet-Draft draft-ietf-nntpext-base-06.txt, August 1998 12. Author's Address Brian Court California State University Office of the Chancellor 4665 Lampson Ave. Los Alamitos, CA 90720 Phone: 562-985-9441 Email: bac@csu.net