[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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