idnits 2.17.1 draft-ietf-usefor-usefor-06.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 1523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1513. ** 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' o IANA considerations (the Klyne message header registry is now' ) ** The abstract seems to contain references ([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 (December 16, 2005) is 6706 days in the past. Is this intentional? 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: 'CFWS' is mentioned on line 1113, but not defined == Missing Reference: 'RFC 3986' is mentioned on line 1131, but not defined == Unused Reference: 'RFC3986' is defined on line 1367, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Errata' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- No information found for draft-ietf-nntpext-base- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 977 (Obsoleted by RFC 3977) -- 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) -- No information found for draft-ietf-usefor-useage- - is the name correct? -- No information found for draft-ietf-usefor-usepro- - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 17 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: June 19, 2006 University of Manchester 6 D. Kohn 7 Skymoon Ventures 8 December 16, 2005 10 Netnews Article Format 11 draft-ietf-usefor-usefor-06 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 June 19, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 Note to the RFC Editor 52 The normative reference to RFC 2234 and the informative reference to 53 RFC 0977 may be replaced by draft-crocker-abnf-rfc2234bis and 54 draft-ietf-nntpext-base respectively should one or both of those of 55 those documents reach RFC status before this one. 57 Changes since draft-ietf-usefor-usefor-05 59 o Resolved ticket #1003 (msg-id). 61 o Resolved ticket #1021 (Newsgroups description and exceptions). 63 o Resolved ticket #1028 (fixed ABNF for orig-date). 65 o Began adding text for ticket #1032 (diff from RFC 1036). 67 o Resolved ticket #1046 (MIME boundary security considerations). 69 o Addressed ticket #1047 (Path header field delimiters and 70 components) using Harald's suggested text -- Still an open issue. 72 o Resolved ticket #1052 (diffs from RFC 2822). 74 o Resolved ticket #1053 (relationship to RFC 2822). 76 o Resolved ticket #1079 (header fields which don't permit CFWS). 78 o Applied text from ticket #1080 (Injection-Info MIME params). 80 o Resolved ticket #1082 (Approved header field semantics). 82 o Resolved ticket #1088 (Injection-Date mandatory/optional). 84 o Resolved ticket #1102 (Definition of "agents", etc). 86 o Removed RFC 0821 as a normative reference. 88 o Miscellaneous editorial changes. 90 Changes since draft-ietf-usefor-usefor-04 92 o Resolved ticket #1002 (updated references). 94 o Applied text from ticket #1003 (ABNF cleanup for msg-id). 96 o Resolved ticket #1004 (deprecate X- headers). 98 o Resolved ticket #1008 (followups & References header field). 100 o Applied text from ticket #1021 (Newsgroups ABNF and description). 102 o Resolved ticket #1022 (obs-phrase). 104 o Applied text from ticket #1028 (GMT timezone for Date). 106 o Applied text from ticket #1042 (Newsgroups folding). 108 o Resolved ticket #1043 (RFC 2822 terms for header fields). 110 o Starting to resolve ticket #1052 (differences from RFC 2822). 112 o Miscellaneous editorial changes. 114 Changes since draft-ietf-usefor-usefor-03 116 o Reworked ABNFs of several headers. 118 o Used Charles' ABNF for . 120 o Disallowed comments in Supersedes header. 122 o Disallowed comments in Xref header. 124 o Disallowed comments in Message-Id header. 126 o CFWS between msg-ids in References header is not optional. 128 o Compatibility changes based on comments from Charles. 130 o Miscellaneous editorial changes. 132 Changes since draft-ietf-usefor-usefor-02 134 o Changed to RFC 3978 boilerplate (xml2rfc v1.29) 136 o Changed "network news" to "Netnews" throughout. 138 o Prohibit NO-WS-CTL in msg-id. 140 o Complaints-To header is now an Injection-Info parameter. 142 o Added descriptions of Injection-Info parameters. 144 o Removed "filename" parameter from Archive header. 146 o Added CFWS to User-Agent header. 148 o Miscellaneous editorial changes. 150 Changes since draft-ietf-usefor-usefor-01 152 o Removed half-hearted discussion of internal format and 8-bit clean 153 transport. 155 o Added definitions of "proto-article", "posting agent", "followup", 156 "followup-agent", "user-agent", and "injecting agent". 158 o Removed discussion of message/partial MIME messages. 160 o Noted that the header contents in every line MUST NOT be empty. 162 o Merged MIME sections. 164 o Only allow "UT" and "GMT" in Date header; disallow all other . 167 o Used Charles' ABNF for and . 169 o Removed restrictions on length and start character for Newsgroups. 171 o More verbose description of Path header. 173 o Disallowed comments in Control header. 175 o Specified that is a verb optionally followed by 176 whitespace-separated arguments. 178 o Noted that Supersedes header is different from [Son-of-1036]. 180 o More exact ABNF for Archive and Injection-Info parameters. 182 o Discussed meaning of "yes", "no" in Archive header. 184 o Added "Obsolete Headers" section. 186 o Miscellaneous editorial changes 188 Changes since draft-ietf-usefor-article-13 190 o The Mail-Copies-To, Posted-And-Mailed headers have been moved to 191 other documents. 193 o Dropped MIME parameters, as there is no WG consensus (per Chair). 195 o More exact ABNF for Archive and Injection-Info parameters. 197 o Complaints-To header is now an Injection-Info parameter. 199 Issues to be addressed 201 o Ticket #1047: Path header field delimiters and components. 203 o IANA considerations (the Klyne message header registry is now 204 official as RFC 3864)?. 206 o Collected Syntax? 208 o Merge more security issues? 210 o Merge acknowledgments? 212 Table of Contents 214 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7 215 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 7 216 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 217 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 7 218 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 8 219 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 220 1.6. Structure of This Document . . . . . . . . . . . . . . . . 9 221 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 222 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 223 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 10 224 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 12 225 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 226 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 13 227 3.1.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 14 228 3.1.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . 14 229 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 14 230 3.1.4. Subject . . . . . . . . . . . . . . . . . . . . . . . 16 231 3.1.5. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 17 232 3.1.6. Path . . . . . . . . . . . . . . . . . . . . . . . . . 18 233 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 20 234 3.2.1. Injection-Date . . . . . . . . . . . . . . . . . . . . 20 235 3.2.2. References . . . . . . . . . . . . . . . . . . . . . . 21 236 3.2.3. Followup-To . . . . . . . . . . . . . . . . . . . . . 21 237 3.2.4. Expires . . . . . . . . . . . . . . . . . . . . . . . 22 238 3.2.5. Control . . . . . . . . . . . . . . . . . . . . . . . 22 239 3.2.6. Supersedes . . . . . . . . . . . . . . . . . . . . . . 22 240 3.2.7. Distribution . . . . . . . . . . . . . . . . . . . . . 23 241 3.2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . 23 242 3.2.9. Approved . . . . . . . . . . . . . . . . . . . . . . . 23 243 3.2.10. Organization . . . . . . . . . . . . . . . . . . . . . 24 244 3.2.11. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 24 245 3.2.12. Archive . . . . . . . . . . . . . . . . . . . . . . . 24 246 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 25 247 3.2.14. Injection-Info . . . . . . . . . . . . . . . . . . . . 25 248 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 27 249 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 28 250 4. Internationalization Considerations . . . . . . . . . . . . . 29 251 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 252 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 253 6.1. Normative References . . . . . . . . . . . . . . . . . . . 31 254 6.2. Informative References . . . . . . . . . . . . . . . . . . 31 255 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 256 Appendix B. Differences from RFC 1036 and its derivatives . . . . 34 257 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 35 258 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 259 Intellectual Property and Copyright Statements . . . . . . . . . . 37 261 1. Introduction 263 1.1. Basic Concepts 265 "Netnews" is a set of protocols for generating, storing and 266 retrieving news "articles" (whose format is a subset of that for 267 Email messages) and for exchanging them amongst a readership which is 268 potentially widely distributed. It is organized around "newsgroups", 269 with the expectation that each reader will be able to see all 270 articles posted to each newsgroup in which he participates. These 271 protocols most commonly use a flooding algorithm which propagates 272 copies throughout a network of participating servers. Typically, 273 only one copy is stored per server, and each server makes it 274 available on demand to readers able to access that server. 276 1.2. Scope 278 This document specifies the syntax of network news (Netnews) articles 279 in the context of the "Internet Message Format" [RFC2822] and 280 "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This 281 document supersedes [RFC1036], updating it to reflect current 282 practice and incorporating changes and clarifications specified in 283 other documents such as [Son-of-1036]. 285 This is the first in a set of documents that obsolete [RFC1036]. 286 This document focuses on the syntax and semantics of Netnews 287 articles. [USEPRO] is also a standards-track document, and describes 288 the protocol issues of Netnews articles, independent of transport 289 protocols such as [NNTP]. A best common practice document, [USEAGE], 290 describes implementation recommendations to improve interoperability 291 and usability. 293 This specification is intended as a definition of what article 294 content format is to be passed between systems. Though some news 295 systems locally store articles in this format (which eliminates the 296 need for translation between formats) and others use formats that 297 differ from the one specified in this standard, local storage is 298 outside of the scope of this standard. 300 1.3. Requirements Notation 302 This document uses terms that appear in capital letters. The key 303 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 304 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 305 are to be interpreted as described in [RFC2119]. 307 1.4. Syntax Notation 309 Header fields defined in this specification use the Augmented Backus- 310 Naur Form (ABNF) notation (including the Core Rules) specified in 311 [RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. 312 Section 3.1.3 updates the [RFC2822] definition of . 314 The following constructs referenced by this document are defined in 315 [RFC2822]: , , , , 316 , , , , , 317 and . 319 The following constructs referenced by this document are defined in 320 [RFC2045] (as amended by [RFC2231]): , , . 322 1.5. Definitions 324 An "article" is the unit of news, synonymous with an [RFC2822] 325 "message". A "proto-article" is one that has not yet been injected 326 into the news system. In constrast to an "article", a "proto- 327 article" may lack some mandatory header fields. 329 A "message identifier" (Section 3.1.3) is a unique identifier for an 330 article, usually supplied by the "user agent" which posted it or, 331 failing that, by the "news server". It distinguishes the article 332 from every other article ever posted anywhere. Articles with the 333 same message identifier are treated as if they are the same article 334 regardless of any differences in the body or header fields. 336 A "newsgroup" is a single news forum, a logical bulletin board, 337 having a name and nominally intended for articles on a specific 338 topic. An article is "posted to" a single newsgroup or several 339 newsgroups. When an article is posted to more than one newsgroup, it 340 is said to be "crossposted"; note that this differs from posting the 341 same text as part of each of several articles, one per newsgroup. 343 A newsgroup may be "moderated", in which case submissions are not 344 posted directly, but mailed to a "moderator" for consideration and 345 possible posting. Moderators are typically human but may be 346 implemented partially or entirely in software. 348 A "poster" is the person or software that composes and submits a 349 possibly compliant article to a "user agent". The poster is 350 analogous to [RFC2822]'s author. 352 A "reader" is the person or software reading news articles. 354 A "followup" is an article containing a response to the contents of 355 an earlier article, its "precursor". Every followup includes a 356 "References" header field identifying that precursor (but note that 357 non-followup articles may also use a References header field). 359 A "control message" is an article which is marked as containing 360 control information; a news server receiving such an article may 361 (subject to the policies observed at that site) take actions beyond 362 just filing and passing on the article. 364 A "news server" is software that may accept articles from a "user 365 agent", and/or make articles available to user agents, and/or 366 exchange articles with other news servers. 368 A "user agent" is software that may help posters submit proto- 369 articles to a news server, and/or fetch articles from a news server 370 and present them to a reader, and/or assist the reader in creating 371 articles and followups. 373 The generic term "agent" is used when describing requirements that 374 apply to both user agents and news servers. 376 1.6. Structure of This Document 378 This document uses a cite by reference methodology, rather than 379 repeating the contents of other standards, which could otherwise 380 result in subtle differences and interoperability challenges. 381 Although this document is as a result rather short, it requires 382 complete understanding and implementation of the normative references 383 to be compliant. 385 Section 2 defines the format of news articles. Section 3 details the 386 header fields necessary to make an article suitable for the Netnews 387 environment. 389 2. Format 391 2.1. Base 393 An article is said to be conformant to this specification if it 394 conforms to the format specified in [RFC2822] section 3 and to the 395 additional requirements of this specification. 397 An article that uses the obsolete syntax specified in section 4 of 398 [RFC2822], except for the two exceptions mentioned below, is NOT 399 conformant to this specification. 401 Articles are conformant if they use the construct (use 402 of a phrase like "John Q. Public" without the use of quotes, see 403 [RFC2822] section 4.1) but agents MUST NOT generate productions of 404 such syntax. 406 Articles are conformant if they use the "GMT" , as specified in 407 Section 3.1.2. 409 This document, and specifications that build upon it, specifies how 410 to handle conformant articles. Handling of non-conformant articles 411 is outside the scope of this specification. 413 Agents conforming to this specification MUST generate only conformant 414 articles. 416 The text below uses ABNF to specify restrictions on the syntax 417 specified in [RFC2822]; this grammar is intended to be more 418 restrictive than the [RFC2822] grammar. Articles must conform to the 419 ABNF specified in [RFC2822]. 421 Articles must also conform to the restrictions specified here, both 422 those that are expressed as text and those that are expressed as 423 ABNF. 425 NOTE: Older Netnews specifications used the term "header" as a 426 synonym for what [RFC2822] calls "header field". This document 427 follows the terminology in Section 2 of [RFC2822] in using the 428 terms "line", "header field", "header field name", "header field 429 body", and "folding", based on a belief that consistent 430 terminology among specifications that depend on each other makes 431 the specifications easier to use in the long run. 433 2.2. Header Fields 435 All header fields in a news article are compliant with [RFC2822], 436 however this specification is less permissive in what can be 437 generated and accepted by news agents. The syntax allowed for news 438 articles is a strict subset of the "Internet Message Format", making 439 all messages compliant with this specification inherently compliant 440 with [RFC2822]. Note however that the converse is not guaranteed to 441 be true in all cases. 443 General rules which apply to all header fields (even those documented 444 in [RFC2822] and [RFC2045]) are listed below and those that apply to 445 specific header fields are described in the relevent sections of this 446 document. 448 o All agents MUST generate header fields so that at least one space 449 immediately follows the ':' separating the header field name and 450 the header field body (for compatibility with deployed software, 451 including [NNTP] servers). News agents MAY accept header fields 452 which do not contain the required space. 454 o Every line of a header field body (including the first and any 455 that are subsequently folded) MUST contain at least one non- 456 whitespace character. 458 NOTE: This means that no header field body defined by or 459 referenced by this document can be empty. As a result, this 460 document updates the construct from Section 461 3.2.6 of [RFC2822] as follows: 463 unstructured = 1*( [FWS] utext ) [FWS] 465 o Compliant software MUST NOT generate (but MAY accept) header 466 fields of more than 998 octets. This is the only limit on the 467 length of a header field prescribed by this standard. However, 468 specific rules to the contrary may apply in particular cases (for 469 example, according to [RFC2047] lines of a header field containing 470 encoded-words are limited to 76 octets). [USEAGE] includes 471 suggested limits for convenience of display by user agents. 473 NOTE: There is NO restriction on the number of lines into which 474 a header field may be split, and hence there is NO restriction 475 on the total length of a header field (in particular it may, by 476 suitable folding, be made to exceed the 998 octets restriction 477 pertaining to a single header line). 479 o The character set for header fields is US-ASCII. Where the use of 480 non-ASCII characters is required, they MUST be encoded using the 481 MIME mechanisms defined in [RFC2047] and [RFC2231]. 483 2.3. MIME Conformance 485 User agents MUST meet the definition of MIME-conformance in [RFC2049] 486 and MUST also support [RFC2231]. This level of MIME Conformance 487 provides support for internationalization and multimedia in message 488 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 489 internationalization of header fields ([RFC2047], [RFC2231]). Note 490 that [Errata] currently exist for [RFC2046] and [RFC2231]. 492 For the purposes of Section 5 of [RFC2047], all header fields defined 493 in Section 3 of this standard are to be considered as "extension 494 message header fields" (insofar as they are not already so considered 495 under the existing Email standards), permitting the use of [RFC2047] 496 encodings within any header field, or within any 497 or permittted within any structured header field. 499 User agents MAY accept and generate other MIME extension header 500 fields, and in particular SHOULD accept Content-Disposition [RFC2183] 501 and Content-Language [RFC3282]. 503 3. News Header Fields 505 The following news header fields extend those defined in section 3.6 506 of [RFC2822]: 508 fields =/ *( newsgroups / 509 path / 510 injection-date / 511 followup-to / 512 expires / 513 control / 514 supersedes / 515 distribution / 516 summary / 517 approved / 518 organization / 519 xref / 520 archive / 521 user-agent / 522 injection-info ) 524 Each of these header fields may occur at most once in a news article. 526 The following header fields defined in this document do not allow 527 comments (CFWS): 529 Newsgroups 530 Path 531 Followup-to 532 Control 533 Supersedes 534 Distribution 535 Xref 536 Lines 538 This also applies to the following header field defined in [RFC2822]: 540 Message-ID 542 Several of these headers are mainly of interest to servers, and 543 servers often need to process these fields very rapidly. 545 3.1. Mandatory Header Fields 547 Each news article conformant with this specification MUST have 548 exactly one of each of the following header fields: From, Date, 549 Message-ID, Subject, Newsgroups, Path. 551 3.1.1. From 553 The From header field is the same as that specified in Section 3.6.2 554 of [RFC2822] with the added restrictions detailed in Section 2.2. 556 from = "From:" SP mailbox-list CRLF 558 3.1.2. Date 560 The Date header field is the same as that specified in Sections 3.3 561 and 3.6.1 of [RFC2822] with the added restrictions detailed in 562 Section 2.2. However, the use of "GMT" as a time zone (part of ), although deprecated, is widespread in news articles today. 564 Therefore, agents MUST accept constructs which use the 565 "GMT" zone. 567 orig-date = "Date:" SP date-time CRLF 569 NOTE: This specification does not change [RFC2822], which says 570 that agents MUST NOT generate constructs which include 571 any zone names defined by . 573 Software that accepts dates with unknown timezones SHOULD treat such 574 timezones as equivalent to "-0000" when comparing dates, as specified 575 in [RFC2822] section 4.3. 577 Also note that these requirements apply wherever is used, 578 including Injection-Date and Expires in Section 3.2.1 and 579 Section 3.2.4 respectively. 581 3.1.3. Message-ID 583 The Message-ID header field contains a single unique message 584 identifier. Netnews is more dependent on message identifier 585 uniqueness and fast comparison than Email is, and some news software 586 and standards [RFC0977] might have trouble with the full range of 587 possible s permitted by [RFC2822]; this section therefore 588 restricts the syntax of as compared to Section 3.6.4 of 589 [RFC2822]. The global uniqueness requirement for in 590 [RFC2822] is to be understood as applying across all protocols using 591 such message identifiers, and across both Email and Netnews in 592 particular. 594 message-id = "Message-ID:" SP [FWS] msg-id [FWS] CRLF 596 msg-id = "<" id-left "@" id-right ">" 597 ; maximum length is 250 octets 599 id-left = dot-atom-text / no-fold-quote 601 id-right = dot-atom-text / no-fold-literal 603 no-fold-quote = DQUOTE 604 ( "." *mqtext / 605 *mqtext "." / 606 *mqtext mqspecial *mqtext ) 607 DQUOTE 609 mqtext = atext / "." / mqspecial 611 mqspecial = "(" / ")" / ; same as specials except 612 "<" / ; "\" and DQUOTE quoted 613 "[" / "]" / ; "." doubled and ">" omitted 614 ":" / ";" / 615 "@" / "," / 616 ".." / "\\" / "\" DQUOTE 618 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 620 mdtext = %d33-61 / ; The rest of the US-ASCII 621 %d63-90 / ; characters not including 622 %d94-126 ; ">", "[", "]", or "\" 624 The msg-id MUST NOT be more than 250 octets in length. 626 NOTE: The length restriction ensures that systems which accept 627 message identifiers as a parameter when retrieving an article 628 (e.g. [NNTP]) can rely on a bounded length. 630 Observe that msg-id includes the < and >. 632 Observe also that in contrast to the corresponding header field in 633 [RFC2822]: 635 o the syntax does not allow comments within the Message-ID header 636 field, 638 o it ensures that no string of characters is quoted if it was 639 already a (it MUST start or end with a ".", or 640 contain at least one ), 642 o it ensures that no single character is prefixed by a "\" in the 643 form of a unless strictly necessary, 645 o it excludes all control characters, 647 o there is no possibility for ">" or WSP to occur inside a , 648 whether quoted or not, and 650 o even though commonly derived from s, s are 651 case-sensitive (and thus, once created, are not to be altered 652 during subsequent transmission or copying) 654 This is to simplify processing by news servers and to ensure 655 interoperability with existing implementations and compliance with 656 [NNTP]. Thus, whereas under [RFC2822] the following s would 657 be considered semantically equivalent, 659 660 <"ab.cd"@example.com> 661 <"ab.\cd"@example.com> 663 only the first of them is syntactically permitted by this standard, 664 and hence a simple comparison of octets will always suffice to 665 determine the identity of two s. 667 Also note that this updated ABNF applies wherever is used, 668 including the References header field discussed in Section 3.2.2 and 669 the Supersedes header field discussed in Section 3.2.6. 671 Some software will try to match the of a in a 672 case-insensitive fashion; some will match it in a case-sensitive 673 fashion. Implementations MUST NOT generate two Message-IDs where the 674 only difference is the case of characters in the part. 676 When generationg a , implementations SHOULD use a domain name 677 as the . 679 NOTE: Section 3.6.4 of [RFC2822] recommends that the 680 should be a domain name or a domain literal. Domain literals are 681 troublesome since many IP addresses are not globally unique; 682 domain names are more likely to generate unique Message-IDs. 684 3.1.4. Subject 686 The Subject header field is the same as that specified in Section 687 3.6.5 of [RFC2822] with the added restrictions detailed in 688 Section 2.2. Further discussion of the content of the Subject header 689 field appears in [USEPRO] and [USEAGE]. 691 subject = "Subject:" SP unstructured CRLF 693 3.1.5. Newsgroups 695 The Newsgroups header field specifies the newsgroup(s) to which the 696 article is posted. 698 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 700 newsgroup-list = [FWS] newsgroup-name 701 *( [FWS] "," [FWS] newsgroup-name ) [FWS] 703 newsgroup-name = component *( "." component ) 705 component = 1*component-char 707 component-char = ALPHA / DIGIT / "+" / "-" / "_" 709 Folding the Newsgroups header field over several lines has been shown 710 to harm propagation significantly. Folded Newsgroups header fields 711 SHOULD NOT be generated, but MUST be accepted. 713 A newsgroup component SHOULD NOT consist of digits only, and SHOULD 714 NOT contain uppercase letters. Such components MAY be used only to 715 refer to existing groups that do not conform to this naming scheme. 717 NOTE: All-digit components conflict with one widely used storage 718 scheme for articles. Mixed case groups cause confusion between 719 systems with case sensitive matching and systems with case 720 insensitive matching of s. 722 s beginning with underline ("_") are reserved for use by 723 future versions of this standard and MUST NOT be generated by user 724 agents (whether in Newsgroups header fields or in newgroup control 725 messages [USEPRO]). However, such names MUST be accepted by news 726 servers. 728 s beginning with "+" and "-" are reserved for private use 729 and MUST NOT be generated by user agents (whether in Newsgroups 730 header fields or in newgroup control messages [USEPRO]) without a 731 private prior agreement to do so. However, such names MUST be 732 accepted by news servers. 734 The following s are reserved, and MUST NOT be used as 735 the name of a newsgroup: 737 o Groups whose first (or only) component is "example" 738 o The group "poster" 740 The following within 762 the Subject header field. 764 3.1.6. Path 766 The Path header field indicates the route taken by an article since 767 its injection into the Netnews system. Each agent that processes an 768 article is required to prepend one (or more) identities to this 769 header field body. This is primarily to enable news servers to avoid 770 sending articles to sites already known to have them, in particular 771 the site they came from, and additionally to permit tracing the route 772 articles take in moving over the network, and for gathering Usenet 773 statistics. 775 path = "Path:" SP path-list CRLF 777 path-list = [FWS] 778 *( ( path-identity / path-keyword / 779 path-diagnostic ) [FWS] 780 path-delimiter [FWS] ) 781 tail-entry [FWS] 783 path-identity = ( ALPHA / DIGIT ) 784 *( ALPHA / DIGIT / "-" / "." / "_" ) 786 path-keyword = "POSTED" / "MISMATCH" 788 path-diagnostic = 1*( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 790 tail-entry = path-identity 792 path-delimiter = "!" / "!!" 794 A is a name identifying a site. It takes the form of 795 a domain name having one or more components separated by dots. 797 Each in the (excluding the one in the 798 ) indicates, from right to left, the successive agents 799 through which the article has passed. The "POSTED" 800 indicates that the agent to its left injected the article. The use 801 of the "!!" indicates that the agent to its left 802 claims that the agent to its right was the verified source of the 803 article (whereas the "!" implies no such claim). 804 The "MISMATCH" indicates that the agent to its right 805 failed to be so verified. 807 NOTE: Although case-insensitive, it is intended that the s "POSTED" and "MISMATCH" should be in upper case, to 809 distinguish them from the s which are traditionally 810 in lower case. 812 A is an item inserted into the Path header for 813 purposes other than to indicate the name of a site. One commonly 814 observed usage is to insert an IP address. The colon (":") is 815 permitted in order to allow IPv6 addresses to be inserted; note that 816 this will cause interoperability problems at older sites that regard 817 ":" as a and have neighbors whose names have 4 or 818 fewer characters, and where all the characters are valid HEX digits. 820 3.2. Optional Header Fields 822 None of the header fields appearing in this section is required to 823 appear in every article but some of them may be required in certain 824 types of articles. Further discussion of these requirements appears 825 in [USEPRO] and [USEAGE]. 827 The header fields Reply-To, Sender, Comments, and Keywords are used 828 in news articles in the same circumstances and with the same meaning 829 as that specified in [RFC2822] with the added restrictions detailed 830 in Section 2.2. Multiple occurances of the Keywords header field are 831 not permitted. 833 sender = "Sender:" SP mailbox CRLF 835 reply-to = "Reply-To:" SP address-list CRLF 837 comments = "Comments:" SP unstructured CRLF 839 keywords = "Keywords:" SP phrase *("," phrase) CRLF 841 The MIME header fields MIME-Version, Content-Type, Content-Transfer- 842 Encoding, Content-Disposition, and Content-Language are used in news 843 articles in the same circumstances and with the same meanings as 844 those specified in [RFC2045], [RFC2183], and [RFC3282] with the added 845 restrictions detailed in Section 2.2. 847 All remaining news header fields are described below. 849 3.2.1. Injection-Date 851 The Injection-Date header field contains the date and time that the 852 article was injected into the network. Its purpose is to prevent the 853 reinjection into the news stream of "stale" articles which have 854 already expired by the time they arrive at some news server. 856 This header field MUST be inserted whenever an article is injected. 857 However, software that predates this standard does not use this 858 header, and therefore agents MUST accept articles without the 859 Injection-Date header field. 861 injection-date = "Injection-Date:" SP date-time CRLF 863 See the remarks under Section 3.1.2 regarding the syntax of and the requirements and recommendations to which it is 865 subject. 867 NOTE: The in this header field would normally be 868 expected to be later than the in the Date header 869 field, but differences between the clocks on the various agents 870 and other special circumstances might vitiate that; no provision 871 is made for any such discrepancy to be corrected - better that the 872 news server should just insert the correct time as it sees it. 874 This header field is intended to replace the currently-used but 875 undocumented "NNTP-Posting-Date" header field, whose use is now 876 deprecated. 878 3.2.2. References 880 The References header field is the same as that specified in Section 881 3.6.4 of [RFC2822] with the added restrictions detailed in 882 Section 2.2 and those listed below: 884 o The updated construct defined in Section 3.1.3 MUST be 885 used. 887 o Message identifiers MUST be separated with CFWS. 889 o Comments in CFWS between message identifiers can cause 890 interoperability problems, so comments SHOULD NOT be generated, 891 but MUST be accepted. 893 references = "References:" SP [CFWS] msg-id *(CFWS msg-id) 894 [CFWS] CRLF 896 3.2.3. Followup-To 898 The Followup-To header field specifies to which newsgroup(s) 899 followups should be posted. The Followup-To header field SHOULD NOT 900 appear in a message, unless its content is different from the content 901 of the Newsgroups header field. 903 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 904 CRLF 906 poster-text = [FWS] %d112.111.115.116.101.114 [FWS] 907 ; "poster" in lower-case 909 The syntax is the same as that of the Newsgroups header field 910 (Section 3.1.5, with the exception that the keyword "poster" (which 911 is always lowercase) requests that followups should be mailed to the 912 article's reply address rather than posted. Although the keyword 913 "poster" is case-sensitive, user agents MAY choose to recognize case- 914 insensitive forms such as "Poster". 916 3.2.4. Expires 918 The Expires header field specifies a date and time when the article 919 is deemed to be no longer relevant and could usefully be removed 920 ("expired"). 922 expires = "Expires:" SP date-time CRLF 924 See the remarks under Section 3.1.2 regarding the syntax of and the requirements and recommendations to which it is 926 subject. 928 3.2.5. Control 930 The Control header field marks the article as a control message, and 931 specifies the desired actions (additional to the usual ones of 932 storing and/or relaying the article). 934 control = "Control:" SP [FWS] control-command [FWS] CRLF 936 control-command = verb *( [FWS] argument ) 938 verb = token 940 argument = value 942 The verb indicates what action should be taken, and the argument(s) 943 (if any) supply details. In some cases, the body of the article may 944 also contain details. The legal verbs and respective arguments are 945 discussed in the companion document, [USEPRO]. 947 An article with a Control header field MUST NOT also have a 948 Supersedes header field. 950 3.2.6. Supersedes 952 The Supersedes header field contains a message identifier specifying 953 an article to be superseded upon the arrival of this one. An article 954 containing a Supersedes header field is equivalent to a "cancel" 955 [USEPRO] control message for the specified article, followed 956 immediately by the new article without the Supersedes header field. 958 supersedes = "Supersedes:" SP [FWS] msg-id [FWS] CRLF 960 NOTE: There is no "c" in Supersedes. 962 NOTE: The Supersedes header field defined here has no connection with 963 the Supersedes header field that sometimes appears in Email messages 964 converted from X.400 according to [RFC2156]; in particular, the 965 syntax here permits only one in contrast to the multiple 966 s in that Email version. 968 3.2.7. Distribution 970 The Distribution header field specifies geographic or organizational 971 limits on an article's propagation. 973 distribution = "Distribution:" SP dist-list CRLF 975 dist-list = [FWS] dist-name 976 *( [FWS] "," [FWS] dist-name ) [FWS] 978 dist-name = ALPHA / DIGIT 979 *( ALPHA / DIGIT / "+" / "-" / "_" ) 981 The s "world" and "local" are predefined. However, 982 "world" SHOULD NOT be used explicitly, since it is the default when 983 the Distribution header field is absent entirely. 985 "All" MUST NOT be used as a . s SHOULD contain 986 at least three characters, except when they are two-letter country 987 names as in [ISO.3166.1988]. s are case-insensitive (i.e. 988 "US", "Us", "uS", and "us" all specify the same distribution). 990 3.2.8. Summary 992 The Summary header field is a short phrase summarizing the article's 993 content. 995 summary = "Summary:" SP unstructured CRLF 997 3.2.9. Approved 999 The Approved header field indicates the mailing addresses (and 1000 possibly the full names) of the persons or entities approving the 1001 article for posting. Its principal uses are in moderated articles 1002 and in group control messages [USEPRO]. 1004 approved = "Approved:" SP mailbox-list CRLF 1006 Each mailbox contained in the Approved header field MUST be that of 1007 one of the person(s) or entity(ies) in question, and one of those 1008 mailboxes MUST be that of the actual sender of the article. Note 1009 that this standard does not provide any means to enforce or verify 1010 this requirement, but future extensions or standards may provide such 1011 a facility (e.g. digitial signatures). 1013 3.2.10. Organization 1015 The Organization header field is a short phrase identifying the 1016 poster's organization. 1018 organization = "Organization:" SP unstructured CRLF 1020 There is no "s" in Organization. 1022 3.2.11. Xref 1024 The Xref header field indicates where an article was filed by the 1025 last news server to process it. The article locations are used to 1026 keep track of crossposted articles so that user agents serviced by a 1027 particular news server can mark such articles as read. 1029 xref = "Xref:" SP [FWS] server-name 1030 1*( FWS location ) [FWS] CRLF 1032 server-name = path-identity 1034 location = newsgroup-name ":" article-locator 1036 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 1037 ; US-ASCII printable characters 1038 ; except '(' and ';' 1040 The is included so that software can determine which 1041 news server generated the header field. The locations specify what 1042 newsgroups the article was filed under (which may differ from those 1043 in the Newsgroups header field) and where it was filed under them. 1044 The exact form of an is implementation-specific. 1046 NOTE: The traditional form of an (as required by 1047 [NNTP]) is a decimal number, with articles in each newsgroup 1048 numbered consecutively starting from 1. 1050 3.2.12. Archive 1052 The Archive header field provides an indication of the poster's 1053 intent regarding preservation of the article in publicly accessible 1054 long-term or permanent storage. 1056 archive = "Archive:" SP [CFWS] ("no" / "yes") 1057 *( [CFWS] ";" archive-param ) CRLF 1059 archive-param = parameter 1061 The presence of an Archive header field in an article with a field 1062 body of "no" indicates that the poster does not permit redistribution 1063 from publicly accessible long-term or permanent archives. The 1064 absence of this header field, or the presence of this header field 1065 with a field body of "yes", indicates that the poster is willing for 1066 such redistribution to take place. Further extensions to this 1067 standard may provide parameters for administration of the archiving 1068 process. 1070 3.2.13. User-Agent 1072 The User-Agent header field contains information about the user agent 1073 (typically a newsreader) generating the article, for statistical 1074 purposes and tracing of standards violations to specific software 1075 needing correction. It is intended that this header field be 1076 suitable for use in Email. 1078 user-agent = "User-Agent:" SP 1*product [CFWS] CRLF 1080 product = [CFWS] token [ [CFWS] "/" product-version ] 1082 product-version = [CFWS] token 1084 This header field MAY contain multiple product-tokens identifying the 1085 user agent and any subproducts which form a significant part of it, 1086 listed in order of their significance for identifying the 1087 application. 1089 NOTE: Some of this information has previously been sent in non- 1090 standardized header fields such as X-Newsreader, X-Mailer, 1091 X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent 1092 uses User-Agent, it should have no need to send these non-standard 1093 header fields. 1095 NOTE: [RFC2616] describes a similar facility for the HTTP 1096 protocol. This specification differs in that "{" and "}" are 1097 allowed in tokens ( and ) and comments 1098 are permitted wherever whitespace is allowed. 1100 3.2.14. Injection-Info 1102 The Injection-Info header field contains information provided by the 1103 injecting news server as to how an article entered the Netnews system 1104 and to assist in tracing its true origin. It can also specify one or 1105 more addresses where complaints concerning the poster of the article 1106 may be sent. 1108 injection-info = "Injection-Info:" SP [CFWS] path-identity 1109 [CFWS] *(';' parameter) CRLF 1111 NOTE: The syntax of ([RFC2045] as amended by 1112 [RFC2231]), taken in conjunction with the folding rules of 1113 [RFC0822], effectively allows [CFWS] to occur both before and 1114 after the , and also on either side of its "=". 1116 The following table gives the and the format of the 1117 for each defined for use with this header field. 1118 At most one occurrence of each such is allowed. 1120 format of 1121 -------------------- ----------------- 1122 "posting-host" a 1123 "posting-account" any 1124 "sender" a 1125 "logging-data" any 1126 "mail-complaints-to" an 1128 where 1130 host-value = dot-atom-text / [ dot-atom-text ":" ] 1131 ( IPv4address / IPv6address ) ; see [RFC 3986] 1133 sender-value = mailbox / "verified" 1135 NOTE: Since any such >, or has also to be a syntactically correct , it will 1137 usually be necessary to encapsulate is as a , for 1138 example: 1140 sender = "\"Joe Q. Public\" " 1142 Additionally, any other whose starts with 1143 "x-" MAY be used where the defined ones appear to be unsuitable, but 1144 other unlisted s SHOULD NOT be used unless defined in 1145 extensions to this standard. 1147 Although comments and folding of white space are permitted throughout 1148 the Injection-Info header field, it is RECOMMENDED that folding is 1149 not used within any (but only before or after the ";" 1150 separating those s), and that comments are only used 1151 following the last . 1153 NOTE: Some of this information has previously been sent in non- 1154 standardized header fields such as NNTP-Posting-Host, X-trace, 1155 X-Complaints-To, and others. Once a news server uses Injection- 1156 Info, it should have no need to send these non-standard header 1157 fields. 1159 The "posting-host" specifies the FQDN and/or IP address 1160 (IPv4address or IPv6address) of the host from which the news server 1161 received the article. 1163 NOTE: If the "posting-host" identifies a dial-up 1164 point-of-presence, the "posting-account" or the "logging-data" 1165 may provide additional information about true origin 1166 of the article. 1168 The "posting-account" identifies the source from which 1169 that news server received the article. For security reasons, it 1170 SHOULD be in a cryptic notation understandable only by the 1171 administrator of the news server. 1173 The "sender" identifies the mailbox of the verified 1174 sender of the article (alternatively, it uses the token "verified" to 1175 indicate that at least any addr-spec in the Sender header field of 1176 the article, or in the From header field if the Sender header field 1177 is absent, is correct). If a news server can verify the sender of an 1178 article, it SHOULD use this in favor of the "posting- 1179 account" . 1181 The "logging-data" contains information (typically a 1182 session number or other non-persistent means of identifying a posting 1183 account) which will enable the true origin of the article to be 1184 determined by reference to logging information kept by the news 1185 server. 1187 The "mail-complaints-to" specifies mailbox(es) for 1188 sending complaints concerning the behavior of the poster of the 1189 article. 1191 3.3. Obsolete Header Fields 1193 Early versions of news software following the modern format sometimes 1194 generated header fields like the following: 1196 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP 1197 Posting-Version: version B 2.10 2/13/83; site eagle.UUCP 1198 Date-Received: Friday, 19-Nov-82 16:59:30 EST 1200 Relay-Version contained version information about the news server 1201 that last processed the article. Posting-Version contained version 1202 information about the user agent that posted the article. Date- 1203 Received contained the date when the last news server to process the 1204 article first saw it (in a slightly nonstandard format). 1206 In addition, this present standard obsoletes certain header fields 1207 defined in [Son-of-1036]: 1209 Also-Control: cancel <9urrt98y53@site.example> 1210 See-Also: 1211 Article-Names: comp.foo:charter 1212 Article-Updates: 1214 Also-Control indicated a control message that was also intended to be 1215 filed as a normal article. See-Also listed related articles, but 1216 without the specific relationship with followups that pertains to the 1217 References header field. Article-Names indicated some special 1218 significance of that article in relation to the indicated newsgroup. 1219 Article-Updates indicated that an earlier article was updated, 1220 without at the same time being superseded. 1222 The header fields listed above are documented for historical purposes 1223 only. Articles containing these header fields MUST NOT be generated. 1224 Persons writing new agents SHOULD ignore any former meanings of these 1225 header fields. 1227 3.3.1. Lines 1229 The Lines header field indicates the number of lines in the body of 1230 the article. 1232 lines = "Lines" ":" SP [FWS] 1*DIGIT [FWS] CRLF 1234 The line count includes all body lines, including the signature if 1235 any, including empty lines (if any) at the beginning or end of the 1236 body, and including the whole of all MIME message and multipart parts 1237 contained in the body (the single empty separator line between the 1238 header fields and the body is not part of the body). The "body" here 1239 is the body as found in the posted article as transmitted by the user 1240 agent. 1242 Historically, this header field was used by the [NNTP] overview 1243 extension, but its use for this purpose is now deprecated. As a 1244 result, this header field is to be regarded as obsolescent, and it is 1245 likely to be removed entirely in a future version of this standard. 1246 Servers and clients SHOULD ignore it, and SHOULD NOT generate it. 1248 4. Internationalization Considerations 1250 Internationalization of news article header fields and bodies is 1251 provided using MIME mechanisms discussed in Section 2.3. Note that 1252 the generation of internationalized s for use in 1253 header fields is not addressed in this document. 1255 5. Security Considerations 1257 The news article format specified in this document does not provide 1258 any security services, such as confidentiality, authentication of 1259 sender, or non-repudiation. Instead, such services need to be 1260 layered above, using such protocols as S/MIME [RFC3851] or PGP/MIME 1261 [RFC3156], or below, using secure versions of news transport 1262 protocols. Additionally, several currently non-standardized 1263 protocols [PGPVERIFY] will hopefully be standardized in the near 1264 future. 1266 Message identifiers (Section 3.1.3) in news are required to be 1267 unique; articles are refused (in server-to-server transfer) if the 1268 identifier has already been seen. So if you can predict the 1269 identifier of a message, you can preempt it by posting a message 1270 (possibly to a quite different group) with the same message 1271 identifier, stopping your target message from propagating. Agents 1272 that generate message identifiers for news articles SHOULD ensure 1273 that they are unpredictable. 1275 MIME security considerations are discussed in [RFC2046]. Note that 1276 the full range of encodings allowed for parameters in [RFC2046] and 1277 [RFC2231] permits constructs that simple parsers may fail to parse 1278 correctly; examples of hard-to-parse constructs are: 1280 Content-Type: multipart/mixed 1281 (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") 1283 Content-Type: multipart/digest; 1284 boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy 1286 Such differences in parsing may be used as part of an attack. 1288 6. References 1290 6.1. Normative References 1292 [Errata] "RFC Editor Errata". 1294 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1295 Extensions (MIME) Part One: Format of Internet Message 1296 Bodies", RFC 2045, November 1996. 1298 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1299 Extensions (MIME) Part Two: Media Types", RFC 2046, 1300 November 1996. 1302 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1303 Part Three: Message Header Extensions for Non-ASCII Text", 1304 RFC 2047, November 1996. 1306 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1307 Extensions (MIME) Part Five: Conformance Criteria and 1308 Examples", RFC 2049, November 1996. 1310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1311 Requirement Levels", BCP 14, RFC 2119, March 1997. 1313 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1314 Presentation Information in Internet Messages: The 1315 Content-Disposition Header Field", RFC 2183, August 1997. 1317 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1318 Word Extensions: Character Sets, Languages, and 1319 Continuations", RFC 2231, November 1997. 1321 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1322 Specifications: ABNF", RFC 2234, November 1997. 1324 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1325 April 2001. 1327 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1328 May 2002. 1330 6.2. Informative References 1332 [ISO.3166.1988] 1333 International Organization for Standardization, "Codes for 1334 the representation of names of countries, 3rd edition", 1335 ISO Standard 3166, August 1988. 1337 [NNTP] Feather, C., "Network News Transfer Protocol", 1338 draft-ietf-nntpext-base-*.txt. 1340 [PGPVERIFY] 1341 Lawrence, D., "PGPverify", June 1999. 1343 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1344 text messages", STD 11, RFC 822, August 1982. 1346 [RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer 1347 Protocol", RFC 977, February 1986. 1349 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1350 USENET messages", RFC 1036, December 1987. 1352 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1353 Mapping between X.400 and RFC 822/MIME", RFC 2156, 1354 January 1998. 1356 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1357 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1358 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1360 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1361 "MIME Security with OpenPGP", RFC 3156, August 2001. 1363 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1364 Extensions (S/MIME) Version 3.1 Message Specification", 1365 RFC 3851, July 2004. 1367 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1368 Resource Identifier (URI): Generic Syntax", STD 66, 1369 RFC 3986, January 2005. 1371 [Son-of-1036] 1372 Spencer, H., "News Article Format and Transmission", 1373 June 1994. 1375 [USEAGE] Lindsey, C., "Usenet Best Practice", 1376 draft-ietf-usefor-useage-*.txt. 1378 [USEPRO] Lindsey, C., "News Article Architecture and Protocols", 1379 draft-ietf-usefor-usepro-*.txt. 1381 Appendix A. Acknowledgements 1383 Comments and/or text were provided by Mark Crispin, Claus Faerber, 1384 Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, 1385 Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey 1386 Melnikov. 1388 Appendix B. Differences from RFC 1036 and its derivatives 1390 This appendix contains a list of changes that have been made in the 1391 Netnews Article Format from earlier standards, specifically 1392 [RFC1036]. 1394 The [RFC2822] conventions for parenthesis-enclosed s in 1395 header fields are supported in all newly defined header fields and 1396 in header fields inherited from [RFC2822]. They are, however, 1397 still disallowed for performance and/or compatibility reasons in 1398 the Message-ID, Newsgroups, Path, Followup-To, Control, 1399 Supersedes, Distribution, Xref and Lines header fields. 1401 Whitespace is permitted in Newsgroups header fields. 1403 An enhanced syntax for the Path header field enables the injection 1404 point of, and the route taken by an article to be determined with 1405 more precision. 1407 MIME is recognized as an integral part of Netnews. 1409 There is a new Injection-Date header to make the rejection of 1410 stale articles more precise and to minimize spurious rejections. 1412 There are several new optional header fields defined, notably 1413 Archive, Injection-Info and User-Agent, leading to increased 1414 functionality. 1416 Certain header fields, notably Lines, have been made obsolete 1417 (Section 3.3). 1419 There are numerous other small changes, clarifications and 1420 enhancements. 1422 Appendix C. Differences from RFC 2822 1424 This appendix lists the differences between the syntax allowed by the 1425 Netnews Article Format (this document) as compared to the Internet 1426 Message Format, as specified in [RFC2822]. 1428 The Netnews article format is a strict subset of the Internet Message 1429 Format; all Netnews articles conform to the syntax of [RFC2822]. 1431 The following restrictions are important: 1433 A SP (space) is REQUIRED after the colon (':') following header 1434 field name. 1436 A more restricted syntax of (to be used by the 1437 Message-ID, References, and Supersedes header fields) is defined. 1439 The length of a msg-id MUST NOT exceed 250 octets. 1441 Comments are not allowed in the Message-ID header field. 1443 The CFWS between s in the References header field is not 1444 optional. 1446 It is legal for a parser to not accept obsolete syntax, except 1447 that: 1449 The construct MUST be accepted. 1451 The obsolete "GMT" MUST be accepted within a . 1454 Every line of a header field body (including the first and any 1455 that are subsequently folded) MUST contain at least one non- 1456 whitespace character. This means that an empty header field body 1457 is illegal. 1459 Authors' Addresses 1461 Kenneth Murchison (editor) 1462 Carnegie Mellon University 1463 5000 Forbes Avenue 1464 Cyert Hall 285 1465 Pittsburgh, PA 15213 1466 US 1468 Phone: +1 412 268 2638 1469 Email: murch@andrew.cmu.edu 1471 Charles H. Lindsey 1472 University of Manchester 1473 5 Clerewood Avenue 1474 Heald Green 1475 Cheadle 1476 Cheshire SK8 3JU 1477 GB 1479 Phone: +44 161 436 6131 1480 Email: chl@clw.cs.man.ac.uk 1482 Dan Kohn 1483 Skymoon Ventures 1484 3045 Park Boulevard 1485 Palo Alto, CA 94306 1486 US 1488 Phone: +1 650 327 2600 1489 Email: dan@dankohn.com 1491 Intellectual Property Statement 1493 The IETF takes no position regarding the validity or scope of any 1494 Intellectual Property Rights or other rights that might be claimed to 1495 pertain to the implementation or use of the technology described in 1496 this document or the extent to which any license under such rights 1497 might or might not be available; nor does it represent that it has 1498 made any independent effort to identify any such rights. Information 1499 on the procedures with respect to rights in RFC documents can be 1500 found in BCP 78 and BCP 79. 1502 Copies of IPR disclosures made to the IETF Secretariat and any 1503 assurances of licenses to be made available, or the result of an 1504 attempt made to obtain a general license or permission for the use of 1505 such proprietary rights by implementers or users of this 1506 specification can be obtained from the IETF on-line IPR repository at 1507 http://www.ietf.org/ipr. 1509 The IETF invites any interested party to bring to its attention any 1510 copyrights, patents or patent applications, or other proprietary 1511 rights that may cover technology that may be required to implement 1512 this standard. Please address the information to the IETF at 1513 ietf-ipr@ietf.org. 1515 Disclaimer of Validity 1517 This document and the information contained herein are provided on an 1518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1520 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1521 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1522 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1525 Copyright Statement 1527 Copyright (C) The Internet Society (2005). This document is subject 1528 to the rights, licenses and restrictions contained in BCP 78, and 1529 except as set forth therein, the authors retain all their rights. 1531 Acknowledgment 1533 Funding for the RFC Editor function is currently provided by the 1534 Internet Society.