idnits 2.17.1 draft-ietf-nntpext-dynfeed-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 96 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC977]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '...listing conta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 977 (Obsoleted by RFC 3977) -- Possible downref: Non-RFC (?) normative reference: ref. 'NNTP-NEW' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Brian Court 3 Expires: May 22, 1998 California State University 5 An NNTP Extension for Dynamic Feed Adjustment 7 draft-ietf-nntpext-dynfeed-00.txt 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 This document describes an extension to the Network News Transport 30 Protocol[RFC977] that allows NNTP peers to dynamically adjust 31 their criteria for sending network news articles to one another. 33 This extension provides only for the addition of "negative" criteria, 34 i.e., criteria for articles that are not to be sent. It is believed 35 that a more comprehensive scheme allowing for "positive" criteria, 36 while desirable, would not receive wide deployment in the Internet 37 because of concerns about security and intellectual property. The 38 extension described in this document does not present these concerns 39 and allows for gains in network efficiency. 41 3. Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [RFC2119]. 47 4. Introduction 49 The Network News Transport Protocol[RFC977] defines a mechanism 50 (IHAVE) that allows news clients to determine that a particular 51 article has already been sent to a particular server, so there is no 52 need to send it again. However, this is the only defined mechanism 53 for restricting which news articles go to a particular server. 55 In practice, it is valuable to make many such restrictions, based on 56 the size of the news article or the values of its various headers 57 (Newsgroups:, Distribution:, etc.) A site wishing to implement 58 restrictions on which news articles may be sent to it must request 59 each of its (potentially many) news peers to make the appropriate 60 adjustments to its feed, a request that typically requires manual 61 configuration. If even one sending site fails to make the needed 62 change, then the receiving site, in order to implement the desired 63 restriction, is forced to receive and immediately discard the unwanted 64 articles, of which there may be a great many. This results in a 65 substantial waste of network bandwidth and computing power. 67 The extension specified in this document is intended to allow a 68 sending site to learn of such restrictions from information sent to it 69 by the receiving site. While it may still be desirable for a sending 70 site to be pre-configured with its peers' restrictions, this 71 extension provides a means by which the restrictions may, entirely or 72 in part, be learned even if no such configuration is done. 74 5. Extension Overview 76 This document defines a new operand for the LIST command: DONTSEND. 77 A client issues LIST DONTSEND to a server to request that the server 78 return a list of criteria for articles that the server wishes not to 79 be sent. 81 6. Use of NNTP Extension Mechanism 83 The availability of the extension described in this document is 84 advertised by the mechanism described in [NNTP-NEW]. 86 7. LIST DONTSEND Command 88 If successful, the LIST DONTSEND command returns response code 230, followed 89 by zero or more lines of the following form: 91 MAXARTSIZE nnn 92 MINARTSIZE nnn 93 MAXGROUPS nnn 94 GROUP wildmat[,wildmat][...] 95 XPOSTGROUP wildmat[,wildmat][...] 96 DIST string[,string][...] 97 PATHHOST string[,string][...] 99 followed by a period on a line by itself. 101 The lines may occur in any order, and each keyword (MAXARTSIZE, GROUP, 102 etc.) may occur on multiple lines. The interpretation of a response 103 with multiple MAXARTSIZE, MINARTSIZE, or MAXGROUPS keywords is 104 implementation-dependent; in other cases, multiple occurrences of a 105 keyword should be logically AND'd together. 107 The values associated with the keywords are as follows: 109 GROUP wildmat[,wildmat][...] 111 Argument: A comma-delimited group of wildmat[NNTP-NEW] patterns 112 specifying one or more newsgroups this site wishes not to 113 receive. 115 This response allows a server to inform a client that it wishes not to 116 be sent articles that are posted to newsgroups matching the specified pattern. 118 If an article is cross-posted, a client implementing this restriction 119 MAY send the article to the server if at least one newsgroup to which 120 the article is posted is one that the server wishes to receive. 122 XPOSTGROUP wildmat[,wildmat][...] 124 Argument: A comma-delimited group of wildmat[NNTP-NEW] patterns 125 specifying one or more newsgroups this site wishes not 126 to receive. 128 This response allows a server to inform a client that it wishes not 129 to be sent articles that are posted to newsgroups matching the 130 specified pattern. 132 This response differs from the DONTSEND GROUP response in that it 133 requests that the article not be sent even if it is cross-posted 134 to an unrestricted newsgroup. 136 ^L 137 INTERNET-DRAFT An NNTP Extension for Dynamic Feed Adjustment 139 MAXARTSIZE nnn 141 Argument: A positive integer specifying the largest article size 142 (in octets) this site is willing to receive. 144 This response allows a server to inform a client that it wishes not to be 145 sent articles larger than the specified number of octets. 147 MINARTSIZE nnn 149 Argument: A positive integer specifying the smallest article size 150 (in octets) this site wishes to receive. 152 This response allows a server to inform a client that it wishes not 153 to be sent articles smaller than the specified number of octets. 155 MAXGROUPS nnn 157 Argument: A positive integer specifying the maximum number of 158 newsgroups to which an article may be posted for the site 159 to be willing to receive it. 161 This response allows a server to inform a client that it wishes not 162 to be sent articles that are posted to more than the specified number 163 of newsgroups. 165 MAXHOPS nnn 167 Argument: A positive integer specifying the largest number of sites, 168 as indicated in the Path: header, that an article may have 169 traversed for the site to be willing to receive it. 171 This response allows a server to inform a client that it wishes not to 172 be sent articles that have traversed more than the specified number of 173 sites. 175 PATHHOST string[,string][...] 177 Argument: A comma-delimited list of strings specifying one or more 178 Path: values that, if found in the Path: header of a given article, 179 indicate that the site does not wish to receive that article. 181 This response allows a server to inform a client that it wishes not 182 to be sent articles that have traversed a specified site or sites. 184 In addition to the 230 response code, other possible response codes 185 to LIST DONTSEND include 187 450 Authentication required 188 452 No permission 189 503 Program error, function not performed 191 8. Implementation Notes 193 Client implementations successfully issuing a LIST DONTSEND command 194 SHOULD refrain from sending to the server articles that do not satisfy 195 the desired restrictions. Implementers should note that this requires 196 "backend" feeder programs to more closely parse article headers than 197 may be necessary without this extension. 199 Server implementations SHOULD make use of the globbing capability of 200 wildmat[NNTP-NEW] to send the smallest number of response lines to 201 LIST DONTSEND that will describe the desired restriction. 203 Client implementations SHOULD issue a LIST DONTSEND near the beginning 204 of an NNTP session with a peer, and SHOULD issue a LIST DONTSEND 205 periodically through the life of the NNTP session. The RECOMMENDED 206 default periodicity of this polling is once every 120 minutes. 207 Implementations MAY allow this value to be configurable. 209 Client implementations MAY issue a LIST DONTSEND at times other than their 210 regular polling time. For example, implementations might choose to 211 issue a LIST DONTSEND after receiving a 437 code in response to an 212 IHAVE/SENDME transaction. 214 Client implementations SHOULD treat the restrictions requested by a 215 response to LIST DONTSEND as valid only for the duration of the NNTP 216 session in which they were learned. In addition, clients MUST treat 217 those restrictions as valid only until another LIST DONTSEND is issued 218 and successfully responded to, and servers MUST return the entire list 219 of desired restrictions in response to each LIST DONTSEND. In other 220 words, the restrictions learned from the response to one LIST DONTSEND 221 are entirely replaced by those learned from the response to the next 222 LIST DONTSEND. 224 The MAXARTSIZE and MINARTSIZE keywords should not be relied upon to 225 precisely control news flow, since sites may modify articles in 226 transit and thereby change their size. Similarly, the MAXHOPS keyword 227 should not be relied upon to precisely control news flow, since the 228 number of sites in the Path: header may not accurately reflect the 229 number of hops the article has traversed. 231 9. Example session 233 A: 234 B: 235 A: LIST EXTENSIONS 236 B: 215 Extensions supported by server: 237 LIST DONTSEND 238 . 239 A: LIST DONTSEND 240 B: 230 Criteria list follows: 241 GROUP clari.*,alt.* 242 GROUP misc.test,misc.jobs.* 243 DIST clari 244 PATHHOST cyberspam 245 MAXARTSIZE 100000 246 MAXGROUPS 8 247 . 249 10. Security Considerations 251 The extension defined in this document allows the set of articles to 252 be sent from one peer to another to be decreased but not increased. 253 Therefore it cannot be used to cause leakage of articles to a site 254 that would otherwise not receive them. A denial of service attack 255 is possible if an attacker exploits existing weaknesses in the 256 TCP/IP protocol suite to send unauthorized DONTSEND commands. 258 11. References 260 [RFC977], Kantor, B., Lapsley, P., Network News Transfer Protocol, 261 Request for Comments (RFC) 977, February 1986. 263 [RFC2119], Bradner, S., Key words for use in RFCs to Indicate 264 Requirement Levels, Request for Comments (RFC) 2119, March 1997 266 [NNTP-NEW], Barber, S., Network News Transfer Protocol, Internet-Draft 267 12. Author's Address 269 Brian Court 270 California State University 271 Office of the Chancellor 272 4665 Lampson Ave. 273 Los Alamitos, CA 90720 274 Phone: 562-985-9441 275 Email: bac@csu.net