idnits 2.17.1 draft-ietf-usefor-usefor-12.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, updated by RFC 4748 on line 1639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1663. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 8, 2007) is 6290 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: 'FWS' is mentioned on line 1529, but not defined == Missing Reference: 'CFWS' is mentioned on line 922, but not defined == Unused Reference: 'RFC3696' is defined on line 1488, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-usefor-usepro-07 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 850 (Obsoleted by RFC 1036) -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Usenet Format Working Group K. Murchison, Ed. 3 Internet-Draft Carnegie Mellon University 4 Obsoletes: 1036 (if approved) C. Lindsey 5 Intended status: Standards Track University of Manchester 6 Expires: July 12, 2007 D. Kohn 7 FlyDash, Inc. 8 January 8, 2007 10 Netnews Article Format 11 draft-ietf-usefor-usefor-12 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 July 12, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document specifies the syntax of Netnews articles in the context 45 of the "Internet Message Format" (RFC 2822) and "Multipurpose 46 Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes 47 RFC 1036, providing an updated specification to reflect current 48 practice and incorporating incremental changes specified in other 49 documents. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Requirements Notation . . . . . . . . . . . . . . . . . . 4 57 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 58 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.6. Structure of This Document . . . . . . . . . . . . . . . . 7 60 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 63 2.3. MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10 64 3. News Header Fields . . . . . . . . . . . . . . . . . . . . . . 11 65 3.1. Mandatory Header Fields . . . . . . . . . . . . . . . . . 11 66 3.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.1.3. Message-ID . . . . . . . . . . . . . . . . . . . . . . 12 69 3.1.4. Newsgroups . . . . . . . . . . . . . . . . . . . . . . 15 70 3.1.5. Path . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 3.1.6. Subject . . . . . . . . . . . . . . . . . . . . . . . 18 72 3.2. Optional Header Fields . . . . . . . . . . . . . . . . . . 18 73 3.2.1. Approved . . . . . . . . . . . . . . . . . . . . . . . 19 74 3.2.2. Archive . . . . . . . . . . . . . . . . . . . . . . . 19 75 3.2.3. Control . . . . . . . . . . . . . . . . . . . . . . . 20 76 3.2.4. Distribution . . . . . . . . . . . . . . . . . . . . . 20 77 3.2.5. Expires . . . . . . . . . . . . . . . . . . . . . . . 21 78 3.2.6. Followup-To . . . . . . . . . . . . . . . . . . . . . 21 79 3.2.7. Injection-Date . . . . . . . . . . . . . . . . . . . . 22 80 3.2.8. Injection-Info . . . . . . . . . . . . . . . . . . . . 22 81 3.2.9. Organization . . . . . . . . . . . . . . . . . . . . . 24 82 3.2.10. References . . . . . . . . . . . . . . . . . . . . . . 24 83 3.2.11. Summary . . . . . . . . . . . . . . . . . . . . . . . 25 84 3.2.12. Supersedes . . . . . . . . . . . . . . . . . . . . . . 25 85 3.2.13. User-Agent . . . . . . . . . . . . . . . . . . . . . . 25 86 3.2.14. Xref . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 3.3. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 26 88 3.3.1. Lines . . . . . . . . . . . . . . . . . . . . . . . . 27 90 4. Internationalization Considerations . . . . . . . . . . . . . 28 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 94 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 95 7.2. Informative References . . . . . . . . . . . . . . . . . . 36 96 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 38 97 Appendix B. Differences from RFC 1036 and its derivatives . . . . 39 98 Appendix C. Differences from RFC 2822 . . . . . . . . . . . . . . 40 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 100 Intellectual Property and Copyright Statements . . . . . . . . . . 42 102 1. Introduction 104 1.1. Basic Concepts 106 "Netnews" is a set of protocols for generating, storing and 107 retrieving news "articles" (whose format is a subset of that for 108 Email messages), and for exchanging them amongst a readership that is 109 potentially widely distributed. It is organized around "newsgroups", 110 with the expectation that each reader will be able to see all 111 articles posted to each newsgroup in which he participates. These 112 protocols most commonly use a flooding algorithm which propagates 113 copies throughout a network of participating servers. Typically, 114 only one copy is stored per server, and each server makes it 115 available on demand to readers able to access that server. 117 1.2. Scope 119 This document specifies the syntax of Netnews articles in the context 120 of the "Internet Message Format" [RFC2822] and "Multipurpose Internet 121 Mail Extensions (MIME)" [RFC2045]. This document obsoletes 122 [RFC1036], updating the syntax of Netnews articles to reflect current 123 practice and incorporating changes and clarifications specified in 124 other documents such as [Son-of-1036]. 126 This is the first in a set of documents that obsolete [RFC1036]. 127 This document focuses on the syntax and semantics of Netnews 128 articles. [I-D.ietf-usefor-usepro] is also a standards-track 129 document and describes the protocol issues of Netnews articles, 130 independent of transport protocols such as NNTP [RFC3977]. A best- 131 common-practice document, [I-D.ietf-usefor-useage], describes 132 implementation recommendations to improve interoperability and 133 usability. 135 This specification is intended as a definition of what article 136 content format is to be passed between systems. Although many news 137 systems locally store articles in this format (which eliminates the 138 need for translation between formats), local storage is outside of 139 the scope of this standard. 141 1.3. Requirements Notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 1.4. Syntax Notation 149 Header fields defined in this specification use the Augmented Backus- 150 Naur Form (ABNF) notation (including the Core Rules) specified in 151 [RFC4234] and many constructs defined in [RFC2822], [RFC2045] as 152 updated by [RFC2231], and [RFC3986], specifically: 154 token = 155 value = 156 parameter = 157 attribute = 159 FWS = 160 comment = 161 CFWS = 162 atext = 163 dot-atom-text = 164 phrase = 165 utext = 166 date-time = 167 mailbox = 168 mailbox-list = 169 address-list = 170 body = 171 fields = 173 IPv6address = 174 IPv4address = 176 ALPHA = 177 CRLF = 178 DIGIT = 179 DQUOTE = 180 SP = 182 Additionally, Section 3.1.3 specifies a stricter definition of 183 than the syntax in [RFC2822] Section 3.6.4. 185 1.5. Definitions 187 An "article" is the unit of Netnews, analogous to an [RFC2822] 188 "message". A "proto-article" is one that has not yet been injected 189 into the news system. In contrast to an "article", a "proto-article" 190 may lack some mandatory header fields. 192 A "message identifier" (Section 3.1.3) is a unique identifier for an 193 article, usually supplied by the "user agent" that posted it or, 194 failing that, by the "news server". It distinguishes the article 195 from every other article ever posted anywhere. Articles with the 196 same message identifier are treated as if they are the same article 197 regardless of any differences in the body or header fields. 199 A "newsgroup" is a forum having a name and intended for articles on a 200 specific topic. An article is "posted to" a single newsgroup or 201 several newsgroups. When an article is posted to more than one 202 newsgroup, it is said to be "crossposted"; note that this differs 203 from posting the same text as part of each of several articles, one 204 per newsgroup. 206 A newsgroup may be "moderated", in which case submissions are not 207 posted directly, but mailed to a "moderator" for consideration and 208 possible posting. Moderators are typically human but may be 209 implemented partially or entirely in software. 211 A "poster" is the person or software that composes and submits a 212 potentially compliant article to a "user agent". 214 A "reader" is the person or software reading Netnews articles. 216 A "followup" is an article containing a response to the contents of 217 an earlier article, its "precursor". Every followup includes a 218 "References" header field identifying that precursor (but note that 219 non-followup articles may also use a References header field). 221 A "control message" is an article which is marked as containing 222 control information; a news server receiving such an article may 223 (subject to the policies observed at that site) take actions beyond 224 just filing and passing on the article. 226 A "news server" is software that may accept articles from a "user 227 agent", and/or make articles available to user agents, and/or 228 exchange articles with other news servers. 230 A "user agent" is software that may help posters submit proto- 231 articles to a news server, and/or fetch articles from a news server 232 and present them to a reader, and/or assist the reader in creating 233 articles and followups. 235 The generic term "agent" is used when describing requirements that 236 apply to both user agents and news servers. 238 An agent is said to "generate" a construct if it did not exist before 239 the agent created it. Examples are when a user agent creates a 240 message from text and addressing information supplied by a user, or 241 when a news server creates an "Injection-Info" header field for a 242 newly posted message. 244 An agent is said to "accept" a construct if some other entity 245 generates it and passes it to the agent in question, and the agent 246 processes it without treating it as a format or protocol error. 248 1.6. Structure of This Document 250 This document uses a cite-by-reference methodology, rather than 251 repeating the contents of other standards, which could otherwise 252 result in subtle differences and interoperability challenges. 253 Although this document is as a result rather short, it requires 254 complete understanding and implementation of the normative references 255 to be compliant. 257 Section 2 defines the format of Netnews articles. Section 3 details 258 the header fields necessary to make an article suitable for the 259 Netnews environment. 261 2. Format 263 2.1. Base 265 An article is said to be conformant to this specification if it 266 conforms to the format specified in [RFC2822] Section 3 and to the 267 additional requirements of this specification. 269 An article that uses the obsolete syntax specified in Section 4 of 270 [RFC2822] is NOT conformant to this specification, except for the 271 following two cases: 273 o Articles are conformant if they use the construct 274 (use of a phrase like "John Q. Public" without the use of quotes, 275 see [RFC2822] Section 4.1) but agents MUST NOT generate 276 productions of such syntax. 278 o Articles are conformant if they use the "GMT" , as specified 279 in Section 3.1.1. 281 This document, and specifications that build upon it, specify how to 282 handle conformant articles. Handling of non-conformant articles is 283 outside the scope of this specification. 285 Agents conforming to this specification MUST generate only conformant 286 articles. 288 The text below uses ABNF to specify restrictions on the syntax 289 specified in [RFC2822]; this grammar is intended to be more 290 restrictive than the [RFC2822] grammar. Articles must conform to the 291 ABNF specified in [RFC2822] and also to the restrictions specified 292 here, both those that are expressed as text and those that are 293 expressed as ABNF. 295 NOTE: Other specifications use the term "header" as a synonym for 296 what [RFC2822] calls "header field". This document follows the 297 terminology in Section 2 of [RFC2822] in using the terms "line", 298 "header field", "header field name", "header field body", and 299 "folding", based on a belief that consistent terminology among 300 specifications that depend on each other makes the specifications 301 easier to use in the long run. 303 2.2. Header Fields 305 All header fields in a Netnews article are compliant with [RFC2822]; 306 this specification, however, is less permissive in what can be 307 generated and accepted by agents. The syntax allowed for Netnews 308 article headers is a strict subset of the "Internet Message Format" 309 headers, making all headers compliant with this specification 310 inherently compliant with [RFC2822]. Note however that the converse 311 is not guaranteed to be true in all cases. 313 General rules which apply to all header fields (even those documented 314 in [RFC2822] and [RFC2045]) are listed below, and those that apply to 315 specific header fields are described in the relevant sections of this 316 document. 318 o All agents MUST generate header fields so that at least one space 319 immediately follows the ':' separating the header field name and 320 the header field body (for compatibility with deployed software, 321 including NNTP [RFC3977] servers). News agents MAY accept header 322 fields which do not contain the required space. 324 o Every line of a header field body (including the first and any 325 that are subsequently folded) MUST contain at least one non- 326 whitespace character. 328 NOTE: This means that no header field body defined by or 329 referenced by this document can be empty. As a result, rather 330 than using the syntax from Section 3.2.6 of 331 [RFC2822], this document uses a stricter definition: 333 unstructured = *WSP utext *( [FWS] utext ) *WSP 335 NOTE: The [RFC2822] specification sometimes uses [FWS] at the 336 beginning or end of ABNF describing header field content. This 337 specification uses *WSP in such cases, also in cases where this 338 specification redefines constructs from [RFC2822]. This is 339 done for consistency with the restriction described here, but 340 the restriction applies to all header fields, not just those 341 where ABNF is defined in this document. 343 o Compliant software MUST NOT generate (but MAY accept) header field 344 lines of more than 998 octets. This is the only limit on the 345 length of a header field line prescribed by this standard. 346 However, specific rules to the contrary may apply in particular 347 cases (for example, according to [RFC2047], lines of a header 348 field containing encoded-words are limited to 76 octets). 349 [I-D.ietf-usefor-useage] includes suggested limits for convenience 350 of display by user agents. 352 NOTE: As stated in [RFC2822], there is NO restriction on the 353 number of lines into which a header field may be split, and 354 hence there is NO restriction on the total length of a header 355 field (in particular it may, by suitable folding, be made to 356 exceed the 998 octets restriction pertaining to a single header 357 field line). 359 o The character set for header fields is US-ASCII. Where the use of 360 non-ASCII characters is required, they MUST be encoded using the 361 MIME mechanisms defined in [RFC2047] and [RFC2231]. 363 2.3. MIME Conformance 365 User agents MUST meet the definition of MIME conformance in [RFC2049] 366 and MUST also support [RFC2231]. This level of MIME conformance 367 provides support for internationalization and multimedia in message 368 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 369 internationalization of header fields ([RFC2047], [RFC2231]). Note 370 that [Errata] currently exist for [RFC2046] and [RFC2231]. 372 For the purposes of Section 5 of [RFC2047], all header fields defined 373 in Section 3 of this standard are to be considered as "extension 374 message header fields", permitting the use of [RFC2047] encodings 375 within any header field, or within any or 376 permitted within any structured header field. 378 User agents MAY accept and generate other MIME extension header 379 fields, and in particular SHOULD accept Content-Disposition [RFC2183] 380 and Content-Language [RFC3282]. 382 3. News Header Fields 384 The following news header fields extend those defined in Section 3.6 385 of [RFC2822]: 387 fields =/ *( approved / 388 archive / 389 control / 390 distribution / 391 expires / 392 followup-to / 393 injection-date / 394 injection-info / 395 lines / 396 newsgroups / 397 organization / 398 path / 399 summary / 400 supersedes / 401 user-agent / 402 xref ) 404 Each of these header fields may occur at most once in a news article. 406 The following header fields defined in this document do not allow 407 comments (CFWS): 409 Control 410 Distribution 411 Followup-To 412 Newsgroups 413 Lines 414 Path 415 Supersedes 416 Xref 418 This also applies to the following header field defined in [RFC2822]: 420 Message-ID 422 Most of these header fields are mainly of interest to news servers, 423 and news servers often need to process these fields very rapidly. 424 Thus some header fields prohibit s. 426 3.1. Mandatory Header Fields 428 Each Netnews article conformant with this specification MUST have 429 exactly one of each of the following header fields: Date, From, 430 Message-ID, Newsgroups, Path, Subject. 432 3.1.1. Date 434 The Date header field is the same as that specified in Sections 3.3 435 and 3.6.1 of [RFC2822] with the added restrictions detailed above in 436 Section 2.2. However, the use of "GMT" as a time zone (part of ), although deprecated, is widespread in Netnews articles today. 438 Therefore, agents MUST accept constructs that use the 439 "GMT" zone. 441 orig-date = "Date:" SP date-time CRLF 443 NOTE: This specification does not change [RFC2822], which says 444 that agents MUST NOT generate constructs which include 445 any zone names defined by . 447 Software that accepts dates with unknown timezones SHOULD treat such 448 timezones as equivalent to "-0000" when comparing dates, as specified 449 in [RFC2822] Section 4.3. 451 Also note that these requirements apply wherever is used, 452 including Injection-Date and Expires in Section 3.2.7 and 453 Section 3.2.5, respectively. 455 3.1.2. From 457 The From header field is the same as that specified in Section 3.6.2 458 of [RFC2822] with the added restrictions detailed above in 459 Section 2.2. 461 from = "From:" SP mailbox-list CRLF 463 3.1.3. Message-ID 465 The Message-ID header field contains a unique message identifier. 466 Netnews is more dependent on message identifier uniqueness and fast 467 comparison than Email is, and some news software and standards 468 [RFC3977] might have trouble with the full range of possible 469 s permitted by [RFC2822]. This section therefore restricts 470 the syntax of as compared to Section 3.6.4 of [RFC2822]. 471 The global uniqueness requirement for in [RFC2822] is to be 472 understood as applying across all protocols using such message 473 identifiers, and across both Email and Netnews in particular. 475 message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF 477 msg-id = "<" msg-id-core ">" 478 ; maximum length is 250 octets 480 msg-id-core = id-left "@" id-right 482 id-left = dot-atom-text / no-fold-quote 484 id-right = dot-atom-text / no-fold-literal 486 no-fold-quote = DQUOTE 487 ( "." *mqtext / 488 *mqtext "." / 489 *mqtext mqspecial *mqtext ) 490 DQUOTE 492 mqtext = atext / "." / mqspecial 494 mqspecial = "(" / ")" / ; same as specials except 495 "<" / ; "\" and DQUOTE quoted 496 "[" / "]" / ; "." doubled and ">" omitted 497 ":" / ";" / 498 "@" / "," / 499 ".." / "\\" / "\" DQUOTE 501 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 503 mdtext = %d33-61 / ; The rest of the US-ASCII 504 %d63-90 / ; characters not including 505 %d94-126 ; ">", "[", "]", or "\" 507 The msg-id MUST NOT be more than 250 octets in length. 509 NOTE: The length restriction ensures that systems that accept 510 message identifiers as a parameter when referencing an article 511 (e.g. [RFC3977]) can rely on a bounded length. 513 Observe that msg-id includes the < and >. 515 Observe also that in contrast to the corresponding header field in 516 [RFC2822]: 518 o the syntax does not allow comments within the Message-ID header 519 field, 521 o it ensures that no string of characters is quoted if it were 522 already a (it MUST start or end with a ".", or 523 contain at least one ), 525 o it ensures that no single character is prefixed by a "\" in the 526 form of a unless strictly necessary, 528 o it excludes all control characters, 530 o there is no possibility for ">" or WSP to occur inside a , 531 whether quoted or not, and 533 o even though commonly derived from s, s are 534 case-sensitive (and thus, once created, are not to be altered 535 during subsequent transmission or copying) 537 This is to simplify processing by news servers and to ensure 538 interoperability with existing implementations and compliance with 539 [RFC3977]. Thus, whereas under [RFC2822] the following s 540 would be considered semantically equivalent, 542 543 <"ab.cd"@example.com> 544 <"ab.\cd"@example.com> 546 only the first of them is syntactically permitted by this standard, 547 and hence a simple comparison of octets will always suffice to 548 determine the identity of two s. 550 Also note that this updated ABNF applies wherever is used, 551 including the References header field discussed in Section 3.2.10 and 552 the Supersedes header field discussed in Section 3.2.12. 554 Some software will try to match the of a in a 555 case-insensitive fashion; some will match it in a case-sensitive 556 fashion. Implementations MUST NOT generate a Message-ID where the 557 only difference from another Message-ID is the case of characters in 558 the part. 560 When generating a , implementations SHOULD use a domain name 561 as the . 563 NOTE: Section 3.6.4 of [RFC2822] recommends that the 564 should be a domain name or a domain literal. Domain literals are 565 troublesome since many IP addresses are not globally unique; 566 domain names are more likely to generate unique Message-IDs. 568 3.1.4. Newsgroups 570 The Newsgroups header field specifies the newsgroup(s) to which the 571 article is posted. 573 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 575 newsgroup-list = *WSP newsgroup-name 576 *( [FWS] "," [FWS] newsgroup-name ) *WSP 578 newsgroup-name = component *( "." component ) 580 component = 1*component-char 582 component-char = ALPHA / DIGIT / "+" / "-" / "_" 584 Not all servers support optional FWS in the list of newsgroups. In 585 particular, folding the Newsgroups header field over several lines 586 has been shown to harm propagation significantly. Optional FWS in 587 the SHOULD NOT be generated, but MUST be accepted. 589 A SHOULD NOT consist solely of digits and SHOULD NOT 590 contain uppercase letters. Such s MAY be used only to 591 refer to existing groups that do not conform to this naming scheme, 592 but MUST NOT be used otherwise. 594 NOTE: All-digit s conflict with one widely used storage 595 scheme for articles. Mixed-case groups cause confusion between 596 systems with case-sensitive matching and systems with case- 597 insensitive matching of s. 599 s beginning with underline ("_") are reserved for use by 600 future versions of this standard and SHOULD NOT be generated by user 601 agents (whether in header fields or in newgroup control messages as 602 defined by [I-D.ietf-usefor-usepro]). However, such names MUST be 603 accepted by news servers. 605 s beginning with "+" and "-" are reserved for private use 606 and SHOULD NOT be generated by user agents (whether in header fields 607 or in newgroup control messages [I-D.ietf-usefor-usepro]) without a 608 private prior agreement to do so. However, such names MUST be 609 accepted by news servers. 611 The following s are reserved and MUST NOT be used as 612 the name of a newsgroup: 614 o Groups whose first (or only) is "example" 615 o The group "poster" 617 The following s have been used for specific purposes 618 in various implementations and protocols and therefore MUST NOT be 619 used for the names of normal newsgroups. They MAY be used for their 620 specific purpose or by local agreement. 622 o Groups whose first (or only) component is "to" 624 o Groups whose first (or only) component is "control" 626 o Groups which contain (or consist only of) the component "all" 628 o Groups which contain (or consist only of) the component "ctl" 630 o The group "junk" 632 NOTE: "example.*" is reserved for examples in this and other 633 standards; "poster" has a special meaning in the Followup-To 634 header field; "to.*" is reserved for certain point-to-point 635 communications in conjunction with the "ihave" control message as 636 defined in [I-D.ietf-usefor-usepro]; "control.*" and "junk" have 637 special meanings in some news servers; "all" is used as a wildcard 638 in some implementations; and "ctl" was formerly used to indicate a 639 within the Newsgroups header field. 641 3.1.5. Path 643 The Path header field indicates the route taken by an article since 644 its injection into the Netnews system. Each agent that processes an 645 article is required to prepend at least one to this 646 header field body. This is primarily so that news servers are able 647 to avoid sending articles to sites already known to have them, in 648 particular the site they came from, and additionally to permit 649 tracing the route articles take in moving over the network, and for 650 gathering statistics. 652 path = "Path:" SP *WSP path-list tail-entry *WSP CRLF 654 path-list = *( path-identity [FWS] [path-diagnostic] "!" ) 656 path-diagnostic = diag-match / diag-other / diag-deprecated 658 diag-match = "!" ; another "!" 660 diag-other = "!." diag-keyword [ "." diag-identity ] [FWS] 662 diag-deprecated = "!" IPv4address [FWS] 664 diag-keyword = 1*ALPHA ; see [I-D.ietf-usefor-usepro] 666 diag-identity = path-identity / IPv4address / IPv6address 668 tail-entry = path-nodot 669 ; may be the string "not-for-mail" 671 path-identity = ( 1*( label "." ) toplabel ) / path-nodot 673 path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names 675 label = alphanum [ *( alphanum / "-" ) alphanum ] 677 toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) / 678 ( label *( "-" ) ALPHA [ *( "-" ) label ] ) / 679 ( label 1*( "-" ) label ) 681 alphanum = ALPHA / DIGIT ; compare RFC3696 683 A is a name identifying a site. It takes the form of 684 a domain name having two or more components separated by dots, or a 685 single name with no dots (). 687 Each in the (which does not include the 688 ) indicates, from right to left, the successive agents 689 through which the article has passed. The use of the , 690 which appears as "!!", indicates that the agent to its left verified 691 the identity of the agent to its right before accepting the article 692 (whereas the "!" implies no such claim). 694 NOTE: Historically, the indicated the name of the 695 sender. If not used for this purpose, the string "not-for-mail" 696 is often used instead (since at one time the whole path could be 697 used as a mail address for the sender). 699 NOTE: Although case-insensitive, it is intended that the s should be in uppercase, to distinguish them from the 701 s which are traditionally in lowercase. 703 A is an item inserted into the Path header field 704 for purposes other than to indicate the name of a site. The use of 705 these is described in [I-D.ietf-usefor-usepro]. 707 NOTE: One usage of a is to record an IP address. 708 The fact that es are allowed means that the colon (:) 709 is permitted; note that this may cause interoperability problems 710 at older sites that regard ":" as a and have 711 neighbors whose names have 4 or fewer characters, and where all 712 the characters are valid HEX digits. 714 NOTE: Although es have occasionally been used in the 715 past (usually with a diagnostic intent), their continued use is 716 deprecated (though it is still acceptable in the form of the 717 ). 719 3.1.6. Subject 721 The Subject header field is the same as that specified in Section 722 3.6.5 of [RFC2822] with the added restrictions detailed above in 723 Section 2.2. Further discussion of the content of the Subject header 724 field appears in [I-D.ietf-usefor-usepro] and 725 [I-D.ietf-usefor-useage]. 727 subject = "Subject:" SP unstructured CRLF 729 3.2. Optional Header Fields 731 None of the header fields appearing in this section is required to 732 appear in every article, but some of them may be required in certain 733 types of article. Further discussion of these requirements appears 734 in [I-D.ietf-usefor-usepro] and [I-D.ietf-usefor-useage]. 736 The header fields Comments, Keywords, Reply-To, and Sender are used 737 in Netnews articles in the same circumstances and with the same 738 meanings as those specified in [RFC2822] with the added restrictions 739 detailed above in Section 2.2. Multiple occurrences of the Keywords 740 header field are not permitted. 742 comments = "Comments:" SP unstructured CRLF 744 keywords = "Keywords:" SP phrase *("," phrase) CRLF 746 reply-to = "Reply-To:" SP address-list CRLF 748 sender = "Sender:" SP mailbox CRLF 750 The MIME header fields MIME-Version, Content-Type, Content-Transfer- 751 Encoding, Content-Disposition, and Content-Language are used in 752 Netnews articles in the same circumstances and with the same meanings 753 as those specified in [RFC2045], [RFC2183], and [RFC3282] with the 754 added restrictions detailed above in Section 2.2. 756 All remaining news header fields are described below. 758 3.2.1. Approved 760 The Approved header field indicates the mailing addresses (and 761 possibly the full names) of the persons or entities approving the 762 article for posting. Its principal uses are in moderated articles 763 and in group control messages; see [I-D.ietf-usefor-usepro]. 765 approved = "Approved:" SP mailbox-list CRLF 767 3.2.2. Archive 769 The Archive header field provides an indication of the poster's 770 intent regarding preservation of the article in publicly accessible 771 long-term or permanent storage. 773 archive = "Archive:" SP [CFWS] ("no" / "yes") 774 *( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF 776 archive-param = parameter 778 The presence of an Archive header field in an article with a field 779 body of "no" indicates that the poster does not permit redistribution 780 from publicly accessible long-term or permanent archives. A field 781 body of "yes" indicates that the poster permits such redistribution. 783 No s are currently defined; if present, they can be 784 ignored. Further discussion of the use of the Archive header field 785 appears in [I-D.ietf-usefor-useage]. 787 3.2.3. Control 789 The Control header field marks the article as a control message and 790 specifies the desired actions (additional to the usual ones of 791 storing and/or relaying the article). 793 control = "Control:" SP *WSP control-command *WSP CRLF 795 control-command = verb *( 1*WSP argument ) 797 verb = token 799 argument = 1*( %x21-7E ) 801 The verb indicates what action should be taken, and the argument(s) 802 (if any) supply details. In some cases, the (as defined in 803 [RFC2822]) of the article may also contain details. The legal verbs 804 and respective arguments are discussed in the companion document, 805 [I-D.ietf-usefor-usepro]. 807 An article with a Control header field MUST NOT also have a 808 Supersedes header field. 810 3.2.4. Distribution 812 The Distribution header field specifies geographic or organizational 813 limits on an article's propagation. 815 distribution = "Distribution:" SP dist-list CRLF 817 dist-list = *WSP dist-name 818 *( [FWS] "," [FWS] dist-name ) *WSP 820 dist-name = ALPHA / DIGIT 821 *( ALPHA / DIGIT / "+" / "-" / "_" ) 823 The s "world" and "local" are reserved. "world" indicates 824 unlimited distribution and SHOULD NOT be used explicitly, since it is 825 the default when the Distribution header field is absent entirely. 826 "local" is reserved for indicating distribution only to the local 827 site, as defined by local software configuration. 829 "All" MUST NOT be used as a . s SHOULD contain 830 at least three characters, except when they are two-letter country 831 codes drawn from [ISO3166-1]. s are case-insensitive (i.e. 832 "US", "Us", "uS", and "us" all specify the same distribution). 834 Optional FWS in the SHOULD NOT be generated, but MUST be 835 accepted. 837 3.2.5. Expires 839 The Expires header field specifies a date and time when the poster 840 deems the article to be no longer relevant and could usefully be 841 removed ("expired"). 843 NOTE: This header field is useful when the poster desires an 844 unusually long or an unusually short expiry time. 846 expires = "Expires:" SP date-time CRLF 848 See the remarks under Section 3.1.1 regarding the syntax of 849 and the requirements and recommendations to which it is 850 subject. 852 NOTE: The Expires header field is also sometimes used in Email 853 with a similar meaning; see [RFC2156]. 855 3.2.6. Followup-To 857 The Followup-To header field specifies to which newsgroup(s) the 858 poster has requested that followups are to be posted. The 859 Followup-To header field SHOULD NOT appear in a message, unless its 860 content is different from the content of the Newsgroups header field. 862 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 863 CRLF 865 poster-text = *WSP %d112.111.115.116.101.114 *WSP 866 ; "poster" in lowercase 868 The syntax is the same as that of the Newsgroups (Section 3.1.4) 869 header field, with the exception that the keyword "poster" requests 870 that followups should be emailed directly to the article's poster 871 (using the addresses contained in the Reply-To header field if one 872 exists, otherwise using the addresses contained in the From header 873 field) rather than posted to any newsgroups. Agents MUST generate 874 the keyword "poster" in lowercase, but MAY choose to recognize case- 875 insensitive forms such as "Poster". 877 As in the Newsgroups (Section 3.1.4) header field, optional FWS in 878 the SHOULD NOT be generated, but MUST be accepted. 880 3.2.7. Injection-Date 882 The Injection-Date header field contains the date and time that the 883 article was injected into the network. Its purpose is to enable news 884 servers, when checking for "stale" articles, to use a 885 that was added by a news server at injection time rather than one 886 added by the user agent at message composition time. 888 This header field MUST be inserted whenever an article is injected. 889 However, software that predates this standard does not use this 890 header, and therefore agents MUST accept articles without the 891 Injection-Date header field. 893 injection-date = "Injection-Date:" SP date-time CRLF 895 See the remarks under Section 3.1.1 regarding the syntax of 896 and the requirements and recommendations to which it is 897 subject. 899 NOTE: Since clocks on various agents are not necessarily 900 synchronized, the in this header field might not be a 901 later value than that in the Date header field. Agents MUST NOT 902 alter a pre-existing Date header field when adding an Injection- 903 Date header field. 905 This header field is intended to replace the currently-used but 906 undocumented "NNTP-Posting-Date" header field, whose use is now 907 deprecated. 909 3.2.8. Injection-Info 911 The Injection-Info header field contains information provided by the 912 injecting news server as to how an article entered the Netnews system 913 and to assist in tracing its true origin. It can also specify one or 914 more addresses where complaints concerning the poster of the article 915 may be sent. 917 injection-info = "Injection-Info:" SP [CFWS] path-identity 918 [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF 920 NOTE: The syntax of ([RFC2045] Section 5.1 as amended 921 by [RFC2231]), taken in conjunction with the folding rules of 922 [RFC0822] (sic), effectively allows [CFWS] to occur on either side 923 of the "=" inside a . 925 The following table gives the and the format of the 926 for each defined for use with this header field. 928 At most one occurrence of each such is allowed. 930 format of 931 -------------------- ----------------- 932 "posting-host" a 933 "posting-account" any 934 "logging-data" any 935 "mail-complaints-to" an 937 where 939 host-value = dot-atom-text / IPv4address / IPv6address / 940 (dot-atom-text ":" ( IPv4address / IPv6address )) 942 NOTE: Since any such or also has to be 943 a syntactically correct , it will usually be necessary to 944 encapsulate it as a , for example: 946 posting-host = "posting.example.com:192.0.2.1" 948 Other s SHOULD NOT be used unless defined in extensions to 949 this standard. If non-standards-based s are used, they 950 MUST begin with an "x-". 952 Although comments and folding of white space are permitted throughout 953 the Injection-Info header field, folding SHOULD NOT be used within 954 any . Folding SHOULD only occur before or after the ";" 955 separating s, and comments SHOULD only be used following 956 the last . 958 NOTE: Some of this information has previously been sent in non- 959 standardized header fields such as NNTP-Posting-Host, X-Trace, 960 X-Complaints-To, and others. Once a news server generates an 961 Injection-Info header field, it should have no need to send these 962 non-standard header fields. 964 The "posting-host" specifies the FQDN and/or IP address 965 (IPv4address or IPv6address) of the host from which the news server 966 received the article. 968 NOTE: If the "posting-host" fails to deterministically 969 identify the host (e.g. dynamic IP address allocation), the 970 "posting-account" or the "logging-data" may provide 971 additional information about the true origin of the article. 973 The "posting-account" identifies the source from which 974 that news server received the article, in a notation that can be 975 interpreted by the news server administrator. This notation can 976 include any information the administrator deems pertinent. In order 977 to limit the exposure of personal data, it SHOULD be given in a form 978 that cannot be interpreted by other sites. However, to make it 979 useful for rate limiting and abuse detection, two messages posted 980 from the same source SHOULD have the same value of "posting-account", 981 and two messages from different sources SHOULD have differing values 982 of "posting-account". The exact definition of "source" is left to 983 the discretion of the news server administrator. 985 The "logging-data" contains information (typically a 986 session number or other non-persistent means of identifying a posting 987 account) that will enable the true origin of the article to be 988 determined by reference to logging information kept by the news 989 server. 991 The "mail-complaints-to" specifies one or more mailboxes 992 for sending complaints concerning the behavior of the poster of the 993 article. 995 It is a matter of local policy which of the above s to 996 include. Some pieces of information have privacy implications; this 997 is discussed in [I-D.ietf-usefor-useage]. 999 3.2.9. Organization 1001 The Organization header field is a short phrase identifying the 1002 poster's organization. 1004 organization = "Organization:" SP unstructured CRLF 1006 NOTE: There is no "s" in Organization. 1008 3.2.10. References 1010 The References header field is the same as that specified in Section 1011 3.6.4 of [RFC2822] with the added restrictions detailed above in 1012 Section 2.2 and those listed below: 1014 o The updated construct defined in Section 3.1.3 MUST be 1015 used. 1017 o Message identifiers MUST be separated with CFWS. 1019 o Comments in CFWS between message identifiers can cause 1020 interoperability problems, so comments SHOULD NOT be generated, 1021 but MUST be accepted. 1023 references = "References:" SP [CFWS] msg-id *(CFWS msg-id) 1024 [CFWS] CRLF 1026 3.2.11. Summary 1028 The Summary header field is a short phrase summarizing the article's 1029 content. 1031 summary = "Summary:" SP unstructured CRLF 1033 3.2.12. Supersedes 1035 The Supersedes header field contains a message identifier specifying 1036 an article to be superseded upon the arrival of this one. An article 1037 containing a Supersedes header field is equivalent to a "cancel" 1038 [I-D.ietf-usefor-usepro] control message for the specified article, 1039 followed immediately by the new article without the Supersedes header 1040 field. 1042 supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLF 1044 NOTE: There is no "c" in Supersedes. 1046 NOTE: The Supersedes header field defined here has no connection 1047 with the Supersedes header field that sometimes appears in Email 1048 messages converted from X.400 according to [RFC2156]; in 1049 particular, the syntax here permits only one in contrast 1050 to the multiple s in that Email version. 1052 3.2.13. User-Agent 1054 The User-Agent header field contains information about the user agent 1055 (typically a newsreader) generating the article, for statistical 1056 purposes and tracing of standards violations to specific software 1057 needing correction. It is intended that this header field be 1058 suitable for use in Email. 1060 user-agent = "User-Agent:" SP 1*product [CFWS] CRLF 1062 product = [CFWS] token [ [CFWS] "/" product-version ] 1064 product-version = [CFWS] token 1066 This header field MAY contain multiple tokens identifying 1067 the user agent and any subproducts which form a significant part of 1068 it, listed in order of their significance for identifying the 1069 application. 1071 NOTE: Some of this information has previously been sent in non- 1072 standardized header fields such as X-Newsreader, X-Mailer, 1073 X-Posting-Agent, X-Http-User-Agent, and others. Once a user agent 1074 generates a User-Agent header field, it should have no need to 1075 send these non-standard header fields. 1077 NOTE: [RFC2616] describes a similar facility for the HTTP 1078 protocol. The Netnews article format differs in that "{" and "}" 1079 are allowed in tokens ( and ) and 1080 comments are permitted wherever whitespace is allowed. 1082 3.2.14. Xref 1084 The Xref header field indicates where an article was filed by the 1085 last news server to process it. User agents often use the 1086 information in the Xref header field to avoid multiple processing of 1087 crossposted articles. 1089 xref = "Xref:" SP *WSP server-name 1090 1*( FWS location ) *WSP CRLF 1092 server-name = path-identity 1094 location = newsgroup-name ":" article-locator 1096 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 1097 ; US-ASCII printable characters 1098 ; except '(' and ';' 1100 The is included so that software can determine which 1101 news server generated the header field. The locations specify what 1102 newsgroups the article was filed under (which may differ from those 1103 in the Newsgroups header field) and where it was filed under them. 1104 The exact form of an is implementation-specific. 1106 NOTE: The traditional form of an (as required by 1107 [RFC3977]) is a decimal number, with articles in each newsgroup 1108 numbered consecutively starting from 1. 1110 3.3. Obsolete Header Fields 1112 The header fields Date-Received, Posting-Version, and Relay-Version 1113 defined in [RFC0850], as well as Also-Control, Article-Names, 1114 Article-Updates, and See-Also defined in [Son-of-1036] are declared 1115 obsolete. See the cited specification documents for further 1116 information on their original use. 1118 These header fields MUST NOT be generated and SHOULD be ignored. 1120 3.3.1. Lines 1122 The Lines header field indicates the number of lines in the 1123 (as defined in [RFC2822]) of the article. 1125 lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF 1127 The line count is the number of CRLF separators in the . 1129 Historically, this header field was used by the NNTP [RFC3977] 1130 overview facility, but its use for this purpose is now deprecated. 1131 As a result, this header field is to be regarded as obsolescent, and 1132 it is likely to be removed entirely in a future version of this 1133 standard. All agents SHOULD ignore it and SHOULD NOT generate it. 1135 4. Internationalization Considerations 1137 Internationalization of Netnews article header fields and bodies is 1138 provided using MIME mechanisms discussed in Section 2.3. Note that 1139 the generation of internationalized s for use in 1140 header fields is not addressed in this document. 1142 5. Security Considerations 1144 The Netnews article format specified in this document does not 1145 provide any security services, such as confidentiality, 1146 authentication of sender, or non-repudiation. Instead, such services 1147 need to be layered above, using such protocols as S/MIME [RFC3851] or 1148 PGP/MIME [RFC3156], or below, using secure versions of news transport 1149 protocols. Additionally, several currently non-standardized 1150 protocols such as [PGPVERIFY] may be standardized in the near future. 1152 Message identifiers (Section 3.1.3) in Netnews articles are required 1153 to be unique; articles may be refused (in server-to-server transfer) 1154 if the identifier has already been seen. If a malicious agent can 1155 predict the identifier of an article, it can preempt the article by 1156 posting its own article (possibly to a quite different group) with 1157 the same message identifier, thereby preventing the target article 1158 from propagating. Therefore, agents that generate message 1159 identifiers for Netnews articles SHOULD ensure that they are 1160 unpredictable. 1162 MIME security considerations are discussed in [RFC2046]. Note that 1163 the full range of encodings allowed for parameters in [RFC2046] and 1164 [RFC2231] permits constructs that simple parsers may fail to parse 1165 correctly; examples of hard-to-parse constructs are: 1167 Content-Type: multipart/mixed 1168 (; boundary=foo ; xyz=");bOuNdArY*=''next%20part(") 1170 Content-Type: multipart/digest; 1171 boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzy 1173 Such deficiencies in parsing may be used as part of an attack. 1175 Further security considerations are discussed in 1176 [I-D.ietf-usefor-usepro]. 1178 6. IANA Considerations 1180 IANA is requested to register the following header fields in the 1181 Permanent Message Header Field Repository, in accordance with the 1182 procedures set out in [RFC3864]. 1184 Header field name: Also-Control 1185 Applicable protocol: netnews 1186 Status: obsoleted 1187 Author/change controller: IETF 1188 Specification document(s): [Son-of-1036] (Section 6.15) 1190 Header field name: Approved 1191 Applicable protocol: netnews 1192 Status: standard 1193 Author/change controller: IETF 1194 Specification document(s): This document (Section 3.2.1) 1196 Header field name: Archive 1197 Applicable protocol: netnews 1198 Status: standard 1199 Author/change controller: IETF 1200 Specification document(s): This document (Section 3.2.2) 1202 Header field name: Article-Names 1203 Applicable protocol: netnews 1204 Status: obsoleted 1205 Author/change controller: IETF 1206 Specification document(s): [Son-of-1036] (Section 6.17) 1208 Header field name: Article-Updates 1209 Applicable protocol: netnews 1210 Status: obsoleted 1211 Author/change controller: IETF 1212 Specification document(s): [Son-of-1036] (Section 6.18) 1214 Header field name: Comments 1215 Applicable protocol: netnews 1216 Status: standard 1217 Author/change controller: IETF 1218 Specification document(s): This document (Section 3.2), 1219 [RFC2822] (Section 3.6.5) 1221 Header field name: Control 1222 Applicable protocol: netnews 1223 Status: standard 1224 Author/change controller: IETF 1225 Specification document(s): This document (Section 3.2.3) 1226 Header field name: Date 1227 Applicable protocol: netnews 1228 Status: standard 1229 Author/change controller: IETF 1230 Specification document(s): This document (Section 3.1.1), 1231 [RFC2822] (Section 3.6.1) 1233 Header field name: Date-Received 1234 Applicable protocol: netnews 1235 Status: obsoleted 1236 Author/change controller: IETF 1237 Specification document(s): [RFC0850] (Section 2.2.4) 1239 Header field name: Distribution 1240 Applicable protocol: netnews 1241 Status: standard 1242 Author/change controller: IETF 1243 Specification document(s): This document (Section 3.2.4) 1245 Header field name: Expires 1246 Applicable protocol: netnews 1247 Status: standard 1248 Author/change controller: IETF 1249 Specification document(s): This document (Section 3.2.5) 1251 Header field name: Followup-To 1252 Applicable protocol: netnews 1253 Status: standard 1254 Author/change controller: IETF 1255 Specification document(s): This document (Section 3.2.6) 1257 Header field name: From 1258 Applicable protocol: netnews 1259 Status: standard 1260 Author/change controller: IETF 1261 Specification document(s): This document (Section 3.1.2), 1262 [RFC2822] (Section 3.6.2) 1264 Header field name: Injection-Date 1265 Applicable protocol: netnews 1266 Status: standard 1267 Author/change controller: IETF 1268 Specification document(s): This document (Section 3.2.7) 1270 Header field name: Injection-Info 1271 Applicable protocol: netnews 1272 Status: standard 1273 Author/change controller: IETF 1274 Specification document(s): This document (Section 3.2.8) 1276 Header field name: Keywords 1277 Applicable protocol: netnews 1278 Status: standard 1279 Author/change controller: IETF 1280 Specification document(s): This document (Section 3.2), 1281 [RFC2822] (Section 3.6.5) 1283 Header field name: Lines 1284 Applicable protocol: netnews 1285 Status: deprecated 1286 Author/change controller: IETF 1287 Specification document(s): This document (Section 3.3.1) 1288 Related information: [RFC3977] (Section 8.1) 1290 Header field name: Message-ID 1291 Applicable protocol: netnews 1292 Status: standard 1293 Author/change controller: IETF 1294 Specification document(s): This document (Section 3.1.3) 1295 Related information: [RFC2822] (Section 3.6.4) 1297 Header field name: Newsgroups 1298 Applicable protocol: netnews 1299 Status: standard 1300 Author/change controller: IETF 1301 Specification document(s): This document (Section 3.1.4) 1303 Header field name: NNTP-Posting-Date 1304 Applicable protocol: netnews 1305 Status: obsoleted 1306 Author/change controller: IETF 1307 Specification document(s): none 1309 Header field name: NNTP-Posting-Host 1310 Applicable protocol: netnews 1311 Status: obsoleted 1312 Author/change controller: IETF 1313 Specification document(s): [RFC2980] (Section 3.4.1) 1315 Header field name: Organization 1316 Applicable protocol: netnews 1317 Status: standard 1318 Author/change controller: IETF 1319 Specification document(s): This document (Section 3.2.9) 1320 Header field name: Path 1321 Applicable protocol: netnews 1322 Status: standard 1323 Author/change controller: IETF 1324 Specification document(s): This document (Section 3.1.5) 1326 Header field name: Posting-Version 1327 Applicable protocol: netnews 1328 Status: obsoleted 1329 Author/change controller: IETF 1330 Specification document(s): [RFC0850] (Section 2.1.2) 1332 Header field name: References 1333 Applicable protocol: netnews 1334 Status: standard 1335 Author/change controller: IETF 1336 Specification document(s): This document (Section 3.2.10), 1337 [RFC2822] (Section 3.6.4) 1339 Header field name: Relay-Version 1340 Applicable protocol: netnews 1341 Status: obsoleted 1342 Author/change controller: IETF 1343 Specification document(s): [RFC0850] (Section 2.1.1) 1345 Header field name: Reply-To 1346 Applicable protocol: netnews 1347 Status: standard 1348 Author/change controller: IETF 1349 Specification document(s): This document (Section 3.2), 1350 [RFC2822] (Section 3.6.2) 1352 Header field name: See-Also 1353 Applicable protocol: netnews 1354 Status: obsoleted 1355 Author/change controller: IETF 1356 Specification document(s): [Son-of-1036] (Section 6.16) 1358 Header field name: Sender 1359 Applicable protocol: netnews 1360 Status: standard 1361 Author/change controller: IETF 1362 Specification document(s): This document (Section 3.2), 1363 [RFC2822] (Section 3.6.2) 1365 Header field name: Subject 1366 Applicable protocol: netnews 1367 Status: standard 1368 Author/change controller: IETF 1369 Specification document(s): This document (Section 3.1.6), 1370 [RFC2822] (Section 3.6.5) 1372 Header field name: Summary 1373 Applicable protocol: netnews 1374 Status: standard 1375 Author/change controller: IETF 1376 Specification document(s): This document (Section 3.2.11) 1378 Header field name: Supersedes 1379 Applicable protocol: netnews 1380 Status: standard 1381 Author/change controller: IETF 1382 Specification document(s): This document (Section 3.2.12) 1384 Header field name: User-Agent 1385 Applicable protocol: netnews 1386 Status: standard 1387 Author/change controller: IETF 1388 Specification document(s): This document (Section 3.2.13) 1389 Related information: [RFC2616] (Section 14.43) 1391 Header field name: Xref 1392 Applicable protocol: netnews 1393 Status: standard 1394 Author/change controller: IETF 1395 Specification document(s): This document (Section 3.2.14) 1397 7. References 1399 7.1. Normative References 1401 [I-D.ietf-usefor-usepro] 1402 Allbery, R. and C. Lindsey, "Netnews Architecture and 1403 Protocols", draft-ietf-usefor-usepro-07 (work in 1404 progress), January 2007. 1406 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1407 Extensions (MIME) Part One: Format of Internet Message 1408 Bodies", RFC 2045, November 1996. 1410 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1411 Extensions (MIME) Part Two: Media Types", RFC 2046, 1412 November 1996. 1414 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1415 Part Three: Message Header Extensions for Non-ASCII Text", 1416 RFC 2047, November 1996. 1418 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1419 Extensions (MIME) Part Five: Conformance Criteria and 1420 Examples", RFC 2049, November 1996. 1422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1423 Requirement Levels", BCP 14, RFC 2119, March 1997. 1425 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1426 Presentation Information in Internet Messages: The 1427 Content-Disposition Header Field", RFC 2183, August 1997. 1429 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1430 Word Extensions: Character Sets, Languages, and 1431 Continuations", RFC 2231, November 1997. 1433 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1434 April 2001. 1436 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1437 May 2002. 1439 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1440 Resource Identifier (URI): Generic Syntax", STD 66, 1441 RFC 3986, January 2005. 1443 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1444 Specifications: ABNF", RFC 4234, October 2005. 1446 7.2. Informative References 1448 [Errata] "RFC Editor Errata", 1449 http://www.rfc-editor.org/errata.html. 1451 [I-D.ietf-usefor-useage] 1452 Lindsey, C., "Usenet Best Practice", 1453 draft-ietf-usefor-useage-01 (work in progress), 1454 March 2005. 1456 [ISO3166-1] 1457 International Organization for Standardization, "ISO 3166- 1458 1:1997. Codes for the representation of names of countries 1459 and their subdivisions -- Part 1: Country codes", 1997. 1461 [PGPVERIFY] 1462 Lawrence, D., "PGPverify", 1463 ftp://ftp.isc.org/pub/pgpcontrol/README.html, June 1999. 1465 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1466 text messages", STD 11, RFC 822, August 1982. 1468 [RFC0850] Horton, M., "Standard for interchange of USENET messages", 1469 RFC 850, June 1983. 1471 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1472 USENET messages", RFC 1036, December 1987. 1474 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1475 Mapping between X.400 and RFC 822/MIME", RFC 2156, 1476 January 1998. 1478 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1479 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1480 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1482 [RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980, 1483 October 2000. 1485 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1486 "MIME Security with OpenPGP", RFC 3156, August 2001. 1488 [RFC3696] Klensin, J., "Application Techniques for Checking and 1489 Transformation of Names", RFC 3696, February 2004. 1491 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1492 Extensions (S/MIME) Version 3.1 Message Specification", 1493 RFC 3851, July 2004. 1495 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1496 Procedures for Message Header Fields", BCP 90, RFC 3864, 1497 September 2004. 1499 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 1500 RFC 3977, October 2006. 1502 [Son-of-1036] 1503 Spencer, H., "News Article Format and Transmission", 1504 ftp://ftp.zoo.toronto.edu/pub/news.txt.Z, June 1994. 1506 Appendix A. Acknowledgments 1508 As this document is the result of an eight year effort, the number of 1509 people that have contributed to its content are too numerous to 1510 mention individually. Many thanks go out to all past and present 1511 members of the USEFOR Working Group of the Internet Engineering Task 1512 Force (IETF) and its accompanying mailing list. 1514 Appendix B. Differences from RFC 1036 and its derivatives 1516 This appendix contains a list of changes that have been made in the 1517 Netnews Article Format from earlier standards, specifically 1518 [RFC1036]. 1520 o The [RFC2822] conventions for parenthesis-enclosed s in 1521 header fields are supported in all newly defined header fields and 1522 in header fields inherited from [RFC2822]. They are, however, 1523 still disallowed for performance and/or compatibility reasons in 1524 the Control, Distribution, Followup-To, Lines, Message-ID, 1525 Newsgroups, Path, Supersedes, and Xref header fields. 1527 o Multiple addresses are allowed in the From header field. 1529 o [FWS] is permitted in Newsgroups header fields. 1531 o An enhanced syntax for the Path header field enables the injection 1532 point of, and the route taken by, an article to be determined with 1533 more precision. 1535 o Only one (1) message identifier is allowed in the Supersedes 1536 header field. 1538 o MIME is recognized as an integral part of Netnews. 1540 o There is a new Injection-Date header field to make the rejection 1541 of stale articles more precise and to minimize spurious 1542 rejections. 1544 o There are several new optional header fields defined, notably 1545 Archive, Injection-Info, and User-Agent, leading to increased 1546 functionality. 1548 o Certain header fields, notably Lines, have been deprecated or made 1549 obsolete (Section 3.3). 1551 o The convention to interpret subjects starting with the word "cmsg" 1552 as a control message was removed. 1554 o There are numerous other small changes, clarifications, and 1555 enhancements. 1557 Appendix C. Differences from RFC 2822 1559 This appendix lists the differences between the syntax allowed by the 1560 Netnews Article Format (this document) as compared to the Internet 1561 Message Format, as specified in [RFC2822]. 1563 The Netnews article format is a strict subset of the Internet Message 1564 Format; all Netnews articles conform to the syntax of [RFC2822]. 1566 The following restrictions are important: 1568 o A SP (space) is REQUIRED after the colon (':') following a header 1569 field name. 1571 o A more restricted syntax of (to be used by the 1572 Message-ID, References, and Supersedes header fields) is defined. 1574 o The length of a MUST NOT exceed 250 octets. 1576 o Comments are not allowed in the Message-ID header field. 1578 o The CFWS between s in the References header field is not 1579 optional. 1581 o It is legal for a parser to reject obsolete syntax, except that: 1583 * The construct MUST be accepted. 1585 * The obsolete "GMT" MUST be accepted within a 1586 . 1588 o Every line of a header field body (including the first and any 1589 that are subsequently folded) MUST contain at least one non- 1590 whitespace character. This means that an empty header field body 1591 is illegal. 1593 Authors' Addresses 1595 Kenneth Murchison (editor) 1596 Carnegie Mellon University 1597 5000 Forbes Avenue 1598 Cyert Hall 285 1599 Pittsburgh, PA 15213 1600 U.S.A. 1602 Phone: +1 412 268 2638 1603 Email: murch@andrew.cmu.edu 1605 Charles H. Lindsey 1606 University of Manchester 1607 5 Clerewood Avenue 1608 Heald Green 1609 Cheadle 1610 Cheshire SK8 3JU 1611 U.K. 1613 Phone: +44 161 436 6131 1614 Email: chl@clerew.man.ac.uk 1616 Dan Kohn 1617 FlyDash, Inc. 1618 1741 Sunset Dr. 1619 Pacific Grove, CA 93950 1620 U.S.A. 1622 Phone: +1 415 233 1000 1623 Email: dan@dankohn.com 1625 Full Copyright Statement 1627 Copyright (C) The IETF Trust (2007). 1629 This document is subject to the rights, licenses and restrictions 1630 contained in BCP 78, and except as set forth therein, the authors 1631 retain all their rights. 1633 This document and the information contained herein are provided on an 1634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1636 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1637 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1638 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1641 Intellectual Property 1643 The IETF takes no position regarding the validity or scope of any 1644 Intellectual Property Rights or other rights that might be claimed to 1645 pertain to the implementation or use of the technology described in 1646 this document or the extent to which any license under such rights 1647 might or might not be available; nor does it represent that it has 1648 made any independent effort to identify any such rights. Information 1649 on the procedures with respect to rights in RFC documents can be 1650 found in BCP 78 and BCP 79. 1652 Copies of IPR disclosures made to the IETF Secretariat and any 1653 assurances of licenses to be made available, or the result of an 1654 attempt made to obtain a general license or permission for the use of 1655 such proprietary rights by implementers or users of this 1656 specification can be obtained from the IETF on-line IPR repository at 1657 http://www.ietf.org/ipr. 1659 The IETF invites any interested party to bring to its attention any 1660 copyrights, patents or patent applications, or other proprietary 1661 rights that may cover technology that may be required to implement 1662 this standard. Please address the information to the IETF at 1663 ietf-ipr@ietf.org. 1665 Acknowledgment 1667 Funding for the RFC Editor function is provided by the IETF 1668 Administrative Support Activity (IASA).