idnits 2.17.1 draft-ietf-usefor-posted-mailed-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 640 lines 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '...th mail and news destinations, it MUST...' RFC 2119 keyword, line 133: '..., conformant software MUST assume that...' RFC 2119 keyword, line 134: '...conform to this document, and MUST NOT...' RFC 2119 keyword, line 136: '...conformant software MUST NOT treat the...' RFC 2119 keyword, line 139: '...This header MUST be present both in th...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1998) is 9447 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 215, but not defined == Unused Reference: 'USEFOR' is defined on line 549, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. 'MAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 977 (ref. 'NNTP') (Obsoleted by RFC 3977) ** Obsolete normative reference: RFC 1036 (ref. 'NEWS') (Obsoleted by RFC 5536, RFC 5537) ** Obsolete normative reference: RFC 1738 (ref. 'NEWSURL') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-13) exists of draft-ietf-usefor-article-00 -- Possible downref: Normative reference to a draft: ref. 'USEFOR' Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Matt Curtin 2 draft-ietf-usefor-posted-mailed-00.txt The Ohio State University 3 Category-to-be: Proposed standard Jamie Zawinski 4 Netscape Communications 6 June 1998 7 Expires: Six Months from above date 9 Identification of messages delivered via both mail and news 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This draft defines a format to be used when delivering a single message 33 to multiple destinations, where some destinations are newsgroups and 34 some destinations are email mailboxes. 36 Table of contents 38 1. Introduction 39 2. Terminology 40 3. Definitions of new message elements 41 3.1. The Posted-And-Mailed header 42 3.2. The Followup-Host header 43 3.3. The Author-Message-ID header 44 3.4. The message body prolog 45 4. Clarifications of the semantics of existing headers 46 4.1. References and In-Reply-To 47 4.2. Message-ID 48 4.3. Followup-To 49 4.4. Newsgroups 50 5. Security considerations 51 6. Acknowledgments 52 7. References 53 8. Authors' Addresses 54 Appendix A: Examples 56 1. Introduction 58 Most news readers include facilities for generating replies which are 59 either posted to news, or mailed directly to the author. An increasing 60 number of news readers have the ability to do both simultaneously: to 61 post one copy of the message to news, and to send a copy of that same 62 message to a set of recipients via email. 64 When one receives an email message, there is currently no reliable way 65 to identify that message as being one which has also been posted. This 66 document specifies a mechanism by which such messages may be identified. 68 The model used in this document is that a single message is prepared, 69 and then delivered on multiple transports to its various destinations. 70 This is not intended to dictate anything about the mechanism by which 71 message delivery must be implemented. But, it is rather intended to 72 convey the intent that both messages should, as far as is possible, have 73 identical bodies and headers. 75 Obviously, various transports (including, but not limited to, [SMTP] and 76 [NNTP]) will add various headers to the messages they carry, and so it 77 will never be the case that two copies of the same message which are 78 received via different transports will be identical. However, excepting 79 the headers added by the transports, it is likely that the two copies of 80 the message will have identical headers, and is also likely that they 81 will have identical bodies. 83 It is also recognized that certain elements of the transport 84 (including, but not limited to, mail-news gateways, mailing list 85 reflectors, and newsgroup or mailing list moderators) might modify 86 existing message bodies and headers. The modification might be in 87 form only, such as the Content-Transfer-Encoding ([MIME]) of the body 88 being changed; or it might be substantive, such as a standard 89 disclaimer, or standard set of instructions, being appended to the 90 bodies. This means that software conforming to this document cannot 91 guarantee that the two messages will have identical bodies by the time 92 they reach their destinations. It can, however, hold that as a goal, 93 with the recognition that the goal will not always be reachable due to 94 forces beyond its control. (In other words, the authors believe that 95 transport and gateway software that so alters the message bodies is 96 generally wrong in so doing, while recognizing that sometimes it's a 97 choice between evils and imperfect preservation of the message may be 98 the best that can be done.) 100 2. Terminology 102 In this document, we will discuss several "views" on the same logical 103 message. 105 A "combined message" is a message for which the sender has chosen some 106 email destinations, as well as and some news destinations. When we are 107 talking about a combined message, we are either talking about it as it 108 appeared when composed, but before it was delivered; or we are talking 109 about both its mail and news aspects simultaneously. 111 When this document refers to a "mail message", it refers to a message 112 received by someone via email. In isolation, "mail message" could refer 113 to either a simple mail-only message, or to the version of a combined 114 message that was delivered by mail. 116 Likewise, unless otherwise specified, "news message" refers to a message 117 that was received by someone via news, and that may or may not also have 118 been mailed. 120 This document assumes familiarity with the mail and news message 121 formats, as documented in [MAIL] and [NEWS]. 123 3. Definitions of new message elements 125 3.1. The Posted-And-Mailed header 127 When a message is sent to both mail and news destinations, it MUST 128 include a Posted-And-Mailed header, with the value "yes": 130 posted-and-mailed = "Posted-And-Mailed:" [CFWS] ("yes" / "no") [CFWS] CRLF 132 The presence of this header indicates that the message conforms to this 133 document. If this header is absent, conformant software MUST assume that 134 the message in question DOES NOT conform to this document, and MUST NOT 135 treat the message as a combined message. If this header is present but 136 has a value other than "yes", conformant software MUST NOT treat the 137 message as a combined message. 139 This header MUST be present both in the version of the message which was 140 sent to a news transport, and in the version of the message which was 141 sent to a mail transport, and MUST be identical in both. 143 This header MAY be omitted in messages which are not combined messages. 144 This is a reasonable thing to do, because messages which do not have 145 that header MUST be assumed by receiving agents to be non-combined 146 messages. However, if this header is included in a non-combined 147 message, it MUST have the value "no". 149 3.2. The Followup-Host header 151 This header is optional. 153 If it is present, it is an instruction to the recipient about what news 154 host and protocol SHOULD be used to send a reply, should the recipient 155 desire to send a reply to any of the newsgroups listed in the 156 Followup-To or Newsgroups headers. 158 Background: 159 It is becoming more common for discussion forums to exist which are 160 for all practical purposes newsgroups, but which are served by only 161 one (or a small number of) hosts. They are not widely replicated. 163 The way one uses these groups is by connecting to a particular port 164 on a particular host and speaking a particular news protocol 165 (typically NNTP.) 167 This differs from the traditional USENET model, where one connects 168 to a local news server for all activity, and the messages are 169 propagated to many different hosts. 171 It is not the place of this document to discuss the pros or cons of 172 this mode of operation. However, this document recognizes that this 173 mode of operation exists, and defines a mechanism to deal with the 174 issues related to posted-and-mailed messages as relates these 175 non-USENET news hosts, as well as the more common USENET case. It 176 is noteworthy that other factors (such as Internet gateway 177 architectures which prohibit connectivity between "internal" 178 clients and "external" news hosts) might prevent the mechanism 179 from working as desired. 181 The Followup-Host header SHOULD be used when all newsgroups in the 182 Newsgroups and Followup-To headers are served by a single, non-USENET 183 news server. 185 It MUST NOT be used when the newsgroups in question use the traditional 186 USENET model of propagation: that is, newsgroups which are not ones that 187 are served only by a particular host. 189 The Followup-Host header is an instruction to use a particular host for 190 posting activity. Therefore, its use includes the assumption that the 191 recipients of the message will be able to post via the host in question. 193 It is recognized that even traditional USENET groups have varying levels 194 of propagation, and that there is no guarantee that any mail recipient 195 has access to any server which offers a particular USENET group. The 196 Followup-Host header is not intended to address this problem. 198 How the posting software makes the determination of whether the current 199 news server is a USENET-style server, or a non-USENET style server is 200 unspecified. It is left up to the implementor. If the client cannot 201 make that determination, then the client MUST assume that the newsgroup 202 is a USENET-style one, and therefore MUST NOT include a Followup-Host 203 header. 205 One possible way to make the determination would be for software which 206 was able to deal with multiple news hosts to remember which hosts were 207 USENET and which were not. A particular news agent might have a notion 208 of a "default" host, and assume that the default host was USENET, and 209 the non-default hosts were not. Another news agent might ask the user 210 to specify whether the host carried USENET at the time the user 211 connected to the host (or subscribed to a group carried by it.) 213 The body of the Followup-Host header is a URL, as defined by [NEWSURL]: 215 followup-host = "Followup-Host:" [CFWS] news-url [CFWS] CRLF 217 news-url = 219 The reason for providing a full URL rather than simply a host name is 220 that news service may not necessarily be provided by [NNTP]. URLs, 221 being extensible, provide an easy way to accommodate current and future 222 protocol innovations. 224 The header's contents could be as simple as: 226 Followup-Host: news://news.example.com/ 228 indicating the default news protocol (nntp) on the default nntp port 229 (TCP 119). An NNTP service running on a nonstandard port could be 230 expressed as 232 Followup-Host: news://news.example.com:6666/ 234 A news service running a protocol other than NNTP would be expressed by 235 using a different type of URL. For example, this header represents news 236 service running on the "snews" protocol (which is actually NNTP 237 wrapped inside of SSL): 239 Followup-Host: snews://secnews.netscape.com/ 241 It is beyond the scope of this document to document these protocols or 242 URL syntaxes. 244 3.3. The Author-Message-ID header 246 It is possible that the copy of a message that is submitted for 247 posting will not be posted without modification. (Such cases include 248 when a moderator or software adds body prolog, or reformats the 249 submission for readability.) For reasons discussed in section 3.4, it 250 would be inappropriate to allow both the submitted and the posted 251 version to have the same ID. However, this can create problems for 252 the submitter, causing such mechanisms as scoring based on replies to 253 break. 255 In the event that the message body is altered, the Author-Message-ID 256 header MUST be present, and populated with the submitted message's 257 Message-ID header. The Message-ID header MUST then be regenerated. 259 3.4. The message body prolog 261 When a message is sent to both mail and news recipients, the posting 262 software MAY choose to automatically include a free-text blurb at 263 beginning of the message body indicating that it has been posted as well 264 as mailed. 266 If this text is inserted, it MUST be inserted in BOTH the copy of the 267 message that is posted, and in the copy that is mailed. This is in 268 keeping with the guiding principle that two copies of the same message 269 MUST have the same Message-ID, and that, conversely, two messages with 270 the same Message-ID MUST have the same body. 272 Message reading software MUST NOT attempt to automatically parse or 273 otherwise interpret this body text. Such software should use the 274 appropriate message headers instead. This body text, like all body 275 text, is intended only for human consumption. 277 If the text is inserted, it SHOULD be kept brief: it is recommended that 278 it consist only of one or two lines of text. For example, 280 [[ This message was both posted and mailed. ]] 282 or perhaps 284 [[ This message was both posted and mailed: see 285 the `To' and `Newsgroups' headers for details. ]] 287 But note that more verbose prologs are allowed, if desired by the user 288 and/or the user's software. 290 Rationale: 291 The reason that a user or user-agent might want to insert a body 292 prolog at all is to draw attention to the fact that this is a 293 combined message. Historically, mail readers did not show the 294 Newsgroups header by default, and news readers did not show the To 295 and CC headers by default; therefore, it is likely that, in the 296 absence of the body prolog, a user might mistakenly assume that a 297 combined message was mailed only, or posted only. 299 The body prolog, if present, is largely redundant with the message 300 headers. This redundancy is called for due to their different uses: 301 the Posted-And-Mailed header is for interpretation by programs; the 302 body is for interpretation by humans. It is intended that when 303 support for the Posted-And-Mailed header becomes more widespread in 304 mail and news reading software, the use of the body prolog will 305 become unnecessary, and deprecated. 307 There are two reasons that the same text MUST be present in both 308 the mailed and posted copies, if it is present at all. 310 * The first reason is that it is a part of the message body; and 311 having two different messages, with different bodies, but with 312 the same Message-ID, would be a misuse of the Message-ID header. 313 Therefore, if it was desired that the bodies differ, then one 314 might conclude that the two different messages should have 315 different Message-IDs. However, it is HIGHLY desirable for the 316 two messages to have the same ID (as discussed in section 4.2, 317 "Message-ID".) Therefore, since the two messages MUST have the 318 same ID, they MUST have identical bodies. 320 Some might argue that the bodies are "substantially the same", 321 and that perhaps an exception should be made, and the two 322 messages with non-identical bodies should be allowed to have the 323 same Message-ID anyway. The problem with this is that it is a 324 slippery slope: it sets a bad precedent. Where would it end? 325 Should it be allowed for two messages to have the same ID if one 326 of them is in plain-text and the other is in HTML? If one 327 includes alternate forms of attached documents? If one has been 328 spell-checked and the other has not? If one is in English, and 329 the other is a translation into Spanish? And so on. 331 * The second reason is that the body prolog provides useful 332 information to all recipients, regardless of whether they 333 receive the message via news or mail. When one sends a mail 334 message To: Bob, and CC: Alice, one does not send Bob a message 335 that contains only a To field, and Alice a message that contains 336 only a CC field. Rather, one discloses the full set of 337 recipients to all recipients. 339 The rationale for having a body prolog at all is the assumption 340 that the message headers (To, CC, and Newsgroups) are not 341 sufficient to fully disclose the set of recipients of the 342 message, because readers will tend not to be shown those headers 343 by default. 345 If one accepts that the body prolog is necessary for full 346 disclosure of the set of recipients to a mail recipient, then 347 one must also accept that it is necessary for full disclosure to 348 a news recipient. 350 There is controversy over whether it is appropriate for a user agent 351 to insert this text at all, the argument against it being that any 352 attempt to impose structure on message bodies is both inappropriate, 353 and doomed to fail. 355 However, it is already the case that user agents are free to insert, 356 automatically or otherwise, any manner of text into message bodies: 357 for example, signature files, or "message templates." The reason 358 this document mentions the possibility of a body prolog which labels 359 combined messages is simply to ensure that conformant software which 360 DOES choose to insert such a blurb does so in both copies of the 361 message, not just one (for the reasons enumerated above.) 363 4. Clarifications of the semantics of existing headers 365 The general principle used here is that when a header is required in 366 either mail or news, a combined message should include both headers. 367 Combined with the principle that the same message text be delivered to 368 both transports, this means that certain previously-news-only headers 369 will be delivered over mail transports, and certain previously-mail-only 370 headers will be delivered over news transports. 372 When sending a message as both mail and news, that message MUST meet the 373 underlying requirements of both mail messages and news messages 374 simultaneously. 376 4.1. References and In-Reply-To 378 Messages which are delivered to both mail and news MUST use the news 379 [NEWS] syntax and semantics of the References header, since that RFC has 380 more restrictive (and, arguably, more useful) syntax and semantics than 381 does the mail message standard [MAIL]. 383 Messages which are delivered to both mail and news, and which are 384 replies, MUST have a References header. 386 If the Author-Message-ID header is present, messages sent in reply 387 MUST include it in the References header. 389 Messages which are delivered to both mail and news MAY include an 390 In-Reply-To header, with the semantics defined in [MAIL]. Should an 391 In-Reply-To header be used, it MUST contain the last message ID of the 392 References header (that is, the ID of the message to which this is a 393 reply.) 395 4.2. Message-ID 397 Messages which are delivered to both mail and news MUST have identical 398 Message-ID headers. 400 The syntax of the Message-ID header MUST be as defined in [NEWS], as 401 that is a more restrictive subset of the syntax defined in [MAIL]. 403 The Message-ID header is optional in [SMTP]. Generally, if the user 404 agent does not generate the Message-ID, then the transport will 405 generate one for the message. (This is typically true in the case of 406 both news and mail. It is noteworthy that this is not a requirement 407 for news hosts. Those that will behave this way go beyond the 408 specification.) 410 Since allowing the server(s) to generate the IDs would cause the use of 411 two different Message-IDs, in order to comply with this rule, a client 412 will probably need to generate the Message-ID before handing the message 413 to either transport. 415 (It is conceivable that some future message submission protocol might 416 allow the client to ask the server to generate and return a Message-ID 417 for it, but this is not possible with any of the currently-existing 418 message submission protocols. So, the requirement is that the two 419 copies of the message MUST have identical Message-IDs, but any 420 mechanism which achieves this end is acceptable.) 422 Rationale: 423 The requirement that the Message-IDs be identical is to make it 424 possible for a recipient of a combined message to reply to it and 425 generate a correct, usable References header. 427 For example: if a Bob sends a combined message to a newsgroup and 428 CCs the message to Alice by mail, Alice might want to reply in 429 public, rather than in private: she might want to post her reply to 430 the same newsgroup. If Bob uses the same Message-ID on both, that 431 works. But, if Bob uses two different message IDs, then the message 432 ID in Alice's References header will be different depending on 433 whether she replies to the mailed copy or the posted copy. If she 434 replies to the mailed copy, her new news message will mention an ID 435 in its References field which is not present in the newsgroup. 436 Therefore, the news thread will be fractured. 438 Similar fracturing effects can occur in mail, when combined messages 439 are delivered to multiple mail recipients, or to newsgroups. 441 4.3. Followup-To 443 If both Posted-And-Mailed (with value "yes") and Followup-To are 444 present, then replies which are to be posted MUST be directed to the 445 newsgroups listed in the Followup-To header by default. 447 If a Followup-To header is present but a Posted-And-Mailed header is not 448 (or has a value other than "yes"), then: 450 * For a news message, the proper interpretation is defined by [NEWS]. 452 * For a mail message, the Followup-To header MUST be ignored. 454 4.4. Newsgroups 456 If the Posted-And-Mailed header is present and has the value "yes", then 457 the Newsgroups header MUST also be present. In that case, the 458 Newsgroups header has the semantics defined by [NEWS]: it lists the 459 newsgroups to which this message was posted. This is true regardless of 460 whether the message in question is the mailed copy or the posted copy: 461 the Newsgroups header has the same semantics in both copies. 463 If a Newsgroups header is present but the Posted-And-Mailed header is 464 not, or if the Posted-And-Mailed header has some value other than "yes": 466 * For a news message, the proper interpretation is defined by [NEWS]. 468 * For a mail message, the Newsgroups header MUST be ignored. 470 Rationale: 471 The requirement to ignore lone Newsgroups headers in mail messages 472 is an important one. Existing practice does not allow one to make 473 any assumptions about the interpretation of the Newsgroups header in 474 mail, as there are two widely used, conflicting interpretations of 475 it: some message-generating software uses it as an indication that 476 this mail message was also posted (for example, Gnus, Pine, and 477 Netscape); and some message-generating software uses it as an 478 indication of the groups to which the message to which this message 479 is a reply was posted (for example, rn and its direct descendants 480 like trn and slrn.) 482 Therefore, one MUST NOT interpret the Newsgroups header in a mail 483 message unless that message is known to be in conformance with this 484 document: unless there is a Posted-And-Mailed header in the message, 485 the semantics of the Newsgroups header is undefined (and unsafe.) 486 If there is a Posted-And-Mailed header, then the semantics of the 487 Newsgroups header IS defined: by this document. 489 5. Security considerations 491 This format will reduce the risk of various unexpected results for 492 combined messages. Some existing risks in email and news may stay even 493 with this format, but no new risks are expected as a result of using 494 this format. In general, increased transportation of messages between 495 news and email may mean that existing risks in news are propagated to 496 email or the reverse, but these risks would not be reduced by the lack 497 of a standard for such combined messages. 499 The union of the security and privacy risks of existing mail and news 500 usage must be considered; for example, care should be taken not to 501 inappropriately disclose the BCC recipients of a mailed message to the 502 news recipients. 504 6. Acknowledgments 506 This document is derived from and inspired by earlier proposals written 507 by Jacob Palme and John Stanley. Valuable feedback was provided by 508 Terje Bless, Stefan Haller, Lars Magne Ingebrigtsen, John Moreno, Jacob 509 Palme, Pete Resnick, Bart Schaefer, Jeroen Scheerder, Brad Templeton, 510 and Curtis Whalen. 512 7. References 514 Ref. Author, title IETF status (June 1998) 515 ---------------------- 516 --- ------------- 518 [SMTP] J. Postel: "Simple Mail Transfer Standard, Recommended. 519 Protocol", STD 10, RFC 821, August 520 1982. 522 [MAIL] D. Crocker: "Standard for the Standard, Recommended. 523 format of ARPA Internet text 524 messages." STD 11, RFC 822, August 525 1982. 527 [NNTP] B. Kantor, P. Lapsley: "Network Non-standard (but still 528 News Transfer Protocol", RFC 977, widely used as a de-facto 529 February 1986. standard). 531 [NEWS] M.R. Horton, R. Adams: "Standard Non-standard (but still 532 for interchange of USENET widely used as a de-facto 533 messages", RFC 1036, December standard). 534 1987. 536 [MIME] N. Freed, N. Borenstein and Draft Standard, elective. 537 others, "Multipurpose Internet 538 Mail Extensions (MIME) Part One to 539 Five", RFC 2045 to 2049. 541 [NEWSURL] T. Berners-Lee, L. Masinter and Draft Standard. 542 others, "Uniform Resource Locators", 543 RFC 1738. 545 See also: 546 A. Gilman, "The 'news' URL scheme", Internet Draft, work in 547 draft-gilman-news-url-01.txt. progress. 549 [USEFOR] D. Ritter, "News Article Format", Internet Draft, work in 550 draft-ietf-usefor-article-00.txt. progress. 552 8. Authors' Addresses 554 Matt Curtin 555 The Ohio State University 556 791 Dreese Laboratories 557 2015 Neil Ave 558 Columbus OH 43210 559 +1 614 292 7352 560 cmcurtin@cis.ohio-state.edu 562 Jamie Zawinski 563 Netscape Communications Corporation 564 501 East Middlefield Road 565 Mountain View, CA 94043 566 (650) 937-2620 567 jwz@netscape.com 569 Appendix A: Examples 571 The following is an example of a combined message, sent both to a 572 newsgroup comp.lang.c and via e-mail to a person bob@foo.example.com. 574 Here is the message as prepared by the message composition software: 576 Date: 7 Jan 1997 12:34:21 +0000 (GMT) 577 From: alice@bar.example.com 578 Subject: language or grade 579 Message-ID: <123zx@example.com> 580 To: bob@foo.example.com 581 Newsgroups: comp.lang.c 582 Posted-And-Mailed: yes 584 Which is it? 586 The same message as it might be received by someone reading it in the 587 newsgroup comp.lang.c: 589 Path: news1.example.com!news2.example.com!bar.example.com!alice 590 NNTP-Posting-Host: news2.example.com 591 Xref: news.blat.example.com comp.lang.c:20465 592 Lines: 1 593 Date: 7 Jan 1997 12:34:21 +0000 (GMT) 594 From: alice@bar.example.com 595 Subject: language or grade 596 Message-ID: <123zx@example.com> 597 To: bob@foo.example.com 598 Newsgroups: comp.lang.c 599 Posted-And-Mailed: yes 601 Which is it? 603 The same message as it might be received by a mail recipient 604 (presumably bob@foo.example.com): 606 Return-Path: 607 Received: from foo.example.com [127.0.0.1] by quux.example.com 608 Received: from quux.example.com [127.0.0.1] by bar.example.com 609 Date: 7 Jan 1997 12:34:21 +0000 (GMT) 610 From: alice@bar.example.com 611 Subject: language or grade 612 Message-ID: <123zx@example.com> 613 To: bob@foo.example.com 614 Newsgroups: comp.lang.c 615 Posted-And-Mailed: yes 617 Which is it?