[要約] RFC 3391は、MIME Application/Vnd.pwg-multiplexed Content-Typeの仕様を定義しています。この仕様の目的は、複数の関連する文書を1つのメッセージにまとめるための方法を提供することです。
Network Working Group R. Herriot
Request for Comments: 3391 December 2002
Category: Informational
The MIME Application/Vnd.pwg-multiplexed Content-Type
MIMEアプリケーション/vnd.pwgマルチプレックスコンテンツタイプ
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.
Copyright（c）The Internet Society（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.
生産者と消費者の間で双方向通信が可能なビープ音に基づくプロトコルなどの代替メカニズムは、消費者の能力が生産者に知られていない場合に考慮する必要があります。
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.
Application/vnd.pwg-Multiplexed Content-Typeは、MultiPart/関連コンテンツタイプと同様に、複数のコンポーネントで構成されるオブジェクトを表すメカニズムを提供します。Application/vnd.pwg-Multiplexedエンティティには、一連のチャンクが含まれています。各チャンクには、mimeメッセージまたはmimeメッセージの一部が含まれています。各mimeメッセージは、複合オブジェクトのコンポーネントを表します。これは、マルチパート/関連エンティティの本体部分がコンポーネントを表すのと同じように表します。マルチパート/関連するエンティティを使用すると、身体部分と他の身体部分への参照は、多くのオクテットで分離される場合があります。Application/vnd.pwg-Multiplexedエンティティを使用すると、参照を含むメッセージをチャンキングすることで、他のメッセージとその参照を非常に近くに行うことができます。たとえば、長いメッセージに画像への参照が含まれており、プロデューサーが参照を生成するまで各画像の必要性を知らない場合、Application/vnd.pwg-Multiplexedにより、消費者は画像と画像への参照を処理できます。長いメッセージ全体を消費する前に。この機能は、アプリケーションの印刷とスキャンにおいて重要です。このドキュメントでは、アプリケーション/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.
「テキスト/プレーン」などのシンプルなMIMEコンテンツタイプは、テキストドキュメントなどの単純なオブジェクトを表すメカニズムを提供します。MultiPart/関連[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.
複合オブジェクトは、複数のコンポーネントで構成されています。そのようなコンポーネントの1つは、複合オブジェクトの他のコンポーネントへの参照を含むルートコンポーネントです。これらのコンポーネントには、複合オブジェクトの他のコンポーネントへの参照が含まれている場合があります。たとえば、複合オブジェクトは、ルートHTMLテキストコンポーネントと2つの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.
複合オブジェクトとコンポーネントはどちらも抽象化です。ワイヤー上の送信またはストレージへの書き込みには、それぞれが表現が必要です。「MultiPart/関連エンティティ」は、複合オブジェクトの可能な表現の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/関連するコンテンツタイプは、各コンポーネントがルートコンポーネントの対応する参照に近いことを要求するアプリケーションにとって適切なソリューションではありません。このドキュメントでは、一部のアプリケーションに適したソリューションを提供する新しいMIMEコンテンツタイプアプリケーション/VND.pwgマルチプレックスを定義しています。Application/vnd.pwg-Multiplexed Content-Typeは、MultiPart/関連コンテンツタイプと同様に、複合オブジェクトを表すための共通のメカニズムを提供します。マルチパート/関連するエンティティは、境界文字列で区切られた一連の身体部分で構成されています。各身体部分は、化合物オブジェクトのコンポーネントを表します。アプリケーション/vnd.pwgマルチプレックスエンティティは、一連のチャンクで構成され、それぞれがチャンクヘッダーで指定されています。各チャンクには、メッセージまたはメッセージの一部が含まれています。各メッセージは、複合オブジェクトのコンポーネントを表します。さまざまなメッセージからのチャンクはインターリーブできます。HTTPは、ワイヤー上のアプリケーション/vnd.pwgマルチプレックスエンティティの典型的なトランスポートです。アプリケーション/vnd.pwg-multiplexedエンティティは、接尾辞が.mhtであるMicrosoft HTML（Message/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マルチプレックスのコンテンツタイプであるマルチパート/関連コンテンツタイプとビープ音[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.
Application/vnd.pwg-Multiplexed Content-Typeを使用すると、各画像はメッセージであり、ルートコンポーネントはメッセージです。プロデューサーは、各画像メッセージが最初の参照の少し前に発生する状態で、ルートコンポーネントメッセージをチャンクに分割します。消費者が参照に遭遇すると、以前のチャンクで参照された画像をすでに受け取っていると仮定できます。
With the Multipart/Related content-type, each image must either precede or follow the root component.
MultiPart/関連コンテンツタイプの場合、各画像はルートコンポーネントの前または従う必要があります。
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.
ビープ音を使用すると、画像とルートコンポーネントを別々のチャネルで送信できます。プロデューサーは、最初の参照に遭遇したときに各画像をプッシュできます。または、消費者が最初のリファレンスに遭遇したときにそれを要求できます。オクテットのオーバーワイヤーストリームは、アプリケーション/vnd.pwgマルチプレックスされたエンティティに似ています。ただし、印刷アプリケーションの動作には大きな違いがあります。Application/vnd.pwg-Multiplexed Content-Typeを使用すると、プロデューサーは各画像メッセージを最初の参照の前に配置して、消費者が参照に遭遇すると、画像がプリンターに存在することが保証されます。ビープ音で、消費者が画像を引っ張った場合、消費者は画像がネットワーク上に来る間待たなければなりません。プロデューサーが画像を押している場合、ビープ音は最初の参照の後に画像メッセージを配置する可能性があり、消費者はまだ画像を待つ必要がある場合があります。高速プリンターは、画像を待つ危険を冒す必要はありません。それ以外の場合は、フルスピードで実行できません。
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：スキャン（FAXのような）アプリケーション。プロデューサーはスキャナーであり、各ページの画像への参照を含むVND.pwg-xhtml-print xmlルートコンポーネントと一緒にページをスキャンして送信します。各ページは、ルートコンポーネントで正確に1回参照されます。消費者は、vnd.pwg-xhtml-print 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.
Application/vnd.pwg-Multiplexed Content-Typeを使用すると、各ページ画像はメッセージであり、ルートコンポーネントはメッセージです。プロデューサーは、参照の直前または直後に各画像メッセージでルートコンポーネントメッセージをチャンクに分割します。
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/関連するコンテンツタイプでは、消費者がルートコンポーネントが到着するまでそれらを保存するのに十分なスペースがない可能性があるため、画像はルートコンポーネントに先行することはできません。この場合、プリンターはジョブの印刷に正しく印刷できず、プロデューサーは知らないかもしれません。したがって、画像はルートコンポーネントに従う必要があり、プロデューサーは最初のページを送信する前にすべてのページをスキャンする必要があります。少なくとも、このソリューションは、すべてがスキャンされるまでページの印刷を遅らせます。最悪の場合、プロデューサーは画像を緩衝するのに十分なメモリを持っていないため、ジョブは失敗します。
With BEEP, the issues are the same as in the previous example, except that speed is not as important in this case. So BEEP is a viable alternative for this example.
ビープ音では、この場合は速度がそれほど重要ではないことを除いて、問題は前の例と同じです。したがって、ビープ音は、この例の実行可能な代替品です。
Example 3: a printing application. A Producer creates a print stream that consists of a series of pages, each of which references zero or more images. Each image is referenced exactly once. The Producer does not know what images to include with a page until it generates that page, and the Producer doesn't know the layout details; the Consumer handles layout. The Producer has enough storage to send the root component and all images. However, it may not have enough storage to hold the entire root component or all octets of any of the images. The Consumer is presumed to have enough storage to render the root component and to render each image. It may not have enough storage to hold the entire root component or all octets of any of the images. The Producer doesn't determine the Consumer's storage capabilities. Rather it arranges the components so that the Consumer is mostly likely to succeed. Of course, a malicious Producer may try 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：印刷アプリケーション。プロデューサーは、一連のページで構成される印刷ストリームを作成します。各ページは、ゼロ以上の画像を参照しています。各画像は正確に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 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-Multiplexed Content-Typeを使用すると、各画像はメッセージであり、ルートコンポーネントはメッセージです。プロデューサーは、参照直後に各画像メッセージでルートコンポーネントメッセージをチャンクに分割します。参照が最初に表示されるため、消費者は画像を処理する前に各画像の位置を把握します。この戦略は、生産者と消費者のストレージニーズを最小限に抑え、失敗の場合に優れた戦略を提供します。考慮すべきケースは次のとおりです。
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) ブロックにテキストと複数の並んでいる画像が含まれると、問題はアイテム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.
アプリケーション/vnd.pwg-multiplexed Content-Typeはこの例で作業することができますが、消費者は失敗戦略を持っている必要があり、結果はプロデューサーが意図したものではないかもしれません。MultiPart/関連するコンテンツタイプでは、消費者がルートコンポーネントが到着するまでそれらを保存するのに十分なスペースがない可能性があるため、画像はルートコンポーネントに先行することはできません。また、消費者は最初の画像が到着する前にルートコンポーネントに十分なストレージを持っていない可能性があるため、画像はルートコンポーネントに従うことができません。したがって、マルチパート/関連コンテンツタイプは、この例では許容可能なソリューションではありません。
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.
ビープ音を使用すると、プロデューサーはルートコンポーネントをチャンネル1に送信でき、消費者は参照に遭遇したときに偶数番号のチャンネルで画像を要求できます。このソリューションにより、Application/vnd.pwg-Multiplexed Content-Typeよりも柔軟性が高くなります。サイドバイサイドの画像やランアラウンドテキストがある場合、消費者は個別のチャネル上で各画像またはランアラウンドテキストのバンドをリクエストできます。
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-Multiplexed Content-Typeは、MultiPart/関連よりもはるかに優れたソリューションを提供します。ただし、ビープ音と均等に一致しています。速度が重要であり、印刷の遅延を避けるためにチャンクの順序付けが重要なアプリケーションの場合、アプリケーション/vnd.pwgマルチプレックス化されたコンテンツタイプが最適です。消費者が受け取ったオクテットの注文をより多くの制御する必要があるアプリケーションの場合、ビープ音が最適です。
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つのコンポーネントを表すすべてのオクテットを記述しています。つまり、マイムヘッダーとコンテンツがあります。
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".
ヘッダー：エンティティ、メッセージ、またはボディパーツの初期行。空の線（つまり、2つの隣接するCRLF）がヘッダーを終了します。「Mime Header」という用語が「ヘッダー」だけでなく使用される場合があります。
Content: the part of an entity, message or body part that follows the headers (i.e., follows the two adjacent CRLFs). The content of a body part ends at the octet preceding the CRLF before the multipart boundary string. The content of a message ends at the octets specified by the length field in the Chunk Header.
コンテンツ：ヘッダーに続くエンティティ、メッセージ、またはボディパーツの部分（つまり、2つの隣接する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.
チャンクヘッダー：チャンクの最初の行。この行は、「CHK」キーワード、メッセージ番号、長さ、継続インジケーターで構成され、それぞれが単一のスペース文字（ASCII 32）で区切られています。CRLFがラインを終了します。Application/vnd.pwg-Multiplexedエンティティ内の各メッセージには、通常、アプリケーション/vnd.pwg-multiplexedエンティティの他のすべてのメッセージのメッセージ番号とは異なるメッセージ番号があります。メッセージ番号0は、Application/vnd.pwg-Multiplexedエンティティの最終チャンクヘッダー用に予約されています。
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（10進価値13）とLF（10進値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-multiplexed Content-Typeは、MultiPart/関連するように、いくつかの相互に関連するコンポーネントで構成される複合オブジェクトを表すことを目的としています。このドキュメントでは、これらの関係の表現を指定しませんが、[RFC2557]には、コンテンツIDとコンテンツロケーションヘッダーを使用して体の部分とURL（「CID」URLを含む）を識別するマルチパート/関連エンティティの例が含まれています。部品。[RFC2557]で説明されているパターンを使用すると、アプリケーション/vnd.pwg-multiplexedエンティティが使用されることが予想されます。
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-Multiplexedエンティティの場合、コンテンツタイプのヘッダーには1つのパラメーターがあります。これは「タイプ」パラメーターであり、MultiPart/関連コンテンツタイプの「タイプ」パラメーターのようなものです。「タイプ」パラメーターの値は、ルートメッセージのコンテンツタイプである必要があり、複合オブジェクトのタイプを効果的に指定します。
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-Multiplexedエンティティには、一連のチャンクが含まれています。各チャンクは、チャンクヘッダー、チャンクペイロード、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で構成されています。長さフィールドは、マルチパートが使用する境界文字列の必要性を削除します。（チャンクヘッダーの構文については、セクション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) 最後のChunkのヘッダーには、メッセージ番号0、長さ0、最後のchunk-of messageマークが含まれています（つまり、チャンクヘッダーラインは「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) メッセージは複合オブジェクトのコンポーネントを表し、同じコンポーネントを表すマルチパート/関連エンティティの体の部分として、オクテットのオクテットとまったく同じ表現を持つことを意図しています。特に、メッセージには、メッセージコンテンツのコンテンツタイプを指定するコンテンツタイプのヘッダーが含まれている場合があります。また、メッセージには、別のメッセージ内から参照されるメッセージを識別するためのコンテンツIDヘッダーおよび/またはコンテンツロケーションヘッダーが含まれている場合があります。メッセージにコンテンツタイプのヘッダーが含まれていない場合、メッセージには「テキスト/プレーン; charset = us-ascii」の暗黙のコンテンツタイプがあります。[RFC2045]。
See section 4 for a discussion displaying an Application/Vnd.pwg-multiplexed entity.
アプリケーション/vnd.pwg-multiplexedエンティティを表示するディスカッションについては、セクション4を参照してください。
The ABNF [RFC2234] for the contents of an Application/Vnd.pwg-multiplexed entity is:
アプリケーション/vnd.pwg-multiplexedエンティティの内容の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
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.
長さフィールドは、チャンクペイロードのオクテットの数を指定します（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フィールドには、メッセージの最後のチャンクの「最後」の値と、他のすべてのメッセージの「より多く」の値があります。
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".
通常、Application/vnd.pwg-Multiplexedエンティティの各メッセージには一意のメッセージ番号があり、メッセージは同じメッセージ番号を持つ1つ以上のチャンクからのすべてのオクテットの連結で構成されています。各メッセージの最後のチャンクのチャンクヘッダーのismoreフィールドには、「最後」の値が必要であり、他のすべてのチャンクのチャンクヘッダーのismoreフィールドには「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.
2つ以上のメッセージには同じメッセージ番号がある場合がありますが、メッセージ番号のそのような再利用は推奨されません。同じメッセージ番号を持つチャンクは、各メッセージの最後のチャンクのチャンクヘッダーのismoreフィールドに「last」の値がある1つ以上のメッセージのシーケンスを表します。チャンクヘッダーのismoreフィールドのすべてのチャンクは、「more」の値が次のチャンク（シーケンス）と同じメッセージに属し、そのチャンクヘッダーのismoreフィールドには「last」の値があります。言い換えれば、2つのメッセージに同じメッセージ番号がある場合、最初のメッセージの最後のチャンクが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.
消費者の動作は、すべてのメッセージの最後のチャンクが発生する前に、最終的なチャンク（つまり、チャンクヘッダーが「chk0 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つの隣接するチャンクには異なるメッセージ番号があります。ただし、同じメッセージ番号を持っている場合があります。2つの隣接するチャンクが同じメッセージ番号を持っている場合、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マルチプレックスされたエンティティにルートメッセージまたはその一部が含まれることが必要です。したがって、最初のチャンクには、2番目のチャンクにルートメッセージの最初のオクテットが付いたゼロオクテットのチャンクペイロードが含まれています。つまり、ルートメッセージのすべてのメッセージヘッダーは2番目のチャンクにあります。極端ではあるがありそうもない例として、チャンク4と7を除くすべてのチャンクにゼロのオクテットチャンクペイロードを備えた10のチャンクにメッセージを分割することが可能です。
This section defines additional parameters for Application/Vnd.pwg-multiplexed.
このセクションでは、Application/vnd.pwg-Multiplexedの追加パラメーターを定義します。
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 syntax for "parameter" is:
「パラメーター」の構文は次のとおりです。
parameter := "type" "=" type "/" subtype ; cf. [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.
Application/vnd.pwg-Multiplexedエンティティを処理するアプリケーションには、エンティティを表示する責任があります。ただし、Application/vnd.pwg-Multiplexedメッセージには、メッセージの表示とストレージの提案を提供するコンテンツディスポジションヘッダーが含まれている場合があり、場合によってはアプリケーションがそのようなヘッダーに注意を払うことがあります。
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マルチプレックスされたエンティティ全体を抑制するか、アプリケーション/vnd.pwgマルチプレックスされたエンティティをマルチパート/混合エンティティとして扱うという選択をユーザーに提供します。。この場合（エンティティが抑制されていない場合）、消費者は、結果のマルチパート/混合エンティティの各身体部分を表示するのに役立つコンテンツ拡散情報を見つけることができます。体の部分にコンテンツ拡張ヘッダーがない場合、消費者は身体部分を添付ファイルとして表示する必要があります。
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-multiplexedを認識していません。消費者は、アプリケーション/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つのコンポーネントがあります。画像はバイナリでエンコードされています。文字列「<<バイナリデータ>>」および「<<バイナリデータの一部>>」は、各例で各画像のバイナリデータのすべてまたは一部を表します。2つの画像は潜在的に並んでおり、3番目の画像はドキュメントの後半に表示されます。すべての画像はContent-IDによって識別され、2つの画像はコンテンツロケーションによっても識別されます。画像の1つは、コンテンツロケーションを参照しています。
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つの画像メッセージの中にインターリーブされています。4番目の例では、XHTMLメッセージは4つのチャンクに分割され、2つの並んでいる画像はそれぞれ2つのチャンクに分割されます。XHTMLチャンクは、画像チャンクの中にインターリーブされています。5番目の例では、空のペイロードと同じメッセージ番号の隣接するチャンクのチャンクがあります。
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.
最後の例は役に立たないケースに対処しているように見えるかもしれませんが、これらのケースが許可されている場合はソフトウェアを作成する方が簡単な場合があります。たとえば、バッファが埋めるとき、チャンクを書くのが最も簡単かもしれませんし、以前のチャンクが同じメッセージ番号を持っていても心配しないでください。同様に、空のチャンクでメッセージを終了するのが最も簡単かもしれません。最後に、Application/vnd.pwg-Multiplexed Content-Typeでは、最初のチャンクがルートメッセージの一部であることが必要です。いくつかの添付ファイルが発生した後にルートメッセージが起動する場合、プロデューサーにとってより便利な場合があります。チャンクは空になる可能性があるため、ルートメッセージの最初のチャンクは空になる可能性があります。つまり、ヘッダーも含まれていません。次に、最初のチャンクにはルートメッセージの一部が含まれていますが、プロデューサーはそのチャンクのオクテットを生成しません。
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.
MultiPart/関連エンティティの各ボディ部分とアプリケーション/vnd.pwg-Multiplexedエンティティの各メッセージには、消費者がセクション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-multiplexedエンティティと比較できます。
Content-Type: multipart/related; boundary="boundary-example";
type="text/xhtml+xml"
--boundary-example
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
--boundary-example
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
--boundary-example--
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"
CHK 1 550 LAST
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>
<p>some final text
</p>
</body>
</html>
CHK 2 6346 LAST
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 0 0 LAST
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"
CHK 1 267 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
CHK 2 6346 LAST
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 3 6401 LAST
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 1 166 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 1 80 LAST
<img src="cid:49568.47333xxx@foo.com"/>
</p>
<p>some final text
</p>
</body>
</html>
CHK 0 0 LAST
CHK 0 0最後
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個に分割されているため、画像への参照がチャンクの開始または終了のいずれかにできるだけ近いようになります。最初と2番目の画像への参照は、参照された画像に密接に従います。3番目の画像への参照は、参照される画像の前に密接に先行します。これにより、参照メッセージと参照メッセージの間の距離が最小限に抑えられます。さらに、最初の2つの画像メッセージは、それぞれ2つのチャンクに分割されます。
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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
CHK 2 184 MORE
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 2 6162 LAST
<<part of binary data>>
CHK 3 6201 LAST
<<part of binary data>>
CHK 1 127 MORE
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
CHK 4 7603 LAST
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 1 41 LAST
</p>
<p>some final text
</p>
</body>
</html>
CHK 0 0 LAST
CHK 0 0最後
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つの隣接するチャンクも示しています。これらの2つのチャンクは、単一のチャンクに合体する可能性がありますが、プログラミングの利便性のために別々に保たれる可能性があります。
Content-Type: application/vnd.pwg-multiplexed;
type=" application/vnd.pwg-xhtml-print+xml"
CHK 1 0 MORE
CHK 1 0
CHK 2 184 MORE
Content-ID: <49568.45876xxx@foo.com>
Content-Location: http://foo.com/images/image1.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 3 200 MORE
Content-ID: <49568.46000xxx@foo.com>
Content-Location: http://foo.com/images/image2.gif
Content-Type: image/gif
Content-Disposition: attachment
<<part of binary data>>
CHK 1 303 MORE
Content-ID: <49568.44343xxx@foo.com>
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Disposition: inline
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<body>
<p>some text
CHK 2 6162 MORE
<<part of binary data>>
CHK 3 6201 MORE
<<part of binary data>>
CHK 2 0 LAST
CHK 3 0 LAST
CHK 3 0最後
CHK 1 78 MORE
<img src="cid:49568.45876xxx@foo.com"/>
<img src="http://foo.com/images/image2.gif"/>
CHK 4 7603 MORE
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Disposition: attachment
<<binary data>>
CHK 4 0 LAST
CHK 1 127 MORE
some more text after the images
</p>
<p>some more text without images
</p>
<p>some more text
<img src="cid:49568.47333xxx@foo.com"/>
CHK 1 41 MORE
</p>
<p>some final text
</p>
</body>
</html>
CHK 1 0 LAST
CHK 1 0最後
CHK 0 0 LAST
CHK 0 0最後
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.
Application/vnd.pwg-Multiplexedエンティティの各メッセージに関連するセキュリティ上の考慮事項があります。これらのセキュリティ上の考慮事項は、メッセージのコンテンツタイプを定義するドキュメントで説明されています。このドキュメントでは対処されていません。
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:
また、アプリケーション/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
宛先：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-multiplexedメディアタイプ名：アプリケーションメディアサブタイプ名：ベンダーツリー-vnd.pwg-multiplexed必要なパラメーター：タイプ、メディアタイプ/サブタイプ。オプションのパラメーター：考慮事項をエンコードするオプションのパラメーターはありません：アプリケーション/vnd.pwg-multiplexedエンティティの各メッセージは、メッセージのコンテンツタイプによって許可された方法でエンコードできます。ただし、MultiPARTの推論を使用して、Application/VND.PWG-Multiplexedエンティティをエンコードすることはできません。それ以外の場合、メッセージはメッセージレベルで1回、Application/vnd.pwg-Multiplexedレベルで2回エンコードされます。セキュリティ上の考慮事項：RFC 3391のセクション6（セキュリティ上の考慮事項）を参照してください。公開された仕様：RFC3391。詳細については、連絡先への個人およびメールアドレス：
Robert Herriot 706 Colorado Ave. Palo Alto, CA 94303 USA Phone: 1-650-327-4466 Fax: 1-650-327-4466 EMail: bob@herriot.com
Robert Herriot 706 Colorado Ave. Palo Alto、CA 94303 USA電話：1-650-327-4466 FAX：1-650-327-4466メール：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.
著者は、Ugo Corda、Dave Crocker、Melinda Sue Grant、Graham Klyne、Carl-Uno Manros、Larry Masinter、Ira McDonald、Chris Newman、Henrik Frystyk Nielsen、Dale R. Worleyの貢献に感謝して認めています。特に、クリス・ニューマンは非常に貴重な助けを提供しました。
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[RFC1806] Troost、R。およびS. Dorner、「インターネットメッセージでのプレゼンテーション情報の伝達：コンテンツ - 分散ヘッダー」、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.クラーク、「メッセージ/外部ボディコンテンツアクセスタイプ」、RFC 1873、1995年12月。進行中。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP. Overell、「Syntaxspifications：ABNF」、RFC 2234、1997年11月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]レビンソン、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]レビンソン、E。、「コンテンツIDおよびメッセージ-IDユニフォームリソースロケーター」、RFC 2392、1998年8月。
[RFC2557] Palme, J., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML", RFC 2557, March 1999.
[RFC2557] Palme、J。、「HTML（MHTMLなどの集計ドキュメントのMIMEカプセル化」、RFC 2557、1999年3月。
[RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、編集者、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
Robert Herriot 706 Colorado Ave. Palo Alto, CA 94303 USA
ロバートヘリオット706コロラドアベニュー。パロアルト、カリフォルニア94303 USA
Phone: 1-650-327-4466 Fax: 1-650-327-4466 EMail: bob@herriot.com
電話：1-650-327-4466ファックス：1-650-327-4466メール：bob@herriot.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。