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]
