Internet Engineering Task Force Robert Herriot Internet-Draft Xerox Corp. Expires: September 23, 2001 March 23, 2001 The MIME Multipart/Interleaved and Application/Chunk Content-types draft-herriot-multipart-interleaved-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. (If this document becomes part of an IETF working group activity, then it will be brought into full compliance with 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. This Internet-Draft will expire on September 16, 2000. Copyright Notice Copyright c The Internet Society (2000). All Rights Reserved. Abstract The Multipart/Interleaved content-type, like the Multipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. Each body part of a Multipart/Related entity represents a component, whereas each body part of a Multipart/Interleaved entity represents either a component or a part of a component. A body part that represents a part of a component has the content-type of Application/Chunk. With Multipart/Related, a body part and its reference in some other body Herriot Expires: September 23, 2001 [page 1] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 part may be separated by many octets -- more octets than a memory- constrained device can deal with. With Multipart/Interleaved, a body part can represent a part of a component. This allows a body part and its reference in some other body part to be made quite close -- close enough for a memory-constrained device to deal with. This document defines the Multipart/Interleaved content-type and the Application/Chunk content-type. It also provides examples of its use. Herriot Expires: September 23, 2001 [page 2] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 Table of Contents 1 Introduction....................................................3 2 Terminology.....................................................4 3 Details.........................................................5 3.1 Parameters for Multipart/Interleaved.........................7 3.1.1The "type" Parameter .........................................7 3.1.2Syntax .......................................................7 3.2 Parameters for Application/Chunk.............................7 3.2.1The "id" Parameter ...........................................7 3.2.2The "number" Parameter .......................................8 3.2.3The "total" Parameter ........................................8 3.2.4Syntax .......................................................8 4 Handling Multipart/Interleaved Entities.........................8 5 Examples.......................................................10 5.1 Example With No Chunking....................................10 5.2 Example of Chunking the Root Body Part......................11 5.3 Example of Chunking the Several Body Parts..................13 6 Receiving User Agent Requirements..............................15 6.1 Data Requirements...........................................15 6.2 Storing Multipart/Interleaved Entities......................15 6.3 Recursion...................................................15 6.4 Configuration Considerations................................16 7 Security Considerations........................................16 8 Registration Information.......................................16 8.1 Multipart/Interleaved Registration Information..............16 8.2 Application/Chunk Registration Information..................16 9 Acknowledgments................................................17 10 References.....................................................17 11 Author's Address...............................................18 12 Full Copyright Statement.......................................18 1 Introduction The simple MIME content-types, such as "text/plain" provide a mechanism for representing a simple object, such as a text document. The Multipart/Related [RFC2387] content-type provides a mechanism for Herriot Expires: September 23, 2001 [page 3] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 representing a compound object, such as a text document with two gif images. A compound object consists of a root component, which contains references to other components of the compound object. These components may, in turn, contain references to other components of the compound object. For example, a compound object could consist of a root html text component and two gif components -- each referenced by the root component. A compound object and a component are both abstractions. For transmission over the wire, each needs a representation. A "Multipart/Related entity" is one possible representation of a compound object, and a "body part" is one possible representation of a component. Within a Multipart/Related entity, the number of octets separating a body part from its reference in some other body part is arbitrarily long. For a memory constrained Receiving User Agent, there is a need to keep the number of octets between a body part and its reference below some maximum number. This requirement implies the need for breaking body parts into chunks and interleaving the chunks among chunks of other body parts. This document defines two new MIME content-types that solve this problem: Application/Chunk and Multipart/Interleaved. The Application/Chunk content-type represents a part of a component. It is modeled after the Message/Partial content-type [RFC2046]. The Multipart/Interleaved content-type, like the Multipart/Related content-type, provides a common mechanism for representing a compound object. It differs from Multipart/Related in one very important way. One or more of the body parts of a Multipart/Interleaved entity can have a content-type of Application/Chunk. 2 Terminology This document uses some of the MIME terms that are defined in [RFC2045]. The following are the terms used in this document: Entity: the headers and the content. In this document "entity" is used to describe all the octets used to represent a compound object. Body part: an entity inside a multipart. That is, a body part is the headers and content (i.e. octets) between the multipart boundary strings not including the CRLF at the beginning and end. This document never uses "entity" to mean "body part". Herriot Expires: September 23, 2001 [page 4] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 Headers: the initial lines of an entity or body part. An empty line (i.e. two adjacent CRLFs) terminates the headers. Content: the part of an entity or body part that follows the headers (i.e. follows the two adjacent CRLFs). The content of a body part ends at the octet preceding the CRLF before the multipart boundary string. Receiving User Agent: the software that receives and processes a MIME entity. Equivalent Whole Body Part: a body part that results from concatenating Application/Chunk body parts together. A user should not be able to detect the difference between the handling of an equivalent whole body part and the chunks that form it. 3 Details The Multipart/Interleaved content-type, like Multipart/Related, is intended to represent a compound object consisting of several inter- related components. This document does not specify the representation of these relationships, but [RFC2557] contains examples of Multipart/Related entities that use the Content-ID and Content-Location headers to identify body parts and URLs (including the "cid" URL) to reference body parts. It is expect that Multipart/Interleaved entities would use the patterns described in [RFC2557]. For a Multipart/Interleaved entity, the parameters for the Content- Type header are those specified for Multipart [RFC2046] plus a "type" parameter that is like the "type" parameter for the Multipart/Related content-type. The value of the "type" parameter must be the content- type of the root body part and it effectively specifies the type of the compound object. Unlike, the Multipart/Related content-type, there is no "start-info" or "start" parameter. There is no "start" parameter because the root must be the first body part of the Multipart/ Interleaved entity. A single Application/Chunk body part represents a part of a component. The parameters of the Content-Type header give information about the Application/Chunk body part. The "id" parameter identifies the component with an ID. Each component has a globally unique ID. Within a Multipart/Interleaved entity, all Application/Chunk body parts that have the same ID represent a single component. The "number" parameter identifies the chunk within the sequence of chunks for a component. The first chunk of a component is numbered 1; the second is 2, and so on with consecutive integers. The chunks cannot occur out of order, and a number cannot be skipped. The "total" parameter specifies the total number of chunks for the component. Herriot Expires: September 23, 2001 [page 5] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 A Receiving User Agent processes a Multipart/Interleaved entity like a Multipart/Related entity, except that the first body part is always the root, and it has to join the Application/Chunk body parts into their "equivalent whole body parts". The Receiving User Agent processes Application/Chunk body parts using the following algorithm or equivalent: 1) Find each body part of a Multipart/Interleaved entity whose content-type is Application/Chunk 2) Of those body parts found, group together all body parts with the same "id" parameter value and assign numbers to each body part in a group. Assign the integers consecutively with1 to the first body part in the group, 2 to the second, and so on. 3) For each group of body parts with the same "id" parameter, take the body part contents (but not the body part headers) and concatenate the octets together in the order that the body parts occur in the Multipart/Interleaved entity. The result is the equivalent whole body part. If the value of the number parameter differs from the number assigned in the previous step, the Receiving User Agent's behavior is undefined. If the value of the number parameter exceeds the value of the "total" parameter or the value of the "total" parameter differs from the number of body parts in the group, the Receiving User Agent's behavior is undefined. Note that the octets of the content do not include the two adjacent CRLFs that end the headers of the Application/Chunk body part and the content does not include the CRLF just before the boundary string that terminates the Application/Chunk body part. 4) To each resulting equivalent whole body part, prefix the octets consisting of a single line whose contents are the header "Content-ID" with the value of the "id" parameter enclosed in angle brackets. For example, if the "id" has the value "49568.44343xxx@foo.com", the characters prefixed to the resulting equivalent whole body part is "Content-ID: <49568.44343xxx@foo.com>CRLF". Note the CRLF means that the prefixed octets constitute a line. Also note that if the contents of the first Application/Chunk body part doesn't contain any headers, it must start with a CRLF to mark the end of the headers in the resulting equivalent whole body part. The part about what headers to include is easy to misunderstand. The headers of each Application/Chunk body part include a Content-Type header whose value is Application/Chunk. This header and any other headers of the body part are not included in the concatenation. Herriot Expires: September 23, 2001 [page 6] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 However, the headers that are a part of the content of the Application/Chunk body part are treated differently. These headers represent the headers of the body part before it was broken into chunks. These headers include a Content-Type header whose value is the type of the component, e.g. "image/gif". The name "Application/Chunk" was chosen over "Application/Fragment" because the term "chunk" has been used to denote a non well-formed part of a whole, e.g. in HTTP/1.1, whereas the term "fragment" has been used to denote a well-formed chunk of a whole, e.g. in XML. The contents of an Application/Chunk body part need not be well formed, and most likely are not well formed. See section 4 for a discussion displaying a Multipart/Interleaved entity. 3.1 Parameters for Multipart/Interleaved The parameters include those specified for "multipart", such as the "boundary" parameter (see {RFC2046]). This section defines additional parameters for Multipart/Interleaved. 3.1.1The "type" Parameter The type parameter must be specified and its value is the content- type of the "root" body part. It permits a MIME Receiving User Agent to determine the content-type without reference to the enclosed body part. If the value of the type parameter differs from the content- type of the root body part, the Receiving User Agent's behavior is undefined. 3.1.2Syntax The syntax for the "parameter" of the Multipart/Interleaved content- type (in addition to the parameters specified for multipart) is: parameter := "type" "=" type "/" subtype ; cf [RFC2045] 3.2 Parameters for Application/Chunk 3.2.1The "id" Parameter The "id" parameter is a unique identifier, as close to a world-unique identifier as possible. The "id" parameter identifies the component that the Application/Chunk body part represents a part of. Herriot Expires: September 23, 2001 [page 7] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 The identifier is essentially a content-id; if placed in double quotes, it can be ANY "addr-spec" as defined in [RFC822]. Note, that the value of the Content-Id header has the syntax of "msg-id" which [RFC822] defines as msg-id = "<" addr-spec ">" ; Unique message id 3.2.2The "number" Parameter The "number" parameter is an integer. Its value is the ordinal number of the chunk. The number of the first chunk of a component must be 1. The number of each subsequent chunk for the component must be one higher than the number of the preceding chunk. On the last chunk, the value of the "number" parameter equals the value of the "total" parameter. Each component, that is each separate "id" has its own sequence of consecutive integers starting at 1. 3.2.3The "total" Parameter The "total" parameter is an integer. Its value is the total number of chunks for the component. This parameter is required on the final chunk of a component, and is optional (though encouraged) on the earlier chunks. On the final chunk of a component, its value must be the same as the "number" parameter. 3.2.4Syntax The syntax for the "parameter" of the Application/Chunk content-type is: parameter := idParameter / numberParameter / totalParameter idParameter := addr-spec ; cf. [RFC822] numberParameter := 1*DIGIT ; cf. [RFC822] totalParameter := 1*DIGIT ; cf. [RFC822] 4 Handling Multipart/Interleaved Entities The application that handles the Multipart/Interleaved entity has the responsibility for displaying the entity. However, Multipart/Interleaved body parts may contain Content-Disposition Herriot Expires: September 23, 2001 [page 8] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 headers that provide suggestions for the display and storage of a body part, and in some cases the application may pay attention to such headers. As a reminder, Content-Disposition headers [RFC1806] allow the sender to suggest presentation styles for MIME body parts. There are two presentation styles, 'inline' and 'attachment'. Content-Disposition headers have a parameter for specifying a suggested file name for storage. There are three cases to consider for handling Multipart/Interleaved entities: a) The Receiving User Agent recognizes Multipart/Interleaved and the content-type of the root. The Receiving User Agent determines the presentation style for the compound object; it handles the display of the components of the compound object in the context of the compound object. In this case, the Content-Disposition header information is redundant or even misleading, and the Receiving User Agent shall ignore them for purposes of display. The Receiving User Agent may use the suggested file name if the entity is stored. b) The Receiving User Agent recognizes Multipart/Interleaved, but not the content-type of the root. The Receiving User Agent will give the user the choice of suppressing the entire Multipart/Interleaved entity or treating the Multipart/Interleaved entity as a Multipart/Mixed entity where Application/Chunk body parts have been converted to their equivalent whole body parts. In this case (where the entity is not suppressed), the Receiving User Agent may find the Content-Disposition information useful for displaying each body part of the resulting Multipart/Mixed entity. If a body part has no Content-Disposition header, the Receiving User Agent should display the body part as an attachment. Note that if an equivalent whole body part (generated from multiple Application/Chunk body parts) has a Content-Disposition header, it is in the header portion that begins the content of the first Application/Chunk body part of the component. c) The Receiving User Agent does not recognize Multipart/Interleaved. The Receiving User Agent treats the Multipart/Interleaved entity as a Multipart/Mixed entity. In this case, the Receiving User Agent may find the Content-Disposition information useful for those body parts whose content-types it recognizes. The Receiving User Agent cannot display an Application/Chunk body part, because it is opaque to such a Receiving User Agent. But the Receiving User Agent may allow it to be stored so that some other application can join the chunks together. Herriot Expires: September 23, 2001 [page 9] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 5 Examples This section contains several examples. All examples consist of an XHTML object with three referenced images. Two images are potentially side-by-side and the third is later in the document. The first example has no interleaving and could thus be represented by a similar Multipart/Related entity. In the second example, the XHTML is interleaved with the three images. In the third example, the two side-by-side images are chunked and interleaved with the XHTML chunks. Each body part contains a content-disposition, which the Receiving User Agent uses according to the rules in section 4. Note the location of the content-disposition headers in the examples. 5.1 Example With No Chunking The following example consists of XHTML with three images. One is encoded in base64, and the other two are encoded in binary (for sake of example). This example has no chunking. Note that if the chunks from the second and third example were reassembled to form their equivalent whole body parts, the result would be identical to this example. Note, also that if the Context-Type of the first line were changed to "multipart/related", it would be a valid "multipart/related" entity, and it would represent a compound object that is identical to the one that this example represents. However, it would require more memory to process it. Content-Type: multipart/interleaved; boundary="boundary-example"; type="text/xhtml+xml" --boundary-example Content-ID: <49568.44343xxx@foo.com> Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline

some text Herriot Expires: September 23, 2001 [page 10] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 some more text after the images

some more text without images

some more text

some final text

--boundary-example Content-ID: <49568.45876xxx @foo.com> Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-ID: <49568.46000xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example-- 5.2 Example of Chunking the Root Body Part The following example consists of XHTML with three images. One is encoded in base64, and the other two are encoded in binary (for sake of example). The root body part is chunked so that each image appears just before the chunk of XHTML that contains the reference. Note there are other possible arrangements (see the third example in section 5.3). For example, a sender could chunk the root body part so that each image appears just after the chunk of XHTML that contains the reference. Also, a sender could chunk the root body part so that Herriot Expires: September 23, 2001 [page 11] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 some images appear just after the chunk of XHTML that contains the reference, and other images appear just before the chunk of XHTML that contains the reference. Content-Type: multipart/interleaved; boundary="boundary-example"; type="text/xhtml+xml" --boundary-example Content-Type: application/chunk;number=1;total=3; id="49568.44343xxx@foo.com" Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline

some text --boundary-example Content-ID: <49568.45876xxx @foo.com> Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-ID: <49568.46000xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example Content-Type: application/chunk;number=2;total=3; id="49568.44343xxx@foo.com" some more text after the images

some more text without images

some more text --boundary-example Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Herriot Expires: September 23, 2001 [page 12] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example Content-Type: application/chunk;number=3;total=3; id="49568.44343xxx@foo.com"

some final text

--boundary-example-- 5.3 Example of Chunking the Several Body Parts The following example consists of XHTML with three images. One is encoded in base64, and the other two are encoded in binary (for sake of example). The root body part is chunked so that each image appears just before the chunk of XHTML that contains the reference except for the third image, which appears just after its reference (for sake of example). In addition, the first two images are chunked so that only a small portion of these images has to be processed before the XHTML reference is processed. This results in the XHTML being divided into 4 chunks. Content-Type: multipart/interleaved; boundary="boundary-example"; type="text/xhtml+xml" --boundary-example Content-Type: application/chunk;number=1;total=4; id="49568.44343xxx@foo.com" Content-Type: text/xhtml+xml;charset="us-ascii" Content-Disposition: inline

some text --boundary-example Content-Type: application/chunk;number=1;total=2; id="49568.45876xxx@foo.com" Herriot Expires: September 23, 2001 [page 13] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 --boundary-example Content-Type: application/chunk;number=1;total=2; id="49568.46000xxx@foo.com" Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example Content-Type: application/chunk;number=2;total=4; id="49568.44343xxx@foo.com" --boundary-example Content-Type: application/chunk;number=2;total=2; id="49568.45876xxx@foo.com" NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-Type: application/chunk;number=2;total=2; id="49568.46000xxx@foo.com" --boundary-example Content-Type: application/chunk;number=3;total=4; id="49568.44343xxx@foo.com" some more text after the images

some more text without images

some more text --boundary-example Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Transfer-Encoding: binary Content-Disposition: attachment --boundary-example Content-Type: application/chunk;number=4;total=4; Herriot Expires: September 23, 2001 [page 14] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 id="49568.44343xxx@foo.com"

some final text

--boundary-example-- 6 Receiving User Agent Requirements See section 4 for details about how a Receiving User Agent processes a Multipart/Interleaved entity. 6.1 Data Requirements ISSUE: what should be in this section: MIME-capable mail user agents (MUAs) are required to provide the application: a) the contents of the MIME entities and the entity Content-* headers, b) the parameters of the Multipart/Interleaved Content-type header, c) the parameters of the Application/Chunk Content-type header, and d) the correspondence between each body part's local file name, that body part's header data, and, if present, the body part's content- ID 6.2 Storing Multipart/Interleaved Entities The Multipart/Interleaved content-type will be used for objects that have internal linkages between the body parts. When the objects are stored the linkages may require processing by the application or its receiving user agent. 6.3 Recursion MIME is a recursive structure. Hence, one must expect a Multipart/Interleaved entity to contain other Multipart/Interleaved entities. When a Multipart/Interleaved entity is being processed for display or storage, any enclosed Multipart/Interleaved entities shall be processed as though they were being stored. Herriot Expires: September 23, 2001 [page 15] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 ISSUE: The above sentence is copies from Multipart/Related. Is it really correct about nested entities being processed for storage rather than display? 6.4 Configuration Considerations It is suggested that MUAs that use configuration mechanisms of [RFC1524]. For an example, refer to Multipart/Interleaved as Multipart/Interleaved/, where is the value of the "type" parameter. 7 Security Considerations Security considerations relevant to Multipart/Interleaved are identical to those of the underlying content-type. 8 Registration Information 8.1 Multipart/Interleaved Registration Information The following form is copied from RFC 1590, Appendix A. To: IANA@isi.edu Subject: Registration of new Media Type content- type/subtype Media Type name: Multipart Media subtype name: Interleaved Required parameters: Type, a media type/subtype. Optional parameters: No optional parameters Encoding considerations: Multipart content-types cannot have encodings. Security considerations: Depends solely on the referenced type. Published specification: RFC-REL (this document). Person & email address to contact for further information: Robert Herriot Xerox Corp. 3400 Hillview Ave, Bldg #1 Palo Alto, CA 94304 USA Phone: 1-650-813-7696 Email: rherriot@pahv.xerox.com Herriot Expires: September 23, 2001 [page 16] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 8.2 Application/Chunk Registration Information The following form is copied from RFC 1590, Appendix A. To: IANA@isi.edu Subject: Registration of new Media Type content- type/subtype Media Type name: Application Media subtype name: Chunk Required parameters: id, a content-ID. number, an integer total, an integer, optional except on last chunk Optional parameters: total, covered in "required parameters" section Encoding considerations: any encoding is allowed. Security considerations: None. Published specification: RFC-REL (this document). Person & email address to contact for further information: Robert Herriot Xerox Corp. 3400 Hillview Ave, Bldg #1 Palo Alto, CA 94304 USA Phone: 1-650-813-7696 Email: rherriot@pahv.xerox.com 9 Acknowledgments The author gratefully acknowledges the contributions of: Ugo Corda, Graham Klyne, Carl-Uno Manros, Larry Masinter, Chris Newman and Henrik Frystyk Nielsen. In particular, Chris Newman provided invaluable help. 10 References [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC1524] Borenstein, N., "A User Agent Configuration Mechanism For Multimedia Mail Format Information", RFC 1524, September 1993. [RFC1806] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. Herriot Expires: September 23, 2001 [page 17] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 [RFC1873] Levinson, E., and J. Clark, "Message/External-Body Content- ID Access Type", RFC 1873, December 1995, Levinson, E., "Message/External-Body Content-ID Access Type", Work in Progress. [RFC2045] Freed, N. et al., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2046, November 1996. [RFC2046] Freed, N. et al., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [RFC2557] Palme, J., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML", RFC 2557, March 1999. 11 Author's Address Robert Herriot Xerox Corp. 3400 Hillview Ave, Bldg #1 Palo Alto, CA 94304 USA Phone: 1-650-813-7696 Email: rherriot@pahv.xerox.com 12 Full Copyright Statement Copyright c The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative work that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Herriot Expires: September 23, 2001 [page 18] INTERNET-DRAFT Multipart/Interleaved March 23, 2001 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Herriot Expires: September 23, 2001 [page 19]