idnits 2.17.1 draft-ietf-usefor-usefor-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1926. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([FWS], [Son-of-1036]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 28, 2006) is 6451 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: 'FWS' is mentioned on line 1792, but not defined == Missing Reference: 'CFWS' is mentioned on line 1187, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Errata' ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-14) exists of draft-ietf-usefor-usepro-05 -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 850 (Obsoleted by RFC 1036) -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Usenet Format Working Group K. Murchison, Ed. 3 Internet-Draft Carnegie Mellon University 4 Obsoletes: 1036 (if approved) C. Lindsey 5 Intended status: Standards Track University of Manchester 6 Expires: March 1, 2007 D. Kohn 7 FlyDash, Inc. 8 August 28, 2006 10 Netnews Article Format 11 draft-ietf-usefor-usefor-09 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 1, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document specifies the syntax of Netnews articles in the context 45 of the "Internet Message Format" (RFC 2822) and "Multipurpose 46 Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes 47 RFC 1036, providing an updated specification to reflect current 48 practice and incorporating incremental changes specified in other 49 documents. 51 Note to RFC Editor 53 Please remove all of the "Changes since ..." sections before 54 publication. 56 Changes since draft-ietf-usefor-usefor-08 58 o Removed "Issues to be addressed" section. 60 o Header fields are now listed and described in alphabetical order 61 (as suggested by Richard Clayton). 63 o Consistently use "Netnews article(s)" throughout document. 65 o Clarified that the 998 octet limit is for header field lines, not 66 the entire header field. 68 o Added to ABNF imports. 70 o Added header fields specified in RFC 850 and RFC 2980 to IANA 71 section. Also rewrote Obsolete Header Fields section to reference 72 RFC 850 and RFC 2980 instead of listing and describing obsolete 73 header fields (ticket #1156). 75 o Added definitions for "generate" and "accept" (ticket #1299). 77 o Added note explaining in Path header field 78 (ticket #1305). 80 o Noted that agents MUST NOT (rather than SHOULD NOT) alter the Date 81 header field when adding an Injection-Date header field (ticket 82 #1306). 84 o Replaced reference to ISO3166 with ISO3166-1. Also refined 85 description of "world" and "local" in Distribution header field. 86 (ticket #1309) 88 o Removed restriction on mailbox-list in Approved header field 89 (ticket #1310). 91 o Refined discussion of Archive header field body (ticket #1311). 93 o Changed definition of Line count to number of CRLF in 94 (ticket #1312). 96 o Changed wording in Header Fields section 2.2 to discuss only 97 headers, not entire messages (ticket #1313). 99 o Reworded text regarding use of special chars in newsgroups names 100 (ticket #1314). 102 o Removed analogy to RFC 2822 article from "poster" definition 103 (ticket #1315). 105 o Reworded the purpose of Injection-Date header field (ticket 106 #1335). 108 o Reworded the description of Expires header field (ticket #1336). 110 o Clarified to which Email addresses followups to "poster" are sent. 112 o Numerous editorial changes from Ralph Babel, Richard Clayton, and 113 Charles Lindsey. 115 Changes since draft-ietf-usefor-usefor-07 117 o Reworked ABNF for Path header field keywords (ticket #1047). 119 o Removed definition of "sender" in Injection-Info header field 120 (ticket #1159). 122 o Reworded description of "posting-account" in Injection-Info header 123 field (ticket #1159). 125 o Discussed the use of [FWS] in Newsgroups, Followup-To, and 126 Distribution header fields (ticket #1178). 128 o Further clarification of *WSP vs. [FWS] in Section 2.2 (ticket 129 #1179). 131 o Miscellaneous editorial changes from Dan Kohn. 133 Changes since draft-ietf-usefor-usefor-06 135 o Reworked ABNF for Path header field delimiters and components 136 (ticket #1047). 138 o Imported ABNF elements from reference docs (ticket #1155). 140 o Added IANA registration for header fields per RFC 3864 (ticket 141 #1156). 143 o New ABNF for Control header field (ticket #1157). 145 o Better ABNF for (ticket #1158). 147 o Added new definitions and advice on sender vs. posting-account in 148 Injection-Info header field (ticket #1159). 150 o New ABNF for Archive and Injection-Info header fields, including 151 note regarding CFWS and (ticket #1177). 153 o Replaced leading/trailing [FWS] with *WSP in header field ANBF 154 (ticket #1179). 156 o Using RFC 4234 as a reference instead of RFC 2234. 158 o Removed reference to RFC 0977 -- using only 159 draft-ietf-nntpext-base. 161 o Added note about Expires being defined by RFC 2156. 163 o Miscellaneous editorial changes. 165 Changes since draft-ietf-usefor-usefor-05 167 o Finalized ABNF for (ticket #1003). 169 o Further cleanup of description for Newsgroups header field (ticket 170 #1021). 172 o Fixed ABNF for (ticket #1028). 174 o Began adding text for differences from RFC 1036 (ticket #1032). 176 o Added text regarding hard-to-parse MIME boundaries (ticket #1046). 178 o Reworked/redefined Path header field delimiters and components 179 (ticket #1047). 181 o Added more differences from RFC 2822 (ticket #1052). 183 o Added text for relationship to RFC 2822 (ticket #1053). 185 o Listed header fields which don't permit CFWS (ticket #1079). 187 o Applied text from ticket #1080 (Injection-Info MIME params). 189 o Added more text Approved header field semantics (ticket #1082). 191 o Added text regarding Injection-Date being mandatory/optional 192 (ticket #1088). 194 o Reworked definitions of "agents", etc (ticket #1102). 196 o Removed RFC 2821 as a normative reference. 198 o Miscellaneous editorial changes. 200 Changes since draft-ietf-usefor-usefor-04 202 o Updated to newer references (ticket #1002). 204 o Cleaned up ABNF for (ticket #1003). 206 o Deprecated X- headers (ticket #1004). 208 o Clarified relationship between followups and References header 209 field (ticket #1008). 211 o Cleaned up ABNF and description for Newsgroups header field 212 (ticket #1021). 214 o Tweaked language regarding the use of (ticket #1022). 216 o Tweaked language regarding GMT timezone and Date header field 217 (ticket #1028). 219 o Added language warning against folding Newsgroups header field 220 (ticket #1042). 222 o Use RFC 2822 term "header field" instead of "header" (ticket 223 #1043). 225 o Starting adding differences from RFC 2822 (ticket #1052). 227 o Miscellaneous editorial changes. 229 Changes since draft-ietf-usefor-usefor-03 231 o Reworked ABNFs of several headers. 233 o Used Charles' ABNF for . 235 o Disallowed comments in Supersedes header. 237 o Disallowed comments in Xref header. 239 o Disallowed comments in Message-Id header. 241 o CFWS between msg-ids in References header is not optional. 243 o Compatibility changes based on comments from Charles. 245 o Miscellaneous editorial changes. 247 Changes since draft-ietf-usefor-usefor-02 249 o Changed to RFC 3978 boilerplate (xml2rfc v1.29) 251 o Changed "network news" to "Netnews" throughout. 253 o Prohibit NO-WS-CTL in msg-id. 255 o Complaints-To header is now an Injection-Info parameter. 257 o Added descriptions of Injection-Info parameters. 259 o Removed "filename" parameter from Archive header. 261 o Added CFWS to User-Agent header. 263 o Miscellaneous editorial changes. 265 Changes since draft-ietf-usefor-usefor-01 267 o Removed half-hearted discussion of internal format and 8-bit clean 268 transport. 270 o Added definitions of "proto-article", "posting agent", "followup", 271 "followup-agent", "user-agent", and "injecting agent". 273 o Removed discussion of message/partial MIME messages. 275 o Noted that the header contents in every line MUST NOT be empty. 277 o Merged MIME sections. 279 o Only allow "UT" and "GMT" in Date header; disallow all other . 282 o Used Charles' ABNF for and . 284 o Removed restrictions on length and start character for Newsgroups. 286 o More verbose description of Path header. 288 o Disallowed comments in Control header. 290 o Specified that is a verb optionally followed by 291 whitespace-separated arguments. 293 o Noted that Supersedes header is different from [Son-of-1036]. 295 o More exact ABNF for Archive and Injection-Info parameters. 297 o Discussed meaning of "yes", "no" in Archive header. 299 o Added "Obsolete Headers" section. 301 o Miscellaneous editorial changes 303 Changes since draft-ietf-usefor-article-13 305 o The Mail-Copies-To, Posted-And-Mailed headers have been moved to 306 other documents. 308 o Dropped MIME parameters, as there is no WG consensus (per Chair). 310 o More exact ABNF for Archive and Injection-Info parameters. 312 o Complaints-To header is now an Injection-Info parameter. 314 Table of Contents 316 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 15 317 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 15 318 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 15 319 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 15 320 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 16 321 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 16 322 1.6. Structure of This Document . . . . . . . . . . . . . . . . 18 323 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 324 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 325 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 326 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 21 327 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 328 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 22 329 3.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . 23 330 3.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 23 331 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 23 332 3.1.4. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 26 333 3.1.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . 27 334 3.1.6. Subject . . . . . . . . . . . . . . . . . . . . . . . 29 335 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 29 336 3.2.1. Approved . . . . . . . . . . . . . . . . . . . . . . . 30 337 3.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 30 338 3.2.3. Control . . . . . . . . . . . . . . . . . . . . . . . 31 339 3.2.4. Distribution . . . . . . . . . . . . . . . . . . . . . 31 340 3.2.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 32 341 3.2.6. Followup-To . . . . . . . . . . . . . . . . . . . . . 32 342 3.2.7. Injection-Date . . . . . . . . . . . . . . . . . . . . 33 343 3.2.8. Injection-Info . . . . . . . . . . . . . . . . . . . . 33 344 3.2.9. Organization . . . . . . . . . . . . . . . . . . . . . 35 345 3.2.10. References . . . . . . . . . . . . . . . . . . . . . . 35 346 3.2.11. Summary . . . . . . . . . . . . . . . . . . . . . . . 36 347 3.2.12. Supersedes . . . . . . . . . . . . . . . . . . . . . . 36 348 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 36 349 3.2.14. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 37 351 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 37 352 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 38 353 4. Internationalization Considerations . . . . . . . . . . . . . 39 354 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 355 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 356 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 357 7.1. Normative References . . . . . . . . . . . . . . . . . . . 46 358 7.2. Informative References . . . . . . . . . . . . . . . . . . 47 359 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 49 360 Appendix B. Differences from RFC 1036 and its derivatives . . . . 50 361 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 51 362 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 363 Intellectual Property and Copyright Statements . . . . . . . . . . 53 365 1. Introduction 367 1.1. Basic Concepts 369 "Netnews" is a set of protocols for generating, storing and 370 retrieving news "articles" (whose format is a subset of that for 371 Email messages), and for exchanging them amongst a readership that is 372 potentially widely distributed. It is organized around "newsgroups", 373 with the expectation that each reader will be able to see all 374 articles posted to each newsgroup in which he participates. These 375 protocols most commonly use a flooding algorithm which propagates 376 copies throughout a network of participating servers. Typically, 377 only one copy is stored per server, and each server makes it 378 available on demand to readers able to access that server. 380 1.2. Scope 382 This document specifies the syntax of Netnews articles in the context 383 of the "Internet Message Format" [RFC2822] and "Multipurpose Internet 384 Mail Extensions (MIME)" [RFC2045]. This document obsoletes 385 [RFC1036], updating the syntax of Netnews articles to reflect current 386 practice and incorporating changes and clarifications specified in 387 other documents such as [Son-of-1036]. 389 This is the first in a set of documents that obsolete [RFC1036]. 390 This document focuses on the syntax and semantics of Netnews 391 articles. [I-D.ietf-usefor-usepro] is also a standards-track 392 document and describes the protocol issues of Netnews articles, 393 independent of transport protocols such as [I-D.ietf-nntpext-base]. 394 A best-common-practice document, [I-D.ietf-usefor-useage], describes 395 implementation recommendations to improve interoperability and 396 usability. 398 This specification is intended as a definition of what article 399 content format is to be passed between systems. Although many news 400 systems locally store articles in this format (which eliminates the 401 need for translation between formats), local storage is outside of 402 the scope of this standard. 404 1.3. Requirements Notation 406 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 407 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 408 document are to be interpreted as described in [RFC2119]. 410 1.4. Syntax Notation 412 Header fields defined in this specification use the Augmented Backus- 413 Naur Form (ABNF) notation (including the Core Rules) specified in 414 [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as 415 updated by [RFC2231], and [RFC3986], specifically: 417 token = 418 value = 419 parameter = 420 attribute = 422 FWS = 423 comment = 424 CFWS = 425 atext = 426 dot-atom-text = 427 phrase = 428 utext = 429 date-time = 430 mailbox = 431 mailbox-list = 432 address-list = 433 body = 434 fields = 436 IPv6address = 437 IPv4address = 439 ALPHA = 440 CRLF = 441 DIGIT = 442 DQUOTE = 443 SP = 445 Additionally, Section 3.1.3 specifies a stricter definition of 446 than the syntax in [RFC2822] Section 3.6.4. 448 1.5. Definitions 450 An "article" is the unit of Netnews, analogous to an [RFC2822] 451 "message". A "proto-article" is one that has not yet been injected 452 into the news system. In contrast to an "article", a "proto-article" 453 may lack some mandatory header fields. 455 A "message identifier" (Section 3.1.3) is a unique identifier for an 456 article, usually supplied by the "user agent" that posted it or, 457 failing that, by the "news server". It distinguishes the article 458 from every other article ever posted anywhere. Articles with the 459 same message identifier are treated as if they are the same article 460 regardless of any differences in the body or header fields. 462 A "newsgroup" is a forum having a name and intended for articles on a 463 specific topic. An article is "posted to" a single newsgroup or 464 several newsgroups. When an article is posted to more than one 465 newsgroup, it is said to be "crossposted"; note that this differs 466 from posting the same text as part of each of several articles, one 467 per newsgroup. 469 A newsgroup may be "moderated", in which case submissions are not 470 posted directly, but mailed to a "moderator" for consideration and 471 possible posting. Moderators are typically human but may be 472 implemented partially or entirely in software. 474 A "poster" is the person or software that composes and submits a 475 potentially compliant article to a "user agent". 477 A "reader" is the person or software reading Netnews articles. 479 A "follow-up" is an article containing a response to the contents of 480 an earlier article, its "precursor". Every followup includes a 481 "References" header field identifying that precursor (but note that 482 non-followup articles may also use a References header field). 484 A "control message" is an article which is marked as containing 485 control information; a news server receiving such an article may 486 (subject to the policies observed at that site) take actions beyond 487 just filing and passing on the article. 489 A "news server" is software that may accept articles from a "user 490 agent", and/or make articles available to user agents, and/or 491 exchange articles with other news servers. 493 A "user agent" is software that may help posters submit proto- 494 articles to a news server, and/or fetch articles from a news server 495 and present them to a reader, and/or assist the reader in creating 496 articles and followups. 498 The generic term "agent" is used when describing requirements that 499 apply to both user agents and news servers. 501 An agent is said to "generate" a construct if it did not exist before 502 the agent created it. Examples are when a user agent creates a 503 message from text and addressing information supplied by a user, or 504 when a news server creates an "Injection-Info" header field for a 505 newly posted message. 507 An agent is said to "accept" a construct if some other entity 508 generates it and passes it to the agent in question, and the agent 509 processes it without treating it as a format or protocol error. 511 1.6. Structure of This Document 513 This document uses a cite-by-reference methodology, rather than 514 repeating the contents of other standards, which could otherwise 515 result in subtle differences and interoperability challenges. 516 Although this document is as a result rather short, it requires 517 complete understanding and implementation of the normative references 518 to be compliant. 520 Section 2 defines the format of Netnews articles. Section 3 details 521 the header fields necessary to make an article suitable for the 522 Netnews environment. 524 2. Format 526 2.1. Base 528 An article is said to be conformant to this specification if it 529 conforms to the format specified in [RFC2822] Section 3 and to the 530 additional requirements of this specification. 532 An article that uses the obsolete syntax specified in Section 4 of 533 [RFC2822] is NOT conformant to this specification, except for the 534 following two cases: 536 o Articles are conformant if they use the construct 537 (use of a phrase like "John Q. Public" without the use of quotes, 538 see [RFC2822] Section 4.1) but agents MUST NOT generate 539 productions of such syntax. 541 o Articles are conformant if they use the "GMT" , as specified 542 in Section 3.1.1. 544 This document, and specifications that build upon it, specify how to 545 handle conformant articles. Handling of non-conformant articles is 546 outside the scope of this specification. 548 Agents conforming to this specification MUST generate only conformant 549 articles. 551 The text below uses ABNF to specify restrictions on the syntax 552 specified in [RFC2822]; this grammar is intended to be more 553 restrictive than the [RFC2822] grammar. Articles must conform to the 554 ABNF specified in [RFC2822]. 556 Articles must also conform to the restrictions specified here, both 557 those that are expressed as text and those that are expressed as 558 ABNF. 560 NOTE: Other specifications use the term "header" as a synonym for 561 what [RFC2822] calls "header field". This document follows the 562 terminology in Section 2 of [RFC2822] in using the terms "line", 563 "header field", "header field name", "header field body", and 564 "folding", based on a belief that consistent terminology among 565 specifications that depend on each other makes the specifications 566 easier to use in the long run. 568 2.2. Header Fields 570 All header fields in a Netnews article are compliant with [RFC2822]; 571 this specification, however, is less permissive in what can be 572 generated and accepted by agents. The syntax allowed for Netnews 573 article headers is a strict subset of the "Internet Message Format" 574 headers, making all headers compliant with this specification 575 inherently compliant with [RFC2822]. Note however that the converse 576 is not guaranteed to be true in all cases. 578 General rules which apply to all header fields (even those documented 579 in [RFC2822] and [RFC2045]) are listed below, and those that apply to 580 specific header fields are described in the relevant sections of this 581 document. 583 o All agents MUST generate header fields so that at least one space 584 immediately follows the ':' separating the header field name and 585 the header field body (for compatibility with deployed software, 586 including NNTP [I-D.ietf-nntpext-base] servers). News agents MAY 587 accept header fields which do not contain the required space. 589 o Every line of a header field body (including the first and any 590 that are subsequently folded) MUST contain at least one non- 591 whitespace character. 593 NOTE: This means that no header field body defined by or 594 referenced by this document can be empty. As a result, rather 595 than using the syntax from Section 3.2.6 of 596 [RFC2822], this document uses a stricter definition: 598 unstructured = *WSP utext *( [FWS] utext ) *WSP 600 NOTE: The [RFC2822] specification sometimes uses [FWS] at the 601 beginning or end of ABNF describing header field content. This 602 specification uses *WSP in such cases, also in cases where this 603 specification redefines constructs from [RFC2822]. This is 604 done for consistency with the restriction described here, but 605 the restriction applies to all header fields, not just those 606 where ABNF is defined in this document. 608 o Compliant software MUST NOT generate (but MAY accept) header field 609 lines of more than 998 octets. This is the only limit on the 610 length of a header field line prescribed by this standard. 611 However, specific rules to the contrary may apply in particular 612 cases (for example, according to [RFC2047], lines of a header 613 field containing encoded-words are limited to 76 octets). 614 [I-D.ietf-usefor-useage] includes suggested limits for convenience 615 of display by user agents. 617 NOTE: As stated in [RFC2822], there is NO restriction on the 618 number of lines into which a header field may be split, and 619 hence there is NO restriction on the total length of a header 620 field (in particular it may, by suitable folding, be made to 621 exceed the 998 octets restriction pertaining to a single header 622 field line). 624 o The character set for header fields is US-ASCII. Where the use of 625 non-ASCII characters is required, they MUST be encoded using the 626 MIME mechanisms defined in [RFC2047] and [RFC2231]. 628 2.3. MIME Conformance 630 User agents MUST meet the definition of MIME conformance in [RFC2049] 631 and MUST also support [RFC2231]. This level of MIME conformance 632 provides support for internationalization and multimedia in message 633 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 634 internationalization of header fields ([RFC2047], [RFC2231]). Note 635 that [Errata] currently exist for [RFC2046] and [RFC2231]. 637 For the purposes of Section 5 of [RFC2047], all header fields defined 638 in Section 3 of this standard are to be considered as "extension 639 message header fields", permitting the use of [RFC2047] encodings 640 within any header field, or within any or 641 permitted within any structured header field. 643 User agents MAY accept and generate other MIME extension header 644 fields, and in particular SHOULD accept Content-Disposition [RFC2183] 645 and Content-Language [RFC3282]. 647 3. News Header Fields 649 The following news header fields extend those defined in Section 3.6 650 of [RFC2822]: 652 fields =/ *( approved / 653 archive / 654 control / 655 distribution / 656 expires / 657 followup-to / 658 injection-date / 659 injection-info / 660 lines / 661 newsgroups / 662 organization / 663 path / 664 summary / 665 supersedes / 666 user-agent / 667 xref ) 669 Each of these header fields may occur at most once in a news article. 671 The following header fields defined in this document do not allow 672 comments (CFWS): 674 Control 675 Distribution 676 Newsgroups 677 Followup-To 678 Lines 679 Path 680 Supersedes 681 Xref 683 This also applies to the following header field defined in [RFC2822]: 685 Message-ID 687 Most of these header fields are mainly of interest to news servers, 688 and news servers often need to process these fields very rapidly. 689 Thus some header fields prohibit s. 691 3.1. Mandatory Header Fields 693 Each Netnews article conformant with this specification MUST have 694 exactly one of each of the following header fields: Date, From, 695 Message-ID, Newsgroups, Path, Subject. 697 3.1.1. Date 699 The Date header field is the same as that specified in Sections 3.3 700 and 3.6.1 of [RFC2822] with the added restrictions detailed above in 701 Section 2.2. However, the use of "GMT" as a time zone (part of ), although deprecated, is widespread in Netnews articles today. 703 Therefore, agents MUST accept constructs that use the 704 "GMT" zone. 706 orig-date = "Date:" SP date-time CRLF 708 NOTE: This specification does not change [RFC2822], which says 709 that agents MUST NOT generate constructs which include 710 any zone names defined by . 712 Software that accepts dates with unknown timezones SHOULD treat such 713 timezones as equivalent to "-0000" when comparing dates, as specified 714 in [RFC2822] Section 4.3. 716 Also note that these requirements apply wherever is used, 717 including Injection-Date and Expires in Section 3.2.7 and 718 Section 3.2.5, respectively. 720 3.1.2. From 722 The From header field is the same as that specified in Section 3.6.2 723 of [RFC2822] with the added restrictions detailed above in 724 Section 2.2. 726 from = "From:" SP mailbox-list CRLF 728 3.1.3. Message-ID 730 The Message-ID header field contains a unique message identifier. 731 Netnews is more dependent on message identifier uniqueness and fast 732 comparison than Email is, and some news software and standards 733 [I-D.ietf-nntpext-base] might have trouble with the full range of 734 possible s permitted by [RFC2822]. This section therefore 735 restricts the syntax of as compared to Section 3.6.4 of 736 [RFC2822]. The global uniqueness requirement for in 737 [RFC2822] is to be understood as applying across all protocols using 738 such message identifiers, and across both Email and Netnews in 739 particular. 741 message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF 743 msg-id = "<" msg-id-core ">" 744 ; maximum length is 250 octets 746 msg-id-core = id-left "@" id-right 748 id-left = dot-atom-text / no-fold-quote 750 id-right = dot-atom-text / no-fold-literal 752 no-fold-quote = DQUOTE 753 ( "." *mqtext / 754 *mqtext "." / 755 *mqtext mqspecial *mqtext ) 756 DQUOTE 758 mqtext = atext / "." / mqspecial 760 mqspecial = "(" / ")" / ; same as specials except 761 "<" / ; "\" and DQUOTE quoted 762 "[" / "]" / ; "." doubled and ">" omitted 763 ":" / ";" / 764 "@" / "," / 765 ".." / "\\" / "\" DQUOTE 767 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 769 mdtext = %d33-61 / ; The rest of the US-ASCII 770 %d63-90 / ; characters not including 771 %d94-126 ; ">", "[", "]", or "\" 773 The msg-id MUST NOT be more than 250 octets in length. 775 NOTE: The length restriction ensures that systems that accept 776 message identifiers as a parameter when referencing an article 777 (e.g. [I-D.ietf-nntpext-base]) can rely on a bounded length. 779 Observe that msg-id includes the < and >. 781 Observe also that in contrast to the corresponding header field in 782 [RFC2822]: 784 o the syntax does not allow comments within the Message-ID header 785 field, 787 o it ensures that no string of characters is quoted if it were 788 already a (it MUST start or end with a ".", or 789 contain at least one ), 791 o it ensures that no single character is prefixed by a "\" in the 792 form of a unless strictly necessary, 794 o it excludes all control characters, 796 o there is no possibility for ">" or WSP to occur inside a , 797 whether quoted or not, and 799 o even though commonly derived from s, s are 800 case-sensitive (and thus, once created, are not to be altered 801 during subsequent transmission or copying) 803 This is to simplify processing by news servers and to ensure 804 interoperability with existing implementations and compliance with 805 [I-D.ietf-nntpext-base]. Thus, whereas under [RFC2822] the following 806 s would be considered semantically equivalent, 808 809 <"ab.cd"@example.com> 810 <"ab.\cd"@example.com> 812 only the first of them is syntactically permitted by this standard, 813 and hence a simple comparison of octets will always suffice to 814 determine the identity of two s. 816 Also note that this updated ABNF applies wherever is used, 817 including the References header field discussed in Section 3.2.10 and 818 the Supersedes header field discussed in Section 3.2.12. 820 Some software will try to match the of a in a 821 case-insensitive fashion; some will match it in a case-sensitive 822 fashion. Implementations MUST NOT generate two Message-IDs where the 823 only difference is the case of characters in the part. 825 When generating a , implementations SHOULD use a domain name 826 as the . 828 NOTE: Section 3.6.4 of [RFC2822] recommends that the 829 should be a domain name or a domain literal. Domain literals are 830 troublesome since many IP addresses are not globally unique; 831 domain names are more likely to generate unique Message-IDs. 833 3.1.4. Newsgroups 835 The Newsgroups header field specifies the newsgroup(s) to which the 836 article is posted. 838 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 840 newsgroup-list = *WSP newsgroup-name 841 *( [FWS] "," [FWS] newsgroup-name ) *WSP 843 newsgroup-name = component *( "." component ) 845 component = 1*component-char 847 component-char = ALPHA / DIGIT / "+" / "-" / "_" 849 Not all servers support [FWS] in the list of newsgroups. In 850 particular, folding the Newsgroups header field over several lines 851 has been shown to harm propagation significantly. [FWS] in the 852 SHOULD NOT be generated, but MUST be accepted. 854 A newsgroup component SHOULD NOT consist of digits only and SHOULD 855 NOT contain uppercase letters. Such components MAY be used only to 856 refer to existing groups that do not conform to this naming scheme, 857 but MUST NOT be used otherwise. 859 NOTE: All-digit components conflict with one widely used storage 860 scheme for articles. Mixed-case groups cause confusion between 861 systems with case-sensitive matching and systems with case- 862 insensitive matching of s. 864 s beginning with underline ("_") are reserved for use by 865 future versions of this standard and SHOULD NOT be generated by user 866 agents (whether in header fields or in newgroup control messages as 867 defined by [I-D.ietf-usefor-usepro]). However, such names MUST be 868 accepted by news servers. 870 s beginning with "+" and "-" are reserved for private use 871 and SHOULD NOT be generated by user agents (whether in header fields 872 or in newgroup control messages [I-D.ietf-usefor-usepro]) without a 873 private prior agreement to do so. However, such names MUST be 874 accepted by news servers. 876 The following s are reserved and MUST NOT be used as 877 the name of a newsgroup: 879 o Groups whose first (or only) is "example" 880 o The group "poster" 882 The following s have been used for specific purposes 883 in various implementations and protocols and therefore MUST NOT be 884 used for the names of normal newsgroups. They MAY be used for their 885 specific purpose or by local agreement. 887 o Groups whose first (or only) component is "to" 889 o Groups whose first (or only) component is "control" 891 o Groups which contain (or consist only of) the component "all" 893 o Groups which contain (or consist only of) the component "ctl" 895 o The group "junk" 897 NOTE: "example.*" is reserved for examples in this and other 898 standards; "poster" has a special meaning in the Followup-To 899 header field; "to.*" is reserved for certain point-to-point 900 communications in conjunction with the "ihave" control message as 901 defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have 902 special meanings in some news servers; "all" is used as a wildcard 903 in some implementations; and "ctl" was formerly used to indicate a 904 within the Newsgroups header field. 906 3.1.5. Path 908 The Path header field indicates the route taken by an article since 909 its injection into the Netnews system. Each agent that processes an 910 article is required to prepend at least one to this 911 header field body. This is primarily so that news servers are able 912 to avoid sending articles to sites already known to have them, in 913 particular the site they came from, and additionally to permit 914 tracing the route articles take in moving over the network, and for 915 gathering statistics. 917 path = "Path:" SP *WSP path-list tail-entry *WSP CRLF 919 path-list = *( path-identity [FWS] [path-diagnostic] "!" ) 921 path-diagnostic = diag-match / diag-other / diag-deprecated 923 diag-match = "!" ; another "!" 925 diag-other = "!." diag-keyword [ "." diag-identity ] [FWS] 927 diag-deprecated = "!" IPv4address [FWS] 929 diag-keyword = 1*ALPHA ; see [I-D.ietf-usefor-usepro] 931 diag-identity = path-identity / IPv4address / IPv6address 933 tail-entry = path-nodot 934 ; may be the string "not-for-mail" 936 path-identity = ( 1*( label "." ) toplabel ) / path-nodot 938 path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names 940 label = alphanum [ *( alphanum / "-" ) alphanum ] 942 toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / 943 ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / 944 ( label 1*( "-" ) label ) 946 alphanum = ALPHA / DIGIT ; compare RFC3696 948 A is a name identifying a site. It takes the form of 949 a domain name having two or more components separated by dots, or a 950 single name with no dots (). 952 Each in the (which does not include the 953 ) indicates, from right to left, the successive agents 954 through which the article has passed. The use of the , 955 which appears as "!!", indicates that the agent to its left verified 956 the identity of the agent to its right before accepting the article 957 (whereas the "!" implies no such claim). 959 NOTE: Historically, the indicated the name of the 960 sender. If not used for this purpose, the string "not-for-mail" 961 is often used instead (since at one time the whole path could be 962 used as a mail address for the sender). 964 NOTE: Although case-insensitive, it is intended that the s should be in upper-case, to distinguish them from the 966 s which are traditionally in lower case. 968 A is an item inserted into the Path header field 969 for purposes other than to indicate the name of a site. The use of 970 these is described in [I-D.ietf-usefor-usepro]. 972 NOTE: One usage of a is to record an IP address. 973 The fact that es are allowed means that the colon (:) 974 is permitted; note that this may cause interoperability problems 975 at older sites that regard ":" as a and have 976 neighbors whose names have 4 or fewer characters, and where all 977 the characters are valid HEX digits. 979 NOTE: Although es have occasionally been used in the 980 past (usually with a diagnostic intent), their continued use is 981 deprecated (though it is still acceptable in the form of the 982 ). 984 3.1.6. Subject 986 The Subject header field is the same as that specified in Section 987 3.6.5 of [RFC2822] with the added restrictions detailed above in 988 Section 2.2. Further discussion of the content of the Subject header 989 field appears in [I-D.ietf-usefor-usepro] and 990 [I-D.ietf-usefor-useage]. 992 subject = "Subject:" SP unstructured CRLF 994 3.2. Optional Header Fields 996 None of the header fields appearing in this section is required to 997 appear in every article, but some of them may be required in certain 998 types of article. Further discussion of these requirements appears 999 in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage]. 1001 The header fields Comments, Keywords, Reply-To, and Sender are used 1002 in Netnews articles in the same circumstances and with the same 1003 meanings as those specified in [RFC2822] with the added restrictions 1004 detailed above in Section 2.2. Multiple occurrences of the Keywords 1005 header field are not permitted. 1007 comments = "Comments:" SP unstructured CRLF 1009 keywords = "Keywords:" SP phrase *("," phrase) CRLF 1011 reply-to = "Reply-To:" SP address-list CRLF 1013 sender = "Sender:" SP mailbox CRLF 1015 The MIME header fields MIME-Version, Content-Type, Content-Transfer- 1016 Encoding, Content-Disposition, and Content-Language are used in 1017 Netnews articles in the same circumstances and with the same meanings 1018 as those specified in [RFC2045], [RFC2183], and [RFC3282] with the 1019 added restrictions detailed above in Section 2.2. 1021 All remaining news header fields are described below. 1023 3.2.1. Approved 1025 The Approved header field indicates the mailing addresses (and 1026 possibly the full names) of the persons or entities approving the 1027 article for posting. Its principal uses are in moderated articles 1028 and in group control messages; see [I-D.ietf-usefor-usepro]. 1030 approved = "Approved:" SP mailbox-list CRLF 1032 3.2.2. Archive 1034 The Archive header field provides an indication of the poster's 1035 intent regarding preservation of the article in publicly accessible 1036 long-term or permanent storage. 1038 archive = "Archive:" SP [CFWS] ("no" / "yes") 1039 *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF 1041 archive-param = parameter 1043 The presence of an Archive header field in an article with a field 1044 body of "no" indicates that the poster does not permit redistribution 1045 from publicly accessible long-term or permanent archives. A field 1046 body of "yes" indicates that the poster permits such redistribution. 1048 No s are currently defined; if present, they can be 1049 ignored. Further discussion of the content of the Archive header 1050 field appears in [I-D.ietf-usefor-useage]. 1052 3.2.3. Control 1054 The Control header field marks the article as a control message and 1055 specifies the desired actions (additional to the usual ones of 1056 storing and/or relaying the article). 1058 control = "Control:" SP *WSP control-command *WSP CRLF 1060 control-command = verb *( 1*WSP argument ) 1062 verb = token 1064 argument = 1*( %x21-7E ) 1066 The verb indicates what action should be taken, and the argument(s) 1067 (if any) supply details. In some cases, the (as defined in 1068 [RFC2822]) of the article may also contain details. The legal verbs 1069 and respective arguments are discussed in the companion document, 1070 [I-D.ietf-usefor-usepro]. 1072 An article with a Control header field MUST NOT also have a 1073 Supersedes header field. 1075 3.2.4. Distribution 1077 The Distribution header field specifies geographic or organizational 1078 limits on an article's propagation. 1080 distribution = "Distribution:" SP dist-list CRLF 1082 dist-list = *WSP dist-name 1083 *( [FWS] "," [FWS] dist-name ) *WSP 1085 dist-name = ALPHA / DIGIT 1086 *( ALPHA / DIGIT / "+" / "-" / "_" ) 1088 The s "world" and "local" are reserved. "world" indicates 1089 unlimited distribution and SHOULD NOT be used explicitly, since it is 1090 the default when the Distribution header field is absent entirely. 1091 "local" is reserved for indicating distribution only to the local 1092 site, as defined by local software configuration. 1094 "All" MUST NOT be used as a . s SHOULD contain 1095 at least three characters, except when they are two-letter country 1096 names drawn from [ISO3166-1]. s are case-insensitive (i.e. 1097 "US", "Us", "uS", and "us" all specify the same distribution). 1099 [FWS] in the SHOULD NOT be generated, but MUST be 1100 accepted. 1102 3.2.5. Expires 1104 The Expires header field specifies a date and time when the poster 1105 deems the article to be no longer relevant and could usefully be 1106 removed ("expired"). 1108 NOTE: This header field is useful when the poster desires an 1109 unusually long or an unusually short expiry time. 1111 expires = "Expires:" SP date-time CRLF 1113 See the remarks under Section 3.1.1 regarding the syntax of 1114 and the requirements and recommendations to which it is 1115 subject. 1117 NOTE: The Expires header field is also sometimes used in Email 1118 with a similar meaning; see [RFC2156]. 1120 3.2.6. Followup-To 1122 The Followup-To header field specifies to which newsgroup(s) the 1123 poster has requested that followups are to be posted. The 1124 Followup-To header field SHOULD NOT appear in a message, unless its 1125 content is different from the content of the Newsgroups header field. 1127 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 1128 CRLF 1130 poster-text = *WSP %d112.111.115.116.101.114 *WSP 1131 ; "poster" in lower-case 1133 The syntax is the same as that of the Newsgroups (Section 3.1.4) 1134 header field, with the exception that the keyword "poster" requests 1135 that followups should be emailed directly to the article's poster 1136 (using the addresses contained in the Reply-To header field if one 1137 exists, otherwise using the addresses contained in the From header 1138 field) rather than posted to any newsgroups. Agents MUST generate 1139 the keyword "poster" in lower-case, but MAY choose to recognize case- 1140 insensitive forms such as "Poster". 1142 As in the Newsgroups (Section 3.1.4) header field, [FWS] in the 1143 SHOULD NOT be generated, but MUST be accepted. 1145 3.2.7. Injection-Date 1147 The Injection-Date header field contains the date and time that the 1148 article was injected into the network. Its purpose is to enable news 1149 servers, when checking for "stale" articles, to use a 1150 that was added by a news server at injection time rather than one 1151 added by the user agent at message composition time. 1153 This header field MUST be inserted whenever an article is injected. 1154 However, software that predates this standard does not use this 1155 header, and therefore agents MUST accept articles without the 1156 Injection-Date header field. 1158 injection-date = "Injection-Date:" SP date-time CRLF 1160 See the remarks under Section 3.1.1 regarding the syntax of 1161 and the requirements and recommendations to which it is 1162 subject. 1164 NOTE: Since clocks on various agents are not necessarily 1165 synchronized, the in this header field may not be 1166 later than the Date header field, as be expected. Agents MUST NOT 1167 alter a pre-existing Date header field when adding an Injection- 1168 Date header field. 1170 This header field is intended to replace the currently-used but 1171 undocumented "NNTP-Posting-Date" header field, whose use is now 1172 deprecated. 1174 3.2.8. Injection-Info 1176 The Injection-Info header field contains information provided by the 1177 injecting news server as to how an article entered the Netnews system 1178 and to assist in tracing its true origin. It can also specify one or 1179 more addresses where complaints concerning the poster of the article 1180 may be sent. 1182 injection-info = "Injection-Info:" SP [CFWS] path-identity 1183 [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF 1185 NOTE: The syntax of ([RFC2045] Section 5.1 as amended 1186 by [RFC2231]), taken in conjunction with the folding rules of 1187 [RFC0822], effectively allows [CFWS] to occur on either side of 1188 the "=" inside a . 1190 The following table gives the and the format of the 1191 for each defined for use with this header field. 1193 At most one occurrence of each such is allowed. 1195 format of 1196 -------------------- ----------------- 1197 "posting-host" a 1198 "posting-account" any 1199 "logging-data" any 1200 "mail-complaints-to" an 1202 where 1204 host-value = dot-atom-text / IPv4address / IPv6address / 1205 (dot-atom-text ":" ( IPv4address / IPv6address )) 1207 NOTE: Since any such or also has to be 1208 a syntactically correct , it will usually be necessary to 1209 encapsulate it as a , for example: 1211 posting-host = "posting@example.com:192.168.0.1" 1213 Other s SHOULD NOT be used unless defined in extensions to 1214 this standard. If non-standards-based s are used, they 1215 MUST begin with an "x-". 1217 Although comments and folding of white space are permitted throughout 1218 the Injection-Info header field, folding SHOULD NOT be used within 1219 any . Folding SHOULD only occur before or after the ";" 1220 separating s, and comments SHOULD only be used following 1221 the last . 1223 NOTE: Some of this information has previously been sent in non- 1224 standardized header fields such as NNTP-Posting-Host, X-Trace, 1225 X-Complaints-To, and others. Once a news server uses Injection- 1226 Info, it should have no need to send these non-standard header 1227 fields. 1229 The "posting-host" specifies the FQDN and/or IP address 1230 (IPv4address or IPv6address) of the host from which the news server 1231 received the article. 1233 NOTE: If the "posting-host" identifies a dial-up 1234 point-of-presence, the "posting-account" or the "logging-data" 1235 may provide additional information about the true 1236 origin of the article. 1238 The "posting-account" identifies the source from which 1239 that news server received the article, in a notation that can be 1240 interpreted by the news server administrator. This notation can 1241 include any information the administrator deems pertinent. In order 1242 to limit the exposure of personal data, it SHOULD be given in a form 1243 that cannot be interpreted by other sites. However, to make it 1244 useful for rate limiting and abuse detection, two messages posted 1245 from the same source SHOULD have the same value of "posting-account", 1246 and two messages from different sources SHOULD have differing values 1247 of "posting-account". The exact definition of "source" is left to 1248 the discretion of the news server administrator. 1250 The "logging-data" contains information (typically a 1251 session number or other non-persistent means of identifying a posting 1252 account) that will enable the true origin of the article to be 1253 determined by reference to logging information kept by the news 1254 server. 1256 The "mail-complaints-to" specifies one or more mailboxes 1257 for sending complaints concerning the behavior of the poster of the 1258 article. 1260 It is a matter of local policy which of the above s to 1261 include. Some pieces of information have privacy implications; this 1262 is discussed in [I-D.ietf-usefor-useage]. 1264 3.2.9. Organization 1266 The Organization header field is a short phrase identifying the 1267 poster's organization. 1269 organization = "Organization:" SP unstructured CRLF 1271 NOTE: There is no "s" in Organization. 1273 3.2.10. References 1275 The References header field is the same as that specified in Section 1276 3.6.4 of [RFC2822] with the added restrictions detailed above in 1277 Section 2.2 and those listed below: 1279 o The updated construct defined in Section 3.1.3 MUST be 1280 used. 1282 o Message identifiers MUST be separated with CFWS. 1284 o Comments in CFWS between message identifiers can cause 1285 interoperability problems, so comments SHOULD NOT be generated, 1286 but MUST be accepted. 1288 references = "References:" SP [CFWS] msg-id *(CFWS msg-id) 1289 [CFWS] CRLF 1291 3.2.11. Summary 1293 The Summary header field is a short phrase summarizing the article's 1294 content. 1296 summary = "Summary:" SP unstructured CRLF 1298 3.2.12. Supersedes 1300 The Supersedes header field contains a message identifier specifying 1301 an article to be superseded upon the arrival of this one. An article 1302 containing a Supersedes header field is equivalent to a "cancel" 1303 [I-D.ietf-usefor-usepro] control message for the specified article, 1304 followed immediately by the new article without the Supersedes header 1305 field. 1307 supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF 1309 NOTE: There is no "c" in Supersedes. 1311 NOTE: The Supersedes header field defined here has no connection 1312 with the Supersedes header field that sometimes appears in Email 1313 messages converted from X.400 according to [RFC2156]; in 1314 particular, the syntax here permits only one in contrast 1315 to the multiple s in that Email version. 1317 3.2.13. User-Agent 1319 The User-Agent header field contains information about the user agent 1320 (typically a newsreader) generating the article, for statistical 1321 purposes and tracing of standards violations to specific software 1322 needing correction. It is intended that this header field be 1323 suitable for use in Email. 1325 user-agent = "User-Agent:" SP 1*product [CFWS] CRLF 1327 product = [CFWS] token [ [CFWS] "/" product-version ] 1329 product-version = [CFWS] token 1331 This header field MAY contain multiple tokens identifying 1332 the user agent and any subproducts which form a significant part of 1333 it, listed in order of their significance for identifying the 1334 application. 1336 NOTE: Some of this information has previously been sent in non- 1337 standardized header fields such as X-Newsreader, X-Mailer, 1338 X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent 1339 uses User-Agent, it should have no need to send these non-standard 1340 header fields. 1342 NOTE: [RFC2616] describes a similar facility for the HTTP 1343 protocol. The Netnews article format differs in that "{" and "}" 1344 are allowed in tokens ( and ) and 1345 comments are permitted wherever whitespace is allowed. 1347 3.2.14. Xref 1349 The Xref header field indicates where an article was filed by the 1350 last news server to process it. User agents often use the 1351 information in the Xref header field to avoid multiple processing of 1352 crossposted articles. 1354 xref = "Xref:" SP *WSP server-name 1355 1*( FWS location ) *WSP CRLF 1357 server-name = path-identity 1359 location = newsgroup-name ":" article-locator 1361 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 1362 ; US-ASCII printable characters 1363 ; except '(' and ';' 1365 The is included so that software can determine which 1366 news server generated the header field. The locations specify what 1367 newsgroups the article was filed under (which may differ from those 1368 in the Newsgroups header field) and where it was filed under them. 1369 The exact form of an is implementation-specific. 1371 NOTE: The traditional form of an (as required by 1372 [I-D.ietf-nntpext-base]) is a decimal number, with articles in 1373 each newsgroup numbered consecutively starting from 1. 1375 3.3. Obsolete Header Fields 1377 The header fields Date-Received, Posting-Version, and Relay-Version 1378 defined in [RFC0850], as well as Also-Control, Article-Names, 1379 Article-Updates, and See-Also defined in [Son-of-1036] are declared 1380 obsolete. See the cited specification documents for further 1381 information on their original use. 1383 These header fields MUST NOT be generated and SHOULD be ignored. 1385 3.3.1. Lines 1387 The Lines header field indicates the number of lines in the 1388 (as defined in [RFC2822]) of the article. 1390 lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF 1392 The line count is the number of CRLF separators in the . 1394 Historically, this header field was used by the 1395 [I-D.ietf-nntpext-base] overview facility, but its use for this 1396 purpose is now deprecated. As a result, this header field is to be 1397 regarded as obsolescent, and it is likely to be removed entirely in a 1398 future version of this standard. All agents SHOULD ignore it and 1399 SHOULD NOT generate it. 1401 4. Internationalization Considerations 1403 Internationalization of Netnews article header fields and bodies is 1404 provided using MIME mechanisms discussed in Section 2.3. Note that 1405 the generation of internationalized s for use in 1406 header fields is not addressed in this document. 1408 5. Security Considerations 1410 The Netnews article format specified in this document does not 1411 provide any security services, such as confidentiality, 1412 authentication of sender, or non-repudiation. Instead, such services 1413 need to be layered above, using such protocols as S/MIME [RFC3851] or 1414 PGP/MIME [RFC3156], or below, using secure versions of news transport 1415 protocols. Additionally, several currently non-standardized 1416 protocols such as [PGPVERIFY] may be standardized in the near future. 1418 Message identifiers (Section 3.1.3) in news are required to be 1419 unique; articles may be refused (in server-to-server transfer) if the 1420 identifier has already been seen. So if you can predict the 1421 identifier of a message, you can preempt it by posting a message 1422 (possibly to a quite different group) with the same message 1423 identifier, stopping your target message from propagating. Agents 1424 that generate message identifiers for Netnews articles SHOULD ensure 1425 that they are unpredictable. 1427 MIME security considerations are discussed in [RFC2046]. Note that 1428 the full range of encodings allowed for parameters in [RFC2046] and 1429 [RFC2231] permits constructs that simple parsers may fail to parse 1430 correctly; examples of hard-to-parse constructs are: 1432 Content-Type: multipart/mixed 1433 (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") 1435 Content-Type: multipart/digest; 1436 boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy 1438 Such deficiencies in parsing may be used as part of an attack. 1440 Further security considerations are discussed in 1441 [I-D.ietf-usefor-usepro]. 1443 6. IANA Considerations 1445 IANA is requested to register the following header fields in the 1446 Permanent Message Header Field Repository, in accordance with the 1447 procedures set out in [RFC3864]. 1449 Header field name: Also-Control 1450 Applicable protocol: netnews 1451 Status: obsoleted 1452 Author/change controller: IETF 1453 Specification document(s): [Son-of-1036] (Section 6.15) 1455 Header field name: Approved 1456 Applicable protocol: netnews 1457 Status: standard 1458 Author/change controller: IETF 1459 Specification document(s): This document (Section 3.2.1) 1461 Header field name: Archive 1462 Applicable protocol: netnews 1463 Status: standard 1464 Author/change controller: IETF 1465 Specification document(s): This document (Section 3.2.2) 1467 Header field name: Article-Names 1468 Applicable protocol: netnews 1469 Status: obsoleted 1470 Author/change controller: IETF 1471 Specification document(s): [Son-of-1036] (Section 6.17) 1473 Header field name: Article-Updates 1474 Applicable protocol: netnews 1475 Status: obsoleted 1476 Author/change controller: IETF 1477 Specification document(s): [Son-of-1036] (Section 6.18) 1479 Header field name: Comments 1480 Applicable protocol: netnews 1481 Status: standard 1482 Author/change controller: IETF 1483 Specification document(s): This document (Section 3.2), 1484 [RFC2822] (Section 3.6.5) 1486 Header field name: Control 1487 Applicable protocol: netnews 1488 Status: standard 1489 Author/change controller: IETF 1490 Specification document(s): This document (Section 3.2.3) 1491 Header field name: Date 1492 Applicable protocol: netnews 1493 Status: standard 1494 Author/change controller: IETF 1495 Specification document(s): This document (Section 3.1.1), 1496 [RFC2822] (Section 3.6.1) 1498 Header field name: Date-Received 1499 Applicable protocol: netnews 1500 Status: obsoleted 1501 Author/change controller: IETF 1502 Specification document(s): [RFC0850] (Section 2.2.4) 1504 Header field name: Distribution 1505 Applicable protocol: netnews 1506 Status: standard 1507 Author/change controller: IETF 1508 Specification document(s): This document (Section 3.2.4) 1510 Header field name: Expires 1511 Applicable protocol: netnews 1512 Status: standard 1513 Author/change controller: IETF 1514 Specification document(s): This document (Section 3.2.5) 1516 Header field name: Followup-To 1517 Applicable protocol: netnews 1518 Status: standard 1519 Author/change controller: IETF 1520 Specification document(s): This document (Section 3.2.6) 1522 Header field name: From 1523 Applicable protocol: netnews 1524 Status: standard 1525 Author/change controller: IETF 1526 Specification document(s): This document (Section 3.1.2), 1527 [RFC2822] (Section 3.6.2) 1529 Header field name: Injection-Date 1530 Applicable protocol: netnews 1531 Status: standard 1532 Author/change controller: IETF 1533 Specification document(s): This document (Section 3.2.7) 1535 Header field name: Injection-Info 1536 Applicable protocol: netnews 1537 Status: standard 1538 Author/change controller: IETF 1539 Specification document(s): This document (Section 3.2.8) 1541 Header field name: Keywords 1542 Applicable protocol: netnews 1543 Status: standard 1544 Author/change controller: IETF 1545 Specification document(s): This document (Section 3.2), 1546 [RFC2822] (Section 3.6.5) 1548 Header field name: Lines 1549 Applicable protocol: netnews 1550 Status: deprecated 1551 Author/change controller: IETF 1552 Specification document(s): This document (Section 3.3.1) 1553 Related information: [I-D.ietf-nntpext-base] (Section 8.1) 1555 Header field name: Message-ID 1556 Applicable protocol: netnews 1557 Status: standard 1558 Author/change controller: IETF 1559 Specification document(s): This document (Section 3.1.3) 1560 Related information: [RFC2822] (Section 3.6.4) 1562 Header field name: Newsgroups 1563 Applicable protocol: netnews 1564 Status: standard 1565 Author/change controller: IETF 1566 Specification document(s): This document (Section 3.1.4) 1568 Header field name: NNTP-Posting-Date 1569 Applicable protocol: netnews 1570 Status: obsoleted 1571 Author/change controller: IETF 1572 Specification document(s): none 1574 Header field name: NNTP-Posting-Host 1575 Applicable protocol: netnews 1576 Status: obsoleted 1577 Author/change controller: IETF 1578 Specification document(s): [RFC2980] (Section 3.4.1) 1580 Header field name: Organization 1581 Applicable protocol: netnews 1582 Status: standard 1583 Author/change controller: IETF 1584 Specification document(s): This document (Section 3.2.9) 1585 Header field name: Path 1586 Applicable protocol: netnews 1587 Status: standard 1588 Author/change controller: IETF 1589 Specification document(s): This document (Section 3.1.5) 1591 Header field name: Posting-Version 1592 Applicable protocol: netnews 1593 Status: obsoleted 1594 Author/change controller: IETF 1595 Specification document(s): [RFC0850] (Section 2.1.2) 1597 Header field name: References 1598 Applicable protocol: netnews 1599 Status: standard 1600 Author/change controller: IETF 1601 Specification document(s): This document (Section 3.2.10), 1602 [RFC2822] (Section 3.6.4) 1604 Header field name: Relay-Version 1605 Applicable protocol: netnews 1606 Status: obsoleted 1607 Author/change controller: IETF 1608 Specification document(s): [RFC0850] (Section 2.1.1) 1610 Header field name: Reply-To 1611 Applicable protocol: netnews 1612 Status: standard 1613 Author/change controller: IETF 1614 Specification document(s): This document (Section 3.2), 1615 [RFC2822] (Section 3.6.2) 1617 Header field name: See-Also 1618 Applicable protocol: netnews 1619 Status: obsoleted 1620 Author/change controller: IETF 1621 Specification document(s): [Son-of-1036] (Section 6.16) 1623 Header field name: Sender 1624 Applicable protocol: netnews 1625 Status: standard 1626 Author/change controller: IETF 1627 Specification document(s): This document (Section 3.2), 1628 [RFC2822] (Section 3.6.2) 1630 Header field name: Subject 1631 Applicable protocol: netnews 1632 Status: standard 1633 Author/change controller: IETF 1634 Specification document(s): This document (Section 3.1.6), 1635 [RFC2822] (Section 3.6.5) 1637 Header field name: Summary 1638 Applicable protocol: netnews 1639 Status: standard 1640 Author/change controller: IETF 1641 Specification document(s): This document (Section 3.2.11) 1643 Header field name: Supersedes 1644 Applicable protocol: netnews 1645 Status: standard 1646 Author/change controller: IETF 1647 Specification document(s): This document (Section 3.2.12) 1649 Header field name: User-Agent 1650 Applicable protocol: netnews 1651 Status: standard 1652 Author/change controller: IETF 1653 Specification document(s): This document (Section 3.2.13) 1654 Related information: [RFC2616] (Section 14.43) 1656 Header field name: Xref 1657 Applicable protocol: netnews 1658 Status: standard 1659 Author/change controller: IETF 1660 Specification document(s): This document (Section 3.2.14) 1662 7. References 1664 7.1. Normative References 1666 [Errata] "RFC Editor Errata", 1667 http://www.rfc-editor.org/errata.html. 1669 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1670 Extensions (MIME) Part One: Format of Internet Message 1671 Bodies", RFC 2045, November 1996. 1673 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1674 Extensions (MIME) Part Two: Media Types", RFC 2046, 1675 November 1996. 1677 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1678 Part Three: Message Header Extensions for Non-ASCII Text", 1679 RFC 2047, November 1996. 1681 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1682 Extensions (MIME) Part Five: Conformance Criteria and 1683 Examples", RFC 2049, November 1996. 1685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1686 Requirement Levels", BCP 14, RFC 2119, March 1997. 1688 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1689 Presentation Information in Internet Messages: The 1690 Content-Disposition Header Field", RFC 2183, August 1997. 1692 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1693 Word Extensions: Character Sets, Languages, and 1694 Continuations", RFC 2231, November 1997. 1696 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1697 April 2001. 1699 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1700 May 2002. 1702 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1703 Resource Identifier (URI): Generic Syntax", STD 66, 1704 RFC 3986, January 2005. 1706 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1707 Specifications: ABNF", RFC 4234, October 2005. 1709 7.2. Informative References 1711 [I-D.ietf-nntpext-base] 1712 Feather, C., "Network News Transfer Protocol", 1713 draft-ietf-nntpext-base-27 (work in progress), June 2005. 1715 [I-D.ietf-usefor-useage] 1716 Lindsey, C., "Usenet Best Practice", 1717 draft-ietf-usefor-useage-01 (work in progress), 1718 March 2005. 1720 [I-D.ietf-usefor-usepro] 1721 Lindsey, C., "News Article Architecture and Protocols", 1722 draft-ietf-usefor-usepro-05 (work in progress), 1723 January 2006. 1725 [ISO3166-1] 1726 International Organization for Standardization, "ISO 3166- 1727 1:1997. Codes for the representation of names of countries 1728 and their subdivisions -- Part 1: Country codes", 1997. 1730 [PGPVERIFY] 1731 Lawrence, D., "PGPverify", 1732 ftp://ftp.isc.org/pub/pgpcontrol/README.html, June 1999. 1734 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1735 text messages", STD 11, RFC 822, August 1982. 1737 [RFC0850] Horton, M., "Standard for interchange of USENET messages", 1738 RFC 850, June 1983. 1740 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1741 USENET messages", RFC 1036, December 1987. 1743 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1744 Mapping between X.400 and RFC 822/MIME", RFC 2156, 1745 January 1998. 1747 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1748 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1749 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1751 [RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, 1752 October 2000. 1754 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1755 "MIME Security with OpenPGP", RFC 3156, August 2001. 1757 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1758 Extensions (S/MIME) Version 3.1 Message Specification", 1759 RFC 3851, July 2004. 1761 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1762 Procedures for Message Header Fields", BCP 90, RFC 3864, 1763 September 2004. 1765 [Son-of-1036] 1766 Spencer, H., "News Article Format and Transmission", 1767 ftp://ftp.zoo.toronto.edu/pub/news.txt.Z, June 1994. 1769 Appendix A. Acknowledgments 1771 As this document is the result of an eight year effort, the number of 1772 people that have contributed to its content are too numerous to 1773 mention individually. Many thanks go out to all past and present 1774 members of the USEFOR Working Group of the Internet Engineering Task 1775 Force (IETF) and its accompanying mailing list. 1777 Appendix B. Differences from RFC 1036 and its derivatives 1779 This appendix contains a list of changes that have been made in the 1780 Netnews Article Format from earlier standards, specifically 1781 [RFC1036]. 1783 o The [RFC2822] conventions for parenthesis-enclosed s in 1784 header fields are supported in all newly defined header fields and 1785 in header fields inherited from [RFC2822]. They are, however, 1786 still disallowed for performance and/or compatibility reasons in 1787 the Control, Distribution, Followup-To, Lines, Message-ID, 1788 Newsgroups, Path, Supersedes, and Xref header fields. 1790 o Multiple addreses are allowed in the From header field. 1792 o [FWS] is permitted in Newsgroups header fields. 1794 o An enhanced syntax for the Path header field enables the injection 1795 point of, and the route taken by, an article to be determined with 1796 more precision. 1798 o Only one (1) message identifier is allowed in the Supersedes 1799 header field. 1801 o MIME is recognized as an integral part of Netnews. 1803 o There is a new Injection-Date header field to make the rejection 1804 of stale articles more precise and to minimize spurious 1805 rejections. 1807 o There are several new optional header fields defined, notably 1808 Archive, Injection-Info, and User-Agent, leading to increased 1809 functionality. 1811 o Certain header fields, notably Lines, have been deprecated or made 1812 obsolete (Section 3.3). 1814 o The convention to interpret subjects starting with the word "cmsg" 1815 as a control message was removed. 1817 o There are numerous other small changes, clarifications, and 1818 enhancements. 1820 Appendix C. Differences from RFC 2822 1822 This appendix lists the differences between the syntax allowed by the 1823 Netnews Article Format (this document) as compared to the Internet 1824 Message Format, as specified in [RFC2822]. 1826 The Netnews article format is a strict subset of the Internet Message 1827 Format; all Netnews articles conform to the syntax of [RFC2822]. 1829 The following restrictions are important: 1831 o A SP (space) is REQUIRED after the colon (':') following a header 1832 field name. 1834 o A more restricted syntax of (to be used by the 1835 Message-ID, References, and Supersedes header fields) is defined. 1837 o The length of a MUST NOT exceed 250 octets. 1839 o Comments are not allowed in the Message-ID header field. 1841 o The CFWS between s in the References header field is not 1842 optional. 1844 o It is legal for a parser to reject obsolete syntax, except that: 1846 * The construct MUST be accepted. 1848 * The obsolete "GMT" MUST be accepted within a 1849 . 1851 o Every line of a header field body (including the first and any 1852 that are subsequently folded) MUST contain at least one non- 1853 whitespace character. This means that an empty header field body 1854 is illegal. 1856 Authors' Addresses 1858 Kenneth Murchison (editor) 1859 Carnegie Mellon University 1860 5000 Forbes Avenue 1861 Cyert Hall 285 1862 Pittsburgh, PA 15213 1863 U.S.A. 1865 Phone: +1 412 268 2638 1866 Email: murch@andrew.cmu.edu 1868 Charles H. Lindsey 1869 University of Manchester 1870 5 Clerewood Avenue 1871 Heald Green 1872 Cheadle 1873 Cheshire SK8 3JU 1874 U.K. 1876 Phone: +44 161 436 6131 1877 Email: chl@clerew.man.ac.uk 1879 Dan Kohn 1880 FlyDash, Inc. 1881 425 Alma St. #411 1882 Palo Alto, CA 94301 1883 U.S.A. 1885 Phone: +1 415 233 1000 1886 Email: dan@dankohn.com 1888 Full Copyright Statement 1890 Copyright (C) The Internet Society (2006). 1892 This document is subject to the rights, licenses and restrictions 1893 contained in BCP 78, and except as set forth therein, the authors 1894 retain all their rights. 1896 This document and the information contained herein are provided on an 1897 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1898 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1899 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1900 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1901 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1902 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1904 Intellectual Property 1906 The IETF takes no position regarding the validity or scope of any 1907 Intellectual Property Rights or other rights that might be claimed to 1908 pertain to the implementation or use of the technology described in 1909 this document or the extent to which any license under such rights 1910 might or might not be available; nor does it represent that it has 1911 made any independent effort to identify any such rights. Information 1912 on the procedures with respect to rights in RFC documents can be 1913 found in BCP 78 and BCP 79. 1915 Copies of IPR disclosures made to the IETF Secretariat and any 1916 assurances of licenses to be made available, or the result of an 1917 attempt made to obtain a general license or permission for the use of 1918 such proprietary rights by implementers or users of this 1919 specification can be obtained from the IETF on-line IPR repository at 1920 http://www.ietf.org/ipr. 1922 The IETF invites any interested party to bring to its attention any 1923 copyrights, patents or patent applications, or other proprietary 1924 rights that may cover technology that may be required to implement 1925 this standard. Please address the information to the IETF at 1926 ietf-ipr@ietf.org. 1928 Acknowledgment 1930 Funding for the RFC Editor function is provided by the IETF 1931 Administrative Support Activity (IASA).