home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-exp-whalen-00.txt < prev    next >
Text File  |  1997-09-22  |  13KB  |  346 lines
  1. Network Working Group                                          C. Whalen
  2. Internet Draft                       Diamond Plus Software Development
  3. Updates: 2183                                             September 1997
  4. Category: Experimental
  5.  
  6.            Communicating Information for External Program Use
  7.                          in Internet Messages:
  8.                  The Process Content-Disposition Type
  9.                 <draft-rfced-exp-whalen-00.txt>
  10.  
  11.  
  12. Status of This Memo
  13.  
  14. This document is an Internet-Draft.  Internet-Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its
  16. areas, and its working groups.  Note that other groups may also
  17. distribute working documents as Internet-Drafts.
  18.  
  19. Internet-Drafts are draft documents valid for a maximum of six
  20. months and may be updated, replaced, or obsoleted by other
  21. documents at any time.  It is inappropriate to use Internet-
  22. Drafts as reference material or to cite them other than as
  23. "work in progress."
  24.  
  25. To learn the current status of any Internet-Draft, please check
  26. the "1id-abstracts.txt" listing contained in the Internet-
  27. Drafts Shadow Directories on ftp.is.co.za (Africa),
  28. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  29. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  30.  
  31. Distribution of this document is unlimited.
  32.  
  33.  
  34. Abstract
  35.  
  36.    This memo provides a mechanism whereby messages conforming to the
  37.    MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
  38.    2049] can convey information not intended for display by the Mail
  39.    User Agent (UA), but for processing (as opposed to display) by an
  40.    external program.  It specifies a new type of 'Content-Disposition'
  41.    (defined by [RFC 2183]), which is valid for any MIME entity 
  42.    ('message' or 'body part).  When 'body part' is referred to in this
  43.    memo, it is referring to any MIME entity, except in section 2.4. This
  44.    memo is the definition of this type, as specified by Section 9 of 
  45.    [RFC 2183].
  46.  
  47.    This document is intended as an extension to MIME.  As such, the
  48.    reader is assumed to be familiar with the MIME specifications,
  49.    [RFC 822], and [RFC 2183].  The information presented herein 
  50.    supplements but does not replace that found in those documents.
  51.  
  52. 1.  Introduction
  53.  
  54.    MIME specifies a standard format for encapsulating multiple pieces of
  55.    data into a single Internet message. That document does not address
  56.    the issue of transferring information to be processed by a non-user 
  57.    agent program via Internet Mail; it provides a framework for the
  58.    interchange of message content. 
  59.  
  60.    Note: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 
  61.    SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
  62.    in this document, are to be interpreted as described in [RFC 2119].
  63.  
  64.  
  65.  
  66.  
  67.  
  68. Whalen                        Experimental                          [Page 1]
  69.  
  70. I/D              Process Content-Disposition             September 1997
  71.  
  72. 2.  The Process Type - Additions to BNF
  73.  
  74.    In the extended BNF notation of [RFC 822], the Content-Disposition
  75.    header field is extended as follows:
  76.  
  77.      disposition := "Content-Disposition" ":"
  78.                     disposition-type
  79.                     *(";" disposition-parm)
  80.  
  81.      disposition-type := "inline"
  82.                        / "attachment"
  83.                        / "process"
  84.                        / extension-token
  85.                        ; values are not case-sensitive
  86.                        ; "inline" and "attachment" and parameters
  87.                        ; associated with them or otherwise not 
  88.                        ; mentioned here are defined in [RFC 2183]
  89.  
  90.      disposition-parm := filename-parm
  91.                        / creation-date-parm
  92.                        / modification-date-parm
  93.                        / read-date-parm
  94.                        / size-parm
  95.                        / program-parm
  96.                        / parameter
  97.  
  98.      program-parm := "program" "=" quoted-string
  99.  
  100.    NOTE ON PARAMETER VALUE LENGTHS: A short (length <= 78 characters)
  101.    parameter value containing only non-`tspecials' characters SHOULD be
  102.    represented as a single `token'.  A short parameter value containing
  103.    only ASCII characters, but including `tspecials' characters, SHOULD
  104.    be represented as `quoted-string'.  Parameter values longer than 78
  105.    characters, or which contain non-ASCII characters, MUST be encoded as
  106.    specified in [RFC 2184].
  107.  
  108.    `Extension-token', `parameter', `tspecials' and `value' are defined
  109.    according to [RFC 2045] (which references [RFC 822] in the definition
  110.    of some of these tokens).  `quoted-string' and `DIGIT' are defined in
  111.    [RFC 822].
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126. Whalen                        Experimental                          [Page 2]
  127.  
  128. I/D              Process Content-Disposition             September 1997
  129.  
  130.  
  131. 2.1  The Process Disposition Type
  132.  
  133.    A bodypart should be marked "process" if it is intended to be
  134.    acted on (as opposed to just being displayed or played) by an 
  135.    external program upon receipt or display of the message. "Process"
  136.    bodyparts should be acted upon in the order in which they occur,
  137.    subject to the normal semantics of multipart messages. All 
  138.    parameters to this disposition type MUST be passed to the external
  139.    program, as well as the Content-Type: header line and all parameters
  140.    that it has.
  141.  
  142.    External programs implementing this memo are RECOMMENDED to require
  143.    that a separate mailbox be used to receive and send messages 
  144.    complying with this document.   
  145.  
  146. 2.2  The Program Parameter
  147.  
  148.    The sender may want to name the program and possibly version of that
  149.    program to process a body part. The Content-Type of a body part 
  150.    SHOULD be used to identify which program will be executed on the 
  151.    receiving end, however, this parameter could be used to identify 
  152.    different programs able to process the same Content-Type. This 
  153.    parameter SHOULD be used for validation of the fact that the 
  154.    external program called can process this body part.
  155.  
  156. 2.3  Other Usable Parameters
  157.  
  158.    The Creation-Date, Modification-Date, Read-Date, and Size parameters
  159.    are OPTIONAL, and may or may not be usable with a particular 
  160.    external program used. The Filename parameter SHOULD NOT be used 
  161.    with the "process" disposition type. If it is used, the security
  162.    risks mentioned in [RFC 2183] apply.
  163.  
  164. 2.4  The "Process" Content-Disposition Type and Multipart
  165.  
  166.    If a "process" Content-Disposition type is used on a multipart 
  167.    body part, it makes "process" the default Content-Disposition of all
  168.    individual subparts. The disposition types of the subparts need to 
  169.    be consulted when the multipart is processed, and when the multipart
  170.    is displayed, then the dispositions of the un-"process"ed subparts
  171.    should be respected.
  172.  
  173.    Implementations MAY display the portion of the message before the 
  174.    first boundary line, MUST ignore message portions without a 
  175.    Content-Type header, MUST ignore message portions with a text/plain
  176.    Content-Type header, and MUST ignore the portion of the message 
  177.    after the last boundary line. 
  178.  
  179.    Implementations MUST ignore message parts with a Content-Type that
  180.    they do not understand. Implementations also MUST NOT process 
  181.    message parts that specify a different Content-Disposition, but MAY
  182.    display them as appropriate.
  183.  
  184. Whalen                        Experimental                          [Page 3]
  185.  
  186. I/D              Process Content-Disposition             September 1997
  187.  
  188.  
  189.  
  190. 2.5  The "Process" Content-Disposition Type and the Text Body Part
  191.  
  192.    It is NOT RECOMMENDED to use the "process" Content-Disposition with
  193.    Content-Types beginning with text, due to the possible destructive
  194.    data in these types of content. 
  195.  
  196. 2.6  The "Process" Content-Disposition Type and the Main Message
  197.  
  198.    It is permissible to use the "process" Content-Disposition type on 
  199.    the main body of an [RFC 822] message, as long as there is a 
  200.    specified Content-Type.
  201.  
  202. 3.  Examples
  203.  
  204.    Here is a an example of a multipart/mixed body containing 2 [RFC 
  205.    1036] Usenet News messages that are intended to be processed by a 
  206.    newsgroup moderation robot. Note that the second message has a 
  207.    Content-Type of text/plain with quoted-printable encoding, so that
  208.    the message/news content type can still be 7bit. 
  209.    
  210.         Content-Type: multipart/mixed; boundary="=_e-postero.05551212_=_"
  211.         Content-Disposition: process
  212.  
  213.         This can be displayed by the moderation robot.
  214.  
  215.         --=_e-postero.05551212_=_
  216.         Content-Type: message/news
  217.         Content-Transfer-Encoding: 7bit
  218.  
  219.          <message header/data>
  220.  
  221.         --=_e-postero.05551212_=_
  222.         Content-Type: message/news
  223.         Content-Transfer-Encoding: 7bit
  224.  
  225.          <message header>
  226.         Content-Type: text/plain; charset="ISO-8859-3"
  227.         Content-Transfer-Encoding: quoted-printable
  228.  
  229.          <message body>
  230.  
  231.         --=_e-postero.05551212_=_
  232.  
  233.         This is ignored by the moderation robot.
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242. Whalen                        Experimental                          [Page 4]
  243.  
  244. I/D              Process Content-Disposition             September 1997
  245.  
  246.  
  247.  
  248.    The following body part contains a request for scheduling an event
  249.    in the user's calendar in a peraonal information management program.
  250.    The program requested (PIM 1.01), any future versions, and any 
  251.    compatible programs could parse the data in the body out that they 
  252.    use and either incorporate it in the receiver's calendar data or 
  253.    refuse to do so. Other programs will ignore this message.
  254.  
  255.         Content-Type: application/vnd.imaginary.pim
  256.         Content-Disposition: process; program="PIM/1.01"
  257.         Content-Description: Programmer's Group Meeting
  258.  
  259.         <scheduling data>
  260.  
  261. 4.  Security Considerations
  262.  
  263.    There are security issues involved any time users exchange data,
  264.    especially when this data is supposed to be processed by another 
  265.    program. Since this memo provides a way to automatically execute
  266.    another program and/or pass invalid or destructive data to another
  267.    program, a receiving UA MUST take care that the execution or 
  268.    interpretation requested through this parameter does not happen 
  269.    without the user's explicit permission, and SHOULD validate the 
  270.    data passed, if possible. The program executed MUST also take care
  271.    that no destructive actions can be performed through this method of
  272.    data input.
  273.  
  274.    If the receiving UA and the external program to be executed to
  275.    process the message are one and the same, (e.g. a newsgroup 
  276.    moderation robot) it SHOULD validate the data received and MUST make
  277.    sure that no destructive actions can be performed. Running this type
  278.    of UA fulfills the requirement for explicit permission from the 
  279.    user.
  280.  
  281.    Implementors MUST be alert to the potential hazards on their target
  282.    systems.
  283.  
  284. 5.  References
  285.  
  286.    [RFC 2183]
  287.         Troost, R. et. al., "Communicating Presentation Information in 
  288.         Internet Messages: The Content-Disposition Header Field", RFC
  289.         2183, August 1997.
  290.  
  291.    [RFC 2119]
  292.         Bradner, S., "Key words for use in RFCs to Indicate Requirement
  293.         Levels", RFC 2119, March 1997.
  294.  
  295.    [RFC 2184]
  296.         Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
  297.         Character Sets, Lanaguage, and Continuations", RFC 2184, August
  298.         1997.
  299.  
  300. Whalen                        Experimental                          [Page 5]
  301.  
  302. I/D              Process Content-Disposition             September 1997
  303.  
  304.  
  305.  
  306.    [RFC 2045]
  307.         Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
  308.         Extensions) Part One: Format of Internet Message Bodies", RFC
  309.         2045, December 1996.
  310.  
  311.    [RFC 2046]
  312.         Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
  313.         Extensions) Part Two: Media Types", RFC 2046, December 1996.
  314.  
  315.    [RFC 2047]
  316.         Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
  317.         Three: Message Header Extensions for non-ASCII Text", RFC 2047,
  318.         December 1996.
  319.  
  320.    [RFC 2048]
  321.         Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
  322.         Internet Mail Extensions) Part Four: Registration Procedures",
  323.         RFC 2048, December 1996.
  324.  
  325.    [RFC 2049]
  326.         Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
  327.         Extensions) Part Five: Conformance Criteria and Examples", RFC
  328.         2049, December 1996.
  329.  
  330.    [RFC 822]
  331.         Crocker, D., "Standard for the Format of ARPA Internet Text
  332.         Messages", STD 11, RFC 822, UDEL, August 1982.
  333.  
  334. 6.  Author's Address
  335.  
  336.         Curtis Whalen
  337.         Diamond Plus Software Development
  338.         2850 Shady Lane
  339.         Poplar Bluff MO  63901-2117
  340.         USA
  341.  
  342.         Phone: +1 (573) 778-0980
  343.         Email: diamondplus@iname.com
  344.  
  345. INTERNET DRAFT        EXPIRE MARCH 1998        INTERNET DRAFT
  346.