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]