Internet DRAFT - draft-court-dynfeed
draft-court-dynfeed
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:22:18 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 14 Aug 1998 13:04:00 GMT
ETag: "2e7faf-2b81-35d435c0"
Accept-Ranges: bytes
Content-Length: 11137
Connection: close
Content-Type: text/plain
INTERNET-DRAFT Brian Court
Expires: February 11, 1999 California State University
An NNTP Extension for Dynamic Feed Adjustment
draft-court-dynfeed-01.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), ds.internic.net (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.
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 MUST 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: <connects to B>
B: <NNTP greeting>
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-04.txt, March 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
