doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc3391.txt b/doc/rfc/rfc3391.txt
new file mode 100644
index 0000000..00f43d5
--- /dev/null
+++ b/doc/rfc/rfc3391.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                         R. Herriot
+Request for Comments: 3391                                 December 2002
+Category: Informational
+
+
+         The MIME Application/Vnd.pwg-multiplexed Content-Type
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+IESG Note
+
+   The IESG believes use of this media type is only appropriate in
+   situations where the producer is fully aware of the capabilities and
+   limitations of the consumer.  In particular, this mechanism is very
+   dependent on the producer knowing when the consumer will need a
+   particular component of a multipart object.  But consumers
+   potentially work in many different ways and different consumers may
+   need different things at different times.  This mechanism provides no
+   means for a producer to determine the needs of a particular consumer
+   and how they are to be accommodated.
+
+   Alternative mechanisms, such as a protocol based on BEEP which is
+   capable of bidirectional communication between the producer and
+   consumer, should be considered when the capabilities of the consumer
+   are not known by the producer.
+
+Abstract
+
+   The Application/Vnd.pwg-multiplexed content-type, like the
+   Multipart/Related content-type, provides a mechanism for representing
+   objects that consist of multiple components.  An
+   Application/Vnd.pwg-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
+   a Multipart/Related entity, a body part and its reference in some
+   other body part may be separated by many octets.  With an
+   Application/Vnd.pwg-multiplexed entity, a message and its reference
+   in some other message can be made quite close by chunking the message
+   containing the reference.  For example, if a long message contains
+
+
+
+Herriot                      Informational                      [Page 1]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   references to images and the producer does not know of the need for
+   each image until it generates the reference, then
+   Application/Vnd.pwg-multiplexed allows the consumer to process the
+   reference to the image and the image before it consumes the entire
+   long message.  This ability is important in printing and scanning
+   applications.  This document defines the Application/Vnd.pwg-
+   multiplexed content-type. It also provides examples of its use.
+
+Table of Contents
+
+   1. Introduction....................................................2
+   2. Terminology.....................................................7
+   3. Details.........................................................9
+   3.1  Syntax of Application/Vnd.pwg-multiplexed Contents...........10
+   3.2  Parameters for Application/Vnd.pwg-multiplexed...............12
+   3.2.1  The "type" Parameter.......................................12
+   3.2.2  Syntax.....................................................12
+   4. Handling Application/Vnd.pwg-multiplexed Entities..............12
+   5. Examples.......................................................13
+   5.1  Example With Multipart/Related...............................14
+   5.2  Examples with Application/Vnd.pwg-multiplexed................15
+   5.2.1  Example Where Each Chunk Has a Complete Message............15
+   5.2.2  Example of Chunking the Root Message.......................17
+   5.2.3  Example of Chunking the Several Messages...................18
+   5.2.4  Example of Chunks with Empty Payloads......................20
+   6. Security Considerations........................................22
+   7. Registration Information for Application/Vnd.pwg-multiplexed...22
+   8. Acknowledgments................................................23
+   9. References.....................................................23
+   10. Author's Address..............................................24
+   11. Full Copyright Statement......................................25
+
+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.
+
+   A compound object consists of multiple components.  One such
+   component is the 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 image components -- each referenced by the root
+   component.
+
+
+
+
+Herriot                      Informational                      [Page 2]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   A compound object and a component are both abstractions.  For
+   transmission over the wire or writing to storage, 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.
+
+   However, the Multipart/Related content-type is not a good solution
+   for applications that require each component to be close to its
+   corresponding reference in the root component.  This document defines
+   a new MIME content-type Application/Vnd.pwg-multiplexed that provides
+   a better solution for some applications.  The Application/Vnd.pwg-
+   multiplexed content-type, like the Multipart/Related content-type,
+   provides a common mechanism for representing a compound object.  A
+   Multipart/Related entity consists of a sequence of body parts
+   separated by boundary strings.  Each body part represents a component
+   of the compound object.  An Application/Vnd.pwg-multiplexed entity
+   consists of 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.  HTTP is the
+   typical transport for an Application/Vnd.pwg-multiplexed entity over
+   the wire.  An Application/Vnd.pwg-multiplexed entity could be stored
+   in a Microsoft HTML (message/rfc822) file whose suffix is .mht.
+
+   The following paragraphs contain three examples of applications.  For
+   each application, there is a discussion of its solution with the
+   Application/Vnd.pwg-multiplexed content-type, the Multipart/Related
+   content-type and BEEP [RFC3080].
+
+   Example 1: a printing application.  A Producer creates a print stream
+   that consists of a very long series of page descriptions, each of
+   which references one or more images.  The root component is the long
+   series of page descriptions.  An image may be referenced from
+   multiple pages descriptions, and there is a mechanism to indicate
+   when there are no additional references to an image (i.e., the image
+   is out of scope).  The Producer does not know what images to include
+   with a page until it generates that page.  The Consumer is presumed
+   to have enough storage to hold all in-scope images and enough of the
+   root component to process at least one page.  The Producer doesn't
+   need any knowledge of the Consumer's storage capabilities in order to
+   create an entity that the Consumer can successfully process.
+   However, the Producer needs to be prudent about the number of images
+   that are in-scope at any time.  Of course, a malicious Producer may
+   try to exceed the storage capabilities of the Consumer, and the
+   Consumer must guard against such entities (see section 6).  Here are
+   ways to represent this compound object.
+
+
+
+
+
+Herriot                      Informational                      [Page 3]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+      With the Application/Vnd.pwg-multiplexed content-type, each image
+      is a message and the root component is a message.  The Producer
+      breaks the root component message into chunks with each image
+      message occurring shortly before its first reference.  When the
+      Consumer encounters a reference, it can assume that it has already
+      received the referenced image in an earlier chunk.
+
+      With the Multipart/Related content-type, each image must either
+      precede or follow the root component.
+
+         If images follow the root component, the Consumer must read all
+         remaining pages of the root component before it can print the
+         first page that references such images.  The Consumer must wait
+         to print such a page until it has received the entire root
+         component, and the Consumer may not have the space to hold the
+         remaining pages.
+
+         If images precede the root component, the Producer must
+         determine and send all such images before it sends the root
+         component.  The Consumer must, in the best case, wait some
+         additional time before it receives the first page of the root
+         component.  In the worse case, the Consumer may not have enough
+         storage for all the images.
+
+         The Multipart/Related solution is not a good solution because
+         of the wait time and because, in some cases, the Consumer may
+         not have sufficient storage for all of the images.
+
+      With BEEP, the images and root component can be sent in separate
+      channels.  The Producer can push each image when it encounters the
+      first reference or the Consumer can request it when it encounters
+      the first reference.  The over-the-wire stream of octets is
+      similar to an Application/Vnd.pwg-multiplexed entity.  However,
+      there is a substantial difference in behavior for a printing
+      application.  With the Application/Vnd.pwg-multiplexed content-
+      type, the Producer puts each image message before its first
+      reference so that when the Consumer encounters a reference, the
+      image is guaranteed to be present on the printer.  With BEEP, if
+      the Consumer pulls the image, the Consumer has to wait while the
+      image comes over the network.  If the Producer pushes the image,
+      BEEP may put the image message after its first reference and the
+      Consumer may still have to wait for the image.  A high-speed
+      printer should not have to risk waiting for images; otherwise it
+      cannot run at full speed.
+
+   Example 2: a scanning (fax-like) application.  The Producer is a
+   scanner, which scans pages and sends them along with a vnd.pwg-
+   xhtml-print+xml root component that contains references to each page
+
+
+
+Herriot                      Informational                      [Page 4]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   image.  Each page is referenced exactly once in the root-component.
+   The Consumer is a printer that consumes vnd.pwg-xhtml-print+xml
+   entities and their attachments.  That is, the Consumer is not limited
+   to print jobs that come from scanners.  A Producer and Consumer are
+   each presumed to have enough storage to hold a few page images and
+   most if not all of the root component.  The Producer doesn't need any
+   additional knowledge of the Consumer's storage capabilities in order
+   to create an entity that the Consumer can successfully process.  Of
+   course, a malicious Producer may try to exceed the storage
+   capabilities of the Consumer and the Consumer must guard against such
+   entities (see section 6).  Here are ways to represent this compound
+   object.
+
+      With the Application/Vnd.pwg-multiplexed content-type, each page
+      image is a message and the root component is a message.  The
+      Producer breaks the root component message into chunks with each
+      image message just before or just after its reference.
+
+      With the Multipart/Related content-type, the images cannot precede
+      the root component because the Consumer might not have enough
+      space to store them until the root component arrived.  In this
+      case, the printer could fail to print the job correctly and the
+      Producer might not know.  Therefore the images must follow the
+      root component, and the Producer must scan all pages before it can
+      send the first page.  At the very least, this solution delays the
+      printing of the pages until all have been scanned.  In the worst
+      case, the Producer does not have sufficient memory to buffer the
+      images, and the job fails.
+
+      With BEEP, the issues are the same as in the previous example,
+      except that speed is not as important in this case.  So BEEP is a
+      viable alternative for this example.
+
+   Example 3: a printing application.  A Producer creates a print stream
+   that consists of a series of pages, each of which references zero or
+   more images.  Each image is referenced exactly once.  The Producer
+   does not know what images to include with a page until it generates
+   that page, and the Producer doesn't know the layout details; the
+   Consumer handles layout.  The Producer has enough storage to send the
+   root component and all images.  However, it may not have enough
+   storage to hold the entire root component or all octets of any of the
+   images.  The Consumer is presumed to have enough storage to render
+   the root component and to render each image.  It may not have enough
+   storage to hold the entire root component or all octets of any of the
+   images.  The Producer doesn't determine the Consumer's storage
+   capabilities.  Rather it arranges the components so that the Consumer
+   is mostly likely to succeed.  Of course, a malicious Producer may try
+
+
+
+
+Herriot                      Informational                      [Page 5]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   to exceed the storage capabilities of the Consumer, and the Consumer
+   must guard against such entities (see section 6).  Here are ways to
+   represent this compound object.
+
+      With the Application/Vnd.pwg-multiplexed content-type, each image
+      is a message and the root component is a message.  The Producer
+      breaks the root component message into chunks with each image
+      message just after its reference.  The references appear first so
+      that the Consumer knows the location of each image before it
+      processes the image.  This strategy minimizes storage needs for
+      Producer and Consumer and provides a good strategy in case of
+      failure.  Here are the cases to consider.
+
+      a) When the document consists of vertically aligned blocks where
+         each block contains either lines of text or a single image, the
+         sequence of chunks is the same as the sequence of printable
+         blocks, thus minimizing Consumer buffering needs.
+
+      b) When a block can contain N side-by-side images, the Consumer
+         must buffer N-1 images unless the Producer interleaves the
+         images.  If the Producer doesn't interleave the images, and the
+         Consumer runs out of storage before it has received N-1,
+         images, it can print what it has and print the remaining images
+         below; not what the Producer intended, but better than nothing.
+         If the Producer interleaves images, and the Consumer runs out
+         of storage before it has received the bands of N images, the
+         Consumer would print portions of images interleaved with
+         portions of other images.  So, a Producer should not interleave
+         images.
+
+      c) When a block contains text and image side-by-side (i.e., run-
+         around text), there are additional buffering requirements.
+         When the Consumer processes the text that follows the
+         reference, it will place some of it next to the image (run-
+         around text) and will place the remaining text after the image.
+         The Producer doesn't know where the run-around ends, and thus
+         doesn't know where to end the text chunk and start the image
+         chunk.  If the Producer ends the text too soon, then the
+         Consumer either has to process the entire image (if it has
+         enough storage) in order to get the remaining run-around text,
+         or it ends the run-around text prematurely.  If the Producer
+         ends the text too late, then the Consumer may have to store too
+         much text and possibly put the image later than the Producer
+         requested.  Because text data requires significantly less
+         storage than image data, a good strategy for Producer is to err
+         on the side of sending too much rather than too little text
+         before the image data.
+
+
+
+
+Herriot                      Informational                      [Page 6]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+      d) When a block contains text and multiple side-by-side images,
+         the problem becomes a combination of items b) and c) above.
+
+      The Application/Vnd.pwg-multiplexed content-type can be made to
+      work in this example, but a Consumer must have failure strategies
+      and the result may not be quite what the producer intended.  With
+      the Multipart/Related content-type, the images cannot precede the
+      root component because the Consumer might not have enough space to
+      store them until the root component arrived.  Also, the images
+      cannot follow the root component because the Consumer might not
+      have enough storage for the root component before the first image
+      arrives.  So the Multipart/Related content-type is not an
+      acceptable solution for this example.
+
+      With BEEP, the Producer can send the root component on channel 1
+      and the Consumer can request images on even numbered channels when
+      it encounters a reference.  This solution allows more flexibility
+      than the Application/Vnd.pwg-multiplexed content-type.  If there
+      are side-by-side images and/or run-around text, the Consumer can
+      request bands of each image or run-around text over separate
+      channels.
+
+   In all of these examples, the Application/Vnd.pwg-multiplexed
+   content-type provides a much better solution than Multipart/Related.
+   However, it is evenly matched with BEEP.  For applications where
+   speed is important and ordering of the chunks is important in order
+   to avoid printing delays, the Application/Vnd.pwg-multiplexed
+   content-type is best.  For applications, where the Consumer needs
+   more control over the ordering of received octets, BEEP is best.
+
+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.
+
+      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".
+
+
+
+
+Herriot                      Informational                      [Page 7]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+      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.
+
+   This document uses the following additional terms.
+
+      Chunk: a chunk of data, consisting of a chunk header, a chunk
+      payload and a CRLF.
+
+      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 space character (ASCII 32).
+      A CRLF terminates the line.  Each message in an
+      Application/Vnd.pwg-multiplexed entity has a message number that
+      normally differs from the message numbers of all other messages in
+      the Application/Vnd.pwg-multiplexed entity.  The message number 0
+      is reserved for final Chunk Header in the Application/Vnd.pwg-
+      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 number of octets in the Chunk Payload.  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.
+
+      CRLF: the sequence of octets corresponding to the two US-ASCII
+      characters CR (decimal value 13) and LF (decimal value 10) which,
+      taken together, in this order, denote a line break.  A CRLF
+      terminates each chunk in order to provide visual separation from
+      the next chunk header.
+
+      Consumer: the software that receives and processes a MIME entity,
+      e.g., software in a printer or software that reads a file.
+
+      Producer: the software that creates and sends a MIME entity, e.g.,
+      software in a scanner or software that writes a file.
+
+
+
+
+
+
+
+
+Herriot                      Informational                      [Page 8]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+3. Details
+
+   The Application/Vnd.pwg-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/Vnd.pwg-multiplexed entities would use the
+   patterns described in [RFC2557].
+
+   For an Application/Vnd.pwg-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/Vnd.pwg-multiplexed entity contains a sequence of
+   chunks.  Each chunk consists of a chunk header, a chunk payload and a
+   CRLF.
+
+     - 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 CRLF.  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 CRLF 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/Vnd.pwg-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.
+
+
+
+
+
+Herriot                      Informational                      [Page 9]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+      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
+         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/Vnd.pwg-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.  If a message
+         contains no Content-Type header, then the message has an
+         implicit content-type of  "text/plain; charset=us-ascii", cf.
+         [RFC2045].
+
+   See section 4 for a discussion displaying an Application/Vnd.pwg-
+   multiplexed entity.
+
+3.1 Syntax of Application/Vnd.pwg-multiplexed Contents
+
+   The ABNF [RFC2234] for the contents of an Application/Vnd.pwg-
+   multiplexed entity is:
+
+   contents = *chunk finalChunk
+   chunk      = header payload CRLF
+   header     = "CHK" SP messageNumber SP length SP isMore CRLF
+   messageNumber   = 1..2147483647
+   length   = 0..2147483647
+   isMore       = "MORE" / "LAST"
+   payload    = *OCTET
+   finalChunk = finalHeader CRLF
+   finalHeader  = "CHK" SP "0" SP "0" SP "LAST" CRLF
+
+
+
+
+
+
+
+Herriot                      Informational                     [Page 10]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   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 CRLF 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.
+
+   Normally each message in an Application/Vnd.pwg-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 Consumer 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 occurs.
+
+   Two adjacent chunks usually have different message numbers.  However,
+   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/Vnd.pwg-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/Vnd.pwg-multiplexed entity contain the root message or a
+
+
+
+Herriot                      Informational                     [Page 11]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   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/Vnd.pwg-multiplexed
+
+   This section defines additional parameters for Application/Vnd.pwg-
+   multiplexed.
+
+3.2.1 The "type" Parameter
+
+   The type parameter must be specified.  Its value is the content-type
+   of the "root" message.  It permits a Consumer 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 Consumer's behavior is undefined.
+
+3.2.2 Syntax
+
+   The syntax for "parameter" is:
+
+     parameter   := "type"  "=" type "/" subtype ; cf. [RFC2045]
+
+4. Handling Application/Vnd.pwg-multiplexed Entities
+
+   The application that handles the Application/Vnd.pwg-multiplexed
+   entity has the responsibility for displaying the entity.  However,
+   Application/Vnd.pwg-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/Vnd.pwg-
+   multiplexed entities:
+
+      a) The Consumer recognizes Application/Vnd.pwg-multiplexed and the
+         content-type of the root.  The Consumer determines the
+         presentation style for the compound object; it handles the
+         display of the components of the compound object in the context
+
+
+
+Herriot                      Informational                     [Page 12]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+         of the compound object.  In this case, the Content-Disposition
+         header information is redundant or even misleading, and the
+         Consumer shall ignore them for purposes of display.  The
+         Consumer may use the suggested file name if the entity is
+         stored.
+
+      b) The Consumer recognizes Application/Vnd.pwg-multiplexed, but
+         not the content-type of the root.  The Consumer will give the
+         user the choice of suppressing the entire Application/Vnd.pwg-
+         multiplexed entity or treating the Application/Vnd.pwg-
+         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 Consumer 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 Consumer
+         should display the body part as an attachment.
+
+      c) The Consumer does not recognize Application/Vnd.pwg-
+         multiplexed.  The Consumer treats the Application/Vnd.pwg-
+         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.
+   The images are encoded in binary.  The string "<<binary data>>" and
+   "<<part of binary data>>" in each example represents all or part of
+   the binary data of each image.  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/Vnd.pwg-
+   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.
+
+
+
+
+Herriot                      Informational                     [Page 13]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   The last example may seem to address useless cases, but sometimes it
+   is easier to write software if these cases are allowed.  For example,
+   when a buffer fills, it may be easiest to write a chunk and not worry
+   if the previous chunk had the same message number.  Likewise, it may
+   be easiest to end a message with an empty chunk.  Finally, the
+   Application/Vnd.pwg-multiplexed content-type requires that the first
+   chunk be part of the root message.  Sometimes, it is more convenient
+   for the Producer if the root message starts after the occurrence of
+   some attachments.  Since a chunk can be empty, the first chunk of the
+   root message can be empty, i.e., it doesn't even contain any headers.
+   Then the first chunk contains a part of the root message, but the
+   Producer doesn't generate any octets for that chunk.
+
+   Each body part of the Multipart/Related entity and each message of
+   the Application/Vnd.pwg-multiplexed entity contain a content-
+   disposition, which the Consumer uses according to the rules in
+   section 4.  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/Vnd.pwg-multiplexed entities.
+
+   Content-Type: multipart/related; boundary="boundary-example";
+                 type="text/xhtml+xml"
+
+   --boundary-example
+   Content-ID: <49568.44343xxx@foo.com>
+   Content-Type: application/vnd.pwg-xhtml-print+xml
+   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>
+
+
+
+Herriot                      Informational                     [Page 14]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+         <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-Disposition: attachment
+
+   <<binary data>>
+   --boundary-example
+   Content-ID: <49568.46000xxx@foo.com>
+   Content-Location: http://foo.com/images/image2.gif
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<binary data>>
+   --boundary-example
+   Content-ID: <49568.47333xxx@foo.com>
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<binary data>>
+   --boundary-example--
+
+5.2 Examples with Application/Vnd.pwg-multiplexed
+
+   The four examples in this section show Application/Vnd.pwg-
+   multiplexed representations of the same compound object.  Note that
+   each CRLF 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/Vnd.pwg-multiplexed entity.  Each chunk contains an
+   entire message, i.e., none of the messages are 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/vnd.pwg-multiplexed;
+                 type="application/vnd.pwg-xhtml-print+xml"
+
+   CHK 1 550 LAST
+   Content-ID: <49568.44343xxx@foo.com>
+   Content-Type: application/vnd.pwg-xhtml-print+xml
+   Content-Disposition: inline
+
+
+
+
+Herriot                      Informational                     [Page 15]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   <?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
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<binary data>>
+   CHK 3 6401 LAST
+   Content-ID: <49568.46000xxx@foo.com>
+   Content-Location: http://foo.com/images/image2.gif
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<binary data>>
+   CHK 4 7603 LAST
+   Content-ID: <49568.47333xxx@foo.com>
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<binary data>>
+   CHK 0 0 LAST
+
+
+
+
+
+
+
+
+
+
+Herriot                      Informational                     [Page 16]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+5.2.2 Example of Chunking the Root Message
+
+   In this example, the compound object is represented as an
+   Application/Vnd.pwg-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/vnd.pwg-multiplexed;
+                 type=" application/vnd.pwg-xhtml-print+xml"
+
+   CHK 1 267 MORE
+   Content-ID: <49568.44343xxx@foo.com>
+   Content-Type: application/vnd.pwg-xhtml-print+xml
+   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-Disposition: attachment
+
+   <<binary data>>
+   CHK 3 6401 LAST
+   Content-ID: <49568.46000xxx@foo.com>
+   Content-Location: http://foo.com/images/image2.gif
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+
+
+
+
+
+Herriot                      Informational                     [Page 17]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   <<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-Disposition: attachment
+
+   <<binary data>>
+   CHK 1 80 LAST
+            <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/Vnd.pwg-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.  The references to the first and second images closely
+   follow the referenced images.  The reference to the third image
+   closely precedes the referenced image.  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/vnd.pwg-multiplexed;
+                 type=" application/vnd.pwg-xhtml-print+xml"
+
+   CHK 1 303 MORE
+   Content-ID: <49568.44343xxx@foo.com>
+   Content-Type: application/vnd.pwg-xhtml-print+xml
+   Content-Disposition: inline
+
+
+
+
+
+
+Herriot                      Informational                     [Page 18]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   <?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-Disposition: attachment
+
+   <<part of binary data>>
+   CHK 3 200 MORE
+   Content-ID: <49568.46000xxx@foo.com>
+   Content-Location: http://foo.com/images/image2.gif
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<part of 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
+   <<part of binary data>>
+   CHK 3 6201 LAST
+   <<part of 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-Disposition: attachment
+
+
+
+
+
+
+
+
+
+
+Herriot                      Informational                     [Page 19]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   <<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 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/vnd.pwg-multiplexed;
+                 type=" application/vnd.pwg-xhtml-print+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-Disposition: attachment
+
+   <<part of binary data>>
+   CHK 3 200 MORE
+   Content-ID: <49568.46000xxx@foo.com>
+   Content-Location: http://foo.com/images/image2.gif
+   Content-Type: image/gif
+   Content-Disposition: attachment
+
+   <<part of binary data>>
+   CHK 1 303 MORE
+   Content-ID: <49568.44343xxx@foo.com>
+   Content-Type: application/vnd.pwg-xhtml-print+xml
+   Content-Disposition: inline
+
+
+
+
+
+
+
+
+Herriot                      Informational                     [Page 20]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   <?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
+   <<part of binary data>>
+   CHK 3 6201 MORE
+   <<part of binary data>>
+   CHK 2 0 LAST
+
+   CHK 3 0 LAST
+
+   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-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
+
+
+
+
+
+
+Herriot                      Informational                     [Page 21]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+6. Security Considerations
+
+   There are security considerations that pertain to each message of an
+   Application/Vnd.pwg-multiplexed entity.  Those security
+   considerations are described by the document that defines the
+   content-type of the message.  They are not addressed in this
+   document.
+
+   There are also security considerations that pertain to the
+   Application/Vnd.pwg-multiplexed entity as a whole.  A Producer that
+   is buggy or malicious may send an Application/Vnd.pwg-multiplexed
+   entity that could cause a Consumer to request more storage than it
+   has, even if it has a large amount of storage.  A Consumer must be
+   able to deal gracefully with the following scenarios and combinations
+   of them:
+
+     - The chunks of one or more messages are separated by a very large
+       number of octets.  In the extreme case some or all of the
+       messages don't terminate, i.e., they don't contain a closing
+       chunk.
+     - A very large number of messages are started and interleaved
+       before their final chunk occurs.
+     - A message contains one or more references to other messages that
+       never occur or don't occur for a large number of octets.
+     - A very large number of referenced messages occur before the
+       Consumer knows that it can discard them.
+
+7. Registration Information for Application/Vnd.pwg-multiplexed
+
+   The following form is copied from RFC 1590, Appendix A.
+
+     To: iana@iana.org
+
+     Subject:           Registration of new Media Type
+                        application/Vnd.pwg-multiplexed
+     Media Type name:   Application
+     Media subtype name:     Vendor Tree - vnd.pwg-multiplexed
+     Required parameters:    Type, a media type/subtype.
+     Optional parameters:    No optional parameters
+     Encoding considerations:    Each message of an
+                         Application/Vnd.pwg-multiplexed entity can be
+                         encoded in any manner allowed by the Content-
+                         Type of the message.  However, using the
+                         reasoning of Multipart, the
+                         Application/Vnd.pwg-multiplexed entity cannot
+                         be encoded.  Otherwise, a message would be
+
+
+
+
+
+Herriot                      Informational                     [Page 22]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+                         encoded twice, once at the message level and
+                         once at the Application/Vnd.pwg-multiplexed
+                         level.
+     Security considerations:    See section 6 (Security
+                                 Considerations) of RFC 3391.
+     Published specification:    RFC 3391.
+     Person & email address to contact for further information:
+
+         Robert Herriot
+         706 Colorado Ave.
+         Palo Alto, CA 94303
+         USA
+         Phone: 1-650-327-4466
+         Fax: 1-650-327-4466
+         EMail: bob@herriot.com
+
+8. Acknowledgments
+
+   The author gratefully acknowledges the contributions of: Ugo Corda,
+   Dave Crocker, Melinda Sue Grant, 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.
+
+9. References
+
+   [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. and N. Borenstein, "Multipurpose Internet Mail
+             Extensions (MIME) Part One: Format of Internet Message
+             Bodies", RFC 2045, November 1996.
+
+   [RFC2046] Freed, N. and N. Borenstein, "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.
+
+
+
+
+Herriot                      Informational                     [Page 23]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+   [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.
+
+   [RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822,
+             April 2001.
+
+   [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
+             RFC 3080, March 2001.
+
+10. Author's Address
+
+   Robert Herriot
+   706 Colorado Ave.
+   Palo Alto, CA 94303
+   USA
+
+   Phone: 1-650-327-4466
+   Fax: 1-650-327-4466
+   EMail: bob@herriot.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot                      Informational                     [Page 24]
+
+RFC 3391                Application/Multiplexed            December 2002
+
+
+11. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herriot                      Informational                     [Page 25]
+