Internet DRAFT - draft-ietf-nntpext-dynfeed

draft-ietf-nntpext-dynfeed





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: <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-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