Internet DRAFT - draft-herriot-multipart-interleaved

draft-herriot-multipart-interleaved









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

   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <html xmlns="http://www.w3.org/TR/xhtml1">
      <body>
         <p>some text
            <img src="cid:49568.45876xxx@foo.com"/>
            <img src="cid:49568.46000xxx@foo.com"/>


Herriot               Expires: September 23, 2001              [page 10]


INTERNET-DRAFT         Multipart/Interleaved             March 23, 2001


            some more text after the images
         </p>
         <p>some more text without images
         </p>
         <p>some more text
            <img src="cid:49568.47333xxx@foo.com"/>
         </p>
         <p>some final text
         </p>
      </body>
   </html>
   --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

   <binary data>
   --boundary-example
   Content-ID: <49568.47333xxx@foo.com>
   Content-Type: image/gif
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment

   <binary data>
   --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

   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <html xmlns="http://www.w3.org/TR/xhtml1">
      <body>
         <p>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

   <binary data>
   --boundary-example
   Content-Type: application/chunk;number=2;total=3;
            id="49568.44343xxx@foo.com"

            <img src="cid:49568.45876xxx@foo.com"/>
            <img src="cid:49568.46000xxx@foo.com"/>
            some more text after the images
         </p>
         <p>some more text without images
         </p>
         <p>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

   <binary data>
   --boundary-example
   Content-Type: application/chunk;number=3;total=3;
            id="49568.44343xxx@foo.com"

            <img src="cid:49568.47333xxx@foo.com"/>
         </p>
         <p>some final text
         </p>
      </body>
   </html>
   --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

   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <html xmlns="http://www.w3.org/TR/xhtml1">
      <body>
         <p>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

   <first part of the binary data>
   --boundary-example
   Content-Type: application/chunk;number=2;total=4;
            id="49568.44343xxx@foo.com"

            <img src="cid:49568.45876xxx@foo.com"/>
            <img src="cid:49568.46000xxx@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"

   <second part of the binary data>
   --boundary-example
   Content-Type: application/chunk;number=3;total=4;
            id="49568.44343xxx@foo.com"

            some more text after the images
         </p>
         <p>some more text without images
         </p>
         <p>some more text
            <img src="cid:49568.47333xxx@foo.com"/>
   --boundary-example
   Content-ID: <49568.47333xxx@foo.com>
   Content-Type: image/gif
   Content-Transfer-Encoding: binary
   Content-Disposition: attachment

   <binary data>
   --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"

         </p>
         <p>some final text
         </p>
      </body>
   </html>
   --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/<type>, where <type> 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]