Network Working Group C. Whalen Internet Draft Diamond Plus Software Development Updates: 2183 September 1997 Category: Experimental Communicating Information for External Program Use in Internet Messages: The Process Content-Disposition Type <draft-rfced-exp-whalen-00.txt> Status of This Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey information not intended for display by the Mail User Agent (UA), but for processing (as opposed to display) by an external program. It specifies a new type of 'Content-Disposition' (defined by [RFC 2183]), which is valid for any MIME entity ('message' or 'body part). When 'body part' is referred to in this memo, it is referring to any MIME entity, except in section 2.4. This memo is the definition of this type, as specified by Section 9 of [RFC 2183]. This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, [RFC 822], and [RFC 2183]. The information presented herein supplements but does not replace that found in those documents. 1. Introduction MIME specifies a standard format for encapsulating multiple pieces of data into a single Internet message. That document does not address the issue of transferring information to be processed by a non-user agent program via Internet Mail; it provides a framework for the interchange of message content. Note: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC 2119]. Whalen Experimental [Page 1]
I/D Process Content-Disposition September 1997 2. The Process Type - Additions to BNF In the extended BNF notation of [RFC 822], the Content-Disposition header field is extended as follows: disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type := "inline" / "attachment" / "process" / extension-token ; values are not case-sensitive ; "inline" and "attachment" and parameters ; associated with them or otherwise not ; mentioned here are defined in [RFC 2183] disposition-parm := filename-parm / creation-date-parm / modification-date-parm / read-date-parm / size-parm / program-parm / parameter program-parm := "program" "=" quoted-string NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters) parameter value containing only non-`tspecials' characters SHOULD be represented as a single `token'. A short parameter value containing only ASCII characters, but including `tspecials' characters, SHOULD be represented as `quoted-string'. Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184]. `Extension-token', `parameter', `tspecials' and `value' are defined according to [RFC 2045] (which references [RFC 822] in the definition of some of these tokens). `quoted-string' and `DIGIT' are defined in [RFC 822]. Whalen Experimental [Page 2]
I/D Process Content-Disposition September 1997 2.1 The Process Disposition Type A bodypart should be marked "process" if it is intended to be acted on (as opposed to just being displayed or played) by an external program upon receipt or display of the message. "Process" bodyparts should be acted upon in the order in which they occur, subject to the normal semantics of multipart messages. All parameters to this disposition type MUST be passed to the external program, as well as the Content-Type: header line and all parameters that it has. External programs implementing this memo are RECOMMENDED to require that a separate mailbox be used to receive and send messages complying with this document. 2.2 The Program Parameter The sender may want to name the program and possibly version of that program to process a body part. The Content-Type of a body part SHOULD be used to identify which program will be executed on the receiving end, however, this parameter could be used to identify different programs able to process the same Content-Type. This parameter SHOULD be used for validation of the fact that the external program called can process this body part. 2.3 Other Usable Parameters The Creation-Date, Modification-Date, Read-Date, and Size parameters are OPTIONAL, and may or may not be usable with a particular external program used. The Filename parameter SHOULD NOT be used with the "process" disposition type. If it is used, the security risks mentioned in [RFC 2183] apply. 2.4 The "Process" Content-Disposition Type and Multipart If a "process" Content-Disposition type is used on a multipart body part, it makes "process" the default Content-Disposition of all individual subparts. The disposition types of the subparts need to be consulted when the multipart is processed, and when the multipart is displayed, then the dispositions of the un-"process"ed subparts should be respected. Implementations MAY display the portion of the message before the first boundary line, MUST ignore message portions without a Content-Type header, MUST ignore message portions with a text/plain Content-Type header, and MUST ignore the portion of the message after the last boundary line. Implementations MUST ignore message parts with a Content-Type that they do not understand. Implementations also MUST NOT process message parts that specify a different Content-Disposition, but MAY display them as appropriate. Whalen Experimental [Page 3]
I/D Process Content-Disposition September 1997 2.5 The "Process" Content-Disposition Type and the Text Body Part It is NOT RECOMMENDED to use the "process" Content-Disposition with Content-Types beginning with text, due to the possible destructive data in these types of content. 2.6 The "Process" Content-Disposition Type and the Main Message It is permissible to use the "process" Content-Disposition type on the main body of an [RFC 822] message, as long as there is a specified Content-Type. 3. Examples Here is a an example of a multipart/mixed body containing 2 [RFC 1036] Usenet News messages that are intended to be processed by a newsgroup moderation robot. Note that the second message has a Content-Type of text/plain with quoted-printable encoding, so that the message/news content type can still be 7bit. Content-Type: multipart/mixed; boundary="=_e-postero.05551212_=_" Content-Disposition: process This can be displayed by the moderation robot. --=_e-postero.05551212_=_ Content-Type: message/news Content-Transfer-Encoding: 7bit <message header/data> --=_e-postero.05551212_=_ Content-Type: message/news Content-Transfer-Encoding: 7bit <message header> Content-Type: text/plain; charset="ISO-8859-3" Content-Transfer-Encoding: quoted-printable <message body> --=_e-postero.05551212_=_ This is ignored by the moderation robot. Whalen Experimental [Page 4]
I/D Process Content-Disposition September 1997 The following body part contains a request for scheduling an event in the user's calendar in a peraonal information management program. The program requested (PIM 1.01), any future versions, and any compatible programs could parse the data in the body out that they use and either incorporate it in the receiver's calendar data or refuse to do so. Other programs will ignore this message. Content-Type: application/vnd.imaginary.pim Content-Disposition: process; program="PIM/1.01" Content-Description: Programmer's Group Meeting <scheduling data> 4. Security Considerations There are security issues involved any time users exchange data, especially when this data is supposed to be processed by another program. Since this memo provides a way to automatically execute another program and/or pass invalid or destructive data to another program, a receiving UA MUST take care that the execution or interpretation requested through this parameter does not happen without the user's explicit permission, and SHOULD validate the data passed, if possible. The program executed MUST also take care that no destructive actions can be performed through this method of data input. If the receiving UA and the external program to be executed to process the message are one and the same, (e.g. a newsgroup moderation robot) it SHOULD validate the data received and MUST make sure that no destructive actions can be performed. Running this type of UA fulfills the requirement for explicit permission from the user. Implementors MUST be alert to the potential hazards on their target systems. 5. References [RFC 2183] Troost, R. et. al., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2184] Freed, N. and K. Moore, "MIME Parameter value and Encoded Words: Character Sets, Lanaguage, and Continuations", RFC 2184, August 1997. Whalen Experimental [Page 5]
I/D Process Content-Disposition September 1997 [RFC 2045] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. [RFC 2046] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, December 1996. [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for non-ASCII Text", RFC 2047, December 1996. [RFC 2048] Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose Internet Mail Extensions) Part Four: Registration Procedures", RFC 2048, December 1996. [RFC 2049] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996. [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. 6. Author's Address Curtis Whalen Diamond Plus Software Development 2850 Shady Lane Poplar Bluff MO 63901-2117 USA Phone: +1 (573) 778-0980 Email: diamondplus@iname.com INTERNET DRAFT EXPIRE MARCH 1998 INTERNET DRAFT