Internet DRAFT - draft-attachment-notification
draft-attachment-notification
INTERNET-DRAFT
Document: <draft-attachment-notification-01.txt>
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 <bob@example.net> , Alice <alice@example.net>
Subject: Picture of my lawn
Notify-To: Joe <joe@example.net>
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]
