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