idnits 2.17.1 draft-ietf-usefor-usefor-08.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 1835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1825. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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. -- The draft header indicates that this document obsoletes RFC1036, but the abstract doesn't seem to directly say this. It does mention RFC1036 though, so this could be OK. 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 (May 22, 2006) is 6549 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 1091, but not defined == Missing Reference: 'CFWS' is mentioned on line 1217, 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 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 (~~), 5 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 Expires: November 23, 2006 University of Manchester 6 D. Kohn 7 FlyDash, Inc. 8 May 22, 2006 10 Netnews Article Format 11 draft-ietf-usefor-usefor-08 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 November 23, 2006. 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 47 supersedes RFC 1036, updating it to reflect current practice and 48 incorporating incremental changes specified in other documents. 50 Changes since draft-ietf-usefor-usefor-07 52 o Reworked ABNF for Path header field keywords (ticket #1047). 54 o Removed definition of "sender" in Injection-Info header field 55 (ticket #1159). 57 o Reworded description of "posting-account" in Injection-Info header 58 field (ticket #1159). 60 o Discussed the use of [FWS] in Newsgroups, Followup-To, and 61 Distribution header fields (ticket #1178). 63 o Further clarification of *WSP vs. [FWS] in Section 2.2 (ticket 64 #1179). 66 o Miscellaneous editorial changes from Dan Kohn. 68 Changes since draft-ietf-usefor-usefor-06 70 o Reworked ABNF for Path header field delimiters and components 71 (ticket #1047). 73 o Imported ABNF elements from reference docs (ticket #1155). 75 o Added IANA registration for header fields per RFC 3864 (ticket 76 #1156). 78 o New ABNF for Control header field (ticket #1157). 80 o Better ABNF for (ticket #1158). 82 o Added new definitions and advice on sender vs. posting-account in 83 Injection-Info header field (ticket #1159). 85 o New ABNF for Archive and Injection-Info header fields, including 86 note regarding CFWS and (ticket #1177). 88 o Replaced leading/trailing [FWS] with *WSP in header field ANBF 89 (ticket #1179). 91 o Using RFC 4234 as a reference instead of RFC 2234. 93 o Removed reference to RFC 0977 -- using only 94 draft-ietf-nntpext-base. 96 o Added note about Expires being defined by RFC 2156. 98 o Miscellaneous editorial changes. 100 Changes since draft-ietf-usefor-usefor-05 102 o Finalized ABNF for (ticket #1003). 104 o Further cleanup of description for Newsgroups header field (ticket 105 #1021). 107 o Fixed ABNF for (ticket #1028). 109 o Began adding text for differences from RFC 1036 (ticket #1032). 111 o Added text regarding hard-to-parse MIME boundaries (ticket #1046). 113 o Reworked/redefined Path header field delimiters and components 114 (ticket #1047). 116 o Added more differences from RFC 2822 (ticket #1052). 118 o Added text for relationship to RFC 2822 (ticket #1053). 120 o Listed header fields which don't permit CFWS (ticket #1079). 122 o Applied text from ticket #1080 (Injection-Info MIME params). 124 o Added more text Approved header field semantics (ticket #1082). 126 o Added text regarding Injection-Date being mandatory/optional 127 (ticket #1088). 129 o Reworked definitions of "agents", etc (ticket #1102). 131 o Removed RFC 2821 as a normative reference. 133 o Miscellaneous editorial changes. 135 Changes since draft-ietf-usefor-usefor-04 137 o Updated to newer references (ticket #1002). 139 o Cleaned up ABNF for (ticket #1003). 141 o Deprecated X- headers (ticket #1004). 143 o Clarified relationship between followups and References header 144 field (ticket #1008). 146 o Cleaned up ABNF and description for Newsgroups header field 147 (ticket #1021). 149 o Tweaked language regarding the use of (ticket #1022). 151 o Tweaked language regarding GMT timezone and Date header field 152 (ticket #1028). 154 o Added language warning against folding Newsgroups header field 155 (ticket #1042). 157 o Use RFC 2822 term "header field" instead of "header" (ticket 158 #1043). 160 o Starting adding differences from RFC 2822 (ticket #1052). 162 o Miscellaneous editorial changes. 164 Changes since draft-ietf-usefor-usefor-03 166 o Reworked ABNFs of several headers. 168 o Used Charles' ABNF for . 170 o Disallowed comments in Supersedes header. 172 o Disallowed comments in Xref header. 174 o Disallowed comments in Message-Id header. 176 o CFWS between msg-ids in References header is not optional. 178 o Compatibility changes based on comments from Charles. 180 o Miscellaneous editorial changes. 182 Changes since draft-ietf-usefor-usefor-02 184 o Changed to RFC 3978 boilerplate (xml2rfc v1.29) 185 o Changed "network news" to "Netnews" throughout. 187 o Prohibit NO-WS-CTL in msg-id. 189 o Complaints-To header is now an Injection-Info parameter. 191 o Added descriptions of Injection-Info parameters. 193 o Removed "filename" parameter from Archive header. 195 o Added CFWS to User-Agent header. 197 o Miscellaneous editorial changes. 199 Changes since draft-ietf-usefor-usefor-01 201 o Removed half-hearted discussion of internal format and 8-bit clean 202 transport. 204 o Added definitions of "proto-article", "posting agent", "followup", 205 "followup-agent", "user-agent", and "injecting agent". 207 o Removed discussion of message/partial MIME messages. 209 o Noted that the header contents in every line MUST NOT be empty. 211 o Merged MIME sections. 213 o Only allow "UT" and "GMT" in Date header; disallow all other . 216 o Used Charles' ABNF for and . 218 o Removed restrictions on length and start character for Newsgroups. 220 o More verbose description of Path header. 222 o Disallowed comments in Control header. 224 o Specified that is a verb optionally followed by 225 whitespace-separated arguments. 227 o Noted that Supersedes header is different from [Son-of-1036]. 229 o More exact ABNF for Archive and Injection-Info parameters. 231 o Discussed meaning of "yes", "no" in Archive header. 233 o Added "Obsolete Headers" section. 235 o Miscellaneous editorial changes 237 Changes since draft-ietf-usefor-article-13 239 o The Mail-Copies-To, Posted-And-Mailed headers have been moved to 240 other documents. 242 o Dropped MIME parameters, as there is no WG consensus (per Chair). 244 o More exact ABNF for Archive and Injection-Info parameters. 246 o Complaints-To header is now an Injection-Info parameter. 248 Issues to be addressed 250 o Path header field delimiters and components ABNF (ticket #1047). 252 o Whitespace in Path header field (ticket #1178). Editor isn't 253 clear on what the issue actually is. 255 Table of Contents 257 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 9 258 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 9 259 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 260 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 9 261 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 262 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 263 1.6. Structure of This Document . . . . . . . . . . . . . . . . 11 264 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 265 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 266 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 267 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 15 268 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 16 269 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 16 270 3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 17 271 3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 17 272 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 17 273 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 19 274 3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 20 275 3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 21 276 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 23 277 3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 23 278 3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 24 279 3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 24 280 3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 25 281 3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 25 282 3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 26 283 3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 26 284 3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 27 285 3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 27 286 3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 27 287 3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 27 288 3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 28 289 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 28 290 3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 29 291 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 31 292 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 32 293 4. Internationalization Considerations . . . . . . . . . . . . . 33 294 5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 295 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 296 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 297 7.1. Normative References . . . . . . . . . . . . . . . . . . . 40 298 7.2. Informative References . . . . . . . . . . . . . . . . . . 41 299 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43 300 Appendix B. Differences from RFC 1036 and its derivatives . . . . 44 301 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 45 302 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 303 Intellectual Property and Copyright Statements . . . . . . . . . . 47 305 1. Introduction 307 1.1. Basic Concepts 309 "Netnews" is a set of protocols for generating, storing and 310 retrieving news "articles" (whose format is a subset of that for 311 Email messages) and for exchanging them amongst a readership which is 312 potentially widely distributed. It is organized around "newsgroups", 313 with the expectation that each reader will be able to see all 314 articles posted to each newsgroup in which he participates. These 315 protocols most commonly use a flooding algorithm which propagates 316 copies throughout a network of participating servers. Typically, 317 only one copy is stored per server, and each server makes it 318 available on demand to readers able to access that server. 320 1.2. Scope 322 This document specifies the syntax of Netnews articles in the context 323 of the "Internet Message Format" [RFC2822] and "Multipurpose Internet 324 Mail Extensions (MIME)" [RFC2045]. This document supersedes 325 [RFC1036], updating it to reflect current practice and incorporating 326 changes and clarifications specified in other documents such as [Son- 327 of-1036]. 329 This is the first in a set of documents that obsolete [RFC1036]. 330 This document focuses on the syntax and semantics of Netnews 331 articles. [I-D.ietf-usefor-usepro] is also a standards-track 332 document, and describes the protocol issues of Netnews articles, 333 independent of transport protocols such as [I-D.ietf-nntpext-base]. 334 A best common practice document, [I-D.ietf-usefor-useage], describes 335 implementation recommendations to improve interoperability and 336 usability. 338 This specification is intended as a definition of what article 339 content format is to be passed between systems. Although some news 340 systems locally store articles in this format (which eliminates the 341 need for translation between formats), local storage is outside of 342 the scope of this standard. 344 1.3. Requirements Notation 346 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 347 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 348 document are to be interpreted as described in [RFC2119]. 350 1.4. Syntax Notation 352 Header fields defined in this specification use the Augmented Backus- 353 Naur Form (ABNF) notation (including the Core Rules) specified in 354 [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as 355 updated by [RFC2231], and [RFC3986], specifically: 357 token = 358 dot-atom-text = 360 parameter = 361 attribute = 363 FWS = 364 CFWS = 365 atext = 366 dot-atom-text = 367 phrase = 368 utext = 369 date-time = 370 mailbox = 371 mailbox-list = 372 address-list = 373 fields = 375 IPv6address = 376 IPv4address = 378 ALPHA = 379 CRLF = 380 DIGIT = 381 DQUOTE = 382 SP = 384 Additionally, Section 3.1.3 specifies a stricter definition of 385 than the syntax in [RFC2822] Section 3.6.4. 387 1.5. Definitions 389 An "article" is the unit of Netnews, analogous to an [RFC2822] 390 "message". A "proto-article" is one that has not yet been injected 391 into the news system. In contrast to an "article", a "proto-article" 392 may lack some mandatory header fields. 394 A "message identifier" (Section 3.1.3) is a unique identifier for an 395 article, usually supplied by the "user agent" that posted it or, 396 failing that, by the "news server". It distinguishes the article 397 from every other article ever posted anywhere. Articles with the 398 same message identifier are treated as if they are the same article 399 regardless of any differences in the body or header fields. 401 A "newsgroup" is a single forum having a name and intended for 402 articles on a specific topic. An article is "posted to" a single 403 newsgroup or several newsgroups. When an article is posted to more 404 than one newsgroup, it is said to be "crossposted"; note that this 405 differs from posting the same text as part of each of several 406 articles, one per newsgroup. 408 A newsgroup may be "moderated", in which case submissions are not 409 posted directly, but mailed to a "moderator" for consideration and 410 possible posting. Moderators are typically human but may be 411 implemented partially or entirely in software. 413 A "poster" is the person or software that composes and submits a 414 possibly compliant article to a "user agent". The poster is 415 analogous to an [RFC2822] author. 417 A "reader" is the person or software reading news articles. 419 A "followup" is an article containing a response to the contents of 420 an earlier article, its "precursor". Every followup includes a 421 "References" header field identifying that precursor (but note that 422 non-followup articles may also use a References header field). 424 A "control message" is an article which is marked as containing 425 control information; a news server receiving such an article may 426 (subject to the policies observed at that site) take actions beyond 427 just filing and passing on the article. 429 A "news server" is software that may accept articles from a "user 430 agent", and/or make articles available to user agents, and/or 431 exchange articles with other news servers. 433 A "user agent" is software that may help posters submit proto- 434 articles to a news server, and/or fetch articles from a news server 435 and present them to a reader, and/or assist the reader in creating 436 articles and followups. 438 The generic term "agent" is used when describing requirements that 439 apply to both user agents and news servers. 441 1.6. Structure of This Document 443 This document uses a cite by reference methodology, rather than 444 repeating the contents of other standards, which could otherwise 445 result in subtle differences and interoperability challenges. 446 Although this document is as a result rather short, it requires 447 complete understanding and implementation of the normative references 448 to be compliant. 450 Section 2 defines the format of Netnews articles. Section 3 details 451 the header fields necessary to make an article suitable for the 452 Netnews environment. 454 2. Format 456 2.1. Base 458 An article is said to be conformant to this specification if it 459 conforms to the format specified in [RFC2822] Section 3 and to the 460 additional requirements of this specification. 462 An article that uses the obsolete syntax specified in Section 4 of 463 [RFC2822] is NOT conformant to this specification, except for 464 following two cases: 466 o Articles are conformant if they use the construct 467 (use of a phrase like "John Q. Public" without the use of quotes, 468 see [RFC2822] Section 4.1) but agents MUST NOT generate 469 productions of such syntax. 471 o Articles are conformant if they use the "GMT" , as specified 472 in Section 3.1.2. 474 This document, and specifications that build upon it, specify how to 475 handle conformant articles. Handling of non-conformant articles is 476 outside the scope of this specification. 478 Agents conforming to this specification MUST generate only conformant 479 articles. 481 The text below uses ABNF to specify restrictions on the syntax 482 specified in [RFC2822]; this grammar is intended to be more 483 restrictive than the [RFC2822] grammar. Articles must conform to the 484 ABNF specified in [RFC2822]. 486 Articles must also conform to the restrictions specified here, both 487 those that are expressed as text and those that are expressed as 488 ABNF. 490 NOTE: Other specifications use the term "header" as a synonym for 491 what [RFC2822] calls "header field". This document follows the 492 terminology in Section 2 of [RFC2822] in using the terms "line", 493 "header field", "header field name", "header field body", and 494 "folding", based on a belief that consistent terminology among 495 specifications that depend on each other makes the specifications 496 easier to use in the long run. 498 2.2. Header Fields 500 All header fields in a news article are compliant with [RFC2822], 501 however this specification is less permissive in what can be 502 generated and accepted by news agents. The syntax allowed for news 503 articles is a strict subset of the "Internet Message Format", making 504 all messages compliant with this specification inherently compliant 505 with [RFC2822]. Note however that the converse is not guaranteed to 506 be true in all cases. 508 General rules which apply to all header fields (even those documented 509 in [RFC2822] and [RFC2045]) are listed below and those that apply to 510 specific header fields are described in the relevant sections of this 511 document. 513 o All agents MUST generate header fields so that at least one space 514 immediately follows the ':' separating the header field name and 515 the header field body (for compatibility with deployed software, 516 including [I-D.ietf-nntpext-base] servers). News agents MAY 517 accept header fields which do not contain the required space. 519 o Every line of a header field body (including the first and any 520 that are subsequently folded) MUST contain at least one non- 521 whitespace character. 523 NOTE: This means that no header field body defined by or 524 referenced by this document can be empty. As a result, rather 525 than using the syntax from Section 3.2.6 of 526 [RFC2822], this document uses a stricter definition: 528 unstructured = *WSP utext *( [FWS] utext ) *WSP 530 NOTE: The [RFC2822] specification sometimes uses [FWS] at the 531 beginning or end of ABNF describing header field content. This 532 specification uses *WSP in such cases, also in cases where this 533 specification redefines constructs from [RFC2822]. This is 534 done for consistency with the restriction described here, but 535 the restriction applies to all header fields, not just those 536 where ABNF is defined in this document. 538 o Compliant software MUST NOT generate (but MAY accept) header 539 fields of more than 998 octets. This is the only limit on the 540 length of a header field prescribed by this standard. However, 541 specific rules to the contrary may apply in particular cases (for 542 example, according to [RFC2047] lines of a header field containing 543 encoded-words are limited to 76 octets). [I-D.ietf-usefor-useage] 544 includes suggested limits for convenience of display by user 545 agents. 547 NOTE: There is NO restriction on the number of lines into which 548 a header field may be split, and hence there is NO restriction 549 on the total length of a header field (in particular it may, by 550 suitable folding, be made to exceed the 998 octets restriction 551 pertaining to a single header line). 553 o The character set for header fields is US-ASCII. Where the use of 554 non-ASCII characters is required, they MUST be encoded using the 555 MIME mechanisms defined in [RFC2047] and [RFC2231]. 557 2.3. MIME Conformance 559 User agents MUST meet the definition of MIME-conformance in [RFC2049] 560 and MUST also support [RFC2231]. This level of MIME Conformance 561 provides support for internationalization and multimedia in message 562 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 563 internationalization of header fields ([RFC2047], [RFC2231]). Note 564 that [Errata] currently exist for [RFC2046] and [RFC2231]. 566 For the purposes of Section 5 of [RFC2047], all header fields defined 567 in Section 3 of this standard are to be considered as "extension 568 message header fields", permitting the use of [RFC2047] encodings 569 within any header field, or within any or 570 permitted within any structured header field. 572 User agents MAY accept and generate other MIME extension header 573 fields, and in particular SHOULD accept Content-Disposition [RFC2183] 574 and Content-Language [RFC3282]. 576 3. News Header Fields 578 The following news header fields extend those defined in Section 3.6 579 of [RFC2822]: 581 fields =/ *( newsgroups / 582 path / 583 injection-date / 584 followup-to / 585 expires / 586 control / 587 supersedes / 588 distribution / 589 summary / 590 approved / 591 organization / 592 xref / 593 archive / 594 user-agent / 595 injection-info / 596 lines ) 598 Each of these header fields may occur at most once in a news article. 600 The following header fields defined in this document do not allow 601 comments (CFWS): 603 Newsgroups 604 Path 605 Followup-To 606 Control 607 Supersedes 608 Distribution 609 Xref 610 Lines 612 This also applies to the following header field defined in [RFC2822]: 614 Message-ID 616 Most of these header fields are mainly of interest to news servers, 617 and news servers often need to process these fields very rapidly. 618 Thus some header fields prohibit comments. 620 3.1. Mandatory Header Fields 622 Each news article conformant with this specification MUST have 623 exactly one of each of the following header fields: From, Date, 624 Message-ID, Subject, Newsgroups, Path. 626 3.1.1. From 628 The From header field is the same as that specified in Section 3.6.2 629 of [RFC2822] with the added restrictions detailed in Section 2.2. 631 from = "From:" SP mailbox-list CRLF 633 3.1.2. Date 635 The Date header field is the same as that specified in Sections 3.3 636 and 3.6.1 of [RFC2822] with the added restrictions detailed in 637 Section 2.2. However, the use of "GMT" as a time zone (part of ), although deprecated, is widespread in news articles today. 639 Therefore, agents MUST accept constructs that use the 640 "GMT" zone. 642 orig-date = "Date:" SP date-time CRLF 644 NOTE: This specification does not change [RFC2822], which says 645 that agents MUST NOT generate constructs which include 646 any zone names defined by . 648 Software that accepts dates with unknown timezones SHOULD treat such 649 timezones as equivalent to "-0000" when comparing dates, as specified 650 in [RFC2822] Section 4.3. 652 Also note that these requirements apply wherever is used, 653 including Injection-Date and Expires in Section 3.2.1 and 654 Section 3.2.4 respectively. 656 3.1.3. Message-ID 658 The Message-ID header field contains a single unique message 659 identifier. Netnews is more dependent on message identifier 660 uniqueness and fast comparison than Email is, and some news software 661 and standards [I-D.ietf-nntpext-base] might have trouble with the 662 full range of possible s permitted by [RFC2822]. This 663 section therefore restricts the syntax of as compared to 664 Section 3.6.4 of [RFC2822]. The global uniqueness requirement for 665 in [RFC2822] is to be understood as applying across all 666 protocols using such message identifiers, and across both Email and 667 Netnews in particular. 669 message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF 671 msg-id = "<" id-left "@" id-right ">" 672 ; maximum length is 250 octets 674 id-left = dot-atom-text / no-fold-quote 676 id-right = dot-atom-text / no-fold-literal 678 no-fold-quote = DQUOTE 679 ( "." *mqtext / 680 *mqtext "." / 681 *mqtext mqspecial *mqtext ) 682 DQUOTE 684 mqtext = atext / "." / mqspecial 686 mqspecial = "(" / ")" / ; same as specials except 687 "<" / ; "\" and DQUOTE quoted 688 "[" / "]" / ; "." doubled and ">" omitted 689 ":" / ";" / 690 "@" / "," / 691 ".." / "\\" / "\" DQUOTE 693 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 695 mdtext = %d33-61 / ; The rest of the US-ASCII 696 %d63-90 / ; characters not including 697 %d94-126 ; ">", "[", "]", or "\" 699 The msg-id MUST NOT be more than 250 octets in length. 701 NOTE: The length restriction ensures that systems that accept 702 message identifiers as a parameter when retrieving an article 703 (e.g. [I-D.ietf-nntpext-base]) can rely on a bounded length. 705 Observe that msg-id includes the < and >. 707 Observe also that in contrast to the corresponding header field in 708 [RFC2822]: 710 o the syntax does not allow comments within the Message-ID header 711 field, 713 o it ensures that no string of characters is quoted if it were 714 already a (it MUST start or end with a ".", or 715 contain at least one ), 717 o it ensures that no single character is prefixed by a "\" in the 718 form of a unless strictly necessary, 720 o it excludes all control characters, 722 o there is no possibility for ">" or WSP to occur inside a , 723 whether quoted or not, and 725 o even though commonly derived from s, s are 726 case-sensitive (and thus, once created, are not to be altered 727 during subsequent transmission or copying) 729 This is to simplify processing by news servers and to ensure 730 interoperability with existing implementations and compliance with 731 [I-D.ietf-nntpext-base]. Thus, whereas under [RFC2822] the following 732 s would be considered semantically equivalent, 734 735 <"ab.cd"@example.com> 736 <"ab.\cd"@example.com> 738 only the first of them is syntactically permitted by this standard, 739 and hence a simple comparison of octets will always suffice to 740 determine the identity of two s. 742 Also note that this updated ABNF applies wherever is used, 743 including the References header field discussed in Section 3.2.2 and 744 the Supersedes header field discussed in Section 3.2.6. 746 Some software will try to match the of a in a 747 case-insensitive fashion; some will match it in a case-sensitive 748 fashion. Implementations MUST NOT generate two Message-IDs where the 749 only difference is the case of characters in the part. 751 When generating a , implementations SHOULD use a domain name 752 as the . 754 NOTE: Section 3.6.4 of [RFC2822] recommends that the 755 should be a domain name or a domain literal. Domain literals are 756 troublesome since many IP addresses are not globally unique; 757 domain names are more likely to generate unique Message-IDs. 759 3.1.4. Subject 761 The Subject header field is the same as that specified in Section 762 3.6.5 of [RFC2822] with the added restrictions detailed in 763 Section 2.2. Further discussion of the content of the Subject header 764 field appears in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor- 765 useage]. 767 subject = "Subject:" SP unstructured CRLF 769 3.1.5. Newsgroups 771 The Newsgroups header field specifies the newsgroup(s) to which the 772 article is posted. 774 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 776 newsgroup-list = *WSP newsgroup-name 777 *( [FWS] "," [FWS] newsgroup-name ) *WSP 779 newsgroup-name = component *( "." component ) 781 component = 1*component-char 783 component-char = ALPHA / DIGIT / "+" / "-" / "_" 785 Not all servers support [FWS] in the list of newsgroups. In 786 particular, folding the Newsgroups header field over several lines 787 has been shown to harm propagation significantly. [FWS] in the 788 SHOULD NOT be generated, but MUST be accepted. 790 A newsgroup component SHOULD NOT consist of digits only, and SHOULD 791 NOT contain uppercase letters. Such components MAY be used only to 792 refer to existing groups that do not conform to this naming scheme. 794 NOTE: All-digit components conflict with one widely used storage 795 scheme for articles. Mixed case groups cause confusion between 796 systems with case sensitive matching and systems with case 797 insensitive matching of s. 799 s beginning with underline ("_") are reserved for use by 800 future versions of this standard and MUST NOT be generated by user 801 agents (whether in Newsgroups header fields or in newgroup control 802 messages [I-D.ietf-usefor-usepro]). However, such names MUST be 803 accepted by news servers. 805 s beginning with "+" and "-" are reserved for private use 806 and MUST NOT be generated by user agents (whether in Newsgroups 807 header fields or in newgroup control messages [I-D.ietf-usefor- 808 usepro]) without a private prior agreement to do so. However, such 809 names MUST be accepted by news servers. 811 The following s are reserved, and MUST NOT be used as 812 the name of a newsgroup: 814 o Groups whose first (or only) component is "example" 816 o The group "poster" 818 The following s have been used for specific purposes 819 in various implementations and protocols, and therefore MUST NOT be 820 used for the names of normal newsgroups. They MAY be used for their 821 specific purpose, or by local agreement. 823 o Groups whose first (or only) component is "to" 825 o Groups whose first (or only) component is "control" 827 o Groups which contain (or consist only of) the component "all" 829 o Groups which contain (or consist only of) the component "ctl" 831 o The group "junk" 833 NOTE: "example.*" is reserved for examples in this and other 834 standards; "poster" has a special meaning in the Followup-To 835 header field; "to.*" is reserved for certain point-to-point 836 communications in conjunction with the "ihave" control message 837 [I-D.ietf-usefor-usepro]; "control.*" and "junk" have special 838 meanings in some news-servers; "all" is used as a wildcard in some 839 implementations; and "ctl" was formerly used to indicate a 840 within the Subject header field. 842 3.1.6. Path 844 The Path header field indicates the route taken by an article since 845 its injection into the Netnews system. Each agent that processes an 846 article is required to prepend at least one to this 847 header field body. This is primarily to enable news servers to avoid 848 sending articles to sites already known to have them, in particular 849 the site they came from, and additionally to permit tracing the route 850 articles take in moving over the network, and for gathering 851 statistics. 853 path = "Path:" SP *WSP path-list tail-entry *WSP CRLF 855 path-list = *( path-identity [FWS] [path-diagnostic] "!" ) 857 path-diagnostic = diag-match / diag-other / diag-deprecated 859 diag-match = "!" ; another "!" 861 diag-other = "!." diag-keyword [ "." diag-identity ] [FWS] 863 diag-deprecated = "!" IPv4address [FWS] 865 diag-keyword = 1*ALPHA ; see USEPRO 867 diag-identity = path-identity / IPv4address / IPv6address 869 tail-entry = path-nodot 870 ; may be the string "not-for-mail" 872 path-identity = ( 1*( label "." ) toplabel ) / path-nodot 874 path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names 876 label = alphanum [ *( alphanum / "-" ) alphanum ] 878 toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / 879 ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / 880 ( label 1*( "-" ) label ) 882 alphanum = ALPHA / DIGIT ; compare RFC3696 884 A is a name identifying a site. It takes the form of 885 a domain name having two or more components separated by dots, or a 886 single name with no dots (). 888 Each in the (which does not include the 889 ) indicates, from right to left, the successive agents 890 through which the article has passed. The use of the , 891 which appears as "!!", indicates that the agent to its left verified 892 the identity of the agent to its right before accepting the article 893 (whereas the "!" implies no such claim). 895 NOTE: Historically, the indicated the name of the 896 sender. If not used for this purpose, the string "not-for-mail" is 897 often used instead (since at one time the whole path could be used as 898 a mail address for the sender). 900 NOTE: Although case-insensitive, it is intended that the s should be in upper case, to distinguish them from the 902 s which are traditionally in lower case. 904 A is an item inserted into the Path header field 905 for purposes other than to indicate the name of a site. The use of 906 these is described in [I-D.ietf-usefor-usepro]. 908 NOTE: One usage of a is to record an IP address. 909 The fact that IPv6 addresses are allowed means that the colon (:) is 910 permitted; note that this may cause interoperability problems at 911 older sites that regard ":" as a and have neighbors 912 whose names have 4 or fewer characters, and where all the characters 913 are valid HEX digits. 915 3.2. Optional Header Fields 917 None of the header fields appearing in this section is required to 918 appear in every article but some of them may be required in certain 919 types of articles. Further discussion of these requirements appears 920 in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage]. 922 The header fields Reply-To, Sender, Comments, and Keywords are used 923 in news articles in the same circumstances and with the same meaning 924 as that specified in [RFC2822] with the added restrictions detailed 925 in Section 2.2. Multiple occurances of the Keywords header field are 926 not permitted. 928 sender = "Sender:" SP mailbox CRLF 930 reply-to = "Reply-To:" SP address-list CRLF 932 comments = "Comments:" SP unstructured CRLF 934 keywords = "Keywords:" SP phrase *("," phrase) CRLF 936 The MIME header fields MIME-Version, Content-Type, Content-Transfer- 937 Encoding, Content-Disposition, and Content-Language are used in news 938 articles in the same circumstances and with the same meanings as 939 those specified in [RFC2045], [RFC2183], and [RFC3282] with the added 940 restrictions detailed in Section 2.2. 942 All remaining news header fields are described below. 944 3.2.1. Injection-Date 946 The Injection-Date header field contains the date and time that the 947 article was injected into the network. Its purpose is to prevent the 948 reinjection into the news stream of "stale" articles which have 949 already expired by the time they arrive at some news server. 951 This header field MUST be inserted whenever an article is injected. 952 However, software that predates this standard does not use this 953 header, and therefore agents MUST accept articles without the 954 Injection-Date header field. 956 injection-date = "Injection-Date:" SP date-time CRLF 958 See the remarks under Section 3.1.2 regarding the syntax of 959 and the requirements and recommendations to which it is 960 subject. 962 NOTE: Since clocks on various agents may not be synchronized, the 963 in this header field may not be later than the Date 964 header field, as would be expected. Agents SHOULD use the they believe is correct when adding Inject-Info but SHOULD 966 NOT alter the pre-existing Date header field. 968 This header field is intended to replace the currently-used but 969 undocumented "NNTP-Posting-Date" header field, whose use is now 970 deprecated. 972 3.2.2. References 974 The References header field is the same as that specified in Section 975 3.6.4 of [RFC2822] with the added restrictions detailed in 976 Section 2.2 and those listed below: 978 o The updated construct defined in Section 3.1.3 MUST be 979 used. 981 o Message identifiers MUST be separated with CFWS. 983 o Comments in CFWS between message identifiers can cause 984 interoperability problems, so comments SHOULD NOT be generated, 985 but MUST be accepted. 987 references = "References:" SP [CFWS] msg-id *(CFWS msg-id) 988 [CFWS] CRLF 990 3.2.3. Followup-To 992 The Followup-To header field specifies to which newsgroup(s) 993 followups should be posted. The Followup-To header field SHOULD NOT 994 appear in a message, unless its content is different from the content 995 of the Newsgroups header field. 997 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 998 CRLF 1000 poster-text = *WSP %d112.111.115.116.101.114 *WSP 1001 ; "poster" in lower-case 1003 The syntax is the same as that of the Newsgroups (Section 3.1.5) 1004 header field, with the exception that the keyword "poster" requests 1005 that followups should be mailed to the article's reply address rather 1006 than posted. Agents MUST generate the keyword "poster" in lower- 1007 case, but MAY choose to recognize case-insensitive forms such as 1008 "Poster". 1010 As in the Newsgroups (Section 3.1.5) header field, [FWS] in the 1011 SHOULD NOT be generated, but MUST be accepted. 1013 3.2.4. Expires 1015 The Expires header field specifies a date and time when the article 1016 is deemed to be no longer relevant and could usefully be removed 1017 ("expired"). 1019 expires = "Expires:" SP date-time CRLF 1021 See the remarks under Section 3.1.2 regarding the syntax of 1022 and the requirements and recommendations to which it is 1023 subject. 1025 NOTE: The Expires header field is also sometimes used in Email 1026 with a similar meaning [RFC2156]. 1028 3.2.5. Control 1030 The Control header field marks the article as a control message, and 1031 specifies the desired actions (additional to the usual ones of 1032 storing and/or relaying the article). 1034 control = "Control:" SP *WSP control-command *WSP CRLF 1036 control-command = verb *( 1*WSP argument ) 1038 verb = token 1040 argument = 1*( %x21-7E ) 1042 The verb indicates what action should be taken, and the argument(s) 1043 (if any) supply details. In some cases, the body of the article may 1044 also contain details. The legal verbs and respective arguments are 1045 discussed in the companion document, [I-D.ietf-usefor-usepro]. 1047 An article with a Control header field MUST NOT also have a 1048 Supersedes header field. 1050 3.2.6. Supersedes 1052 The Supersedes header field contains a message identifier specifying 1053 an article to be superseded upon the arrival of this one. An article 1054 containing a Supersedes header field is equivalent to a "cancel" 1055 [I-D.ietf-usefor-usepro] control message for the specified article, 1056 followed immediately by the new article without the Supersedes header 1057 field. 1059 supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF 1061 NOTE: There is no "c" in Supersedes. 1063 NOTE: The Supersedes header field defined here has no connection 1064 with the Supersedes header field that sometimes appears in Email 1065 messages converted from X.400 according to [RFC2156]; in 1066 particular, the syntax here permits only one in contrast 1067 to the multiple s in that Email version. 1069 3.2.7. Distribution 1071 The Distribution header field specifies geographic or organizational 1072 limits on an article's propagation. 1074 distribution = "Distribution:" SP dist-list CRLF 1076 dist-list = *WSP dist-name 1077 *( [FWS] "," [FWS] dist-name ) *WSP 1079 dist-name = ALPHA / DIGIT 1080 *( ALPHA / DIGIT / "+" / "-" / "_" ) 1082 The s "world" and "local" are predefined. However, 1083 "world" SHOULD NOT be used explicitly, since it is the default when 1084 the Distribution header field is absent entirely. 1086 "All" MUST NOT be used as a . s SHOULD contain 1087 at least three characters, except when they are two-letter country 1088 names drawn from [ISO.3166.1988]. s are case-insensitive 1089 (i.e. "US", "Us", "uS", and "us" all specify the same distribution). 1091 [FWS] in the SHOULD NOT be generated, but MUST be 1092 accepted. 1094 3.2.8. Summary 1096 The Summary header field is a short phrase summarizing the article's 1097 content. 1099 summary = "Summary:" SP unstructured CRLF 1101 3.2.9. Approved 1103 The Approved header field indicates the mailing addresses (and 1104 possibly the full names) of the persons or entities approving the 1105 article for posting. Its principal uses are in moderated articles 1106 and in group control messages [I-D.ietf-usefor-usepro]. 1108 approved = "Approved:" SP mailbox-list CRLF 1110 Each mailbox contained in the Approved header field MUST be that of 1111 one of the person(s) or entity(ies) in question, and one of those 1112 mailboxes MUST be that of the actual sender of the article. Note 1113 that this standard does not provide any means to enforce or verify 1114 this requirement, but future extensions or standards may provide such 1115 a facility (e.g. digitial signatures). 1117 3.2.10. Organization 1119 The Organization header field is a short phrase identifying the 1120 poster's organization. 1122 organization = "Organization:" SP unstructured CRLF 1124 NOTE: There is no "s" in Organization. 1126 3.2.11. Xref 1128 The Xref header field indicates where an article was filed by the 1129 last news server to process it. The article locations are used to 1130 keep track of crossposted articles so that user agents serviced by a 1131 particular news server can mark such articles as read. 1133 xref = "Xref:" SP *WSP server-name 1134 1*( FWS location ) *WSP CRLF 1136 server-name = path-identity 1138 location = newsgroup-name ":" article-locator 1140 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 1141 ; US-ASCII printable characters 1142 ; except '(' and ';' 1144 The is included so that software can determine which 1145 news server generated the header field. The locations specify what 1146 newsgroups the article was filed under (which may differ from those 1147 in the Newsgroups header field) and where it was filed under them. 1148 The exact form of an is implementation-specific. 1150 NOTE: The traditional form of an (as required by 1151 [I-D.ietf-nntpext-base]) is a decimal number, with articles in 1152 each newsgroup numbered consecutively starting from 1. 1154 3.2.12. Archive 1156 The Archive header field provides an indication of the poster's 1157 intent regarding preservation of the article in publicly accessible 1158 long-term or permanent storage. 1160 archive = "Archive:" SP [CFWS] ("no" / "yes") 1161 *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF 1163 archive-param = parameter 1165 The presence of an Archive header field in an article with a field 1166 body of "no" indicates that the poster does not permit redistribution 1167 from publicly accessible long-term or permanent archives. The 1168 absence of this header field, or the presence of this header field 1169 with a field body of "yes", indicates that the poster is willing for 1170 such redistribution to take place. Further extensions to this 1171 standard may provide parameters for administration of the archiving 1172 process. 1174 3.2.13. User-Agent 1176 The User-Agent header field contains information about the user agent 1177 (typically a newsreader) generating the article, for statistical 1178 purposes and tracing of standards violations to specific software 1179 needing correction. It is intended that this header field be 1180 suitable for use in Email. 1182 user-agent = "User-Agent:" SP 1*product [CFWS] CRLF 1184 product = [CFWS] token [ [CFWS] "/" product-version ] 1186 product-version = [CFWS] token 1188 This header field MAY contain multiple product-tokens identifying the 1189 user agent and any subproducts which form a significant part of it, 1190 listed in order of their significance for identifying the 1191 application. 1193 NOTE: Some of this information has previously been sent in non- 1194 standardized header fields such as X-Newsreader, X-Mailer, 1195 X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent 1196 uses User-Agent, it should have no need to send these non-standard 1197 header fields. 1199 NOTE: [RFC2616] describes a similar facility for the HTTP 1200 protocol. This specification differs in that "{" and "}" are 1201 allowed in tokens ( and ) and comments 1202 are permitted wherever whitespace is allowed. 1204 3.2.14. Injection-Info 1206 The Injection-Info header field contains information provided by the 1207 injecting news server as to how an article entered the Netnews system 1208 and to assist in tracing its true origin. It can also specify one or 1209 more addresses where complaints concerning the poster of the article 1210 may be sent. 1212 injection-info = "Injection-Info:" SP [CFWS] path-identity 1213 [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF 1215 NOTE: The syntax of ([RFC2045] Section 5.1 as amended 1216 by [RFC2231]), taken in conjunction with the folding rules of 1217 [RFC0822], effectively allows [CFWS] to occur on either side of 1218 the "=" inside a . 1220 The following table gives the and the format of the 1221 for each defined for use with this header field. 1222 At most one occurrence of each such is allowed. 1224 format of 1225 -------------------- ----------------- 1226 "posting-host" a 1227 "posting-account" any 1228 "logging-data" any 1229 "mail-complaints-to" an 1230 where 1232 host-value = dot-atom-text / IPv4address / IPv6address / 1233 (dot-atom-text ":" ( IPv4address / IPv6address )) 1235 NOTE: Since any such or also has to be 1236 a syntactically correct , it will usually be necessary to 1237 encapsulate it as a , for example: 1239 posting-host = "posting@example.com:192.168.0.1" 1241 Other s SHOULD NOT be used unless defined in extensions to 1242 this standard. If non-standards-based s are used, they 1243 MUST begin with an "x-". 1245 Although comments and folding of white space are permitted throughout 1246 the Injection-Info header field, folding SHOULD NOT be used within 1247 any . Folding SHOULD only occur before or after the ";" 1248 separating s, and comments SHOULD only be used following 1249 the last . 1251 NOTE: Some of this information has previously been sent in non- 1252 standardized header fields such as NNTP-Posting-Host, X-trace, 1253 X-Complaints-To, and others. Once a news server uses Injection- 1254 Info, it should have no need to send these non-standard header 1255 fields. 1257 The "posting-host" specifies the FQDN and/or IP address 1258 (IPv4address or IPv6address) of the host from which the news server 1259 received the article. 1261 NOTE: If the "posting-host" identifies a dial-up 1262 point-of-presence, the "posting-account" or the "logging-data" 1263 may provide additional information about the true 1264 origin of the article. 1266 The "posting-account" identifies the source from which 1267 that news server received the article, in a notation that can be 1268 interpreted by the news server administrator. This notation can 1269 include any information the administrator deems pertinent. In order 1270 to limit the exposure of personal data, it SHOULD be given in a form 1271 that can't be interpreted by other sites. However, to make it useful 1272 for rate limiting and abuse detection, two messages posted from the 1273 same source SHOULD have the same value of "posting-account", and two 1274 messages from different sources SHOULD have differing values of 1275 "posting-account". The exact definition of "source" is left to the 1276 discretion of the news server administrator. 1278 The "logging-data" contains information (typically a 1279 session number or other non-persistent means of identifying a posting 1280 account) that will enable the true origin of the article to be 1281 determined by reference to logging information kept by the news 1282 server. 1284 The "mail-complaints-to" specifies one or more mailboxes 1285 for sending complaints concerning the behavior of the poster of the 1286 article. 1288 It is a matter of local policy which s to include. Some 1289 pieces of information have privacy implications; this is discussed in 1290 [I-D.ietf-usefor-useage]. 1292 3.3. Obsolete Header Fields 1294 Early Netnews software sometimes generated header fields such as: 1296 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP 1297 Posting-Version: version B 2.10 2/13/83; site eagle.UUCP 1298 Date-Received: Friday, 19-Nov-82 16:59:30 EST 1300 Relay-Version contained version information about the news server 1301 that last processed the article. Posting-Version contained version 1302 information about the user agent that posted the article. Date- 1303 Received contained the date when the last news server to process the 1304 article first saw it (in a slightly nonstandard format). 1306 These header fields are mentioned for historical purposes only. 1307 Agents MUST NOT generate articles containing these header fields. 1309 In addition, this standard obsoletes certain header fields defined in 1310 [Son-of-1036]: 1312 Also-Control: cancel <9urrt98y53@site.example> 1313 See-Also: 1314 Article-Names: comp.foo:charter 1315 Article-Updates: 1317 Also-Control indicated a control message that was also intended to be 1318 filed as a normal article. See-Also listed related articles, but 1319 without the specific relationship with followups that pertains to the 1320 References header field. Article-Names indicated some special 1321 significance of that article in relation to the indicated newsgroup. 1322 Article-Updates indicated that an earlier article was updated, 1323 without at the same time being superseded. 1325 The header fields listed above are documented for historical purposes 1326 only. These header fields MUST NOT be generated and SHOULD be 1327 ignored. 1329 3.3.1. Lines 1331 The Lines header field indicates the number of lines in the body of 1332 the article. 1334 lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF 1336 The line count includes all body lines, including the signature if 1337 any, including empty lines (if any) at the beginning or end of the 1338 body, and including the whole of all MIME message and multipart parts 1339 contained in the body (the single empty separator line between the 1340 header fields and the body is not part of the body). The "body" here 1341 is the body as found in the posted article as transmitted by the user 1342 agent. 1344 Historically, this header field was used by the [I-D.ietf-nntpext- 1345 base] Overview facility, but its use for this purpose is now 1346 deprecated. As a result, this header field is to be regarded as 1347 obsolescent, and it is likely to be removed entirely in a future 1348 version of this standard. Servers and clients SHOULD ignore it, and 1349 SHOULD NOT generate it. 1351 4. Internationalization Considerations 1353 Internationalization of news article header fields and bodies is 1354 provided using MIME mechanisms discussed in Section 2.3. Note that 1355 the generation of internationalized s for use in 1356 header fields is not addressed in this document. 1358 5. Security Considerations 1360 The news article format specified in this document does not provide 1361 any security services, such as confidentiality, authentication of 1362 sender, or non-repudiation. Instead, such services need to be 1363 layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME 1364 [RFC3156], or below, using secure versions of news transport 1365 protocols. Additionally, several currently non-standardized 1366 protocols [PGPVERIFY] will hopefully be standardized in the near 1367 future. 1369 Message identifiers (Section 3.1.3) in news are required to be 1370 unique; articles are refused (in server-to-server transfer) if the 1371 identifier has already been seen. So if you can predict the 1372 identifier of a message, you can preempt it by posting a message 1373 (possibly to a quite different group) with the same message 1374 identifier, stopping your target message from propagating. Agents 1375 that generate message identifiers for news articles SHOULD ensure 1376 that they are unpredictable. 1378 MIME security considerations are discussed in [RFC2046]. Note that 1379 the full range of encodings allowed for parameters in [RFC2046] and 1380 [RFC2231] permits constructs that simple parsers may fail to parse 1381 correctly; examples of hard-to-parse constructs are: 1383 Content-Type: multipart/mixed 1384 (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") 1386 Content-Type: multipart/digest; 1387 boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy 1389 Such differences in parsing may be used as part of an attack. 1391 6. IANA Considerations 1393 IANA is requested to register the following header fields in the 1394 Permanent Message Header Field Repository, in accordance with the 1395 procedures set out in [RFC3864]. 1397 Header field name: Also-Control 1398 Applicable protocol: netnews 1399 Status: obsoleted 1400 Author/change controller: IETF 1401 Specification document(s): [Son-of-1036] (Section 6.15) 1403 Header field name: Approved 1404 Applicable protocol: netnews 1405 Status: standard 1406 Author/change controller: IETF 1407 Specification document(s): This document (Section 3.2.9) 1409 Header field name: Archive 1410 Applicable protocol: netnews 1411 Status: standard 1412 Author/change controller: IETF 1413 Specification document(s): This document (Section 3.2.12) 1415 Header field name: Article-Names 1416 Applicable protocol: netnews 1417 Status: obsoleted 1418 Author/change controller: IETF 1419 Specification document(s): [Son-of-1036] (Section 6.17) 1421 Header field name: Article-Updates 1422 Applicable protocol: netnews 1423 Status: obsoleted 1424 Author/change controller: IETF 1425 Specification document(s): [Son-of-1036] (Section 6.18) 1427 Header field name: Comments 1428 Applicable protocol: netnews 1429 Status: standard 1430 Author/change controller: IETF 1431 Specification document(s): This document (Section 3.2), 1432 [RFC2822] (Section 3.6.5) 1434 Header field name: Control 1435 Applicable protocol: netnews 1436 Status: standard 1437 Author/change controller: IETF 1438 Specification document(s): This document (Section 3.2.5) 1439 Header field name: Date 1440 Applicable protocol: netnews 1441 Status: standard 1442 Author/change controller: IETF 1443 Specification document(s): This document (Section 3.1.2), 1444 [RFC2822] (Section 3.6.1) 1446 Header field name: Distribution 1447 Applicable protocol: netnews 1448 Status: standard 1449 Author/change controller: IETF 1450 Specification document(s): This document (Section 3.2.7) 1452 Header field name: Expires 1453 Applicable protocol: netnews 1454 Status: standard 1455 Author/change controller: IETF 1456 Specification document(s): This document (Section 3.2.4) 1458 Header field name: Followup-To 1459 Applicable protocol: netnews 1460 Status: standard 1461 Author/change controller: IETF 1462 Specification document(s): This document (Section 3.2.3) 1464 Header field name: From 1465 Applicable protocol: netnews 1466 Status: standard 1467 Author/change controller: IETF 1468 Specification document(s): This document (Section 3.1.1), 1469 [RFC2822] (Section 3.6.2) 1471 Header field name: Injection-Date 1472 Applicable protocol: netnews 1473 Status: standard 1474 Author/change controller: IETF 1475 Specification document(s): This document (Section 3.2.1) 1477 Header field name: Injection-Info 1478 Applicable protocol: netnews 1479 Status: standard 1480 Author/change controller: IETF 1481 Specification document(s): This document (Section 3.2.14) 1483 Header field name: Keywords 1484 Applicable protocol: netnews 1485 Status: standard 1486 Author/change controller: IETF 1487 Specification document(s): This document (Section 3.2), 1488 [RFC2822] (Section 3.6.5) 1490 Header field name: Lines 1491 Applicable protocol: netnews 1492 Status: deprecated 1493 Author/change controller: IETF 1494 Specification document(s): This document (Section 3.3.1) 1495 Related information: [I-D.ietf-nntpext-base] (Section 8.1) 1497 Header field name: Message-ID 1498 Applicable protocol: netnews 1499 Status: standard 1500 Author/change controller: IETF 1501 Specification document(s): This document (Section 3.1.3) 1502 Related information: [RFC2822] (Section 3.6.4) 1504 Header field name: Newsgroups 1505 Applicable protocol: netnews 1506 Status: standard 1507 Author/change controller: IETF 1508 Specification document(s): This document (Section 3.1.5) 1510 Header field name: NNTP-Posting-Date 1511 Applicable protocol: netnews 1512 Status: obsoleted 1513 Author/change controller: IETF 1514 Specification document(s): none 1516 Header field name: NNTP-Posting-Host 1517 Applicable protocol: netnews 1518 Status: obsoleted 1519 Author/change controller: IETF 1520 Specification document(s): none 1522 Header field name: Organization 1523 Applicable protocol: netnews 1524 Status: standard 1525 Author/change controller: IETF 1526 Specification document(s): This document (Section 3.2.10) 1528 Header field name: Path 1529 Applicable protocol: netnews 1530 Status: standard 1531 Author/change controller: IETF 1532 Specification document(s): This document (Section 3.1.6) 1533 Header field name: References 1534 Applicable protocol: netnews 1535 Status: standard 1536 Author/change controller: IETF 1537 Specification document(s): This document (Section 3.2.2), 1538 [RFC2822] (Section 3.6.4) 1540 Header field name: Reply-To 1541 Applicable protocol: netnews 1542 Status: standard 1543 Author/change controller: IETF 1544 Specification document(s): This document (Section 3.2), 1545 [RFC2822] (Section 3.6.2) 1547 Header field name: See-Also 1548 Applicable protocol: netnews 1549 Status: obsoleted 1550 Author/change controller: IETF 1551 Specification document(s): [Son-of-1036] (Section 6.16) 1553 Header field name: Sender 1554 Applicable protocol: netnews 1555 Status: standard 1556 Author/change controller: IETF 1557 Specification document(s): This document (Section 3.2), 1558 [RFC2822] (Section 3.6.2) 1560 Header field name: Subject 1561 Applicable protocol: netnews 1562 Status: standard 1563 Author/change controller: IETF 1564 Specification document(s): This document (Section 3.1.4), 1565 [RFC2822] (Section 3.6.5) 1567 Header field name: Summary 1568 Applicable protocol: netnews 1569 Status: standard 1570 Author/change controller: IETF 1571 Specification document(s): This document (Section 3.2.8) 1573 Header field name: Supersedes 1574 Applicable protocol: netnews 1575 Status: standard 1576 Author/change controller: IETF 1577 Specification document(s): This document (Section 3.2.6) 1579 Header field name: User-Agent 1580 Applicable protocol: netnews 1581 Status: standard 1582 Author/change controller: IETF 1583 Specification document(s): This document (Section 3.2.13) 1585 Header field name: Xref 1586 Applicable protocol: netnews 1587 Status: standard 1588 Author/change controller: IETF 1589 Specification document(s): This document (Section 3.2.11) 1591 7. References 1593 7.1. Normative References 1595 [Errata] "RFC Editor Errata". 1597 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1598 Extensions (MIME) Part One: Format of Internet Message 1599 Bodies", RFC 2045, November 1996. 1601 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1602 Extensions (MIME) Part Two: Media Types", RFC 2046, 1603 November 1996. 1605 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1606 Part Three: Message Header Extensions for Non-ASCII Text", 1607 RFC 2047, November 1996. 1609 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1610 Extensions (MIME) Part Five: Conformance Criteria and 1611 Examples", RFC 2049, November 1996. 1613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1614 Requirement Levels", BCP 14, RFC 2119, March 1997. 1616 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1617 Presentation Information in Internet Messages: The 1618 Content-Disposition Header Field", RFC 2183, August 1997. 1620 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1621 Word Extensions: Character Sets, Languages, and 1622 Continuations", RFC 2231, November 1997. 1624 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1625 April 2001. 1627 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1628 May 2002. 1630 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1631 Resource Identifier (URI): Generic Syntax", STD 66, 1632 RFC 3986, January 2005. 1634 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1635 Specifications: ABNF", RFC 4234, October 2005. 1637 7.2. Informative References 1639 [I-D.ietf-nntpext-base] 1640 Feather, C., "Network News Transfer Protocol", 1641 draft-ietf-nntpext-base-27 (work in progress), June 2005. 1643 [I-D.ietf-usefor-useage] 1644 Lindsey, C., "Usenet Best Practice", 1645 draft-ietf-usefor-useage-01 (work in progress), 1646 March 2005. 1648 [I-D.ietf-usefor-usepro] 1649 Lindsey, C., "News Article Architecture and Protocols", 1650 draft-ietf-usefor-usepro-05 (work in progress), 1651 January 2006. 1653 [ISO.3166.1988] 1654 International Organization for Standardization, "Codes for 1655 the representation of names of countries, 3rd edition", 1656 ISO Standard 3166, August 1988. 1658 [PGPVERIFY] 1659 Lawrence, D., "PGPverify", June 1999. 1661 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1662 text messages", STD 11, RFC 822, August 1982. 1664 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1665 USENET messages", RFC 1036, December 1987. 1667 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1668 Mapping between X.400 and RFC 822/MIME", RFC 2156, 1669 January 1998. 1671 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1672 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1673 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1675 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1676 "MIME Security with OpenPGP", RFC 3156, August 2001. 1678 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1679 Extensions (S/MIME) Version 3.1 Message Specification", 1680 RFC 3851, July 2004. 1682 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1683 Procedures for Message Header Fields", BCP 90, RFC 3864, 1684 September 2004. 1686 [Son-of-1036] 1687 Spencer, H., "News Article Format and Transmission", 1688 June 1994. 1690 Appendix A. Acknowledgments 1692 As this document is the result of an eight year effort, the number of 1693 people that have contributed to its content are too numerous to 1694 mention individually. Many thanks go out to all past and present 1695 members of the USEFOR Working Group of the Internet Engineering Task 1696 Force (IETF) and the accompanying mailing list. 1698 Appendix B. Differences from RFC 1036 and its derivatives 1700 This appendix contains a list of changes that have been made in the 1701 Netnews Article Format from earlier standards, specifically 1702 [RFC1036]. 1704 o The [RFC2822] conventions for parenthesis-enclosed s in 1705 header fields are supported in all newly defined header fields and 1706 in header fields inherited from [RFC2822]. They are, however, 1707 still disallowed for performance and/or compatibility reasons in 1708 the Message-ID, Newsgroups, Path, Followup-To, Control, 1709 Supersedes, Distribution, Xref and Lines header fields. 1711 o Whitespace is permitted in Newsgroups header fields. 1713 o An enhanced syntax for the Path header field enables the injection 1714 point of, and the route taken by an article to be determined with 1715 more precision. 1717 o MIME is recognized as an integral part of Netnews. 1719 o There is a new Injection-Date header to make the rejection of 1720 stale articles more precise and to minimize spurious rejections. 1722 o There are several new optional header fields defined, notably 1723 Archive, Injection-Info and User-Agent, leading to increased 1724 functionality. 1726 o Certain header fields, notably Lines, have been deprecated or made 1727 obsolete (Section 3.3). 1729 o The convention to interpret subjects starting with the word "cmsg" 1730 as a control message was removed. 1732 o There are numerous other small changes, clarifications and 1733 enhancements. 1735 Appendix C. Differences from RFC 2822 1737 This appendix lists the differences between the syntax allowed by the 1738 Netnews Article Format (this document) as compared to the Internet 1739 Message Format, as specified in [RFC2822]. 1741 The Netnews article format is a strict subset of the Internet Message 1742 Format; all Netnews articles conform to the syntax of [RFC2822]. 1744 The following restrictions are important: 1746 o A SP (space) is REQUIRED after the colon (':') following a header 1747 field name. 1749 o A more restricted syntax of (to be used by the 1750 Message-ID, References, and Supersedes header fields) is defined. 1752 o The length of a MUST NOT exceed 250 octets. 1754 o Comments are not allowed in the Message-ID header field. 1756 o The CFWS between s in the References header field is not 1757 optional. 1759 o It is legal for a parser to reject obsolete syntax, except that: 1761 * The construct MUST be accepted. 1763 * The obsolete "GMT" MUST be accepted within a 1764 . 1766 o Every line of a header field body (including the first and any 1767 that are subsequently folded) MUST contain at least one non- 1768 whitespace character. This means that an empty header field body 1769 is illegal. 1771 Authors' Addresses 1773 Kenneth Murchison (editor) 1774 Carnegie Mellon University 1775 5000 Forbes Avenue 1776 Cyert Hall 285 1777 Pittsburgh, PA 15213 1778 US 1780 Phone: +1 412 268 2638 1781 Email: murch@andrew.cmu.edu 1783 Charles H. Lindsey 1784 University of Manchester 1785 5 Clerewood Avenue 1786 Heald Green 1787 Cheadle 1788 Cheshire SK8 3JU 1789 GB 1791 Phone: +44 161 436 6131 1792 Email: chl@clw.cs.man.ac.uk 1794 Dan Kohn 1795 FlyDash, Inc. 1796 425 Alma St. #411 1797 Palo Alto, CA 94301 1798 US 1800 Phone: +1 415 233 1000 1801 Email: dan@dankohn.com 1803 Intellectual Property Statement 1805 The IETF takes no position regarding the validity or scope of any 1806 Intellectual Property Rights or other rights that might be claimed to 1807 pertain to the implementation or use of the technology described in 1808 this document or the extent to which any license under such rights 1809 might or might not be available; nor does it represent that it has 1810 made any independent effort to identify any such rights. Information 1811 on the procedures with respect to rights in RFC documents can be 1812 found in BCP 78 and BCP 79. 1814 Copies of IPR disclosures made to the IETF Secretariat and any 1815 assurances of licenses to be made available, or the result of an 1816 attempt made to obtain a general license or permission for the use of 1817 such proprietary rights by implementers or users of this 1818 specification can be obtained from the IETF on-line IPR repository at 1819 http://www.ietf.org/ipr. 1821 The IETF invites any interested party to bring to its attention any 1822 copyrights, patents or patent applications, or other proprietary 1823 rights that may cover technology that may be required to implement 1824 this standard. Please address the information to the IETF at 1825 ietf-ipr@ietf.org. 1827 Disclaimer of Validity 1829 This document and the information contained herein are provided on an 1830 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1831 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1832 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1833 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1834 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1837 Copyright Statement 1839 Copyright (C) The Internet Society (2006). This document is subject 1840 to the rights, licenses and restrictions contained in BCP 78, and 1841 except as set forth therein, the authors retain all their rights. 1843 Acknowledgment 1845 Funding for the RFC Editor function is currently provided by the 1846 Internet Society.