idnits 2.17.1 draft-ietf-usefor-usefor-00.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 695. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 711), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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.) -- The draft header indicates that this document obsoletes RFC1036, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2822, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2822, updated by this document, for RFC5378 checks: 1996-11-27) -- 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 (July 11, 2004) is 7228 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 2822' is mentioned on line 196, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'CFWS' is mentioned on line 342, but not defined == Unused Reference: 'RFC2646' is defined on line 585, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2646 (Obsoleted by RFC 3676) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 977 (Obsoleted by RFC 3977) -- Obsolete informational reference (is this intentional?): RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Usenet Format Working Group C. Lindsey 2 Internet-Draft University of Manchester 3 Updates: 2822 (if approved) D. Kohn 4 Obsoletes: 1036 (if approved) Skymoon Ventures 5 Expires: January 9, 2005 K. Murchison 6 Oceana Matrix Ltd. 7 July 11, 2004 9 News Article Format 10 draft-ietf-usefor-usefor-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document defines the format of network news articles. 45 Network news articles resemble mail messages but are broadcast to 46 potentially large audiences, using a flooding algorithm that 47 propagates one copy to each interested host (or group thereof), 48 typically stores only one copy per host, and does not require any 49 central administration or systematic registration of interested 50 users. Network news originated as the medium of communication for 51 Usenet, circa 1980. Since then Usenet has grown explosively, and 52 many Internet sites participate in it. In addition, the news 53 technology is now in widespread use for other purposes, on the 54 Internet and elsewhere. 56 This document defines the format of network news articles in the 57 context of the Internet Message Format, and adds Multipurpose 58 Internet Mail Extensions (MIME) support for multimedia and 59 internationalized message bodies. 61 Changes since draft-kohn-news-article-03 63 o Document is now a work product of USEFOR 64 o Added new co-authors 65 o Added some definitions from draft-ietf-usefor-article-13 66 o Removed text that belongs in [usepro] 67 o Reorganized header sections 68 o Added Archive and User-Agent headers 69 o Compatibility changes based on comments from Charles 71 Issues to be addressed 73 o More detailed discussion of Control header verbs 74 o Discussion of 78 character limit in headers 75 o Discussion of required space after ':' in headers 76 o Review Message-ID limitations 77 o Further discussion of newsgroup name character limits 78 o Investigate using MIME parameters for Archive header 79 o Should we use the User-Agent specification from HTTP? 80 o Review of ABNF 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 85 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.2 Requirements Notation . . . . . . . . . . . . . . . . . . 5 87 1.3 Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 1.4 Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 89 1.5 Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 90 1.6 Structure of This Document . . . . . . . . . . . . . . . . 6 91 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 92 2.1 Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 93 2.2 MIME Conformance . . . . . . . . . . . . . . . . . . . . . 7 94 2.3 Additional MIME Support . . . . . . . . . . . . . . . . . 7 95 3. Internet Message Format Headers . . . . . . . . . . . . . . 8 96 3.1 Mandatory Headers . . . . . . . . . . . . . . . . . . . . 8 97 3.2 Optional Headers . . . . . . . . . . . . . . . . . . . . . 8 98 3.3 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 99 3.4 Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 9 100 3.5 News Headers . . . . . . . . . . . . . . . . . . . . . . . 10 101 3.5.1 Newsgroups . . . . . . . . . . . . . . . . . . . . . . 10 102 3.5.2 Path . . . . . . . . . . . . . . . . . . . . . . . . . 10 103 3.5.3 Followup-To . . . . . . . . . . . . . . . . . . . . . 11 104 3.5.4 Expires . . . . . . . . . . . . . . . . . . . . . . . 11 105 3.5.5 Control . . . . . . . . . . . . . . . . . . . . . . . 11 106 3.5.6 Distribution . . . . . . . . . . . . . . . . . . . . . 12 107 3.5.7 Summary . . . . . . . . . . . . . . . . . . . . . . . 12 108 3.5.8 Approved . . . . . . . . . . . . . . . . . . . . . . . 12 109 3.5.9 Organization . . . . . . . . . . . . . . . . . . . . . 12 110 3.5.10 Xref . . . . . . . . . . . . . . . . . . . . . . . . 12 111 3.5.11 Supersedes . . . . . . . . . . . . . . . . . . . . . 13 112 3.5.12 Archive . . . . . . . . . . . . . . . . . . . . . . 13 113 3.5.13 User-Agent . . . . . . . . . . . . . . . . . . . . . 13 114 4. Internationalization Considerations . . . . . . . . . . . . 14 115 5. Security Considerations . . . . . . . . . . . . . . . . . . 15 116 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 117 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 118 6.2 Informative References . . . . . . . . . . . . . . . . . . . 16 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 120 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 121 Intellectual Property and Copyright Statements . . . . . . . 20 123 1. Introduction 125 1.1 Scope 127 "Netnews" is a set of protocols for generating, storing and 128 retrieving news "articles" (a subset of the Internet Message Format) 129 and for exchanging them among a readership which is potentially 130 widely distributed. It is organized around "newsgroups", with the 131 expectation that each reader will be able to see all articles posted 132 to each newsgroup in which she participates. These protocols most 133 commonly use a flooding algorithm which propagates copies throughout 134 a network of participating servers. Typically, only one copy is 135 stored per server, and each server makes it available on demand to 136 readers able to access that server. 138 This is the first of four documents that obsolete RFC 1036. This 139 document focuses on the syntax and semantics of network news 140 articles. [usepro] is also a standards-track document, and describes 141 the protocol issues of network news articles, independent of 142 transmission protocols such as NNTP [RFC0977] and IMAP [RFC3501]. An 143 informational document, [useage], describes implementation 144 recommendations to improve interoperability and usability. The 145 fourth document, [useint], an experimental standard, specifies 146 internationalization of message headers. 148 The predecessor to this document [RFC1036] said that: "In any 149 situation where this standard conflicts with the Internet [email 150 standard, the latter] should be considered correct and this standard 151 in error." The basic philosophy of this document follows that 152 previous convention, so as to standardize news article syntax firmly 153 as a subset of the Internet Message Format syntax. Note that this 154 means that all news articles are suitable for email, but the converse 155 isn't necessarily true. 157 In the context of the Internet messaging architecture, different 158 protocols (such as IMAP, POP3 [RFC1939], NNTP and SMTP [RFC2821]) are 159 seen as alternative ways of moving around the same content. That 160 content is the Internet Message Format as specified by [RFC2822], 161 including optional enhancements such as MIME [RFC2049]. A user 162 should be able to ingest an article via NNTP, read it via IMAP, 163 forward it off to someone else via SMTP and have them read it via 164 POP3 all without having to alter the content. 166 This document uses a cite by reference methodology, rather than 167 trying to repeat the contents of other standards, which could 168 otherwise result in subtle differences and interoperability 169 challenges. Although this document is as a result rather short, it 170 requires complete understanding and implementation of the normative 171 references to be compliant. 173 1.2 Requirements Notation 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 1.3 Errata 181 The RFC Editor makes available errata for RFCs at [errata]. 182 Implementers should review that page for normative references, noting 183 in particular that errata currently exist for [RFC2046] and 184 [RFC2231]. 186 1.4 Syntax Notation 188 Headers defined in this specification use the Augmented Backus-Naur 189 Form (ABNF) notation (including the Core Rules) specified in 190 [RFC2234] and many constructs (specifically , 191 , , and ) defined in [RFC2822]. 192 Section 3.4 updates the [RFC2822] definition of . 194 1.5 Definitions 196 An "article" is the unit of news, analogous to an [RFC 2822] 197 "message". A "proto-article" is one that has not yet been injected 198 into the news system. 200 A "newsgroup" is a single news forum, a logical bulletin board, 201 having a name and nominally intended for articles on a specific 202 topic. An article is "posted to" a single newsgroup or several 203 newsgroups. When an article is posted to more than one newsgroup, it 204 is said to be "crossposted"; note that this differs from posting the 205 same text as part of each of several articles, one per newsgroup. 207 A newsgroup may be "moderated", in which case submissions are not 208 posted directly, but mailed to a "moderator" for consideration and 209 possible posting. Moderators are typically human but may be 210 implemented partially or entirely in software. 212 A "gateway" is software which receives news articles and converts 213 them to messages of some other kind (e.g. mail to a mailing list), 214 or vice versa; in essence it is a translating relaying agent that 215 straddles boundaries between different methods of message exchange. 216 The most common type of gateway connects newsgroup(s) to mailing 217 list(s), either unidirectionally or bidirectionally, but there are 218 also gateways between news networks using this standard's news format 219 and those using other formats. 221 1.6 Structure of This Document 223 Section 2 defines the format of news articles. Section 3 defines 224 some additional headers necessary for the netnews environment. 226 2. Format 228 2.1 Base 230 News articles MUST conform to the "legal to generate syntax" 231 specified in Section 3 of [RFC2822]. News agents MAY also accept the 232 obsolete syntax specified in Section 4 of [RFC2822], but they MUST 233 NOT generate such syntax. 235 2.2 MIME Conformance 237 User agents MUST meet the definition of MIME-conformance in 238 [RFC2049]. This level of MIME Conformance provides support for 239 internationalization and multimedia in message bodies, and support 240 for internationalization of headers. Note that the generation of 241 internationalized newsgroup names for use in headers is specified by 242 [useint]. 244 2.3 Additional MIME Support 246 User agents conformant with this document MAY support receipt (and 247 automatic reassembly) of message/partial MIME messages, as specified 248 in Section 5.2.2 of [RFC2046] and MAY support generation of message/ 249 partial articles for excessively large articles. 251 User agents SHOULD support on receipt and MAY generate MIME extension 252 header fields, including but not limited to Content-Disposition 253 [RFC2183] and Content-Language [RFC3282]. 255 3. Internet Message Format Headers 257 Following [RFC2822] syntax, the headers defined in this document do 258 not require a space between the ":" and the field's contents. (E.g., 259 "Subject:Hello World" is acceptable, as opposed to requiring 260 "Subject: Hello World".) To be compliant with this specification, 261 news agents MUST support 0 or more spaces between the colon and the 262 field's contents. However, to maximize compatibility with the 263 installed base of news agents, implementers SHOULD use exactly one 264 space. 266 3.1 Mandatory Headers 268 Each news article conformant with this specification MUST have 269 exactly one of each of the following headers: From, Subject, Date, 270 Message-ID, Newsgroups, and Path. 272 From and Subject are exactly as specified in Sections 3.6.2 and 3.6.5 273 respectively of [RFC2822]. Further discussion of the content of the 274 Subject header is discussed in [usepro] and [useage]. 276 Date is fully conformant with [RFC2822], though with extra 277 restrictions detailed in Section 3.3 279 In Section 3.4, this document updates the construct from 280 [RFC2822] so as to ensure that Internet Message Format Message-IDs 281 are usable in widely deployed news software. 283 Newsgroups and Path are defined in Section 3.5.1 and Section 3.5.2 284 respectively. 286 3.2 Optional Headers 288 The headers Reply-To, Sender, Comments, and Keywords are often used 289 in news articles and have the identical meaning as that specified in 290 [RFC2822]. References and In-Reply-To are also regularly used in 291 news articles and have same the same meaning as that specified in 292 [RFC2822], except that they use the updated construct 293 defined in Section 3.4. 295 The headers Followup-To, Expires, Control, Distribution, Summary, 296 Approved, Organization, Xref, Supersedes, Archive, and User-Agent are 297 often used in news articles and are defined in Section 3.5. 299 3.3 Date 301 The Date header is the same as that specified in Sections 3.3 and 302 3.6.1 of [RFC2822]. However, the use of "GMT" as a time zone, which 303 is part of , is widespread in news articles today. 304 Therefore, agents MUST accept, but MUST NOT generate, 305 constructs which include . (As stated in Section 2.1, 306 support for would otherwise have been SHOULD accept, MUST 307 NOT generate.) Note that these requirements apply wherever 308 is used, including Expires in Section 3.5.4. 310 3.4 Message-ID 312 The "Message-ID:" field contains a single unique message identifier. 313 This is the only header field definition that updates [RFC2822]. The 314 ABNF should be used as below, but the requirements and descriptive 315 text from Section 3.6.4 of [RFC2822] still apply. 317 message-id = "Message-ID:" msg-id CRLF 319 msg-id = [CFWS] msg-id-core [CFWS] 321 msg-id-core = "<" id-left "@" id-right ">" 322 ; maximum length is 250 octets 324 id-left = dot-atom-text / no-fold-quote / obs-id-left 326 id-right = dot-atom-text / no-fold-literal / obs-id-right 328 no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE 330 no-fold-literal = "[" *( htext / no-space-qp ) "]" 332 no-space-qp = ( "\" ptext ) / obs-qp 334 ptext = %d33-61 / ; Printable characters excluding ">" 335 %d63-126 / 336 obs-text 338 htext = HEXDIG / ; hexadecimal digits, case-insensitive 339 "." / ; IPv4 separator 340 ":" ; IPv6 separator 342 Although compliant agents MUST support [CFWS] between the 343 "Message-ID:" and the , implementers SHOULD generate 344 exactly one space there, to maximize compatibility with the installed 345 base. 347 Note that this updated ABNF applies wherever is used, 348 including the In-Reply-To and References headers mentioned in Section 349 3.2. 351 3.5 News Headers 353 The following news headers (also known as header fields) extend the 354 fields defined in section 3.6 of [RFC2822] as follows: 356 fields =/ *( newsgroups / 357 path / 358 followup-to / 359 expires / 360 control / 361 distribution / 362 summary / 363 approved / 364 organization / 365 xref / 366 supersedes / 367 archive / 368 user-agent ) 370 Each of these headers may occur at most once in a news article. 372 3.5.1 Newsgroups 374 The Newsgroups header specifies to which newsgroup(s) the article is 375 posted. 377 newsgroups = "Newsgroups:" newsgroup-list CRLF 379 newsgroup-list = [FWS] newsgroup-name 380 *( "," [FWS] newsgroup-name ) [FWS] 382 newsgroup-name = component *( "." component ) ; 71 character max 384 component = plain-component 386 plain-component = component-start *29component-rest 388 component-start = ALPHA / DIGIT 390 component-rest = ALPHA / DIGIT / "+" / "-" / "_" 392 A newsgroup name consists of one or more components separated by 393 periods, with no more than 71 characters total. Each component 394 consists of less than 30 or less letters and digits. 396 3.5.2 Path 398 The Path header's content indicates which relayers the article has 399 already visited, so that unnecessary redundant transmission can be 400 avoided. 402 path = "Path:" [FWS] 403 *( path-host [FWS] path-delimiter [FWS] ) 404 path-host [FWS] CRLF 406 path-host = ( ALPHA / DIGIT ) 407 *( ALPHA / DIGIT / "-" / "." / ":" / "_" ) 409 path-delimiter = "!" 411 3.5.3 Followup-To 413 The Followup-To header specifies to which newsgroup(s) followups 414 should be posted. 416 followup-to = "Followup-To:" ( newsgroup-list / poster-text ) 417 CRLF 419 poster-text = [FWS] %d112.111.115.116.101.114 [FWS] 420 ; "poster" in lower-case 422 The syntax is the same as that of the Newsgroups content, with the 423 exception that the magic word "poster" (which is always lowercase) 424 means that followups should be mailed to the article's reply address 425 rather than posted. 427 3.5.4 Expires 429 The Expires header specifies a date and time when the article is 430 deemed to be no longer useful and could usefully be removed 431 ("expired"). 433 expires = "Expires:" date-time CRLF 435 3.5.5 Control 437 The Control header marks the article as a control message, and 438 specifies the desired actions (additional to the usual ones of 439 storing and/or relaying the article). The verb indicates what action 440 should be taken, and the argument(s) (if any) supply details. In 441 some cases, the body of the article may also contain details. 442 Control messages are further specified in the companion document, 443 [usepro]. 445 control = "Control:" verb *( FWS argument ) CRLF 447 An article with a Control header MUST NOT have a Supersedes header. 449 3.5.6 Distribution 451 The Distribution header specifies geographic or organizational limits 452 on an article's propagation. 454 distribution = "Distribution:" dist-name *( "," dist-name ) CRLF 456 dist-name = [FWS] ALPHA / DIGIT 457 *( ALPHA / DIGIT / "+" / "-" / "_" ) [FWS] 459 "All" MUST NOT be used as a distribution-name. Distribution-names 460 SHOULD contain at least three characters, except when they are 461 two-letter country names as in [ISO.3166.1988]. Distribution-names 462 are case-insensitive (i.e. "US", "Us", "uS", and "us" all specify 463 the same distribution). 465 3.5.7 Summary 467 The Summary header is a short phrase summarizing the article's 468 content. 470 summary = "Summary:" unstructured CRLF 472 3.5.8 Approved 474 The Approved header indicates the mailing addresses (and possibly the 475 full names) of the moderators approving the article for posting. 477 approved = "Approved:" mailbox-list CRLF 479 3.5.9 Organization 481 The Organization header is a short phrase identifying the poster's 482 organization. 484 organization = "Organization:" unstructured CRLF 486 There is no "s" in Organization. 488 3.5.10 Xref 490 The Xref header indicates where an article was filed by the last 491 server to process it. 493 xref = "Xref:" [CFWS] path-host 494 1*( CFWS location ) CRLF 496 location = newsgroup-name ":" 1*16DIGIT 498 3.5.11 Supersedes 500 The Supersedes header specifies articles to be cancelled. 502 supersedes = "Supersedes:" 1*( [FWS] msg-id-core ) CRLF 504 There is no "c" in Supersedes. 506 3.5.12 Archive 508 The Archive header provides an indication of the poster's intent 509 regarding preservation of the article in publicly accessible 510 long-term or permanent storage. 512 archive = "Archive:" [CFWS] ("no" / "yes") 513 *( [CFWS] ";" archive-param ) CRLF 515 archive-param = 518 3.5.13 User-Agent 520 The User-Agent header contains information about the user agent 521 (typically a newsreader) generating the article for statistical 522 purposes and tracing of standards violations to specific software 523 needing correction. Although not one of the mandatory headers, 524 posting agents SHOULD normally include it. It is also intended that 525 this header be suitable for use in Email. 527 user-agent = "User-Agent:" 528 1*( [CFWS] product [ "/" prod-version ] ) CRLF 530 product = token 531 prod-version = token 533 4. Internationalization Considerations 535 Internationalization of news article bodies is provided using MIME 536 mechanisms in Section 2.2. Generation of internationalized message 537 headers is not specified in this document, and is instead specified 538 in the experimental standard, [useint]. 540 5. Security Considerations 542 The news article format specified in this document does not provide 543 any security services, such as confidentiality, authentication of 544 sender, or non-forgery. Instead, such services need to be layered 545 above, using such protocols as S/MIME [RFC2633] or PGP/MIME 546 [RFC3156], or below, using secure versions of news transport 547 protocols. Additionally, several currently non-standardized 548 protocols [PGPVERIFY] will hopefully be standardized in the near 549 future. 551 Message-IDs (see Section 3.4) in news are required to be unique; 552 articles are refused (in server-to-server transfer) if the ID has 553 already been seen. So if you can predict the ID of a message, you 554 can preempt it by posting a message (possibly to a quite different 555 group) with the same ID, stopping your target message from 556 propagating. Agents that generate message-ids for news articles 557 SHOULD ensure that they are unpredictable. 559 6. References 561 6.1 Normative References 563 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 564 Extensions (MIME) Part Two: Media Types", RFC 2046, 565 November 1996. 567 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 568 Extensions (MIME) Part Five: Conformance Criteria and 569 Examples", RFC 2049, November 1996. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 [RFC2183] Troost, R., Dorner, S. and K. Moore, "Communicating 575 Presentation Information in Internet Messages: The 576 Content-Disposition Header Field", RFC 2183, August 1997. 578 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 579 Word Extensions: Character Sets, Languages, and 580 Continuations", RFC 2231, November 1997. 582 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 583 Specifications: ABNF", RFC 2234, November 1997. 585 [RFC2646] Gellens, R., "The Text/Plain Format Parameter", RFC 2646, 586 August 1999. 588 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 589 2001. 591 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 592 2002. 594 6.2 Informative References 596 [ISO.3166.1988] 597 International Organization for Standardization, "Codes for 598 the representation of names of countries, 3rd edition", 599 ISO Standard 3166, August 1988. 601 [PGPVERIFY] 602 Lawrence, D., "PGPverify 603 ", June 604 1999. 606 [RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer 607 Protocol", RFC 977, February 1986. 609 [RFC1036] Horton, M. and R. Adams, "Standard for interchange of 610 USENET messages", RFC 1036, December 1987. 612 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 613 STD 53, RFC 1939, May 1996. 615 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 616 RFC 2633, June 1999. 618 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 619 April 2001. 621 [RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, 622 "MIME Security with OpenPGP", RFC 3156, August 2001. 624 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 625 4rev1", RFC 3501, March 2003. 627 [errata] "RFC Editor Errata 628 ". 630 [useage] "Usenet Implementation Recommendations (work in 631 progress)". 633 [useint] "Usenet Internationalization (work in progress)". 635 [usepro] "Usenet Protocol (work in progress)". 637 Authors' Addresses 639 Charles H. Lindsey 640 University of Manchester 641 5 Clerewood Avenue 642 Heald Green 643 Cheadle 644 Chesire SK8 3JU 645 GB 647 Phone: +44 161 436 6131 648 EMail: chl@clw.cs.man.ac.uk 649 Dan Kohn 650 Skymoon Ventures 651 3045 Park Boulevard 652 Palo Alto, CA 94306 653 US 655 Phone: +1 650 327 2600 656 EMail: dan@dankohn.com 658 Kenneth Murchison 659 Oceana Matrix Ltd. 660 21 Princeton Place 661 Orchard Park, NY 14127 662 US 664 Phone: +1 716 662 8973 665 EMail: ken@oceana.com 667 Appendix A. Acknowledgements 669 Comments and/or text were provided by Mark Crispin, Claus Faerber, 670 Ned Freed, Andrew Gierth, Tony Hansen, Paul Hoffman, Simon Josefsson, 671 Bruce Lilly, Pete Resnick, and Henry Spencer. 673 Intellectual Property Statement 675 The IETF takes no position regarding the validity or scope of any 676 Intellectual Property Rights or other rights that might be claimed to 677 pertain to the implementation or use of the technology described in 678 this document or the extent to which any license under such rights 679 might or might not be available; nor does it represent that it has 680 made any independent effort to identify any such rights. Information 681 on the procedures with respect to rights in RFC documents can be 682 found in BCP 78 and BCP 79. 684 Copies of IPR disclosures made to the IETF Secretariat and any 685 assurances of licenses to be made available, or the result of an 686 attempt made to obtain a general license or permission for the use of 687 such proprietary rights by implementers or users of this 688 specification can be obtained from the IETF on-line IPR repository at 689 http://www.ietf.org/ipr. 691 The IETF invites any interested party to bring to its attention any 692 copyrights, patents or patent applications, or other proprietary 693 rights that may cover technology that may be required to implement 694 this standard. Please address the information to the IETF at 695 ietf-ipr@ietf.org. 697 Disclaimer of Validity 699 This document and the information contained herein are provided on an 700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 702 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 703 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 704 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 Copyright Statement 709 Copyright (C) The Internet Society (2004). This document is subject 710 to the rights, licenses and restrictions contained in BCP 78, and 711 except as set forth therein, the authors retain all their rights. 713 Acknowledgment 715 Funding for the RFC Editor function is currently provided by the 716 Internet Society.