idnits 2.17.1 draft-ietf-usefor-usefor-07.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 1827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1817. ** 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2006) is 6621 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 517, but not defined == Missing Reference: 'CFWS' is mentioned on line 1198, 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 (~~), 6 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: September 6, 2006 University of Manchester 6 D. Kohn 7 Skymoon Ventures 8 March 5, 2006 10 Netnews Article Format 11 draft-ietf-usefor-usefor-07 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 September 6, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document specifies the syntax of network news (Netnews) articles 45 in the context of the "Internet Message Format" (RFC 2822) and 46 "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This 47 document supersedes RFC 1036, updating it to reflect current practice 48 and incorporating incremental changes specified in other documents. 50 Changes since draft-ietf-usefor-usefor-06 52 o Reworked ABNF for Path header field delimiters and components 53 (ticket #1047). 55 o Imported ABNF elements from reference docs (ticket #1155). 57 o Added IANA registration for header fields per RFC 3864 (ticket 58 #1156). 60 o New ABNF for Control header field (ticket #1157). 62 o Better ABNF for (ticket #1158). 64 o Added new definitions and advice on sender vs. posting-account in 65 Injection-Info header field (ticket #1159). 67 o New ABNF for Archive and Injection-Info header fields, including 68 note regarding CFWS and (ticket #1177). 70 o Replaced leading/trailing [FWS] with *WSP in header field ANBF 71 (ticket #1179). 73 o Using RFC 4234 as a reference instead of RFC 2234. 75 o Removed reference to RFC 0977 -- using only 76 draft-ietf-nntpext-base. 78 o Added note about Expires being defined by RFC 2156. 80 o Miscellaneous editorial changes. 82 Changes since draft-ietf-usefor-usefor-05 84 o Finalized ABNF for (ticket #1003). 86 o Further cleanup of description for Newsgroups header field (ticket 87 #1021). 89 o Fixed ABNF for (ticket #1028). 91 o Began adding text for differences from RFC 1036 (ticket #1032). 93 o Added text regarding hard-to-parse MIME boundaries (ticket #1046). 95 o Reworked/redefined Path header field delimiters and components 96 (ticket #1047). 98 o Added more differences from RFC 2822 (ticket #1052). 100 o Added text for relationship to RFC 2822 (ticket #1053). 102 o Listed header fields which don't permit CFWS (ticket #1079). 104 o Applied text from ticket #1080 (Injection-Info MIME params). 106 o Added more text Approved header field semantics (ticket #1082). 108 o Added text regarding Injection-Date being mandatory/optional 109 (ticket #1088). 111 o Reworked definitions of "agents", etc (ticket #1102). 113 o Removed RFC 2821 as a normative reference. 115 o Miscellaneous editorial changes. 117 Changes since draft-ietf-usefor-usefor-04 119 o Updated to newer references (ticket #1002). 121 o Cleaned up ABNF for (ticket #1003). 123 o Deprecated X- headers (ticket #1004). 125 o Clarified relationship between followups and References header 126 field (ticket #1008). 128 o Cleaned up ABNF and description for Newsgroups header field 129 (ticket #1021). 131 o Tweaked language regarding the use of (ticket #1022). 133 o Tweaked language regarding GMT timezone and Date header field 134 (ticket #1028). 136 o Added language warning against folding Newsgroups header field 137 (ticket #1042). 139 o Use RFC 2822 term "header field" instead of "header" (ticket 140 #1043). 142 o Starting adding differences from RFC 2822 (ticket #1052). 144 o Miscellaneous editorial changes. 146 Changes since draft-ietf-usefor-usefor-03 148 o Reworked ABNFs of several headers. 150 o Used Charles' ABNF for . 152 o Disallowed comments in Supersedes header. 154 o Disallowed comments in Xref header. 156 o Disallowed comments in Message-Id header. 158 o CFWS between msg-ids in References header is not optional. 160 o Compatibility changes based on comments from Charles. 162 o Miscellaneous editorial changes. 164 Changes since draft-ietf-usefor-usefor-02 166 o Changed to RFC 3978 boilerplate (xml2rfc v1.29) 168 o Changed "network news" to "Netnews" throughout. 170 o Prohibit NO-WS-CTL in msg-id. 172 o Complaints-To header is now an Injection-Info parameter. 174 o Added descriptions of Injection-Info parameters. 176 o Removed "filename" parameter from Archive header. 178 o Added CFWS to User-Agent header. 180 o Miscellaneous editorial changes. 182 Changes since draft-ietf-usefor-usefor-01 184 o Removed half-hearted discussion of internal format and 8-bit clean 185 transport. 187 o Added definitions of "proto-article", "posting agent", "followup", 188 "followup-agent", "user-agent", and "injecting agent". 190 o Removed discussion of message/partial MIME messages. 192 o Noted that the header contents in every line MUST NOT be empty. 194 o Merged MIME sections. 196 o Only allow "UT" and "GMT" in Date header; disallow all other . 199 o Used Charles' ABNF for and . 201 o Removed restrictions on length and start character for Newsgroups. 203 o More verbose description of Path header. 205 o Disallowed comments in Control header. 207 o Specified that is a verb optionally followed by 208 whitespace-separated arguments. 210 o Noted that Supersedes header is different from [Son-of-1036]. 212 o More exact ABNF for Archive and Injection-Info parameters. 214 o Discussed meaning of "yes", "no" in Archive header. 216 o Added "Obsolete Headers" section. 218 o Miscellaneous editorial changes 220 Changes since draft-ietf-usefor-article-13 222 o The Mail-Copies-To, Posted-And-Mailed headers have been moved to 223 other documents. 225 o Dropped MIME parameters, as there is no WG consensus (per Chair). 227 o More exact ABNF for Archive and Injection-Info parameters. 229 o Complaints-To header is now an Injection-Info parameter. 231 Issues to be addressed 233 o Path header field delimiters and components ABNF (ticket #1047). 235 o Whitespace in Path header field (ticket #1178). Editor isn't 236 clear on what the issue actually is. 238 Table of Contents 240 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 8 241 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 8 242 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 243 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 8 244 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 9 245 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 246 1.6. Structure of This Document . . . . . . . . . . . . . . . . 10 247 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 248 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 249 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 12 250 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 14 251 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 15 252 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 15 253 3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 16 254 3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 16 255 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 16 256 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 18 257 3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 19 258 3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 20 259 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 22 260 3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 23 261 3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 23 262 3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 24 263 3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 24 264 3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 24 265 3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 25 266 3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 25 267 3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 26 268 3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 26 269 3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 26 270 3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26 271 3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 27 272 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 27 273 3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 28 274 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 30 275 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 31 276 4. Internationalization Considerations . . . . . . . . . . . . . 32 277 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 278 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 279 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 280 7.1. Normative References . . . . . . . . . . . . . . . . . . . 39 281 7.2. Informative References . . . . . . . . . . . . . . . . . . 39 283 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42 284 Appendix B. Differences from RFC 1036 and its derivatives . . . . 43 285 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 44 286 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 287 Intellectual Property and Copyright Statements . . . . . . . . . . 46 289 1. Introduction 291 1.1. Basic Concepts 293 "Netnews" is a set of protocols for generating, storing and 294 retrieving news "articles" (whose format is a subset of that for 295 Email messages) and for exchanging them amongst a readership which is 296 potentially widely distributed. It is organized around "newsgroups", 297 with the expectation that each reader will be able to see all 298 articles posted to each newsgroup in which he participates. These 299 protocols most commonly use a flooding algorithm which propagates 300 copies throughout a network of participating servers. Typically, 301 only one copy is stored per server, and each server makes it 302 available on demand to readers able to access that server. 304 1.2. Scope 306 This document specifies the syntax of network news (Netnews) articles 307 in the context of the "Internet Message Format" [RFC2822] and 308 "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This 309 document supersedes [RFC1036], updating it to reflect current 310 practice and incorporating changes and clarifications specified in 311 other documents such as [Son-of-1036]. 313 This is the first in a set of documents that obsolete [RFC1036]. 314 This document focuses on the syntax and semantics of Netnews 315 articles. [I-D.ietf-usefor-usepro] is also a standards-track 316 document, and describes the protocol issues of Netnews articles, 317 independent of transport protocols such as [I-D.ietf-nntpext-base]. 318 A best common practice document, [I-D.ietf-usefor-useage], describes 319 implementation recommendations to improve interoperability and 320 usability. 322 This specification is intended as a definition of what article 323 content format is to be passed between systems. Though some news 324 systems locally store articles in this format (which eliminates the 325 need for translation between formats) and others use formats that 326 differ from the one specified in this standard, local storage is 327 outside of the scope of this standard. 329 1.3. Requirements Notation 331 This document uses terms that appear in capital letters. The key 332 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 333 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 334 are to be interpreted as described in [RFC2119]. 336 1.4. Syntax Notation 338 Header fields defined in this specification use the Augmented Backus- 339 Naur Form (ABNF) notation (including the Core Rules) specified in 340 [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as 341 amended by [RFC2231], and [RFC3986], specifically: 343 token = 344 dot-atom-text = 346 parameter = 347 attribute = 349 FWS = 350 CFWS = 351 atext = 352 dot-atom-text = 353 phrase = 354 utext = 355 date-time = 356 mailbox = 357 mailbox-list = 358 address-list = 359 fields = 361 IPv6address = 362 IPv4address = 364 ALPHA = 365 CRLF = 366 DIGIT = 367 DQUOTE = 368 SP = 370 Additionally, Section 3.1.3 updates the [RFC2822] definition of 371 . 373 1.5. Definitions 375 An "article" is the unit of news, synonymous with an [RFC2822] 376 "message". A "proto-article" is one that has not yet been injected 377 into the news system. In constrast to an "article", a "proto- 378 article" may lack some mandatory header fields. 380 A "message identifier" (Section 3.1.3) is a unique identifier for an 381 article, usually supplied by the "user agent" which posted it or, 382 failing that, by the "news server". It distinguishes the article 383 from every other article ever posted anywhere. Articles with the 384 same message identifier are treated as if they are the same article 385 regardless of any differences in the body or header fields. 387 A "newsgroup" is a single news forum, a logical bulletin board, 388 having a name and nominally intended for articles on a specific 389 topic. An article is "posted to" a single newsgroup or several 390 newsgroups. When an article is posted to more than one newsgroup, it 391 is said to be "crossposted"; note that this differs from posting the 392 same text as part of each of several articles, one per newsgroup. 394 A newsgroup may be "moderated", in which case submissions are not 395 posted directly, but mailed to a "moderator" for consideration and 396 possible posting. Moderators are typically human but may be 397 implemented partially or entirely in software. 399 A "poster" is the person or software that composes and submits a 400 possibly compliant article to a "user agent". The poster is 401 analogous to [RFC2822]'s author. 403 A "reader" is the person or software reading news articles. 405 A "followup" is an article containing a response to the contents of 406 an earlier article, its "precursor". Every followup includes a 407 "References" header field identifying that precursor (but note that 408 non-followup articles may also use a References header field). 410 A "control message" is an article which is marked as containing 411 control information; a news server receiving such an article may 412 (subject to the policies observed at that site) take actions beyond 413 just filing and passing on the article. 415 A "news server" is software that may accept articles from a "user 416 agent", and/or make articles available to user agents, and/or 417 exchange articles with other news servers. 419 A "user agent" is software that may help posters submit proto- 420 articles to a news server, and/or fetch articles from a news server 421 and present them to a reader, and/or assist the reader in creating 422 articles and followups. 424 The generic term "agent" is used when describing requirements that 425 apply to both user agents and news servers. 427 1.6. Structure of This Document 429 This document uses a cite by reference methodology, rather than 430 repeating the contents of other standards, which could otherwise 431 result in subtle differences and interoperability challenges. 433 Although this document is as a result rather short, it requires 434 complete understanding and implementation of the normative references 435 to be compliant. 437 Section 2 defines the format of news articles. Section 3 details the 438 header fields necessary to make an article suitable for the Netnews 439 environment. 441 2. Format 443 2.1. Base 445 An article is said to be conformant to this specification if it 446 conforms to the format specified in [RFC2822] Section 3 and to the 447 additional requirements of this specification. 449 An article that uses the obsolete syntax specified in Section 4 of 450 [RFC2822], except for the two exceptions mentioned below, is NOT 451 conformant to this specification. 453 Articles are conformant if they use the construct (use 454 of a phrase like "John Q. Public" without the use of quotes, see 455 [RFC2822] Section 4.1) but agents MUST NOT generate productions of 456 such syntax. 458 Articles are conformant if they use the "GMT" , as specified in 459 Section 3.1.2. 461 This document, and specifications that build upon it, specifies how 462 to handle conformant articles. Handling of non-conformant articles 463 is outside the scope of this specification. 465 Agents conforming to this specification MUST generate only conformant 466 articles. 468 The text below uses ABNF to specify restrictions on the syntax 469 specified in [RFC2822]; this grammar is intended to be more 470 restrictive than the [RFC2822] grammar. Articles must conform to the 471 ABNF specified in [RFC2822]. 473 Articles must also conform to the restrictions specified here, both 474 those that are expressed as text and those that are expressed as 475 ABNF. 477 NOTE: Other specifications use the term "header" as a synonym for 478 what [RFC2822] calls "header field". This document follows the 479 terminology in Section 2 of [RFC2822] in using the terms "line", 480 "header field", "header field name", "header field body", and 481 "folding", based on a belief that consistent terminology among 482 specifications that depend on each other makes the specifications 483 easier to use in the long run. 485 2.2. Header Fields 487 All header fields in a news article are compliant with [RFC2822], 488 however this specification is less permissive in what can be 489 generated and accepted by news agents. The syntax allowed for news 490 articles is a strict subset of the "Internet Message Format", making 491 all messages compliant with this specification inherently compliant 492 with [RFC2822]. Note however that the converse is not guaranteed to 493 be true in all cases. 495 General rules which apply to all header fields (even those documented 496 in [RFC2822] and [RFC2045]) are listed below and those that apply to 497 specific header fields are described in the relevent sections of this 498 document. 500 o All agents MUST generate header fields so that at least one space 501 immediately follows the ':' separating the header field name and 502 the header field body (for compatibility with deployed software, 503 including [I-D.ietf-nntpext-base] servers). News agents MAY 504 accept header fields which do not contain the required space. 506 o Every line of a header field body (including the first and any 507 that are subsequently folded) MUST contain at least one non- 508 whitespace character. 510 NOTE: This means that no header field body defined by or 511 referenced by this document can be empty. As a result, this 512 document updates the construct from Section 513 3.2.6 of [RFC2822] as follows: 515 unstructured = *WSP utext *( [FWS] utext ) *WSP 517 NOTE: The [RFC2822] specification uses [FWS] at the beginning 518 of ABNF for header field content. This specification uses 519 *WSP. This is done for consistency with the restriction 520 described here, but the restriction applies to all header 521 fields, not just those where ABNF is defined in this document. 523 o Compliant software MUST NOT generate (but MAY accept) header 524 fields of more than 998 octets. This is the only limit on the 525 length of a header field prescribed by this standard. However, 526 specific rules to the contrary may apply in particular cases (for 527 example, according to [RFC2047] lines of a header field containing 528 encoded-words are limited to 76 octets). [I-D.ietf-usefor-useage] 529 includes suggested limits for convenience of display by user 530 agents. 532 NOTE: There is NO restriction on the number of lines into which 533 a header field may be split, and hence there is NO restriction 534 on the total length of a header field (in particular it may, by 535 suitable folding, be made to exceed the 998 octets restriction 536 pertaining to a single header line). 538 o The character set for header fields is US-ASCII. Where the use of 539 non-ASCII characters is required, they MUST be encoded using the 540 MIME mechanisms defined in [RFC2047] and [RFC2231]. 542 2.3. MIME Conformance 544 User agents MUST meet the definition of MIME-conformance in [RFC2049] 545 and MUST also support [RFC2231]. This level of MIME Conformance 546 provides support for internationalization and multimedia in message 547 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 548 internationalization of header fields ([RFC2047], [RFC2231]). Note 549 that [Errata] currently exist for [RFC2046] and [RFC2231]. 551 For the purposes of Section 5 of [RFC2047], all header fields defined 552 in Section 3 of this standard are to be considered as "extension 553 message header fields" (insofar as they are not already so considered 554 under the existing Email standards), permitting the use of [RFC2047] 555 encodings within any header field, or within any 556 or permittted within any structured header field. 558 User agents MAY accept and generate other MIME extension header 559 fields, and in particular SHOULD accept Content-Disposition [RFC2183] 560 and Content-Language [RFC3282]. 562 3. News Header Fields 564 The following news header fields extend those defined in Section 3.6 565 of [RFC2822]: 567 fields =/ *( newsgroups / 568 path / 569 injection-date / 570 followup-to / 571 expires / 572 control / 573 supersedes / 574 distribution / 575 summary / 576 approved / 577 organization / 578 xref / 579 archive / 580 user-agent / 581 injection-info / 582 lines ) 584 Each of these header fields may occur at most once in a news article. 586 The following header fields defined in this document do not allow 587 comments (CFWS): 589 Newsgroups 590 Path 591 Followup-to 592 Control 593 Supersedes 594 Distribution 595 Xref 596 Lines 598 This also applies to the following header field defined in [RFC2822]: 600 Message-ID 602 Most of these headers are mainly of interest to news servers, and 603 news servers often need to process these fields very rapidly. 605 3.1. Mandatory Header Fields 607 Each news article conformant with this specification MUST have 608 exactly one of each of the following header fields: From, Date, 609 Message-ID, Subject, Newsgroups, Path. 611 3.1.1. From 613 The From header field is the same as that specified in Section 3.6.2 614 of [RFC2822] with the added restrictions detailed in Section 2.2. 616 from = "From:" SP mailbox-list CRLF 618 3.1.2. Date 620 The Date header field is the same as that specified in Sections 3.3 621 and 3.6.1 of [RFC2822] with the added restrictions detailed in 622 Section 2.2. However, the use of "GMT" as a time zone (part of ), although deprecated, is widespread in news articles today. 624 Therefore, agents MUST accept constructs which use the 625 "GMT" zone. 627 orig-date = "Date:" SP date-time CRLF 629 NOTE: This specification does not change [RFC2822], which says 630 that agents MUST NOT generate constructs which include 631 any zone names defined by . 633 Software that accepts dates with unknown timezones SHOULD treat such 634 timezones as equivalent to "-0000" when comparing dates, as specified 635 in [RFC2822] Section 4.3. 637 Also note that these requirements apply wherever is used, 638 including Injection-Date and Expires in Section 3.2.1 and 639 Section 3.2.4 respectively. 641 3.1.3. Message-ID 643 The Message-ID header field contains a single unique message 644 identifier. Netnews is more dependent on message identifier 645 uniqueness and fast comparison than Email is, and some news software 646 and standards [I-D.ietf-nntpext-base] might have trouble with the 647 full range of possible s permitted by [RFC2822]; this section 648 therefore restricts the syntax of as compared to Section 649 3.6.4 of [RFC2822]. The global uniqueness requirement for 650 in [RFC2822] is to be understood as applying across all protocols 651 using such message identifiers, and across both Email and Netnews in 652 particular. 654 message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF 656 msg-id = "<" id-left "@" id-right ">" 657 ; maximum length is 250 octets 659 id-left = dot-atom-text / no-fold-quote 661 id-right = dot-atom-text / no-fold-literal 663 no-fold-quote = DQUOTE 664 ( "." *mqtext / 665 *mqtext "." / 666 *mqtext mqspecial *mqtext ) 667 DQUOTE 669 mqtext = atext / "." / mqspecial 671 mqspecial = "(" / ")" / ; same as specials except 672 "<" / ; "\" and DQUOTE quoted 673 "[" / "]" / ; "." doubled and ">" omitted 674 ":" / ";" / 675 "@" / "," / 676 ".." / "\\" / "\" DQUOTE 678 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 680 mdtext = %d33-61 / ; The rest of the US-ASCII 681 %d63-90 / ; characters not including 682 %d94-126 ; ">", "[", "]", or "\" 684 The msg-id MUST NOT be more than 250 octets in length. 686 NOTE: The length restriction ensures that systems which accept 687 message identifiers as a parameter when retrieving an article 688 (e.g. [I-D.ietf-nntpext-base]) can rely on a bounded length. 690 Observe that msg-id includes the < and >. 692 Observe also that in contrast to the corresponding header field in 693 [RFC2822]: 695 o the syntax does not allow comments within the Message-ID header 696 field, 698 o it ensures that no string of characters is quoted if it was 699 already a (it MUST start or end with a ".", or 700 contain at least one ), 702 o it ensures that no single character is prefixed by a "\" in the 703 form of a unless strictly necessary, 705 o it excludes all control characters, 707 o there is no possibility for ">" or WSP to occur inside a , 708 whether quoted or not, and 710 o even though commonly derived from s, s are 711 case-sensitive (and thus, once created, are not to be altered 712 during subsequent transmission or copying) 714 This is to simplify processing by news servers and to ensure 715 interoperability with existing implementations and compliance with 716 [I-D.ietf-nntpext-base]. Thus, whereas under [RFC2822] the following 717 s would be considered semantically equivalent, 719 720 <"ab.cd"@example.com> 721 <"ab.\cd"@example.com> 723 only the first of them is syntactically permitted by this standard, 724 and hence a simple comparison of octets will always suffice to 725 determine the identity of two s. 727 Also note that this updated ABNF applies wherever is used, 728 including the References header field discussed in Section 3.2.2 and 729 the Supersedes header field discussed in Section 3.2.6. 731 Some software will try to match the of a in a 732 case-insensitive fashion; some will match it in a case-sensitive 733 fashion. Implementations MUST NOT generate two Message-IDs where the 734 only difference is the case of characters in the part. 736 When generationg a , implementations SHOULD use a domain name 737 as the . 739 NOTE: Section 3.6.4 of [RFC2822] recommends that the 740 should be a domain name or a domain literal. Domain literals are 741 troublesome since many IP addresses are not globally unique; 742 domain names are more likely to generate unique Message-IDs. 744 3.1.4. Subject 746 The Subject header field is the same as that specified in Section 747 3.6.5 of [RFC2822] with the added restrictions detailed in 748 Section 2.2. Further discussion of the content of the Subject header 749 field appears in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor- 750 useage]. 752 subject = "Subject:" SP unstructured CRLF 754 3.1.5. Newsgroups 756 The Newsgroups header field specifies the newsgroup(s) to which the 757 article is posted. 759 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 761 newsgroup-list = *WSP newsgroup-name 762 *( [FWS] "," [FWS] newsgroup-name ) *WSP 764 newsgroup-name = component *( "." component ) 766 component = 1*component-char 768 component-char = ALPHA / DIGIT / "+" / "-" / "_" 770 Folding the Newsgroups header field over several lines has been shown 771 to harm propagation significantly. Folded Newsgroups header fields 772 SHOULD NOT be generated, but MUST be accepted. 774 A newsgroup component SHOULD NOT consist of digits only, and SHOULD 775 NOT contain uppercase letters. Such components MAY be used only to 776 refer to existing groups that do not conform to this naming scheme. 778 NOTE: All-digit components conflict with one widely used storage 779 scheme for articles. Mixed case groups cause confusion between 780 systems with case sensitive matching and systems with case 781 insensitive matching of s. 783 s beginning with underline ("_") are reserved for use by 784 future versions of this standard and MUST NOT be generated by user 785 agents (whether in Newsgroups header fields or in newgroup control 786 messages [I-D.ietf-usefor-usepro]). However, such names MUST be 787 accepted by news servers. 789 s beginning with "+" and "-" are reserved for private use 790 and MUST NOT be generated by user agents (whether in Newsgroups 791 header fields or in newgroup control messages [I-D.ietf-usefor- 792 usepro]) without a private prior agreement to do so. However, such 793 names MUST be accepted by news servers. 795 The following s are reserved, and MUST NOT be used as 796 the name of a newsgroup: 798 o Groups whose first (or only) component is "example" 800 o The group "poster" 802 The following s have been used for specific purposes 803 in various implementations and protocols, and therefore MUST NOT be 804 used for the names of normal newsgroups. They MAY be used for their 805 specific purpose, or by local agreement. 807 o Groups whose first (or only) component is "to" 809 o Groups whose first (or only) component is "control" 811 o Groups which contain (or consist only of) the component "all" 813 o Groups which contain (or consist only of) the component "ctl" 815 o The group "junk" 817 NOTE: "example.*" is reserved for examples in this and other 818 standards; "poster" has a special meaning in the Followup-To 819 header field; "to.*" is reserved for certain point-to-point 820 communications in conjunction with the "ihave" control message 821 [I-D.ietf-usefor-usepro]; "control.*" and "junk" have special 822 meanings in some news-servers; "all" is used as a wildcard in some 823 implementations; and "ctl" was formerly used to indicate a 824 within the Subject header field. 826 3.1.6. Path 828 The Path header field indicates the route taken by an article since 829 its injection into the Netnews system. Each agent that processes an 830 article is required to prepend one (or more) identities to this 831 header field body. This is primarily to enable news servers to avoid 832 sending articles to sites already known to have them, in particular 833 the site they came from, and additionally to permit tracing the route 834 articles take in moving over the network, and for gathering 835 statistics. 837 path = "Path:" SP *WSP path-list tail-entry *WSP CRLF 839 path-list = *( path-identity [FWS] [path-diagnostic] "!" ) 841 path-diagnostic = diag-match / diag-mismatch / diag-seen / 842 diag-posted / diag-deprecated 844 diag-match = "!" ; an additional "!" 846 diag-seen = "!.SEEN." diag-identity 848 diag-mismatch = "!.MISMATCH." diag-identity 850 diag-posted = "!.POSTED" [ "." diag-identity ] 852 diag-deprecated = "!" 1*( path-nodot "." ) path-nodot 854 diag-identity = path-identity / IPv4address / IPv6address 856 tail-entry = path-nodot 857 ; recommended to be "not-for-mail" 859 path-identity = ( 1*( label "." ) toplabel ) / path-nodot 861 path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names 863 label = alphanum [ *( alphanum / "-" ) alphanum ] 865 toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / 866 ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / 867 ( label 1*( "-" ) label ) 869 alphanum = ALPHA / DIGIT ; compare RFC3696 871 A is a name identifying a site. It takes the form of 872 a domain name having one or more components separated by dots. 874 Each in the (excluding the one in the 875 ) indicates, from right to left, the successive agents 876 through which the article has passed. The "POSTED" 877 indicates that the agent to its left injected the article. The use 878 of the "!!" indicates that the agent to its left 879 verified the identity of the agent to its right before accepting the 880 article (whereas the "!" implies no such claim). 881 The "MISMATCH" indicates that the agent to its right 882 failed to be so verified. 884 NOTE: Historically, the indicated the name of the 885 sender. If not used for this purpose, the string "not-for-mail" 886 is often used instead (since at one time the whole path could be 887 used as a mail address for the sender). 889 NOTE: Although case-insensitive, it is intended that the s "POSTED" and "MISMATCH" should be in upper case, to 891 distinguish them from the s which are traditionally 892 in lower case. 894 A is an item inserted into the Path header for 895 purposes other than to indicate the name of a site. One commonly 896 observed usage is to insert an IP address. The colon (":") is 897 permitted in order to allow IPv6 addresses to be inserted; note that 898 this will cause interoperability problems at older sites that regard 899 ":" as a and have neighbors whose names have 4 or 900 fewer characters, and where all the characters are valid HEX digits. 902 3.2. Optional Header Fields 904 None of the header fields appearing in this section is required to 905 appear in every article but some of them may be required in certain 906 types of articles. Further discussion of these requirements appears 907 in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage]. 909 The header fields Reply-To, Sender, Comments, and Keywords are used 910 in news articles in the same circumstances and with the same meaning 911 as that specified in [RFC2822] with the added restrictions detailed 912 in Section 2.2. Multiple occurances of the Keywords header field are 913 not permitted. 915 sender = "Sender:" SP mailbox CRLF 917 reply-to = "Reply-To:" SP address-list CRLF 919 comments = "Comments:" SP unstructured CRLF 921 keywords = "Keywords:" SP phrase *("," phrase) CRLF 923 The MIME header fields MIME-Version, Content-Type, Content-Transfer- 924 Encoding, Content-Disposition, and Content-Language are used in news 925 articles in the same circumstances and with the same meanings as 926 those specified in [RFC2045], [RFC2183], and [RFC3282] with the added 927 restrictions detailed in Section 2.2. 929 All remaining news header fields are described below. 931 3.2.1. Injection-Date 933 The Injection-Date header field contains the date and time that the 934 article was injected into the network. Its purpose is to prevent the 935 reinjection into the news stream of "stale" articles which have 936 already expired by the time they arrive at some news server. 938 This header field MUST be inserted whenever an article is injected. 939 However, software that predates this standard does not use this 940 header, and therefore agents MUST accept articles without the 941 Injection-Date header field. 943 injection-date = "Injection-Date:" SP date-time CRLF 945 See the remarks under Section 3.1.2 regarding the syntax of 946 and the requirements and recommendations to which it is 947 subject. 949 NOTE: The in this header field would normally be 950 expected to be later than the in the Date header 951 field, but differences between the clocks on the various agents 952 and other special circumstances might vitiate that; no provision 953 is made for any such discrepancy to be corrected - better that the 954 news server should just insert the correct time as it sees it. 956 This header field is intended to replace the currently-used but 957 undocumented "NNTP-Posting-Date" header field, whose use is now 958 deprecated. 960 3.2.2. References 962 The References header field is the same as that specified in Section 963 3.6.4 of [RFC2822] with the added restrictions detailed in 964 Section 2.2 and those listed below: 966 o The updated construct defined in Section 3.1.3 MUST be 967 used. 969 o Message identifiers MUST be separated with CFWS. 971 o Comments in CFWS between message identifiers can cause 972 interoperability problems, so comments SHOULD NOT be generated, 973 but MUST be accepted. 975 references = "References:" SP [CFWS] msg-id *(CFWS msg-id) 976 [CFWS] CRLF 978 3.2.3. Followup-To 980 The Followup-To header field specifies to which newsgroup(s) 981 followups should be posted. The Followup-To header field SHOULD NOT 982 appear in a message, unless its content is different from the content 983 of the Newsgroups header field. 985 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 986 CRLF 988 poster-text = *WSP %d112.111.115.116.101.114 *WSP 989 ; "poster" in lower-case 991 The syntax is the same as that of the Newsgroups header field 992 (Section 3.1.5, with the exception that the keyword "poster" (which 993 is always lowercase) requests that followups should be mailed to the 994 article's reply address rather than posted. Although the keyword 995 "poster" is case-sensitive, user agents MAY choose to recognize case- 996 insensitive forms such as "Poster". 998 3.2.4. Expires 1000 The Expires header field specifies a date and time when the article 1001 is deemed to be no longer relevant and could usefully be removed 1002 ("expired"). 1004 expires = "Expires:" SP date-time CRLF 1006 See the remarks under Section 3.1.2 regarding the syntax of 1007 and the requirements and recommendations to which it is 1008 subject. 1010 NOTE: The Expires header field is also sometimes used in Email 1011 with a similar meaning [RFC2156]. 1013 3.2.5. Control 1015 The Control header field marks the article as a control message, and 1016 specifies the desired actions (additional to the usual ones of 1017 storing and/or relaying the article). 1019 control = "Control:" SP *WSP control-command *WSP CRLF 1021 control-command = verb *( 1*WSP argument ) 1023 verb = token 1025 argument = 1*( %x21-7E ) 1026 The verb indicates what action should be taken, and the argument(s) 1027 (if any) supply details. In some cases, the body of the article may 1028 also contain details. The legal verbs and respective arguments are 1029 discussed in the companion document, [I-D.ietf-usefor-usepro]. 1031 An article with a Control header field MUST NOT also have a 1032 Supersedes header field. 1034 3.2.6. Supersedes 1036 The Supersedes header field contains a message identifier specifying 1037 an article to be superseded upon the arrival of this one. An article 1038 containing a Supersedes header field is equivalent to a "cancel" 1039 [I-D.ietf-usefor-usepro] control message for the specified article, 1040 followed immediately by the new article without the Supersedes header 1041 field. 1043 supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF 1045 NOTE: There is no "c" in Supersedes. 1047 NOTE: The Supersedes header field defined here has no connection 1048 with the Supersedes header field that sometimes appears in Email 1049 messages converted from X.400 according to [RFC2156]; in 1050 particular, the syntax here permits only one in contrast 1051 to the multiple s in that Email version. 1053 3.2.7. Distribution 1055 The Distribution header field specifies geographic or organizational 1056 limits on an article's propagation. 1058 distribution = "Distribution:" SP dist-list CRLF 1060 dist-list = *WSP dist-name 1061 *( [FWS] "," [FWS] dist-name ) *WSP 1063 dist-name = ALPHA / DIGIT 1064 *( ALPHA / DIGIT / "+" / "-" / "_" ) 1066 The s "world" and "local" are predefined. However, 1067 "world" SHOULD NOT be used explicitly, since it is the default when 1068 the Distribution header field is absent entirely. 1070 "All" MUST NOT be used as a . s SHOULD contain 1071 at least three characters, except when they are two-letter country 1072 names as in [ISO.3166.1988]. s are case-insensitive (i.e. 1073 "US", "Us", "uS", and "us" all specify the same distribution). 1075 3.2.8. Summary 1077 The Summary header field is a short phrase summarizing the article's 1078 content. 1080 summary = "Summary:" SP unstructured CRLF 1082 3.2.9. Approved 1084 The Approved header field indicates the mailing addresses (and 1085 possibly the full names) of the persons or entities approving the 1086 article for posting. Its principal uses are in moderated articles 1087 and in group control messages [I-D.ietf-usefor-usepro]. 1089 approved = "Approved:" SP mailbox-list CRLF 1091 Each mailbox contained in the Approved header field MUST be that of 1092 one of the person(s) or entity(ies) in question, and one of those 1093 mailboxes MUST be that of the actual sender of the article. Note 1094 that this standard does not provide any means to enforce or verify 1095 this requirement, but future extensions or standards may provide such 1096 a facility (e.g. digitial signatures). 1098 3.2.10. Organization 1100 The Organization header field is a short phrase identifying the 1101 poster's organization. 1103 organization = "Organization:" SP unstructured CRLF 1105 There is no "s" in Organization. 1107 3.2.11. Xref 1109 The Xref header field indicates where an article was filed by the 1110 last news server to process it. The article locations are used to 1111 keep track of crossposted articles so that user agents serviced by a 1112 particular news server can mark such articles as read. 1114 xref = "Xref:" SP *WSP server-name 1115 1*( FWS location ) *WSP CRLF 1117 server-name = path-identity 1119 location = newsgroup-name ":" article-locator 1121 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 1122 ; US-ASCII printable characters 1123 ; except '(' and ';' 1125 The is included so that software can determine which 1126 news server generated the header field. The locations specify what 1127 newsgroups the article was filed under (which may differ from those 1128 in the Newsgroups header field) and where it was filed under them. 1129 The exact form of an is implementation-specific. 1131 NOTE: The traditional form of an (as required by 1132 [I-D.ietf-nntpext-base]) is a decimal number, with articles in 1133 each newsgroup numbered consecutively starting from 1. 1135 3.2.12. Archive 1137 The Archive header field provides an indication of the poster's 1138 intent regarding preservation of the article in publicly accessible 1139 long-term or permanent storage. 1141 archive = "Archive:" SP [CFWS] ("no" / "yes") 1142 *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF 1144 archive-param = parameter 1146 The presence of an Archive header field in an article with a field 1147 body of "no" indicates that the poster does not permit redistribution 1148 from publicly accessible long-term or permanent archives. The 1149 absence of this header field, or the presence of this header field 1150 with a field body of "yes", indicates that the poster is willing for 1151 such redistribution to take place. Further extensions to this 1152 standard may provide parameters for administration of the archiving 1153 process. 1155 3.2.13. User-Agent 1157 The User-Agent header field contains information about the user agent 1158 (typically a newsreader) generating the article, for statistical 1159 purposes and tracing of standards violations to specific software 1160 needing correction. It is intended that this header field be 1161 suitable for use in Email. 1163 user-agent = "User-Agent:" SP 1*product [CFWS] CRLF 1165 product = [CFWS] token [ [CFWS] "/" product-version ] 1167 product-version = [CFWS] token 1169 This header field MAY contain multiple product-tokens identifying the 1170 user agent and any subproducts which form a significant part of it, 1171 listed in order of their significance for identifying the 1172 application. 1174 NOTE: Some of this information has previously been sent in non- 1175 standardized header fields such as X-Newsreader, X-Mailer, 1176 X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent 1177 uses User-Agent, it should have no need to send these non-standard 1178 header fields. 1180 NOTE: [RFC2616] describes a similar facility for the HTTP 1181 protocol. This specification differs in that "{" and "}" are 1182 allowed in tokens ( and ) and comments 1183 are permitted wherever whitespace is allowed. 1185 3.2.14. Injection-Info 1187 The Injection-Info header field contains information provided by the 1188 injecting news server as to how an article entered the Netnews system 1189 and to assist in tracing its true origin. It can also specify one or 1190 more addresses where complaints concerning the poster of the article 1191 may be sent. 1193 injection-info = "Injection-Info:" SP [CFWS] path-identity 1194 [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF 1196 NOTE: The syntax of ([RFC2045] as amended by 1197 [RFC2231]), taken in conjunction with the folding rules of 1198 [RFC0822], effectively allows [CFWS] to occur on either side of 1199 the "=" inside a . 1201 The following table gives the and the format of the 1202 for each defined for use with this header field. 1203 At most one occurrence of each such is allowed. 1205 format of 1206 -------------------- ----------------- 1207 "posting-host" a 1208 "posting-account" any 1209 "sender" a 1210 "logging-data" any 1211 "mail-complaints-to" an 1213 where 1215 host-value = dot-atom-text / IPv4address / IPv6address / 1216 (dot-atom-text ":" ( IPv4address / IPv6address )) 1218 sender-value = mailbox / "verified" 1219 NOTE: Since any such >, or has also to be a syntactically correct , it will 1221 usually be necessary to encapsulate it as a , for 1222 example: 1224 posting-host = "posting@example.com:192.168.0.1" 1226 sender = "\"Joe Q. Public\" " 1228 Additionally, any other whose starts with 1229 "x-" MAY be used where the defined ones appear to be unsuitable, but 1230 other unlisted s SHOULD NOT be used unless defined in 1231 extensions to this standard. 1233 Although comments and folding of white space are permitted throughout 1234 the Injection-Info header field, it is RECOMMENDED that folding is 1235 not used within any (but only before or after the ";" 1236 separating those s), and that comments are only used 1237 following the last . 1239 NOTE: Some of this information has previously been sent in non- 1240 standardized header fields such as NNTP-Posting-Host, X-trace, 1241 X-Complaints-To, and others. Once a news server uses Injection- 1242 Info, it should have no need to send these non-standard header 1243 fields. 1245 The "posting-host" specifies the FQDN and/or IP address 1246 (IPv4address or IPv6address) of the host from which the news server 1247 received the article. 1249 NOTE: If the "posting-host" identifies a dial-up 1250 point-of-presence, the "posting-account" or the "logging-data" 1251 may provide additional information about the true 1252 origin of the article. 1254 The "posting-account" > identifies the source from which 1255 that news server received the article, in a notation that can be 1256 interpreted by the news server administrator. This notation can 1257 include any information the administrator deems pertinent, such as 1258 the authorized and/or authenticated identity of the poster. In order 1259 to limit the exposure of personal data, it SHOULD be given in a form 1260 that can't be interpreted by other sites, but two messages posted 1261 from the same account SHOULD have the same value of "posting- 1262 account". 1264 The "sender" > identifies a mailbox that the news server 1265 configuration shows as one that can be used to reach the user posting 1266 the article. There is no implied relationship between the "sender" 1267 parameter and the "From" or "Sender" header fields of the article. 1269 It is a matter of local policy whether to include the "posting- 1270 account" >, the "sender" , both, or neither. 1272 The "logging-data" contains information (typically a 1273 session number or other non-persistent means of identifying a posting 1274 account) which will enable the true origin of the article to be 1275 determined by reference to logging information kept by the news 1276 server. 1278 The "mail-complaints-to" specifies mailbox(es) for 1279 sending complaints concerning the behavior of the poster of the 1280 article. 1282 3.3. Obsolete Header Fields 1284 Early versions of news software following the modern format sometimes 1285 generated header fields like the following: 1287 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP 1288 Posting-Version: version B 2.10 2/13/83; site eagle.UUCP 1289 Date-Received: Friday, 19-Nov-82 16:59:30 EST 1291 Relay-Version contained version information about the news server 1292 that last processed the article. Posting-Version contained version 1293 information about the user agent that posted the article. Date- 1294 Received contained the date when the last news server to process the 1295 article first saw it (in a slightly nonstandard format). 1297 These header fields are mentioned for historical purposes only. 1298 Agents MUST NOT generate articles containing these header fields. 1300 In addition, this present standard obsoletes certain header fields 1301 defined in [Son-of-1036]: 1303 Also-Control: cancel <9urrt98y53@site.example> 1304 See-Also: 1305 Article-Names: comp.foo:charter 1306 Article-Updates: 1308 Also-Control indicated a control message that was also intended to be 1309 filed as a normal article. See-Also listed related articles, but 1310 without the specific relationship with followups that pertains to the 1311 References header field. Article-Names indicated some special 1312 significance of that article in relation to the indicated newsgroup. 1313 Article-Updates indicated that an earlier article was updated, 1314 without at the same time being superseded. 1316 The header fields listed above are documented for historical purposes 1317 only. Articles containing these header fields MUST NOT be generated. 1318 Persons writing new agents SHOULD ignore any former meanings of these 1319 header fields. 1321 3.3.1. Lines 1323 The Lines header field indicates the number of lines in the body of 1324 the article. 1326 lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF 1328 The line count includes all body lines, including the signature if 1329 any, including empty lines (if any) at the beginning or end of the 1330 body, and including the whole of all MIME message and multipart parts 1331 contained in the body (the single empty separator line between the 1332 header fields and the body is not part of the body). The "body" here 1333 is the body as found in the posted article as transmitted by the user 1334 agent. 1336 Historically, this header field was used by the [I-D.ietf-nntpext- 1337 base] Overview facility, but its use for this purpose is now 1338 deprecated. As a result, this header field is to be regarded as 1339 obsolescent, and it is likely to be removed entirely in a future 1340 version of this standard. Servers and clients SHOULD ignore it, and 1341 SHOULD NOT generate it. 1343 4. Internationalization Considerations 1345 Internationalization of news article header fields and bodies is 1346 provided using MIME mechanisms discussed in Section 2.3. Note that 1347 the generation of internationalized s for use in 1348 header fields is not addressed in this document. 1350 5. Security Considerations 1352 The news article format specified in this document does not provide 1353 any security services, such as confidentiality, authentication of 1354 sender, or non-repudiation. Instead, such services need to be 1355 layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME 1356 [RFC3156], or below, using secure versions of news transport 1357 protocols. Additionally, several currently non-standardized 1358 protocols [PGPVERIFY] will hopefully be standardized in the near 1359 future. 1361 Message identifiers (Section 3.1.3) in news are required to be 1362 unique; articles are refused (in server-to-server transfer) if the 1363 identifier has already been seen. So if you can predict the 1364 identifier of a message, you can preempt it by posting a message 1365 (possibly to a quite different group) with the same message 1366 identifier, stopping your target message from propagating. Agents 1367 that generate message identifiers for news articles SHOULD ensure 1368 that they are unpredictable. 1370 MIME security considerations are discussed in [RFC2046]. Note that 1371 the full range of encodings allowed for parameters in [RFC2046] and 1372 [RFC2231] permits constructs that simple parsers may fail to parse 1373 correctly; examples of hard-to-parse constructs are: 1375 Content-Type: multipart/mixed 1376 (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") 1378 Content-Type: multipart/digest; 1379 boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy 1381 Such differences in parsing may be used as part of an attack. 1383 6. IANA Considerations 1385 IANA is requested to register the following header fields in the 1386 Permanent Message Header Field Repository, in accordance with the 1387 procedures set out in [RFC3864]. 1389 Header field name: Also-Control 1390 Applicable protocol: netnews 1391 Status: obsoleted 1392 Author/change controller: IETF 1393 Specification document(s): [Son-of-1036] (Section 6.15) 1395 Header field name: Approved 1396 Applicable protocol: netnews 1397 Status: standard 1398 Author/change controller: IETF 1399 Specification document(s): This document (Section 3.2.9) 1401 Header field name: Archive 1402 Applicable protocol: netnews 1403 Status: standard 1404 Author/change controller: IETF 1405 Specification document(s): This document (Section 3.2.12) 1407 Header field name: Article-Names 1408 Applicable protocol: netnews 1409 Status: obsoleted 1410 Author/change controller: IETF 1411 Specification document(s): [Son-of-1036] (Section 6.17) 1413 Header field name: Article-Updates 1414 Applicable protocol: netnews 1415 Status: obsoleted 1416 Author/change controller: IETF 1417 Specification document(s): [Son-of-1036] (Section 6.18) 1419 Header field name: Comments 1420 Applicable protocol: netnews 1421 Status: standard 1422 Author/change controller: IETF 1423 Specification document(s): This document (Section 3.2), 1424 [RFC2822] (Section 3.6.5) 1426 Header field name: Control 1427 Applicable protocol: netnews 1428 Status: standard 1429 Author/change controller: IETF 1430 Specification document(s): This document (Section 3.2.5) 1431 Header field name: Date 1432 Applicable protocol: netnews 1433 Status: standard 1434 Author/change controller: IETF 1435 Specification document(s): This document (Section 3.1.2), 1436 [RFC2822] (Section 3.6.1) 1438 Header field name: Distribution 1439 Applicable protocol: netnews 1440 Status: standard 1441 Author/change controller: IETF 1442 Specification document(s): This document (Section 3.2.7) 1444 Header field name: Expires 1445 Applicable protocol: netnews 1446 Status: standard 1447 Author/change controller: IETF 1448 Specification document(s): This document (Section 3.2.4) 1450 Header field name: Followup-To 1451 Applicable protocol: netnews 1452 Status: standard 1453 Author/change controller: IETF 1454 Specification document(s): This document (Section 3.2.3) 1456 Header field name: From 1457 Applicable protocol: netnews 1458 Status: standard 1459 Author/change controller: IETF 1460 Specification document(s): This document (Section 3.1.1), 1461 [RFC2822] (Section 3.6.2) 1463 Header field name: Injection-Date 1464 Applicable protocol: netnews 1465 Status: standard 1466 Author/change controller: IETF 1467 Specification document(s): This document (Section 3.2.1) 1469 Header field name: Injection-Info 1470 Applicable protocol: netnews 1471 Status: standard 1472 Author/change controller: IETF 1473 Specification document(s): This document (Section 3.2.14) 1475 Header field name: Keywords 1476 Applicable protocol: netnews 1477 Status: standard 1478 Author/change controller: IETF 1479 Specification document(s): This document (Section 3.2), 1480 [RFC2822] (Section 3.6.5) 1482 Header field name: Lines 1483 Applicable protocol: netnews 1484 Status: deprecated 1485 Author/change controller: IETF 1486 Specification document(s): This document (Section 3.3.1) 1487 Related information: [I-D.ietf-nntpext-base] (Section 8.1) 1489 Header field name: Message-ID 1490 Applicable protocol: netnews 1491 Status: standard 1492 Author/change controller: IETF 1493 Specification document(s): This document (Section 3.1.3) 1494 Related information: [RFC2822] (Section 3.6.4) 1496 Header field name: Newsgroups 1497 Applicable protocol: netnews 1498 Status: standard 1499 Author/change controller: IETF 1500 Specification document(s): This document (Section 3.1.5) 1502 Header field name: NNTP-Posting-Date 1503 Applicable protocol: netnews 1504 Status: obsoleted 1505 Author/change controller: IETF 1506 Specification document(s): none 1508 Header field name: NNTP-Posting-Host 1509 Applicable protocol: netnews 1510 Status: obsoleted 1511 Author/change controller: IETF 1512 Specification document(s): none 1514 Header field name: Organization 1515 Applicable protocol: netnews 1516 Status: standard 1517 Author/change controller: IETF 1518 Specification document(s): This document (Section 3.2.10) 1520 Header field name: Path 1521 Applicable protocol: netnews 1522 Status: standard 1523 Author/change controller: IETF 1524 Specification document(s): This document (Section 3.1.6) 1525 Header field name: References 1526 Applicable protocol: netnews 1527 Status: standard 1528 Author/change controller: IETF 1529 Specification document(s): This document (Section 3.2.2), 1530 [RFC2822] (Section 3.6.4) 1532 Header field name: Reply-To 1533 Applicable protocol: netnews 1534 Status: standard 1535 Author/change controller: IETF 1536 Specification document(s): This document (Section 3.2), 1537 [RFC2822] (Section 3.6.2) 1539 Header field name: See-Also 1540 Applicable protocol: netnews 1541 Status: obsoleted 1542 Author/change controller: IETF 1543 Specification document(s): [Son-of-1036] (Section 6.16) 1545 Header field name: Sender 1546 Applicable protocol: netnews 1547 Status: standard 1548 Author/change controller: IETF 1549 Specification document(s): This document (Section 3.2), 1550 [RFC2822] (Section 3.6.2) 1552 Header field name: Subject 1553 Applicable protocol: netnews 1554 Status: standard 1555 Author/change controller: IETF 1556 Specification document(s): This document (Section 3.1.4), 1557 [RFC2822] (Section 3.6.5) 1559 Header field name: Summary 1560 Applicable protocol: netnews 1561 Status: standard 1562 Author/change controller: IETF 1563 Specification document(s): This document (Section 3.2.8) 1565 Header field name: Supersedes 1566 Applicable protocol: netnews 1567 Status: standard 1568 Author/change controller: IETF 1569 Specification document(s): This document (Section 3.2.6) 1571 Header field name: User-Agent 1572 Applicable protocol: netnews 1573 Status: standard 1574 Author/change controller: IETF 1575 Specification document(s): This document (Section 3.2.13) 1577 Header field name: Xref 1578 Applicable protocol: netnews 1579 Status: standard 1580 Author/change controller: IETF 1581 Specification document(s): This document (Section 3.2.11) 1583 7. References 1585 7.1. Normative References 1587 [Errata] "RFC Editor Errata". 1589 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1590 Extensions (MIME) Part One: Format of Internet Message 1591 Bodies", RFC 2045, November 1996. 1593 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1594 Extensions (MIME) Part Two: Media Types", RFC 2046, 1595 November 1996. 1597 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1598 Part Three: Message Header Extensions for Non-ASCII Text", 1599 RFC 2047, November 1996. 1601 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1602 Extensions (MIME) Part Five: Conformance Criteria and 1603 Examples", RFC 2049, November 1996. 1605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1606 Requirement Levels", BCP 14, RFC 2119, March 1997. 1608 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1609 Presentation Information in Internet Messages: The 1610 Content-Disposition Header Field", RFC 2183, August 1997. 1612 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1613 Word Extensions: Character Sets, Languages, and 1614 Continuations", RFC 2231, November 1997. 1616 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1617 April 2001. 1619 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1620 May 2002. 1622 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1623 Specifications: ABNF", RFC 4234, October 2005. 1625 7.2. Informative References 1627 [I-D.ietf-nntpext-base] 1628 Feather, C., "Network News Transfer Protocol", 1629 draft-ietf-nntpext-base-27 (work in progress), June 2005. 1631 [I-D.ietf-usefor-useage] 1632 Lindsey, C., "Usenet Best Practice", 1633 draft-ietf-usefor-useage-01 (work in progress), 1634 March 2005. 1636 [I-D.ietf-usefor-usepro] 1637 Lindsey, C., "News Article Architecture and Protocols", 1638 draft-ietf-usefor-usepro-05 (work in progress), 1639 January 2006. 1641 [ISO.3166.1988] 1642 International Organization for Standardization, "Codes for 1643 the representation of names of countries, 3rd edition", 1644 ISO Standard 3166, August 1988. 1646 [PGPVERIFY] 1647 Lawrence, D., "PGPverify", June 1999. 1649 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1650 text messages", STD 11, RFC 822, August 1982. 1652 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1653 USENET messages", RFC 1036, December 1987. 1655 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1656 Mapping between X.400 and RFC 822/MIME", RFC 2156, 1657 January 1998. 1659 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1660 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1661 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1663 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1664 "MIME Security with OpenPGP", RFC 3156, August 2001. 1666 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1667 Extensions (S/MIME) Version 3.1 Message Specification", 1668 RFC 3851, July 2004. 1670 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1671 Procedures for Message Header Fields", BCP 90, RFC 3864, 1672 September 2004. 1674 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1675 Resource Identifier (URI): Generic Syntax", STD 66, 1676 RFC 3986, January 2005. 1678 [Son-of-1036] 1679 Spencer, H., "News Article Format and Transmission", 1680 June 1994. 1682 Appendix A. Acknowledgements 1684 As this document is the result of an eight year effort, the number of 1685 people that have contributed to its content are too numerous to 1686 mention individually. Many thanks go out to all past and present 1687 members of the USEFOR Working Group of the Internet Engineering Task 1688 Force (IETF) and the accompanying mailing list. 1690 Appendix B. Differences from RFC 1036 and its derivatives 1692 This appendix contains a list of changes that have been made in the 1693 Netnews Article Format from earlier standards, specifically 1694 [RFC1036]. 1696 o The [RFC2822] conventions for parenthesis-enclosed s in 1697 header fields are supported in all newly defined header fields and 1698 in header fields inherited from [RFC2822]. They are, however, 1699 still disallowed for performance and/or compatibility reasons in 1700 the Message-ID, Newsgroups, Path, Followup-To, Control, 1701 Supersedes, Distribution, Xref and Lines header fields. 1703 o Whitespace is permitted in Newsgroups header fields. 1705 o An enhanced syntax for the Path header field enables the injection 1706 point of, and the route taken by an article to be determined with 1707 more precision. 1709 o MIME is recognized as an integral part of Netnews. 1711 o There is a new Injection-Date header to make the rejection of 1712 stale articles more precise and to minimize spurious rejections. 1714 o There are several new optional header fields defined, notably 1715 Archive, Injection-Info and User-Agent, leading to increased 1716 functionality. 1718 o Certain header fields, notably Lines, have been made obsolete 1719 (Section 3.3). 1721 o The convention to interpret subjects starting with the word "cmsg" 1722 as a control message was removed. 1724 o There are numerous other small changes, clarifications and 1725 enhancements. 1727 Appendix C. Differences from RFC 2822 1729 This appendix lists the differences between the syntax allowed by the 1730 Netnews Article Format (this document) as compared to the Internet 1731 Message Format, as specified in [RFC2822]. 1733 The Netnews article format is a strict subset of the Internet Message 1734 Format; all Netnews articles conform to the syntax of [RFC2822]. 1736 The following restrictions are important: 1738 o A SP (space) is REQUIRED after the colon (':') following a header 1739 field name. 1741 o A more restricted syntax of (to be used by the 1742 Message-ID, References, and Supersedes header fields) is defined. 1744 o The length of a MUST NOT exceed 250 octets. 1746 o Comments are not allowed in the Message-ID header field. 1748 o The CFWS between s in the References header field is not 1749 optional. 1751 o It is legal for a parser to reject obsolete syntax, except that: 1753 * The construct MUST be accepted. 1755 * The obsolete "GMT" MUST be accepted within a 1756 . 1758 o Every line of a header field body (including the first and any 1759 that are subsequently folded) MUST contain at least one non- 1760 whitespace character. This means that an empty header field body 1761 is illegal. 1763 Authors' Addresses 1765 Kenneth Murchison (editor) 1766 Carnegie Mellon University 1767 5000 Forbes Avenue 1768 Cyert Hall 285 1769 Pittsburgh, PA 15213 1770 US 1772 Phone: +1 412 268 2638 1773 Email: murch@andrew.cmu.edu 1775 Charles H. Lindsey 1776 University of Manchester 1777 5 Clerewood Avenue 1778 Heald Green 1779 Cheadle 1780 Cheshire SK8 3JU 1781 GB 1783 Phone: +44 161 436 6131 1784 Email: chl@clw.cs.man.ac.uk 1786 Dan Kohn 1787 Skymoon Ventures 1788 3045 Park Boulevard 1789 Palo Alto, CA 94306 1790 US 1792 Phone: +1 650 327 2600 1793 Email: dan@dankohn.com 1795 Intellectual Property Statement 1797 The IETF takes no position regarding the validity or scope of any 1798 Intellectual Property Rights or other rights that might be claimed to 1799 pertain to the implementation or use of the technology described in 1800 this document or the extent to which any license under such rights 1801 might or might not be available; nor does it represent that it has 1802 made any independent effort to identify any such rights. Information 1803 on the procedures with respect to rights in RFC documents can be 1804 found in BCP 78 and BCP 79. 1806 Copies of IPR disclosures made to the IETF Secretariat and any 1807 assurances of licenses to be made available, or the result of an 1808 attempt made to obtain a general license or permission for the use of 1809 such proprietary rights by implementers or users of this 1810 specification can be obtained from the IETF on-line IPR repository at 1811 http://www.ietf.org/ipr. 1813 The IETF invites any interested party to bring to its attention any 1814 copyrights, patents or patent applications, or other proprietary 1815 rights that may cover technology that may be required to implement 1816 this standard. Please address the information to the IETF at 1817 ietf-ipr@ietf.org. 1819 Disclaimer of Validity 1821 This document and the information contained herein are provided on an 1822 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1823 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1824 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1825 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1826 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1829 Copyright Statement 1831 Copyright (C) The Internet Society (2006). This document is subject 1832 to the rights, licenses and restrictions contained in BCP 78, and 1833 except as set forth therein, the authors retain all their rights. 1835 Acknowledgment 1837 Funding for the RFC Editor function is currently provided by the 1838 Internet Society.