idnits 2.17.1 draft-ietf-usefor-usefor-02.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1113. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1103. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (November 23, 2004) is 7088 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 854, 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: 10 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Usenet Format Working Group K. Murchison, Ed. 2 Internet-Draft Oceana Matrix Ltd. 3 Obsoletes: 1036 (if approved) C. Lindsey 4 Expires: May 24, 2005 University of Manchester 5 D. Kohn 6 Skymoon Ventures 7 November 23, 2004 9 News Article Format 10 draft-ietf-usefor-usefor-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document specifies the syntax of network news (Netnews) articles 46 in the context of the "Internet Message Format" (RFC 2822) and 47 "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This 48 document supersedes RFC 1036, updating it to reflect current practice 49 and incorporating incremental changes specified in other documents. 51 Changes since draft-ietf-usefor-usefor-01 53 o Removed half-hearted discussion of internal format and 8-bit clean 54 transport. 55 o Added definitions of "proto-article", "posting agent", "followup", 56 "followup-agent", "user-agent", and "injecting agent". 57 o Removed discussion of message/partial MIME messages. 58 o Noted that the header contents in every line MUST NOT be empty. 59 o Merged MIME sections. 60 o Only allow "UT and "GMT" in Date header; disallow all other 61 . 62 o Used Charles' ABNF for and . 63 o Removed restrictions on length and start character for Newsgroups. 64 o More verbose description of Path header. 65 o Disallowed comments in Control header. 66 o Specified that is a verb optionally followed by 67 whitespace-separated arguments. 68 o Noted that Supersedes header is different from [Son-of-1036]. 69 o More exact ABNF for Archive and Injection-Info parameters. 70 o Discussed meaning of "yes", "no", and "filename" in Archive 71 header. 72 o Added "Obsolete Headers" section. 73 o Miscellaneous editorial changes 75 Changes since draft-kohn-news-article-03 77 o Document is now a work product of USEFOR 78 o Added new co-authors 79 o Added some definitions from draft-ietf-usefor-article-13 80 o Removed discussion of message/partial MIME messages. 81 o Removed text that belongs in [USEPRO] 82 o Reorganized header sections 83 o Added Archive, User-Agent, Injection-Date, and Injection-Info 84 headers. 85 o Used Charles' ABNF for and . 86 o Removed restrictions on length and start character for Newsgroups. 87 o Added required SP to ABNF of header definitions. 88 o Disallowed comments in Control header. 89 o Xref header allows for non-digit "locations". 90 o Only allow for a single message-id in Supersedes header. 91 o Changes to the References header. 92 o Compatibility changes based on comments from Charles 94 Changes since draft-ietf-usefor-article-13 95 o The Mail-Copies-To, Posted-And-Mailed and Complaints-To headers 96 have been moved to other documents. 97 o Dropped MIME parameters, as there is no WG consensus (per Chair). 98 o More exact ABNF for Archive and Injection-Info parameters. 100 Issues to be addressed 102 o Decide which definitions should go in this document and in 103 [USEPRO]. 104 o Decide how much (if any) discussion of Injection-Info content 105 belongs in this document vs. [USEPRO]. 106 o Do we want to discuss message/partial? 107 o Add appendixes for changes from RFC 1036 and differences from RFC 108 2822. 109 o IANA considerations (the Klyne message header registry is now 110 official as RFC 3864). 111 o Collected Syntax. 112 o Merge more security issues? 113 o Merge acknowledgments? 115 Table of Contents 117 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 118 1.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 5 119 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 120 1.3 Requirements Notation . . . . . . . . . . . . . . . . . . 5 121 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 122 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 123 1.6 Structure of This Document . . . . . . . . . . . . . . . . 7 124 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 125 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 126 2.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 8 127 2.3 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 9 128 3. News Headers . . . . . . . . . . . . . . . . . . . . . . . . 10 129 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 10 130 3.1.1 From . . . . . . . . . . . . . . . . . . . . . . . . . 10 131 3.1.2 Date . . . . . . . . . . . . . . . . . . . . . . . . . 10 132 3.1.3 Message-ID . . . . . . . . . . . . . . . . . . . . . . 11 133 3.1.4 Subject . . . . . . . . . . . . . . . . . . . . . . . 13 134 3.1.5 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 13 135 3.1.6 Path . . . . . . . . . . . . . . . . . . . . . . . . . 14 136 3.1.7 Injection-Date . . . . . . . . . . . . . . . . . . . . 14 137 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 15 138 3.2.1 References . . . . . . . . . . . . . . . . . . . . . . 15 139 3.2.2 Followup-To . . . . . . . . . . . . . . . . . . . . . 16 140 3.2.3 Expires . . . . . . . . . . . . . . . . . . . . . . . 16 141 3.2.4 Control . . . . . . . . . . . . . . . . . . . . . . . 16 142 3.2.5 Supersedes . . . . . . . . . . . . . . . . . . . . . . 17 143 3.2.6 Distribution . . . . . . . . . . . . . . . . . . . . . 17 144 3.2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 18 145 3.2.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 18 146 3.2.9 Organization . . . . . . . . . . . . . . . . . . . . . 18 147 3.2.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 18 148 3.2.11 Archive . . . . . . . . . . . . . . . . . . . . . . 19 149 3.2.12 User-Agent . . . . . . . . . . . . . . . . . . . . . 19 150 3.2.13 Injection-Info . . . . . . . . . . . . . . . . . . . 20 151 3.3 Obsolete Headers . . . . . . . . . . . . . . . . . . . . . 21 152 3.3.1 Lines . . . . . . . . . . . . . . . . . . . . . . . . 22 153 4. Internationalization Considerations . . . . . . . . . . . . 23 154 5. Security Considerations . . . . . . . . . . . . . . . . . . 24 155 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 156 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 157 6.2 Informative References . . . . . . . . . . . . . . . . . . . 25 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 159 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 160 Intellectual Property and Copyright Statements . . . . . . . 29 162 1. Introduction 164 1.1 Basic Concepts 166 "Netnews" is a set of protocols for generating, storing and 167 retrieving news "articles" (which are a subset of Email messages) and 168 for exchanging them amongst a readership which is potentially widely 169 distributed. It is organized around "newsgroups", with the 170 expectation that each reader will be able to see all articles posted 171 to each newsgroup in which he participates. These protocols most 172 commonly use a flooding algorithm which propagates copies throughout 173 a network of participating servers. Typically, only one copy is 174 stored per server, and each server makes it available on demand to 175 readers able to access that server. 177 1.2 Scope 179 This document specifies the syntax of network news (Netnews) articles 180 in the context of the "Internet Message Format" [RFC2822] and 181 "Multipurpose Internet Mail Extensions (MIME)" [RFC2045]. This 182 document supersedes [RFC1036], updating it to reflect current 183 practice and incorporating changes and clarifications specified in 184 other documents such as [Son-of-1036]. 186 This is the first in a set of documents that obsolete [RFC1036]. 187 This document focuses on the syntax and semantics of Netnews 188 articles. [USEPRO] is also a standards-track document, and describes 189 the protocol issues of network news articles, independent of 190 transport protocols such as [NNTP]. An best common practice 191 document, [USEAGE], describes implementation recommendations to 192 improve interoperability and usability. 194 This specification is intended as a definition of what article 195 content format is to be passed between systems. Though some news 196 systems locally store articles in this format (which eliminates the 197 need for translation between formats) and others use formats that 198 differ from the one specified in this standard, local storage is 199 outside of the scope of this standard. 201 1.3 Requirements Notation 203 This document uses terms that appear in capital letters. The key 204 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 205 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 206 are to be interpreted as described in [RFC2119]. 208 1.4 Syntax Notation 210 Headers defined in this specification use the Augmented Backus-Naur 211 Form (ABNF) notation (including the Core Rules) specified in 212 [RFC2234] and many constructs defined in [RFC2822] and [RFC2045]. 213 Section 3.1.2 and Section 3.1.3 update the [RFC2822] definitions of 214 and respectively. 216 1.5 Definitions 218 An "article" is the unit of news, synonymous with an [RFC2822] 219 "message". A "proto-article" is one that has not yet been injected 220 into the news system. 222 A "message identifier" Section 3.1.3 is a unique identifier for an 223 article, usually supplied by the "posting agent" which posted it or, 224 failing that, by the "injecting agent". It distinguishes the article 225 from every other article ever posted anywhere. Articles with the 226 same message identifier are treated as if they are the same article 227 regardless of any differences in the body or headers. 229 A "newsgroup" is a single news forum, a logical bulletin board, 230 having a name and nominally intended for articles on a specific 231 topic. An article is "posted to" a single newsgroup or several 232 newsgroups. When an article is posted to more than one newsgroup, it 233 is said to be "crossposted"; note that this differs from posting the 234 same text as part of each of several articles, one per newsgroup. 236 A newsgroup may be "moderated", in which case submissions are not 237 posted directly, but mailed to a "moderator" for consideration and 238 possible posting. Moderators are typically human but may be 239 implemented partially or entirely in software. 241 A "poster" is the person or software that composes and submits a 242 possibly compliant article to a "posting agent". The poster is 243 analogous to [RFC2822]'s author. 245 A "posting agent" is the software that assists posters to prepare 246 proto-articles, in compliance with this standard. The proto-article 247 is then passed on to an "injecting agent" for final checking and 248 injection into the news stream. If the article is not compliant, or 249 is rejected by the injecting agent, then the posting agent informs 250 the poster with an explanation of the error. 252 A "reader" is the person or software reading news articles. 254 A "reading agent" is software which presents articles to a reader. 256 A "followup" is an article containing a response to the contents of 257 an earlier article (the followup's "precursor"). 259 A "followup agent" is a combination of reading agent and posting 260 agent that aids in the preparation and posting of a followup. 262 Posting, reading and followup agents (which are usually just 263 different services provided by the same piece of software) are known 264 collectively as "user agents". 266 An "injecting agent" takes the finished article from the posting 267 agent (often via the [NNTP] "post" command) performs some final 268 checks and passes it on to a relaying agent for general distribution. 270 A "control message" is an article which is marked as containing 271 control information; a relaying or serving agent receiving such an 272 article may (subject to the policies observed at that site) take 273 actions beyond just filing and passing on the article. 275 1.6 Structure of This Document 277 This document uses a cite by reference methodology, rather than 278 repeating the contents of other standards, which could otherwise 279 result in subtle differences and interoperability challenges. 280 Although this document is as a result rather short, it requires 281 complete understanding and implementation of the normative references 282 to be compliant. 284 Section 2 defines the format of news articles. Section 3 details the 285 headers necessary to make an article suitable for the netnews 286 environment. 288 2. Format 290 2.1 Base 292 News articles MUST conform to the syntax specified in Section 3 of 293 [RFC2822]. Netnews agents MAY also accept the obsolete syntax 294 specified in Section 4 of [RFC2822], but they MUST NOT generate such 295 syntax. 297 This specification uses the terms "header", "header name", and 298 "header content" which are synonymous with the [RFC2822] terms 299 "header field", "field name", and "field body" respectively. 301 2.2 Headers 303 All headers in a news article are compliant with [RFC2822], however 304 this specification is less permissive in what can be generated and 305 accepted by news agents. The syntax allowed for news articles is a 306 strict subset of the "Internet Message Format", making all messages 307 compliant with this specification inherently compliant with 308 [RFC2822]. Note however that the converse is not guaranteed to be 309 true in all cases. 311 General rules which apply to all headers (even those documented in 312 [RFC2822] and [RFC2045]) are listed below and those that apply to 313 specific headers are described in the relevent sections of this 314 document. 316 o All agents MUST generate headers so that at least one space 317 immediately follows the ':' separating the header name and the 318 header contents (for compatibility with deployed software). News 319 agents MAY accept headers which do not contain the required space. 320 o The header contents of every header line (including the first and 321 any that are subsequently folded) MUST contain at least one 322 non-whitespace character. 323 NOTE: This means that no header content defined by or 324 referenced by this document can be empty. As a result, this 325 document updates the construct from Section 326 3.2.6 of [RFC2822] as follows: 328 unstructured = 1*( [FWS] utext ) [FWS] 330 o Compliant software MUST NOT generate (but MAY accept) headers of 331 more than 998 octets. This is the only limit on the length of a 332 header line prescribed by this standard. However, specific rules 333 to the contrary may apply in particular cases (for example, 334 according to [RFC2047] header lines containing encoded-words are 335 limited to 76 octets). [USEAGE] includes suggested limits for 336 convenience of display by user agents. 337 NOTE: There is NO restriction on the number of lines into which 338 a header may be split, and hence there is NO restriction on the 339 total length of a header (in particular it may, by suitable 340 folding, be made to exceed the 998 octets restriction 341 pertaining to a single header line). 342 o The character set for headers is US-ASCII. Where the use of 343 non-ASCII characters is required, they MUST be encoded using the 344 MIME mechanisms defined in [RFC2045] and [RFC2231]. 346 2.3 MIME Conformance 348 User agents MUST meet the definition of MIME-conformance in [RFC2049] 349 and MUST also support [RFC2231]. This level of MIME Conformance 350 provides support for internationalization and multimedia in message 351 bodies ([RFC2045], [RFC2046], [RFC2231]), and support for 352 internationalization of headers ([RFC2047], [RFC2231]). Note that 353 [Errata] currently exist for [RFC2046] and [RFC2231]. 355 For the purposes of Section 5 of [RFC2047], all headers defined in 356 Section 3 of this standard are to be considered as "extension message 357 header fields" (insofar as they are not already considered under the 358 existing Email standards), permitting the use of [RFC2047] encodings 359 within any header, or within any or 360 permittted within any structured header. 362 User agents MAY accept and generate other MIME extension headers, and 363 in particular SHOULD accept Content-Disposition [RFC2183] and 364 Content-Language [RFC3282]. 366 3. News Headers 368 The following news headers extend those defined in section 3.6 of 369 [RFC2822]: 371 fields =/ *( newsgroups / 372 path / 373 injection-date / 374 followup-to / 375 expires / 376 control / 377 supersedes / 378 distribution / 379 summary / 380 approved / 381 organization / 382 xref / 383 archive / 384 user-agent / 385 injection-info ) 387 Each of these headers may occur at most once in a news article. 389 3.1 Mandatory Headers 391 Each news article conformant with this specification MUST have 392 exactly one of each of the following headers: From, Date, Message-ID, 393 Subject, Newsgroups, Path, and Injection-Date. 395 3.1.1 From 397 The From header is the same as that specified in Section 3.6.2 of 398 [RFC2822] with the added restrictions detailed in Section 2.2. 400 from = "From:" SP mailbox-list CRLF 402 3.1.2 Date 404 The Date header is the same as that specified in Sections 3.3 and 405 3.6.1 of [RFC2822] with the added restrictions detailed in Section 406 2.2. However, the use of "UT" and "GMT" as time zones (part of 407 ), although deprecated, is widespread in news articles 408 today. Therefore, agents MUST accept constructs which 409 include the updated construct below. 411 orig-date = "Date:" SP date-time CRLF 412 zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT" 414 Note that agents SHOULD NOT generate constructs which 415 include either "UT" or "GMT" and MUST NOT generate 416 constructs which include any other zone names defined by , 417 some of which have ambiguous interpretations and would have adverse 418 effects on Netnews protocols. 420 Also note that these requirements apply wherever is used, 421 including Injection-Date and Expires in Section 3.1.7 and Section 422 3.2.3 respectively. 424 3.1.3 Message-ID 426 The Message-ID header contains a single unique message identifier. 427 This document updates the construct from Section 3.6.4 of 428 [RFC2822] so as to ensure that Internet Message Format Message-IDs 429 are usable in widely deployed news software. The global uniqueness 430 requirement for in [RFC2822] is to be understood as applying 431 across all protocols using such message identifiers, and across both 432 Email and Netnews in particular. The ABNF should be used as below, 433 but the requirements and descriptive text from Section 3.6.4 of 434 [RFC2822] still apply. 436 message-id = "Message-ID:" SP msg-id CRLF 438 msg-id = [FWS] msg-id-core [FWS] 440 msg-id-core = "<" id-left "@" id-right ">" 441 ; maximum length is 250 octets 443 id-left = dot-atom-text / no-fold-quote 445 id-right = dot-atom-text / no-fold-literal 447 no-fold-quote = DQUOTE 448 *( mqtext / "\\" / "\" DQUOTE ) 449 mqspecial 450 *( mqtext / "\\" / "\" DQUOTE ) 451 DQUOTE 453 mqtext = NO-WS-CTL / ; all of except 454 %d33 / ; SP, HTAB, "\", ">" 455 %d35-61 / ; and DQUOTE 456 %d63-91 / 457 %d93-126 459 mqspecial = "(" / ")" / ; same as specials except 460 "<" / ; "\" and DQUOTE quoted 461 "[" / "]" / ; and ">" omitted 462 ":" / ";" / 463 "@" / "\\" / 464 "," / "." / 465 "\" DQUOTE 467 no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]" 469 mdtext = NO-WS-CTL / ; Non white space controls 470 %d33-61 / ; The rest of the US-ASCII 471 %d63-90 / ; characters not including 472 %d94-126 ; ">", "[", "]", or "\" 474 The msg-id-core MUST NOT be more than 250 octets in length. 476 NOTE: The length restriction ensures that systems which accept 477 message identifiers as a parameter when retrieving an article 478 (e.g. [NNTP]) can rely on a bounded length. 480 Observe that msg-id-core includes the < and >. 482 Observe also that in contrast to the corresponding header in 483 [RFC2822], the syntax does not allow comments within the Message-ID 484 header, it ensures that no string of characters is quoted unless 485 strictly necessary (it must contain at least one mqspecial) and no 486 single character is prefixed by a "\" in the form of a quoted-pair 487 unless strictly necessary, and moreover there is no possibility for 488 ">" or WSP to occur inside a msg-id-core, whether quoted or not. 489 This is to simplify processing by relaying and serving agents and to 490 ensure interoperability with existing implementations. Thus, whereas 491 under [RFC2822] the following would be considered 492 semantically equivalent, 494 495 <"abcd"@example.com> 496 <"ab\cd"@example.com> 498 only the first of them is syntactically permitted by this standard, 499 and hence a simple comparison of octets will always suffice to 500 determine the identity of two . 502 Also note that this updated ABNF applies wherever are 503 used, including the References header discussed in Section 3.2.1 and 504 the Supersedes header discussed in Section 3.2.5. 506 3.1.4 Subject 508 The Subject header is the same as that specified in Section 3.6.5 of 509 [RFC2822] with the added restrictions detailed in Section 2.2. 510 Further discussion of the content of the Subject header appears in 511 [USEPRO] and [USEAGE]. 513 subject = "Subject:" SP unstructured CRLF 515 3.1.5 Newsgroups 517 The Newsgroups header specifies the newsgroup(s) to which the article 518 is posted. 520 newsgroups = "Newsgroups:" SP newsgroup-list CRLF 522 newsgroup-list = [FWS] newsgroup-name 523 *( [FWS] "," [FWS] newsgroup-name ) [FWS] 525 newsgroup-name = component *( "." component ) 527 component = 1*component-char 529 component-char = ALPHA / DIGIT / "+" / "-" / "_" 530 NOTE: Observe that the syntax does not allow comments within the 531 Newsgroups header; this is to simplify processing by relaying and 532 serving agents which have a requirement to process this header 533 extremely rapidly. 535 Components beginning with underline ("_") are reserved for use by 536 future versions of this standard and MUST NOT occur in 537 s (whether in Newsgroups headers or in newgroup 538 control messages [USEPRO]). However, such names MUST be accepted. 540 The specific format and lengths of and 541 are discussed in [USEAGE]. 543 3.1.6 Path 545 The Path header indicates the route taken by an article since its 546 injection into the Netnews system. Each agent that processes an 547 article is required to prepend one (or more) identities to this 548 header. This is primarily to enable relaying agents to avoid sending 549 articles to sites already known to have them, in particular the site 550 they came from, and additionally to permit tracing the route articles 551 take in moving over the network, and for gathering Usenet statistics. 553 path = "Path:" SP path-list CRLF 555 path-list = [FWS] 556 *( path-identity [FWS] path-delimiter [FWS] ) 557 tail-entry [FWS] 559 path-identity = ( ALPHA / DIGIT ) 560 *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 562 tail-entry = path-identity 564 path-delimiter = "!" ; possible other delimiters TBD 566 The specific format and use of and are 567 discussed in [USEPRO]. 569 3.1.7 Injection-Date 571 The Injection-Date header contains the date and time that the article 572 was injected into the network. Its purpose is to prevent the 573 reinjection into the news stream of "stale" articles which have 574 already expired by the time they arrive at some relaying or serving 575 agent. 577 injection-date = "Injection-Date:" SP date-time CRLF 578 See the remarks under Section 3.1.2 regarding the syntax of 579 date-time and the requirements and recommendations to which it is 580 subject. 582 NOTE: The date-time in this header would normally be expected to 583 be later than the date-time in the Date header, but differences 584 between the clocks on the various agents and other special 585 circumstances might vitiate that; no provision is made for any 586 such discrepancy to be corrected - better that the injecting agent 587 should just insert the correct time as it sees it. 589 This header is intended to replace the currently-used but 590 undocumented "NNTP-Posting-Date" header, whose use is now deprecated. 592 3.2 Optional Headers 594 None of the headers appearing in this section is required to appear 595 in every article but some of them are required in certain types of 596 article, such as followups. Further discussion of these requirements 597 appears in [USEPRO] and [USEAGE]. 599 The headers Reply-To, Sender, Comments, and Keywords are used in news 600 articles in the same circumstances and with the same meaning as that 601 specified in [RFC2822] with the added restrictions detailed in 602 Section 2.2. Multiple occurances of the Keywords header are not 603 permitted. 605 sender = "Sender:" SP mailbox CRLF 607 reply-to = "Reply-To:" SP address-list CRLF 609 comments = "Comments:" SP unstructured CRLF 611 keywords = "Keywords:" SP phrase *("," phrase) CRLF 613 The MIME headers MIME-Version, Content-Type, 614 Content-Transfer-Encoding, Content-Disposition, and Content-Language 615 are used in news articles in the same circumstances and with the same 616 meanings as those specified in [RFC2045], [RFC2183], and [RFC3282] 617 with the added restrictions detailed in Section 2.2. 619 All remaining news headers are described below. 621 3.2.1 References 623 The References header is the same as that specified in Section 3.6.4 624 of [RFC2822] with the added restrictions detailed in Section 2.2 and 625 those listed below: 627 o The updated construct defined in Section 3.1.3 MUST 628 be used. 629 o Message identifiers MUST be separated with CFWS. 630 o Comments in CFWS between message identifiers can cause 631 interoperability problems, so comments SHOULD NOT be generated, 632 but MUST be accepted. 634 references = "References:" SP 1*( [CFWS] msg-id-core) [CFWS] 635 CRLF 637 3.2.2 Followup-To 639 The Followup-To header specifies to which newsgroup(s) followups 640 should be posted. The Followup-To header SHOULD NOT appear in a 641 message, unless its content is different from the content of the 642 Newsgroups header. 644 followup-to = "Followup-To:" SP ( newsgroup-list / poster-text ) 645 CRLF 647 poster-text = [FWS] %d112.111.115.116.101.114 [FWS] 648 ; "poster" in lower-case 650 The syntax is the same as that of the Newsgroups header (Section 651 3.1.5, with the exception that the keyword "poster" (which is always 652 lowercase) requests that followups should be mailed to the article's 653 reply address rather than posted. Although the keyword "poster" is 654 case-sensitive, followup agents MAY choose to recognize 655 case-insensitive forms such as "Poster". 657 3.2.3 Expires 659 The Expires header specifies a date and time when the article is 660 deemed to be no longer relevant and could usefully be removed 661 ("expired"). 663 expires = "Expires:" SP date-time CRLF 665 See the remarks under Section 3.1.2 regarding the syntax of 666 date-time and the requirements and recommendations to which it is 667 subject. 669 3.2.4 Control 671 The Control header marks the article as a control message, and 672 specifies the desired actions (additional to the usual ones of 673 storing and/or relaying the article). 675 control = "Control:" SP [FWS] control-message [FWS] CRLF 677 control-message = verb *( [FWS] argument ) 679 verb = token 681 argument = value 683 The verb indicates what action should be taken, and the argument(s) 684 (if any) supply details. In some cases, the body of the article may 685 also contain details. The legal verbs and respective arguments are 686 discussed in the companion document, [USEPRO]. 688 An article with a Control header MUST NOT also have a Supersedes 689 header. 691 3.2.5 Supersedes 693 The Supersedes header contains a message identifier specifying an 694 article to be superseded upon the arrival of this one. An article 695 containing a Supersedes header is equivalent to a "cancel" [USEPRO] 696 control message for the specified article, followed immediately by 697 the new article without the Supersedes header. 699 supersedes = "Supersedes:" SP [CFWS] msg-id-core [CFWS] CRLF 701 NOTE: There is no "c" in Supersedes. 703 NOTE: The Supersedes header defined here has no connection with the 704 Supersedes header that sometimes appears in Email messages converted 705 from X.400 according to [RFC2156]; in particular, the syntax here 706 permits only one in contrast to the multiple 707 s in that Email version. 709 3.2.6 Distribution 711 The Distribution header specifies geographic or organizational limits 712 on an article's propagation. 714 distribution = "Distribution:" SP distribution-list CRLF 716 dist-list = [FWS] dist-name *( "," [FWS] dist-name ) [FWS] 718 dist-name = ALPHA / DIGIT 719 *( ALPHA / DIGIT / "+" / "-" / "_" ) 721 The s "world" and "local" are predefined. However, 722 "world" SHOULD NOT be used explicitly, since it is the default when 723 the Distribution header is absent entirely. 725 "All" MUST NOT be used as a . s SHOULD contain 726 at least three characters, except when they are two-letter country 727 names as in [ISO.3166.1988]. s are case-insensitive (i.e. 728 "US", "Us", "uS", and "us" all specify the same distribution). 730 3.2.7 Summary 732 The Summary header is a short phrase summarizing the article's 733 content. 735 summary = "Summary:" SP unstructured CRLF 737 3.2.8 Approved 739 The Approved header indicates the mailing addresses (and possibly the 740 full names) of the persons or entities approving the article for 741 posting. 743 approved = "Approved:" SP mailbox-list CRLF 745 Each mailbox contained in the Approved header MUST be that of one of 746 the person(s) or entity(ies) in question, and one of those mailboxes 747 MUST be that of the actual injector of the article. Note that this 748 standard doesn't provide any means to enforce or verify this 749 requirement, but future extensions or standards may provide such a 750 facility (e.g. digitial signatures). 752 3.2.9 Organization 754 The Organization header is a short phrase identifying the poster's 755 organization. 757 organization = "Organization:" SP unstructured CRLF 759 There is no "s" in Organization. 761 3.2.10 Xref 763 The Xref header indicates where an article was filed by the last 764 serving agent to process it. The article locations are used to keep 765 track of crossposted articles so that reading agents serviced by a 766 particular serving agent can mark such articles as read. 768 xref = "Xref:" SP [CFWS] server-name 769 1*( CFWS location ) [CFWS] CRLF 771 server-name = path-identity 773 location = newsgroup-name ":" article-locator 775 article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E ) 776 ; US-ASCII printable characters 777 ; except '(' and ';' 779 The is included so that software can determine which 780 serving agent generated the header. The locations specify what 781 newsgroups the article was filed under (which may differ from those 782 in the Newsgroups header) and where it was filed under them. The 783 exact form of an article-locator is implementation-specific. 785 NOTE: The traditional form of an article-locator (as used by 786 [NNTP]) is a decimal number, with articles in each newsgroup 787 numbered consecutively starting from 1. 789 3.2.11 Archive 791 The Archive header provides an indication of the poster's intent 792 regarding preservation of the article in publicly accessible 793 long-term or permanent storage. 795 archive = "Archive:" SP [CFWS] ("no" / "yes") 796 *( [CFWS] ";" archive-param ) CRLF 798 archive-param = "filename=" value 800 The presence of an "Archive: no" header in an article indicates that 801 the poster does not permit redistribution from publicly accessible 802 long-term or permanent archives. The absence of this header, or an 803 explicit "Archive: yes", indicates that the poster is willing for 804 such redistribution to take place. The optional "filename" parameter 805 can then be used to suggest a filename under which the article should 806 be stored. Further extensions to this standard may provide 807 additional parameters for administration of the archiving process. 809 3.2.12 User-Agent 811 The User-Agent header contains information about the user agent 812 (typically a newsreader) generating the article, for statistical 813 purposes and tracing of standards violations to specific software 814 needing correction. It is intended that this header be suitable for 815 use in Email. 817 user-agent = "User-Agent:" SP 1*product CRLF 819 product = [CFWS] token [CFWS] [ "/" product-version ] 821 product-version = [CFWS] token [CFWS] 823 This header MAY contain multiple product-tokens identifying the agent 824 and any subproducts which form a significant part of the posting 825 agent, listed in order of their significance for identifying the 826 application. 827 NOTE: This header supersedes the role performed redundantly by 828 experimental headers such as X-Newsreader, X-Mailer, 829 X-Posting-Agent, X-Http-User-Agent, and other headers previously 830 used on Usenet and in Email for this purpose. Use of these 831 experimental headers SHOULD be discontinued in favor of the 832 single, standard User-Agent header. 833 NOTE: [RFC2616] describes a similar facility for the HTTP 834 protocol. This specification differs in that "{" and "}" are 835 allowed in tokens ( and ) and comments 836 are permitted wherever whitespace is allowed. 838 3.2.13 Injection-Info 840 The Injection-Info header provides information as to how an article 841 entered the Netnews system and to assist in tracing its true origin. 843 injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] 844 *( ";" inj-info-para ) CRLF 846 inj-info-param = post-host-param / 847 post-account-param / 848 sender-param / 849 logging-param 851 post-host-param = "posting-host=" host-value 853 host-value = dot-atom / [ dot-atom ":" ] 854 ( IPv4address / IPv6address ) ; see [RFC 2373] 856 post-acct-param = "posting-account=" value 858 sender-param = "sender=" sender-value 860 sender-value = mailbox / "verified" 862 logging-param = "logging-data=" value 863 Although comments and folding of white space are permitted throughout 864 the Injection-Info header, it is RECOMMENDED that folding is not used 865 within any parameter (but only before or after the ";" separating 866 those parameters), and that comments are only used following the last 867 parameter. It is also RECOMMENDED that such parameters as are 868 present are included in the order in which they have been defined in 869 the syntax above. 871 This header is intended to replace various currently-used but 872 undocumented headers such as "NNTP-Posting-Host" and "X-Trace". 873 These headers are now deprecated. 875 3.3 Obsolete Headers 877 Early versions of news software following the modern format sometimes 878 generated headers like the following: 880 Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP 881 Posting-Version: version B 2.10 2/13/83; site eagle.UUCP 882 Date-Received: Friday, 19-Nov-82 16:59:30 EST 884 Relay-Version contained version information about the relaying agent 885 that last processed the article. Posting-Version contained version 886 information about the posting agent that posted the article. 887 Date-Received contained the date when the last relaying agent to 888 process the article first saw it (in a slightly nonstandard format). 890 In addition, this present standard obsoletes certain headers defined 891 in [Son-of-1036]: 893 Also-Control: cancel <9urrt98y53@site.example> 894 See-Also: 895 Article-Names: comp.foo:charter 896 Article-Updates: 898 Also-Control indicated a control message that was also intended to be 899 filed as a normal article. See-Also listed related articles, but 900 without the specific relationship with followups that pertains to the 901 References-header. Article-Names indicated some special significance 902 of that article in relation to the indicated newsgroup. 903 Article-Updates indicated that an earlier article was updated, 904 without at the same time being superseded. 906 The headers listed above are documented for historical purposes only. 907 Articles containing these headers MUST NOT be generated. Persons 908 writing new agents SHOULD ignore any former meanings these headers. 910 3.3.1 Lines 912 The Lines header indicates the number of lines in the body of the 913 article. 915 lines = "Lines" ":" SP [CFWS] 1*DIGIT [CFWS] CRLF 917 The line count includes all body lines, including the signature if 918 any, including empty lines (if any) at the beginning or end of the 919 body, and including the whole of all MIME message and multipart parts 920 contained in the body (the single empty separator line between the 921 headers and the body is not part of the body). The "body" here is 922 the body as found in the posted article as transmitted by the posting 923 agent. 925 Historically, this header was used by the [NNTP] overview extension, 926 but its use for this purpose is now deprecated. As a result, this 927 header is to be regarded as obsolete, and it will likely be removed 928 entirely in a future version of this standard. 930 4. Internationalization Considerations 932 Internationalization of news article headers and bodies is provided 933 using MIME mechanisms discussed in Section 2.3. Note that the 934 generation of internationalized newsgroup names for use in headers is 935 not addressed in this document. 937 5. Security Considerations 939 The news article format specified in this document does not provide 940 any security services, such as confidentiality, authentication of 941 sender, or non-repudiation. Instead, such services need to be 942 layered above, using such protocols as S/MIME [RFC2633] or PGP/MIME 943 [RFC3156], or below, using secure versions of news transport 944 protocols. Additionally, several currently non-standardized 945 protocols [PGPVERIFY] will hopefully be standardized in the near 946 future. 948 Message-IDs (Section 3.1.3) in news are required to be unique; 949 articles are refused (in server-to-server transfer) if the ID has 950 already been seen. So if you can predict the ID of a message, you 951 can preempt it by posting a message (possibly to a quite different 952 group) with the same ID, stopping your target message from 953 propagating. Agents that generate message-ids for news articles 954 SHOULD ensure that they are unpredictable. 956 The filename parameter of the Archive-header (Section 3.2.11) can be 957 used to attempt to store archived articles in inappropriate 958 locations. Archiving sites should be suspicious of absolute filename 959 parameters, as opposed to those relative to some location of the 960 archiver's choosing. 962 6. References 964 6.1 Normative References 966 [Errata] "RFC Editor Errata". 968 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 969 Extensions (MIME) Part One: Format of Internet Message 970 Bodies", RFC 2045, November 1996. 972 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 973 Extensions (MIME) Part Two: Media Types", RFC 2046, 974 November 1996. 976 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 977 Part Three: Message Header Extensions for Non-ASCII Text", 978 RFC 2047, November 1996. 980 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 981 Extensions (MIME) Part Five: Conformance Criteria and 982 Examples", RFC 2049, November 1996. 984 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 985 Requirement Levels", BCP 14, RFC 2119, March 1997. 987 [RFC2183] Troost, R., Dorner, S. and K. Moore, "Communicating 988 Presentation Information in Internet Messages: The 989 Content-Disposition Header Field", RFC 2183, August 1997. 991 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 992 Word Extensions: Character Sets, Languages, and 993 Continuations", RFC 2231, November 1997. 995 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 996 Specifications: ABNF", RFC 2234, November 1997. 998 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 999 2001. 1001 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 1002 2002. 1004 6.2 Informative References 1006 [ISO.3166.1988] 1007 International Organization for Standardization, "Codes for 1008 the representation of names of countries, 3rd edition", 1009 ISO Standard 3166, August 1988. 1011 [NNTP] Feather, C., "Network News Transfer Protocol", 1012 draft-ietf-nntpext-base-*.txt. 1014 [PGPVERIFY] 1015 Lawrence, D., "PGPverify", June 1999. 1017 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 1018 USENET messages", RFC 1036, December 1987. 1020 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 1021 Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1022 1998. 1024 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1025 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1026 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1028 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1029 RFC 2633, June 1999. 1031 [RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, 1032 "MIME Security with OpenPGP", RFC 3156, August 2001. 1034 [Son-of-1036] 1035 Spencer, H., "News Article Format and Transmission", June 1036 1994. 1038 [USEAGE] Lindsey, C., "Usenet Best Practice", 1039 draft-ietf-usefor-useage-*.txt. 1041 [USEPRO] Lindsey, C., "News Article Architecture and Protocols", 1042 draft-ietf-usefor-usepro-*.txt. 1044 Authors' Addresses 1046 Kenneth Murchison (editor) 1047 Oceana Matrix Ltd. 1048 21 Princeton Place 1049 Orchard Park, NY 14127 1050 US 1052 Phone: +1 716 662 8973 1053 EMail: ken@oceana.com 1054 Charles H. Lindsey 1055 University of Manchester 1056 5 Clerewood Avenue 1057 Heald Green 1058 Cheadle 1059 Chesire SK8 3JU 1060 GB 1062 Phone: +44 161 436 6131 1063 EMail: chl@clw.cs.man.ac.uk 1065 Dan Kohn 1066 Skymoon Ventures 1067 3045 Park Boulevard 1068 Palo Alto, CA 94306 1069 US 1071 Phone: +1 650 327 2600 1072 EMail: dan@dankohn.com 1074 Appendix A. Acknowledgements 1076 Comments and/or text were provided by Mark Crispin, Claus Faerber, 1077 Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, 1078 Bruce Lilly, Pete Resnick, Henry Spencer, Russ Allbery, and Alexey 1079 Melnikov. 1081 Intellectual Property Statement 1083 The IETF takes no position regarding the validity or scope of any 1084 Intellectual Property Rights or other rights that might be claimed to 1085 pertain to the implementation or use of the technology described in 1086 this document or the extent to which any license under such rights 1087 might or might not be available; nor does it represent that it has 1088 made any independent effort to identify any such rights. Information 1089 on the procedures with respect to rights in RFC documents can be 1090 found in BCP 78 and BCP 79. 1092 Copies of IPR disclosures made to the IETF Secretariat and any 1093 assurances of licenses to be made available, or the result of an 1094 attempt made to obtain a general license or permission for the use of 1095 such proprietary rights by implementers or users of this 1096 specification can be obtained from the IETF on-line IPR repository at 1097 http://www.ietf.org/ipr. 1099 The IETF invites any interested party to bring to its attention any 1100 copyrights, patents or patent applications, or other proprietary 1101 rights that may cover technology that may be required to implement 1102 this standard. Please address the information to the IETF at 1103 ietf-ipr@ietf.org. 1105 Disclaimer of Validity 1107 This document and the information contained herein are provided on an 1108 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1109 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1110 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1111 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1112 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1113 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1115 Copyright Statement 1117 Copyright (C) The Internet Society (2004). This document is subject 1118 to the rights, licenses and restrictions contained in BCP 78, and 1119 except as set forth therein, the authors retain all their rights. 1121 Acknowledgment 1123 Funding for the RFC Editor function is currently provided by the 1124 Internet Society.