INTERNET-DRAFT Document: Expires: April 2004 H. Murthy SJCE.NET October 2003 Mechanism to send notification of attachment details to select recipients of an address list in an email message, while the other recipients of the address list are sent the actual attachment. Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The motivation for this memo stems from a need not to inundate the mailboxes of recipients with attachments, when all they need is a notification with the details of the attachment and the list of recipients that the attachment was sent to. Also, the recipients of the attachment would in their email copy get the details of list of notified recipients. A use case would be where Joe sends an email with an attachment to Bill, and Bill in turn adds some comments to the body of the message, and has to send it to Bob and Joe with the attachment, In this case, Joe ends up having two emails with the same attachment. This memo provides a mechanism whereby messages conforming to the [RFC 2822] ("Internet Message Format") specification can convey extra information. It specifies a new set of "Attachment-Notification" headers, optional and valid for any [RFC 2822] entity ("message" or "body part"). This document is intended as an extension to [RFC 2822]. As such, the reader is assumed to be familiar with [RFC 2822] and [RFC 2045]-[RFC 2049]. The information presented herein supplements but does not replace that found in those documents. Murthy Expires April 2004 [Page 1] Internet Draft Attachment Notification Headers October 2003 1. Introduction [RFC 2045]-[RFC 2049] specifies a standard format for encapsulating multiple pieces of data into a single Internet message. It caters to mechanism where all recipients get a copy of the exact message. There are times when a sender desires to send an attatchment to some recipients on an address-list, while notifying other recipients only of the details of the attachment. A mechanism is needed to allow the sender to transmit this information to the recipient;the headers provides this mechanism. This document does not address the issue of presentation styles, it provides a mechanism for exchange of information, and leaves the presentation issues solely in the hands of the mail user agent( MUA) implementers. 2. Field definitions The header fields of a message are defined here. All header fields have the same general syntactic structure: A field name, followed by a colon, followed by the field body. The specific syntax for each header field is defined in the subsequent sections. 2.1 Destination address fields As mentioned in [RFC 2822], the destination fields of a message consist of three entries, each of the same form: The field name, which is either "To","Cc" or "Bcc", followed by a comma separated list of one or more addresses( either mailbox or group syntax). to = "To:" address-list CRLF cc = "Cc:" address-list CRLF bcc = "Bcc" (address-list / [CFWS]) CRLF The meanings of the above are mentioned in 3.6.3 of [RFC 2822]. 2.2 Attachment Notification destination address fields The below destination fields of a message consist of three possible fields, each of the same form: The field name, which is either "Notify-To", "Notify-Cc", or "Notify-Bcc", followed by a comma-separated list of one or more addresses (either mailbox or group syntax). Notify-to = "Notify-To:" address-list CRLF Notify-cc = "Notify-Cc:" address-list CRLF Notify-bcc = "Notify-Bcc:" (address-list / [CFWS]) CRLF Murthy Expires April 2004 [Page 2] Internet Draft Attachment Notification Headers October 2003 The Attachment notification destination fields specify the recipients of the notification message. Each destination field may have one or more addresses, and each of the addresses indicate the intended recipients of the notification message. The only difference between the three fields is how each is used. The "Notify-To:" field contains the address(es) of the primary recipient(s) of the notification message. The "Notify-Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a copy on a typewriter using carbon paper) contains the addresses of others who are to receive the message, though the content of the notification message may not be directed at them. The "Notify-Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses of recipients of the notification message whose addresses are not to be revealed to other recipients of the message. There are three ways in which the "Notify-Bcc:" field is used. In the first case, when a message containing a "Notify-Bcc:" field is prepared to be sent, the "Notify-Bcc:" line is removed even though all of the recipients (including those specified in the "Notify-Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "Notify-To:" and "Notify-Cc:" lines each are sent a copy of the message with the "Notify-Bcc:" line removed as above, but the recipients on the "Notify-Bcc:" line get a separate copy of the message containing a "Notify-Bcc:" line. (When there are multiple recipient addresses in the "Notify-Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Notify-Bcc:" containing only the address of that particular recipient.) Finally, since a "Notify-Bcc:" field may contain no addresses, a "Notify-Bcc:" field can be sent without any addresses indicating to the recipients that blind copies were sent to someone. Which method to use with "Notify-Bcc:" fields is implementation dependent. 3. Attachment Notification Description header field The Attachment Notification Description header field is optional, in its absence, the MUA may use whatever description method it deems suitable. In the extended BNF notation of [RFC 822], the Attachment Notification Description header field is defined as follows: Attachment-Notification-Description := " Attachment-Notification-Description " ":" unstructred CRLF As mentioned above, this header can be unstructured, which is defined in [RFC 2822]. One possible values is a descriptive filename of the Attachment, Murthy Expires April 2004 [Page 3] Internet Draft Attachment Notification Headers October 2003 4. Attachment Notification Checksum header field The Attachment Notification Checksum header field is optional, In its absence, the MUA may use whatever checksum method it deems suitable. In the extended BNF notation of [RFC 822], the Attachment Notification Description header field is defined as follows: Attachment-Notification-Checksum:= "Attachment-Notification-Checksum" ":" Attachment-Checksum CRLF Attachment-Checksum := Checksum-Algorithm":"Checksum-Value Checksum-Algorithm := unstructured Checksum-Value := 1*DIGIT The Checksum-Algorithm could be any of the checksum generating algorithms, the most popular being "MD5". The Checksum-Value is the checksum value of the attachment computed using the algorithm mentioned in Checksum-Algorithm. 5. Example Bob and Alice are sent the attachment, but Joe is just sent the notification of the attachment. The sender of the email is sending a PNG image to be viewed by Bob and Alice. Only the headers of relevance to this memo are shown in the example. ---- To: Bob , Alice Subject: Picture of my lawn Notify-To: Joe Attachment-Notification-Description: Picture of Lawn Attachment-Notification-Description: MD5:1202 Hi Guys, Am attaching the picture of my lawn that I had sent to Joe ---- 6. Security Considerations There are security issues involved any time users exchange data. While these are not to be minimized, neither does this memo change the status quo in that regard. Murthy Expires April 2004 [Page 5] Internet Draft Attachment Notification Headers October 2003 7. References [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC 1806] R. Troost,S.Dorner,"Communicating Presentation Information in Internet Messages:The Content-Disposition Header" [RFC 2822] P. Resnick, Editor,"Internet Message Format" [RFC 2045] N. Freed,N. Borenstein,"Multipurpose Internet Mail Extensions, Part 1: Format of Internet Message Bodies" [RFC 2046] N. Freed,N. Borenstein,"Multipurpose Internet Mail Extensions, Part 2: Media Types" [RFC 2047] K. Moore,"Multipurpose Internet Mail Extensions, Part 3: Message Header Extensions for Non-ASCII Text" [RFC 2048] N. Freed,J. Klensin,J. Postel,"Multipurpose Internet Mail Extensions, Part 4: Registration Procedures" [RFC 2049] N. Freed,N. Borenstein,"Multipurpose Internet Mail Extensions, Part 5: Conformance Criteria and Examples" 8. Acknowledgements I gratefully acknowledge the help these people provided during the preparation of this draft: John Jorgensen 9. Authors' Addresses Harish Murthy 185, Freeman Street,Apt 651 Brookline, MA 02446 Email: harishm@ieee.org Fax: +1-240-757-6081 Murthy Expires April 2004 [Page 5]