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.
著作権（C）インターネット協会（2002）。全著作権所有。
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 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.
アプリケーション/ Vnd.pwg多重コンテンツタイプは、マルチパート/関連コンテンツ・タイプのような、複数のコンポーネントで構成されたオブジェクトを表すためのメカニズムを提供します。アプリケーション/ Vnd.pwg多重エンティティはチャンクの配列を含みます。各チャンクは、MIMEメッセージやMIMEメッセージの一部が含まれています。各MIMEメッセージは、マルチパート/関連エンティティの本体部分が構成要素を表すのと同様に、化合物の成分を表します。マルチパート/関連エンティティと、本体部と、いくつかの他の身体部分におけるその基準は、多くのオクテットによって分離することができます。アプリケーション/ Vnd.pwg多重エンティティと、いくつかの他のメッセージ内のメッセージとその参照基準を含むメッセージをチャンク化することによって、非常に近づけることができます。長いメッセージ、画像への参照が含まれており、それは参照を生成するまで、プロデューサは、各画像のための必要性を知っていない場合、例えば、アプリケーション/ Vnd.pwg多重化は、消費者が画像を参照して画像を処理することを可能にしますそれは全体長いメッセージを消費する前に。この機能は、印刷やスキャンアプリケーションで重要です。この文書では、アプリケーション/ Vnd.pwg多重コンテンツタイプを定義します。また、その使用例を示します。
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
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.
そのような「text / plainの」などの単純なMIMEコンテンツタイプは、そのようなテキスト文書などの単純なオブジェクトを表現するためのメカニズムを提供します。マルチパート/関連[RFC2387]コンテンツ・タイプは、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.
複合オブジェクトは、複数のコンポーネントから構成されています。そのような成分は、化合物の他の構成要素への参照を含むルート要素です。これらのコンポーネントは、今度は、化合物の他の構成要素への参照を含んでいてもよいです。ルートコンポーネントによって参照される各 - 例えば、化合物は、ルートHTMLテキストコンポーネント二GIF画像成分から成ることができました。
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.
しかしながら、マルチパート/関連コンテンツタイプは、ルート・コンポーネント内の対応する参照に近くなるように各成分を必要とするアプリケーションのための良好な解決策ではありません。この文書では、いくつかのアプリケーションのための優れたソリューションを提供する新しいMIMEコンテンツタイプアプリケーション/ Vnd.pwg多重を定義します。アプリケーション/ Vnd.pwg多重コンテンツタイプは、マルチパート/関連コンテンツ・タイプのような、化合物のオブジェクトを表現するための共通のメカニズムを提供します。マルチパート/関連エンティティは、境界文字列によって分離身体部分の配列からなります。各本体部分は、化合物の成分を表します。アプリケーション/ Vnd.pwg多重エンティティはチャンクの配列からなる、長さの各々は、チャンクヘッダーで指定されています。各チャンクは、メッセージまたはメッセージの一部が含まれています。各メッセージは、複合オブジェクトの構成要素を表します。異なるメッセージからのチャンクをインターリーブすることができます。 HTTPは、ワイヤを介してアプリケーション/ Vnd.pwg多重エンティティのための典型的なトランスポートです。アプリケーション/ Vnd.pwg多重エンティティは、そのサフィックスの.mhtは、Microsoft HTML（メッセージ/ RFC822）ファイルに保存することができます。
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つの例を含んでいます。各アプリケーションに対して、アプリケーション/ Vnd.pwg多重コンテンツタイプ、マルチパート/関連コンテンツタイプと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：印刷アプリケーション。プロデューサーは、1つまたは複数の画像を参照するそれぞれのページの説明、非常に長いシリーズで構成された印刷ストリームを作成します。ルートコンポーネントは、ページ記述の長いシリーズです。画像は、複数ページの記述から参照することができ、画像（すなわち、画像が範囲外である）への追加の参照が存在しないときを示すためのメカニズムがあります。プロデューサーは、それがそのページを生成するまでのページに含めるものを画像認識していません。消費者は、全てのスコープ内の画像を保持し、少なくとも1ページを処理するには、ルート要素の十分なのに十分な記憶域を持っていると推定されます。プロデューサーは、消費者が正常に処理できるエンティティを作成するために、消費者のストレージ機能の知識を必要としません。しかし、プロデューサーは随時にスコープされている画像の数について慎重にする必要があります。もちろん、悪質なプロデューサーは、消費者の貯蔵能力を超えるしよう、と消費者は、そのような実体（セクション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 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.
アプリケーション/コンテンツタイプVnd.pwg多重して、各画像は、メッセージは、ルートコンポーネントがメッセージです。プロデューサーは、各画像メッセージがその最初の基準日の直前に発生するとチャンクにルートコンポーネントメッセージを破ります。消費者は、参照を検出すると、それは既に以前チャンクで参照画像を受信したと仮定することができます。
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.
BEEPで、画像ルート成分は、別個のチャネルで送信することができます。それが第1の基準に遭遇するかが第1の基準に遭遇したときに消費者がそれを要求することができる場合プロデューサは、各画像を押すことができます。オクテットのオーバーザワイヤストリームアプリケーション/ Vnd.pwg多重エンティティに類似しています。しかし、印刷アプリケーションのための行動にかなり違いがあります。消費者は、参照に遭遇したとき、画像がプリンタに存在することが保証されるように、アプリケーション/コンテンツ・タイプVnd.pwg多重化と、プロデューサは、その最初の参照の前に各画像のメッセージを置きます。消費者が画像を引く場合BEEPで、消費者は画像をネットワーク経由で来る間、待たなければなりません。プロデューサーは、画像を押すと、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 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.
実施例2：走査（ファックスのような）アプリケーション。プロデューサーは、ページをスキャンし、各ページの画像への参照が含まれていvnd.pwg-XHTML-印刷+ xmlのルートコンポーネントとそれらを一緒に送り、スキャナ、です。各ページはルート・コンポーネントに正確に一度参照されています。消費者はvnd.pwg-XHTML-印刷+ xmlのエンティティとその添付ファイルを消費したプリンタです。これは、消費者がスキャナから来る印刷ジョブに限定されるものではなく、です。生産と消費者がそれぞれ数ページ画像を保持するのに十分な記憶域を持っていると推定していないすべてのルートコンポーネントの場合はほとんどされています。プロデューサーは、消費者が正常に処理できるエンティティを作成するために、消費者のストレージ機能の追加の知識は必要ありません。もちろん、悪質なプロデューサーは、消費者の貯蔵能力を超えるしようと消費者は、そのような実体（セクション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.
アプリケーション/コンテンツタイプVnd.pwg多重して、各ページの画像は、メッセージは、ルートコンポーネントがメッセージです。プロデューサーは、直前または単にその参照した後、各画像メッセージをチャンクにルートコンポーネントメッセージを破ります。
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.
その速度は、この場合のように重要ではありません除い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 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.
例3：印刷アプリケーション。プロデューサーは、ゼロ以上の画像を参照するそれぞれの、一連のページで構成された印刷ストリームを作成します。各画像は正確に一度参照されています。プロデューサーは、それがそのページを生成するまでのページに含めるものを画像認識していない、とプロデューサーは、レイアウトの詳細を知りません。消費者は、レイアウトを処理します。プロデューサーは、ルート・コンポーネントとすべての画像を送信するために十分なストレージを持っています。しかし、それは全体のルート・コンポーネントや画像のいずれかのすべてのオクテットを保持するのに十分なストレージを持っていないかもしれません。消費者は、ルートコンポーネントをレンダリングすると、各画像をレンダリングするのに十分なストレージを持っていると推定されます。これは、全体のルート・コンポーネントや画像のいずれかのすべてのオクテットを保持するのに十分なストレージを持っていないかもしれません。プロデューサーは、消費者のストレージ機能を決定するものではありません。消費者が成功するほとんどがそうであるように、むしろそれは、コンポーネントを配置します。もちろん、悪質なプロデューサーは、消費者の貯蔵能力を超えるしよう、と消費者は、そのような実体（セクション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.
アプリケーション/コンテンツタイプVnd.pwg多重して、各画像は、メッセージは、ルートコンポーネントがメッセージです。プロデューサーは、ちょうどその参照後の各画像メッセージをチャンクにルートコンポーネントメッセージを破ります。それは、画像を処理する前に消費者は、各画像の位置を知っているように、参照が最初に表示されます。この戦略は、生産と消費者のためのストレージのニーズを最小限に抑え、障害が発生した場合には良い戦略を提供します。ここで考慮すべきケースがあります。
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）、チャンクのシーケンスは、このように消費者のバッファリングの必要性を最小限に、印刷可能なブロックの配列と同じです。
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サイドバイサイド画像を含むことができる場合、消費者は、N-1の画像をバッファしなければなりません。プロデューサーは、画像をインターリーブしませんし、それはN-1を受信する前の消費者は、ストレージを使い果たし、画像ならば、それが持っているものに印刷し、下記の残りの画像を印刷することができます。プロデューサーものではなく、何もないよりはましではないものを。プロデューサーは、画像をインターリーブし、それがN画像のバンドを受信する前に消費者がストレージの不足した場合、消費者は、他の画像の部分と交互に画像の一部を印刷します。だから、プロデューサーは、画像をインターリーブべきではありません。
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）（即ち、ラン周りテキスト）、追加のバッファリング要件があります。消費者は、基準を次のテキストを処理するときに、次の画像にその一部を配置します（ランの周りにテキスト）や画像の後に残りのテキストを配置します。 - 周りの実行が終了し、したがって、どこのテキストチャンクを終了し、画像チャンクを開始するために知らないどこプロデューサーは知りません。プロデューサーには早すぎるテキストを終了した場合、消費者は残りの実行の周りにテキストを取得するために、（それが十分な記憶を持っている場合）の全体画像を処理しているか、それが早期実行の周りにテキストを終了します。プロデューサーは遅すぎるテキストを終了した場合、消費者は、あまりにも多くのテキストを格納し、可能性が要求されたプロデューサーよりも後の画像を配置する必要があります。テキストデータは、画像データよりも大幅に少ないストレージを必要とするため、生産者のための良い戦略は、画像データの前にあまりにも多くのではなく、あまりにも少しのテキストを送信するのに越しことです。
d) When a block contains text and multiple side-by-side images, the problem becomes a combination of items b) and c) above.
ブロックは、テキストと、複数のサイドバイサイド画像を含む場合、D）、問題は、c）上記の項目B）との組み合わせとなります。
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.
アプリケーション/ Vnd.pwg多重コンテンツタイプは、この例で動作させることができますが、消費者は、障害戦略を持っている必要があり、その結果がプロデューサーが意図した、非常にどのようなことがないかもしれません。消費者は、ルート・コンポーネントが到着するまで、それらを格納するのに十分なスペースを持っていない可能性があるため、マルチパート/関連コンテンツ・タイプでは、イメージがルートコンポーネントの前にすることはできません。最初の画像が到着する前に、消費者は、ルート・コンポーネントのための十分なストレージを持っていない可能性があるため、また、画像はルートコンポーネントを追跡することはできません。そうマルチパート/関連コンテンツタイプは、この例のために許容される解決策ではありません。
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では、プロデューサーはチャンネル1でルートコンポーネントを送ることができますし、それを基準に遭遇したときの消費者は、偶数番号のチャンネルに画像を要求することができます。このソリューションは、アプリケーション/ Vnd.pwg多重コンテンツタイプより柔軟に行うことができます。サイドバイサイド画像および/または実行の周りにテキストがある場合、消費者は、各画像の帯域を要求することができるまたは実行の周りに別のチャネル上のテキスト。
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.
これらの例の全てにおいて、アプリケーション/ Vnd.pwg多重コンテンツタイプは、マルチパート/関連よりもはるかに優れたソリューションを提供します。しかし、それは均等にBEEPと一致しています。スピードが重要であり、チャンクの順序は、印刷の遅れを避けるために重要であり、アプリケーション/ Vnd.pwg多重コンテンツタイプが最善であるアプリケーションの場合。消費者は、受信したオクテットの順序をより詳細に制御する必要があるアプリケーションの場合、BEEPは最高です。
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]のようなエンティティ。この文書では、用語「メッセージ」は、化合物の一の成分を表すすべてのオクテットが記載されています。つまり、それは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".
ボディパート：マルチパート内のエンティティ。すなわち、本体部は、最初と最後にCRLFを含まないマルチパートの境界文字列間のヘッダとコンテンツ（即ち、オクテット）です。この文書では、「体の一部」を意味する「実体」を使用することはありません。
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".
ヘッダ：エンティティ、メッセージ、または身体部分の最初の行。空行（すなわち、隣接する二つのCRLF）はヘッダを終了します。時には、用語「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.
コンテンツ：エンティティ、メッセージ、または身体の一部（すなわち、隣接する二つのCRLFに続く）ヘッダに続く部分。身体部分の含有量は、マルチパートの境界文字列の前にCRLFの前オクテットで終了します。メッセージの内容は、チャンクヘッダの長さフィールドで指定されたオクテットで終了します。
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.
チャンクヘッダー：チャンクの最初の行。ラインは、それぞれが単一の空白文字（ASCII 32）によって分離された「CHK」キーワード、メッセージの数、長さ及び継続インジケータ、から成ります。 CRLFは、行を終了します。アプリケーション/ Vnd.pwg多重エンティティ内の各メッセージは、通常、アプリケーション/ Vnd.pwg多重エンティティ内の他のすべてのメッセージのメッセージ番号とは異なるメッセージの数を有しています。メッセージ番号0は、アプリケーション/ Vnd.pwg多重エンティティの最後のチャンクヘッダーのために予約されています。
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.
CRLF 2つのUS-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エンティティを作成し、送信するソフトウェア。
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].
アプリケーション/ Vnd.pwg多重コンテンツタイプは、マルチパート/関連ように、いくつかの相互に関連する成分からなる化合物を表すことを意図しています。この文書では、これらの関係の表現を指定しませんが、[RFC2557]は体を参照するために（「CID」URLを含む）のボディパーツとURLを識別するためのContent-IDとContent-場所ヘッダーを使用マルチパート/関連エンティティの例が含まれています部品。アプリケーション/ 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.
アプリケーション/ Vnd.pwg多重化エンティティは、Content-Typeヘッダのための1つのパラメータが存在します。これは、「タイプ」パラメータであり、そしてそれはマルチパート/関連コンテンツ・タイプの「タイプ」パラメータのようなものです。 「タイプ」パラメータの値は、ルートメッセージのコンテンツタイプでなければならず、それが効果的に複合オブジェクトのタイプを指定します。
An Application/Vnd.pwg-multiplexed entity contains a sequence of chunks. Each chunk consists of a chunk header, a chunk payload and a CRLF.
アプリケーション/ 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).
- チャンクヘッダは、チャンクメッセージと、最終的には、CRLFの最後のチャンクであるか否かをメッセージ番号、チャンクペイロード長、続いて「CHK」キーワードから成ります。長さフィールドは、マルチパートが使用する境界文字列の必要性を取り除きます。 （チャンクヘッダの構文は、セクション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.
各メッセージは、同じ構成要素を表すマルチパート/関連エンティティの本体部として、化合物の成分を表し、そしてメッセージが全く同じ表現を有することが意図され、オクテットのためのオクテット。メッセージは複数のチャンクに分割された場合、チャンクは連続している必要はありません。
The contents of an Application/Vnd.pwg-multiplexed entity have the following properties:
アプリケーション/ 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）最初のチャンクは、（）のいずれかの場合に複合オブジェクトのルート・コンポーネントを表し、完全または部分的メッセージを含みます。
2) Additional chunks contain messages or partial messages that represent some component of the compound object.
2）その他のチャンクは、化合物のいくつかの構成要素を表すメッセージまたは部分的メッセージを含みます。
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）最終的なチャンクのヘッダが0のメッセージ数、0の長さと最終チャンクのメッセージマーク（すなわち、チャンクヘッダー行は、「CHK 0 LAST」である）を含みます。最後のチャンクにはチャンクペイロードが含まれていません。
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）メッセージが複数の部分に分割することができ、それぞれのブレークは、メッセージ内のどこにでも発生する可能性があります。メッセージの各部分は、長さがゼロ以上のバイトであり、メッセージの各部分は、それ自身のチャンクの内容です。アプリケーション/ Vnd.pwg多重エンティティ内のチャンクの順序は、メッセージ内の部分の順序と同じでなければなりません。
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）メッセージは、複合オブジェクトの構成要素を表しており、同じ構成要素を表すマルチパート/関連エンティティの本体部分と全く同じ表現、オクテットのためのオクテットを有することが意図されています。具体的には、メッセージは、メッセージコンテンツのコンテンツ・タイプを指定するためのContent-Typeヘッダを含んでいてもよいです。また、メッセージは、別のメッセージの中から参照されるメッセージを識別するためのContent-IDヘッダおよび/またはContent-Locationヘッダを含んでいてもよいです。 、参照、メッセージが全くContent-Typeヘッダが含まれていない場合、メッセージは、「文字セット= US-ASCII、プレーンテキスト/」の暗黙のコンテンツタイプを有します[RFC2045]。
See section 4 for a discussion displaying an Application/Vnd.pwg-multiplexed entity.
アプリケーション/ Vnd.pwg多重エンティティを表示する議論についてはセクション4を参照してください。
The ABNF [RFC2234] for the contents of an Application/Vnd.pwg-multiplexed entity is:
アプリケーション/ Vnd.pwg多重エンティティの内容のためのABNF [RFC2234]は次のとおりです。
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
内容= *チャンクfinalChunkチャンク=ヘッダペイロードCRLFヘッダー= "CHK" SP messageNumber属性SP長SP isMore CRLF messageNumber属性= 1 2147483647長さ= 0 2147483647 isMore = "MORE" / "LAST" ペイロード= * OCTET finalChunk = finalHeader CRLF finalHeader SP "0" = "CHK" SP "0" のSP "LAST" CRLF
The messageNumber field specifies the message that the chunk is associated with. See the end of this section for more details.
messageNumber属性フィールドは、チャンクが関連付けられているメッセージを指定します。詳細については、このセクションの最後を参照してください。
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.
長さフィールドは、（「ペイロード」とABNFで表される）チャンクペイロードのオクテットの数を指定します。チャンクペイロードの最初のオクテットは直ちにチャンクヘッダのLF（すなわち、最終オクテット）を以下のものです。チャンクペイロードの最後のオクテットが直ちにチャンクを終了する2つのオクテットのCRLFに先行するものです。
The isMore field has a value of "LAST" for the last chunk of a message and "MORE" for all other chunks of a message.
isMoreフィールドは、メッセージの他のすべてのチャンクのためのメッセージと、「MORE」の最後のチャンクのための「LAST」の値を有します。
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".
通常、アプリケーション/ Vnd.pwg多重エンティティ内の各メッセージは固有のメッセージ番号を有し、メッセージは同じメッセージ番号を有する1つまたは複数のチャンクから全てのオクテットの連結から成ります。各メッセージの最後のチャンクのチャンクヘッダのisMoreフィールドが「LAST」の値を持っている必要があり、他のすべてのチャンクのチャンクヘッダのisMoreフィールドが「その他」の値を有していなければなりません。
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.
メッセージ番号のように再利用が推奨されていないが二つ以上のメッセージが、同じメッセージ番号を持つことができます。同一のメッセージ番号のチャンクは、各メッセージの最後のチャンクのチャンクヘッダのisMoreフィールドが「LAST」の値を有する1つまたは複数のメッセージの順序を表します。そのisMoreフィールドチャンクヘッダの「MORE」の値を有する（配列で）次のチャンクと同じメッセージに属するチャンクヘッダのisMoreフィールドのすべてのチャンクは「LAST」の値を有します。 2つのメッセージが同じメッセージ番号を持っている場合は、他の言葉では、最初のメッセージの最後のチャンクは、第二のメッセージの最初のチャンクの前に行わなければなりません。
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.
最終的なチャンク（すなわち、そのチャンクヘッダチャンクは「CHK 0 LAST」である）場合に消費者の行動は、すべてのメッセージの最後のチャンクが発生する前に発生未定義です。
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.
隣接する二つのチャンクは通常、異なるメッセージ番号を持っています。しかし、それらは同じメッセージ番号を持つことができます。隣接する二つのチャンクが同じメッセージ番号をお持ちの場合は、2つのチャンクは単一のチャンクに組み合わせることができるが、それらを結合する必要はありません。
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 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.
チャンクペイロードのオクテットの数はゼロであってもよく、アプリケーション/ Vnd.pwg多重化エンティティは、チャンクペイロードのゼロオクテットとチャンクの任意の数を含んでいてもよいです。例えば、各メッセージの最後のチャンクは、プログラミング便宜上ゼロオクテットを含んでいてもよいです。別の例として、特定の化合物のオブジェクトフォーマットは、参照メッセージは、ルートメッセージの前に起こることを必要とすると仮定する。この文書では、アプリケーション/ Vnd.pwg多重エンティティの最初のチャンクがルートメッセージまたはその一部を含有することを必要とします。だから、最初のチャンクは、第二のチャンクのルートメッセージの最初のオクテットでゼロオクテットのチャンクペイロードを含みます。つまり、ルートメッセージのメッセージヘッダの全ては、第二のチャンクです。極端しかしそう例としては、チャンク4,7を除くすべてのチャンクでゼロオクテットチャンクペイロードと10個のチャンクに分割メッセージを有することが可能であろう。
This section defines additional parameters for Application/Vnd.pwg-multiplexed.
このセクションでは、アプリケーション/ Vnd.pwg多重化のための追加のパラメータを定義します。
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.
typeパラメータを指定する必要があります。その値は、「ルート」のメッセージのコンテンツタイプです。これは、囲まれたメッセージを参照することなく、コンテンツ・タイプを決定するために、消費者を可能にします。 typeパラメータの値は、ルートメッセージのコンテンツタイプと異なる場合は、消費者の動作は未定義です。
The syntax for "parameter" is:
「パラメータ」の構文は次のとおりです。
parameter := "type" "=" type "/" subtype ; cf. [RFC2045]
パラメータ：=「タイプ」「=」タイプ「/」サブタイプ。参照[RFC2045]
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.
アプリケーション/ Vnd.pwg多重エンティティを処理するアプリケーションは、エンティティを表示するための責任があります。しかし、アプリケーション/ Vnd.pwg多重メッセージは、メッセージの表示や保存のための提案を提供コンテンツディスポジションヘッダーが含まれていてもよいし、いくつかのケースではアプリケーションは、ヘッダに注意を払うことがあります。
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.
念のため、コンテンツディスポジションヘッダー[RFC1806]は、送信者がMIMEメッセージのためのプレゼンテーションスタイルを提案することができます。 2つのプレゼンテーションのスタイルは「インライン」と「添付ファイル」は、あります。コンテンツディスポジションヘッダーには、保存のために推奨されるファイル名を指定するためのパラメータを持っています。
There are three cases to consider for handling Application/Vnd.pwg-multiplexed entities:
アプリケーション/ Vnd.pwg多重エンティティを処理するために考慮すべき3つのケースがあります。
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 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.
a）は、消費者は、アプリケーション/ Vnd.pwg多重化および根のコンテンツタイプを認識する。消費者は、複合オブジェクトのプレゼンテーションスタイルを決定します。それは化合物の文脈における化合物の構成要素の表示を処理します。この場合、コンテンツディスポジションヘッダー情報は、冗長、あるいは誤解を招くおそれがあり、消費者は、ディスプレイの目的のためにそれらを無視しなければなりません。エンティティが格納されている場合の消費者は、提案されたファイル名を使用することができます。
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）の消費者は、アプリケーション/ Vnd.pwg多重認識しますが、根のないコンテンツタイプ。消費者は、ユーザーにアプリケーション全体/ Vnd.pwg多重エンティティを抑制したり、各メッセージはマルチパート/ミックスエンティティの身体の一部であるマルチパート/ミックスエンティティとしてApplication / Vnd.pwg多重エンティティの治療選択肢を提供します。 （エンティティが抑制されていない）、この場合、消費者は、得られた複合/混合エンティティの各身体部分を表示するために有用なコンテンツの廃棄情報を見つけることができます。身体部分がないコンテンツ-Dispositionヘッダーを持っていない場合、消費者は、添付ファイルとして身体部分を表示すべきです。
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）消費者は、アプリケーション/ Vnd.pwg多重認識しません。消費者は、不透明としてApplication / Vnd.pwg多重エンティティを扱い、それを何もしないことができます。
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.
このセクションでは、5つの例が含まれています。各例では、同じ化合物の異なる表現です。 XHTMLテキストコンポーネントと3つの画像成分：化合物は、4つの成分を有します。画像はバイナリで符号化されます。各実施例における文字列「<<バイナリデータ>>」および「バイナリデータの<<一部は>>」は、各画像のバイナリデータの全部または一部を表します。画像の二つは、潜在的に並んでおり、第三の画像は、後で文書内に表示されます。すべての画像は、Content-IDによって識別され、画像の2は、また、コンテンツの場所によって識別されます。画像の一つは、コンテンツの場所を参照します。
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.
最初の例では、読者が精通していることを表現を提供するために、化合物のマルチパート/関連表現を示します。残りの実施例は、同じ化合物の適用/ Vnd.pwg多重表現を示します。第2の例では、各チャンクはメッセージ全体を含んでいます。第3の例では、XHTMLメッセージは3つのチャンクに分割され、これらのチャンクは、3つの画像メッセージのうちインターリーブされます。第四の実施例では、XHTMLメッセージは4つのチャンクに分割され、2つのサイドバイサイド画像がそれぞれ2つのチャンクに分割されます。 XHTMLチャンクは、画像チャンク間でインターリーブされています。第五の実施例では、空のペイロードと同一のメッセージ番号を持つ隣接チャンクとのチャンクがあります。
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.
最後の例では役に立たないケースに対処するために見えるかもしれませんが、これらのケースが許可されている場合、時にはソフトウェアを書くことが容易です。たとえば、バッファがいっぱいになると、それはチャンクを書いて、以前のチャンクが同じメッセージ番号を持っていた場合、心配しないでするのが最も簡単かもしれません。同様に、それは空のチャンクでメッセージを終了するのが最も簡単かもしれません。最後に、アプリケーション/コンテンツ・タイプVnd.pwg多重化は、最初のチャンクは、ルートメッセージの一部であることを必要とします。ルートメッセージは、一部の添付ファイルが発生した後に開始した場合時には、それはプロデューサーのために、より便利です。チャンクが空であることができるので、ルート・メッセージの最初のチャンク、すなわち、それはあっても、任意のヘッダが含まれていない、空にすることができます。そして、最初のチャンクは、ルートメッセージの一部が含まれていますが、プロデューサーはそのチャンクのための任意のオクテットを生成しません。
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.
マルチパート/関連エンティティの各部位とアプリケーション/ Vnd.pwg多重エンティティの各メッセージは、消費者がセクション4ノートの規則に従って使用コンテンツ配置を含むコンテンツ配置ヘッダの場所で例。
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.
読者がアプリケーション/ Vnd.pwg多重エンティティと比較できるように、この例では、化合物は、マルチパート/関連エンティティとして表されています。
Content-Type: multipart/related; boundary="boundary-example"; type="text/xhtml+xml"
コンテンツタイプ：マルチパート/関連;境界=「境界例」。タイプ= "テキスト/ XHTML + xml" で
--boundary-example Content-ID: <49568.44343xxx@foo.com> Content-Type: application/vnd.pwg-xhtml-print+xml Content-Disposition: inline
--boundary-例のContent-ID：<49568.44343xxx@foo.com>コンテンツタイプ：アプリケーション/ vnd.pwg-XHTML印刷+ XMLコンテンツの廃棄：インライン
<?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のバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict .DTD "> <HTMLのxmlns =" http://www.w3.org/TR/xhtml1 "> <BODY> <P>一部のテキスト<IMG SRC =" CID：49568.45876xxx@foo.com "/> <IMG画像後のsrcは= "http://foo.com/images/image2.gif" />いくつかのより多くのテキスト</ p> <p>この画像のないいくつかのより多くのテキスト</ p> <p>このいくつかのより多くのテキスト<IMG SRC = "CID：49568.47333xxx@foo.com" /> </ P>
<p>some final text </p> </body> </html> --boundary-example Content-ID: <49568.45876xxx@foo.com> Content-Location: http://foo.com/images/image1.gif Content-Type: image/gif Content-Disposition: attachment
<P>いくつかの最終テキスト</ P> </ body> </ html>この--boundary-例のContent-ID：<49568.45876xxx@foo.com>コンテンツ - ロケーション：http://foo.com/images/image1画像/ gif形式のコンテンツディスポジション：添付ファイルのContent-Type .GIF
<<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
<<バイナリデータ>> --boundary-例のContent-ID：<49568.46000xxx@foo.com>コンテンツロケーション：http://foo.com/images/image2.gifコンテンツタイプ：image / gif形式のコンテンツの廃棄：添付ファイル
<<binary data>> --boundary-example Content-ID: <49568.47333xxx@foo.com> Content-Type: image/gif Content-Disposition: attachment
<<バイナリデータ>> --boundary-例のContent-ID：<49568.47333xxx@foo.com>コンテンツタイプ：image / gifのコンテンツの廃棄：添付ファイル
<<binary data>> --boundary-example--
<<バイナリデータ>> --boundary-example--
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.
このセクションを表示アプリケーションの4つの例は、同じ化合物の/ Vnd.pwg多重表現。各CRLFは、視覚改行で表現されることに注意してください。
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.
この例では、化合物は、アプリケーション/ Vnd.pwg多重エンティティとして表されています。各チャンクは、メッセージ全体が含まれ、すなわち、メッセージのいずれも複数のチャンクに分割されていません。この例では、各メッセージには、前述のマルチパート/例に関連の対応する身体部分と同一です。
Content-Type: application/vnd.pwg-multiplexed; type="application/vnd.pwg-xhtml-print+xml"
コンテンツタイプ：アプリケーション/ vnd.pwg多重;タイプ= "アプリケーション/ vnd.pwg-XHTML-印刷+ 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>コンテンツタイプ：アプリケーション/ vnd.pwg-XHTML印刷+ XMLコンテンツの廃棄：インライン
<?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のバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict .DTD "> <HTMLのxmlns =" http://www.w3.org/TR/xhtml1 "> <BODY> <P>一部のテキスト<IMG SRC =" CID：49568.45876xxx@foo.com "/> <IMG画像後のsrcは= "http://foo.com/images/image2.gif" />いくつかのより多くのテキスト</ p> <p>この画像のないいくつかのより多くのテキスト</ p> <p>このいくつかのより多くのテキスト<IMG SRC = "CID：49568.47333xxx@foo.com" /> </ p> <p>このいくつかの最終テキスト</ 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>コンテンツ - ロケーション：http://foo.com/images/image1.gifのContent-Type：画像/ gif形式のコンテンツディスポジション：添付ファイル
<<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
<<バイナリデータ>> CHK 3 6401 LASTのContent-ID：<49568.46000xxx@foo.com>コンテンツロケーション：http://foo.com/images/image2.gifコンテンツタイプ：image / gif形式のコンテンツの廃棄：アタッチメント
<<binary data>> 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>コンテンツタイプ：image / gif形式のコンテンツの廃棄：添付ファイル
<<binary data>> CHK 0 0 LAST
<<バイナリデータ>> CHK 0 0 LAST
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.
この例では、化合物は、アプリケーション/ Vnd.pwg多重エンティティとして表されています。画像への参照は、チャンクの開始にできるだけ近くなるように、XHTML成分を含むメッセージは、3個に分割されています。参照画像メッセージを含むチャンクを参照して単にチャンクの前に発生します。これは、基準と参照されるメッセージとの間の距離を最小化します。
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.
他の可能な配置が（セクション5.2.3における第3の例を参照）が存在することに留意されたいです。画像への参照は、チャンクの終わりにできるだけ近くなるように、例えば、送信者は、XHTMLメッセージを分割することができました。次に、参照画像メッセージを含むチャンクを参照して単にチャンクの後に起こるべきです。送信者は、この例で使用したもので、この戦略を混ぜることができます。
Content-Type: application/vnd.pwg-multiplexed; type=" application/vnd.pwg-xhtml-print+xml"
コンテンツタイプ：アプリケーション/ vnd.pwg多重;タイプ= "アプリケーション/ vnd.pwg-XHTML-印刷+ 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：アプリケーション/ vnd.pwg-XHTML-印刷+ xmlのコンテンツディスポジション：インライン
<?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のバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict .DTD "> <HTMLのxmlns =" http://www.w3.org/TR/xhtml1" > <BODY> <P>テキスト
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>コンテンツ - ロケーション：http://foo.com/images/image1.gifのContent-Type：画像/ gif形式のコンテンツディスポジション：添付ファイル
<<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
<<バイナリデータ>> CHK 3 6401 LASTのContent-ID：<49568.46000xxx@foo.com>コンテンツロケーション：http://foo.com/images/image2.gifコンテンツタイプ：image / gif形式のコンテンツの廃棄：アタッチメント
<<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 1 166 MORE <IMG SRC = "CID：49568.45876xxx@foo.com" /> <IMG SRC = "http://foo.com/images/image2.gif" />いくつかのより多くのテキスト画像の後に</ p> <p>この画像のないいくつかのより多くのテキスト</ p> <p>このいくつかのより多くのテキスト
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>コンテンツタイプ：image / gif形式のコンテンツの廃棄：添付ファイル
<<binary data>> CHK 1 80 LAST <img src="cid:49568.47333xxx@foo.com"/> </p> <p>some final text </p> </body> </html>
<<バイナリデータ>> CHK 1 80 LAST <IMG SRC = "CID：49568.47333xxx@foo.com" /> </ P> <P>いくつかの最終的なテキスト</ P> </ BODY> </ HTML>
CHK 0 0 LAST
CHK 0 0 LAST
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.
この例では、化合物は、アプリケーション/ Vnd.pwg多重エンティティとして表されています。画像への参照を開始またはチャンクのいずれかの端部にできるだけ近くなるようにXHTMLコンポーネントを含むメッセージは、4個に分割されています。第1および第2の画像への参照が密接に参照されるイメージに従ってください。第三の画像への参照は、密接に参照画像に先行します。これは、基準と参照されるメッセージとの間の距離を最小化します。加えて、最初の二つの画像メッセージは、2つのチャンク毎に分割されています。
Content-Type: application/vnd.pwg-multiplexed; type=" application/vnd.pwg-xhtml-print+xml"
コンテンツタイプ：アプリケーション/ vnd.pwg多重;タイプ= "アプリケーション/ vnd.pwg-XHTML-印刷+ 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以上のコンテンツ-ID：<49568.44343xxx@foo.com>コンテンツタイプ：アプリケーション/ vnd.pwg-XHTML印刷+ XMLコンテンツの廃棄：インライン
<?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のバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict .DTD "> <HTMLのxmlns =" http://www.w3.org/TR/xhtml1" > <BODY> <P>テキスト
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>コンテンツ - ロケーション：http://foo.com/images/image1.gifのContent-Type：画像/ gif形式のコンテンツディスポジション：添付ファイル
<<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
<<バイナリデータの一部>> CHK 3 200以上のコンテンツ-ID：<49568.46000xxx@foo.com>コンテンツロケーション：http://foo.com/images/image2.gifコンテンツタイプ：image / gif形式のContent処分：添付ファイル
<<part of binary data>> CHK 1 78 MORE <img src="cid:49568.45876xxx@foo.com"/> <img src="http://foo.com/images/image2.gif"/>
バイナリデータの一部<< >> CHK 1 78以上の<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バイナリデータの一部<< >> CHKバイナリデータの3 6201 LAST <<部>> CHK 1 127以上の画像の後にいくつかのより多くのテキスト</ P> <P>画像せず、いくつかのより多くのテキスト</ P> <P>いくつかのより多くのテキスト<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>コンテンツタイプ：image / gif形式のコンテンツの廃棄：添付ファイル
<<binary data>> CHK 1 41 LAST </p> <p>some final text </p> </body> </html>
<<バイナリデータ>> CHK 1 41 LAST </ P> <P>いくつかの最終的なテキスト</ P> </ BODY> </ HTML>
CHK 0 0 LAST
CHK 0 0 LAST
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.
この例では、いくつかのチャンクはゼロオクテットのチャンク・ペイロードを有することを除いて、以前のものと同じです。ルートメッセージは、そのペイロード空であり、すべてのメッセージは、そのペイロード空であるチャンクと終了チャンクから始まります。この例では、同じメッセージからのものである二つの隣接するチャンクを示しています。これらの2つのチャンクは単一のチャンクに合体することができますが、それらは、プログラミングの利便のために分離して保持される可能性があります。
Content-Type: application/vnd.pwg-multiplexed; type=" application/vnd.pwg-xhtml-print+xml"
コンテンツタイプ：アプリケーション/ vnd.pwg多重;タイプ= "アプリケーション/ vnd.pwg-XHTML-印刷+ 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>コンテンツ - ロケーション：http://foo.com/images/image1.gifのContent-Type：画像/ gif形式のコンテンツディスポジション：添付ファイル
<<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
<<バイナリデータの一部>> CHK 3 200以上のコンテンツ-ID：<49568.46000xxx@foo.com>コンテンツロケーション：http://foo.com/images/image2.gifコンテンツタイプ：image / gif形式のContent処分：添付ファイル
<<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
バイナリデータの一部<< >> CHK 1 303以上のコンテンツ-ID：<49568.44343xxx@foo.com>コンテンツタイプ：アプリケーション/ vnd.pwg-XHTML印刷+ XMLコンテンツの廃棄：インライン
<?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のバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict .DTD "> <HTMLのxmlns =" http://www.w3.org/TR/xhtml1" > <BODY> <P>テキスト
CHK 2 6162 MORE <<part of binary data>> CHK 3 6201 MORE <<part of binary data>> CHK 2 0 LAST
CHK 2 6162以上のバイナリデータの一部<< >> CHK 3 6201 MOREをバイナリデータの一部<< >> 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以上の<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以上のコンテンツ-ID：<49568.47333xxx@foo.com>コンテンツタイプ：image / gif形式のコンテンツの廃棄：添付ファイル
<<binary data>> CHK 4 0 LAST
<<バイナリデータ>> 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以上の画像の後にいくつかのより多くのテキスト</ P> <P>画像せず、いくつかのより多くのテキスト</ P> <P>いくつかのより多くのテキスト<IMG SRC = "CID：49568.47333xxx@foo.com" />
CHK 1 41 MORE </p> <p>some final text </p> </body> </html>
CHK 1 41以上の</ P> <P>いくつかの最終的なテキスト</ P> </ BODY> </ HTML>
CHK 1 0 LAST
CHK 1 0 LAST
CHK 0 0 LAST
CHK 0 0 LAST
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.
アプリケーション/ Vnd.pwg多重エンティティの各メッセージに関連するセキュリティ上の考慮事項があります。これらのセキュリティ問題は、メッセージのコンテンツタイプを定義する文書に記載されています。彼らは、このドキュメントでは扱われていません。
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多重エンティティに関連するセキュリティ上の考慮事項もあります。バギーや悪意のあるであるプロデューサーは、消費者はそれがストレージの大容量を持っている場合でも、それが持っているよりも多くのストレージを要求する可能性があり、アプリケーション/ Vnd.pwg多重エンティティを送信することができます。消費者は彼らの次のシナリオとの組み合わせで優雅に対処できなければなりません。
- 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つまたは複数の参照が含まれています。 - 消費者はそれがそれらを捨てることができることを知っている前に、参照されたメッセージの非常に多くが起こります。
The following form is copied from RFC 1590, Appendix A.
次の形式は、RFC 1590、付録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 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:
件名：新しいメディアタイプアプリケーション/ Vnd.pwg多重メディアタイプ名の登録：アプリケーションメディアサブタイプ名：ベンダーツリー - vnd.pwg多重必須パラメータ：タイプ、メディアタイプ/サブタイプ。オプションのパラメータ：なしオプションパラメータエンコーディングの考慮事項：アプリケーション/ Vnd.pwg多重エンティティの各メッセージは、メッセージのコンテンツタイプによって許可された任意の方法で符号化することができます。しかしながら、マルチパートの推論を使用して、アプリケーション/ Vnd.pwg多重化エンティティを符号化することができません。そうでなければ、メッセージは、一度メッセージレベルで、一度アプリケーション/ Vnd.pwg多重レベルで、二回符号化されるであろう。セキュリティに関する考慮事項：RFC 3391.公開仕様のセクション6（セキュリティ上の考慮事項）を参照してください：RFC 3391.人と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
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.
ウーゴコルダ、デイブ・クロッカー、メリンダ・スー・グラント、グラハムKlyne、カール・宇野Manros、ラリーMasinter、アイラマクドナルド、クリス・ニューマン、ヘンリック・フリスティック・ニールセンとデールR.ウォーリー：著者は感謝の貢献を認めています。具体的には、クリス・ニューマンは非常に貴重な援助を提供しました。
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[RFC1806] Troost、R.とS.ドルナー、 "インターネット・メッセージでプレゼンテーション情報を伝える：のContent-Dispositionヘッダー"、RFC 1806、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.クラーク、 "メッセージ/外部-ボディのContent-IDアクセスタイプ"、RFC 1873、1995年12月レビンソン、E.、 "メッセージ/外部-ボディのContent-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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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：メディアタイプ"、RFC 2046、1996年11月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifications: ABNF", RFC 2234, November 1997.
"SyntaxSpecificationsのための増大しているBNF：ABNF" [RFC2234]クロッカー、D.、およびP. Overell、RFC 2234、1997年11月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2392、1998年8月。
[RFC2557] Palme, J., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML", RFC 2557, March 1999.
[RFC2557]パルメ、J.、RFC 2557、1999年3月 "は、HTML（MHTMLとして集約文書のMIMEカプセル化"。
[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エディタ、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
Robert Herriot 706 Colorado Ave. Palo Alto, CA 94303 USA
ロバート・ヘリオット706コロラドアベニューパロアルト、CA 94303 USA
Phone: 1-650-327-4466 Fax: 1-650-327-4466 EMail: bob@herriot.com
電話：1-650-327-4466ファックス：1-650-327-4466 Eメール：bob@herriot.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。