Network Working Group Keith Moore Internet Draft University of Tennessee 24 October 1993 Multipart/References MIME Content-Type draft-moore-mime-references-00.txt 1. 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 valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. (The file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil, describes the current status of each Internet Draft.) It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". 2. Abstract This memo defines a new MIME content-type "multipart/references", which can be used to denote a set of MIME contents, of which any one may reference the others by its MIME content-id. This mechanism may be used by presentation languages that wish to be able to reference MIME objects, or by other applications (file transfer, authentication, delivery reports) which need to supply related information about another MIME object. 3. Introduction Several new MIME [1] -based applications are being developed which require data that is best represented (within a MIME message) as multiple MIME body parts. Frequently, such applications simply need to "embellish" or provide additional information about one or more other objects, which themselves are naturally represented as MIME body parts. Examples of such applications include the following: + File transfer. When using MIME to transfer a file, it is useful to represent the file being transferred as a MIME body part (with appropriate MIME content-type labelling), and provide additional information (ownership, creation date, permissions, icon, or data specific to a particular system) in a separate body part. A MIME mail reader could present the contents of the file being transferred in addition to offering to store the file on the recipient's file system. K. Moore Expires 24 April 1994 [Page 1] Multipart/References 24 October 1993 + Authentication. A separate body part could be used as a certificate of authorship and integrity check, using protocols such as PEM [2,3,4,5]. + Delivery and receipt notifications. A delivery status notification (or receipt notification) may include both the original message, and a separate body part indicating why the delivery of the message failed. The mechanism defined in this memo could be used to illustrate the relationship between the two. + Hypertext systems. It may be desirable to transmit a set of hypertext documents which reference one another, in a single MIME message. + Presentation languages. Since MIME says little about how the objects it carries are to be presented, this extension may be used by presentation languages that wish to reference other MIME objects. Although MIME [5] defines a content-id header which can be used for this purpose, it provides no mechanism by which one body part can reference another. Neither does it provide a mechanism to indicate whether a particular body part should be presented by a mail reader, stored in a file (as in an attachment), or whether the body part is intended to be referenced by another body part. This memo thus defines: + a "multipart/references" content-type to be used to indicate a set of body parts that may reference one another. + a new "internal" access-type for the message/external-body content- type, which instructs the mail reader to present another body part contained within the same multipart/references content. (This is intended to be used within multipart/alternative, as a fallback for when better presentation languages are not supported.) 4. The Multipart/References Content-Type The Multipart/References Content-Type is defined as follows: MIME type name: multipart MIME subtype name: references Required parameters: start Optional parameters: none Encoding considerations: No content-transfer-encoding may be used. Security considerations: none NOTE IN DRAFT: this content-type needs a better name. Suggestions are welcome! K. Moore Expires 24 April 1994 [Page 2] Multipart/References 24 October 1993 The "start" parameter contains the content-id of one of the immediate children of the multipart/references body part being defined (without the enclosing '<' and '>'). It indicates to the mail reader which of the components of the multipart/references should be presented. When presenting a multipart/references body part, the mail reader first scans all of the components contained within. Then it presents the component whose content-id is indicated by the "start" parameter. The "start" component may then reference other body parts contained within the same, or an enclosing, multipart/references body part. If an external program is responsible for presenting the "start" body part, the mail reader will run it in an environment from which it can obtain the other body parts (and associated headers) by using their content-id. Any component of a multipart/references body part (not just the "start" component) may reference any other component within the same (or an enclosing) multipart/references body part. (The module charged with presenting the "start" component may cause other components of the multipart/references body part to be presented, which themselves reference other body parts.) Other than storing the information associated with each component of a multipart/references body part to allow for later retrival, and undoing any content-transfer-encoding applied to the component, no processing is performed on any of the components, before presenting the "start" component. NOTE: This includes any "composite" content-types such as multipart, message/external-body, or message/rfc822. If such objects are referenced by other components, they will obtain the original headers and/or (decoded) body comprising the multipart, message/external- body, or message/rfc822 body part. The individual components or sub- components of a composite CANNOT be directly referenced by another body part, unless it first parses the components. A component of a multipart/references body part need not include a content-id header. However, without such a header, there is no way for it to either be the "distinguished" component, or to be refernced by another component. Such components will only be presented by a mail reader that does not implement this specification. 5. The "internal" Access-Type for Message/External-Body A new access-type is defined for the MIME Message/External-Body content-type. The "internal" access-type indicates that the actual body of this particular message/external-body body part, should be obtained from another body part contained within an enclosing multipart/references body part. The mandantory parameter for this access-type is: K. Moore Expires 24 April 1994 [Page 3] Multipart/References 24 October 1993 CONTENT-ID -- the content-id of the body part being referenced The value associated with the content-id parameter should NOT include the enclosing '<' and '>' required by the content-id body part header. NOTE IN DRAFT: alternatives for the name "internal" are also solicited! When the internal access-type is used, the headers that appear in the body of the message/external-body part will normally be similar to the body part headers that appear with the referenced body part. However, the headers need not be the identical, since it may be desirable to present the object slightly differently under different conditions. In any case, when a message/external-body body part is presented, the headers appearing in the body of the message/external-body body part are used, rather than those of the referenced body part. The "internal" access type is designed to allow "fallback" access to one or more components of a multipart/references body part. For example, a hypothetical application/foo body part might reference other body parts A, B, and C. If the recipient's mail reader doesn't support application/foo, the sender might want her to see A, B, and C anyway. So the message could be constructed as follows. (In this example, A, B, C, and D are the content-ids of the components of the multipart/references body part.) multipart/references ; start=D { A: [body-part-A] B: [body-part-B] C: [body-part-C] D: multipart/alternative { application/foo (which references A, B, and C internally) multipart/mixed message/external-body; access-type=internal; content-id=A message/external-body; access-type=internal; content-id=B message/external-body; access-type=internal; content-id=C } } 6. Security considerations Security considerations are not discussed in this memo. 7. Acknowledgements This proposal is an amalgam resulting from ideas presented in several other approaches to this problem, including Harald Tveit Alvestrand's "multipart/related", Dave Crocker's "multipart/header-set", and Rens Troost's "content-disposition" documents. (There are probably others K. Moore Expires 24 April 1994 [Page 4] Multipart/References 24 October 1993 that I don't recall at the moment.) Discussion on the ietf-822 and info-metamail mailing lists has helped to define the requirements for this proposal. 8. References [1] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 23 1993. [2] J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures". RFC 1421, February 10 1993. [3] S. Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 10 1993. [4] D. Balenson, "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 10 1993. [5] B. Kaliski, "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, Febryary 10, 1993. 9. Author's address Keith Moore University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA email: moore@cs.utk.edu K. Moore Expires 24 April 1994 [Page 5] Multipart/References 24 October 1993 Appendix. Implementation suggestion This proposal requires that the "modules" responsible for presenting a body part be able to reference other body parts. The mechanisms by which this might be done vary considerably from one system to another (e.g. logical names on VMS, shared file descriptors on UNIX). Because dissimilar systems often share code nowadays, there is some advantage in having a system-independent way to provide such access. Here is a suggestion for how this might be done in a relatively painless manner. When a mail reader encounters a multipart/references body part, it proceeds to scan each of the components. Each component's headers are stored in a temporary file, and the body part (after undoing any content-transfer-encoding) is stored in a separate temporary file. The names of the files are based on the content-id of the body part being stored. Since content-IDs may contain special characters not allowed in a file name, or may be longer than the length of a file name, they may be mapped into legal file names as follows: 1. Remove the '<' and '>' enclosing the content-id. 2. Apply the MD5 digest algorithm (see RFC 1321) to the result. 3. Separate the resulting 128-bit digest into four groups of 32 bits each, and exclusive-or together all four groups, producing a 32-bit result. 4. Encode the resulting 32-bit quantity as 8 hexadecimal, upper case characters. 5. If necessary, truncate the resulting character string so that it fits within the limits of the local file system (leaving room for a four character filename suffix). 6. Append the string ".HDR" to produce the filename to contain the header, and ".BDY" for the filename to contain the body part. 7. The calling program should remove the temporary files after the sub- program completes its work. The author hopes this method will be sufficient for any modern file system. File name collisions are presumed to be unlikely, but paranoid implementors might want to modify the filename suffix should collisions occur. An application programmer's interface should be provided to handle the details of translating file names and manipulating the resulting files. Such an interface could also be extended "underneath" to provide more efficient access where the operating system supports it, e.g. by sharing memory between processes. K. Moore Expires 24 April 1994 [Page 6]