Internet Engineering Task Force Robert Herriot
Internet-Draft Xerox Corp.
Expires: December 1, 2001 June 1, 2001
[Target Category: Informational RFC]
The MIME Application/Multiplexed Content-type
draft-herriot-application-multiplexed-02
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 Application/Multiplexed content-type, like the Multipart/Related
content-type, provides a mechanism for representing objects that
consist of multiple components. An Application/Multiplexed entity
contains a sequence of chunks. Each chunk contains a MIME message or
a part of a MIME message. Each MIME message represents a component of
the compound object, just as a body part of a Multipart/Related
entity represents a component. With an Application/Multiplexed
entity, a body part and its reference in some other body part may be
Herriot Expires: December 1, 2001 [page 1]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
separated by many octets -- more octets than a memory-constrained
device can deal with. With an Application/Multiplexed entity, a chunk
can contain part of a message. This allows a message and its
reference in some other message to be made quite close -- close
enough for a memory-constrained device to deal with. This document
defines the Application/Multiplexed content-type. It also provides
examples of its use.
Herriot Expires: December 1, 2001 [page 2]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
Table of Contents
1 Introduction....................................................3
2 Terminology.....................................................4
3 Details.........................................................6
3.1 Syntax of Application/Multiplexed Contents...................7
3.2 Parameters for Application/Multiplexed.......................8
3.2.1 The "type" Parameter.......................................9
3.2.2 Syntax.....................................................9
4 Handling Application/Multiplexed Entities.......................9
5 Examples.......................................................10
5.1 Example With Multipart/Related..............................10
5.2 Examples with Application/Multiplexed.......................12
5.2.1 Example Where Each Chunk Has a Complete Message...........12
5.2.2 Example of Chunking the Root Message......................13
5.2.3 Example of Chunking the Several Messages..................15
5.2.4 Example of Chunks with Empty Payloads.....................16
6 Receiving User Agent Requirements..............................18
6.1 Storing Application/Multiplexed Entities....................18
6.2 Recursion...................................................19
6.3 Configuration Considerations................................19
7 Security Considerations........................................19
8 Registration Information for Application/Multiplexed...........19
9 Acknowledgments................................................20
10 References.....................................................20
11 Author's Address...............................................20
12 Full Copyright Statement.......................................21
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
representing a compound object, such as a text document with two gif
images.
Herriot Expires: December 1, 2001 [page 3]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
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 to
define some unit that represents a part of a component and to be able
to interleave these units among those from other components.
This document defines a new MIME content-type Application/Multiplexed
that provides a simple solution to this problem. There are compound
objects that a Receiving User Agent can successfully receive as an
Application/Multiplexed entity but not as a Multipart/Related entity
because of memory constraints. It is recognized that are compound
objects that a Receiving User Agent can successfully receive via a
protocol but not as a Application/Multiplexed entity. However, there
are circumstances where it is preferable to transmit a compound
object via a stream of octets rather than via a protocol.
The Application/Multiplexed content-type, like the Multipart/Related
content-type, provides a common mechanism for representing a compound
object. A Multipart/Related entity consists of sequence of body parts
separated by boundary strings, and each body part represents a
component of the compound object. An Application/Multiplexed entity
contains a sequence of chunks, each of whose length is specified in
the chunk header. Each chunk contains a message or a part of a
message. Each message represents a component of the compound object.
Chunks from different messages can be interleaved.
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, the term
"entity" describes all the octets that represent a compound object.
Herriot Expires: December 1, 2001 [page 4]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
Message: an entity as in [RFC2045]. In this document, the term
"message" describes all octets that represent one component of a
compound object. That is, it has MIME headers and content.
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".
Headers: the initial lines of an entity, message or body part. An
empty line (i.e. two adjacent CRLFs) terminates the headers.
Sometimes the term "MIME header" is used instead of just "header".
Content: the part of an entity, message 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. The content of a message ends at the octets
specified by the length field in the Chunk Header.
Receiving User Agent: the software that receives and processes a
MIME entity.
This document uses the following additional terms.
Chunk: a chunk of data, consisting of a chunk header, a chunk
payload and a CR LF.
Chunk Header: the first line of a chunk. The line consists of the
"CHK" keyword, the message number, the length and the continuation
indicator, each separated by a single blank. A CR LF terminates the
line. Each message in an application/multiplexed entity has a
message number that normally differs from the message numbers of
all other messages in the application/multiplexed entity. The
message number 0 is reserved for final Chunk Header in the
application/multiplexed entity.
Chunk Payload: the octets between the Chunk Header and the Chunk
Header of the next chunk. The length field in the header's length
field specifies the octets. The Chunk Payload is either a complete
message or a part of a message. The continuation field in the
header specifies whether the chunk is the last chunk of the
message.
CR LF: A CR LF terminates each chunk in order to provide visual
separation from the next chunk header.
Herriot Expires: December 1, 2001 [page 5]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
3 Details
The Application/Multiplexed 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 expected that
Application/Multiplexed entities would use the patterns described in
[RFC2557].
For an Application/Multiplexed entity, there is one parameter for the
Content-Type header. It is a "type" parameter, and it 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 message and
it effectively specifies the type of the compound object.
An Application/Multiplexed entity contains a sequence of chunks. Each
chunk consists of a chunk header, a chunk payload and a CR LF.
- The chunk header consists of a "CHK" keyword followed by the
message number, the chunk payload length, whether the chunk is
the last chunk of a message, and finally a CR LF. The length
field removes the need for boundary strings that Multipart uses.
(See section 3.1 for the syntax of a chunk header).
- The chunk payload is a sequence of octets that is either a
complete message or a part of a message.
- The CR LF provides visual separation from the following chunk
Each message represents a component of the compound object, and a
message is intended to have exactly the same representation, octet
for octet, as a body part of a Multipart/Related entity that
represents the same component. When a message is split across
multiple chunks, the chunks need not be contiguous.
The contents of an Application/Multiplexed entity have the following
properties:
1)The first chunk contains a complete or partial message that (in
either case) represents the root component of the compound
object.
2)Additional chunks contain messages or partial messages that
represent some component of the compound object.
3)The final chunk's header contains a message number of 0, a
length of 0 and a last-chunk-of-message mark (i.e. the chunk
Herriot Expires: December 1, 2001 [page 6]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
header line is "CHK 0 0 LAST"). The final chunk contains no
chunk payload.
4)A message can be broken into multiple parts and each break can
occur anywhere within the message. Each part of the message is
zero or more bytes in length and each part of the message is the
contents of its own chunk. The order of the chunks within the
Application/Multiplexed entity must be the same as the order of
the parts within the message.
5)A message represents a component of a compound object, and it is
intended that it have exactly the same representation, octet for
octet, as a body part of a Multipart/Related entity that
represents the same component. In particular, the message may
contain a Content-Type header to specify the content-type of the
message content. Also, the message may contain a Content-ID
header and/or Content-Location header to identify a message that
is referenced from within another message.
See section 0 for a discussion displaying a Application/Multiplexed
entity.
3.1 Syntax of Application/Multiplexed Contents
The ABNF [RFC2234] for the contents of an Application/Multiplexed
entity is:
contents = *chunk finalChunk
chunk = header payload CR LF
header = "CHK" SP messageNumber SP length SP isMore CR LF
messageNumber = 1..2147483647
length = 0..2147483647
isMore = "MORE" / "LAST"
payload = *OCTET
finalChunk = finalHeader CR LF
finalHeader = "CHK" SP "0" SP "0" SP "LAST" CR LF
The messageNumber field specifies the message that the chunk is
associated with. See the end of this section for more details.
The length field specifies the number of octets in the chunk payload
(represented in ABNF as "payload"). The first octet of the chunk
payload is the one immediately following the LF (i.e. final octet) of
the chunk header. The last octet of the chunk payload is the one
immediately preceding the two octets CR LF that end the chunk.
The isMore field has a value of "LAST" for the last chunk of a
message and "MORE" for all other chunks of a message.
Herriot Expires: December 1, 2001 [page 7]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
Normally each message in an Application/Multiplexed entity has a
unique message number, and a message consists of the concatenation of
all the octets from the one or more chunks with the same message
number. The isMore field of the chunk header of the last chunk of
each message must have a value of "LAST" and the isMore field of the
chunk header of all other chunks must have a value of "MORE".
Two or more messages may have the same message number, though such
reuse of message numbers is not recommended. The chunks with the
same message number represent a sequence of one or more messages
where the isMore field of the chunk header of the last chunk of each
message has a value of "LAST". All chunks whose isMore field of the
chunk header has the value of "MORE" belong to the same message as
the next chunk (in sequence) whose isMore field of the chunk header
has the value of "LAST". In other words, if two messages have the
same message number, the last chunk of the first message must occur
before the first chunk of the second message.
The behavior of the Receiving User Agent is undefined if the final
Chunk (i.e. the Chunk whose chunk header is "CHK 0 0 LAST") occurs
before the last chunk of every message has occurred.
Two adjacent chunks usually have different message numbers, but they
may have the same message number. If two adjacent chunks have the
same message number, the two chunks could be combined into a single
chunk, but they need not be combined.
The number of octets in a chunk payload may be zero, and an
application/multiplexed entity may contain any number of chunks with
zero octets of chunk payload. For example, the last chunk of each
message may contain zero octets for programming convenience. As
another example, suppose that a particular compound object format
requires that referenced messages occur before the root message. This
document requires that the first chunk of an application/multiplexed
entity contain the root message or a part of it. So, the first chunk
contains a chunk payload of zero octets with the first octet of the
root message in the second chunk. That is, all of the message headers
of the root message are in the second chunk. As an extreme, but
unlikely example, it would be possible to have a message broken into
ten chunks with zero octet chunk payloads in all chunks except for
chunks 4 and 7.
3.2 Parameters for Application/Multiplexed
This section defines additional parameters for
Application/Multiplexed.
Herriot Expires: December 1, 2001 [page 8]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
3.2.1The "type" Parameter
The type parameter must be specified and its value is the content-
type of the "root" message. It permits a MIME Receiving User Agent
to determine the content-type without reference to the enclosed
message. If the value of the type parameter differs from the
content-type of the root message, the Receiving User Agent's behavior
is undefined.
3.2.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]
4 Handling Application/Multiplexed Entities
The application that handles the Application/Multiplexed entity has
the responsibility for displaying the entity. However,
Application/Multiplexed messages may contain Content-Disposition
headers that provide suggestions for the display and storage of a
message, 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 messages. 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
Application/Multiplexed entities:
a)The Receiving User Agent recognizes Application/Multiplexed 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 Application/Multiplexed, but
not the content-type of the root. The Receiving User Agent will
give the user the choice of suppressing the entire
Application/Multiplexed entity or treating the
Herriot Expires: December 1, 2001 [page 9]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
Application/Multiplexed entity as a Multipart/Mixed entity where
each message is a body part of the Multipart/Mixed entity. 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.
c)The Receiving User Agent does not recognize
Application/Multiplexed. The Receiving User Agent treats the
Application/Multiplexed entity as opaque and can do nothing with
it.
5 Examples
This section contains five examples. Each example is a different
representation of the same compound object. The compound object has
four components: an XHTML text component and three image components.
One image is encoded in base64, and the other two images are encoded
in binary (for sake of example). Two of the images are potentially
side by side, and the third image is displayed later in the document.
All of the images are identified by Content-Id, and two of the images
are also identified by a Content-Location. One of the images
references the Content-Location.
The first example shows a Multipart/Related representation of the
compound object in order to provide a representation that the reader
is familiar with. The remaining examples show Application/Multiplexed
representations of the same compound object. In the second example,
each chunk contains a whole message. In the third example, the XHTML
message is split across 3 chunks, and these chunks are interleaved
among the three image messages. In the fourth example, the XHTML
message is split across 4 chunks, and the two side-by-side images are
each split across two chunks. The XHTML chunks are interleaved among
the image chunks. In the fifth example, there are chunks with empty
payloads and adjacent chunks with the same message number.
Each body part of the Multipart/Related entity and each message of
the Application/Multiplexed entity contains a content-disposition,
which the Receiving User Agent uses according to the rules in section
0. Note the location of the content-disposition headers in the
examples.
5.1 Example With Multipart/Related
In this example, the compound object is represented as a
Multipart/Related entity so that the reader can compare it with the
Application/Multiplexed entities.
Herriot Expires: December 1, 2001 [page 10]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
Content-Type: multipart/related; 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="http://foo.com/images/image2.gif"/>
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-Location: http://foo.com/images/image1.gif
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-Location: http://foo.com/images/image2.gif
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
Herriot Expires: December 1, 2001 [page 11]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
<binary data>
--boundary-example--
5.2 Examples with Application/Multiplexed
The four examples in this section show Application/Multiplexed
representations of the same compound object. Note that each CR LF is
represented by a visual line break.
5.2.1 Example Where Each Chunk Has a Complete Message
In this example, the compound object is represented as an
Application/Multiplexed entity. Each chunk contains an entire
message, i.e. none of the messages is split across multiple chunks.
Each message in this example is identical to the corresponding body
part in the preceding Multipart/Relate example.
Content-Type: application/multiplexed;
type="text/xhtml+xml"
CHK 1 550 LAST
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="http://foo.com/images/image2.gif"/>
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>
CHK 2 6346 LAST
Content-ID: <49568.45876xxx @foo.com>
Content-Location: http://foo.com/images/image1.gif
Herriot Expires: December 1, 2001 [page 12]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<binary data>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<binary data>
CHK 0 0 LAST
5.2.2 Example of Chunking the Root Message
In this example, the compound object is represented as an
Application/Multiplexed. The message that represents the XHTML (root)
component is split across multiple chunks. The messages that contain
the image components are not split across multiple chunks.
In this example, the compound object is represented as an
Application/Multiplexed entity. The message containing the XHTML
component is split into 3 pieces so that the reference to an image is
as close as possible to the beginning of the chunk. The chunk
containing the referenced image message occurs just before the chunk
with the reference. This minimizes the distance between reference and
referenced message.
Note that there are other possible arrangements (see the third
example in section 5.2.3). For example, a sender could split the
XHTML message so that the reference to an image is as close as
possible to the end of the chunk. Then the chunk containing the
referenced image message should occur just after the chunk with the
reference. The sender could mix this strategy with the one used in
this example.
Content-Type: application/multiplexed;
Herriot Expires: December 1, 2001 [page 13]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
type="text/xhtml+xml"
CHK 1 267 MORE
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
CHK 2 6346 LAST
Content-ID: <49568.45876xxx @foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<binary data>
CHK 1 166 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<binary data>
CHK 1 80 LAST
Herriot Expires: December 1, 2001 [page 14]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
CHK 0 0 LAST
5.2.3 Example of Chunking the Several Messages
In this example, the compound object is represented as an
Application/Multiplexed. The message that represents the XHTML (root)
component is split across multiple chunks. The messages that contain
the image components are not split across multiple chunks.
In this example, the compound object is represented as an
Application/Multiplexed entity. The message containing the XHTML
component is split into 4 pieces so that the reference to an image is
as close as possible to either the beginning or the end of the chunk.
In the former case, the chunk containing the referenced image message
occurs just before the chunk with the reference (see the first two
images in this example). In the later case, the chunk containing the
referenced image message occurs just after the chunk with the
reference (see the third image in this example). This minimizes the
distance between reference and referenced message. In addition, the
first two image messages are split into two chunks each.
Content-Type: application/multiplexed;
type="text/xhtml+xml"
CHK 1 303 MORE
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
CHK 2 184 MORE
Content-ID: <49568.45876xxx @foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment
Herriot Expires: December 1, 2001 [page 15]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<first part of the binary data>
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 2 6162 LAST
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
CHK 3 6201 LAST
<second part of the binary data>
CHK 1 127 MORE
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"/>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<binary data>
CHK 1 41 LAST
</p>
<p>some final text
</p>
</body>
</html>
CHK 0 0 LAST
5.2.4 Example of Chunks with Empty Payloads
This example is identical to the previous one except that some chunks
have a chunk payload of zero octets. The root message starts with a
Herriot Expires: December 1, 2001 [page 16]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
chunk whose payload is empty and every message ends with a chunk
whose payload is empty. This example also shows two adjacent chunks
that are from the same message. These two chunks could be coalesced
into a single chunk, but they might be kept separate for programming
convenience.
Content-Type: application/multiplexed;
type="text/xhtml+xml"
CHK 1 0 MORE
CHK 2 184 MORE
Content-ID: <49568.45876xxx @foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<first part of the binary data>
CHK 1 303 MORE
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
CHK 2 6162 MORE
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
CHK 3 6201 MORE
<second part of the binary data>
CHK 2 0 LAST
CHK 3 0 LAST
Herriot Expires: December 1, 2001 [page 17]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 4 7603 MORE
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment
<binary data>
CHK 4 0 LAST
CHK 1 127 MORE
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"/>
CHK 1 41 MORE
</p>
<p>some final text
</p>
</body>
</html>
CHK 1 0 LAST
CHK 0 0 LAST
6 Receiving User Agent Requirements
See section 0 for details about how a Receiving User Agent processes
an Application/Multiplexed entity.
6.1 Storing Application/Multiplexed Entities
The Application/Multiplexed content-type will be used for objects
that have internal linkages between the messages. When the objects
are stored the linkages may require processing by the application or
its receiving user agent.
Herriot Expires: December 1, 2001 [page 18]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
6.2 Recursion
MIME is a recursive structure. Hence, it is possible for an
Application/Multiplexed entity to contain other
Application/Multiplexed entities.
6.3 Configuration Considerations
It is suggested that MUAs that use configuration mechanisms of
[RFC1524]. For an example, refer to Application/Multiplexed as
Application/Multiplexed/<type>, where <type> is the value of the
"type" parameter.
7 Security Considerations
Security considerations relevant to Application/Multiplexed are
identical to those of the underlying content-type.
8 Registration Information for Application/Multiplexed
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: Multiplexed
Required parameters: Type, a media type/subtype.
Optional parameters: No optional parameters
Encoding considerations: Application/Multiplexed content-types
cannot have encodings. But the individual
messages do 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: December 1, 2001 [page 19]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
9 Acknowledgments
The author gratefully acknowledges the contributions of: Ugo Corda,
Dave Crocker, Graham Klyne, Carl-Uno Manros, Larry Masinter, Ira
McDonald, Chris Newman, Henrik Frystyk Nielsen and Dale R. Worley.
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.
[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.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for
SyntaxSpecifications: ABNF", RFC 2234, November 1997.
[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
Herriot Expires: December 1, 2001 [page 20]
INTERNET-DRAFT Application/Multiplexed June 1, 2001
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.
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: December 1, 2001 [page 21]