RFC3391 日本語訳
3391 The MIME Application/Vnd.pwg-multiplexed Content-Type. R.Herriot. December 2002. (Format: TXT=54739 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Herriot Request for Comments: 3391 December 2002 Category: Informational
コメントを求めるワーキンググループR.エリオの要求をネットワークでつないでください: 3391 2002年12月のカテゴリ: 情報
The MIME Application/Vnd.pwg-multiplexed Content-Type
Vnd.pwgによってMIMEアプリケーション/多重送信されたコンテントタイプ
Status of this Memo
この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.
Copyright(C)インターネット協会(2002)。 All rights reserved。
IESG Note
IESG注意
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.
IESGは、このメディアタイプの使用がプロデューサーが消費者の能力と限界を百も承知しているところで状況だけで適切であると信じています。 特に、このメカニズムは消費者がいつ複合オブジェクトの特定の部品を必要とするかを知っているプロデューサーに非常に依存しています。 しかし、消費者は潜在的に多くの異なった方法で働いています、そして、異なった消費者はいろいろな時間に別物を必要とするかもしれません。 このメカニズムはプロデューサーが特定の消費者とそれらがどう設備されることになっているかに関する必要性を決定する手段を全く提供しません。
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.
消費者の能力がプロデューサーによって知られていないと、生産者と消費者との双方向のコミュニケーションができるBEEPに基づくプロトコルなどの代替のメカニズムは考えられるべきです。
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
Multipart/関連のcontent typeのように、Application/Vnd.pwgによって多重送信されたcontent typeは複数のコンポーネントから成るオブジェクトを表すのにメカニズムを提供します。 Application/Vnd.pwgによって多重送信された実体は塊の系列を含んでいます。 各塊はMIMEメッセージかMIMEメッセージの一部を含んでいます。 それぞれのMIMEメッセージは合成オブジェクトの部品を表します、ちょうどMultipart/関連の実体の身体の部分がコンポーネントを表すように。 Multipart/関連の実体で、身体の部分とある他の身体の部分でのその参照は多くの八重奏で切り離されるかもしれません。 Application/Vnd.pwgによって多重送信された実体で、ある他のメッセージにおけるメッセージとその参照は人工のかなり間近の分魂化が参照を含むメッセージであったならそうすることができます。 例えば長いメッセージである、含有
Herriot Informational [Page 1] RFC 3391 Application/Multiplexed December 2002
エリオ情報[1ページ]のRFC3391Application/多重送信された2002年12月
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.
全体の長いメッセージを消費する前に消費者が各イメージで参照を生成して、次に、Application/Vnd.pwg多重送信するまでイメージとイメージの参照を処理できるので、イメージの参照とプロデューサーは必要性を知りません。 この能力はアプリケーションを印刷して、スキャンするのにおいて重要です。 このドキュメントはApplication/Vnd.pwgの多重送信されたcontent typeを定義します。 また、それは使用に関する例を提供します。
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. 序論…2 2. 用語…7 3. 詳細…9 Vnd.pwgによってアプリケーション/多重送信されたコンテンツの3.1構文…10 アプリケーション/のための3.2のパラメタがVnd.pwg多重送信されました…12 3.2 .1 「タイプ」パラメタ…12 3.2 .2構文…12 4. Vnd.pwgによってアプリケーション/多重送信された実体を扱います…12 5. 例…13 複合か関連がある5.1の例…14 Vnd.pwgによってアプリケーション/多重送信されるのがある5.2の例…15 5.2 各塊が完全なメッセージを持っている.1の例…15 5.2 根が通信させる分魂化に関する.2の例…17 5.2 数個が通信させる分魂化に関する.3の例…18 5.2 空の有効搭載量がある塊に関する.4の例…20 6. セキュリティ問題…22 7. アプリケーション/のためのレジスト情報はVnd.pwg多重送信されました…22 8. 承認…23 9. 参照…23 10. 作者のアドレス…24 11. 完全な著作権宣言文…25
1. Introduction
1. 序論
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.
「テキスト/平野」などの簡単なMIME content typeはテキストドキュメントなどの簡単なオブジェクトを表すのにメカニズムを提供します。 Multipart/関連の[RFC2387]content typeは合成オブジェクトを表すのにメカニズムを提供します、2つのgifイメージがあるテキストドキュメントのように。
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.
合成オブジェクトは複数のコンポーネントから成ります。 そのようなコンポーネントの1つは根の成分です。(その成分は合成オブジェクトの他の部品の参照を含みます)。 これらのコンポーネントは順番に合成オブジェクトの他の部品の参照を含むかもしれません。 例えば、合成オブジェクトは根のhtmlテキスト成分と2つのgifイメージの部品から成ることができました--根の成分によってそれぞれ参照をつけられます。
Herriot Informational [Page 2] RFC 3391 Application/Multiplexed December 2002
エリオ情報[2ページ]のRFC3391Application/多重送信された2002年12月
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.
合成オブジェクトとコンポーネントは両方の抽象化です。 ワイヤの上のトランスミッションかストレージへの書くことのために、それぞれが表現を必要とします。 「複合の、または、関連の実体」は合成オブジェクトの1つの可能な表現です、そして、「身体の部分」はコンポーネントの1つの可能な表現です。
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.
しかしながら、Multipart/関連のcontent typeは根の成分における対応する参照の近くに各コンポーネントがあるのを必要とするアプリケーションのための良いソリューションではありません。 Application/Vnd.pwgによって多重送信されていた状態で、このドキュメントは新しいMIME content typeを定義します。それは、より良い解決法をいくつかのアプリケーションに提供します。 Multipart/関連のcontent typeのように、Application/Vnd.pwgの多重送信されたcontent typeは合成オブジェクトを表すのに一般的なメカニズムを提供します。 Multipart/関連の実体は境界ストリングによって切り離された身体の部分の系列から成ります。 それぞれの身体の部分は合成オブジェクトの部品を表します。 Application/Vnd.pwgによって多重送信された実体は塊の系列から成ります。(長さのそれぞれが塊のために塊ヘッダーで指定されます)。 各塊はメッセージのメッセージか一部を含んでいます。 各メッセージは合成オブジェクトの部品を表します。 異なったメッセージからの塊をはさみ込むことができます。 HTTPはワイヤの上のApplication/Vnd.pwgによって多重送信された実体のための典型的な輸送です。 接尾語が.mhtであるマイクロソフトHTML(メッセージ/rfc822)ファイルにApplication/Vnd.pwgによって多重送信された実体を保存できました。
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].
以下のパラグラフはアプリケーションに関する3つの例を含んでいます。 各アプリケーションのために、Application/Vnd.pwgによって多重送信されたcontent type、Multipart/関連のcontent type、および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.
例1: 印刷アプリケーション。 Producerが非常に長いシリーズのページ記述から成る印刷ストリームを作成して、それぞれがそれに関する参照1つであるか以上はイメージです。 根の成分は長いシリーズのページ記述です。 イメージは複数のページ記述から参照をつけられるかもしれません、そして、いつ、イメージのどんな追加参照もないかを(範囲の外にすなわち、イメージがあります)示すために、メカニズムがあります。 そのページを生成するまで、Producerは、1ページでどんなイメージを含んだらよいかを知りません。 範囲のすべてのイメージを保持できるくらいのストレージと根の成分が少なくとも1ページを処理する十分はあえてConsumerが持たれています。 Producerは、Consumerが首尾よく処理できる実体を作成するためにConsumerのストレージ能力に関する少しの知識も必要としません。 しかしながら、Producerは、いつでも範囲であるイメージの数に関して慎重である必要があります。 もちろん、悪意があるProducerはConsumerのストレージ能力を超えていようとするかもしれません、そして、Consumerはそのような実体に用心しなければなりません(セクション6を見てください)。 ここに、この合成オブジェクトを表す方法があります。
Herriot Informational [Page 3] RFC 3391 Application/Multiplexed December 2002
エリオ情報[3ページ]のRFC3391Application/多重送信された2002年12月
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.
Application/Vnd.pwgによって多重送信されたcontent typeで、各イメージはメッセージです、そして、根の成分はメッセージです。 それぞれのイメージメッセージが最初の参照のすぐ前に現れていて、Producerは根のコンポーネントメッセージを塊に細かく分けます。 Consumerが参照に遭遇すると、それは、既に以前の塊における参照をつけられたイメージを受け取ったと仮定できます。
With the Multipart/Related content-type, each image must either
precede or follow the root component.
Multipart/関連のcontent typeで、各イメージは、根の成分に先行しなければならないか、または続かなければなりません。
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.
イメージが根の成分に続くなら、そのようなイメージに参照をつける最初のページを印刷できる前にConsumerは根の成分のすべての残っているページを読まなければなりません。 Consumerは、残っているページを保持するためにそのような全体の根の成分を受けて、Consumerにはスペースがないかもしれないまでのページを印刷するのを待たなければなりません。
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.
イメージが根の成分に先行するなら、根の成分を送る前に、Producerはそのようなすべてのイメージを決定して、送らなければなりません。 根の成分の最初のページを受ける前に、いつかの追加時間、最も良い場合では、Consumerは待たなければなりません。 より悪い場合では、Consumerはすべてのイメージのための十分なストレージを持っていないかもしれません。
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.
待ち時間のためいくつかの場合、Consumerにイメージのすべてのための十分なストレージがないかもしれないのでMultipart/関連のソリューションは良いソリューションではありません。
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.
BEEPと共に、別々のチャンネルでイメージと根の成分を送ることができます。 最初の参照に遭遇すると、Producerが各イメージを押すことができますか、または最初の参照に遭遇すると、Consumerはそれを要求できます。 過剰、ワイヤ、八重奏のストリームはApplication/Vnd.pwgによって多重送信された実体と同様です。 しかしながら、印刷アプリケーションのための振舞いのかなりの違いがあります。 Application/Vnd.pwgによって多重送信された内容タイプで、Producerは、Consumerが参照に遭遇するとき、イメージがプリンタに存在しているように保証されるように、最初の参照の前にそれぞれのイメージメッセージを置きます。 Consumerがイメージを引くなら、イメージがネットワークを襲っている間、BEEPと共に、Consumerは待たなければなりません。 Producerがイメージを押すなら、最初の参照とConsumerがまだイメージを待たなければならなかったかもしれない後にBEEPはイメージメッセージを置くかもしれません。 高速プリンタは、イメージを待つ危険を冒すはずである必要はありません。 さもなければ、それは全速力で稼働できません。
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
例2: スキャン(ファックスのような)アプリケーション。 Producerはスキャナです。(そのスキャナは、各ページの参照を含むvnd.pwg- xhtml-印刷+xml根の成分と共に、ページをスキャンして、それらを送ります)。
Herriot Informational [Page 4] RFC 3391 Application/Multiplexed December 2002
エリオ情報[4ページ]のRFC3391Application/多重送信された2002年12月
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.
イメージ。 各ページはまさに根成分で一度参照をつけられます。 Consumerはvnd.pwg-xhtml-印刷+xml実体と彼らの付属を消費するプリンタです。 すなわち、Consumerは、スキャナから来る仕事を印刷するために制限されません。 ProducerとConsumerは根の成分のいくつかのページイメージを保持できるくらいのストレージがあえて持たれているそれぞれと大部分かすべてです。 Producerは、Consumerが首尾よく処理できる実体を作成するためにConsumerのストレージ能力に関する少しの追加知識も必要としません。 もちろん、悪意があるProducerはConsumerのストレージ能力を超えていようとするかもしれません、そして、Consumerはそのような実体に用心しなければなりません(セクション6を見てください)。 ここに、この合成オブジェクトを表す方法があります。
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.
Application/Vnd.pwgによって多重送信されたcontent typeで、それぞれのページイメージはメッセージです、そして、根の成分はメッセージです。 Producerはすぐ参照の前かその参照のすぐ後のそれぞれのイメージメッセージで根のコンポーネントメッセージを塊に細かく分けます。
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.
Multipart/関連のcontent typeで、Consumerには根の成分が到着するまでそれらを保存できるくらいのスペースがないかもしれないので、イメージは根の成分に先行できません。 この場合、プリンタは正しく仕事を印刷できませんでした、そして、Producerは知らないかもしれません。 したがって、イメージは根の成分に続かなければなりません、そして、最初のページを送ることができる前にProducerはすべてのページをスキャンしなければなりません。 少なくとも、すべてがスキャンされるまで、このソリューションはページの印刷を遅らせます。 最悪の場合には、Producerには、イメージをバッファリングできるくらいの記憶力がありません、そして、仕事は失敗します。
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.
BEEPと共に、問題は前の例と同じです、速度がこの場合同じくらい重要でないのを除いて。 それで、BEEPはこの例のための実行可能な代案です。
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
例3: 印刷アプリケーション。 Producerはそれぞれの一連のページ、どの参照ゼロまたは、より多くのイメージから成る印刷ストリームを作成します。 各イメージはまさに一度参照をつけられます。 そのページを生成するまで、Producerは、1ページでどんなイメージを含んだらよいかを知りません、そして、Producerはレイアウトの詳細を知りません。 Consumerはレイアウトを扱います。 Producerには、根の成分とすべてのイメージを送ることができるくらいのストレージがあります。 しかしながら、それには、全体の根の成分かイメージのどれかのすべての八重奏を保持できるくらいのストレージがないかもしれません。 根の成分をレンダリングして、各イメージを表すことができるくらいのストレージはあえてConsumerが持たれています。 それには、全体の根の成分かイメージのどれかのすべての八重奏を保持できるくらいのストレージがないかもしれません。 ProducerはConsumerのストレージ能力を決定しません。 コンポーネントをアレンジするので、Consumerはほとんど成功しそうです。 もちろん、悪意があるProducerは試みるかもしれません。
Herriot Informational [Page 5] RFC 3391 Application/Multiplexed December 2002
エリオ情報[5ページ]のRFC3391Application/多重送信された2002年12月
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.
Consumerの能力、およびConsumerが超えなければならないストレージを超えるには、そのような実体に用心してください(セクション6を見てください)。 ここに、この合成オブジェクトを表す方法があります。
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.
Application/Vnd.pwgによって多重送信されたcontent typeで、各イメージはメッセージです、そして、根の成分はメッセージです。 Producerは参照のすぐ後のそれぞれのイメージメッセージで根のコンポーネントメッセージを塊に細かく分けます。 参照が現れるので、イメージを処理する前に、Consumerは最初に、それぞれのイメージの位置を知っています。 この戦略は、ProducerとConsumerのストレージの必要性を最小にして、失敗の場合に優れた戦略を提供します。 ここに、考えるケースがあります。
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.
a) ドキュメントが各ブロックがテキストの系列かただ一つのイメージのどちらかを保管している垂直に並べられたブロックから成るとき、塊の系列は印刷可能なブロックの系列と同じです、その結果、必要性をバッファリングするConsumerを最小にします。
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.
b) ブロックがN並列しているイメージを含むことができて、Producerがイメージをはさみ込まない場合、ConsumerはN-1イメージをバッファリングしなければなりません。 Producerがイメージをはさみ込まないか、そして、N-1を受ける前のストレージからのConsumer下痢、イメージ、それが持っているものを印刷して、以下の残っているイメージを印刷できます。 しかしProducerが無よりよく意図したことでない。 Producerがイメージをはさみ込んで、Nイメージのバンドを受ける前にConsumerがストレージを使い果たすなら、Consumerは他のイメージの部分ではさみ込まれたイメージの部分を印刷するでしょう。 それで、Producerはイメージをはさみ込むはずがありません。
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.
c) ブロックが並列した状態でテキストとイメージを含むとき(すなわち、テキストを走り回ってください)、追加バッファリング要件があります。 Consumerが参照に続くテキストを処理するとき、それは、イメージ(テキストの周りで実行する)の横のそれのいくつかを置いて、残っているテキストをイメージの後に置くでしょう。 Producerは言い逃れがどこで終わるかを知らないで、またその結果、どこでテキスト塊を終わらせて、イメージ塊を出発させるかを知りません。 Producerがあまりに早くテキストを終わらせるならConsumerが残っている言い逃れテキストを得るために、全体のイメージ(それに十分なストレージがあるなら)を処理しなければならない、さもなければ、それは早まって、言い逃れテキストを終わらせます。 Producerがあまりに遅くテキストを終わらせるなら、Consumerはあまりに多くの本文を保存して、Producerが要求したより遅く、ことによるとイメージを述べなければならないかもしれません。 テキストデータがイメージデータよりかなり少ないストレージを必要とするので、Producerのための優れた戦略はイメージデータの前にあまりに少ないテキストよりむしろ発信し過ぎることの側で間違えることです。
Herriot Informational [Page 6] RFC 3391 Application/Multiplexed December 2002
エリオ情報[6ページ]のRFC3391Application/多重送信された2002年12月
d) When a block contains text and multiple side-by-side images,
the problem becomes a combination of items b) and c) above.
d) ブロックがテキストと複数の並列しているイメージを含んでいると、問題は上で項目b)とc)の組み合わせのようになります。
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.
Consumerには、失敗戦略がなければなりません、そして、Application/Vnd.pwgによって多重送信されたcontent typeはこの例で働かされることができますが、結果はいったいプロデューサーが意図したことであるかもしれないというわけではありません。 Multipart/関連のcontent typeで、Consumerには根の成分が到着するまでそれらを保存できるくらいのスペースがないかもしれないので、イメージは根の成分に先行できません。 また、最初のイメージが到着する前にConsumerには根の成分のための十分なストレージがないかもしれないので、イメージは根の成分に続くことができません。 それで、Multipart/関連のcontent typeはこの例のための許容できるソリューションではありません。
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.
BEEPと共に、Producerはチャンネル1の上の根の成分を送ることができます、そして、参照に遭遇すると、Consumerは番号付のチャンネルさえに関するイメージを要求できます。 このソリューションはApplication/Vnd.pwgによって多重送信されたcontent typeより多くの柔軟性を許容します。 並列しているイメージ、そして/または、言い逃れテキストがあれば、Consumerは別々のチャンネルの上に各イメージか言い逃れテキストのバンドを要求できます。
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.
これらの例では、全部で、Application/Vnd.pwgによって多重送信されたcontent typeはMultipart/関連であるよりはるかに良い解決法を提供します。 しかしながら、それは均等にBEEPに合わせられています。 速度が重要であり、塊の注文が遅れを印刷するのを避けるために重要であるアプリケーションにおいて、Application/Vnd.pwgによって多重送信されたcontent typeは最も良いです。 アプリケーションに、BEEPは最も良いです。そこでは、Consumerが容認された八重奏の注文の、より多くのコントロールを必要とします。
2. Terminology
2. 用語
This document uses some of the MIME terms that are defined in [RFC2045]. The following are the terms used in this document:
このドキュメントは[RFC2045]で定義されるMIME用語のいくつかを使用します。 ↓これは本書では使用される用語です:
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.
メッセージ: 同じくらい中の実体[RFC2045]。 本書では、「メッセージ」という用語は合成オブジェクトの1つの部品を表すすべての八重奏について説明します。 すなわち、それには、MIMEヘッダーと内容があります。
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".
身体の部分: aの複合の実体。 すなわち、身体の部分は、首尾でCRLFを含まない複合境界ストリングの間のヘッダーと内容(すなわち、八重奏)です。 このドキュメントは、「身体の部分」を意味するのに「実体」を決して使用しません。
Herriot Informational [Page 7] RFC 3391 Application/Multiplexed December 2002
エリオ情報[7ページ]のRFC3391Application/多重送信された2002年12月
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".
ヘッダー: 実体、メッセージまたはボディーの始線は離れています。 空の系列(すなわち、2隣接しているCRLFs)はヘッダーを終えます。 時々、「MIMEヘッダー」という用語はまさしく「ヘッダー」の代わりに使用されます。
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.
内容: ヘッダー(すなわち、2隣接しているCRLFsに続く)に続く実体、メッセージまたは身体の部分の一部分。 身体の部分の内容は複合境界ストリングの前でCRLFに先行する八重奏のときに終わります。 メッセージの内容は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.
塊: データの塊、塊ヘッダーから成る、塊ペイロード、および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.
塊ヘッダー: 塊の最初の系列。 系列は"CHK"キーワードとメッセージ番号と長さと継続インディケータ(シングルスペースキャラクタ(ASCII32)によって切り離されたそれぞれ)から成ります。 CRLFは系列を終えます。 Application/Vnd.pwgによって多重送信された実体における各メッセージには、通常、Application/Vnd.pwgによって多重送信された実体における、他のすべてのメッセージのメッセージ番号と異なっているメッセージ番号があります。 メッセージ番号0はApplication/Vnd.pwgの多重送信された実体における最終的なChunk Headerのために予約されます。
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.
塊有効搭載量: 次の塊のChunk HeaderとChunk Headerの間の八重奏。 ヘッダーの長さの分野の長さの分野はChunk有効搭載量における、八重奏の数を指定します。 Chunk有効搭載量は、メッセージの完全なメッセージか部分のどちらかです。 ヘッダーの継続欄は、塊がメッセージの最後の塊であるかどうか指定します。
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.
CRLF: 一緒に、この順で取って、ラインブレイクを指示する2の米国-ASCII文字CR(デシマル値13)とLF(デシマル値10)に対応する八重奏の系列。 CRLFは、次の塊ヘッダーから視覚分離を提供するために各塊を終えます。
Consumer: the software that receives and processes a MIME entity,
e.g., software in a printer or software that reads a file.
消費者: MIME実体を受けて、処理するソフトウェア、例えばプリンタかソフトウェアのファイルを読むソフトウェア。
Producer: the software that creates and sends a MIME entity, e.g.,
software in a scanner or software that writes a file.
プロデューサー: MIME実体を作成して、送るソフトウェア、例えば、スキャナかソフトウェアのファイルを書くソフトウェア。
Herriot Informational [Page 8] RFC 3391 Application/Multiplexed December 2002
エリオ情報[8ページ]のRFC3391Application/多重送信された2002年12月
3. Details
3. 詳細
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].
Multipart/関連であることのように、Application/Vnd.pwgによって多重送信されたcontent typeがいくつかの相互関連するコンポーネントから成る合成オブジェクトを表すことを意図します。 このドキュメントはこれらの関係の表現を指定しませんが、[RFC2557]は身体の部分とURL(「Cid」URLを含んでいる)を参照身体の部分に特定するのにコンテントIDとContent-位置のヘッダーを使用するMultipart/関連の実体に関する例を含んでいます。 Application/Vnd.pwgによって多重送信された実体が[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.
Application/Vnd.pwgによって多重送信された実体のために、コンテントタイプヘッダーへの1つのパラメタがあります。 それは「タイプ」パラメタです、そして、Multipart/関連のcontent typeのための「タイプ」パラメタに似ています。 「タイプ」パラメタの値は根のメッセージのcontent typeでなければなりません、そして、事実上、それは合成オブジェクトのタイプを指定します。
An Application/Vnd.pwg-multiplexed entity contains a sequence of chunks. Each chunk consists of a chunk header, a chunk payload and a CRLF.
Application/Vnd.pwgによって多重送信された実体は塊の系列を含んでいます。 各塊は塊ヘッダー、塊ペイロード、および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).
- 塊ヘッダーはメッセージ番号があとに続いた"CHK"キーワードから成ります、塊ペイロード長、塊がメッセージと最終的にCRLFの最後の塊であるか否かに関係なく。 長さの分野はMultipartが使用する境界ストリングの必要性を取り除きます。 (塊ヘッダーの構文に関してセクション3.1を見ます。)
- 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.
- CRLFは以下の塊から視覚分離を提供します。
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.
各メッセージは合成オブジェクトの部品を表します、そして、メッセージにはまさに同じ表現があることを意図します、八重奏のための八重奏、同じコンポーネントを表すMultipart/関連の実体の身体の部分として。 メッセージが複数の塊の向こう側に分けられるとき、塊は隣接である必要はありません。
The contents of an Application/Vnd.pwg-multiplexed entity have the following properties:
Application/Vnd.pwgによって多重送信された実体の内容には、以下の特性があります:
1) The first chunk contains a complete or partial message that (in
either case) represents the root component of the compound
object.
1) 最初の塊は合成オブジェクトの根の成分を表す(どちらかの場合で)完全であるか部分的なメッセージを含んでいます。
Herriot Informational [Page 9] RFC 3391 Application/Multiplexed December 2002
エリオ情報[9ページ]のRFC3391Application/多重送信された2002年12月
2) Additional chunks contain messages or partial messages that
represent some 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
header line is "CHK 0 0 LAST"). The final chunk contains no
chunk payload.
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.
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].
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.
See section 4 for a discussion displaying an Application/Vnd.pwg- multiplexed entity.
3.1 Syntax of Application/Vnd.pwg-multiplexed Contents
3.1 Syntax of Application/Vnd.pwg-multiplexed Contents
The ABNF [RFC2234] for the contents of an Application/Vnd.pwg- multiplexed entity is:
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
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
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 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 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.
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".
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.
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.
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.
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
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
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.
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
3.2 Parameters for Application/Vnd.pwg-multiplexed
This section defines additional parameters for Application/Vnd.pwg- multiplexed.
This section defines additional parameters for Application/Vnd.pwg- multiplexed.
3.2.1 The "type" Parameter
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.
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
3.2.2 Syntax
The syntax for "parameter" is:
The syntax for "parameter" is:
parameter := "type" "=" type "/" subtype ; cf. [RFC2045]
parameter := "type" "=" type "/" subtype ; cf. [RFC2045]
4. Handling Application/Vnd.pwg-multiplexed Entities
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.
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.
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:
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
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
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.
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.
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.
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
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.
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.
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
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.
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.
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
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.
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"
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
--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>
<?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
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
<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.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 Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Disposition: attachment
<<binary data>> --boundary-example--
<<binary data>> --boundary-example--
5.2 Examples with Application/Vnd.pwg-multiplexed
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.
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
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.
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"
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
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
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>
<?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
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 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 4 7603 LAST Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Disposition: attachment
<<binary data>> CHK 0 0 LAST
<<binary data>> CHK 0 0 LAST
Herriot Informational [Page 16] RFC 3391 Application/Multiplexed December 2002
Herriot Informational [Page 16] RFC 3391 Application/Multiplexed December 2002
5.2.2 Example of Chunking the Root Message
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.
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.
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"
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
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
<?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
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 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
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
<<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
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>
<<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
CHK 0 0 LAST
5.2.3 Example of Chunking the Several Messages
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.
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"
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
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
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
<?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
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 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"/>
<<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 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
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
Herriot Informational [Page 19] RFC 3391 Application/Multiplexed December 2002
<<binary data>>
CHK 1 41 LAST
</p>
<p>some final text
</p>
</body>
</html>
<<binary data>> CHK 1 41 LAST </p> <p>some final text </p> </body> </html>
CHK 0 0 LAST
CHK 0 0 LAST
5.2.4 Example of Chunks with Empty Payloads
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.
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"
Content-Type: application/vnd.pwg-multiplexed; type=" application/vnd.pwg-xhtml-print+xml"
CHK 1 0 MORE
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
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 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
<<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
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
<?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 2 6162 MORE <<part of binary data>> CHK 3 6201 MORE <<part of binary data>> CHK 2 0 LAST
CHK 3 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 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
CHK 4 7603 MORE Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Disposition: attachment
<<binary data>> CHK 4 0 LAST
<<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 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 41 MORE </p> <p>some final text </p> </body> </html>
CHK 1 0 LAST
CHK 1 0 LAST
CHK 0 0 LAST
CHK 0 0 LAST
Herriot Informational [Page 21] RFC 3391 Application/Multiplexed December 2002
Herriot Informational [Page 21] RFC 3391 Application/Multiplexed December 2002
6. Security Considerations
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 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:
また、全体でApplication/Vnd.pwgによって多重送信された実体に関係するセキュリティ問題があります。 バギーであるか、または悪意があるProducerはConsumerがそれより多くの格納がそうしたよう要求できたApplication/Vnd.pwgによって多重送信された実体を送るかもしれません、それに多量の格納があっても。 Consumerは優雅にそれらの以下のシナリオと組み合わせに対処できなければなりません:
- 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.
- 1つ以上のメッセージの塊は非常に多くの八重奏で切り離されます。 メッセージの極端な場合にはいくつかかすべてが終わりません、すなわち、それらは終わりの塊を含んでいません。 - それらの最終的な塊が起こる前に、非常に多くのメッセージが、始められて、はさみ込まれます。 - メッセージは起こるか、または多くの八重奏のために決して現れない他のメッセージの1つ以上の参照箇所を含んでいます。 - Consumerが、それらを捨てることができるのを知る前に非常に多くの参照をつけられたメッセージが現れます。
7. Registration Information for Application/Vnd.pwg-multiplexed
7. アプリケーション/のためのレジスト情報はVnd.pwg多重送信されました。
The following form is copied from RFC 1590, Appendix A.
Appendix A、以下のフォームはRFC1590からコピーされます。
To: iana@iana.org
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
Subject: Typeが命名するVnd.pwgによって新しいメディアTypeアプリケーション/多重送信されたメディアの登録: アプリケーションメディア「副-タイプ」は以下を命名します。 業者Tree--vnd.pwgによって多重送信されたRequiredパラメタ: タイプ、メディアタイプ/「副-タイプ」。 任意のパラメタ: 任意のパラメタEncoding問題がありません: メッセージのContentタイプによって許容されたどんな方法でもApplication/Vnd.pwgによって多重送信された実体に関する各メッセージをコード化できます。 しかしながら、Multipartの推理を使用して、Application/Vnd.pwgによって多重送信された実体をコード化できません。 さもなければ、メッセージはそうでしょう。
Herriot Informational [Page 22] RFC 3391 Application/Multiplexed December 2002
エリオ情報[22ページ]のRFC3391Application/多重送信された2002年12月
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:
いったんメッセージレベルにおいてApplication/Vnd.pwgによって多重送信されたレベルで一度と、二度コード化されます。 セキュリティ問題: RFC3391のセクション6(セキュリティConsiderations)を見てください。 広められた仕様: RFC3391。 詳細のために連絡する人とEメールアドレス:
Robert Herriot
706 Colorado Ave.
Palo Alto, CA 94303
USA
Phone: 1-650-327-4466
Fax: 1-650-327-4466
EMail: bob@herriot.com
ロバートエリオ706コロラドAve。 カリフォルニア94303パロアルト(米国)は以下に電話をします。 1-650-327-4466 Fax: 1-650-327-4466 メールしてください: bob@herriot.com
8. Acknowledgments
8. 承認
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.
作者は感謝して以下の貢献を承諾します。 ウーゴCorda、デーヴ・クロッカー、メリンダスーGrant、グラハムKlyne、カール-宇野Manros、ラリーMasinter、イラ・マクドナルド、クリス・ニューマン、Henrik Frystykニールセン、およびデール・R.ウォーリー。 特に、クリス・ニューマンは非常に貴重な助けを提供しました。
9. References
9. 参照
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 1995.
[RFC1806] Troost、R.、およびS.デルナー、「インターネットでプレゼンテーション情報を伝えるのは通信します」。 「満足している気質ヘッダー」、RFC1806、1995年6月。
[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.
[RFC1873]レヴィンソンとE.とJ.クラーク、「外部のボディーメッセージ/内容IDアクセス型」、RFC1873、1995年12月。 レヴィンソン、E.、「外部のメッセージ/ボディーコンテントIDアクセス型」が進行中で働いています。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for
SyntaxSpecifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「SyntaxSpecificationsのための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2387, August 1998.
[RFC2387]レヴィンソン、1998年8月のE.、「MIMEの複合の、または、関連の文書内容」RFC2387。
Herriot Informational [Page 23] RFC 3391 Application/Multiplexed December 2002
エリオ情報[23ページ]のRFC3391Application/多重送信された2002年12月
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[RFC2392] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2392、1998年8月。
[RFC2557] Palme, J., "MIME Encapsulation of Aggregate Documents, such
as HTML (MHTML", RFC 2557, March 1999.
[RFC2557]パルメ、J.、「HTMLなどのAggregate DocumentsのMIME Encapsulation、(MHTML、」、RFC2557、3月1999日
[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エディタ、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[RFC3080] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
10. Author's Address
10. 作者のアドレス
Robert Herriot 706 Colorado Ave. Palo Alto, CA 94303 USA
ロバートエリオ706コロラドAve。 パロアルト、カリフォルニア94303米国
Phone: 1-650-327-4466 Fax: 1-650-327-4466 EMail: bob@herriot.com
以下に電話をしてください。 1-650-327-4466 Fax: 1-650-327-4466 メールしてください: bob@herriot.com
Herriot Informational [Page 24] RFC 3391 Application/Multiplexed December 2002
エリオ情報[24ページ]のRFC3391Application/多重送信された2002年12月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Herriot Informational [Page 25]
エリオInformationalです。[25ページ]
一覧
スポンサーリンク
