idnits 2.17.1 draft-ietf-usefor-usefor-03.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 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1197. ** 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 ([USEPRO], [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 (April 6, 2005) is 6952 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: 'RFC 2373' is mentioned on line 922, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) -- 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 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 2633 (Obsoleted by RFC 3851) -- 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: 8 errors (**), 0 flaws (~~), 4 warnings (==), 15 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 Oceana Matrix Ltd. 4 Obsoletes: 1036 (if approved) C. Lindsey 5 Expires: October 8, 2005 University of Manchester 6 D. Kohn 7 Skymoon Ventures 8 April 6, 2005 10 News Article Format 11 draft-ietf-usefor-usefor-03 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 October 8, 2005. 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 Changes since draft-ietf-usefor-usefor-02 52 o Changed to RFC 3978 boilerplate (xml2rfc v1.29) 54 o Changed "network news" to "Netnews" throughout. 56 o Prohibit NO-WS-CTL in msg-id-core. 58 o Complaints-To header is now an Injection-Info parameter. 60 o Added descriptions of Injection-Info parameters. 62 o Removed "filename" parameter from Archive header. 64 o Added CFWS to User-Agent header. 66 o Miscellaneous editorial changes. 68 Changes since draft-ietf-usefor-usefor-01 70 o Removed half-hearted discussion of internal format and 8-bit clean 71 transport. 73 o Added definitions of "proto-article", "posting agent", "followup", 74 "followup-agent", "user-agent", and "injecting agent". 76 o Removed discussion of message/partial MIME messages. 78 o Noted that the header contents in every line MUST NOT be empty. 80 o Merged MIME sections. 82 o Only allow "UT and "GMT" in Date header; disallow all other . 85 o Used Charles' ABNF for and . 87 o Removed restrictions on length and start character for Newsgroups. 89 o More verbose description of Path header. 91 o Disallowed comments in Control header. 93 o Specified that is a verb optionally followed by 94 whitespace-separated arguments. 96 o Noted that Supersedes header is different from [Son-of-1036]. 98 o More exact ABNF for Archive and Injection-Info parameters. 100 o Discussed meaning of "yes", "no" in Archive header. 102 o Added "Obsolete Headers" section. 104 o Miscellaneous editorial changes 106 Changes since draft-kohn-news-article-03 108 o Document is now a work product of USEFOR 110 o Added new co-authors 112 o Added some definitions from draft-ietf-usefor-article-13 114 o Removed discussion of message/partial MIME messages. 116 o Removed text that belongs in [USEPRO] 118 o Reorganized header sections 120 o Added Archive, User-Agent, Injection-Date, and Injection-Info 121 headers. 123 o Used Charles' ABNF for and . 125 o Removed restrictions on length and start character for Newsgroups. 127 o Added required SP to ABNF of header definitions. 129 o Disallowed comments in Control header. 131 o Xref header allows for non-digit "locations". 133 o Only allow for a single message-id in Supersedes header. 135 o Changes to the References header. 137 o Compatibility changes based on comments from Charles 139 Changes since draft-ietf-usefor-article-13 140 o The Mail-Copies-To, Posted-And-Mailed headers have been moved to 141 other documents. 143 o Dropped MIME parameters, as there is no WG consensus (per Chair). 145 o More exact ABNF for Archive and Injection-Info parameters. 147 o Complaints-To header is now an Injection-Info parameter. 149 Issues to be addressed 151 o Decide which definitions should go in this document and in 152 [USEPRO]. 154 o Do we want to discuss message/partial? 156 o Add appendixes for changes from RFC 1036 and differences from RFC 157 2822. 159 o IANA considerations (the Klyne message header registry is now 160 official as RFC 3864). 162 o Collected Syntax. 164 o Merge more security issues? 166 o Merge acknowledgments? 168 Table of Contents 170 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 171 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 6 172 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 173 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 6 174 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 175 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 176 1.6 Structure of This Document . . . . . . . . . . . . . . . . 8 177 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 178 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 179 2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9 180 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 10 181 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 11 182 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 11 183 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 11 184 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 11 185 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 12 186 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 14 187 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 14 188 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 15 189 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 15 190 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 16 191 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 16 192 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 17 193 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 17 194 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 17 195 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 18 196 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 18 197 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 19 198 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 19 199 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 19 200 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 19 201 3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 20 202 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 20 203 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 21 204 3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 23 205 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 24 206 4. Internationalization Considerations . . . . . . . . . . . . 25 207 5. Security Considerations . . . . . . . . . . . . . . . . . . 26 208 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 209 6.1 Normative References . . . . . . . . . . . . . . . . . . . 27 210 6.2 Informative References . . . . . . . . . . . . . . . . . . 27 211 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 212 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 213 Intellectual Property and Copyright Statements . . . . . . . 31 215 1. Introduction 217 1.1 Basic Concepts 219 "Netnews" is a set of protocols for generating, storing and 220 retrieving news "articles" (which are a subset of Email messages) and 221 for exchanging them amongst a readership which is potentially widely 222 distributed. It is organized around "newsgroups", with the 223 expectation that each reader will be able to see all articles posted 224 to each newsgroup in which he participates. These protocols most 225 commonly use a flooding algorithm which propagates copies throughout 226 a network of participating servers. Typically, only one copy is 227 stored per server, and each server makes it available on demand to 228 readers able to access that server. 230 1.2 Scope 232 This document specifies the syntax of network news (Netnews) articles 233 in the context of the "Internet Message Format" [RFC2822] and 234 "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This 235 document supersedes [RFC1036], updating it to reflect current 236 practice and incorporating changes and clarifications specified in 237 other documents such as [Son-of-1036]. 239 This is the first in a set of documents that obsolete [RFC1036]. 240 This document focuses on the syntax and semantics of Netnews 241 articles. [USEPRO] is also a standards-track document, and describes 242 the protocol issues of Netnews articles, independent of transport 243 protocols such as [NNTP]. An best common practice document, 244 [USEAGE], describes implementation recommendations to improve 245 interoperability and usability. 247 This specification is intended as a definition of what article 248 content format is to be passed between systems. Though some news 249 systems locally store articles in this format (which eliminates the 250 need for translation between formats) and others use formats that 251 differ from the one specified in this standard, local storage is 252 outside of the scope of this standard. 254 1.3 Requirements Notation 256 This document uses terms that appear in capital letters. The key 257 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 258 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 259 are to be interpreted as described in [RFC2119]. 261 1.4 Syntax Notation 263 Headers defined in this specification use the Augmented Backus-Naur 264 Form (ABNF) notation (including the Core Rules) specified in 265 [RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. 266 Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of 267 and respectively. 269 1.5 Definitions 271 An "article" is the unit of news, synonymous with an [RFC2822] 272 "message". A "proto-article" is one that has not yet been injected 273 into the news system. In constrast to an "article", a "proto- 274 article" may lack some mandatory headers. 276 A "message identifier" Section 3.1.3 is a unique identifier for an 277 article, usually supplied by the "posting agent" which posted it or, 278 failing that, by the "injecting agent". It distinguishes the article 279 from every other article ever posted anywhere. Articles with the 280 same message identifier are treated as if they are the same article 281 regardless of any differences in the body or headers. 283 A "newsgroup" is a single news forum, a logical bulletin board, 284 having a name and nominally intended for articles on a specific 285 topic. An article is "posted to" a single newsgroup or several 286 newsgroups. When an article is posted to more than one newsgroup, it 287 is said to be "crossposted"; note that this differs from posting the 288 same text as part of each of several articles, one per newsgroup. 290 A newsgroup may be "moderated", in which case submissions are not 291 posted directly, but mailed to a "moderator" for consideration and 292 possible posting. Moderators are typically human but may be 293 implemented partially or entirely in software. 295 A "poster" is the person or software that composes and submits a 296 possibly compliant article to a "posting agent". The poster is 297 analogous to [RFC2822]'s author. 299 A "posting agent" is the software that assists posters to prepare 300 proto-articles, in compliance with this standard. The proto-article 301 is then passed on to an "injecting agent" for final checking and 302 injection into the news stream. If the article is not compliant, or 303 is rejected by the injecting agent, then the posting agent informs 304 the poster with an explanation of the error. 306 A "reader" is the person or software reading news articles. 308 A "reading agent" is software which presents articles to a reader. 310 A "followup" is an article containing a response to the contents of 311 an earlier article (the followup's "precursor"). 313 A "followup agent" is a combination of reading agent and posting 314 agent that aids in the preparation and posting of a followup. 316 Posting, reading and followup agents (which are usually just 317 different services provided by the same piece of software) are known 318 collectively as "user agents". 320 An "injecting agent" takes the finished article from the posting 321 agent (often via the [NNTP] "post" command) performs some final 322 checks and passes it on to a relaying agent for general distribution. 324 A "control message" is an article which is marked as containing 325 control information; a relaying or serving agent receiving such an 326 article may (subject to the policies observed at that site) take 327 actions beyond just filing and passing on the article. 329 1.6 Structure of This Document 331 This document uses a cite by reference methodology, rather than 332 repeating the contents of other standards, which could otherwise 333 result in subtle differences and interoperability challenges. 334 Although this document is as a result rather short, it requires 335 complete understanding and implementation of the normative references 336 to be compliant. 338 Section 2 defines the format of news articles. Section 3 details the 339 headers necessary to make an article suitable for the netnews 340 environment. 342 2. Format 344 2.1 Base 346 News articles MUST conform to the syntax specified in Section 3 of 347 [RFC2822]. Netnews agents MAY also accept the obsolete syntax 348 specified in Section 4 of [RFC2822], but they MUST NOT generate 349 productions of such syntax. 351 This specification uses the terms "header", "header name", and 352 "header content" which are synonymous with the [RFC2822] terms 353 "header field", "field name", and "field body" respectively. 355 2.2 Headers 357 All headers in a news article are compliant with [RFC2822], however 358 this specification is less permissive in what can be generated and 359 accepted by news agents. The syntax allowed for news articles is a 360 strict subset of the "Internet Message Format", making all messages 361 compliant with this specification inherently compliant with 362 [RFC2822]. Note however that the converse is not guaranteed to be 363 true in all cases. 365 General rules which apply to all headers (even those documented in 366 [RFC2822] and [RFC2045]) are listed below and those that apply to 367 specific headers are described in the relevent sections of this 368 document. 370 o All agents MUST generate headers so that at least one space 371 immediately follows the ':' separating the header name and the 372 header contents (for compatibility with deployed software). News 373 agents MAY accept headers which do not contain the required space. 375 o The header contents of every header line (including the first and 376 any that are subsequently folded) MUST contain at least one non- 377 whitespace character. 379 NOTE: This means that no header content defined by or 380 referenced by this document can be empty. As a result, this 381 document updates the construct from Section 382 3.2.6 of [RFC2822] as follows: 384 unstructured = 1*( [FWS] utext ) [FWS] 386 o Compliant software MUST NOT generate (but MAY accept) headers of 387 more than 998 octets. This is the only limit on the length of a 388 header line prescribed by this standard. However, specific rules 389 to the contrary may apply in particular cases (for example, 390 according to [RFC2047] header lines containing encoded-words are 391 limited to 76 octets). [USEAGE] includes suggested limits for 392 convenience of display by user agents. 394 NOTE: There is NO restriction on the number of lines into which 395 a header may be split, and hence there is NO restriction on the 396 total length of a header (in particular it may, by suitable 397 folding, be made to exceed the 998 octets restriction 398 pertaining to a single header line). 400 o The character set for headers is US-ASCII. Where the use of non- 401 ASCII characters is required, they MUST be encoded using the MIME 402 mechanisms defined in [RFC2047] and [RFC2231]. 404 2.3 MIME Conformance 406 User agents MUST meet the definition of MIME-conformance in [RFC2049] 407 and MUST also support [RFC2231]. This level of MIME Conformance 408 provides support for internationalization and multimedia in message 409 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 410 internationalization of headers ([RFC2047], [RFC2231]). Note that 411 [Errata] currently exist for [RFC2046] and [RFC2231]. 413 For the purposes of Section 5 of [RFC2047], all headers defined in 414 Section 3 of this standard are to be considered as "extension message 415 header fields" (insofar as they are not already considered under the 416 existing Email standards), permitting the use of [RFC2047] encodings 417 within any header, or within any or 418 permittted within any structured header. 420 User agents MAY accept and generate other MIME extension headers, and 421 in particular SHOULD accept Content-Disposition [RFC2183] and 422 Content-Language [RFC3282]. 424 3. News Headers 426 The following news headers extend those defined in section 3.6 of 427 [RFC2822]: 429 fields =/ *( newsgroups / 430 path / 431 injection-date / 432 followup-to / 433 expires / 434 control / 435 supersedes / 436 distribution / 437 summary / 438 approved / 439 organization / 440 xref / 441 archive / 442 user-agent / 443 injection-info ) 445 Each of these headers may occur at most once in a news article. 447 3.1 Mandatory Headers 449 Each news article conformant with this specification MUST have 450 exactly one of each of the following headers: From, Date, Message-ID, 451 Subject, Newsgroups, Path, and Injection-Date. 453 3.1.1 From 455 The From header is the same as that specified in Section 3.6.2 of 456 [RFC2822] with the added restrictions detailed in Section 2.2. 458 from = "From:" SP mailbox-list CRLF 460 3.1.2 Date 462 The Date header is the same as that specified in Sections 3.3 and 463 3.6.1 of [RFC2822] with the added restrictions detailed in 464 Section 2.2. However, the use of "UT" and "GMT" as time zones (part 465 of ), although deprecated, is widespread in news articles 466 today. Therefore, agents MUST accept constructs which 467 include the updated construct below. 469 orig-date = "Date:" SP date-time CRLF 470 zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" 472 Note that agents SHOULD NOT generate constructs which 473 include either "UT" or "GMT" and MUST NOT generate 474 constructs which include any other zone names defined by , 475 some of which have ambiguous interpretations and would have adverse 476 effects on the Netnews protocols. 478 Also note that these requirements apply wherever is used, 479 including Injection-Date and Expires in Section 3.1.7 and 480 Section 3.2.3 respectively. 482 3.1.3 Message-ID 484 The Message-ID header contains a single unique message identifier. 485 This document updates the construct from Section 3.6.4 of 486 [RFC2822] so as to ensure that Internet Message Format Message-IDs 487 are usable in widely deployed news software. The global uniqueness 488 requirement for in [RFC2822] is to be understood as applying 489 across all protocols using such message identifiers, and across both 490 Email and Netnews in particular. A revised syntax for is 491 given below, but the requirements and descriptive text from Section 492 3.6.4 of [RFC2822] still apply. 494 message-id = "Message-ID:" SP msg-id CRLF 496 msg-id = [FWS] msg-id-core [FWS] 498 msg-id-core = "<" id-left "@" id-right ">" 499 ; maximum length is 250 octets 501 id-left = dot-atom-text / no-fold-quote 503 id-right = dot-atom-text / no-fold-literal 505 no-fold-quote = DQUOTE 506 *( mqtext / mquoted-pair ) 507 mqspecial 508 *( mqtext / mquoted-pair ) 509 DQUOTE 511 mqtext = %d33 / ; all of except 512 %d35-61 / ; controls, SP, HTAB, "\", ">" 513 %d63-91 / ; and DQUOTE 514 %d93-126 516 mquoted-pair = "\\" / "\" DQUOTE 518 mqspecial = "(" / ")" / ; same as specials except 519 "<" / ; "\" and DQUOTE quoted 520 "[" / "]" / ; and ">" omitted 521 ":" / ";" / 522 "@" / "," / 523 "." / mquoted-pair 525 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 527 [[Adjacent dots should not be allowed]] 529 mdtext = %d33-61 / ; The rest of the US-ASCII 530 %d63-90 / ; characters not including 531 %d94-126 ; ">", "[", "]", or "\" 533 The msg-id-core MUST NOT be more than 250 octets in length. 535 NOTE: The length restriction ensures that systems which accept 536 message identifiers as a parameter when retrieving an article 537 (e.g. [NNTP]) can rely on a bounded length. 539 Observe that msg-id-core includes the < and >. 541 Observe also that in contrast to the corresponding header in 543 [RFC2822], the syntax does not allow comments within the Message-ID 544 header, it ensures that no string of characters is quoted unless 545 strictly necessary (it must contain at least one mqspecial) and no 546 single character is prefixed by a "\" in the form of a quoted-pair 547 unless strictly necessary, and moreover there is no possibility for 548 ">" or WSP to occur inside a msg-id-core, whether quoted or not. 549 This is to simplify processing by relaying and serving agents and to 550 ensure interoperability with existing implementations. Thus, whereas 551 under [RFC2822] the following s would be considered 552 semantically equivalent, 554 555 <"abcd"@example.com> 556 <"ab\cd"@example.com> 558 only the first of them is syntactically permitted by this standard, 559 and hence a simple comparison of octets will always suffice to 560 determine the identity of two s. 562 Also note that this updated ABNF applies wherever is 563 used, including the References header discussed in Section 3.2.1 and 564 the Supersedes header discussed in Section 3.2.5. 566 3.1.4 Subject 568 The Subject header is the same as that specified in Section 3.6.5 of 569 [RFC2822] with the added restrictions detailed in Section 2.2. 570 Further discussion of the content of the Subject header appears in 571 [USEPRO] and [USEAGE]. 573 subject = "Subject:" SP unstructured CRLF 575 3.1.5 Newsgroups 577 The Newsgroups header specifies the newsgroup(s) to which the article 578 is posted. 580 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 582 newsgroup-list = [FWS] newsgroup-name 583 *( [FWS] "," [FWS] newsgroup-name ) [FWS] 585 newsgroup-name = component *( "." component ) 587 component = 1*component-char 589 component-char = ALPHA / DIGIT / "+" / "-" / "_" 590 NOTE: Observe that the syntax does not allow comments within the 591 Newsgroups header; this is to simplify processing by relaying and 592 serving agents which have a requirement to process this header 593 extremely rapidly. 595 Components beginning with underline ("_") are reserved for use by 596 future versions of this standard and MUST NOT occur in s (whether in Newsgroups headers or in newgroup control messages 598 [USEPRO]). However, such names MUST be accepted. 600 The specific format and lengths of and 601 are discussed in [USEAGE]. 603 3.1.6 Path 605 The Path header indicates the route taken by an article since its 606 injection into the Netnews system. Each agent that processes an 607 article is required to prepend one (or more) identities to this 608 header. This is primarily to enable relaying agents to avoid sending 609 articles to sites already known to have them, in particular the site 610 they came from, and additionally to permit tracing the route articles 611 take in moving over the network, and for gathering Usenet statistics. 613 path = "Path:" SP path-list CRLF 615 path-list = [FWS] 616 *( path-identity [FWS] path-delimiter [FWS] ) 617 tail-entry [FWS] 619 path-identity = ( ALPHA / DIGIT ) 620 *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 622 tail-entry = path-identity 624 path-delimiter = "!" ; possible other delimiters TBD 626 The specific format and use of and are 627 discussed in [USEPRO]. 629 3.1.7 Injection-Date 631 The Injection-Date header contains the date and time that the article 632 was injected into the network. Its purpose is to prevent the 633 reinjection into the news stream of "stale" articles which have 634 already expired by the time they arrive at some relaying or serving 635 agent. 637 injection-date = "Injection-Date:" SP date-time CRLF 638 See the remarks under Section 3.1.2 regarding the syntax of date- 639 time and the requirements and recommendations to which it is subject. 641 NOTE: The date-time in this header would normally be expected to 642 be later than the date-time in the Date header, but differences 643 between the clocks on the various agents and other special 644 circumstances might vitiate that; no provision is made for any 645 such discrepancy to be corrected - better that the injecting agent 646 should just insert the correct time as it sees it. 648 This header is intended to replace the currently-used but 649 undocumented "NNTP-Posting-Date" header, whose use is now deprecated. 651 3.2 Optional Headers 653 None of the headers appearing in this section is required to appear 654 in every article but some of them are required in certain types of 655 article, such as followups. Further discussion of these requirements 656 appears in [USEPRO] and [USEAGE]. 658 The headers Reply-To, Sender, Comments, and Keywords are used in news 659 articles in the same circumstances and with the same meaning as that 660 specified in [RFC2822] with the added restrictions detailed in 661 Section 2.2. Multiple occurances of the Keywords header are not 662 permitted. 664 sender = "Sender:" SP mailbox CRLF 666 reply-to = "Reply-To:" SP address-list CRLF 668 comments = "Comments:" SP unstructured CRLF 670 keywords = "Keywords:" SP phrase *("," phrase) CRLF 672 The MIME headers MIME-Version, Content-Type, Content-Transfer- 673 Encoding, Content-Disposition, and Content-Language are used in news 674 articles in the same circumstances and with the same meanings as 675 those specified in [RFC2045], [RFC2183], and [RFC3282] with the added 676 restrictions detailed in Section 2.2. 678 All remaining news headers are described below. 680 3.2.1 References 682 The References header is the same as that specified in Section 3.6.4 683 of [RFC2822] with the added restrictions detailed in Section 2.2 and 684 those listed below: 686 o The updated construct defined in Section 3.1.3 MUST 687 be used. 689 o Message identifiers MUST be separated with CFWS. 691 o Comments in CFWS between message identifiers can cause 692 interoperability problems, so comments SHOULD NOT be generated, 693 but MUST be accepted. 695 references = "References:" SP 1*( [CFWS] msg-id-core) [CFWS] 696 CRLF 698 3.2.2 Followup-To 700 The Followup-To header specifies to which newsgroup(s) followups 701 should be posted. The Followup-To header SHOULD NOT appear in a 702 message, unless its content is different from the content of the 703 Newsgroups header. 705 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 706 CRLF 708 poster-text = [FWS] %d112.111.115.116.101.114 [FWS] 709 ; "poster" in lower-case 711 The syntax is the same as that of the Newsgroups header 712 (Section 3.1.5, with the exception that the keyword "poster" (which 713 is always lowercase) requests that followups should be mailed to the 714 article's reply address rather than posted. Although the keyword 715 "poster" is case-sensitive, followup agents MAY choose to recognize 716 case-insensitive forms such as "Poster". 718 3.2.3 Expires 720 The Expires header specifies a date and time when the article is 721 deemed to be no longer relevant and could usefully be removed 722 ("expired"). 724 expires = "Expires:" SP date-time CRLF 726 See the remarks under Section 3.1.2 regarding the syntax of date- 727 time and the requirements and recommendations to which it is subject. 729 3.2.4 Control 731 The Control header marks the article as a control message, and 732 specifies the desired actions (additional to the usual ones of 733 storing and/or relaying the article). 735 control = "Control:" SP [FWS] control-message [FWS] CRLF 737 control-message = verb *( [FWS] argument ) 739 verb = token 741 argument = value 743 The verb indicates what action should be taken, and the argument(s) 744 (if any) supply details. In some cases, the body of the article may 745 also contain details. The legal verbs and respective arguments are 746 discussed in the companion document, [USEPRO]. 748 An article with a Control header MUST NOT also have a Supersedes 749 header. 751 3.2.5 Supersedes 753 The Supersedes header contains a message identifier specifying an 754 article to be superseded upon the arrival of this one. An article 755 containing a Supersedes header is equivalent to a "cancel" [USEPRO] 756 control message for the specified article, followed immediately by 757 the new article without the Supersedes header. 759 supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF 761 NOTE: There is no "c" in Supersedes. 763 NOTE: The Supersedes header defined here has no connection with the 764 Supersedes header that sometimes appears in Email messages converted 765 from X.400 according to [RFC2156]; in particular, the syntax here 766 permits only one in contrast to the multiple s in that Email version. 769 3.2.6 Distribution 771 The Distribution header specifies geographic or organizational limits 772 on an article's propagation. 774 distribution = "Distribution:" SP distribution-list CRLF 776 dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS] 778 dist-name = ALPHA / DIGIT 779 *( ALPHA / DIGIT / "+" / "-" / "_" ) 781 The s "world" and "local" are predefined. However, 782 "world" SHOULD NOT be used explicitly, since it is the default when 783 the Distribution header is absent entirely. 785 "All" MUST NOT be used as a . s SHOULD contain 786 at least three characters, except when they are two-letter country 787 names as in [ISO.3166.1988]. s are case-insensitive (i.e. 788 "US", "Us", "uS", and "us" all specify the same distribution). 790 3.2.7 Summary 792 The Summary header is a short phrase summarizing the article's 793 content. 795 summary = "Summary:" SP unstructured CRLF 797 3.2.8 Approved 799 The Approved header indicates the mailing addresses (and possibly the 800 full names) of the persons or entities approving the article for 801 posting. 803 approved = "Approved:" SP mailbox-list CRLF 805 Each mailbox contained in the Approved header MUST be that of one of 806 the person(s) or entity(ies) in question, and one of those mailboxes 807 MUST be that of the actual injector of the article. Note that this 808 standard doesn't provide any means to enforce or verify this 809 requirement, but future extensions or standards may provide such a 810 facility (e.g. digitial signatures). 812 3.2.9 Organization 814 The Organization header is a short phrase identifying the poster's 815 organization. 817 organization = "Organization:" SP unstructured CRLF 819 There is no "s" in Organization. 821 3.2.10 Xref 823 The Xref header indicates where an article was filed by the last 824 serving agent to process it. The article locations are used to keep 825 track of crossposted articles so that reading agents serviced by a 826 particular serving agent can mark such articles as read. 828 xref = "Xref:" SP [CFWS] server-name 829 1*( CFWS location ) [CFWS] CRLF 831 server-name = path-identity 833 location = newsgroup-name ":" article-locator 835 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 836 ; US-ASCII printable characters 837 ; except '(' and ';' 839 The is included so that software can determine which 840 serving agent generated the header. The locations specify what 841 newsgroups the article was filed under (which may differ from those 842 in the Newsgroups header) and where it was filed under them. The 843 exact form of an article-locator is implementation-specific. 845 NOTE: The traditional form of an article-locator (as required by 846 [NNTP]) is a decimal number, with articles in each newsgroup 847 numbered consecutively starting from 1. 849 3.2.11 Archive 851 The Archive header provides an indication of the poster's intent 852 regarding preservation of the article in publicly accessible long- 853 term or permanent storage. 855 archive = "Archive:" SP [CFWS] ("no" / "yes") 856 *( [CFWS] ";" archive-param ) CRLF 858 archive-param = parameter 860 The presence of an "Archive: no" header in an article indicates that 861 the poster does not permit redistribution from publicly accessible 862 long-term or permanent archives. The absence of this header, or an 863 explicit "Archive: yes", indicates that the poster is willing for 864 such redistribution to take place. Further extensions to this 865 standard may provide parameters for administration of the archiving 866 process. 868 3.2.12 User-Agent 870 The User-Agent header contains information about the user agent 871 (typically a newsreader) generating the article, for statistical 872 purposes and tracing of standards violations to specific software 873 needing correction. It is intended that this header be suitable for 874 use in Email. 876 user-agent = "User-Agent:" SP 1*product [CFWS] CRLF 878 product = [CFWS] token [ [CFWS] "/" product-version ] 880 product-version = [CFWS] token 882 This header MAY contain multiple product-tokens identifying the agent 883 and any subproducts which form a significant part of the posting 884 agent, listed in order of their significance for identifying the 885 application. 887 NOTE: This header supersedes the role performed redundantly by 888 experimental headers such as X-Newsreader, X-Mailer, X-Posting- 889 Agent, X-Http-User-Agent, and other headers previously used on 890 Usenet and in Email for this purpose. Use of these experimental 891 headers SHOULD be discontinued in favor of the single, standard 892 User-Agent header. 894 NOTE: [RFC2616] describes a similar facility for the HTTP 895 protocol. This specification differs in that "{" and "}" are 896 allowed in tokens ( and ) and comments 897 are permitted wherever whitespace is allowed. 899 3.2.13 Injection-Info 901 The Injection-Info header provides information as to how an article 902 entered the Netnews system and to assist in tracing its true origin. 903 It can also specify one or more addresses where complaints concerning 904 the poster of the article may be sent. 906 injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] 907 *( ";" inj-info-para ) CRLF 909 inj-info-param = post-host-param / 910 post-account-param / 911 sender-param / 912 logging-param / 913 complainto-param 915 [[Each parameter is allowed only once?]] 917 [[Should also allow for x-attributes?]] 919 post-host-param = "posting-host" "=" host-value 921 host-value = dot-atom / [ dot-atom ":" ] 922 ( IPv4address / IPv6address ) ; see [RFC 2373] 924 post-acct-param = "posting-account" "=" value 926 sender-param = "sender" "=" sender-value 928 sender-value = mailbox / "verified" 930 logging-param = "logging-data" "=" value 932 complainto-param= "complaints-to" "=" address-list 934 Although comments and folding of white space are permitted throughout 935 the Injection-Info header, it is RECOMMENDED that folding is not used 936 within any parameter (but only before or after the ";" separating 937 those parameters), and that comments are only used following the last 938 parameter. 940 This header is intended to replace various currently-used but 941 undocumented headers such as "NNTP-Posting-Host", "X-Trace" and 942 "X-Complaints-To". These headers are thus deprecated. 944 The "posting-host" parameter specifies the FQDN and/or IP address 945 (IPv4address or IPv6address) of the host from which the injecting 946 agent received the article. 948 NOTE: If the "posting-host" parameter identifies a dial-up point- 949 of-presence, the "posting-account" or the "logging-data" parameter 950 may provide additional information about true origin of the 951 article. 953 The "posting-account" parameter identifies the source from which the 954 injecting agent received the article. For security reasons, it 955 SHOULD be in a cryptic notation understandable only by the 956 administrator of the injecting agent. 958 The "sender" parameter identifies the mailbox of the verified sender 959 of the article (alternatively, it uses the token "verified" to 960 indicate that at least any addr-spec in the Sender header of the 961 article, or in the From header if the Sender header is absent, is 962 correct). If an injecting agent can verify sender of an article, it 963 SHOULD use this parameter in favour of the "posting-account" 964 parameter. 966 The "logging-data" parameter contains information (typically a 967 session number or other non-persistent means of identifying a posting 968 account) which will enable the true origin of the article to be 969 determined by reference to logging information kept by the injecting 970 agent. 972 The "complaints-to" parameter specifies mailbox(es) for sending 973 complaints concerning the behaviour of the poster of the article. 975 3.3 Obsolete Headers 977 Early versions of news software following the modern format sometimes 978 generated headers like the following: 980 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP 981 Posting-Version: version B 2.10 2/13/83; site eagle.UUCP 982 Date-Received: Friday, 19-Nov-82 16:59:30 EST 984 Relay-Version contained version information about the relaying agent 985 that last processed the article. Posting-Version contained version 986 information about the posting agent that posted the article. Date- 987 Received contained the date when the last relaying agent to process 988 the article first saw it (in a slightly nonstandard format). 990 In addition, this present standard obsoletes certain headers defined 991 in [Son-of-1036]: 993 Also-Control: cancel <9urrt98y53@site.example> 994 See-Also: 995 Article-Names: comp.foo:charter 996 Article-Updates: 998 Also-Control indicated a control message that was also intended to be 999 filed as a normal article. See-Also listed related articles, but 1000 without the specific relationship with followups that pertains to the 1001 References-header. Article-Names indicated some special significance 1002 of that article in relation to the indicated newsgroup. Article- 1003 Updates indicated that an earlier article was updated, without at the 1004 same time being superseded. 1006 The headers listed above are documented for historical purposes only. 1007 Articles containing these headers MUST NOT be generated. Persons 1008 writing new agents SHOULD ignore any former meanings these headers. 1010 3.3.1 Lines 1012 The Lines header indicates the number of lines in the body of the 1013 article. 1015 lines = "Lines" ":" SP [CFWS] 1*DIGIT [CFWS] CRLF 1017 The line count includes all body lines, including the signature if 1018 any, including empty lines (if any) at the beginning or end of the 1019 body, and including the whole of all MIME message and multipart parts 1020 contained in the body (the single empty separator line between the 1021 headers and the body is not part of the body). The "body" here is 1022 the body as found in the posted article as transmitted by the posting 1023 agent. 1025 Historically, this header was used by the [NNTP] overview extension, 1026 but its use for this purpose is now deprecated. As a result, this 1027 header is to be regarded as obsolete, and it will likely be removed 1028 entirely in a future version of this standard. 1030 4. Internationalization Considerations 1032 Internationalization of news article headers and bodies is provided 1033 using MIME mechanisms discussed in Section 2.3. Note that the 1034 generation of internationalized newsgroup names for use in headers is 1035 not addressed in this document. 1037 5. Security Considerations 1039 The news article format specified in this document does not provide 1040 any security services, such as confidentiality, authentication of 1041 sender, or non-repudiation. Instead, such services need to be 1042 layered above, using such protocols as S/MIME [RFC2633] or PGP/MIME 1043 [RFC3156], or below, using secure versions of news transport 1044 protocols. Additionally, several currently non-standardized 1045 protocols [PGPVERIFY] will hopefully be standardized in the near 1046 future. 1048 Message-IDs (Section 3.1.3) in news are required to be unique; 1049 articles are refused (in server-to-server transfer) if the ID has 1050 already been seen. So if you can predict the ID of a message, you 1051 can preempt it by posting a message (possibly to a quite different 1052 group) with the same ID, stopping your target message from 1053 propagating. Agents that generate message-ids for news articles 1054 SHOULD ensure that they are unpredictable. 1056 6. References 1058 6.1 Normative References 1060 [Errata] "RFC Editor Errata". 1062 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1063 Extensions (MIME) Part One: Format of Internet Message 1064 Bodies", RFC 2045, November 1996. 1066 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1067 Extensions (MIME) Part Two: Media Types", RFC 2046, 1068 November 1996. 1070 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1071 Part Three: Message Header Extensions for Non-ASCII Text", 1072 RFC 2047, November 1996. 1074 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1075 Extensions (MIME) Part Five: Conformance Criteria and 1076 Examples", RFC 2049, November 1996. 1078 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1079 Requirement Levels", BCP 14, RFC 2119, March 1997. 1081 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 1082 Presentation Information in Internet Messages: The 1083 Content-Disposition Header Field", RFC 2183, August 1997. 1085 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1086 Word Extensions: Character Sets, Languages, and 1087 Continuations", RFC 2231, November 1997. 1089 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1090 Specifications: ABNF", RFC 2234, November 1997. 1092 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1093 April 2001. 1095 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 1096 May 2002. 1098 6.2 Informative References 1100 [ISO.3166.1988] 1101 International Organization for Standardization, "Codes for 1102 the representation of names of countries, 3rd edition", 1103 ISO Standard 3166, August 1988. 1105 [NNTP] Feather, C., "Network News Transfer Protocol", 1106 draft-ietf-nntpext-base-*.txt. 1108 [PGPVERIFY] 1109 Lawrence, D., "PGPverify", June 1999. 1111 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1112 USENET messages", RFC 1036, December 1987. 1114 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1115 Mapping between X.400 and RFC 822/MIME", RFC 2156, 1116 January 1998. 1118 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1119 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1120 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1122 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1123 RFC 2633, June 1999. 1125 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 1126 "MIME Security with OpenPGP", RFC 3156, August 2001. 1128 [Son-of-1036] 1129 Spencer, H., "News Article Format and Transmission", 1130 June 1994. 1132 [USEAGE] Lindsey, C., "Usenet Best Practice", 1133 draft-ietf-usefor-useage-*.txt. 1135 [USEPRO] Lindsey, C., "News Article Architecture and Protocols", 1136 draft-ietf-usefor-usepro-*.txt. 1138 Authors' Addresses 1140 Kenneth Murchison (editor) 1141 Oceana Matrix Ltd. 1142 21 Princeton Place 1143 Orchard Park, NY 14127 1144 US 1146 Phone: +1 716 662 8973 1147 Email: ken@oceana.com 1148 Charles H. Lindsey 1149 University of Manchester 1150 5 Clerewood Avenue 1151 Heald Green 1152 Cheadle 1153 Chesire SK8 3JU 1154 GB 1156 Phone: +44 161 436 6131 1157 Email: chl@clw.cs.man.ac.uk 1159 Dan Kohn 1160 Skymoon Ventures 1161 3045 Park Boulevard 1162 Palo Alto, CA 94306 1163 US 1165 Phone: +1 650 327 2600 1166 Email: dan@dankohn.com 1168 Appendix A. Acknowledgements 1170 Comments and/or text were provided by Mark Crispin, Claus Faerber, 1171 Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, 1172 Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey 1173 Melnikov. 1175 Intellectual Property Statement 1177 The IETF takes no position regarding the validity or scope of any 1178 Intellectual Property Rights or other rights that might be claimed to 1179 pertain to the implementation or use of the technology described in 1180 this document or the extent to which any license under such rights 1181 might or might not be available; nor does it represent that it has 1182 made any independent effort to identify any such rights. Information 1183 on the procedures with respect to rights in RFC documents can be 1184 found in BCP 78 and BCP 79. 1186 Copies of IPR disclosures made to the IETF Secretariat and any 1187 assurances of licenses to be made available, or the result of an 1188 attempt made to obtain a general license or permission for the use of 1189 such proprietary rights by implementers or users of this 1190 specification can be obtained from the IETF on-line IPR repository at 1191 http://www.ietf.org/ipr. 1193 The IETF invites any interested party to bring to its attention any 1194 copyrights, patents or patent applications, or other proprietary 1195 rights that may cover technology that may be required to implement 1196 this standard. Please address the information to the IETF at 1197 ietf-ipr@ietf.org. 1199 Disclaimer of Validity 1201 This document and the information contained herein are provided on an 1202 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1203 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1204 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1205 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1206 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1207 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1209 Copyright Statement 1211 Copyright (C) The Internet Society (2005). This document is subject 1212 to the rights, licenses and restrictions contained in BCP 78, and 1213 except as set forth therein, the authors retain all their rights. 1215 Acknowledgment 1217 Funding for the RFC Editor function is currently provided by the 1218 Internet Society.