idnits 2.17.1 draft-ietf-usefor-article-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 38 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC977], [KLYNE], [NNTP], [USEAGE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 16 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2009 has weird spacing: '...es both a per...' == Line 2112 has weird spacing: '...ant and could...' == Line 4356 has weird spacing: '...troller doc...' == Line 4372 has weird spacing: '...pies-To net...' == Line 4384 has weird spacing: '...on-Info net...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (May 2004) is 7248 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 977' is mentioned on line 73, but not defined ** Obsolete undefined reference: RFC 977 (Obsoleted by RFC 3977) == Missing Reference: 'FWS' is mentioned on line 5053, but not defined == Missing Reference: 'CFWS' is mentioned on line 5128, but not defined == Unused Reference: 'ISO 3166' is defined on line 4399, but no explicit reference was found in the text == Unused Reference: 'RFC 822' is defined on line 4494, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' -- No information found for draft-ietf-nntpext-base- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NNTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PGPVERIFY' ** Obsolete normative reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2298 (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 850 (Obsoleted by RFC 1036) ** Downref: Normative reference to an Unknown state RFC: RFC 976 -- Possible downref: Non-RFC (?) normative reference: ref. 'Son-of-1036' -- Possible downref: Non-RFC (?) normative reference: ref. 'USEAGE' -- Possible downref: Non-RFC (?) normative reference: ref. 'USEFOR' Summary: 17 errors (**), 0 flaws (~~), 16 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Charles H. Lindsey 3 Usenet Format Working Group University of Manchester 4 May 2004 6 News Article Format and Transmission 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This Draft is intended as a standards track document, obsoleting 34 RFC 1036, which itself dates from 1987. 36 This Standard defines the format of Netnews articles and specifies 37 the requirements to be met by software which originates, distributes, 38 stores and displays them. 40 Since the 1980s, Usenet has grown explosively, and many Internet and 41 non-Internet sites now participate. In addition, the Netnews 42 technology is now in widespread use for other purposes. 44 Backward compatibility has been a major goal of this endeavour, but 45 where this standard and earlier documents or practices conflict, this 46 standard should be followed. In most such cases, current practice is 47 already compatible with these changes. 49 [Draft-10 removed all the Internationalization features (i.e. those 50 involving the use of the UTF-8 charset in headers). This is being done 51 so as to facilitate publishing those features, or similar ones, as an 52 experimental protocol at a later stage. 54 A companion Current Best Practice document [USEAGE], addressing 55 requirements which are present for Social rather than Normative reasons 56 is in preparation. 58 There may well be a further split of the present draft into a 59 syntax/semantics part and a protocol part. Thus this present draft is 60 but an intermediate stage in an ongoing development process.] 62 [The use of the words "this standard" within this document when 63 referring to itself does not imply that this draft yet has pretensions 64 to be a standard, but rather indicates what will become the case if and 65 when it is accepted as an RFC with the status of a proposed or draft 66 standard.] 68 [Remarks enclosed in square brackets and aligned with the left margin, 69 such as this one, are not part of this draft, but are editorial notes to 70 explain matters amongst ourselves, or to point out alternatives, or to 71 assist the RFC Editor.] 73 [In this draft, references to [NNTP] are to be replaced by [RFC 977], or 74 else by references to the RFC arising from the series of drafts draft- 75 ietf-nntpext-base-*.txt, in the event that such RFC has been accepted at 76 the time this document is published. 77 References to [KLYNE], which has now passed its IETF last call, are to 78 be replaced by references to the eventual RFC.] 80 Table of Contents 82 1. Introduction .................................................. 6 83 1.1. Basic Concepts ............................................ 6 84 1.2. Objectives ................................................ 6 85 1.3. Historical Outline ........................................ 7 86 1.4. Transport ................................................. 7 87 2. Definitions, Notations and Conventions ........................ 7 88 2.1. Definitions ............................................... 7 89 2.2. Textual Notations ......................................... 9 90 2.3. Relation To Email and MIME ................................ 10 91 2.4. Syntax .................................................... 10 92 2.4.1. Syntax Notation ....................................... 10 93 2.4.2. Syntax copied from other standards .................... 11 94 2.4.3. Syntax adapted from Email and MIME .................... 13 95 2.5. Language .................................................. 15 96 3. Changes to the existing protocols ............................. 15 97 3.1. Principal Changes ......................................... 15 98 3.2. Transitional Arrangements ................................. 16 99 4. Basic Format .................................................. 17 100 4.1. Syntax of News Articles ................................... 17 101 4.2. Headers ................................................... 18 102 4.2.1. Naming of Headers ..................................... 18 103 4.2.2. MIME-style Parameters ................................. 19 104 4.2.3. White Space and Continuations ......................... 20 105 4.2.4. Comments .............................................. 21 106 4.2.5. Header Properties ..................................... 22 107 4.2.5.1. Experimental Headers .............................. 22 108 4.2.5.2. Inheritable Headers ............................... 22 109 4.2.5.3. Variant Headers ................................... 22 110 4.3. Body ...................................................... 23 111 4.4. Octets, Characters and Character Sets ..................... 23 112 4.4.1. Character Sets within Article Headers ................. 24 113 4.4.2. Character Sets within Article Bodies .................. 24 114 4.5. Size Limits ............................................... 24 115 4.6. Example ................................................... 25 116 5. Mandatory Headers ............................................. 26 117 5.1. Date ...................................................... 26 118 5.1.1. Examples .............................................. 26 119 5.2. From ...................................................... 27 120 5.2.1. Examples: ............................................ 27 121 5.3. Message-ID ................................................ 27 122 5.4. Subject ................................................... 28 123 5.5. Newsgroups ................................................ 28 124 5.5.1. Forbidden newsgroup-names ............................. 30 125 5.6. Path ...................................................... 31 126 5.6.1. Format ................................................ 31 127 5.6.2. Adding a path-identity to the Path-header ............. 32 128 5.6.3. The tail-entry ........................................ 33 129 5.6.4. Path-Delimiter Summary ................................ 34 130 5.6.5. Example ............................................... 34 131 5.7. Injection-Date ............................................ 35 132 6. Optional Headers .............................................. 36 133 6.1. Reply-To .................................................. 36 134 6.1.1. Examples .............................................. 36 135 6.2. Sender .................................................... 37 136 6.3. Organization .............................................. 37 137 6.4. Keywords .................................................. 37 138 6.5. Summary ................................................... 37 139 6.6. Distribution .............................................. 37 140 6.7. Followup-To ............................................... 39 141 6.8. Mail-Copies-To ............................................ 39 142 6.9. Posted-And-Mailed ......................................... 40 143 6.10. References ............................................... 40 144 6.10.1. Examples ............................................. 41 145 6.11. Expires .................................................. 41 146 6.12. Archive .................................................. 41 147 6.13. Control .................................................. 42 148 6.14. Approved ................................................. 43 149 6.15. Supersedes ............................................... 43 150 6.16. Xref ..................................................... 44 151 6.17. Lines .................................................... 45 152 6.18. User-Agent ............................................... 45 153 6.18.1. Examples ............................................. 46 154 6.19. Injection-Info ........................................... 46 155 6.19.1. Usage of Injection-Info-parameters ................... 47 156 6.19.1.1. The posting-host-parameter ....................... 48 157 6.19.1.2. The posting-account-parameter .................... 48 158 6.19.1.3. The posting-sender-parameter ..................... 48 159 6.19.1.4. The posting-logging-parameter .................... 48 160 6.19.2. Example .............................................. 48 161 6.20. Complaints-To ............................................ 49 162 6.21. MIME headers ............................................. 49 163 6.21.1. Syntax ............................................... 49 164 6.21.2. Content-Type ......................................... 50 165 6.21.3. Content-Transfer-Encoding ............................ 50 166 6.21.4. Definition of some new Content-Types ................. 51 167 6.21.4.1. Application/news-transmission .................... 51 168 6.21.4.2. Message/news obsoleted ........................... 53 169 6.22. Obsolete Headers ......................................... 53 170 7. Control Messages .............................................. 53 171 7.1. Digital Signature of Headers .............................. 53 172 7.2. Group Control Messages .................................... 54 173 7.2.1. The 'newgroup' Control Message ........................ 54 174 7.2.1.1. The Body of the 'newgroup' Control Message ........ 55 175 7.2.1.2. Application/news-groupinfo ........................ 55 176 7.2.1.3. Initial Articles .................................. 56 177 7.2.1.4. Example ........................................... 57 178 7.2.2. The 'rmgroup' Control Message ......................... 58 179 7.2.2.1. Example ........................................... 58 180 7.2.3. The 'mvgroup' Control Message ......................... 58 181 7.2.3.1. Example ........................................... 60 182 7.2.4. The 'checkgroups' Control Message ..................... 61 183 7.2.4.1. Application/news-checkgroups ...................... 62 184 7.3. Cancel .................................................... 62 185 7.4. Ihave, sendme ............................................. 63 186 7.5. Obsolete control messages. ............................... 64 187 8. Duties of Various Agents ...................................... 64 188 8.1. General principles to be followed ......................... 65 189 8.2. Duties of an Injecting Agent .............................. 65 190 8.2.1. Proto-articles ........................................ 66 191 8.2.2. Procedure to be followed by Injecting Agents .......... 66 192 8.3. Duties of a Relaying Agent ................................ 68 193 8.4. Duties of a Serving Agent ................................. 70 194 8.5. Duties of a Posting Agent ................................. 70 195 8.6. Duties of a Followup Agent ................................ 71 196 8.7. Duties of a Moderator ..................................... 73 197 8.8. Duties of a Gateway ....................................... 74 198 8.8.1. Duties of an Outgoing Gateway ......................... 76 199 8.8.2. Duties of an Incoming Gateway ......................... 76 200 8.8.3. Example ............................................... 78 201 9. Security and Related Considerations ........................... 79 202 9.1. Leakage ................................................... 79 203 9.2. Attacks ................................................... 80 204 9.2.1. Denial of Service ..................................... 80 205 9.2.2. Compromise of System Integrity ........................ 81 206 9.3. Liability ................................................. 82 207 10. IANA Considerations .......................................... 82 208 10.1. Media Types .............................................. 82 209 10.2. Header Field Registry .................................... 83 210 11. References ................................................... 84 211 12. Acknowledgements ............................................. 86 212 13. Contact Address .............................................. 87 213 Appendix A.1 - A-News Article Format .............................. 87 214 Appendix A.2 - Early B-News Article Format ........................ 88 215 Appendix A.3 - Obsolete Headers ................................... 88 216 Appendix A.4 - Obsolete Control Messages .......................... 89 217 Appendix B - Collected Syntax ..................................... 90 218 Appendix B.1 - Characters, Atoms and Folding ...................... 90 219 Appendix B.2 - Basic Forms ........................................ 92 220 Appendix B.3 - Headers ............................................ 93 221 Appendix B.3.1 - Header outlines .................................. 93 222 Appendix B.3.2 - Control-message outlines ......................... 95 223 Appendix B.3.3 - Other header rules ............................... 96 224 Appendix C - Notices .............................................. 98 225 1. Introduction 227 1.1. Basic Concepts 229 "Netnews" is a set of protocols for generating, storing and 230 retrieving news "articles" (which resemble email messages) and for 231 exchanging them amongst a readership which is potentially widely 232 distributed. It is organized around "newsgroups", with the 233 expectation that each reader will be able to see all articles posted 234 to each newsgroup in which he participates. These protocols most 235 commonly use a flooding algorithm which propagates copies throughout 236 a network of participating servers. Typically, only one copy is 237 stored per server, and each server makes it available on demand to 238 readers able to access that server. 240 An important characteristic of Netnews is the lack of any requirement 241 for a central administration or for the establishment of any 242 controlling host to manage the network. A network which limits 243 participation to some restricted set of hosts (within some company, 244 for example) is a "closed" network; otherwise it is an "open" 245 network. A set of hosts within a network which, by mutual 246 arrangement, operates some variant (whether more or less restrictive) 247 of the Netnews protocols is a "cooperating subnet". 249 "Usenet" is a particular worldwide open network based upon the 250 Netnews protocols, with the newsgroups being organized into 251 recognized "hierarchies". Anybody can join (it is simply necessary 252 to negotiate an exchange of articles with one or more other 253 participating hosts). 255 A "policy" is a rule intended to facilitate the smooth operation of a 256 network by establishing parameters which restrict behaviour that, 257 whilst technically unexceptionable, would nevertheless contravene 258 some accepted standard of "Good Netkeeping". Since the ultimate 259 beneficiaries of a network are its human readers, who will be less 260 tolerant of poorly designed interfaces than mere computers, articles 261 in breach of established policy can cause considerable annoyance to 262 their recipients. 264 1.2. Objectives 266 The purpose of this present standard is to define the format of 267 articles and the protocols to be used for Netnews in general, and for 268 Usenet in particular, and to set standards to be followed by software 269 that implements those protocols. 271 It is NOT the purpose of this standard to settle matters of policy, 272 nor aspects of software behaviour which do not impinge upon the 273 generation, transmission, storate and reception of articles, nor how 274 the authority of various agencies to exercise control or oversight of 275 the various parts of Usenet is established. For these purposes, a 276 separate Best Current Practice document [USEAGE] is being provided. 278 Nevertheless, it is assumed that agencies with the necessary 279 authority will exist, and tools are provided within the protocols for 280 their use. 282 1.3. Historical Outline 284 Network news originated as the medium of communication for Usenet, 285 circa 1980. Since then, Usenet has grown explosively, and many 286 Internet and non-Internet sites participate in it. In addition, the 287 news technology is now in widespread use for other purposes, on the 288 Internet and elsewhere. 290 The earliest news interchange used the so-called "A News" article 291 format. Shortly thereafter, an article format vaguely resembling 292 Internet Mail was devised and used briefly. Both of those formats 293 are completely obsolete; they are documented in Appendix A.1 and 294 Appendix A.2 for historical reasons only. With publication of [RFC 295 850] in 1983, news articles came to closely resemble Internet Mail 296 messages, with some restrictions and some additional headers. [RFC 297 1036] in 1987 updated [RFC 850] without making major changes. 299 A Draft popularly referred to as "Son of 1036" [Son-of-1036] was 300 written in 1994 by Henry Spencer. That document formed the original 301 basis for this standard, and its author has endorsed this standard as 302 its successor. Much is taken directly from Son of 1036, and it is 303 hoped that we have followed its spirit and intentions. It is 304 anticipated that [Son-of-1036] will be published as an Historic RFC, 305 in a suitably relabelled form, following the publication of this 306 standard. 308 1.4. Transport 310 As in this standard's predecessors, the exact means used to transmit 311 articles from one host to another is not specified. NNTP [NNTP] is 312 the most common transmission method on the Internet, but much 313 transmission takes place entirely independent of the Internet. Other 314 methods in use include the UUCP protocol [RFC 976] extensively used 315 in the early days of Usenet, FTP, downloading via satellite, tape 316 archives, and physically delivered magnetic and optical media. 318 2. Definitions, Notations and Conventions 320 2.1. Definitions 322 An "article" is the unit of news, analogous to an [RFC 2822] 323 "message". A "proto-article" is one that has not yet been injected 324 into the news system. 326 A "message identifier" (5.3) is a unique identifier for an article, 327 usually supplied by the "posting agent" which posted it or, failing 328 that, by the "injecting agent". It distinguishes the article from 329 every other article ever posted anywhere. Articles with the same 330 message identifier are treated as if they are the same article 331 regardless of any differences in the body or headers. 333 A "newsgroup" is a single news forum, a logical bulletin board, 334 having a name and nominally intended for articles on a specific 335 topic. An article is "posted to" a single newsgroup or several 336 newsgroups. When an article is posted to more than one newsgroup, it 337 is said to be "crossposted"; note that this differs from posting the 338 same text as part of each of several articles, one per newsgroup. 340 A newsgroup may be "moderated", in which case submissions are not 341 posted directly, but mailed to a "moderator" for consideration and 342 possible posting. Moderators are typically human but may be 343 implemented partially or entirely in software. 345 A "hierarchy" is the set of all newsgroups whose names share a first 346 component (as defined in 5.5). The term "sub-hierarchy" is also used 347 where several initial components are shared. 349 A "poster" is the person or software that composes and submits a 350 possibly compliant article to a "posting agent". The poster is 351 analogous to [RFC 2822]'s author. 353 A "posting agent" is the software that assists posters to prepare 354 proto-articles, in compliance with this standard. The proto-article 355 is then passed on to an "injecting agent" for final checking and 356 injection into the news stream. If the article is not compliant, or 357 is rejected by the injecting agent, then the posting agent informs 358 the poster with an explanation of the error. 360 A "reader" is the person or software reading news articles. 362 A "reading agent" is software which presents articles to a reader. 364 A "followup" is an article containing a response to the contents of 365 an earlier article (the followup's "precursor"). 367 A "followup agent" is a combination of reading agent and posting 368 agent that aids in the preparation and posting of a followup. 370 An (email) "address" is the mailbox [RFC 2822] (or more particularly 371 the addr-spec within that mailbox) which directs the delivery of an 372 email to its intended recipient, who is said to "own" that address. 374 An article's "reply address" is the address to which mailed replies 375 should be sent. This is the address specified in the article's From- 376 header (5.2), unless it also has a Reply-To-header (6.1). 378 A "sender" is the person or software (usually, but not always, the 379 same as the poster) responsible for the operation of the posting 380 agent or, which amounts to the same thing, for passing the article to 381 the injecting agent. The sender is analogous to [RFC 2822]'s sender. 383 An "injecting agent" takes the finished article from the posting 384 agent (often via the NNTP "post" command) performs some final checks 385 and passes it on to a relaying agent for general distribution. 387 A "relaying agent" is software which receives allegedly compliant 388 articles from injecting agents and/or other relaying agents, and 389 possibly passes copies on to other relaying agents and serving 390 agents. 392 A "news database" is the set of articles and related structural 393 information stored by a serving agent and made available for access 394 by reading agents. 396 A "serving agent" receives an article from a relaying agent and files 397 it in a news database. It also provides an interface for reading 398 agents to access the news database. 400 A "control message" is an article which is marked as containing 401 control information; a relaying or serving agent receiving such an 402 article may (subject to the policies observed at that site) take 403 actions beyond just filing and passing on the article. 405 A "gateway" is software which receives news articles and converts 406 them to messages of some other kind (e.g. mail to a mailing list), or 407 vice versa; in essence it is a translating relaying agent that 408 straddles boundaries between different methods of message exchange. 409 The most common type of gateway connects newsgroup(s) to mailing 410 list(s), either unidirectionally or bidirectionally, but there are 411 also gateways between news networks using this standard's news format 412 and those using other formats. 414 2.2. Textual Notations 416 This standard contains explanatory NOTEs using the following format. 417 These may be skipped by persons interested solely in the content of 418 the specification. The purpose of the notes is to explain why choices 419 were made, to place them in context, or to suggest possible 420 implementation techniques. 422 NOTE: While such explanatory notes may seem superfluous in 423 principle, they often help the less-than-omniscient reader grasp 424 the purpose of the specification and the constraints involved. 425 Given the limitations of natural language for descriptive 426 purposes, this improves the probability that implementors and 427 users will understand the true intent of the specification in 428 cases where the wording is not entirely clear. 430 "US-ASCII" is short for "the ANSI X3.4 character set" [ANSI X3.4]. 431 While "ASCII" is often misused to refer to various character sets 432 somewhat similar to X3.4, in this standard "US-ASCII" is used to mean 433 X3.4 and only X3.4. US-ASCII is a 7 bit character set. Please note 434 that this standard requires that all agents be 8 bit clean; that is, 435 they must accept and transmit data without changing or omitting the 436 8th bit. 438 Certain words, when capitalized, are used to define the significance 439 of individual requirements. The key words "MUST", "REQUIRED", 440 "SHOULD", "RECOMMENDED", "MAY" and "OPTIONAL", and any of those words 441 associated with the word "NOT", are to be interpreted as described in 442 [RFC 2119]. 444 NOTE: The use of "MUST" or "SHOULD" implies a requirement that 445 would or could lead to interoperability problems if not 446 followed. 448 NOTE: A requirement imposed on a relaying or serving agent 449 regarding some particular article should be understood as 450 applying only if that article is actually accepted for 451 processing (since any agent may always reject any article 452 entirely, for reasons of site policy). 454 Wherever the context permits, use of the masculine includes the 455 feminine and use of the singular includes the plural, and vice versa. 457 Throughout this standard we will give examples of various 458 definitions, headers and other specifications. It needs to be 459 remembered that these samples are for the aid of the reader only and 460 do NOT define any specification themselves. In order to prevent 461 possible conflict with "Real World" entities and people the top level 462 domain ".example" is used in all sample domains and addresses. The 463 hierarchy "example.*" is also used as a sample hierarchy. 464 Information on the ".example" top level domain is in [RFC 2606]. 466 2.3. Relation To Email and MIME 468 The primary intent of this standard is to describe the news article 469 format. Insofar as news articles are a subset of the email message 470 format augmented by some new headers, this standard incorporates many 471 (though not all) of the provisions of [RFC 2822], with the aim of 472 enabling news articles to pass through email systems and vice versa, 473 provided only that they contain the minimum headers required for the 474 mode of transport being used. Unfortunately, the match is not 475 perfect, but it is the intention of this standard that gateways 476 between Email and Netnews should be able to operate with the minimum 477 of tinkering. 479 Likewise, this standard incorporates (see section 6.21) many, though 480 not all, of the provisions of the MIME standards [RFC 2045] et seq 481 which, though designed with Email in mind, are mostly applicable to 482 Netnews. 484 2.4. Syntax 486 The complete syntax defined in this standard is repeated, for 487 convenience, in Appendix B. 489 2.4.1. Syntax Notation 491 This standard uses the Augmented Backus Naur Form described in [RFC 492 2234]. 494 In particular, it makes significant use of the "incremental 495 alternative" feature of that notation. For example, the two rules 496 header = other-header 497 header =/ Date-header 498 are equivalent to the single rule 499 header = other-header / Date-header 501 2.4.2. Syntax copied from other standards 503 The following syntactic forms for characters, atoms and folding, 504 taken from [RFC 2234] or from [RFC 2822] and adapted to incorporate 505 variations introduced in [RFC 2047], are repeated here for 506 convenience only: 508 ALPHA = %x41-5A / ; A-Z 509 %x61-7A ; a-z 510 CR = %x0D ; carriage return 511 CRLF = CR LF 512 DIGIT = %x30-39 ; 0-9 513 HTAB = %x09 ; horizontal tab 514 LF = %x0A ; line feed 515 SP = %x20 ; space 516 NO-WS-CTL = %d1-8 / ; US-ASCII control characters 517 %d11 / ; which do not include the 518 %d12 / ; carriage return, line feed, 519 %d14-31 / ; and whitespace characters 520 %d127 521 specials = "(" / ")" / ; Special characters used in 522 "<" / ">" / ; other parts of the syntax 523 "[" / "]" / 524 ":" / ";" / 525 "@" / "\" / 526 "," / "." / 527 DQUOTE 528 WSP = SP / HTAB ; whitespace characters 529 FWS = ([*WSP CRLF] 1*WSP); folding whitespace 530 ccontent = ctext / quoted-pair / comment / encoded-word 531 comment = "(" *([FWS] ccontent) [FWS] ")" 532 CFWS = *([FWS] comment) ( ([FWS] comment) / FWS ) 533 DQUOTE = %d34 ; quote mark 534 quoted-pair = "\" text 535 atext = ALPHA / DIGIT / 536 "!" / "#" / ; Any US-ASCII character except 537 "$" / "%" / ; controls, SP, and specials. 538 "&" / "'" / ; Used for atoms 539 "*" / "+" / 540 "-" / "/" / 541 "=" / "?" / 542 "^" / "_" / 543 "`" / "{" / 544 "|" / "}" / 545 "~" 546 atom = [CFWS] 1*atext [CFWS] 547 dot-atom = [CFWS] dot-atom-text [CFWS] 548 dot-atom-text = 1*atext *( "." 1*atext ) 549 qcontent = qtext / quoted-pair 550 quoted-string = [CFWS] DQUOTE 551 *( [FWS] qcontent ) [FWS] 552 DQUOTE [CFWS] 553 word = atom / quoted-string 555 NOTE: Following [RFC 2234], literal text included in the syntax 556 is to be regarded as case-insensitive. However, in 557 contradistinction to [RFC 2822], the Netnews protocols are 558 sensitive to case in some instances (as in newsgroup-names, some 559 header parameters, etc.). Care has been taken to indicate this 560 explicitly where required. 562 As in [RFC 2822], where any quoted-pair appears it is to be 563 interpreted as its text character alone. That is to say, the "\" 564 character that appears as part of a quoted-pair is semantically 565 "invisible". 567 Again, as in [RFC 2822], strings of characters that include 568 characters not syntactically allowed in some particular context may 569 be incorporated into a quoted-string by "encapsulating" them between 570 quote (DQUOTE, US-ASCII 34) characters, prefixing every quote and 571 backslash character (and possibly other characters too) with a "\" so 572 as to form a quoted-pair, and possibly introducing folding by 573 prefixing some WSP with CRLF. 575 The semantic value of a quoted-string (i.e. the result of reversing 576 the encapsulation) is a string of characters which includes neither 577 the optional CFWS outside of the quote characters, nor the quote 578 characters themselves, nor any CRLF contained within any FWS between 579 the two quote characters, nor the "\" which introduces any quoted- 580 pair. 582 The following basic forms are taken from [RFC 2045] and [RFC 2231] 583 (having regard to [RFC Errata]), adapted to use the folding syntax 584 from [RFC 2822]: 586 charset = 587 ; [RFC 2978] 588 language = 589 ; [RFC 3066] 590 encoded-word = "=?" charset ["*" language] "?" encoding 591 "?" encoded-text "?=" 592 parameter = regular-parameter / extended-parameter 593 regular-parameter = [CFWS] regular-parameter-name [CFWS] 594 "=" value 595 regular-parameter-name = attribute [section] 596 attribute = 1*attribute-char 597 attribute-char= 599 tspecials = "(" / ")" / "<" / ">" / "@" / 600 "," / ";" / ":" / "\" / DQUOTE / 601 "/" / "[" / "]" / "?" / "=" 603 extended-parameter 604 = ( [CFWS] extended-initial-name [CFWS] 605 "=" extended-initial-value ) / 606 ( [CFWS] extended-other-names [CFWS] 607 "=" extended-other-values ) 608 value = [CFWS] token [CFWS] / quoted-string 609 token = 1* 612 For the purposes of section 5 of [RFC 2047] all headers (4.1) defined 613 in this standard are to be considered as "extension message header 614 fields" (insofar as they are not already so considered under the 615 existing Email standards), permitting the use of [RFC 2047] encodings 616 within any unstructured header, or within any comment or phrase 617 permitted within any structured header. 619 The syntax of encoded-text and of encoding can be found in [RFC 620 2047], and there are restrictions on the characters that may occur 621 within an encoded-text, depending on its context. There are also 622 restrictions on the overall length of an encoded-word and of headers 623 containing encoded-words and requirements for encoded-words to have 624 FWS on either side of them in most contexts. All these restrictions 625 and requirements MUST be observed. 627 2.4.3. Syntax adapted from Email and MIME 629 Much of the syntax of Netnews Articles is based on the corresponding 630 syntax defined in [RFC 2822]. Therefore, wherever in this standard 631 the syntax is stated to be taken from [RFC 2822], it is to be 632 understood, unless explicitly stated to the contrary, as the syntax 633 defined by [RFC 2822], but NOT including any syntax defined in 634 section 4 ("Obsolete syntax") of [RFC 2822]. Software compliant with 635 this standard MUST NOT generate any of the syntactic forms defined in 636 that Obsolete Syntax, although it MAY accept such syntactic forms. 638 Likewise, certain syntax from the MIME specifications [RFC 2045] et 639 seq is also considered to have been incorporated into this standard 640 (see 6.21). 642 However, there are differences arising from some special requirements 643 of Netnews, and the following syntactic rules therefore supersede the 644 corresponding rules given in [RFC 2822]. 646 NOTE: Netnews parsers historically have been much less 647 permissive than Email parsers, and this is reflected in the 648 modifications referred to, and in some further specific rules. 650 In contradistinction to [RFC 2822], an unstructured header (e.g. a 651 Subject-header) MUST contain at least one non-whitespace character. 653 unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS] 655 Extended-phrases (known somewhat confusingly in [RFC 2822] as obs- 656 phrases) are introduced to allow headers such as 657 From: Joe Q. Public 658 without the necessity of using a quoted-string. They MUST be accepted 659 by compliant software, but they SHOULD NOT be generated until 660 software capable of accepting them has become widely deployed. 662 phrase = 1*( [CFWS] encoded-word [CFWS] / word ) / 663 extended-phrase 664 extended-phrase = ( [CFWS] encoded-word [CFWS] / word ) 665 *( [CFWS] encoded-word [CFWS] / word / 666 [CFWS] "." [CFWS] ) 668 Within a date-time, two of the obs-zones from [RFC 2822] are retained 669 because of current widespread usage. 671 zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" 673 The forms "UT" and "GMT" (indicating universal time) are to be 674 regarded as obsolete synonyms for "+0000". They MUST be accepted, and 675 passed on unchanged, by all agents, but they MUST NOT be generated as 676 part of new articles by posting and injecting agents. 678 Msg-ids are redefined to be a "normalized" subset of those defined by 679 [RFC 2822], ensuring that no string of characters is quoted unless 680 strictly necessary (it must contain at least one mqspecial) and no 681 single character is prefixed by a "\" in the form of a quoted-pair 682 unless strictly necessary, and moreover there is no possibility for 683 ">" or WSP to occur inside a msg-id, whether quoted or not. Thus, 684 whereas under [RFC 2822] 685 686 <"abcd"@example.com> 687 <"ab\cd"@example.com> 688 would be considered semantically equivalent, only the first of them 689 is syntactically permitted by this standard, and hence a simple 690 comparison of octets will always suffice to determine the identity of 691 two msg-ids. 693 msg-id = "<" id-left "@" id-right ">" 694 id-left = dot-atom-text / no-fold-quote 695 id-right = dot-atom-text / no-fold-literal 696 no-fold-quote = DQUOTE 697 *( mqtext / "\\" / "\" DQUOTE ) 698 mqspecial 699 *( mqtext / "\\" / "\" DQUOTE ) 700 DQUOTE 701 mqtext = NO-WS-CTL / ; all of except 702 %d33 / ; SP, HTAB, "\", ">" 703 %d35-61 / ; and DQUOTE 704 %d63-91 / 705 %d93-126 707 mqspecial = "(" / ")" / ; same as specials except 708 "<" / ; "\" and DQUOTE quoted 709 "[" / "]" / ; and ">" omitted 710 ":" / ";" / 711 "@" / "\\" / 712 "," / "." / 713 "\" DQUOTE 714 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 715 mdtext = NO-WS-CTL / ; Non white space controls 716 %d33-61 / ; The rest of the US-ASCII 717 %d63-90 / ; characters not including 718 %d94-126 ; ">", "[", "]", or "\" 720 2.5. Language 722 Various constant strings in this standard, such as header-names and 723 month names, are derived from English words. Despite their 724 derivation, these words do NOT change when the poster or reader 725 employing them is interacting in a language other than English. 726 Posting and reading agents MAY translate as appropriate in their 727 interaction with the poster or reader, but the forms that actually 728 appear in articles as transmitted MUST be the English-derived ones 729 defined in this standard. 731 3. Changes to the existing protocols 733 This standard prescribes many changes, clarifications and new 734 features since the protocols described in [RFC 1036] and [Son-of- 735 1036]. It is the intention that they can be assimilated into Usenet 736 as it presently operates without major interruption to the service, 737 though some of the new features may not begin to show benefit until 738 they become widely implemented. This section summarizes the main 739 changes, and comments on some features of the transition. 741 3.1. Principal Changes 743 o The [RFC 2822] conventions for parenthesis-enclosed comments in 744 headers are supported. 745 o Whitespace is permitted in Newsgroups-headers, permitting folding 746 of such headers. Indeed, all headers can now be folded. 747 o An enhanced syntax for the Path-header enables the injection 748 point of and the route taken by an article to be determined with 749 certainty. 750 o Large parts of MIME are recognized as an integral part of 751 Netnews. 752 o There is a new Control message 'mvgroup' to facilitate moving a 753 group to a different place (name) in a hierarchy. 754 o There is a new mandatory Injection-Date-header to facilitate the 755 rejection of stale articles. 756 o There are several new optional headers defined, notably Archive, 757 Complaints-To, Injection-Info, Mail-Copies-To, Posted-And-Mailed 758 and User-Agent, leading to increased functionality. 759 o Provision has been made for almost all headers to have MIME-style 760 parameters (to be ignored if not recognized), thus facilitating 761 extension of those headers in future standards. 762 o Certain headers and Control messages (Appendix A.3 and Appendix 763 A.4) have been made obsolete. 764 o Distributions are expected to be checked at the receiving end, as 765 well as the sending end, of a relaying link. 766 o There are numerous other small changes, clarifications and 767 enhancements. 769 3.2. Transitional Arrangements 771 An important distinction must be made between serving and relaying 772 agents, which are responsible for the distribution and storage of 773 news articles, and user agents, which are responsible for 774 interactions with users. It is important that the former should be 775 upgraded to conform to this standard as soon as possible to provide 776 the benefit of the enhanced facilities. Fortunately, the number of 777 distinct implementations of such agents is rather small, at least so 778 far as the main "backbone" of Usenet is concerned, and many of the 779 new features are already supported. Contrariwise, there are a great 780 number of implementations of user agents, installed on a vastly 781 greater number of small sites. Therefore, the new functionality has 782 been designed so that existing agents may continue to be used, 783 although the full benefits may not be realised until a substantial 784 proportion of them have been upgraded. 786 In the list which follows, care has been taken to distinguish the 787 implications for both kinds of agent. 789 o [RFC 2822] style comments in headers do not affect serving and 790 relaying agents (note that the Message-ID-, Newsgroups-, 791 Distribution- and Path-headers do not contain them). They are 792 unlikely to hinder their proper display in existing reading 793 agents except in the case of the References-header in agents 794 which thread articles. Therefore, it is provided that they SHOULD 795 NOT be generated except where permitted by the previous 796 standards. 797 o Because of its importance to all serving agents, the extension 798 permitting whitespace and folding in Newsgroups-headers SHOULD 799 NOT be used until it has been widely deployed amongst relaying 800 agents. User agents are unaffected. 801 o The new style of Path-header is already consistent with the 802 previous standards. However, the intention is that relaying 803 agents should eventually reject articles in the old style, and so 804 this possibility should be offered as a configurable option in 805 relaying agents. User agents are unaffected. 806 o The introduction of MIME reflects a practice that is already 807 widespread. Articles in strict compliance with the previous 808 standards (using strict US-ASCII) will be unaffected. Many user 809 agents already support it, at least to the extent of widely used 810 charsets such as ISO-8859-1. Users expecting to read articles 811 using other charsets will need to acquire suitable reading 812 agents. It is not intended, in general, that any single user 813 agent will be able to display every charset known to IANA, but 814 all such agents MUST support US-ASCII. Serving and relaying 815 agents are not affected. 816 o The new Control: mvgroup command will need to be implemented in 817 serving agents. For the benefit of older serving agents it is 818 therefore RECOMMENDED that it be followed shortly by a 819 corresponding newgroup command and it MUST always be followed by 820 a rmgroup command for the old group after a reasonable overlap 821 period. An implementation of the mvgroup command as an alias for 822 the newgroup command would thus be minimally conforming. User 823 agents are unaffected. 824 o Provision is made for relaying and serving agents to use the 825 Date-header in the case of articles injected through existing 826 agents which do not provide an Injection-Date-header. 827 o All the headers newly introduced by this standard can safely be 828 ignored by existing software, albeit with loss of the new 829 functionality. 831 4. Basic Format 833 4.1. Syntax of News Articles 835 The overall syntax of a news article is: 837 article = 1*( header CRLF ) separator body 838 header = other-header 839 other-header = header-name ":" 1*SP other-content 840 header-name = 1*name-character *( "-" 1*name-character ) 841 name-character = ALPHA / DIGIT 842 other-content = 844 separator = CRLF 845 body = *( *998text CRLF ) 847 However, the rule given above for header is incomplete. Further 848 alternatives will be added incrementally as the various Netnews 849 headers are introduced in this standard (or in future extensions), 850 using the "=/" notation defined in [RFC 2234]. For example, a 851 putative "Usenet-header" would be defined as follows: 853 header =/ Usenet-header 854 Usenet-header = "Usenet" ":" SP Usenet-content 855 *( ";" ( Usenet-parameter / 856 extension-parameter ) ) 857 Usenet-content = 858 Usenet-parameter = 860 where the Usenet-parameter, which MUST always be of the same 861 syntactic form as a parameter, is only provided for certain headers, 862 and even the extension-parameter is omitted in some cases (see 863 4.2.2). Observe that "Usenet" is (and MUST be) of the syntactic form 864 of a header-name. 866 extension-parameter 867 = 868 x-attribute = "x-" attribute 870 An article consists of some headers followed by a body. An empty line 871 separates the two. A header begins with a header-name identifying it, 872 and can be continued onto subsequent lines as described in section 873 4.2.3. The body is largely unstructured text significant only to the 874 poster and the readers. 876 NOTE: Terminology here follows the current custom in the news 877 community, rather than the [RFC 2822] convention of referring to 878 what is here called a "header" as a "header-field" or "field". 880 Note that the separator line MUST be truly empty, not just a line 881 containing white space. Further empty lines following it are part of 882 the body, as are empty lines at the end of the article. 884 NOTE: The syntax above defines the canonical form of a news 885 article as a sequence of lines each terminated by CRLF. This 886 does not prevent serving or relaying agents from storing or 887 handling the article in other formats (e.g. using a single LF in 888 place of CRLF) so long as the overall effects achieved are as 889 defined by this standard when operating on the canonical form. 891 4.2. Headers 893 The order of headers in an article is not significant. However, 894 posting agents are encouraged to put mandatory headers (section 5) 895 first, followed by optional headers (section 6), followed by 896 experimental headers and headers not defined in this standard or its 897 extensions. Relaying agents MUST NOT change the order of the headers 898 in an article. 900 4.2.1. Naming of Headers 902 Despite the restrictions on header-name syntax imposed by the 903 grammar, relaying, serving and reading agents SHOULD tolerate 904 header-names containing any US-ASCII printable character other than 905 colon (":", US-ASCII 58). 907 Whilst relaying agents MUST accept, and pass on unaltered, any non- 908 variant header whose header-name is syntactically correct, and 909 reading agents MUST at least provide the option of displaying them, 910 posting and injecting agents SHOULD NOT generate headers other than 911 o headers established by this standard or any extension to it; 912 o those recognized by other IETF-established standards, notably the 913 Email standard [RFC 2822] and its extensions, and included in the 914 Permanent Message Header Field Repository maintained by IANA in 915 accordance with [KLYNE], but excluding any header explicitly 916 deprecated for Netnews (e.g. see section 9.2.1 for the deprecated 917 Disposition-Notification-To-header); 918 o experimental headers beginning with "X-" (as defined in 4.2.5.1); 919 o on a provisional basis only, headers related to new protocols 920 under development which are listed in the Provisional Message 921 Header Field Repository maintained by IANA in accordance with 922 [KLYNE]. 923 However, software SHOULD NOT attempt to interpret headers not 924 specifically intended to be meaningful in the Netnews environment. 926 Header-names are case-insensitive. There is a preferred case 927 convention set out in [USEAGE], and which is used in the various 928 rules defining headers in this standard. Relaying and reading agents 929 MUST, however, tolerate header-names in any case. 931 4.2.2. MIME-style Parameters 933 A few header-specific MIME-style parameters are defined in this 934 standard (see 6.12 and 6.19), but there is also provision for generic 935 extension-parameters to appear in most headers for the purpose of 936 allowing future extensions to those headers. Observe that such 937 parameters do not, in general, occur in headers defined in other 938 standards, except for the MIME standards [RFC 2045] et seq. and their 939 extensions. 941 Extension-parameters, other than those using x-attributes, MUST NOT 942 be used unless they have first been defined in an IETF-approved RFC 943 (whether Informational, Experimental or Standards-Track) or, on a 944 provisional basis only, in relation to new protocols under 945 development which are the subject of (or intended to be the subject 946 of) some such IETF-approved RFC. They MUST ONLY be defined for use in 947 those headers where the syntax of this standard so allows. They 948 SHOULD NOT, at present, be defined for use in headers in widespread 949 use prior to the introduction of this standard (this restriction is 950 likely to be removed in a future version of this standard). 951 Nevertheless, compliant software MUST accept such parameters wherever 952 syntactically allowed in this standard (ignoring them if their 953 meaning is unknown) and SHOULD accept (and ignore) them in all 954 structured headers wherever defined. 955 [We could go further, and establish an IANA registry for these 956 parameters, preloaded with the ones already defined in this standard. A 957 good model for setting up such a registry is to be found in RFC 2183 958 (Content-Disposition).] 960 NOTE: The syntax does not permit extension-parameters in 961 unstructured headers (where they are unnecessary) or in certain 962 headers (notably the Date-, From-, Message-ID-, Reply-To-, 963 Sender-, Keywords-, Mail-Copies-To-, References-, Supersedes- 964 and Complaints-To-headers) which are the same (or similar to) 965 headers already existing in the Email standards. 967 Each header-specific MIME-style parameter introduced in this standard 968 is described by specifying 969 (a) its attribute, and 970 (b) the syntax rule(s) defining the object(s) permitted in its 971 value. 972 Any parameter, or set of parameters with numbered sections, which, 973 according to [RFC 2231], is semantically equivalent to an unnumbered 974 regular-parameter with that attribute and value may be used. 976 NOTE: If the value is not of the syntactic form of a token and 977 is not encoded as an extended-value, it is necessary to 978 encapsulate it within a quoted-string (2.4.2). Observe that the 979 syntax of a parameter also allows additional WSP, folding and 980 comments. 982 The semantics of a parameter is always to associate its attribute 983 with the object represented by the token, or the semantic value 984 (2.4.2) of the quoted-string, contained in its value. 986 For example, the posting-sender-parameter (6.19) is defined to be 987 988 where 989 sender-value = mailbox / "verified" 990 A valid posting-sender-parameter would be 991 sender = "\"Joe D. Bloggs\" " (authinfo) 992 The comment (syntactically part of the quoted-string) is irrelevant. 993 The actual mailbox (to be used, for example, if email is to be sent 994 to the sender) is 995 "Joe D. Bloggs" 997 4.2.3. White Space and Continuations 999 Each header is logically a single line of characters comprising the 1000 header-name, the colon with its following SP, the content, and any 1001 parameters. For convenience, however, the content and parameters can 1002 be "folded" into a multiple line representation by inserting a CRLF 1003 before any WSP contained within any FWS (or CFWS), but not any other 1004 SP or HTAB, allowed by this standard (see 2.4.2). For example, the 1005 header: 1006 Approved: modname@modsite.example (Moderator of example.foo.bar) 1007 can be represented as: 1008 Approved: modname@modsite.example 1009 (Moderator of example.foo.bar) 1011 FWS occurs at many places in the syntax (usually within a CFWS) in 1012 order to allow the inclusion of comments, whitespace and folding. The 1013 syntax is in fact ambiguous insofar as it sometimes allows for two 1014 consecutive FWS (as least one of which is always optional), or for an 1015 optional FWS followed by an explicit CRLF. In the first case, (one 1016 of) the optional FWS MUST NOT be instantiated; in the second case, 1017 the [*WSP CRLF] within the optional FWS MUST NOT be instantiated. 1018 Thus it is thus precluded that any line of a header should be made up 1019 of whitespace characters and nothing else (for such a line might 1020 otherwise have been interpreted by a non-compliant agent as the 1021 separator between the headers and the body of the article). 1023 NOTE: This does not lead to semantic ambiguity because, unless 1024 specifically stated otherwise, the presence or absence of 1025 folding, a comment or additional WSP has no semantic meaning 1026 and, in particular, it is a matter of indifference whether it 1027 forms a part of the syntactic construct preceding it or the one 1028 following it. 1030 NOTE: It may be observed that the content part of every header 1031 begins and ends with an optional CFWS (or FWS in the case of a 1032 few headers). Moreover, every parameter also begins and ends 1033 with an optional CFWS. 1035 In accordance with the syntax, the header-name and colon on the first 1036 line MUST be followed by a SP (even if the rest of the header is 1037 empty, which in fact cannot occur because this standard defines no 1038 headers with empty content and extensions MUST NOT do so). Even 1039 though the syntax allows otherwise, at least some visible content 1040 MUST appear on that first line (to avoid the possibility of harm by 1041 any non-compliant agent that might eliminate a trailing WSP). Posting 1042 and injecting agents are REQUIRED to enforce these restrictions, 1043 deleting any headers with empty content that are encountered, but 1044 relaying and serving agents MUST accept and pass on untouched 1045 articles that violate them. 1047 NOTE: This standard differs from [RFC 2822] in requiring that SP 1048 following the colon (it was also an [RFC 1036] requirement). 1050 Posters and posting agents SHOULD use SP, not HTAB, where white space 1051 is desired in headers (some existing software expects this). Relaying 1052 and serving agents SHOULD accept HTAB in all such cases, however. 1054 Relaying and serving agents MUST NOT refold headers (i.e. they must 1055 pass on the folding as received). 1057 4.2.4. Comments 1059 Strings of characters which are treated as comments may be included 1060 in headers wherever the syntactic element CFWS occurs. They consist 1061 of characters enclosed in parentheses. Comments may be nested. 1063 NOTE: Although CFWS occurs wherever whitespace is allowed in 1064 almost all headers, there are exceptions where only FWS is 1065 permitted (hence folding but no comments). Notably, this happens 1066 in the case of the Message-ID-, Newsgroups-, Distribution-, 1067 Path- and Followup-To-headers, and within the Date-header except 1068 right at the end. 1070 Since a comment is allowed to contain FWS, folding is permitted 1071 within it as well as immediately preceding and immediately following 1072 it. Also note that, since quoted-pair is allowed in a comment, the 1073 parenthesis and backslash characters may appear in a comment so long 1074 as they appear as a quoted-pair. Semantically, the enclosing 1075 parentheses are not part of the content of the comment; the content 1076 is what is contained between the two parentheses. 1078 Since comments have not hitherto been permitted in news articles, 1079 except in a few specified places, posters and posting-agents SHOULD 1080 NOT insert them except in those places, namely following mailboxes in 1081 From and similar headers (a now deprecated convention for indicating 1082 the owner of that mailbox), and to indicate the name of the timezone 1083 in Date-headers. However, compliant software MUST accept them in all 1084 places where they are syntactically allowed. 1086 4.2.5. Header Properties 1088 There are three special properties that may apply to particular 1089 headers, namely: "experimental", "inheritable", and "variant". When a 1090 header is defined, in this (or any future) standard, as having one 1091 (or possibly more) of these properties, it is subject to special 1092 treatment, as indicated below. 1094 4.2.5.1. Experimental Headers 1096 Experimental headers are those whose header-names begin with "X-". 1097 They are to be used for experimental Netnews features, or for 1098 enabling additional material to be propagated with an article. They 1099 are not (and will not be) defined by this, or any, standard. 1101 NOTE: Experimental headers are suitable for situations where 1102 they need only to be human readable. They are not intended to be 1103 recognized by widely deployed Netnews software and, should such 1104 a requirement be envisaged, it is preferable to arrange for a 1105 suitable normal header to be included in the Provisional Message 1106 Header Field Repository maintained by IANA in accordance with 1107 [KLYNE]. 1109 4.2.5.2. Inheritable Headers 1111 Subject only to the overriding ability of the poster to determine the 1112 contents of the headers in a proto-article, headers with the 1113 inheritable property MUST be copied by followup agents (perhaps with 1114 some modification) into the followup article, and headers without 1115 that property MUST NOT be so copied. Examples include: 1116 o Newsgroups (5.5) - copied from the precursor, subject to any 1117 Followup-To-header. 1118 o Subject (5.4) - often modified by prefixing with "Re: ", but 1119 otherwise copied from the precursor. 1120 o References (6.10) - copied from the precursor, with the addition 1121 of the precursor's Message-ID. 1122 o Distribution (6.6) - copied from the precursor. 1124 NOTE: The Keywords-header is not inheritable, though some older 1125 newsreaders treated it as such. 1127 4.2.5.3. Variant Headers 1129 Headers with the variant property may differ between (or even be 1130 completely absent from) copies of the same article as stored or 1131 relayed throughout a Netnews system. The manner of the difference (or 1132 absence) MUST be as specified in this (or some future) standard. 1133 Typically, these headers are modified as articles are propagated, or 1134 they reflect the status of the article on a particular serving agent, 1135 or cooperating group of such agents. The variant header MAY be placed 1136 anywhere within the headers (though placing it first is recommended). 1137 The principal examples are: 1139 o Path (5.6) - augmented at each relaying agent that an article 1140 passes through. 1141 o Xref (6.16) - used to keep track of the article locators of 1142 crossposted articles so that reading agents serviced by a 1143 particular serving agent can mark such articles as read. 1145 4.3. Body 1147 The body of an article SHOULD NOT be empty. A posting or injecting 1148 agent which does not reject such an article entirely SHOULD at least 1149 issue a warning message to the poster and supply a non-empty body. 1150 Note that the separator line MUST be present even if the body is 1151 empty. 1153 NOTE: Some existing news software is known to react badly to 1154 body-less articles, hence the request for posting and injecting 1155 agents to insert a body in such cases. The sentence "This 1156 article was probably generated by a buggy news reader" has 1157 traditionally been used in this situation. 1159 Note that an article body is a sequence of lines terminated by CRLFs, 1160 not arbitrary binary data, although a MIME Content-Type-header may 1161 impose some structure or intended interpretation upon it. In 1162 particular the body MUST end with a CRLF. 1164 4.4. Octets, Characters and Character Sets 1166 Transmission paths for news articles MUST treat news articles as 1167 uninterpreted sequences of octets, excluding the values 0 (US-ASCII 1168 NUL) and 13 and 10 (US-ASCII CR and LF, which MUST ONLY appear in the 1169 combination CRLF which denotes a line separator). 1171 NOTE: this corresponds to the range of octets permitted for MIME 1172 "8bit data" [RFC 2045]. Thus raw binary data cannot be 1173 transmitted in an article body except by the use of a Content- 1174 Transfer-Encoding such as base64. 1176 In particular, transmission paths MUST convey all headers (including 1177 body part headers and headers within message/rfc822 objects) intact, 1178 even if they contain octets in the range 128 to 255. These 1179 requirements include the transmissiom paths between posting agents, 1180 injecting agents, relaying agents, serving agents and reading agents, 1181 but NOT the paths traversed by Netnews articles that have been 1182 gatewayed into Email (8.8.1). 1183 [At some point it will be necessary for the IMAP standards to catch up 1184 with these requirements.] 1186 Moreover, a body or body part that uses Content-Transfer-Encoding 1187 8bit MUST NOT have that encoding changed to quoted-printable or bas64 1188 during transmission, except in the course of gatewaying into some 1189 other medium such as email (8.8). 1191 NOTE: An agent that was incapable of handling 8bit would be 1192 unlikely to be able to make use of the article on its own 1193 servers, and the usual flooding algorithm would likely find some 1194 alternative route to get the article to destinations where it is 1195 needed. 1197 4.4.1. Character Sets within Article Headers 1199 The character set for headers is US-ASCII. Where the use of non- 1200 ASCII characters is required, they MUST be encoded using the MIME 1201 mechanisms defined in [RFC 2047] and [RFC 2231]. 1203 Examples: 1204 Organization: Technische =?iso-8859-1?Q?Universit=E4t_M=FCnchen?= 1205 Approved: =?iso-8859-1?Q?Fran=E7ois_Faur=E9?= 1206 (=?iso-8859-1?Q*fr?Mod=E9rateur_autoris=E9?=) 1207 Archive: yes; filename*=iso-8859-1'es'ma=F1ana.txt 1209 NOTE: The raw use of non-ASCII character sets or of encodings 1210 other than those described above is not compliant with this 1211 standard, even though such usage has been seen in some 1212 hierarchies (with no indication of which character set has been 1213 used beyond the user's ability to guess based upon other clues 1214 in the article, or custom within the newsgroup). Future 1215 extensions to this standard may make provision for other 1216 character sets, hence the requirement that octets beyond the 1217 US-ASCII range be transported without error. 1219 4.4.2. Character Sets within Article Bodies 1221 Within article bodies, characters are represented as octets according 1222 to the encoding scheme implied by any Content-Transfer-Encoding- and 1223 Content-Type-headers [RFC 2045]. In the absence of such headers, 1224 reading agents cannot be relied upon to display correctly more than 1225 the US-ASCII characters, though they MUST display at least those. 1227 NOTE: The use of non-ASCII characters in the absence of an 1228 appropriate Content-Type-header is not compliant with this 1229 standard, even though such usage has been seen in some 1230 hierarchies (with no indication of which character set has been 1231 used beyond the user's ability to guess based upon other clues 1232 in the article, or custom within the newsgroup). 1234 Followup agents MUST be careful to apply appropriate encodings to the 1235 outbound followup. A followup to an article containing non-ASCII 1236 material is very likely to contain non-ASCII material itself. 1238 4.5. Size Limits 1240 Compliant software MUST support headers of at least 998 octets, and 1241 that is the only limit on the length of a header line prescribed by 1242 this standard. However, specific rules to the contrary may apply in 1243 particular cases (for example, according to [RFC 2047] header lines 1244 containing encoded-words are limited to 76 octets). 1246 NOTE: There is NO restriction on the number of lines into which 1247 a header may be split, and hence there is NO restriction on the 1248 total length of a header (in particular it may, by suitable 1249 folding, be made to exceed the 998 octets restriction pertaining 1250 to a single header line). 1252 The syntax provides for the lines of a body to be up to 998 octets in 1253 length, not including the CRLF. All software compliant with this 1254 standard MUST support body lines of at least that length, and all 1255 such software SHOULD support lines of arbitrary length. In 1256 particular, relaying agents MUST transmit lines of arbitrary length 1257 without truncation or any other modification. 1259 NOTE: The limit of 998 octets is consistent with the 1260 corresponding limit in [RFC 2822]. In practice, lines will be 1261 much shorter, and [USEAGE] suggests a default limit of 79 1262 characters to be used where there are no pressing needs to do 1263 otherwise. 1265 NOTE: This standard provides no upper bound on the overall size 1266 of a single article, but neither does it forbid relaying agents 1267 from dropping articles of excessive length. It is, however, 1268 suggested that any limits thought appropriate by particular 1269 agents would be more appropriately expressed in megabytes than 1270 in kilobytes. 1272 4.6. Example 1274 Here is a sample article: 1276 Path: server.example/unknown.site2.example@site2.example/ 1277 relay.site.example/site.example/injector.site.example%jsmith 1278 Newsgroups: example.announce,example.chat 1279 Message-ID: <9urrt98y53@site1.example> 1280 From: Ann Example 1281 Subject: Announcing a new sample article. 1282 Date: Wed, 27 Mar 2002 12:12:50 +0300 1283 Approved: example.announce moderator 1284 Followup-To: example.chat 1285 Reply-To: Ann Example 1286 Expires: Mon, 22 Apr 2002 12:12:50 +0300 1287 Organization: Site1, The Number one site for examples. 1288 User-Agent: ExampleNews/3.14 (Unix) 1289 Keywords: example, announcement, standards, RFC 1036, Usefor 1290 Summary: The URL for the next standard. 1291 Injection-Info: injector.site.example; posting-host=du003.site.example 1292 Complaints-To: abuse@site.example 1293 Injection-Date: Mon, 22 Apr 2002 13:22:40 +0300 1295 Just a quick announcement that a new standard example article has 1296 been released; it is in the new [USEFOR] standard obtainable from 1297 ftp.ietf.org. 1299 Ann. 1301 -- 1302 Ann Example Sample Poster to the Stars 1303 "The opinions in this article are bloody good ones" - J. Clarke. 1304 [The RFC Editor is invited to change the above Date, Injection-Date and 1305 Expires headers to match the actual publication dates and to insert its 1306 correct URL.] 1308 5. Mandatory Headers 1310 An article MUST have one, and only one, of each of the following 1311 headers: Date, From, Message-ID, Subject, Newsgroups, Path. 1313 Note also that there are situations, discussed in the relevant parts 1314 of section 6, where References-, Sender-, or Approved-headers are 1315 mandatory. 1317 A proto-article (8.2.1) may lack some of these mandatory headers, but 1318 they MUST then be supplied by the injecting agent. 1320 5.1. Date 1322 The Date-header contains the date and time that the article was 1323 prepared by the poster ready for transmission and SHOULD express the 1324 poster's local time. The content syntax makes use of syntax defined 1325 in [RFC 2822] (but see the revised definition of zone in section 1326 2.4.3). 1328 header =/ Date-header 1329 Date-header = "Date" ":" SP Date-content 1330 Date-content = date-time 1332 The date-time MUST be semantically valid as required by [RFC 2822]. 1333 Although folding white space is permitted throughout the date-time 1334 syntax, it is RECOMMENDED that a single space be used in each place 1335 that FWS appears (whether it is required or optional). 1337 The date-time MUST NOT be more than 24 hours into the future 1338 (injecting agents will reject such articles, possibly even when the 1339 margin is less than 24 hours - see 8.2.2 - and MAY also reject them 1340 if it is inordinately far into the past). Relaying agents MUST NOT 1341 modify the Date-header in transit. 1343 5.1.1. Examples 1345 Date: Sat, 26 May 2001 11:13:00 -0500 (EST) 1346 Date: 26 May 2001 16:13 +0000 1347 Date: 26 May 2001 16:13 GMT (Obsolete) 1349 5.2. From 1351 The From-header contains the email address(es), possibly including 1352 the full name(s), of the article's poster(s), or of the person or 1353 agent on whose behalf the article is posted (see the Sender-header, 1354 6.2). The content syntax makes use of syntax defined in [RFC 2822]. 1356 header =/ From-header 1357 From-header = "From" ":" SP From-content 1358 From-content = mailbox-list 1360 NOTE: Observe that there is no provision for parameters in this 1361 header, or in other headers containing addresses likely to be 1362 used for sending email (see 4.2.2). When, for whatever reason, 1363 a poster does not wish to use a valid address, the mailbox 1364 concerned SHOULD end in the top level domain ".invalid" [RFC 1365 2606]. 1367 5.2.1. Examples: 1369 From: John Smith 1370 From: "John Smith" , dave@isp.example 1371 From: "John D. Smith" , andrew@isp.example, 1372 fred@site2.example 1373 From: Jan Jones 1374 From: Jan Jones 1375 From: dave@isp.example (Dave Smith) 1377 NOTE: the last example shows a now deprecated convention of 1378 putting a poster's full name in a comment following the mailbox, 1379 rather than in a phrase at the start of it. Observe also the use 1380 of the quoted-string "John D. Smith" which SHOULD still be used 1381 on account of presence of the '.' character, even though 1382 software is now REQUIRED to operate without it (see 2.4.3). 1384 5.3. Message-ID 1386 The Message-ID-header contains the article's message identifier, a 1387 unique identifier distinguishing the article from every other 1388 article. The content syntax makes use of syntax defined in [RFC 2822] 1389 (but see the revised definition of msg-id in section 2.4.3). 1391 header =/ Message-ID-header 1392 Message-ID-header = "Message-ID" ":" SP Message-ID-content 1393 Message-ID-content = [FWS] msg-id [FWS] 1395 The msg-id MUST NOT be more than 250 octets in length. 1397 NOTE: The length restriction ensures that systems which accept 1398 message identifiers as a parameter when retrieving an article 1399 (e.g. [NNTP]) can rely on a bounded length. Observe that msg-id 1400 includes the '<' and '>'. 1402 Observe that, in contrast to the corresponding header in [RFC 1403 2822], the syntax does not allow comments within the Message- 1404 ID-header; this is to simplify processing by relaying and 1405 serving agents and to ensure interoperability with existing 1406 implementations. 1408 An agent generating an article's message identifier MUST ensure that 1409 it is unique (as also required in [RFC 2822]) and that it is chosen 1410 in such a way that it will NEVER be applied to any other Netnews 1411 article or Email message. However, an article emailed (without 1412 encapsulation) to a moderator (8.2.2 and 8.7) or gatewayed into some 1413 other medium (8.8.1) SHOULD retain the same message identifier 1414 throughout its travels so long as it remains recognizably the same 1415 article. 1417 Even though commonly derived from the domain name of the originating 1418 site (and domain names are case-insensitive), a message identifier 1419 MUST NOT be altered in any way during transport, or when copied (as 1420 into a References-header), and thus a simple (case-sensitive) 1421 comparison of octets will always suffice to recognize that same 1422 message identifier wherever it subsequently reappears. 1424 NOTE: These requirements are to be contrasted with those of the 1425 un-normalized msg-ids defined by [RFC 2822], which may perfectly 1426 legitimately become normalized (or vice versa) during transport 1427 or copying in email systems. 1429 NOTE: Some old software may treat message identifiers that 1430 differ only in case within their id-right part as equivalent, 1431 and implementors of agents that generate message identifiers 1432 should be aware of this. 1434 5.4. Subject 1436 The Subject-header contains a short string identifying the topic of 1437 the article. This is an inheritable header (4.2.5.2), normally to be 1438 copied into the Subject-header of any followup with the possible 1439 addition of a back-reference as described in B.6. 1441 header =/ Subject-header 1442 Subject-header = "Subject" ":" SP Subject-content 1443 Subject-content = unstructured 1445 NOTE: The syntax of unstructured differs from that prescribed in 1446 [RFC 2822], so ensuring that the Subject-content is not 1447 permitted to be completely empty, or to consist of WSP only. 1449 5.5. Newsgroups 1451 The Newsgroups-header's content specifies the newsgroup(s) in which 1452 the article is intended to appear. It is an inheritable header 1453 (4.2.5.2) which then becomes the default Newsgroups-header of any 1454 followup, unless a Followup-To-header is present to prescribe 1455 otherwise (see 8.6). Articles MUST NOT be passed between relaying 1456 agents or to serving agents unless the sending agent has been 1457 configured to supply and the receiving agent to receive at least one 1458 of the newsgroup-names in the Newsgroups-header. 1460 header =/ Newsgroups-header 1461 Newsgroups-header = "Newsgroups" ":" SP Newsgroups-content 1462 *( ";" extension-parameter ) 1463 Newsgroups-content = [FWS] newsgroup-name 1464 *( [FWS] ng-delim [FWS] newsgroup-name ) 1465 [FWS] 1466 newsgroup-name = component *( "." component ) 1467 component = 1*component-grapheme 1468 ng-delim = "," 1469 component-grapheme = DIGIT / ALPHA / "+" / "-" / "_" 1470 [Maybe some better word for 'grapheme'.] 1472 NOTE: Observe that the syntax does not allow comments within the 1473 Newsgroups-header; this is to simplify processing by relaying 1474 and serving agents which have a requirement to process this 1475 header extremely rapidly. 1477 Components beginning with underline ("_") are reserved for use by 1478 future versions of this standard and MUST NOT occur in newsgroup- 1479 names (whether in Newsgroups-headers or in newgroup control messages 1480 (7.2.1)). However, such names MUST be accepted. 1482 Components beginning with "+" or "-" are reserved for use by 1483 implementations and MUST NOT occur in newsgroup-names (whether in 1484 Newsgroups-headers or in newgroup control messages). Implementors may 1485 assume that this rule will not change in any future version of this 1486 standard. 1488 NOTE: For example, implementors may safely use leading "+" and 1489 "-" to "escape" other entities within something that looks like 1490 a newsgroup-name. 1492 The format of newsgroup-names is ultimately determined by the 1493 policies of those administrative agencies which have the 1494 responsibility for creating new newsgroups within the various 1495 hierarchies of Usenet. There are traditional, social and technical 1496 arguments why there should be restrictions on these formats (and the 1497 force of the technical ones changes over time with developments in 1498 computers and operating systems). Therefore, such administrative 1499 agencies SHOULD establish and promulgate the restrictions they intend 1500 to apply within their own hierarchies. 1502 NOTE: These issues are discussed more fully in [USEAGE]. The 1503 following policy restrictions represent what is considered safe 1504 and appropriate at the present time. Although purely advisory, 1505 hierarchy administrators should consider the consequences 1506 carefully before allowing them to be exceeded. They could also 1507 be taken as the defaults in unmanaged hierarchies. 1509 1. Uppercase letters are forbidden. 1511 2. A component name is forbidden to consist entirely of digits. 1513 3. A component is limited to 30 component-graphemes and a 1514 newsgroup-name to 66 component-graphemes (counting also the 1515 '.'s separating the components). 1517 Serving and relaying agents MUST accept any syntactially correct 1518 newsgroup-name even if it would violate whatever policy restrictions 1519 may be in place. Posting and injecting agents MAY enforce them (but 1520 only with the explicit agreement of the poster). 1522 The inclusion of folding white space within a Newsgroups-content is a 1523 newly introduced feature in this standard. It MUST be accepted by all 1524 conforming implementations (relaying agents, serving agents and 1525 reading agents). Posting agents should be aware that such postings 1526 may be rejected by overly-critical old-style relaying agents. When a 1527 sufficient number of relaying agents are in conformance, posting 1528 agents SHOULD generate such whitespace in the form of so 1529 as to keep the length of lines in the relevant headers (notably 1530 Newsgroups and Followup-To) to a reasonable length (such as 79 1531 characters, which is likely to be displayed satisfactorily by most 1532 current reading agents). Before such critical mass occurs, injecting 1533 agents MAY reformat such headers by removing whitespace inserted by 1534 the posting agent, but relaying agents MUST NOT do so. 1536 Posters SHOULD use only the names of existing newsgroups in the 1537 Newsgroups-header. However, it is legitimate to cross-post to 1538 newsgroups which do not exist on the posting agent's host, provided 1539 that at least one of the newsgroups DOES exist there. Relaying agents 1540 MUST NOT rewrite Newsgroups-headers in any way, even if some or all 1541 of the newsgroups do not exist on the relaying agent's host. Serving 1542 agents MUST NOT create new newsgroups simply because an unrecognized 1543 newsgroup-name occurs in a Newsgroups-header (see 7.2.1 for the 1544 correct method of newsgroup creation). 1546 The Newsgroups-header is intended for use in Netnews articles rather 1547 than in email messages. It MAY be used in an email message to 1548 indicate that it is a copy also posted to the listed newsgroups, in 1549 which case the inclusion of a Posted-And-Mailed header (6.9) would 1550 also be appropriate. However, it SHOULD NOT be used in an email-only 1551 reply to a Netnews article (thus the "inheritable" property of this 1552 header applies only to followups to a newsgroup, and not to followups 1553 to the poster). 1555 5.5.1. Forbidden newsgroup-names 1557 The following forms of newsgroup-name MUST NOT be used except for the 1558 specific purposes indicated: 1560 o Newsgroup-names having only one component. These are reserved for 1561 newsgroups whose propagation is restricted to a single host or 1562 local network, and for pseudo-newsgroups such as "poster" (which 1563 has special meaning in the Followup-To-header - see section 6.7), 1564 "junk" (often used by serving agents), and "control" (likewise); 1565 o Any newsgroup-name beginning with "control." (used as pseudo- 1566 newsgroups by many serving agents); 1567 o Any newsgroup-name containing the component "ctl" (likewise); 1568 o "to" or any newsgroup-name beginning with "to." (reserved for the 1569 ihave/sendme protocol described in section 7.4, and for test 1570 articles sent on an essentially point-to-point basis); 1571 o Any newsgroup-name beginning with "example." (reserved for 1572 examples in this and other standards); 1573 o Any newsgroup-name containing the component "all" (because this 1574 is used as a wildcard in some implementations). 1576 A newsgroup-name SHOULD NOT appear more than once in the Newsgroups- 1577 header. The order of newsgroup-names in the Newsgroups-header is not 1578 significant, except for determining which moderator to send the 1579 article to if more than one of the groups is moderated (see 8.2). 1581 5.6. Path 1583 The Path-header shows the route taken by an article since its entry 1584 into the Netnews system. It is a variant header (4.2.5.3), each agent 1585 that processes an article being required to add one (or more) entries 1586 to it. This is primarily to enable relaying agents to avoid sending 1587 articles to sites already known to have them, in particular the site 1588 they came from, and additionally to permit tracing the route articles 1589 take in moving over the network, and for gathering Usenet statistics. 1590 Finally the presence of a '%' path-delimiter in the Path-header can 1591 be used to identify an article injected in conformance with this 1592 standard. 1594 5.6.1. Format 1596 header =/ Path-header 1597 Path-header = "Path" ":" SP Path-content 1598 *( ";" extension-parameter ) 1599 Path-content = [FWS] 1600 *( path-identity [FWS] path-delimiter [FWS] ) 1601 tail-entry [FWS] 1602 path-identity = ( ALPHA / DIGIT ) 1603 *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 1604 path-delimiter = "/" / "?" / "%" / "," / "!" 1605 tail-entry = path-identity 1607 NOTE: A Path-content will inevitably contain at least one path- 1608 identity, except possibly in the case of a proto-article that 1609 has not yet been injected onto the network. 1611 NOTE: Observe that the syntax does not allow comments within the 1612 Path-header; this is to simplify processing by relaying and 1613 injecting agents which have a requirement to process this header 1614 extremely rapidly. 1616 A relaying agent SHOULD NOT pass an article to another relaying agent 1617 whose path-identity (or some known alias thereof) already appears in 1618 the Path-content. Since the comparison may be either case sensitive 1619 or case insensitive, relaying agents SHOULD NOT generate a name which 1620 differs from that of another site only in terms of case. 1622 A relaying agent MAY decline to accept an article if its own path- 1623 identity is already present in the Path-content or if the Path- 1624 content contains some path-identity whose articles the relaying agent 1625 does not want, as a matter of local policy. 1627 NOTE: This last facility is sometimes used to detect and decline 1628 control messages (notably cancel messages) which have been 1629 deliberately seeded with a path-identity to be "aliased out" by 1630 sites not wishing to act upon them. 1632 5.6.2. Adding a path-identity to the Path-header 1634 When an injecting, relaying or serving agent receives an article, it 1635 MUST prepend its own path-identity followed by a path-delimiter to 1636 the beginning of the Path-content. In addition, it SHOULD then add 1637 CRLF and WSP if it would otherwise result in a line longer than 79 1638 characters. 1640 The path-identity added MUST be unique to that agent. To this end it 1641 SHOULD be one of: 1643 1. A fully qualified domain name (FQDN) associated (by the Internet 1644 DNS service [RFC 1034]) with an A record, which SHOULD identify 1645 the actual machine prepending this path-identity. Ideally, this 1646 FQDN should also be "mailable" (see later in this section). 1648 2. A fully qualified domain name (FQDN) associated (by the Internet 1649 DNS service) with an MX record, which MUST be "mailable". 1651 3. An arbitrary name believed to be unique and registered at least 1652 with all sites which receive articles directly from the given 1653 site. 1655 4. An encoding of an IP address - or [RFC 1656 2373] (the requirement to be able to use an is the 1657 reason for including ':' as an allowed character within a path- 1658 identity). 1660 The FQDN of an agent is "mailable" if the administrators of that 1661 agent can be reached by email using both of the forms "usenet@" 1662 and "news@", in conformity with [RFC 2142]. 1664 Of the above options, nos. 1 to 3 are much to be preferred, unless 1665 there are strong technical reasons dictating otherwise. In 1666 particular, the injecting agent's path-identity MUST, as a special 1667 case, be an FQDN as in option 1 or option 2, and MUST be mailable. 1668 Additionally, in the case of an injecting agent offering its services 1669 to the general public, its administrators MUST also be reachable 1670 using the form "abuse@" UNLESS a more specific complaints 1671 address has been specified in a Complaints-To-header (6.20). 1672 [Suggested alternative for 1st two sentences: 1673 For injecting agents, the path-identity MUST be option 1 or 2. For 1674 other agents, options 1 through 3 are preferrable.] 1676 The injecting agent's path-identity MUST be followed by the special 1677 path-delimiter '%' which serves to separate the pre-injection and 1678 post-injection regions of the Path-content (see 5.6.3). 1680 In the case of a relaying or serving agent, the path-delimiter is 1681 chosen as follows. When such an agent receives an article, it MUST 1682 establish the identity of the source and compare it with the leftmost 1683 path-identity of the Path-content. If it matches, a '/' should be 1684 used as the path-delimiter when prepending the agent's own path- 1685 identity. If it does not match then the agent should prepend two 1686 entries to the Path-content; firstly the true established path- 1687 identity of the source followed by a '?' path-delimiter, and then, 1688 to the left of that, the agent's own path-identity followed by a '/' 1689 path-delimiter as usual. This prepending of two entries SHOULD NOT 1690 be done if the provided and established identities match. 1692 Any method of establishing the identity of the source may be used 1693 with the consideration that, in the event of problems, the agent 1694 concerned may be called upon to justify it. 1696 NOTE: The use of the '%' path-delimiter marks the position of 1697 the injecting agent in the chain. In normal circumstances there 1698 should therefore be only one '%' path-delimiter present. If more 1699 than one '%' is found, then the article has evidently been 1700 reinjected (8.2) at some stage, in which case the path-identity 1701 in front of the leftmost '%' is to be regarded as the true 1702 injecting agent. 1704 5.6.3. The tail-entry 1706 For historical reasons, the tail-entry (i.e. the rightmost entry in 1707 the Path-content) is regarded as a "user name", and therefore MUST 1708 NOT be interpreted as a site through which the article has already 1709 passed. Moreover, the Path-content as a whole is not an email address 1710 and MUST NOT be used to contact the poster. Posting and/or injecting 1711 agents MAY place any string here. When it is not an actual user 1712 name, the string "not-for-mail" is often used. 1714 Often this field will be the only entry in the region (known as the 1715 pre-injection region) after the '%', although there may be entries 1716 corresponding to machines traversed between the posting agent and the 1717 injecting agent proper. In particular, injecting agents that receive 1718 articles from many sources MAY include information to establish the 1719 circumstances of the injection such as the identity of the source 1720 machine (especially if an Injection-Info-header (6.19) is not being 1721 provided). Any such inclusion SHOULD NOT conflict with any genuine 1722 site identifier. The '!' path-delimiter may be used freely within 1723 the pre-injection region, although '/' and '?' are also appropriate 1724 if used correctly. 1726 5.6.4. Path-Delimiter Summary 1728 A summary of the various path-delimiters. The name immediately to the 1729 left of the path-delimiter is always that of the machine which added 1730 the path-delimiter. 1732 '/' The name immediately to the right is known to be the identity of 1733 the machine from which the article was received (either because 1734 the entry was made by that machine and we have verified it, or 1735 because we have added it ourselves). 1737 '?' The name immediately to the right is the claimed identity of the 1738 machine from which the article was received, but we were unable 1739 to verify it (and have prepended our own view of where it came 1740 from, and then a '/'). 1742 '%' Everything to the right is the pre-injection region followed by 1743 the tail-entry. The name on the left is the FQDN of the 1744 injecting agent. The presence of two '%'s in a path indicates a 1745 reinjection (see 8.2.2). 1747 '!' The name immediately to the right is unverified. The presence of 1748 a '!' to the left of the '%' indicates that the identity to the 1749 left is that of an old-style system not conformant with this 1750 standard. 1752 ',' Reserved for future use, treat as '/'. 1754 Other 1755 Old software may possibly use other path-delimiters, which should 1756 be treated as '!'. But note in particular that ':', '-' and '_' 1757 are components of names, not path-delimiters, and FWS on its own 1758 MUST NOT be used as the sole path-delimiter. 1760 NOTE: Old Netnews relaying and injecting agents almost all 1761 delimit Path entries with a '!', and these entries are not 1762 verified. The presence of '%' indicates that the article was 1763 injected by software conforming to this standard, and the 1764 presence of '!' to the left of a '%' indicates that the article 1765 passed through systems developed prior to this standard. It is 1766 anticipated that relaying agents will reject articles in the old 1767 style once this new standard has been widely adopted. 1769 5.6.5. Example 1771 Path: foo.isp.example/ 1772 foo-server/bar.isp.example?10.123.12.2/old.site.example! 1773 barbaz/baz.isp.example%dialup123.baz.isp.example!x 1775 NOTE: That article was injected into the news stream by 1776 baz.isp.example (complaints may be addressed to 1777 abuse@baz.isp.example). The injector has taken care to record 1778 that it got it from dialup123.baz.isp.example. "x" is a dummy 1779 tail-entry, though sometimes a real userid is put there. 1781 The article was relayed, perhaps by UUCP, to the machine known, 1782 at least to old.site.example, as "barbaz". 1784 Barbaz relayed it to old.site.example, which does not yet 1785 conform to this standard (hence the '!' path-delimiter). So one 1786 cannot be sure that it really came from barbaz. 1788 Old.site.example relayed it to a site claiming to have the IP 1789 address [10.123.12.2], and claiming (by using the '/' path- 1790 delimiter) to have verified that it came from old.site.example. 1792 [10.123.12.2] relayed it to "foo-server" which, not being 1793 convinced that it truly came from [10.123.12.2], did a reverse 1794 lookup on the actual source and concluded it was known as 1795 bar.isp.example (that is not to say that [10.123.12.2] was not a 1796 correct IP address for bar.isp.example, but simply that that 1797 connection could not be substantiated by foo-server). Observe 1798 that foo-server has now added two entries to the Path. 1800 "foo-server" is a locally significant name within the complex 1801 site of many machines run by foo.isp.example, so the latter 1802 should have no problem recognizing foo-server and using a '/' 1803 path-delimiter. Presumably foo.isp.example then delivered the 1804 article to its direct clients. 1806 It appears that foo.isp.example and old.site.example decided to 1807 fold the line, on the grounds that it seemed to be getting a 1808 little too long. 1810 5.7. Injection-Date 1812 The Injection-Date-header contains the date and time that the article 1813 was injected into the network. Its purpose is to prevent the 1814 reinjection into the news stream of "stale" articles which have 1815 already expired by the time they arrive at some relaying or serving 1816 agent. 1818 header =/ Injection-Date-header 1819 Injection-Date-header 1820 = "Injection-Date" ":" SP Injection-Date-content 1821 *( ";" extension-parameter ) 1822 Injection-Date-content 1823 = date-time 1825 See the remarks under the Date-header (5.1) regarding the syntax of a 1826 date-time and the requirements and recommendations to which it is 1827 subject. 1829 An Injection-Date-header MUST NOT be added to an article except by an 1830 injecting agent, hence it will never be present in a proto-article 1831 (8.2.1). It MUST be added by each injecting agent but, once added, 1832 it MUST NOT subsequently be changed or removed by any other agent, 1833 even during reinjection (8.2.2). 1835 NOTE: The date-time would normally be expected to be later than 1836 the date-time in the Date-header, but differences between the 1837 clocks on the various agents and other special circumstances 1838 might vitiate that; no provision is made for any such 1839 discrepancy to be corrected - better that the injecting agent 1840 should just insert the correct time as it sees it. 1842 Since this header is newly introduced in this standard, other 1843 agents cannot rely on its always being present; therefore, 1844 provision is made (8.3,8.4) for the Date-header to be used when 1845 it is absent. 1847 This header is intended to replace the currently-used but nowhere- 1848 documented header "NNTP-Posting-Date", whose use is now deprecated. 1850 6. Optional Headers 1852 None of the headers appearing in this section is required to appear 1853 in every article but some of them are required in certain types of 1854 article, such as followups. Any header defined in this (or any other) 1855 standard MUST NOT appear more than once in an article unless 1856 specifically stated otherwise. Experimental headers (4.2.5.1) and 1857 headers defined by cooperating subnets are exempt from this 1858 requirement. See section 8 "Duties of Various Agents" for the full 1859 picture. 1861 6.1. Reply-To 1863 The Reply-To-header specifies a reply address(es) to be used for 1864 personal replies for the poster(s) of the article when this is 1865 different from the poster's address(es) given in the From-header. The 1866 content syntax makes use of syntax defined in [RFC 2822]. 1868 header =/ Reply-To-header 1869 Reply-To-header = "Reply-To" ":" SP Reply-To-content 1870 Reply-To-content = address-list 1872 In the absence of Reply-To, the reply address(es) is the address(es) 1873 in the From-header. 1875 6.1.1. Examples 1877 Reply-To: John Smith 1878 Reply-To: John Smith , dave@isp.example 1879 Reply-To: John Smith ,andrew@isp.example, 1880 fred@site2.example 1882 6.2. Sender 1884 The Sender-header specifies the mailbox of the person or entity which 1885 caused this article to be posted (and hence injected), if that person 1886 or entity is different from that given in the From-header or if more 1887 than one mailbox appears in the From-header. This header SHOULD NOT 1888 appear in an article unless the sender is different from the poster. 1889 This header is appropriate for use by automatic article posters. The 1890 content syntax makes use of syntax defined in [RFC 2822]. 1892 header =/ Sender-header 1893 Sender-header = "Sender" ":" SP Sender-content 1894 Sender-content = mailbox 1896 6.3. Organization 1898 The Organization-header is a short phrase identifying the poster's 1899 organization. 1901 header =/ Organization-header 1902 Organization-header = "Organization" ":" SP Organization-content 1903 Organization-content= unstructured 1905 6.4. Keywords 1907 The Keywords field contains a comma separated list of important words 1908 and phrases intended to describe some aspect of the content of the 1909 article. The content syntax makes use of syntax defined in [RFC 1910 2822]. 1912 header =/ Keywords-header 1913 Keywords-header = "Keywords" ":" SP Keywords-content 1914 Keywords-content = phrase *( "," phrase ) 1916 NOTE: The list is comma separated, NOT space separated. 1918 NOTE: Contrary to the usage defined in [RFC 2822], this standard 1919 does not permit multiple occurrences of this header. 1921 6.5. Summary 1923 The Summary-header is a short phrase summarizing the article's 1924 content. 1926 header =/ Summary-header 1927 Summary-header = "Summary" ":" SP Summary-content 1928 Summary-content = unstructured 1930 6.6. Distribution 1932 The Distribution-header is an inheritable header (see 4.2.5.2) which 1933 specifies geographical or organizational limits to an article's 1934 propagation. 1936 header =/ Distribution-header 1937 Distribution-header = "Distribution" ":" SP Distribution-content 1938 *( ";" extension-parameter ) 1939 Distribution-content= distribution *( dist-delim distribution ) 1940 dist-delim = "," 1941 distribution = [FWS] distribution-name [FWS] 1942 distribution-name = ALPHA 1*distribution-rest 1943 distribution-rest = ALPHA / "+" / "-" / "_" 1945 Articles MUST NOT be passed between relaying agents or to serving 1946 agents unless the sending agent has been configured to supply and the 1947 receiving agent to receive at least one of the distributions in the 1948 Distribution-header. Additionally, reading agents MAY also be 1949 configured so that unwanted distributions do not get displayed. 1951 NOTE: Although it would seem redundant to filter out unwanted 1952 distributions at both ends of a relaying link (and it is clearly 1953 more efficient to do so at the sending end), many sending sites 1954 have been reluctant, historically speaking, to apply such 1955 filters (except to ensure that distributions local to their own 1956 site or cooperating subnet did not escape); moreover they tended 1957 to configure their filters on an "all but those listed" basis, 1958 so that new and hitherto unheard of distributions would not be 1959 caught. Indeed many "hub" sites actually wanted to receive all 1960 possible distributions so that they could feed on to their 1961 clients in all possible geographical (or organizational) 1962 regions. 1964 Therefore, it is desirable to provide facilities for rejecting 1965 unwanted distributions at the receiving end. Indeed, it may be 1966 simpler to do so locally than to inform each sending site of 1967 what is required, especially in the case of specialized 1968 distributions (for example for control messages, such as cancels 1969 from certain issuers) which might need to be added at short 1970 notice. The possibility for reading agents to filter 1971 distributions has been provided for the same reason. 1973 Exceptionally, ALL relaying agents are deemed willing to supply or 1974 accept the distribution "world", and NO relaying agent should supply 1975 or accept the distribution "local". However, "world" SHOULD NEVER be 1976 mentioned explicitly since it is the default when the Distribution- 1977 header is absent entirely. "All" MUST NOT be used as a 1978 distribution-name. Distribution-names SHOULD contain at least three 1979 characters, except when they are two-letter country names as in [ISO 1980 3166]. Distribution-names are case-insensitive (i.e. "US", "Us" and 1981 "us" all specify the same distribution). 1983 Followup agents SHOULD initially supply the same Distribution-header 1984 as found in the precursor. 1986 6.7. Followup-To 1988 The Followup-To-header specifies which newsgroup(s) followups should 1989 be posted to. 1991 header =/ Followup-To-header 1992 Followup-To-header = "Followup-To" ":" SP Followup-To-content 1993 *( ";" extension-parameter ) 1994 Followup-To-content = Newsgroups-content / 1995 [FWS] %x70.6F.73.74.65.72 [FWS] 1996 ; which is a case-sensitive "poster" 1998 The syntax is the same as that of the Newsgroups-content, with the 1999 addition that the keyword "poster" is allowed. In the absence of a 2000 Followup-To-content, the default newsgroup(s) for a followup are 2001 those in the Newsgroups-header. 2003 A Followup-To-header consisting of the keyword "poster" indicates 2004 that the poster requests no followups to be sent in response to this 2005 article, only personal replies to the article's reply address. 2006 Although the keyword "poster" is case-sensitive, followup agents MAY 2007 choose to regognize case insensitive forms such as "Poster". 2009 NOTE: A poster who wishes both a personal reply and a followup 2010 post should include an appropriate Mail-Copies-To-header (6.8). 2012 6.8. Mail-Copies-To 2014 The Mail-Copies-To-header indicates whether or not the poster wishes 2015 to have followups to an article emailed in addition to being posted 2016 to Netnews and, if so, establishes the address to which they should 2017 be sent. 2019 The content syntax makes use of syntax defined in [RFC 2822]. 2021 header =/ Mail-Copies-To-header 2022 Mail-Copies-To-header 2023 = "Mail-Copies-To" ":" SP Mail-Copies-To-content 2024 Mail-Copies-To-content 2025 = copy-addr / [CFWS] ( "nobody" / "poster" ) [CFWS] 2026 copy-addr = address-list 2028 The keyword "nobody" indicates that the poster does not wish copies 2029 of any followup postings to be emailed. This indication is widely 2030 seen as a very strong wish, and is to be taken as the default when 2031 this header is absent. 2033 The keyword "poster" indicates that the poster wishes a copy of any 2034 followup postings to be emailed to him. 2036 Otherwise, this header contains a copy-addr to which the poster 2037 wishes a copy of any followup postings to be sent. 2039 NOTE: Some existing practice uses the keyword "never" in place 2040 of "nobody" and "always" in place of "poster". These usages are 2041 deprecated, but followup agents MAY observe them. The actions 2042 to be taken by by followup agent when following up to an article 2043 containing a Mail-Copies-To header are set out in section 8.6. 2045 Whether or not this header will also find similar usage for replies 2046 to messages sent to mailing lists falls outside the scope of this 2047 standard. 2049 6.9. Posted-And-Mailed 2051 header =/ Posted-And-Mailed-header 2052 Posted-And-Mailed-header 2053 = "Posted-And-Mailed" ":" SP Posted-And-Mailed-content 2054 *( ";" extension-parameter ) 2055 Posted-And-Mailed-content 2056 = [CFWS] ( "yes" / "no" ) [CFWS] 2058 This header, when used with the "yes" keyword, indicates that the 2059 article has been both posted to the specified newsgroups and emailed. 2060 It SHOULD be used when replying to the poster of an article to which 2061 this one is a followup (see the Mail-Copies-To-header in section 6.8) 2062 and it MAY be used when any article is also mailed to a recipient(s) 2063 identified in a To- and/or Cc-header that is also present. The "no" 2064 keyword is included for the sake of completeness; it MAY be used to 2065 indicate the opposite state, but is redundant insofar as it only 2066 describes the default state when this header is absent. 2068 This header, if present, MUST be included in both the posted and 2069 emailed versions of the article. The Newsgroups-header of the posted 2070 article SHOULD be included in the email version as recommended in 2071 section 5.5. All other headers defined in this standard (excluding 2072 variant headers) MUST be identical in both the posted and emailed 2073 versions of the article. The bodies MUST be identical in both, apart 2074 from a possible change of Content-Transfer-Encoding. 2076 NOTE: This leaves open the question of whether a To- or a Cc- 2077 header should appear in the posted version. Naturally, a Bcc- 2078 header should not appear, except in a form which indicates that 2079 there are additional unspecified recipients. 2081 6.10. References 2083 The References-header is an inheritable header (see 4.2.5.2) which 2084 lists CFWS-separated message identifiers of the article's precursors, 2085 as described in 8.6. The content syntax makes use of syntax defined 2086 in [RFC 2822] (but see the revised definition of msg-id in section 2087 2.4.3). 2089 header =/ References-header 2090 References-header = "References" ":" SP References-content 2091 References-content = [CFWS] msg-id *( CFWS msg-id ) [CFWS] 2092 NOTE: This differs from the syntax of [RFC 2822] by requiring at 2093 least one CFWS between the msg-ids (a SP at this point was an 2094 [RFC 1036] requirement). 2096 A followup MUST have a References-header, and an article that is not 2097 a followup MUST NOT have a References-header. 2099 6.10.1. Examples 2101 References: 2102 References: 2103 References: 2104 <222@site1.example> <87tfbyv@site7.example> 2105 <67jimf@site666.example> 2106 References: 2107 2109 6.11. Expires 2111 The Expires-header specifies a date and time when the article is 2112 deemed to be no longer relevant and could usefully be removed 2113 ("expired"). The content syntax makes use of syntax defined in [RFC 2114 2822]. 2116 header =/ Expires-header 2117 Expires-header = "Expires" ":" SP Expires-content 2118 *( ";" extension-parameter ) 2119 Expires-content = date-time 2121 NOTE: This header is suitable for specifying both unusually 2122 short and unusually long expiry times; there is little point in 2123 using it in other circumstances. 2125 6.12. Archive 2127 This optional header provides an indication of the poster's intent 2128 regarding preservation of the article in publicly accessible long- 2129 term or permanent storage. 2131 header =/ Archive-header 2132 Archive-header = "Archive" ":" SP Archive-content 2133 *( ";" ( Archive-parameter / 2134 extension-parameter ) ) 2135 Archive-content = [CFWS] ("no" / "yes" ) [CFWS] 2136 Archive-parameter = 2139 The presence of an "Archive: no" header in an article indicates that 2140 the poster does not permit redistribution from publicly accessible 2141 long-term or permanent archives. The absence of this header, or an 2142 explicit "Archive: yes", indicates that the poster is willing for 2143 such redistribution to take place. The optional "filename" parameter 2144 can then be used to suggest a filename under which the article should 2145 be stored. Further extensions to this standard may provide additional 2146 parameters for administration of the archiving process. 2148 NOTE: This standard does not attempt to define the length of 2149 "long-term", since it is dependent on many factors, including 2150 the retention policies of individual sites, and the customs or 2151 policies established for particular newsgroups or hierarchies. 2153 NOTE: Posters are cautioned that some sites may not implement 2154 the "no" option of the Archive-header correctly. In some 2155 jurisdictions non-compliance with this header may constitute a 2156 breach of copyright or of other legal provisions. Moreover, 2157 even if this header prevents the poster's words from being 2158 archived publicly, it does nothing to prevent the archiving of a 2159 followup in which those words are quoted. 2161 6.13. Control 2163 The Control-header marks the article as a control message, and 2164 specifies the desired actions (additional to the usual ones of 2165 storing and/or relaying the article). 2167 header =/ Control-header 2168 Control-header = "Control" ":" SP Control-content 2169 *( ";" extension-parameter ) 2170 Control-content = [CFWS] control-message [CFWS] 2171 control-message = 2173 However, the rule given above for control-message is incomplete. 2174 Further alternatives will be added incrementally as the various 2175 control-messages are introduced in section 7, or in extensions to 2176 this standard, using the "=/" notation defined in [RFC 2234]. For 2177 example, a putative "Control-message" would be defined as follows: 2179 control-message =/ Control-message 2180 Control-message = "Control" Control-arguments 2181 Control-arguments = 2184 where "Control" is a "verb" which is (and MUST be) of the syntactic 2185 form of a token and Control-arguments MUST be of the syntactic form 2186 of a CFWS-separated list of values (which may require the use of 2187 quoted-strings if any tspecials or non-ASCII characters are 2188 involved). 2190 The verb indicates what action should be taken, and the argument(s) 2191 (if any) supply details. In some cases, the body of the article may 2192 also contain details. 2194 An article with a Control-header MUST NOT also have a Supersedes- 2195 header. 2197 NOTE: The presence of a Subject-header starting with the string 2198 "cmsg " and followed by a Control-message MUST NOT be construed, 2199 in the absence of a proper Control-header, as a request to 2200 perform that control action (as may have occurred in some legacy 2201 software). 2203 6.14. Approved 2205 The Approved-header indicates the mailing addresses (possibly 2206 including the full names) of the persons or entities approving the 2207 article for posting. 2209 header =/ Approved-header 2210 Approved-header = "Approved" ":" SP Approved-content 2211 *( ";" extension-parameter ) 2212 Approved-content = From-content ; see 5.2 2214 Each mailbox contained in the Approved-content MUST be that of one of 2215 the person(s) or entity(ies) in question, and one of those mailboxes 2216 MUST be that of the actual injector of the article. 2218 An Approved-header is required in all postings to moderated 2219 newsgroups. If this header is not present in such postings, then 2220 serving agents MUST (and relaying agents MAY) reject the article. 2221 Please see section 8.2.2 for how injecting agents should treat 2222 postings to moderated groups that do not contain this header. 2224 An Approved-header is also required in certain control messages, to 2225 reduce the risks of accidental or unauthorized posting of same. 2227 NOTE: The presence of an Approved-header indicates that the 2228 person or entity identified claims to have the necessary 2229 authority to post the article in question, thus enabling sites 2230 that dispute that authority to refuse to accept or to act upon 2231 it. However, the mere presence of the header is insufficient to 2232 provide assurance that it indeed originated from that person or 2233 entity, and it is therefore desirable that it be included within 2234 some digital signature scheme (see 7.1), especially in the case 2235 of control messages (section 7). 2237 6.15. Supersedes 2239 The Supersedes-header contains a message identifier specifying an 2240 article to be superseded upon the arrival of this one. The specified 2241 article MUST be treated as though a "cancel" control message had 2242 arrived for the article (but observe that a site MAY choose not to 2243 honour a "cancel" message, especially if its authenticity is in 2244 doubt). The content syntax makes use of syntax defined in [RFC 2822] 2245 (but see the revised definition of msg-id in section 2.4.3). 2247 header =/ Supersedes-header 2248 Supersedes-header = "Supersedes" ":" SP Supersedes-content 2249 Supersedes-content = [CFWS] msg-id [CFWS] 2251 NOTE: There is no "c" in "Supersedes". 2253 NOTE: The Supersedes-header defined here has no connection with 2254 the Supersedes-header that sometimes appears in Email messages 2255 converted from X.400 according to [RFC 2156]; in particular, the 2256 syntax here permits only one msg-id in contrast to the multiple 2257 msg-ids in that Email version. 2259 Thus when an article contains a Supersedes-header, the old article 2260 mentioned SHOULD be withdrawn from circulation or access, as in a 2261 cancel message (7.3), and the new article inserted into the system as 2262 any other new article would have been. 2264 Whatever security or authentication checks are normally applied to a 2265 Control cancel message (or may be prescribed for such messages by 2266 some extension to this standard - see the remarks in 7.1 and 7.3) 2267 MUST also be applied to an article with a Supersedes-header. In the 2268 event of the failure of such checks, the article SHOULD be discarded, 2269 or at most stored as an ordinary article. 2271 6.16. Xref 2273 The Xref-header is a variant header (4.2.5.3) which indicates where 2274 an article was filed by the last serving agent to process it. 2276 header =/ Xref-header 2277 Xref-header = "Xref" ":" SP Xref-content 2278 *( ";" extension-parameter ) 2279 Xref-content = [CFWS] server-name 1*( CFWS location ) [CFWS] 2280 server-name = path-identity ; see 5.6.1 2281 location = newsgroup-name ":" article-locator 2282 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 2283 ; US-ASCII printable characters 2284 ; except '(' and ';' 2286 The server-name is included so that software can determine which 2287 serving agent generated the header. The locations specify what 2288 newsgroups the article was filed under (which may differ from those 2289 in the Newsgroups-header) and where it was filed under them. The 2290 exact form of an article-locator is implementation-specific. 2292 NOTE: The traditional form of an article-locator is a decimal 2293 number, with articles in each newsgroup numbered consecutively 2294 starting from 1. NNTP demands that such a model be provided, and 2295 much other software expects it, but it seems desirable to permit 2296 flexibility for unorthodox implementations. 2298 An agent inserting an Xref-header into an article MUST delete any 2299 previous Xref-header(s). A relaying agent MAY delete it before 2300 relaying, but otherwise it SHOULD be ignored by any relaying or 2301 serving agent receiving it. 2303 It is convenient, though not required, for a serving agent to use the 2304 same server-name in Xref-headers as the path-identity it uses in 2305 Path-headers (just so long as reading agents can distinguish it from 2306 other serving agents known to them). 2308 6.17. Lines 2310 The Lines-header indicates the number of lines in the body of the 2311 article. 2313 header =/ Lines-header 2314 Lines-header = "Lines" ":" SP Lines-content 2315 *( ";" extension-parameter ) 2316 Lines-content = [CFWS] 1*DIGIT [CFWS] 2318 The line count includes all body lines, including the signature if 2319 any, including empty lines (if any) at the beginning or end of the 2320 body, and including the whole of all MIME message and multipart parts 2321 contained in the body (the single empty separator line between the 2322 headers and the body is not part of the body). The "body" here is the 2323 body as found in the posted article as transmitted by the posting 2324 agent. 2326 This header is to be regarded as obsolete, and it will likely be 2327 removed entirely in a future version of this standard. In the 2328 meantime, its use is deprecated. 2330 6.18. User-Agent 2332 The User-Agent-header contains information about the user agent 2333 (typically a newsreader) generating the article, for statistical 2334 purposes and tracing of standards violations to specific software 2335 needing correction. Although not one of the mandatory headers, 2336 posting agents SHOULD normally include it. It is also intended that 2337 this header be suitable for use in Email. 2339 header =/ User-Agent-header 2340 User-Agent-header = "User-Agent" ":" SP User-Agent-content 2341 *( ";" extension-parameter ) 2342 User-Agent-content = product *( CFWS product ) 2343 product = [CFWS] token [CFWS] [ "/" product-version ] 2344 product-version = [CFWS] token [CFWS] 2346 This header MAY contain multiple product-tokens identifying the agent 2347 and any subproducts which form a significant part of the posting 2348 agent, listed in order of their significance for identifying the 2349 application. Product-tokens should be short and to the point - they 2350 MUST NOT be used for information beyond the canonical name of the 2351 product and its version. Injecting agents MAY include product 2352 information for themselves (such as "INN/1.7.2"), but relaying and 2353 serving agents MUST NOT generate or modify this header to list 2354 themselves. 2356 NOTE: Minor variations from [RFC 2616] which describes a similar 2357 facility for the HTTP protocol: 2359 1. "{" and "}" are allowed in a token (product and product- 2360 version) in Netnews, 2362 2. Comments are permitted wherever whitespace is allowed. 2364 NOTE: This header supersedes the role performed redundantly by 2365 experimental headers such as X-Newsreader, X-Mailer, X-Posting- 2366 Agent, X-Http-User-Agent, and other headers previously used on 2367 Usenet and in Email for this purpose. Use of these experimental 2368 headers SHOULD be discontinued in favor of the single, standard 2369 User-Agent-header. 2371 6.18.1. Examples 2373 User-Agent: tin/1.3-950621beta-PL0 (Unix) 2374 User-Agent: tin/pre-1.4-971106 (UNIX) (Linux/2.0.30 (i486)) 2375 User-Agent: Mozilla/4.02b7 (X11; I; en; HP-UX B.10.20 9000/712) 2376 User-Agent: Microsoft-Internet-News/4.70.1161 2377 User-Agent: Gnus/5.4.64 XEmacs/20.3beta17 ("Bucharest") 2378 User-Agent: inn/1.7.2 2379 User-Agent: telnet 2381 6.19. Injection-Info 2383 The Injection-Info-header SHOULD be added to each article by the 2384 injecting agent in order to provide information as to how that 2385 article entered the Netnews system and to assist in tracing its true 2386 origin. 2388 header =/ Injection-Info-header 2389 Injection-Info-header 2390 = "Injection-Info" ":" SP Injection-Info-content 2391 *( ";" ( Injection-Info-parameter / 2392 extension-parameter ) ) 2393 Injection-Info-content 2394 = [CFWS] path-identity [CFWS] 2395 Injection-Info-parameter 2396 = posting-host-parameter / 2397 posting-account-parameter / 2398 posting-sender-parameter / 2399 posting-logging-parameter 2400 ; for {USENET}-parameters see 4.1 2401 posting-host-parameter 2402 = 2404 host-value = dot-atom / 2405 [ dot-atom ":" ] 2406 ( IPv4address / IPv6address ); see [RFC 2373] 2407 posting-account-parameter 2408 = 2410 posting-sender-parameter 2411 = 2413 sender-value = mailbox / "verified" 2414 posting-logging-parameter 2415 = 2418 An Injection-Info-header MUST NOT be added to an article except by an 2419 injecting agent. Any Injection-Info-header present when an article 2420 arrives at an injecting agent MUST be removed. In particular if, for 2421 some exceptional reason, an article is being reinjected (8.2.2), the 2422 Injection-Info-header will always relate to the latest injection (to 2423 the extent that this happens, the Injection-Info-header can be 2424 regarded as a variant header). 2426 The path-identity MUST be the same as the path-identity prepended to 2427 the Path-header by that same injecting agent which, following section 2428 5.6.2, MUST therefore be a fully qualified domain name (FQDN) 2429 mailable address. 2431 Although comments and folding of white space are permitted throughout 2432 the Injection-Info-content specification, it is RECOMMENDED that 2433 folding is not used within any parameter (but only before or after 2434 the ";" separating those parameters), and that comments are only used 2435 following the last parameter. It is also RECOMMENDED that such 2436 parameters as are present are included in the order in which they 2437 have been defined in the syntax above. An injecting agent SHOULD use 2438 a consistent form of this header for all articles emanating from the 2439 same or similar origins. 2441 NOTE: The effect of those recommendations is to facilitate the 2442 recognition of articles arising from certain designated origins 2443 (as in the so-called "killfiles" which are available in some 2444 reading agents). Observe that the order within the syntax has 2445 been chosen to place last those parameters which are most likely 2446 to change between successive articles posted from the same 2447 origin. 2449 NOTE: To comply with the overall "attribute = value" syntax of 2450 parameters, any value containing an IPv6address, a date-time, a 2451 mailbox, or any CFWS MUST be quoted using s (the quoting 2452 is optional in other cases). 2454 NOTE: This header is intended to replace various currently-used 2455 but nowhere-documented headers such as "NNTP-Posting-Host" and 2456 "X-Trace". These headers are now deprecated, and any of them 2457 present when an article arrives at an injecting agent SHOULD 2458 also be removed as above. 2460 6.19.1. Usage of Injection-Info-parameters 2462 The purpose of these parameters is to enable the injecting agent to 2463 make assertions about the origin of the article, in fulfilment of its 2464 responsibilities towards the rest of the network as set out in 2465 section 8.2. 2467 An injecting agent MUST NOT include any Injection-Info-parameter 2468 unless it has positive evidence of its correctness. An injecting 2469 agent MAY also include further extension-parameters with x-attributes 2470 which will assist in identifying the origin of the article. 2472 6.19.1.1. The posting-host-parameter 2474 If a dot-atom is present, it MUST be a FQDN identifying the specific 2475 host from which the injecting agent received the article. 2476 Alternatively, an IP address (IPv4address or IPv6address) identifies 2477 that host. If both forms are present, then they MUST identify the 2478 same host, or at least have done so at the time the article was 2479 injected. 2481 NOTE: It is commonly the case that this parameter identifies a 2482 dial-up point-of-presence, in which case a posting-account or 2483 logging-data may need to be consulted to find the true origin of 2484 the article. 2486 6.19.1.2. The posting-account-parameter 2488 This parameter identifies the source from which the injecting agent 2489 received the article. It SHOULD be in a cryptic notation 2490 understandable only by the administrator of the injecting agent, but 2491 it MUST be such that a given source gives rise to the same posting- 2492 account, at least in the short term. If the injecting agent is unable 2493 to meet that obligation, then it should use a posting-logging- 2494 parameter instead. 2496 6.19.1.3. The posting-sender-parameter 2498 This parameter identifies the mailbox of the verified sender of the 2499 article (alternatively, it uses the token "verified" to indicate that 2500 at least any addr-spec in the Sender-header of the article, or in the 2501 From-header if the Sender-header is absent, is correct). 2503 NOTE: An injecting agent is unlikely to be able to make use of 2504 this parameter except in cases where it is running on a machine 2505 which is aware of the user-space in which the posting agent is 2506 operating. This parameter should be used in preference to a 2507 posting-account-parameter in such situations. 2509 6.19.1.4. The posting-logging-parameter 2511 This parameter contains information (typically a session number or 2512 other non-persistent means of identifying a posting account) which 2513 will enable the true origin of the article to be determined by 2514 reference to logging information kept by the injecting agent. 2516 6.19.2. Example 2518 Injection-Info: news2.isp.net; posting-host=modem-15.pop.isp.net; 2519 posting-account=client0002623; logging-data=2427" 2521 6.20. Complaints-To 2523 The Complaints-To-header is added to an article by an injecting agent 2524 in order to indicate the mailbox to which complaints concerning the 2525 poster of the article may be sent. The content syntax makes use of 2526 syntax defined in [RFC 2822]. 2528 header =/ Complaints-To-header 2529 Complaints-To-header 2530 = "Complaints-To" ":" SP Complaints-To-content 2531 Complaints-To-content 2532 = address-list 2534 A Complaints-To-header MUST NOT be added to an article except by an 2535 injecting agent. Any Complaints-To-header present when an article 2536 arrives at an injecting agent MUST be removed. In particular if, for 2537 some exceptional reason an article is being reinjected (8.2.2), the 2538 Complaints-To-header will always relate to the latest injection (to 2539 the extent that this happens, the Complaints-To-header can be 2540 regarded as a variant header). 2542 The specified mailbox is for sending complaints concerning the 2543 behaviour of the poster of the article; it SHOULD NOT be used for 2544 matters concerning propagation, protocol problems, etc. which should 2545 be addressed to "usenet@" or "news@" the path-identity which was 2546 prepended to the Path-header by the injecting agent, in accordance 2547 with section 5.6.2. In the absence of this header, complaints 2548 concerning a poster's behaviour MAY be addressed to "abuse@" that 2549 path-identity (although section 5.6.2 provides no obligation for that 2550 address to be mailable at an injecting agent that is not provided for 2551 the use of the general public). 2553 6.21. MIME headers 2555 6.21.1. Syntax 2557 The following headers may be used within articles conforming to this 2558 standard. 2560 MIME-Version: [RFC 2045] 2561 Content-Type: [RFC 2045],[RFC 2046] 2562 Content-Transfer-Encoding: [RFC 2045] 2563 Content-ID: [RFC 2045] 2564 Content-Description: [RFC 2045] 2565 Content-Disposition: [RFC 2183] 2566 Content-Location: [RFC 2557] 2567 Content-Language: [RFC 3282] 2568 Content-MD5: [RFC 1864] 2570 The RFCs listed are deemed to be incorporated into this standard to 2571 the extent necessary to facilitate their usage within Netnews, 2572 subject to curtailment of that usage as described in the following 2573 sections. Moreover, extensions to those standards registered in 2574 accordance with [RFC 2048] are also available for use within Netnews, 2575 as indeed is any other header in the Content-* series which has a 2576 sensible interpretation within Netnews. 2578 Insofar as the syntax for these headers, as given in those RFCs does 2579 not specify precisely where whitespace and comments may occur 2580 (whether in the form of WSP, FWS or CFWS), the usage defined in this 2581 standard, and failing that in [RFC 2822], and failing that in [RFC 2582 822] MUST be followed. In particular, there MUST NOT be any WSP 2583 between a header-name and the following colon and there MUST be a SP 2584 following that colon. 2586 6.21.2. Content-Type 2588 If the contents of an article is something other than plain text in 2589 the US-ASCII charset (these being the default assumptions), an 2590 appropriate Content-Type-header MUST be included. 2592 Reading agents SHOULD NOT, unless explicitly configured otherwise, 2593 act automatically on Application types which could change the state 2594 of that agent (e.g. by writing or modifying files), except in the 2595 case of those prescribed for use in control messages (7.2.1.2 and 2596 7.2.4.1). 2598 The Content-Type "message/partial" MAY be used to split a long news 2599 article into several smaller ones. However, breaking long texts into 2600 several parts is usually unnecessary, since modern transport agents 2601 should have no difficulty in handling articles of arbitrary length, 2602 although it may be useful to break long binaries. 2604 IF the Content-Type "message/partial" is used, then the "id" 2605 parameter SHOULD be in the form of a unique message identifier (but 2606 different from that in the Message-ID-header of any of the parts). 2607 The second and subsequent parts SHOULD contain References-headers 2608 referring to all the previous parts, thus enabling reading agents 2609 with threading capabilities to present them in the correct order. 2610 Reading agents MAY then provide a facility to recombine the parts 2611 into a single article (but this standard does not require them to do 2612 so). 2614 The Content-Type "message/rfc822" should be used for the 2615 encapsulation (whether as part of another news article or, more 2616 usually, as part of an email message) of complete news articles which 2617 have already been posted to Netnews and which are for the information 2618 of the recipient, and do not constitute a request to repost them 2619 (refer to 6.21.4.2 for the now obsolete "message/news" formerly 2620 intended for this purpose). 2622 6.21.3. Content-Transfer-Encoding 2624 "Content-Transfer-Encoding: 7bit" is sufficient for article bodies 2625 (or parts of multiparts) written in pure US-ASCII (or most other 2626 material representable in 7 bits). Posting agents SHOULD specify 2627 "Content-Transfer-Encoding: 8bit" for all other cases except where 2628 the content is (or might be) "8bit-unsafe", or where some protocol 2629 explicitly disallows it. They MAY use "8bit" encoding even when 2630 "7bit" encoding would have sufficed. 2632 Content is "8bit-unsafe" if it contains octets equivalent to the US- 2633 ASCII characters CR or LF (other than in the combination CRLF) or 2634 NUL. This is often the case with application types (though in many 2635 cases application types are intended to be human readable, in which 2636 case they will usually be 8bit-safe). It also arises with certain 2637 charsets (as indicated in the Content-Type-header), particularly in 2638 the case of 16-bit charsets such as UTF-16 ([UNICODE 3.2] or [ISO/IEC 2639 10646]). 2641 Examples of protocols REQUIRING particular Content-Transfer-Encodings 2642 include the Content-Type "application/pgp-signature" [RFC 3156], and 2643 the Content-Type "message/partial" which itself MUST use "Content- 2644 Transfer-Encoding: 7bit" (though the encapsulated complete message 2645 may itself use encoding "quoted-printable" or "base64", but that 2646 information is only conveyed along with the first of the partial 2647 parts). 2649 Encoding "binary" MUST NOT be used (except in cooperating subnets 2650 with alternative transport arrangements) because this standard does 2651 not mandate a transport mechanism that could support it. 2653 Injecting and relaying agents MUST NOT change the encoding of 2654 articles passed to them. Gateways SHOULD NOT change the encoding 2655 unless absolutely necessary. 2657 6.21.4. Definition of some new Content-Types 2659 This standard defines (or redefines) several new Content-Types, which 2660 require to be registered with IANA as provided for in [RFC 2048]. 2661 For "application/news-groupinfo" see 7.2.1.2, for "application/news- 2662 checkgroups" see 7.2.4.1, and for "application/news-transmission" see 2663 the following section. 2665 6.21.4.1. Application/news-transmission 2667 The Content-Type "application/news-transmission" is intended for the 2668 encapsulation of complete news articles where the intention is that 2669 the recipient should then inject them into Netnews. This Application 2670 type provides one of the methods for mailing articles to moderators 2671 (see 8.2.2) and it is also the preferred method when sending to an 2672 email-to-news gateway (see 8.8.2). 2674 NOTE: The benefit of such encapsulation is that it removes 2675 possible conflict between news and email headers and it provides 2676 a convenient way of "tunnelling" a news article through a 2677 transport medium that does not support 8bit characters. 2679 The MIME content type definition of "application/news-transmission" 2680 is: 2682 MIME type name: application 2683 MIME subtype name: news-transmission 2684 Required parameters: none 2685 Optional parameters: usage=moderate 2686 usage=inject 2687 usage=relay 2688 Encoding considerations: A transfer-encoding (such as Quoted- 2689 Printable or Base64) different from that of 2690 the article transmitted MAY be supplied 2691 (perhaps en route) to ensure correct 2692 transmission over some 7bit transport 2693 medium. 2694 Security considerations: A news article may be a "control message", 2695 which could have effects on the recipient 2696 host's system beyond just storage of the 2697 article. However, such control messages 2698 also occur in normal news flow, so most 2699 hosts will already be suitably defended 2700 against undesired effects. 2701 Published specification: [USEFOR] 2702 Body part: A complete article or proto-article, ready 2703 for injection into Netnews, or a batch of 2704 such articles. 2706 NOTE: It is likely that the recipient of an "application/news- 2707 transmission" will be a specialized gateway (e.g. a moderator's 2708 submission address) able to accept articles with only one of the 2709 three usage parameters "moderate", "inject" and "relay", hence 2710 the reason why they are optional, being redundant in most 2711 situations. Nevertheless, they MAY be used to signify the 2712 originator's intention with regard to the transmission, so 2713 removing any possible doubt. 2715 When the parameter "relay" is used, or implied, the body part MAY be 2716 a batch of articles to be transmitted together, in which case the 2717 following syntax MUST be used. 2719 batch = 1*( batch-header article ) 2720 batch-header = "#!" SP rnews SP article-size CRLF 2721 rnews = %x72.6E.65.77.73 ; case sensitive "rnews" 2722 article-size = 1*DIGIT 2724 Thus a batch is a sequence of articles, each prefixed by a header 2725 line that includes its size. The article-size is a decimal count of 2726 the octets in the article, counting each CRLF as one octet regardless 2727 of how it is actually represented. 2729 NOTE: Despite the similarity of this format to an executable 2730 UNIX script, it is EXTREMELY unwise to feed such a batch into a 2731 command interpreter in anticipation of it running a command 2732 named "rnews"; the security implications of so doing would be 2733 disastrous. 2735 6.21.4.2. Message/news obsoleted 2737 The Content-Type "message/news", as previously registered with IANA, 2738 is hereby declared obsolete. It was never widely implemented, and its 2739 default treatment as "application/octet-stream" by agents that did 2740 not recognize it was counter productive. The Content-Type 2741 "message/rfc822" SHOULD be used in its place, as already described 2742 above. 2744 6.22. Obsolete Headers 2746 Persons writing new agents SHOULD ignore any former meanings of the 2747 following headers: 2749 Also-Control 2750 See-Also 2751 Article-Names 2752 Article-Updates 2754 7. Control Messages 2756 The following sections document the control messages. "Message" is 2757 used herein as a synonym for "article" unless context indicates 2758 otherwise. 2760 The Newsgroups-header of each control message SHOULD include the 2761 newsgroup-name(s) for the group(s) affected (i.e. groups to be 2762 created, modified or removed, or containing articles to be canceled). 2763 This is to ensure that the message propagates to all sites which 2764 receive (or would receive) that group(s). It MAY include other 2765 newsgroup-names so as to improve propagation (but this practice may 2766 cause the control message to propagate also to places where it is 2767 unwanted, or even cause it not to propagate where it should, so it 2768 should not be used without good reason). 2770 The descriptions below set out REQUIREMENTS to be followed by sites 2771 that receive control messages and choose to honour them. However, 2772 nothing in these descriptions should be taken as overriding the right 2773 of any such site, in accordance with its local policy, to deny any 2774 particular control message, or to refer it to an administrator for 2775 approval (either as a class or on a case-by-case basis). 2777 Relaying Agents MUST propagate all control messages regardless of 2778 whether or not they are recognized or processed locally. 2780 In the following sections, each type of control message is defined 2781 syntactically by defining its verb, its arguments, and possibly its 2782 body. 2784 7.1. Digital Signature of Headers 2786 It is most desirable that group control messages (7.2) in particular 2787 be authenticated by incorporating them within some digital signature 2788 scheme that encompasses other headers closely associated with them 2789 (including at least the Approved-, Message-ID- and Date-headers). At 2790 the time of writing, this is usually done by means of a protocol 2791 known as "PGPverify" ([PGPVERIFY]), and continued usage of this is 2792 encouraged at least as an interim measure. 2794 However, PGPverify is not considered suitable for standardization in 2795 its present form, for various technical reasons. It is therefore 2796 expected that an early extension to this standard will provide a 2797 robust and general purpose digital authentication mechanism with 2798 applicability to all situations requiring protection against 2799 malicious use of, or interference with, headers. That extension 2800 would also address other Netnews security issues. 2802 7.2. Group Control Messages 2804 "Group control messages" are the sub-class of control messages that 2805 request some update to the configuration of the groups known to a 2806 serving agent, namely "newgroup". "rmgroup", "mvgroup" and 2807 "checkgroups", plus any others created by extensions to this 2808 standard. 2810 All of the group control messages MUST have an Approved-header 2811 (6.14) which, in those hierarchies where appropriate administrative 2812 agencies exist (see 1.1), identifies the appropriate person or entity 2813 as authorized by those agencies. The authorized person or entity 2814 SHOULD adhere to the conventions and restrictions on the format of 2815 newsgroup-names established for those hierarchies (see 5.5). 2817 7.2.1. The 'newgroup' Control Message 2819 control-message =/ Newgroup-message 2820 Newgroup-message = "newgroup" Newgroup-arguments 2821 Newgroup-arguments = CFWS newsgroup-name [ CFWS newgroup-flag ] 2822 newgroup-flag = "moderated" 2824 The "newgroup" control message requests that the specified group be 2825 created or changed. If the request is honoured, or if the group 2826 already exists on the serving agent, and if the newgroup-flag 2827 "moderated" is present, then the group MUST be marked as moderated, 2828 and vice versa. "Moderated" is the only such flag defined by this 2829 standard; other flags MAY be defined for use in cooperating subnets, 2830 but newgroup messages containing them MUST NOT be acted on outside of 2831 those subnets. 2833 NOTE: Specifically, some alternative flags such as "y" and "m", 2834 which are sent and recognized by some current software, are NOT 2835 part of this standard. Moreover, some existing implementations 2836 treat any flag other than "moderated" as indicating an 2837 unmoderated newsgroup. Both of these usages are contrary to this 2838 standard and control messages with such non-standard flags 2839 should be ignored. 2841 The message body comprises or includes an "application/news- 2842 groupinfo" (7.2.1.2) part containing machine- and human-readable 2843 information about the group. 2845 The newgroup command is also used to update the newsgroups-line or 2846 the moderation status of a group. 2848 7.2.1.1. The Body of the 'newgroup' Control Message 2850 The body of the newgroup message contains the following subparts, 2851 preferably in the order shown: 2853 1. An "application/news-groupinfo" part (7.2.1.2) containing the name 2854 and newsgroups-line of the group(s). This part MUST be present. 2856 2. Other parts containing useful information about the background of 2857 the newgroup message (typically of type "text/plain"). 2859 3. Parts containing initial articles for the newsgroup. See section 2860 7.2.1.3 for details. 2862 In the event that there is only the single (i.e. application/news- 2863 groupinfo) subpart present, it will suffice to include a "Content- 2864 Type: application/news-groupinfo" amongst the headers of the control 2865 message. Otherwise, a "Content-Type: multipart/mixed" header will be 2866 needed, and each separate part will then need its own Content-Type- 2867 header. 2869 7.2.1.2. Application/news-groupinfo 2871 The "application/news-groupinfo" body part contains brief information 2872 about a newsgroup, i.e. the group's name, it's newsgroup-description 2873 and the moderation-flag. 2875 NOTE: The presence of the newsgroups-tag "For your newsgroups 2876 file:" is intended to make the whole newgroup message compatible 2877 with current practice as described in [Son-of-1036]. 2879 The MIME content type definition of "application/news-groupinfo" is: 2881 MIME type name: application 2882 MIME subtype name: news-groupinfo 2883 Required parameters: none 2884 Disposition: by default, inline 2885 Encoding considerations: "7bit" or "8bit" is sufficient and MUST be 2886 used to maintain compatibility. 2887 Security considerations: this type MUST NOT be used except as part 2888 of a control message for the creation or 2889 modification of a Netnews newsgroup 2890 Published specification: [USEFOR] 2892 The content of the "application/news-groupinfo" body part is defined 2893 as: 2895 groupinfo-body = [ newsgroups-tag CRLF ] 2896 newsgroups-line CRLF 2897 newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP 2898 %x6E.65.77.73.67.72.6F.75.70.73 SP 2899 %x66.69.6C.65.3A 2900 ; case sensitive 2901 ; "For your newsgroups file:" 2902 newsgroups-line = newsgroup-name 2903 [ 1*HTAB newsgroup-description ] 2904 [ 1*WSP moderation-flag ] 2905 newsgroup-description 2906 = utext *( *WSP utext ) 2907 moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29 2908 ; case sensitive "(Moderated)" 2910 The newsgroup-description MUST NOT contain any occurrence of the 2911 string "(Moderated)" within it. 2913 The "application/news-groupinfo" is used in conjunction with the 2914 "newgroup" (7.2.1) and "mvgroup" (7.2.3) control messages. The 2915 newsgroup-name in the newsgroups-line MUST agree with the newsgroup- 2916 name in the "newgroup" or "mvgroup" control message. The Content- 2917 Type "application/news-groupinfo" MUST NOT be used except as a part 2918 of such control messages. Although optional, the newsgroups-tag 2919 SHOULD be included until such time as this standard has been widely 2920 adopted, to ensure compatibility with present practice. 2922 Moderated newsgroups MUST be marked by appending the case sensitive 2923 text " (Moderated)" at the end. It is NOT recommended that the 2924 moderator's email address be included in the newsgroup-description as 2925 has sometimes been done. 2927 NOTE: There is no provision for the use of charsets other than 2928 US-ASCII within a newsgroup-description. Such a facility may be 2929 provided in a future extension to this standard. 2930 [That may seem harsh, but if we make any such provision now, it will 2931 make life more complicated and restrict our freedom when it comes to the 2932 proposed I18N extension. Therefore I resisted the temptation to include 2933 any charset parameter with this Content-Type. Note that this also 2934 applies to the checkgroups message further on.] 2936 7.2.1.3. Initial Articles 2938 Some subparts of a "newgroup" or "mvgroup" control message MAY 2939 contain an initial set of articles to be posted to the affected 2940 newsgroup(s) as soon as it has been created or modified. These parts 2941 are identified by having the Content-Type "application/news- 2942 transmission", possibly with the parameter "usage=inject". The body 2943 of each such part should be a complete proto-article, ready for 2944 posting. This feature is intended for the posting of charters, 2945 initial FAQs and the like to the newly formed group(s). 2947 The Newsgroups-header of the proto-article MUST include the 2948 newsgroup-name of the newly created or modified group. It MAY include 2949 other newsgroup-names. If the proto-article includes a Message-ID- 2950 header, the message identifier in it MUST be different from that of 2951 any existing article and from that of the control message as a whole. 2952 Alternatively such a message identifier MAY be derived by the 2953 injecting agent when the proto-article is posted. The proto-article 2954 SHOULD include the header "Distribution: local". 2956 The proto-article SHOULD be injected at the serving agent that 2957 processes the control message AFTER the newsgroup in question has 2958 been created or modified. It MUST NOT be injected if the newsgroup 2959 is not, in fact, created (for whatever reason). It MUST NOT be 2960 submitted to any relaying agent for transmission beyond the serving 2961 agent(s) upon which the newsgroup creation has just been effected (in 2962 other words, it is to be treated as having a "Distribution: local" 2963 header, whether such a header is actually present or not). 2965 NOTE: It is not precluded that the proto-article is itself a 2966 control message or other type of special article, to be 2967 activated only upon creation of the new newsgroup. However, 2968 except as might arise from that possibility, any 2969 "application/news-transmission" within some nested "multipart/*" 2970 structure within the proto-article is not to be activated. 2972 7.2.1.4. Example 2974 A "newgroup" with its charter: 2976 From: "example.all Administrator" 2977 Newsgroups: example.admin.info,example.admin.announce 2978 Date: 27 Feb 2002 12:50:22 +0200 2979 Subject: cmsg newgroup example.admin.info moderated 2980 Approved: admin@noc.example 2981 Control: newgroup example.admin.info moderated 2982 Message-ID: 2983 MIME-Version: 1.0 2984 Content-Type: multipart/mixed; boundary="nxtprt" 2985 Content-Transfer-Encoding: 8bit 2987 This is a MIME control message. 2988 --nxtprt 2989 Content-Type: application/news-groupinfo 2991 For your newsgroups file: 2992 example.admin.info About the example.* groups (Moderated) 2994 --nxtprt 2995 Content-Type: application/news-transmission 2997 Newsgroups: example.admin.info 2998 From: "example.all Administrator" 2999 Subject: Charter for example.admin.info 3000 Message-ID: 3001 Distribution: local 3002 Content-Type: text/plain; charset=us-ascii 3003 Content-Transfer-Encoding: 7bit 3005 The group example.admin.info contains regularly posted 3006 information on the example.* hierarchy. 3008 --nxtprt-- 3010 7.2.2. The 'rmgroup' Control Message 3012 control-message =/ Rmgroup-message 3013 Rmgroup-message = "rmgroup" Rmgroup-arguments 3014 Rmgroup-arguments = CFWS newsgroup-name 3016 The "rmgroup" control message requests that the specified group be 3017 removed from the list of valid groups. The Content-Type of the body 3018 is unspecified; it MAY contain anything, usually an explanatory text. 3020 NOTE: It is entirely proper for a serving agent to retain the 3021 group until all the articles in it have expired, provided that 3022 it ceases to accept new articles. 3024 7.2.2.1. Example 3026 From: "example.all Administrator" 3027 Newsgroups: example.admin.obsolete, example.admin.announce 3028 Date: 4 Apr 2002 22:04 -0900 (PST) 3029 Subject: cmsg rmgroup example.admin.obsolete 3030 Message-ID: 3031 Approved: admin@noc.example 3032 Control: rmgroup example.admin.obsolete 3034 The group example.admin.obsolete is obsolete. Please remove it 3035 from your system. 3037 7.2.3. The 'mvgroup' Control Message 3039 control-message =/ Mvgroup-message 3040 Mvgroup-message = "mvgroup" Mvgroup-arguments 3041 Mvgroup-arguments = CFWS newsgroup-name CFWS newsgroup-name 3042 [ CFWS newgroup-flag ] 3044 The "mvgroup" control message requests that the group specified by 3045 the first (old-)newsgroup-name be moved to that specified by the 3046 second (new-)newsgroup-name. Thus it is broadly equivalent to a 3047 "newgroup" control message for the second group followed by a 3048 "rmgroup" control message for the first group. 3050 The message body contains an "application/news-groupinfo" part 3051 (7.2.1.2) containing machine- and human-readable information about 3052 the new group, and possibly other subparts as for a "newgroup" 3053 control message. The information conveyed in the "application/news- 3054 groupinfo" body part, notably its newsgroups-line (7.2.1.2), is 3055 applied to the new group. 3057 When this message is received, the new group is created (if it does 3058 not exist already) as for a "newgroup" control message, and MUST in 3059 any case be made moderated if a newgroup-flag "moderated" is present, 3060 and vice versa. At the same time, arrangements SHOULD be made to 3061 remove the old group (as with a "rmgroup" control message), but only 3062 after a suitable overlap period to allow the network to adjust to the 3063 new arrangement. 3065 At the same time as a serving agent acts upon this message, all 3066 injecting agents associated with that serving agent SHOULD inhibit 3067 the posting of new articles to the old group (preferably with some 3068 indication to the poster that the new group should have been used). 3069 Relaying agents, however, MUST continue to propagate such articles 3070 during the overlap period. 3072 NOTE: It is to be expected that different serving agents will 3073 act on this message at different points of time, users of the 3074 old group will have to become accustomed to the new arrangement, 3075 and followups to already established threads will likely 3076 continue under the old group. Therefore, there needs to be an 3077 overlap period during which articles may continue to be accepted 3078 by relaying and serving agents in either group. This standard 3079 does not specify any standard period of overlap (though it would 3080 be expected to be expressed in days rather than in months). The 3081 inhibition of injection of new articles to the old group may 3082 seem draconian, but it is the surest way to prevent the 3083 changeover from dragging on indefinitely. 3085 Since the "mvgroup" control message is newly introduced in this 3086 standard and may not be widely implemented initially, it SHOULD be 3087 followed shortly afterwards by a corresponding "newgroup" control 3088 message; and again, after a reasonable overlap period, it MUST be 3089 followed by a "rmgroup" control message for the old group. 3091 In order to facilitate a smooth changeover, serving agents MAY 3092 arrange to service requests for access to the old group by providing 3093 access to the new group, which would then contain, or appear to 3094 contain, all articles posted to either group (including, ideally, the 3095 pre-changeover articles from the old one). Nevertheless, if this 3096 feature is implemented, the articles themselves, as supplied to 3097 reading agents, MUST NOT be altered in any way (and, in particular, 3098 their Newsgroups-headers MUST contain exactly those newsgroups 3099 present when they were injected). On the other hand, the Xref-header 3100 MAY contain entries for either group (or even both). 3102 NOTE: Some serving agents that use an "active" file permit an 3103 entry of the form "oldgroup xxx yyy =newgroup", which enables 3104 any articles arriving for oldgroup to be diverted to newgroup, 3105 thus providing a simple implementation of this feature. However, 3106 it is known that not all current serving agents will find 3107 implementation so easy (especially in the short term) which is 3108 why it is not mandated by this standard. Nevertheless, its 3109 eventual implementation in all serving agents is to be 3110 considered highly desirable. 3112 On the other hand, it is recognized that this feature would 3113 likely not be implementable if the new group was already in 3114 existence with existing articles in it. This situation should 3115 not normally arise except when there is already some confusion 3116 as to which groups are, or are not, supposed to exist in that 3117 hierarchy. Note that the "mvgroup" control message is not really 3118 intended to be used for merging two existing groups. 3120 7.2.3.1. Example 3122 From: "example.all Administrator" 3123 Newsgroups: example.oldgroup,example.newgroup,example.admin.announce 3124 Date: 30 Apr 2002 22:04 -0500 (EST) 3125 Subject: cmsg mvgroup example.oldgroup example.newgroup moderated 3126 Message-ID: 3127 Approved: admin@noc.example 3128 Control: mvgroup example.oldgroup example.newgroup moderated 3129 MIME-Version: 1.0 3130 Content-Type: multipart/mixed; boundary=nxt 3132 --nxt 3133 Content-Type: application/news-groupinfo 3135 For your newsgroups file: 3136 example.newgroup The new replacement group (Moderated) 3138 --nxt 3140 The moderated group example.oldgroup is replaced by 3141 example.newgroup. Please update your configuration, and please, 3142 if possible, arrange to file articles arriving for 3143 example.oldgroup as if they were in example.newgroup. 3145 --nxt 3146 Content-Type: application/news-transmission 3148 Newsgroups: example.admin.info 3149 From: "example.all Administrator" 3150 Subject: Charter for example.newgroup 3151 Message-ID: 3152 Distribution: local 3153 Content-Type: text/plain; charset=us-ascii 3154 Content-Transfer-Encoding: 7bit 3156 This group (formerly known as example.oldgroup) is for the 3157 discussion of examples. 3159 --nxt-- 3161 7.2.4. The 'checkgroups' Control Message 3163 The "checkgroups" control message contains a list of all the valid 3164 groups in a complete hierarchy. 3166 control-message =/ Checkgroup-message 3167 Checkgroup-message = "checkgroups" Checkgroup-arguments 3168 Checkgroup-arguments= [ chkscope ] [ chksernr ] 3169 chkscope = 1*( CFWS ["!"] newsgroup-name ) 3170 chksernr = CFWS "#" 1*DIGIT 3172 A "checkgroups" message applies to any (sub-)hierarchy with a prefix 3173 listed in the chkscope parameter, provided that the rightmost 3174 matching newsgroup-name in the list is not immediately preceded by a 3175 "!". If no chkscope parameter is given, it applies to all 3176 hierarchies for which group statements appear in the message. 3178 NOTE: Some existing software does not support the "chkscope" 3179 parameter. Thus a "checkgroups" message SHOULD also contain the 3180 groups of other subhierarchies the sender is not responsible 3181 for. "New" software MUST ignore groups which do not fall within 3182 the chkscope parameter of the "checkgroups" message. 3184 The chksernr parameter is a serial number, which can be any positive 3185 integer (e.g. just numbered or the date in YYYYMMDD). It SHOULD 3186 increase by an arbitrary value with every change to the group list 3187 and MUST NOT ever decrease. 3189 NOTE: This was added to circumvent security problems in 3190 situations where the Date-header cannot be authenticated. 3192 Example: 3194 Control: checkgroups de !de.alt #248 3196 which includes the whole of the 'de.*' hierarchy, with the exception 3197 of its 'de.alt.*' sub-hierarchy. 3199 The body of the message has the Content-Type "application/news- 3200 checkgroups". It asserts that the newsgroups it lists are the only 3201 newsgroups in the specified hierarchies. 3203 NOTE: The checkgroups message is intended to synchronize the 3204 list of newsgroups stored by a serving agent, and their 3205 newsgroup-descriptions, with the lists stored by other serving 3206 agents throughout the network. However, it might be inadvisable 3207 for the serving agent actually to create or delete any 3208 newsgroups without first obtaining the approval of its 3209 administrators for such proposed actions. 3211 7.2.4.1. Application/news-checkgroups 3213 The "application/news-checkgroups" body part contains a complete list 3214 of all the newsgroups in a hierarchy, their newsgroup-descriptions 3215 and their moderation status. 3217 The MIME content type definition of "application/news-checkgroups" 3218 is: 3220 MIME type name: application 3221 MIME subtype name: news-checkgroups 3222 Required parameters: none 3223 Disposition: by default, inline 3224 Encoding considerations: "7bit" or "8bit" is sufficient and MUST be 3225 used to maintain compatibility. 3226 Security considerations: this type MUST NOT be used except as part 3227 of a checkgroups control message 3229 The content of the "application/news-checkgroups" body part is 3230 defined as: 3232 checkgroups-body = *( valid-group CRLF ) 3233 valid-group = newsgroups-line ; see 7.2.1.2 3235 The "application/news-checkgroups" content type is used in 3236 conjunction with the "checkgroups" control message (7.2.4). 3238 NOTE: The possibility of removing a complete hierarchy by means 3239 of an "invalidation" line beginning with a '!' is no longer 3240 provided by this standard. The intent of the feature was widely 3241 misunderstood and it was misused more often than it was used 3242 correctly. The same effect, if required, can now be obtained by 3243 the use of an appropriate chkscope argument in conjunction with 3244 an empty checkgroups-body. 3246 7.3. Cancel 3248 The cancel message requests that a target article be "canceled" i.e. 3249 be withdrawn from circulation or access. 3251 control-message =/ Cancel-message 3252 Cancel-message = "cancel" Cancel-arguments 3253 Cancel-arguments = CFWS msg-id [CFWS] 3255 The argument identifies the article to be cancelled by its message 3256 identifier. The body SHOULD contain an indication of why the 3257 cancellation was requested. The cancel message SHOULD be posted to 3258 the same newsgroup, with the same distribution, as the article it is 3259 attempting to cancel. 3261 A serving agent that elects to honour a cancel message SHOULD make 3262 the article unavailable for relaying or serving (perhaps by deleting 3263 it completely). If the target article is unavailable, and the 3264 acceptability of the cancel message cannot be established without it, 3265 activation of the cancel message SHOULD be delayed until the target 3266 article has been seen. See also sections 8.3 and 8.4. 3268 NOTE: It is expected that the security extension envisaged in 3269 section 7.1 will make more detailed provisions for establishing 3270 whether honouring a particular cancel message is in order. In 3271 particular, it is likely that there will be provision for the 3272 digital signature of 3rd party cancels (i.e. those issued other 3273 than by the sender, the moderator, or the injector). 3275 NOTE: A cancel submitted by the poster for an article in a 3276 moderated group will be forwarded to the moderator of that 3277 group, and it is up to that moderator to act upon it (8.7). 3279 NOTE: The former requirement [RFC 1036] that the From and/or 3280 Sender-headers of the cancel message should match those of the 3281 original article has been removed from this standard, since it 3282 only encouraged cancel issuers to conceal their true identity, 3283 and it was not usually checked or enforced by canceling 3284 software. Therefore, both the From and/or Sender-headers and 3285 any Approved-header should now relate to the entity responsible 3286 for issuing the cancel message. 3288 7.4. Ihave, sendme 3290 The "ihave" and "sendme" control messages implement a crude batched 3291 predecessor of the NNTP [NNTP] protocol. They are largely obsolete on 3292 the Internet, but still see use in conjunction with some transport 3293 protocols such as UUCP, especially for backup feeds that normally are 3294 active only when a primary feed path has failed. There is no 3295 requirement for relaying agents that do not support such transport 3296 protocols to implement them. 3298 NOTE: The ihave and sendme messages defined here have ABSOLUTELY 3299 NOTHING TO DO WITH NNTP, despite similarities of terminology. 3301 The two messages share the same syntax: 3303 control-message =/ Ihave-message 3304 Ihave-message = "ihave" Ihave-arguments 3305 Ihave-arguments = relayer-name 3306 control-message =/ Sendme-message 3307 Sendme-message = "sendme" Sendme-arguments 3308 Sendme-arguments = Ihave-arguments 3309 relayer-name = path-identity ; see 5.6.1 3310 ihave-body = *( msg-id CRLF ) 3311 sendme-body = ihave-body 3313 The body of the message consists of a list of msg-ids, one per line. 3314 [RFC 1036] also permitted the list of msg-ids to appear in the Ihave- 3315 or Sendme-arguments with the syntax 3316 Ihave-arguments = [FWS] *( msg-id FWS ) [relayer-name] 3317 but this form SHOULD NOT now be used, though relaying agents MAY 3318 recognize and process it for backward compatibility. 3320 The ihave message states that the named relaying agent has received 3321 articles with the specified message identifiers, which may be of 3322 interest to the relaying agents receiving the ihave message. The 3323 sendme message requests that the agent receiving it send the articles 3324 having the specified message identifiers to the named relaying agent. 3326 These control messages are normally sent essentially as point-to- 3327 point messages, by using newsgroup-names in the Newsgroups-header of 3328 the form "to." followed by one (or possibly more) components in the 3329 form of a relayer-name (see section 5.5.1 which forbids "to" as the 3330 first component of a newsgroup-name). The control message SHOULD then 3331 be delivered ONLY to the relaying agent(s) identified by that 3332 relayer-name, and any relaying agent receiving such a message which 3333 includes its own relayer-name MUST NOT propagate it further. Each 3334 pair of relaying agent(s) sending and receiving these messages MUST 3335 be immediate neighbors, exchanging news directly with each other. 3336 Each relaying agent advertises its new arrivals to the other using 3337 ihave messages, and each uses sendme messages to request the articles 3338 it lacks. 3340 To reduce overhead, ihave and sendme messages SHOULD be sent 3341 relatively infrequently and SHOULD contain reasonable numbers of 3342 message identifiers. If ihave and sendme are being used to implement 3343 a backup feed, it may be desirable to insert a delay between 3344 reception of an ihave and generation of a sendme, so that a slightly 3345 slow primary feed will not cause large numbers of articles to be 3346 requested unnecessarily via sendme. 3348 7.5. Obsolete control messages. 3350 The following control messages are declared obsolete by this 3351 standard: 3353 sendsys 3354 version 3355 whogets 3356 senduuname 3358 8. Duties of Various Agents 3360 The following section sets out the duties of various agents involved 3361 in the creation, relaying and serving of Usenet articles. Insofar as 3362 these duties are described as sequences of steps to be followed, it 3363 should be understood that it is the effect of these sequences that is 3364 important, and implementations may use any method that gives rise to 3365 that same effect. 3367 In this section, the word "trusted", as applied to the source of some 3368 article, means that an agent processing that article has verified, by 3369 some means, the identity of that source (which may be another agent 3370 or a poster). 3372 NOTE: In many implementations, a single agent may perform 3373 various combinations of the injecting, relaying and serving 3374 functions. Its duties are then the union of the various duties 3375 concerned. 3377 8.1. General principles to be followed 3379 There are two important principles that news implementors (and 3380 administrators) need to keep in mind. The first is the well-known 3381 Internet Robustness Principle: 3383 Be liberal in what you accept, and conservative in what you 3384 send. 3386 However, in the case of news there is an even more important 3387 principle, derived from a much older code of practice, the 3388 Hippocratic Oath (we may thus call this the Hippocratic Principle): 3390 First, do no harm. 3392 It is VITAL to realize that decisions which might be merely 3393 suboptimal in a smaller context can become devastating mistakes when 3394 amplified by the actions of thousands of hosts within a few minutes. 3396 In the case of gateways, the primary corollary to this is: 3398 Cause no loops. 3400 8.2. Duties of an Injecting Agent 3402 An Injecting Agent is responsible for taking a proto-article from a 3403 posting agent and either forwarding it to a moderator or injecting it 3404 into the relaying system for access by readers. 3406 As such, an injecting agent is considered responsible for ensuring 3407 that any article it injects conforms with the rules of this standard. 3408 It is also expected to bear some responsibility towards the rest of 3409 the network for the behaviour of its posters (and provision is 3410 therefore made for it to be easily contactable by email). 3412 In the normal course of events, an article that has already been 3413 injected into a Netnews network will never pass through another 3414 injecting agent. So, if an injecting agent receives an otherwise 3415 valid article that has already been injected (as evidenced by the 3416 presence of an Injection-Date-header, an Injection-Info-header, or 3417 more thath one '%' path-delimiter in a Path-header) it MAY choose to 3418 reject it, but otherwise SHOULD cause it to be relayed, as it stands, 3419 by a relaying agent (8.3). 3421 In exceptional circumstances (e.g. as part of come complex gatewaying 3422 process, or where a relaying agent considers it essential for 3423 fulfilling its responsibility towards the rest of the network) an 3424 already injected article MAY be "reinjected" into the network. This 3425 standard does not prescribe any such circumstance; rather this is a 3426 matter of policy to be determined by the administrators of each 3427 injecting agent, who have the responsibility to ensure that no harm 3428 arises. In all other circumstances, unintented reinjection is to be 3429 avoided (see 8.8). Nevertheless, in order to preserve the integrity 3430 of the network in those special cases, this standard does set out the 3431 proper way to reinject. 3433 8.2.1. Proto-articles 3435 A proto-article is one that has been created by a posting agent and 3436 has not yet been injected into a Netnews system by an injecting 3437 agent. It SHOULD NOT be propagated in that form to other than 3438 injecting agents. 3440 A proto-article has the same format as a normal article except that 3441 some of the following mandatory headers MAY be omitted: Message-Id- 3442 header, Date-header, Path-header (and even From-header if the 3443 particular injecting agent can derive that information from other 3444 sources). However, if it is intended to offer the proto-article to 3445 two or more injecting agents in parallel, then it is only the Path- 3446 header that MAY be omitted. The omitted headers MUST NOT contain 3447 invalid values; they MUST either be correct or not present at all. 3449 NOTE: An article that is offered for reinjection has, by 3450 definition, already been injected once, and is not therefore to 3451 be considered as a proto-article. Hence a genuine proto-article 3452 will not contain any Injection-Date-header nor any '%' path- 3453 delimiter in its Path-header. It MAY contain path-identities 3454 with other path-delimiters in the pre-injection portion of its 3455 Path-header (5.6.3). 3457 8.2.2. Procedure to be followed by Injecting Agents 3459 An injecting agent receives proto-articles from posting and followup 3460 agents. It verifies them, adds headers where required, and then 3461 either forwards them to a moderator or injects them by passing them 3462 to serving or relaying agents. It MUST NOT forward an already 3463 injected article to a moderator. 3465 An injecting agent processes articles as follows: 3467 1. It MUST remove any Injection-Info- or Complaints-To-header already 3468 present (though it might be useful to copy them to suitable X- 3469 headers). It SHOULD likewise remove any NNTP-Posting-Host, X-Trace 3470 or other undocumented tracing header. 3472 2. It SHOULD verify that the article is from a trusted source. 3473 However, it MAY allow articles in which headers contain unverified 3474 email addresses, that is, addresses which are not known to be 3475 valid for the trusted source, and notably so if they end in 3476 ".invalid". 3478 3. It SHOULD reject any article whose Date-header (5.1) is more than 3479 24 hours into the future (and MAY use a margin less than that 24 3480 hours). It MUST, except when reinjecting, reject any article with 3481 an Injection-Date-header already present (and SHOULD do likewise 3482 with any NNTP-Posting-Date-header). It MAY when reinjecting, but 3483 only if there is no Injection-Date-header present, reject any 3484 article whose Date-header appears to be stale (e.g. more than 72 3485 hours into the past). 3487 4. It MUST reject any article that does not have the correct 3488 mandatory headers for a proto-article (or, when reinjecting, all 3489 the mandatory headers other than Injection-Date), or which 3490 contains any header that does not have legal contents. It SHOULD 3491 reject any article which contains any header deprecated for 3492 Netnews (4.2.1). 3494 5. If the article is rejected (for reasons given above, or for other 3495 formatting errors or matters of site policy) the posting agent 3496 SHOULD be informed (such as via an NNTP 44x response code) that 3497 posting has failed and the article MUST NOT then be processed 3498 further. 3500 6. The Message-ID, Date and From-headers (and their contents) MUST be 3501 added when not already present (but that situation could not arise 3502 during reinjection). 3504 7. A Path-header with a tail-entry (5.6.3) MUST be correctly added if 3505 not already present (except that it SHOULD NOT be added if the 3506 article is to be forwarded to a moderator). During reinjection, 3507 the existing Path-header SHOULD be retained. 3509 8. The path-identity of the injecting agent with a '%' path-delimiter 3510 (5.6.2) MUST be prepended to the Path-header (which could result 3511 in more that one '%' path-delimiter in the case of reinjection); 3512 moreover, that path-identity MUST be an FQDN mailable address 3513 (5.6.2). 3515 9. An Injection-Info-header (6.19) SHOULD be added, identifying the 3516 trusted source of the article, and a suitable Complaints-To-header 3517 (6.20) MAY be added (except that these two headers MUST NOT be 3518 added if the article is to be forwarded to a moderator). 3520 10.The injecting agent MUST NOT alter the body of the article in any 3521 way. It MAY, except when reinjecting, add other headers not 3522 already provided by the poster, but SHOULD NOT alter, delete, or 3523 reorder any existing header, with the specific exception of 3524 "tracing" headers such as Injection-Info and Complaints-To, which 3525 are to be removed as already mentioned. 3527 11.If the Newsgroups-header contains no moderated groups, or if it 3528 contains an Approved-header, the injecting agent MUST then add an 3529 Injection-Date-header (5.7) if one is not already present, but it 3530 MUST NOT alter, or remove, an already present Injection-Date- 3531 header (and likewise SHOULD NOT alter, or remove, an already 3532 present NNTP-Posting-Date-header). Finally, it forwards the 3533 article to one or more relaying or serving agents. 3535 12.Otherwise, when the Newsgroups-header contains one or more 3536 moderated groups and the article does NOT contain an Approved- 3537 header, the injecting agent MUST forward it to the moderator of 3538 the first (leftmost) moderated group listed in the Newsgroups- 3539 header via email. There are two possibilities for doing this: 3541 (a) The complete article is encapsulated (headers and all) within 3542 the email, preferably using the Content-Type 3543 "application/news-transmission" (6.21.4.1) with any usage 3544 parameter set to "moderate". Moreover, there SHOULD NOT be 3545 more than one encapsulated article within the one email. 3546 This method has the advantage of removing any possible 3547 conflict between Netnews and Email headers, or of changes to 3548 those headers during transport through email. 3550 (b) The article is sent as an email as it stands, with the 3551 addition of such extra headers (e.g. a To-header) as are 3552 necessary for an email. 3554 Although both of these methods have seen use in the past, the 3555 preponderance of current usage on Usenet has been for method (b) 3556 and many moderators are ill-prepared to deal with method (a). 3557 Therefore, method (a) SHOULD NOT be used until such time as the 3558 majority of moderators are able to accept it. 3560 13.This standard does not prescribe how the email address of the 3561 moderator is to be determined, that being a matter of policy to be 3562 arranged by the agency responsible for the oversight of each 3563 hierarchy. Nevertheless, there do exist various agents worldwide 3564 which provide the service of forwarding to moderators, and the 3565 address to use with them is obtained as follows: 3567 (a) Each '.' in the newsgroup-name is replaced with a '-'. 3569 (b) The result of these operations is used as the local-part of 3570 the mailbox of the agent. For example, articles intended for 3571 "news.announce.important" would be emailed to "news- 3572 announce-important@forwardingagent.example". 3574 8.3. Duties of a Relaying Agent 3576 A Relaying Agent accepts injected articles from injecting and other 3577 relaying agents and passes them on to relaying or serving agents 3578 according to mutually agreed policy. Relaying agents SHOULD accept 3579 articles ONLY from trusted agents. 3581 A relaying agent processes articles as follows: 3583 1. It MUST verify the leftmost entry in the Path-header and then 3584 prepend its own path-identity with a '/' path-delimiter, and 3585 possibly also the verified path-identity of its source with a '?' 3586 path-delimiter (5.6.2). 3588 2. It MUST examine the Injection-Date-header (or, if that is absent, 3589 the Date-header) and reject the article as stale (5.7) if that 3590 predates the earliest articles of which it normally keeps record, 3591 or if it is more than 24 hours into the future (the margin MAY be 3592 less than that 24 hours). 3594 3. It MUST reject any article that does not have the correct 3595 mandatory headers (section 5) present with legal contents. 3597 4. It SHOULD reject any article whose optional headers (section 6) do 3598 not have legal contents. 3600 5. It SHOULD reject any article that has already been sent to it (a 3601 database of message identifiers of recent messages is usually kept 3602 and matched against). 3604 6. It SHOULD reject any article that matches an already received 3605 cancel message (or an equivalent Supersedes-header) issued by its 3606 poster or by some other trusted entity. 3608 7. It MAY reject any article without an Approved-header posted to 3609 newsgroups known to be moderated (this practice is strongly 3610 recommended, but the information necessary to do it may not be 3611 available to all agents). 3613 8. It then passes articles which match mutually agreed criteria on to 3614 neighbouring relaying and serving agents. However, it SHOULD NOT 3615 forward articles to sites whose path-identity is already in the 3616 Path-header. 3618 NOTE: It is usual for relaying and serving agents to restrict 3619 the Newsgroups, Distributions, age and size of articles that 3620 they wish to receive. 3622 If the article is rejected as being invalid, unwanted or unacceptable 3623 due to site policy, the agent that passed the article to the relaying 3624 agent SHOULD be informed (such as via an NNTP 43x response code) that 3625 relaying failed. In order to prevent a large number of error messages 3626 being sent to one location, relaying agents MUST NOT inform any other 3627 external entity that an article was not relayed UNLESS that external 3628 entity has explicitly requested that it be informed of such errors. 3630 NOTE: In order to prevent overloading, relaying agents should 3631 not routinely query an external entity (such as a DNS-server) in 3632 order to verify an article (though a local cache of the required 3633 information might usefully be consulted). 3635 Relaying agents MUST NOT alter, delete or rearrange any part of an 3636 article expect for headers designated as variant (4.2.5.3). 3638 8.4. Duties of a Serving Agent 3640 A Serving Agent takes an article from a relaying or injecting agent 3641 and files it in a "news database". It also provides an interface for 3642 reading agents to access the news database. This database is normally 3643 indexed by newsgroup with articles in each newsgroup identified by an 3644 article-locator (usually in the form of a decimal number - see 6.16). 3646 NOTE: Since control messages are often of interest, but should 3647 not be displayed as normal articles in regular newsgroups, it is 3648 common for serving agents to make them available in a pseudo- 3649 newsgroup named "control" or in a pseudo-newsgroup in a sub- 3650 hierarchy under "control." (e.g. "control.cancel"). 3652 A serving agent processes articles as follows: 3654 1. It MUST verify the leftmost entry in the Path-header and then 3655 prepend its own path-identity with a '/' path-delimiter, and 3656 possibly also the verified path-identity of its source with a '?' 3657 path-delimiter (5.6.2). 3659 2. It MUST examine the Injection-Date-header (or, if that is absent, 3660 the Date-header) and reject the article as stale (5.7) if that 3661 predates the earliest articles of which it normally keeps record, 3662 or if it is more than 24 hours into the future (the margin MAY be 3663 less than that 24 hours). 3665 3. It MUST reject any article that does not have the correct 3666 mandatory headers (section 5) present, or which contains any 3667 header that does not have legal contents. 3669 4. It SHOULD reject any article that has already been sent to it (a 3670 database of message identifiers of recent messages is usually kept 3671 and matched against). 3673 5. It SHOULD reject any article that matches an already received 3674 cancel message (or an equivalent Supersedes-header) issued by its 3675 poster or by some other trusted entity. 3677 6. It MUST reject any article without an Approved-header posted to 3678 any moderated newsgroup which it is configured to receive, and it 3679 MAY reject such articles for any newsgroup it knows to be 3680 moderated. 3682 7. It MUST remove any Xref-header (6.16) from each article. It then 3683 MAY (and usually will) generate a fresh Xref-header. 3685 8. Finally, it stores the article in its news database. 3687 8.5. Duties of a Posting Agent 3689 A Posting Agent is used to assist the poster in creating a valid 3690 proto-article and forwarding it to an injecting agent. 3692 Postings agents SHOULD ensure that proto-articles they create are 3693 valid according to this standard and other applicable policies. In 3694 particular, they MUST NOT create any Injection-Date-, Injection-Info- 3695 or Complaints-To-header. 3697 Posting agents meant for use by ordinary posters SHOULD reject any 3698 attempt to post an article which cancels or Supersedes another 3699 article of which the poster is not the author. 3701 8.6. Duties of a Followup Agent 3703 A Followup Agent is a special case of a posting agent, and as such is 3704 bound by all the posting agent's requirements. Followup agents MUST 3705 create valid followups and are subject to special requirements 3706 involving certain inheritable (4.2.5.2) and other headers. Wherever 3707 in the following it is stated that, "by default", a header is to be 3708 taken from some header in the precursor, it means that its initial 3709 content (plus its extension-parameters, if any) are to be copied from 3710 those of that precursor header. However, posters MAY then override 3711 that default before posting if they so wish. 3713 NOTE: There is no provision in this standard for a followup to 3714 have more than one precursor (though it might be permitted in 3715 some future extension). 3717 1. The Newsgroups-header (5.5) SHOULD by default be taken from the 3718 precursor's Followup-To-header if present, and otherwise from the 3719 precursor's Newsgroups-header. However, if the content of that 3720 Followup-To-header consists of "poster" (and the user does not 3721 override it), then the followup MUST NOT be posted but, rather, is 3722 to be emailed to the precursor's poster. 3724 2. The Subject-header SHOULD by default be taken from that of the 3725 precursor's Subject-header. The case sensitive string "Re: " 3726 (known as a "back reference") MAY be prepended to its Subject- 3727 Content unless it already begins with that string. 3729 NOTE: The practice of prepending such a "Re: " (which is an 3730 abbreviation for the Latin "In re", meaning "in the matter of", 3731 and not an abbreviation of "Reference" as is sometimes 3732 erroneously supposed) is widespread, but reading agents cannot 3733 rely on all followup Subject-headers using it, nor can it be 3734 assumed that reading agents will understand any back-reference 3735 other than a single "Re: ". 3736 [Shmuel wants something like "... nor that the "Re:" was even intended 3737 as a back-reference."] 3739 Some reading agents, notably those which choose to use the 3740 Subject-header to enable a simple form of thread sorting, need 3741 to be able to recognize the presence of a back-reference. 3743 [Various other snippets of text have been suggested for the NOTE, 3744 including the following: 3746 NOTE: Some reading agents expect a single "Re: " at the 3747 beginning of the Subject-content of a followup, and consider 3748 this when sorting articles for display. This is unreliable, and 3749 an intrusion on the unstructured nature of the header, but 3750 widespread. 3752 NOTE: Some reading agents expect this string at the beginning of 3753 the Subject-content of a followup, and consider this when 3754 sorting articles for display. Further, most expect just one 3755 instance of "Re: ", and do not treat any other string in this 3756 manner. 3758 NOTE: Further discussion of this (user interface) issue can be 3759 found in [USEAGE] section x.x. 3761 Although "Re: " is case-sensitive, there has historically been 3762 some disagreement about that, so it is best to check for its 3763 presence with a case-insensitive test. 3764 End of snippets.] 3766 3. The Distribution-header (6.6) SHOULD by default be taken from the 3767 precursor's Distribution-header, if any. 3769 4. If the precursor did not have a References-header (6.10), the 3770 followup's References-content MUST be formed by the message 3771 identifier of the precursor. A followup to an article which had a 3772 References-header MUST have a References-header containing the 3773 precursor's References-content (subject to trimming as described 3774 below) plus the precursor's message identifier appended to the end 3775 of the list (separated from it by CFWS). 3777 Followup agents MAY trim References-headers which have grown to 3778 excessive length, but the first and last message identifiers from 3779 the precursor MUST NOT be removed. 3781 5. If the precursor contains a Mail-Copies-To-header (6.8), the 3782 actions to be taken, in accordance with the Mail-Copies-To- 3783 content, (and subject to manual override by the poster) are as 3784 follows: 3786 "nobody" (or when the header is absent) 3787 The followup agent SHOULD NOT email a copy of a posted 3788 followup to the poster of the precursor. 3790 "poster" 3791 The followup agent SHOULD (if it has the necessary 3792 capability) email a copy of a posted followup, which MUST 3793 then be sent to the address(es) in the Reply-To-header, and 3794 in the absence of that to the address(es) in the From- 3795 header. 3797 a copy-addr 3798 The followup agent SHOULD likewise email a copy of a posted 3799 followup, which MUST then be sent to the copy-addr. 3801 When emailing a copy, the followup agent SHOULD also include a 3802 "Posted-And-Mailed: yes" header (6.9). 3804 Followup agents SHOULD NOT attempt to send email to any address 3805 ending in ".invalid". 3807 8.7. Duties of a Moderator 3809 A Moderator receives news articles by email, decides whether to 3810 accept them and, if so, either injects them into the news stream or 3811 forwards them to further moderators. 3813 Articles will be received by the moderator either encapsulated as an 3814 object of Content-Type application/news-transmission (or possibly 3815 encapsulated but without an explicit Content-Type-header), or else 3816 directly as an email already containing all the headers appropriate 3817 for a Netnews article (see 8.2.2). Moderators SHOULD be prepared to 3818 accept articles in either format. 3820 A moderator processes an article, as submitted to any newsgroup that 3821 he moderates, as follows: 3823 1. He decides, on the basis of whatever moderation policy applies to 3824 his group, whether to accept or reject the article. He MAY do this 3825 manually, or else partially or wholly with the aid of appropriate 3826 software for whose operation he is then responsible. If the 3827 article is a cancel nessage (7.3) issued by the poster of an 3828 earlier article, then he is expected to cancel that earlier 3829 article (in which case there is no more to be done). He MAY 3830 modify the article if that is in accordance with the applicable 3831 moderation policy (and in particular he MAY remove redundant 3832 headers and add Comments and other informational headers). He 3833 also needs to be aware if any change he makes to the article will 3834 invalidate some authentication check provided by the poster or by 3835 an earlier moderator. 3837 If the article is rejected, then it normally fails for all the 3838 newsgroups for which it was intended. If it is accepted, the 3839 moderator proceeds with the following steps. 3841 2. If the Newsgroups-header contains further moderated newsgroups for 3842 which approval has not already been given, he adds an indication 3843 (identifying both himself and the name of the group) that he 3844 approves the article, and then forwards it to the moderator of the 3845 leftmost unapproved group (which, if this standard has been 3846 followed correctly, will generally be the next moderated group to 3847 the right of his own). There are two ways to do this: 3849 (a) He emails it to the submission address of the next moderator 3850 (see section 8.2.2 for the proper method of doing this), or 3852 (b) he rotates the newsgroup-names in the Newsgroups-header to 3853 the left so that the targeted group is the leftmost moderated 3854 group in that header, and injects it as below (thus causing 3855 the injecting agent to email it to the correct moderator). 3856 However, he MUST first ensure that the article contains no 3857 Approved-header. 3859 NOTE: This standard does not prescribe how a moderator's 3860 approval is to be indicated (though a future standard may do 3861 so). Possible methods include adding an Approved header (or a 3862 similar but differently named header if method (b) is being 3863 used) listing all the approvals made so far, or adding a 3864 separate header for each individual approval (the header X-Auth 3865 is sometimes used for this purpose). The approval may also be 3866 confirmed with some form of digital signature (7.1). 3868 3. If the Newsgroups-header contains no further unapproved moderated 3869 groups, he adds an Approved-header (6.14) identifying himself and, 3870 insofar as is possible, all the other moderators who have approved 3871 the article. He thus assumes responsibility for having ensured 3872 that the article was acceptable to the moderators of all the 3873 moderated groups involved. 3875 4. The Date-header SHOULD be retained. Any Injection-Date-header 3876 already present (though there should be none) MUST be removed. 3877 Exceptionally, if it is known that the injecting agent does not 3878 yet support the Injection-Date-header and the Date-header appears 3879 to be stale (5.7) for reasons understood by the moderator (e.g. 3880 delays in the moderation process) he MAY substitute the current 3881 date. The Message-ID-header SHOULD also be retained unless it is 3882 obviously non-compliant with this standard. 3884 NOTE: A message identifier created by a conforming posting or 3885 injecting agent, or even by a mail user agent conforming to [RFC 3886 2822], may reasonably be supposed to be conformant (and will, in 3887 any case, be caught by the injecting agent if it is not). 3889 5. Any variant headers (4.2.5.3) MUST be removed, except that a 3890 Path-header MAY be truncated to only its pre-injection region 3891 (5.6.3). Any Injection-Date-header (5.7), Injection-Info-header 3892 (6.19) or Complaints-To-header (6.20) MUST be removed (though in 3893 fact there should be none of these). 3895 6. He then causes the article to be injected, having first observed 3896 all the duties of a posting agent. 3898 NOTE: This standard does not prescribe how the moderator or 3899 moderation policy for each newsgroup is established; rather it 3900 assumes that whatever agencies are responsible for the relevant 3901 network or hierarchy (1.1) will have made appropriate 3902 arrangements in that regard. 3904 8.8. Duties of a Gateway 3906 A Gateway transforms an article into the native message format of 3907 another medium, or translates the messages of another medium into 3908 news articles. Encapsulation of a news article into a message of MIME 3909 type application/news-transmission, or the subsequent undoing of that 3910 encapsulation, is not gatewaying, since it involves no transformation 3911 of the article. 3913 There are two basic types of gateway, the Outgoing Gateway that 3914 transforms a news article into a different type of message, and the 3915 Incoming Gateway that transforms a message from another medium into a 3916 news article and injects it into a news system. These are handled 3917 separately below. 3919 The primary dictat for a gateway is: 3921 Above all, prevent loops. 3923 Transformation of an article into another medium stands a very high 3924 chance of discarding or interfering with the protection inherent in 3925 the news system against duplicate articles. The most common problem 3926 caused by gateways is "spews," gateway loops that cause previously 3927 posted articles to be reinjected repeatedly into Usenet. To prevent 3928 this, a gateway MUST take precautions against loops, as detailed 3929 below. 3931 If bidirectional gatewaying (both an incoming and an outgoing 3932 gateway) is being set up between Netnews and some other medium, the 3933 incoming and outgoing gateways SHOULD be coordinated to avoid 3934 unintended reinjection of gated articles. Circular gatewaying 3935 (gatewaying a message into another medium and then back into Netnews) 3936 SHOULD NOT be done; encapsulation of the article SHOULD be used 3937 instead where this is necessary. 3939 A second general principal of gatewaying is that the transformations 3940 applied to the message SHOULD be as minimal as possible while still 3941 accomplishing the gatewaying. Every change made by a gateway 3942 potentially breaks a property of one of the media or loses 3943 information, and therefore only those transformations made necessary 3944 by the differences between the media should be applied. 3946 It is worth noting that safe bidirectional gatewaying between a 3947 mailing list and a newsgroup is far easier if the newsgroup is 3948 moderated. Posts to the moderated group and submissions to the 3949 mailing list can then go through a single point that does the 3950 necessary gatewaying and then sends the message out to both the 3951 newsgroup and the mailing list at the same time, eliminating most of 3952 the possibility of loops. Bidirectional gatewaying between a mailing 3953 list and an unmoderated newsgroup, in contrast, is difficult to do 3954 correctly and is far more fragile. 3956 Newsgroups intended to be bidirectionally gated to a mailing list 3957 SHOULD therefore be moderated where possible, even if the moderator 3958 is a simple gateway and injecting agent that correctly handles 3959 crossposting to other moderated groups and otherwise passes all 3960 traffic. 3962 8.8.1. Duties of an Outgoing Gateway 3964 From the perspective of Netnews, an outgoing gateway is just a 3965 special type of reading agent. The exact nature of what the outgoing 3966 gateway will need to do to articles depends on the medium to which 3967 the articles are being gated. The operation of the outgoing gateway 3968 is only subject to additional constraints in the presence of one or 3969 more corresponding incoming gateways back from that medium to 3970 Netnews, since this opens the possibility of loops. 3972 In general, the following practices are recommended for all outgoing 3973 gateways, regardless of whether there is known to be a related 3974 incoming gateway, both as a precautionary measure and as a guideline 3975 to quality of implementation. 3977 1. The message identifier of the news article should be preserved if 3978 at all possible, preferably as or within the corresponding unique 3979 identifier of the other medium, but if not at least as a comment 3980 in the message. This helps greatly with preventing loops. 3982 2. The Date and Injection-Date of the news article should also be 3983 preserved if possible, for similar reasons. 3985 3. The message should be tagged in some way so as to prevent its 3986 reinjection into Netnews. This may be impossible to do without 3987 knowledge of potential incoming gateways, but it is better to try 3988 to provide some indication even if not successful; at the least, a 3989 human-readable indication that the article should not be gated 3990 back to Netnews can help locate a human problem. 3992 4. Netnews control messages should not be gated to another medium 3993 unless they would somehow be meaningful in that medium. 3995 8.8.2. Duties of an Incoming Gateway 3997 The incoming gateway has the serious responsibility of ensuring that 3998 all of the requirements of this standard are met by the articles that 3999 it forms. In addition to its special duties as a gateway, it bears 4000 all of the duties and responsibilities of an injecting agent as well, 4001 and additionally has the same responsibility of a relaying agent to 4002 reject articles that it has already gatewayed. 4004 An incoming gateway MUST NOT gate the same message twice. It may not 4005 be possible to ensure this in the face of mangling or modification of 4006 the message, but at the very least a gateway, when given a copy of a 4007 message it has already gated identical except for trace headers (like 4008 Received in Email or Path in Netnews) MUST NOT gate the message 4009 again. An incoming gateway SHOULD take precautions against having 4010 this rule bypassed by modifications of the message that can be 4011 anticipated. 4013 News articles prepared by gateways MUST be legal news articles. In 4014 particular, they MUST include all of the mandatory headers, MUST 4015 fully conform to the restrictions on said headers, and SHOULD exclude 4016 any deprecated headers (4.2.1). This often requires that a gateway 4017 function not only as a relaying agent, but also partly as a posting 4018 agent, aiding in the synthesis of a conforming article from non- 4019 conforming input. 4021 Incoming gateways MUST NOT pass control messages (articles containing 4022 a Control- or Supersedes-header) without removing or renaming that 4023 header. Gateways MAY, however, generate their own cancel messages, 4024 under the general allowance for injecting agents to cancel their own 4025 messages (7.3). If a gateway receives a message that it can 4026 determine is a valid equivalent of a cancel message in the medium it 4027 is gatewaying, it SHOULD discard that message without gatewaying it, 4028 generate a corresponding cancel message of its own, and inject that 4029 cancel message. 4031 Incoming gateways MUST NOT inject control messages other than 4032 cancels. Encapsulation SHOULD be used instead of gatewaying, when 4033 direct posting is not possible or desirable. 4035 NOTE: It is not unheard of for mail-to-news gateways to be used 4036 to post control messages, but encapsulation should be used for 4037 these cases instead. Gateways by their very nature are 4038 particularly prone to loops. Spews of normal articles are bad 4039 enough; spews of control messages with special significance to 4040 the news system, possibly resulting in high processing load or 4041 even email sent for every message received, are catastrophic. It 4042 is far preferable to construct a system specifically for posting 4043 control messages that can do appropriate consistency checks and 4044 authentication of the originator of the message. 4046 If there is a message identifier that fills a role similar to that of 4047 the Message-ID-header in news, it SHOULD be used in the formation of 4048 the message identifier of the news article, perhaps with 4049 transformations required to meet the uniqueness requirement of 4050 Netnews and with the removal of any comments so as to comply with the 4051 syntax in section 5.3. Such transformations SHOULD be designed so 4052 that two messages with the same identifier generate the same 4053 Message-ID-header. 4055 NOTE: Message identifiers play a central role in the prevention 4056 of duplicates, and their correct use by gateways will do much to 4057 prevent loops. Netnews does, however, require that message 4058 identifiers be unique, and therefore message identifiers from 4059 other media may not be suitable for use without modification. A 4060 balance must be struck by the gateway between preserving 4061 information used to prevent loops and generating unique message 4062 identifiers. 4064 Exceptionally, if there are multiple incoming gateways for a 4065 particular set of messages, each to a different newsgroup(s), each 4066 one SHOULD generate a message identifier unique to that gateway. Each 4067 incoming gateway nonetheless MUST ensure that it does not gate the 4068 same message twice. 4070 NOTE: Consider the example of two gateways of a given mailing 4071 list into the world-wide Usenet newsgroups, both of which 4072 preserve the email message identifier. Each newsgroup may then 4073 receive a portion of the messages (different sites seeing 4074 different portions). In these cases, where there is no one 4075 "official" gateway, some other method of generating message 4076 identifiers has to be used to avoid collisions. It would 4077 obviously be preferable for there to be only one gateway which 4078 crossposts, but this may not be possible to coordinate. 4080 If no date information is available, the gateway MAY supply a Date- 4081 header with the gateway's current date. If no injection-date 4082 information is available, the gateway MUST supply an Injection-Date- 4083 header with whatever date information is available, and otherwise 4084 with the gateway's current date. If only partial information is 4085 available (e.g. date but not time), this SHOULD be fleshed out to a 4086 full Date- and/or Injection-Date-header by adding default values 4087 rather than discarding this information. Only in very exceptional 4088 circumstances should Date information be discarded, as it plays an 4089 important role in preventing reinjection of old messages. 4091 An incoming gateway MUST add a Sender-header to the news article it 4092 forms containing the mailbox of the administrator of the gateway. 4093 Problems with the gateway may be reported to this mailbox. The 4094 display-name portion of this mailbox SHOULD indicate that the entity 4095 responsible for injection of the message is a gateway. If the 4096 original message already had a Sender-header, it SHOULD be renamed so 4097 that its contents can be preserved. 4099 8.8.3. Example 4101 To illustrate the type of precautions that should be taken against 4102 loops, here is an example of the measures taken by one particular 4103 combination of mail-to-news and news-to-mail gateways at Stanford 4104 University designed to handle bidirectional gatewaying between 4105 mailing lists and unmoderated groups. 4107 1. The news-to-mail gateway preserves the message identifier of the 4108 news article in the generated email message. The mail-to-news 4109 gateway likewise preserves the email message identifier provided 4110 that it is syntactically valid for Netnews. This allows the news 4111 system's built-in suppression of duplicates to serve as the first 4112 line of defense against loops. 4114 2. The news-to-mail gateway adds an X-Gateway-header to all messages 4115 it generates. The mail-to-news gateway discards any incoming 4116 messages containing this header. This is robust against mailing 4117 list managers that replace the message identifier, and against any 4118 number of email hops, provided that the other message headers are 4119 preserved. 4121 3. The mail-to-news gateway inserts the host name from which it 4122 received the email message in the pre-injection region of the Path 4123 (5.6.3). The news-to-mail gateway refuses to gateway any message 4124 that contains the list server name in the pre-injection region of 4125 its Path-header. This is robust against any amount of munging of 4126 the message headers by the mailing list, provided that the email 4127 only goes through one hop. 4129 4. The mail-to-news gateway is designed never to generate bounces to 4130 the envelope sender. Instead, articles that are rejected by the 4131 news server (for reasons not warranting silent discarding of the 4132 message) result in a bounce message sent to an errors address 4133 known not to forward to any mailing lists, so that they can be 4134 handled by the news administrators. 4136 These precautions have proven effective in practice at preventing 4137 loops for this particular application (bidirectional gatewaying 4138 between mailing lists and locally distributed newsgroups where both 4139 gateways can be designed together). General gatewaying to world-wide 4140 newsgroups poses additional difficulties; one must be very wary of 4141 strange configurations, such as a newsgroup gated to a mailing list 4142 which is in turn gated to a different newsgroup. 4144 9. Security and Related Considerations 4146 There is no security. Don't fool yourself. Usenet is a prime example 4147 of an Internet Adhocratic-Anarchy; that is, an environment in which 4148 trust forms the basis of all agreements. It works. 4150 9.1. Leakage 4152 Articles which are intended to have restricted distribution are 4153 dependent on the goodwill of every site receiving them. The 4154 "Archive: no" header (6.12) is available as a signal to automated 4155 archivers not to file an article, but that cannot be guaranteed. 4157 The Distribution-header makes provision for articles which should not 4158 be propagated beyond a cooperating subnet. The key security word here 4159 is "cooperating". When a machine is not configured properly, it may 4160 become uncooperative and tend to distribute all articles. 4162 The flooding algorithm is extremely good at finding any path by which 4163 articles can leave a subnet with supposedly restrictive boundaries, 4164 and substantial administrative effort is required to avoid this. 4165 Organizations wishing to control such leakage are strongly advised to 4166 designate a small number of official gateways to handle all news 4167 exchange with the outside world (however, making such gateways too 4168 restrictive can also encourage the setting up of unofficial paths 4169 which can be exceedingly hard to track down). 4171 The sendme control message (7.4), insofar as it is still used, can be 4172 used to request articles with a given message identifier, even one 4173 that is not supposed to be supplied to the requestor. 4175 9.2. Attacks 4177 9.2.1. Denial of Service 4179 The proper functioning of individual newsgroups can be disrupted by 4180 the massive posting of "noise" articles, by the repeated posting of 4181 identical or near identical articles, by posting followups unrelated 4182 to their precursors, or which quote their precursors in full with the 4183 addition of minimal extra material (especially if this process is 4184 iterated), and by crossposting to, or setting followups to, totally 4185 unrelated newsgroups. 4187 Many have argued that "spam", massively multiposted (and to a lesser 4188 extent massively crossposted) articles, usually for advertising 4189 purposes, also constitutes a DoS attack in its own regard. This may 4190 be so. 4192 Such articles intended to deny service, or other articles of an 4193 inflammatory nature, may also have their From or Reply-To addresses 4194 set to valid but incorrect email addresses, thus causing large 4195 volumes of email to descend on the true owners of those addresses. 4197 Similar effects could be caused by any email header which could cause 4198 every reading agent receiving it to take some externally visible 4199 action. For example, the Disposition-Notification-To-header defined 4200 in [RFC 2298] could cause huge numbers of acknowledgements to be 4201 emailed to an unsuspecting third party (for which reason [RFC 2298] 4202 declares that that header SHOULD NOT be used in Netnews). 4204 It is a violation of this standard for a poster to use as his address 4205 a mailbox which he is not entitled to use. Even addresses with an 4206 invalid local-part but a valid domain can cause disruption to the 4207 administrators of such domains. Posters who wish to remain anonymous 4208 or to prevent automated harvesting of their addresses, but who do not 4209 care to take the additional precautions of using more sophisticated 4210 anonymity measures, should avoid that violation by the use of 4211 addresses ending in the ".invalid" top-level-domain (see 5.2). 4213 A malicious poster may also prevent his article being seen at a 4214 particular site by preloading that site into the Path-header (5.6.1) 4215 and may thus prevent the true owner of a forged From or Reply-To 4216 address from ever seeing it. 4218 A malicious complainer may submit a modified copy of an article (e.g. 4219 with an altered Injection-Info-header) to the administrator of an 4220 injecting agent in an attempt to discredit the author of that article 4221 and even to have his posting privileges removed. Administrators 4222 should therefore obtain a genuine copy of the article from their own 4223 serving agent before taking such precipitate action. 4225 Administrative agencies with responsibility for establishing policies 4226 in particular hierarchies can and should set bounds upon the 4227 behaviour that is considered acceptable within those hierarchies (for 4228 example by promulgating charters for individual newsgroups, and other 4229 codes of conduct). 4231 Whilst this standard places an onus upon injecting agents to bear 4232 responsibility for the misdemeanours of their posters (which includes 4233 non-adherence to established policies of the relevant hierarchies as 4234 provided in section 8.2), and to provide assistance to the rest of 4235 the network by making proper use of the Injection-Info- (6.19) and 4236 Complaints-To- (6.20) headers, it makes no provision for enforcement, 4237 which may in consequence be patchy. Nevertheless, injecting sites 4238 which persistently fail to honour their responsibilities or to comply 4239 with generally accepted standards of behaviour are likely to find 4240 themselves blacklisted, with their articles refused propagation and 4241 even subject to cancellation, and other relaying sites would be well 4242 advised to withdraw peering arrangements from them. 4244 9.2.2. Compromise of System Integrity 4246 The posting of unauthorized (as determined by the policies of the 4247 relevant hierarchy) control messages can cause unwanted newsgroups to 4248 be created, or wanted ones removed, from serving agents. 4249 Administrators of such agents SHOULD therefore take steps to verify 4250 the authenticity of such control messages, either by manual 4251 inspection (particularly of the Approved-header) or by checking any 4252 digital signatures that may be provided (see 7.1). In addition, they 4253 SHOULD periodically compare the newsgroups carried against any 4254 regularly issued checkgroups messages, or against lists maintained by 4255 trusted servers and accessed by out-of-band protocols such as FTP or 4256 HTTP. 4258 Malicious cancel messages (7.3) can cause valid articles to be 4259 removed from serving agents. Administrators of such agents SHOULD 4260 therefore take steps to verify that they originated from the 4261 (apparent) poster, the injector or the moderator of the article, or 4262 that in other cases they came from a place that is trusted to work 4263 within established policies and customs. Such steps SHOULD include 4264 the checking of any digital signatures, or other security devices, 4265 that may be provided (see 7.1). Articles containing Supersedes- 4266 headers (6.15) are effectively cancel messages, and SHOULD be subject 4267 to the same checks. Currently, many sites choose to ignore all 4268 cancel messages on account of the difficulty of conducting such 4269 checks. 4271 Improperly configured serving agents can allow articles posted to 4272 moderated groups onto the net without first being approved by the 4273 moderator. Injecting agents SHOULD verify that moderated articles 4274 were received from one of the entities given in their Approved- 4275 headers and/or check any digital signatures that may be provided (see 4276 7.1). 4278 The filename parameter of the Archive-header (6.12) can be used to 4279 attempt to store archived articles in inappropriate locations. 4280 Archiving sites should be suspicious of absolute filename parameters, 4281 as opposed to those relative to some location of the archiver's 4282 choosing. 4284 There may be weaknesses in particular implementations that are 4285 subject to malicious exploitation. In particular, it has not been 4286 unknown for complete shell scripts to be included within Control- 4287 headers. Implementors need to be aware of this. 4289 Reading agents should be chary of acting automatically upon MIME 4290 objects with an "application" Content-Type that could change the 4291 state of that agent, except in contexts where such applications are 4292 specifically expected (see 6.21). Even the Content-Type "text/html" 4293 could have unexpected side effects on account of embedded objects, 4294 especially embedded executable code or URLs that invoke non-news 4295 protocols such as HTTP [RFC 2616]. It is therefore generally 4296 recommended that reading agents do not enable the execution of such 4297 code (since it is extremely unlikely to have a valid application 4298 within Netnews) and that they only honour URLs referring to other 4299 parts of the same article. 4301 Non-printable characters embedded in article bodies may have 4302 surprising effects on printers or terminals, notably by reconfiguring 4303 them in undesirable ways which may become apparent only after the 4304 reading agent has terminated. 4306 9.3. Liability 4308 There is a presumption that a poster who sends an article to Usenet 4309 intends it to be stored on a multitude of serving agents, and has 4310 therefore given permission for it to be copied to that extent. 4311 Nevertheless, Usenet is not exempt from the Copyright laws, and it 4312 should not be assumed that permission has been given for the article 4313 to be copied outside of Usenet, nor for its permanent archiving 4314 contrary to any Archive-header that may be present. 4316 Posters also need to be aware that they are responsible if they 4317 breach Copyright, Libel, Harassment or other restrictions relating to 4318 material that they post, and that they may possibly find themselves 4319 liable for such breaches in jurisdictions far from their own. Serving 4320 agents may also be liable in some jurisdictions, especially if the 4321 breach has been explicitly drawn to their attention. 4323 Users who are concerned about such matters should seek advice from 4324 competent legal authorities. 4326 10. IANA Considerations 4328 10.1. Media Types 4330 IANA is requested to register the following media types, described 4331 elsewhere in this standard for use with the Content-Type-header, in 4332 the IETF tree in accordance with the procedures set out in [RFC 4333 2048]. 4335 application/news-transmission (6.21.4.1) 4336 application/news-groupinfo (7.2.1.2) 4337 application/news-checkgroups (7.2.4.1) 4339 IANA is also requested to change the status of the following media 4340 type to "OBSOLETE". 4342 message/news (6.21.4.2) 4344 NOTE: "Application/news-transmission" is an update, with 4345 clarification and additional optional parameters, to an existing 4346 registration. "Message/rfc822" should now be used in place of 4347 the obsoleted "message/news". 4349 10.2. Header Field Registry 4351 IANA is requested to register the following headers in the Permanent 4352 Message Header Field Repository, in accordance with the procedures 4353 set out in [KLYNE]. 4355 Header field Applicable Status Author/Change Specification 4356 name protocol controller document 4358 Date netnews standard IETF [USEFOR] 5.1 4359 From netnews standard IETF [USEFOR] 5.2 4360 Message-ID netnews standard IETF [USEFOR] 5.3 4361 Subject netnews standard IETF [USEFOR] 5.4 4362 Newsgroups netnews standard IETF [USEFOR] 5.5 4363 Newsgroups mail standard IETF [USEFOR] 5.5 4364 Path netnews standard IETF [USEFOR] 5.6 4365 Reply-To netnews standard IETF [USEFOR] 6.1 4366 Sender netnews standard IETF [USEFOR] 6.2 4367 Organization netnews standard IETF [USEFOR] 6.3 4368 Keywords netnews standard IETF [USEFOR] 6.4 4369 Summary netnews standard IETF [USEFOR] 6.5 4370 Distribution netnews standard IETF [USEFOR] 6.6 4371 Followup-To netnews standard IETF [USEFOR] 6.7 4372 Mail-Copies-To netnews standard IETF [USEFOR] 6.8 4373 Posted-And-Mailed netnews standard IETF [USEFOR] 6.9 4374 References netnews standard IETF [USEFOR] 6.10 4375 Expires netnews standard IETF [USEFOR] 6.11 4376 Archive netnews standard IETF [USEFOR] 6.12 4377 Control netnews standard IETF [USEFOR] 6.13 4378 Approved netnews standard IETF [USEFOR] 6.14 4379 Supersedes netnews standard IETF [USEFOR] 6.15 4380 Xref netnews standard IETF [USEFOR] 6.16 4381 Lines netnews standard IETF [USEFOR] 6.17 4382 User-Agent netnews standard IETF [USEFOR] 6.18 4383 User-Agent mail standard IETF [USEFOR] 6.18 4384 Injection-Info netnews standard IETF [USEFOR] 6.19 4385 NNTP-Posting-Host netnews deprecated IETF [USEFOR] 6.19 4386 NNTP-Posting-Date netnews deprecated IETF [USEFOR] 5.7 4387 Complaints-To netnews standard IETF [USEFOR] 6.20 4388 Also-Control netnews obsoleted IETF [USEFOR] 6.22 4389 See-Also netnews obsoleted IETF [USEFOR] 6.22 4390 Article-Names netnews obsoleted IETF [USEFOR] 6.22 4391 Article-Updates netnews obsoleted IETF [USEFOR] 6.22 4393 11. References 4395 [ANSI X3.4] "American National Standard for Information Systems - 4396 Coded Character Sets - 7-Bit American National Standard Code for 4397 Information Interchange (7-Bit ASCII)", ANSI X3.4, 1986. 4399 [ISO 3166] "Codes for the representation of names of countries and 4400 their subdivisions -- Part 1: Country codes", ISO 3166, 1997. 4402 [ISO/IEC 10646] "International Standard - Information technology - 4403 Universal Multiple-Octet Coded Character Set (UCS) - Part 1: 4404 Architecture and Basic Multilingual Plane", ISO/IEC 10646- 4405 1:2000, 2000. 4407 [KLYNE] G. Klyne, M. Nottingham, and J. Mogul, "Registration 4408 procedures for message header fields", draft-klyne-msghdr- 4409 registry-07.txt. 4411 [NNTP] S. Barber, "Network News Transport Protocol", draft-ietf- 4412 nntpext-base-*.txt. 4414 [PGPVERIFY] David Lawrence, 4415 . 4417 [RFC 1034] P. Mockapetris, "Domain Names - Concepts and Facilities", 4418 RFC 1034, November 1987. 4420 [RFC 1036] M. Horton and R. Adams, "Standard for Interchange of 4421 USENET Messages", RFC 1036, December 1987. 4423 [RFC 1864] J. Myers and M. Rose, "The Content-MD5 Header Field", RFC 4424 1864, October 1995. 4426 [RFC 2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4427 Extensions (MIME) Part One: Format of Internet Message Bodies", 4428 RFC 2045, November 1996. 4430 [RFC 2046] N. Freed and N. Borenstein, "Multipurpose Internet Mail 4431 Extensions (MIME) Part Two: Media Types", RFC 2046, November 4432 1996. 4434 [RFC 2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 4435 Part Three: Message Header Extensions for Non-ASCII Text", RFC 4436 2047, November 1996. 4438 [RFC 2048] N. Freed, J. Klensin, and J. Postel, "Multipurpose 4439 Internet Mail Extensions (MIME) Part Four: Registration 4440 Procedures", RFC 2048, November 1996. 4442 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 4443 Requirement Levels", RFC 2119, March 1997. 4445 [RFC 2142] D. Crocker, "Mailbox Names for Common Services, Roles and 4446 Functions", RFC 2142, May 1997. 4448 [RFC 2156] S. Kille, "MIXER (Mime Internet X.400 Enhanced Relay): 4449 Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. 4451 [RFC 2183] R. Troost, S. Dorner, and K.Moore, "Communicating 4452 Presentation Information in Internet Messages: The Content- 4453 Disposition Header Field", RFC 2183, August 1997. 4455 [RFC 2231] N. Freed and K. Moore, "MIME Parameter Value and Encoded 4456 Word Extensions: Character Sets, Languages, and Continuations", 4457 RFC 2231, November 1997. 4459 [RFC 2234] D. Crocker and P. Overell, "Augmented BNF for Syntax 4460 Specifications: ABNF", RFC 2234, November 1997. 4462 [RFC 2298] R. Fajman, "An Extensible Message Format for Message 4463 Disposition Notifications", RFC 2298, March 1998. 4465 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 4466 Architecture", RFC 2373, July 1998. 4468 [RFC 2557] J. Palme, A. Hopmann, and N. Shelness, "MIME Encapsulation 4469 of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 4470 1999. 4472 [RFC 2606] D. Eastlake and A. Panitz, "Reserved Top Level DNS Names", 4473 RFC 2606, June 1999. 4475 [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 4476 P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- 4477 HTTP/1.1", RFC 2616, June 1999. 4479 [RFC 2822] P. Resnick, "Internet Message Format", RFC 2822, April 4480 2001. 4482 [RFC 2978] N. Freed and J. Postel, "IANA Charset Registration 4483 Procedures", RFC 2978, October 2000. 4485 [RFC 3066] H. Alvestrand, "Tags for the Identification of Languages", 4486 RFC 3066, January 2001. 4488 [RFC 3156] M. Elkins, D. Del Torto, R. Levien, and T. Roessler, "MIME 4489 Security with OpenPGP", RFC 3156, August 2001. 4491 [RFC 3282] H. Alvestrand, "Content Language Headers", RFC 3282, May 4492 2002. 4494 [RFC 822] D. Crocker, "Standard for the Format of ARPA Internet Text 4495 Messages.", STD 11, RFC 822, August 1982. 4497 [RFC 850] Mark R. Horton, "Standard for interchange of Usenet 4498 messages", RFC 850, June 1983. 4500 [RFC 976] Mark R. Horton, "UUCP mail interchange format standard", 4501 RFC 976, February 1986. 4503 [RFC Errata] RFC Editor, "RFC Errata", . 4506 [Son-of-1036] Henry Spencer, "News article format and transmission", 4507 , June 1994. 4509 [UNICODE 3.0] The Unicode Consortium, "The Unicode Standard - Version 4510 3.0", Addison-Wesley, 2000. 4512 [UNICODE 3.1] The Unicode Consortium, "The Unicode Standard - Version 4513 3.1, being an amendment to [UNICODE 3.0]", Unicode Standard 4514 Annex #27 , 2001. 4516 [UNICODE 3.2] The Unicode Consortium, "The Unicode Standard - Version 4517 3.2, being an amendment to [UNICODE 3.1]", Unicode Standard 4518 Annex #28 , 2002. 4520 [USEAGE] Draft in preparation. 4522 [USEFOR] This Standard. 4524 12. Acknowledgements 4526 The editor wishes to thank the following members of the IETF Usenet 4527 Format Working Group who made significant contributions to this 4528 endeavour (however, inclusion in this list does not imply that a 4529 person approves of everything contained herein). 4531 Per Abrahamsen Brian Kelly 4532 Peter Alfredsen Evan Kirshenbaum 4533 Russ Allbery Brad Knowles 4534 Greg Andruk Kent Landfield 4535 Ralph Babel David C. Lawrence 4536 Stan Barber Bruce Lilly 4537 Dave Barr Simon Lyall 4538 Ian Bell Todd Michel McComb 4539 G. James Berigan Denis McKeon 4540 Terje Bless Seymour J. Metz 4541 Seth Breidbart John Moreno 4542 Buddha Buck Chris Newman 4543 Forrest J. Cavalier III Dirk Nimmich 4544 Evan Champion Paul Overell 4545 Maurizio Codogno Jacob Palme 4546 Don Croyle Brian Palmer 4547 Matt Curtin Pete Resnick 4548 Bill Davidsen Jon Ribbens 4549 Ian Davis Dan Ritter 4550 Jean-Marc Desperrier Thomas Roessler 4551 Martin J. Duerst Doug Royer 4552 Claus Andre Faerber Frederic Senis 4553 Clive D.W. Feather Erland Sommarskog 4554 David Formosa Henry Spencer 4555 Marty Fouts John Stanley 4556 Benjamin Franz Brad Templeton 4557 Andrew Gierth Florian Weimer 4558 Jonathan Grobe Curt Welch 4559 Thomas Gschwind Curtis Whalen 4560 Kai Henningsen Leonid Yegoshin 4561 Lars Magne Ingebrigtsen Jamie Zawinski 4563 13. Contact Address 4565 Editor 4567 Charles. H. Lindsey 4568 5 Clerewood Avenue 4569 Heald Green 4570 Cheadle 4571 Cheshire SK8 3JU 4572 United Kingdom 4573 Phone: +44 161 436 6131 4574 Email: chl@clw.cs.man.ac.uk 4576 [ 4578 Working group chairs 4580 Andrew Gierth 4581 Pete Resnick 4582 ] 4584 Comments on this draft should preferably be sent to the mailing list 4585 of the Usenet Format Working Group at 4587 usenet-format@landfield.com. 4589 This draft expires six months after the date of publication (see Page 4590 1) (i.e. in November 2004). 4592 Appendix A.1 - A-News Article Format 4594 The obsolete "A News" article format consisted of exactly five lines 4595 of header information, followed by the body. For example: 4597 Aeagle.642 4598 news.misc 4599 cbosgd!mhuxj!mhuxt!eagle!jerry 4600 Fri Nov 19 16:14:55 1982 4601 Usenet Etiquette - Please Read 4602 body 4603 body 4604 body 4606 The first line consisted of an "A" followed by an article ID 4607 (analogous to a message identifier and used for similar purposes). 4608 The second line was the list of newsgroups. The third line was the 4609 path. The fourth was the date, in the format above (all fields fixed 4610 width), resembling an Internet date but not quite the same. The fifth 4611 was the subject. 4613 This format is documented for archeological purposes only. Articles 4614 MUST NOT be generated in this format. 4616 Appendix A.2 - Early B-News Article Format 4618 The obsolete pseudo-Internet article format, used briefly during the 4619 transition between the A News format and the modern format, followed 4620 the general outline of a MAIL message but with some non-standard 4621 headers. For example: 4623 From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz) 4624 Newsgroups: news.misc 4625 Title: Usenet Etiquette -- Please Read 4626 Article-I.D.: eagle.642 4627 Posted: Fri Nov 19 16:14:55 1982 4628 Received: Fri Nov 19 16:59:30 1982 4629 Expires: Mon Jan 1 00:00:00 1990 4631 body 4632 body 4633 body 4635 The From-header contained the information now found in the Path- 4636 header, plus possibly the full name now typically found in the From- 4637 header. The Title-header contained what is now the Subject-content. 4638 The Posted-header contained what is now the Date-content. The 4639 Article-I.D.-header contained an article ID, analogous to a message 4640 identifier and used for similar purposes. The Newsgroups- and 4641 Expires-headers were approximately as now. The Received-header 4642 contained the date when the latest relaying agent to process the 4643 article first saw it. All dates were in the above format, with all 4644 fields fixed width, resembling an Internet date but not quite the 4645 same. 4647 This format is documented for archeological purposes only. Articles 4648 MUST NOT be generated in this format. 4650 Appendix A.3 - Obsolete Headers 4652 Early versions of news software following the modern format sometimes 4653 generated headers like the following: 4655 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP 4656 Posting-Version: version B 2.10 2/13/83; site eagle.UUCP 4657 Date-Received: Friday, 19-Nov-82 16:59:30 EST 4659 Relay-Version contained version information about the relaying agent 4660 that last processed the article. Posting-Version contained version 4661 information about the posting agent that posted the article. Date- 4662 Received contained the date when the last relaying agent to process 4663 the article first saw it (in a slightly nonstandard format). 4665 In addition, this present standard obsoletes certain headers defined 4666 in [Son-of-1036] (see 6.22): 4668 Also-Control: cancel <9urrt98y53@site.example> 4669 See-Also: 4670 Article-Names: comp.foo:charter 4671 Article-Updates: 4673 Also-Control indicated a control message that was also intended to be 4674 filed as a normal article. See-Also listed related articles, but 4675 without the specific relationship with followups that pertains to the 4676 References-header. Article-Names indicated some special significance 4677 of that article in relation to the indicated newsgroup. Article- 4678 Updates indicated that an earlier article was updated, without at the 4679 same time being superseded. 4681 These headers are documented for archeological purposes only. 4682 Articles containing these headers MUST NOT be generated. 4684 Appendix A.4 - Obsolete Control Messages 4686 This present standard obsoletes certain control messages defined in 4687 [RFC 1036] (see 7.5), all of which had the effect of requesting a 4688 description of a relaying or serving agent's software, or its peering 4689 arrangements with neighbouring sites, to be emailed to the article's 4690 reply address. Whilst of some utility when Usenet was much smaller 4691 than it is now, they had become no more than a tool for the malicious 4692 sending of mailbombs. Moreover, many organizations now consider 4693 information about their internal connectivity to be confidential. 4695 version 4696 sendsys 4697 whogets 4698 senduuname 4700 "Version" requested details of the transport software in use at a 4701 site. "Sendsys" requested the full list of newsgroups taken, and the 4702 peering arrangements. "Who gets" was similar, but restricted to a 4703 named newsgroup. "Senduuname" resembled "sendsys" but restricted to 4704 the list of peers connected by UUCP. 4706 Historically, a checkgroups body consisting of one or two lines, the 4707 first of the form "-n newsgroup", caused check-groups to apply to 4708 only that single newsgroup. 4710 Historically, an article posted to a newsgroup whose name had exactly 4711 three components of which the third was "ctl" signified that article 4712 was to be taken as a control message. The Subject-header specified 4713 the actions, in the same way the Control-header does now. 4715 These forms are documented for archeological purposes only; they MUST 4716 NO LONGER be used. 4718 Appendix B - Collected Syntax 4720 Appendix B.1 - Characters, Atoms and Folding 4722 In the following syntactic rules, numbers in the left hand margin 4723 indicate rules taken from other documents, specifically: 4724 1 from [RFC 2231] having regard to errata contained in [RFC 4725 Errata]; 4726 2 from [RFC 2822] with the exception of those elements described 4727 therein as "obsolete"; 4728 3 from [RFC 2373]; 4729 4 from [RFC 2234]; 4730 5 from [RFC 2045]. 4732 Where the number is followed by an asterisk ('*'), it indicates that 4733 the rule in question has been modified for the purposes of this 4734 standard. 4736 4 ALPHA = %x41-5A / ; A-Z 4737 %x61-7A ; a-z 4738 2 CFWS = *([FWS] comment) ( ([FWS] comment) / FWS ) 4739 4 CR = %x0D ; carriage return 4740 4 CRLF = CR LF 4741 4 DIGIT = %x30-39 ; 0-9 4742 4 DQUOTE = %d34 ; quote mark 4743 2 FWS = ([*WSP CRLF] 1*WSP); folding whitespace 4744 4 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 4745 4 HTAB = %x09 ; horizontal tab 4746 4 LF = %x0A ; line feed 4747 2 NO-WS-CTL = %d1-8 / ; US-ASCII control characters 4748 %d11 / ; which do not include the 4749 %d12 / ; carriage return, line feed, 4750 %d14-31 / ; and whitespace characters 4751 %d127 4752 4 SP = %x20 ; space 4753 4 WSP = SP / HTAB ; whitespace characters 4754 2 atext = ALPHA / DIGIT / 4755 "!" / "#" / ; Any character except 4756 "$" / "%" / ; controls, SP, and specials. 4757 "&" / "'" / ; Used for atoms 4758 "*" / "+" / 4759 "-" / "/" / 4760 "=" / "?" / 4761 "^" / "_" / 4762 "`" / "{" / 4763 "|" / "}" / 4764 "~" 4765 2 atom = [CFWS] 1*atext [CFWS] 4766 2* ccontent = ctext / quoted-pair / comment / encoded-word 4767 charset = 4768 ; [RFC 2978] 4769 2 comment = "(" *([FWS] ccontent) [FWS] ")" 4770 2 ctext = NO-WS-CTL / ; all of except 4771 %d33-39 / ; SP, HTAB, "(", ")" 4772 %d42-91 / ; and "\" 4773 %d93-126 4774 1 encoded-word = "=?" charset ["*" language] "?" encoding 4775 "?" encoded-text "?=" 4776 2 dcontent = dtext / quoted-pair 4777 2 dot-atom = [CFWS] dot-atom-text [CFWS] 4778 2 dot-atom-text = 1*atext *( "." 1*atext ) 4779 2 dtext = NO-WS-CTL / ; Non white space controls 4780 %d33-90 / ; The rest of the US-ASCII 4781 %d94-126 ; characters not including 4782 ; "[", "]", or " 4783 extended-phrase = ( [CFWS] encoded-word [CFWS] / word ) 4784 *( [CFWS] encoded-word [CFWS] / word / 4785 [CFWS] "." [CFWS] ) 4786 language = 4787 ; [RFC 3066] 4788 2* phrase = 1*( [CFWS] encoded-word [CFWS] / word ) / 4789 extended-phrase 4790 2 qcontent = qtext / quoted-pair 4791 2 qtext = NO-WS-CTL / ; all of except 4792 %d33 / ; SP, HTAB, "\" and DQUOTE 4793 %d35-91 / 4794 %d93-126 4795 2 quoted-pair = "\" text 4796 2 quoted-string = [CFWS] DQUOTE 4797 *( [FWS] qcontent ) [FWS] 4798 DQUOTE [CFWS] 4799 2 specials = "(" / ")" / ; Special characters used in 4800 "<" / ">" / ; other parts of the syntax 4801 "[" / "]" / 4802 ":" / ";" / 4803 "@" / "\" / 4804 "," / "." / 4805 DQUOTE 4806 2 text = %d1-9 / ; all US-ASCII characters except 4807 %d11-12 / ; NUL, CR and LF 4808 %d14-127 4809 5 tspecials = "(" / ")" / "<" / ">" / "@" / 4810 "," / ";" / ":" / "\" / DQUOTE / 4811 "/" / "[" / "]" / "?" / "=" 4812 2* unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS] 4813 2 utext = NO-WS-CTL / ; Non white space controls 4814 %d33-126 ; The rest of US-ASCII 4815 2 word = atom / quoted-string 4816 Appendix B.2 - Basic Forms 4818 2 addr-spec = local-part "@" domain 4819 2 address = mailbox / group 4820 2 address-list = address *( "," address ) 4821 2 angle-addr = [CFWS] "<" addr-spec ">" [CFWS] 4822 article = 1*( header CRLF ) separator body 4823 1 attribute = 1*attribute-char 4824 1 attribute-char = 4826 body = *( *998text CRLF ) 4827 2 display-name = phrase 4828 2 date = day month year 4829 2 date-time = [ day-of-week "," ] date FWS time [CFWS] 4830 2 day = [FWS] 1*2DIGIT 4831 2 day-name = "Mon" / "Tue" / "Wed" / "Thu" / 4832 "Fri" / "Sat" / "Sun" 4833 2 day-of-week = [FWS] day-name 4834 2 domain = dot-atom / domain-literal 4835 2 domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] 4836 1 extended-initial-name 4837 = attribute [initial-section] "*" 4838 1 extended-initial-value 4839 = [charset] "'" [language] "'" 4840 extended-other-values 4841 1 extended-other-names = attribute other-sections "*" 4842 1* extended-other-values= *( "%" 2HEXDIG / attribute-char ) 4843 1* extended-parameter = ( [CFWS] extended-initial-name [CFWS] 4844 "=" extended-initial-value ) / 4845 ( [CFWS] extended-other-names [CFWS] 4846 "=" extended-other-values ) 4847 extension-parameter = 4848 2 group = display-name ":" [ mailbox-list / CFWS ] ";" 4849 [CFWS] 4850 header-name = 1*name-character *( "-" 1*name-character ) 4851 2 hour = 2DIGIT 4852 1 initial-section = "*0" 4853 2 local-part = dot-atom / quoted-string 4854 2 mailbox = name-addr / addr-spec 4855 2 mailbox-list = mailbox *( "," mailbox ) 4856 2 minute = 2DIGIT 4857 2 month = FWS month-name FWS 4858 2 month-name = "Jan" / "Feb" / "Mar" / "Apr" / 4859 "May" / "Jun" / "Jul" / "Aug" / 4860 "Sep" / "Oct" / "Nov" / "Dec" 4861 2 name-addr = [display-name] angle-addr 4862 name-character = ALPHA / DIGIT 4863 other-header = header-name ":" 1*SP other-content 4864 other-content = 4866 other-section = "*" ("1" / "2" / "3" / "4" / "5" / 4867 "6" / "7" / "8" / "9") *DIGIT 4868 1 parameter = regular-parameter / extended-parameter 4869 1* regular-parameter = [CFWS] regular-parameter-name [CFWS] 4870 "=" value 4871 1 regular-parameter-name 4872 = attribute [section] 4873 2 second = 2DIGIT 4874 1 section = initial-section / other-section 4875 separator = CRLF 4876 2 time = time-of-day FWS zone 4877 2 time-of-day = hour ":" minute [ ":" second ] 4878 5 token = 1* 4880 5 value = [CFWS] token [CFWS] / quoted-string 4881 x-attribute = "x-" attribute 4882 2 year = 4*DIGIT 4883 2* zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" 4885 Appendix B.3 - Headers 4887 Appendix B.3.1 - Header outlines 4889 header = other-header / 4890 Date-header / 4891 From-header / 4892 Message-ID-header / 4893 Subject-header / 4894 Newsgroups-header / 4895 Path-header / 4896 Injection-Date-header / 4897 Reply-To-header / 4898 Sender-header / 4899 Organization-header / 4900 Keywords-header / 4901 Summary-header / 4902 Distribution-header / 4903 Followup-To-header / 4904 Mail-Copies-To-header / 4905 Posted-And-Mailed-header / 4906 References-header / 4907 Expires-header / 4908 Archive-header / 4909 Control-header / 4910 Approved-header / 4911 Supersedes-header / 4912 Xref-header / 4913 Lines-header / 4914 User-Agent-header / 4915 Injection-Info-header / 4916 Complaints-To-header 4918 Approved-content = From-content 4919 Approved-header = "Approved" ":" SP Approved-content 4920 *( ";" extension-parameter ) 4921 Archive-content = [CFWS] ("no" / "yes" ) [CFWS] 4922 Archive-header = "Archive" ":" SP Archive-content 4923 *( ";" ( Archive-parameter / 4924 extension-parameter ) ) 4925 Archive-parameter = 4927 Complaints-To-content= address-list 4928 Complaints-To-header = "Complaints-To" ":" SP Complaints-To-content 4929 Control-content = [CFWS] control-message [CFWS] 4930 Control-header = "Control" ":" SP Control-content 4931 *( ";" extension-parameter ) 4932 Date-content = date-time 4933 Date-header = "Date" ":" SP Date-content 4934 Distribution-content = distribution *( dist-delim distribution ) 4935 Distribution-header = "Distribution" ":" SP Distribution-content 4936 *( ";" extension-parameter ) 4937 Expires-content = date-time 4938 Expires-header = "Expires" ":" SP Expires-content 4939 *( ";" extension-parameter ) 4940 Followup-To-content = Newsgroups-content / 4941 [FWS] %x70.6F.73.74.65.72 [FWS] 4942 ; which is a case-sensitive "poster" 4943 Followup-To-header = "Followup-To" ":" SP Followup-To-content 4944 *( ";" extension-parameter ) 4945 From-content = mailbox-list 4946 From-header = "From" ":" SP From-content 4947 Injection-Date-content 4948 = date-time 4949 Injection-Date-header 4950 = "Injection-Date" ":" SP Injection-Date-content 4951 *( ";" extension-parameter ) 4952 Injection-Info-content 4953 = [CFWS] path-identity [CFWS] 4954 Injection-Info-header= "Injection-Info" ":" SP Injection-Info-content 4955 *( ";" ( Injection-Info-parameter / 4956 extension-parameter ) ) 4957 Injection-Info-parameter 4958 = posting-host-parameter / 4959 posting-account-parameter / 4960 posting-sender-parameter / 4961 posting-logging-parameter 4962 Keywords-content = phrase *( "," phrase ) 4963 Keywords-header = "Keywords" ":" SP Keywords-content 4964 Lines-content = [CFWS] 1*DIGIT [CFWS] 4965 Lines-header = "Lines" ":" SP Lines-content 4966 *( ";" extension-parameter ) 4967 Mail-Copies-To-content 4968 = copy-addr / [CFWS] ( "nobody" / 4969 "poster" ) [CFWS] 4970 Mail-Copies-To-header= "Mail-Copies-To" ":" SP Mail-Copies-To-content 4971 Message-ID-content = [FWS] msg-id [FWS] 4972 Message-ID-header = "Message-ID" ":" SP Message-ID-content 4973 Newsgroups-content = [FWS] newsgroup-name 4974 *( [FWS] ng-delim [FWS] newsgroup-name ) 4975 [FWS] 4977 Newsgroups-header = "Newsgroups" ":" SP Newsgroups-content 4978 *( ";" extension-parameter ) 4979 Organization-content = unstructured 4980 Organization-header = "Organization" ":" SP Organization-content 4981 Path-content = [FWS] *( path-identity [FWS] 4982 path-delimiter [FWS] 4983 ) tail-entry [FWS] 4984 Path-header = "Path" ":" SP Path-content 4985 *( ";" extension-parameter ) 4986 Posted-And-Mailed-content 4987 = [CFWS] ( "yes" / "no" ) [CFWS] 4988 Posted-And-Mailed-header 4989 = "Posted-And-Mailed" ":" SP 4990 Posted-And-Mailed-content 4991 *( ";" extension-parameter ) 4992 References-content = [CFWS] msg-id *( CFWS msg-id ) [CFWS] 4993 References-header = "References" ":" SP References-content 4994 Reply-To-content = address-list 4995 Reply-To-header = "Reply-To" ":" SP Reply-To-content 4996 Sender-content = mailbox 4997 Sender-header = "Sender" ":" SP Sender-content 4998 Subject-content = unstructured 4999 Subject-header = "Subject" ":" SP Subject-content 5000 Summary-content = unstructured 5001 Summary-header = "Summary" ":" SP Summary-content 5002 Supersedes-content = [CFWS] msg-id [CFWS] 5003 Supersedes-header = "Supersedes" ":" SP Supersedes-content 5004 User-Agent-content = product *( CFWS product ) 5005 User-Agent-header = "User-Agent" ":" SP User-Agent-content 5006 *( ";" extension-parameter ) 5007 Xref-content = [CFWS] server-name 1*( CFWS location ) [CFWS] 5008 Xref-header = "Xref" ":" SP Xref-content 5009 *( ";" extension-parameter ) 5011 Appendix B.3.2 - Control-message outlines 5013 control-message = / 5014 Newgroup-message / 5015 Rmgroup-message / 5016 Mvgroup-message / 5017 Checkgroup-message / 5018 Cancel-message / 5019 Ihave-message / 5020 Sendme-message 5022 Cancel-arguments = CFWS msg-id [CFWS] 5023 Cancel-message = "cancel" Cancel-arguments 5024 Checkgroup-arguments = [ chkscope ] [ chksernr ] 5025 Checkgroup-message = "checkgroups" Checkgroup-arguments 5026 Ihave-arguments = relayer-name 5027 Ihave-message = "ihave" Ihave-arguments 5028 Mvgroup-arguments = CFWS newsgroup-name CFWS newsgroup-name 5029 [ CFWS newgroup-flag ] 5030 Mvgroup-message = "mvgroup" Mvgroup-arguments 5031 Newgroup-arguments = CFWS newsgroup-name [ CFWS newgroup-flag ] 5032 Newgroup-message = "newgroup" Newgroup-arguments 5033 Rmgroup-arguments = CFWS newsgroup-name 5034 Rmgroup-message = "rmgroup" Rmgroup-arguments 5035 Sendme-arguments = Ihave-arguments 5036 Sendme-message = "sendme" Sendme-arguments 5038 Appendix B.3.3 - Other header rules 5040 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 5041 ; US-ASCII printable characters 5042 ; except'(' and ';' 5043 article-size = 1*DIGIT 5044 batch = 1*( batch-header article ) 5045 batch-header = "#!" SP rnews SP article-size CRLF 5046 checkgroups-body = *( valid-group CRLF ) 5047 chkscope = 1*( CFWS ["!"] newsgroup-name ) 5048 chksernr = CFWS "#" 1*DIGIT 5049 component = 1*component-grapheme 5050 component-grapheme = DIGIT / ALPHA / "+" / "-" / "_" 5051 copy-addr = address-list 5052 dist-delim = "," 5053 distribution = [FWS] distribution-name [FWS] 5054 distribution-name = ALPHA 1*distribution-rest 5055 distribution-rest = ALPHA / "+" / "-" / "_" 5056 groupinfo-body = [ newsgroups-tag CRLF ] 5057 newsgroups-line CRLF 5058 3 hex4 = 1*4HEXDIG 5059 3 hexpart = hexseq / hexseq "::" [ hexseq ] / 5060 "::" [ hexseq ] 5061 3 hexseq = hex4 *( ":" hex4 ) 5062 host-value = dot-atom / 5063 [ dot-atom ":" ] 5064 ( IPv4address / IPv6address ) 5065 ; see [RFC 2373] 5066 2 id-left = dot-atom-text / no-fold-quote 5067 2 id-right = dot-atom-text / no-fold-literal 5068 ihave-body = *( msg-id CRLF ) 5069 3 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 5070 1*3DIGIT "." 1*3DIGIT 5071 3 IPv6address = hexpart [ ":" IPv4address ] 5072 location = newsgroup-name ":" article-locator 5073 mdtext = NO-WS-CTL / ; Non white space controls 5074 %d33-61 / ; The rest of the US-ASCII 5075 %d63-90 / ; characters not including 5076 %d94-126 ; ">", "[", "]", or "\" 5077 moderation-flag = %x28.4D.6F.64.65.72.61.74.65.64.29 5078 ; case sensitive "(Moderated)" 5080 mqspecial = "(" / ")" / ; same as specials except 5081 "<" / ; "\" and DQUOTE quoted 5082 "[" / "]" / ; and ">" omitted 5083 ":" / ";" / 5084 "@" / "\\" / 5085 "," / "." / 5086 "\" DQUOTE 5087 mqtext = NO-WS-CTL / ; all of except 5088 %d33 / ; SP, HTAB, "\", ">" 5089 %d35-61 / ; and DQUOTE 5090 %d63-91 / 5091 %d93-126 5092 2* msg-id = "<" id-left "@" id-right ">" 5093 newgroup-flag = "moderated" 5094 newsgroup-description 5095 = utext *( *WSP utext ) 5096 newsgroup-name = component *( "." component ) 5097 newsgroups-line = newsgroup-name 5098 [ 1*HTAB newsgroup-description ] 5099 [ 1*WSP moderation-flag ] 5100 newsgroups-tag = %x46.6F.72 SP %x79.6F.75.72 SP 5101 %x6E.65.77.73.67.72.6F.75.70.73 SP 5102 %x66.69.6C.65.3A 5103 ; case sensitive 5104 ; "For your newsgroups file:" 5105 ng-delim = "," 5106 2* no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 5107 2* no-fold-quote = DQUOTE 5108 *( mqtext / "\\" / "\" DQUOTE ) 5109 mqspecial 5110 *( mqtext / "\\" / "\" DQUOTE ) 5111 DQUOTE 5112 path-delimiter = "/" / "?" / "%" / "," / "!" 5113 path-identity = ( ALPHA / DIGIT ) 5114 *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 5115 posting-account-parameter 5116 = 5118 posting-host-parameter 5119 = 5121 posting-logging-parameter 5122 = 5124 posting-sender-parameter 5125 = 5127 product = [CFWS] token [CFWS] [ "/" product-version ] 5128 product-version = [CFWS] token [CFWS] 5129 relayer-name = path-identity 5130 rnews = %x72.6E.65.77.73 ; case sensitive "rnews" 5131 sender-value = mailbox / "verified" 5132 sendme-body = ihave-body 5133 server-name = path-identity 5134 tail-entry = path-identity 5135 valid-group = newsgroups-line 5137 Appendix C - Notices 5139 Intellectual Property 5141 The IETF takes no position regarding the validity or scope of any 5142 intellectual property or other rights that might be claimed to 5143 pertain to the implementation or use of the technology described in 5144 this document or the extent to which any license under such rights 5145 might or might not be available; neither does it represent that it 5146 has made any effort to identify any such rights. Information on the 5147 IETF's procedures with respect to rights in standards-track and 5148 standards-related documentation can be found in BCP-11. Copies of 5149 claims of rights made available for publication and any assurances of 5150 licenses to be made available, or the result of an attempt made to 5151 obtain a general license or permission for the use of such 5152 proprietary rights by implementors or users of this specification can 5153 be obtained from the IETF Secretariat. 5155 The IETF invites any interested party to bring to its attention any 5156 copyrights, patents or patent applications, or other proprietary 5157 rights which may cover technology that may be required to practice 5158 this standard. Please address the information to the IETF Executive 5159 Director. 5161 Full Copyright Statement 5163 Copyright (C) The Internet Society (2003). All Rights Reserved 5165 This document and translations of it may be copied and furnished to 5166 others, and derivative works that comment on or otherwise explain it 5167 or assist in its implementation may be prepared, copied, published 5168 and distributed, in whole or in part, without restriction of any 5169 kind, provided that the above copyright notice and this paragraph are 5170 included on all such copies and derivative works. However, this 5171 document itself may not be modified in any way, such as by removing 5172 the copyright notice or references to the Internet Society or other 5173 Internet organizations, except as needed for the purpose of 5174 developing Internet standards in which case the procedures for 5175 copyrights defined in the Internet Standards process must be 5176 followed, or as required to translate it into languages other than 5177 English. 5179 The limited permissions granted above are perpetual and will not be 5180 revoked by the Internet Society or its successors or assigns. 5182 This document and the information contained herein is provided on an 5183 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5184 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5185 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5186 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5187 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.