draft-ietf-usefor-posted-mailed-00.txt   draft-ietf-usefor-posted-mailed-01.txt 
Internet Draft Matt Curtin Internet Draft Matt Curtin
draft-ietf-usefor-posted-mailed-00.txt The Ohio State University draft-ietf-usefor-posted-mailed-01.txt The Ohio State University
Category-to-be: Proposed standard Jamie Zawinski Category-to-be: Proposed standard Jamie Zawinski
Netscape Communications Netscape Communications
June 1998 July 1998
Expires: Six Months from above date Expires: Six Months from above date
Identification of messages delivered via both mail and news Identification of messages delivered via both mail and news
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
(US West Coast).
Abstract Abstract
This draft defines a format to be used when delivering a single message This draft defines a format to be used when delivering a single message
to multiple destinations, where some destinations are newsgroups and to multiple destinations, where some destinations are newsgroups and
some destinations are email mailboxes. some destinations are email mailboxes.
Table of contents Table of contents
1. Introduction 1. Introduction
2. Terminology 2. Terminology
3. Definitions of new message elements 3. Definitions of new message elements
3.1. The Posted-And-Mailed header 3.1. The Posted-And-Mailed header
3.2. The Followup-Host header 3.2. The Followup-Host header
3.3. The Author-Message-ID header 3.3. The message body prolog
3.4. The message body prolog
4. Clarifications of the semantics of existing headers 4. Clarifications of the semantics of existing headers
4.1. References and In-Reply-To 4.1. References and In-Reply-To
4.2. Message-ID 4.2. Message-ID
4.3. Followup-To 4.3. Followup-To
4.4. Newsgroups 4.4. Newsgroups
5. Security considerations 5. Security considerations
6. Acknowledgments 6. Acknowledgments
7. References 7. References
8. Authors' Addresses 8. Authors' Addresses
Appendix A: Examples Appendix A: Examples
skipping to change at line 229 skipping to change at line 226
The reason for providing a full URL rather than simply a host name is The reason for providing a full URL rather than simply a host name is
that news service may not necessarily be provided by [NNTP]. URLs, that news service may not necessarily be provided by [NNTP]. URLs,
being extensible, provide an easy way to accommodate current and future being extensible, provide an easy way to accommodate current and future
protocol innovations. protocol innovations.
The header's contents could be as simple as: The header's contents could be as simple as:
Followup-Host: news://news.example.com/ Followup-Host: news://news.example.com/
indicating the default news protocol (nntp) on the default nntp port indicating the default news protocol (NNTP) on the default nntp port
(TCP 119). An NNTP service running on a nonstandard port could be (TCP 119). An NNTP service running on a nonstandard port could be
expressed as expressed as
Followup-Host: news://news.example.com:6666/ Followup-Host: news://news.example.com:6666/
A news service running a protocol other than NNTP would be expressed by A news service running a protocol other than NNTP would be expressed by
using a different type of URL. For example, this header represents news using a different type of URL. For example, this header represents news
service running on the "snews" protocol (which is actually NNTP service running on the "snews" protocol (which is actually NNTP
wrapped inside of SSL): wrapped inside of SSL):
Followup-Host: snews://secnews.netscape.com/ Followup-Host: snews://secnews.netscape.com/
It is beyond the scope of this document to document these protocols or It is beyond the scope of this document to document these protocols or
URL syntaxes. URL syntaxes.
3.3. The Author-Message-ID header 3.3. The message body prolog
It is possible that the copy of a message that is submitted for
posting will not be posted without modification. (Such cases include
when a moderator or software adds body prolog, or reformats the
submission for readability.) For reasons discussed in section 3.4, it
would be inappropriate to allow both the submitted and the posted
version to have the same ID. However, this can create problems for
the submitter, causing such mechanisms as scoring based on replies to
break.
In the event that the message body is altered, the Author-Message-ID
header MUST be present, and populated with the submitted message's
Message-ID header. The Message-ID header MUST then be regenerated.
3.4. The message body prolog
When a message is sent to both mail and news recipients, the posting When a message is sent to both mail and news recipients, the posting
software MAY choose to automatically include a free-text blurb at software MAY choose to automatically include a free-text blurb at
beginning of the message body indicating that it has been posted as well beginning of the message body indicating that it has been posted as well
as mailed. as mailed.
If this text is inserted, it MUST be inserted in BOTH the copy of the If this text is inserted, it MUST be inserted in BOTH the copy of the
message that is posted, and in the copy that is mailed. This is in message that is posted, and in the copy that is mailed. This is in
keeping with the guiding principle that two copies of the same message keeping with the guiding principle that two copies of the same message
MUST have the same Message-ID, and that, conversely, two messages with MUST have the same Message-ID, and that, conversely, two messages with
skipping to change at line 414 skipping to change at line 396
The Message-ID header is optional in [SMTP]. Generally, if the user The Message-ID header is optional in [SMTP]. Generally, if the user
agent does not generate the Message-ID, then the transport will agent does not generate the Message-ID, then the transport will
generate one for the message. (This is typically true in the case of generate one for the message. (This is typically true in the case of
both news and mail. It is noteworthy that this is not a requirement both news and mail. It is noteworthy that this is not a requirement
for news hosts. Those that will behave this way go beyond the for news hosts. Those that will behave this way go beyond the
specification.) specification.)
Since allowing the server(s) to generate the IDs would cause the use of Since allowing the server(s) to generate the IDs would cause the use of
two different Message-IDs, in order to comply with this rule, a client two different Message-IDs, in order to comply with this rule, a client
will probably need to generate the Message-ID before handing the message will probably need to generate the Message-ID before handing the message
to either transport. to either transport. Some suggestions for good client-side Message-ID
generation are offered in [MSGID].
(It is conceivable that some future message submission protocol might (It is conceivable that some future message submission protocol might
allow the client to ask the server to generate and return a Message-ID allow the client to ask the server to generate and return a Message-ID
for it, but this is not possible with any of the currently-existing for it, but this is not possible with any of the currently-existing
message submission protocols. So, the requirement is that the two message submission protocols. So, the requirement is that the two
copies of the message MUST have identical Message-IDs, but any copies of the message MUST have identical Message-IDs, but any
mechanism which achieves this end is acceptable.) mechanism which achieves this end is acceptable.)
Rationale: Rationale:
The requirement that the Message-IDs be identical is to make it The requirement that the Message-IDs be identical is to make it
skipping to change at line 551 skipping to change at line 534
[NEWSURL] T. Berners-Lee, L. Masinter and Draft Standard. [NEWSURL] T. Berners-Lee, L. Masinter and Draft Standard.
others, "Uniform Resource Locators", others, "Uniform Resource Locators",
RFC 1738. RFC 1738.
See also: See also:
A. Gilman, "The 'news' URL scheme", Internet Draft, work in A. Gilman, "The 'news' URL scheme", Internet Draft, work in
draft-gilman-news-url-01.txt. progress. draft-gilman-news-url-01.txt. progress.
[USEFOR] D. Ritter, "News Article Format", Internet Draft, work in [USEFOR] D. Ritter, "News Article Format", Internet Draft, work in
draft-ietf-usefor-article-00.txt. progress. draft-ietf-usefor-article-01.txt. progress.
[MSGID] M. Curtin and J. Zawinski, Internet Draft,
"Recommendations for generating work in progress
Message-IDs",
draft-ietf-usefor-message-id-01.txt.
8. Authors' Addresses 8. Authors' Addresses
Matt Curtin Matt Curtin
The Ohio State University The Ohio State University
791 Dreese Laboratories 791 Dreese Laboratories
2015 Neil Ave 2015 Neil Ave
Columbus OH 43210 Columbus OH 43210
+1 614 292 7352 +1 614 292 7352
cmcurtin@cis.ohio-state.edu cmcurtin@cis.ohio-state.edu
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/