Assertion | Section | Test | Quote/Description |
rfc3391-1 | 3. Details |
RFC 2775 Test List |
Application/Vnd.pwg-multiplexed entities ... use the
patterns described in [RFC2557] [to specify the relationship between entities, using the Content-ID and Content-Location headers]. See
RFC 2557 Test List
|
rfc3391-2 | 3. Details |
rfc3391-BF-01.mx |
The value of the "type" parameter must be the content-type of the root message
|
rfc3391-3 | 3 Details |
rfc3391-BF-01.mx |
An Application/Vnd.pwg-multiplexed entity contains a sequence of
chunks. Each chunk consists of a chunk header, a chunk payload and a
CRLF.
|
rfc3391-4 | 3 Details |
rfc3391-BF-01.mx |
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
|
rfc3391-5 | 3. Details |
rfc3391-BF-01.mx |
The chunk payload is a sequence of octets that is either a
complete message or a part of a message.
|
rfc3391-6 | 3. Details |
rfc3391-BF-02.mx |
When a message is split across
multiple chunks, the chunks need not be contiguous.
|
rfc3391-7 | 3. Details |
rfc3391-BF-01.mx |
The first chunk contains a complete or partial message that (in
either case) represents the root component of the compound
object.
|
rfc3391-8 | 3. Details |
rfc3391-BF-02.mx |
Additional chunks contain messages or partial messages that
represent some component of the compound object.
|
rfc3391-9 | 3. Details |
rfc3391-BF-01.mx |
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").
|
rfc3391-10 | 3. Details |
rfc3391-BF-02.mx |
A message can be broken into multiple parts and each break can occur anywhere within the message.
|
rfc3391-11 | 3. Details |
rfc3391-BF-02.mx |
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.
|
rfc3391-12 | 3. Details |
rfc3391-BF-02.mx |
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.
|
rfc3391-13 | 3. Details |
rfc3391-BF-02.mx |
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"
|
rfc3391-14 | 3.1 Syntax of Application/Vnd.pwg-multipexed Contents |
rfc3391-BF-02.mx |
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.
|
rfc3391-15 | 3.1 Syntax of Application/Vnd.pwg-multipexed Contents |
rfc3391-BF-02.mx |
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".
|
rfc3391-16 | 3.1 Syntax of Application/Vnd.pwg-multipexed Contents |
rfc3391-BF-03.mx |
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
|
rfc3391-17 | 3.2.1 The "type" Parameter |
rfc3391-BF-01.mx |
The type parameter must be specified. Its value is the content-type
of the "root" message.
|
rfc3391-18 | 4. Handling Application/Vnd.pg-meultiplexed Entities |
rfc3391-BF-04.mx
| [When] [t]he Consumer recognizes Application/Vnd.pwg-multiplexed and the
content-type of the root[,] ... the Content-Disposition
header information is redundant or even misleading, and the
Consumer shall ignore them for purposes of display.
|