[要約] RFC 2387は、MIME Multipart/Relatedコンテンツタイプの仕様を定義しており、関連する複数のメディアタイプを1つのメッセージで表現するための方法を提供しています。このRFCの目的は、関連するコンテンツを効果的に組み合わせ、送信および受信するための標準化された手法を提供することです。
Network Working Group E. Levinson
Request for Comments: 2387 August 1998
Obsoletes: 2112
Category: Standards Track
The MIME Multipart/Related Content-type
MIMEマルチパート/関連コンテンツタイプ
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use.
Multipart / Related content-typeは、関連するMIMEボディパーツの集合体であるオブジェクトを表すための共通のメカニズムを提供します。このドキュメントは、Multipart / Relatedコンテンツタイプを定義し、その使用例を提供します。
Several applications of MIME, including MIME-PEM, and MIME-Macintosh and other proposals, require multiple body parts that make sense only in the aggregate. The present approach to these compound objects has been to define specific multipart subtypes for each new object. In keeping with the MIME philosophy of having one mechanism to achieve the same goal for different purposes, this document describes a single mechanism for such aggregate or compound objects.
MIME-PEMを含むMIMEのいくつかのアプリケーション、およびMIME-Macintoshおよびその他の提案では、集合体でのみ意味を持つ複数のボディパーツが必要です。これらの複合オブジェクトに対する現在のアプローチは、新しいオブジェクトごとに特定のマルチパートサブタイプを定義することです。このドキュメントでは、さまざまな目的で同じ目標を達成するためのメカニズムを1つ持つというMIMEの哲学に従って、このような集合オブジェクトまたは複合オブジェクトの単一のメカニズムについて説明します。
The Multipart/Related content-type addresses the MIME representation of compound objects. The object is categorized by a "type" parameter. Additional parameters are provided to indicate a specific starting body part or root and auxiliary information which may be required when unpacking or processing the object.
Multipart / Relatedコンテンツタイプは、複合オブジェクトのMIME表現を扱います。オブジェクトは「タイプ」パラメーターによって分類されます。オブジェクトを解凍または処理するときに必要になる可能性がある特定の開始ボディパーツまたはルートおよび補助情報を示すために、追加のパラメーターが提供されます。
Multipart/Related MIME entities may contain Content-Disposition headers that provide suggestions for the storage and display of a body part. Multipart/Related processing takes precedence over Content-Disposition; the interaction between them is discussed in section 4.
Multipart / Related MIMEエンティティには、ボディパーツの保存と表示に関する提案を提供するContent-Dispositionヘッダーが含まれる場合があります。マルチパート/関連処理はContent-Dispositionよりも優先されます。それらの間の相互作用については、セクション4で説明します。
Responsibility for the display or processing of a Multipart/Related's constituent entities rests with the application that handles the compound object.
Multipart / Relatedの構成エンティティの表示または処理の責任は、複合オブジェクトを処理するアプリケーションにあります。
The following form is copied from RFC 1590, Appendix A.
次のフォームはRFC 1590の付録Aからコピーされたものです。
To: IANA@isi.edu
Subject: Registration of new Media Type content-type/subtype
Media Type name: Multipart
メディアタイプ名：マルチパート
Media subtype name: Related
メディアサブタイプ名：関連
Required parameters: Type, a media type/subtype.
必須パラメーター：タイプ、メディアタイプ/サブタイプ。
Optional parameters: Start Start-info
オプションのパラメーター：Start Start-info
Encoding considerations: Multipart content-types cannot have encodings.
エンコーディングに関する考慮事項：マルチパートコンテンツタイプにはエンコーディングを含めることができません。
Security considerations: Depends solely on the referenced type.
セキュリティに関する考慮事項：参照されるタイプにのみ依存します。
Published specification: RFC-REL (this document).
公開された仕様：RFC-REL（このドキュメント）。
Person & email address to contact for further information: Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 +1 908 494 1606 XIson@cnj.digex.net
詳細について連絡する人とメールアドレス：Edward Levinson 47 Clive Street Metuchen、NJ 08840-1060 +1 908 494 1606 XIson@cnj.digex.net
The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts. The content-type of the Multipart/Related object is specified by the type parameter. The "start" parameter, if given, points, via a content-ID, to the body part that contains the object root. The default root is the first body part within the Multipart/Related body.
Multipart / Relatedメディアタイプは、相互に関連する複数のボディパーツで構成される複合オブジェクトを対象としています。マルチパート/関連オブジェクトの場合、構成するボディパーツを個別に表示することで適切な表示を実現できません。 Multipart / Relatedオブジェクトのコンテンツタイプは、typeパラメータで指定されます。 「start」パラメータが指定されている場合、content-IDを介して、オブジェクトルートを含むボディパーツを指します。デフォルトのルートは、マルチパート/関連ボディ内の最初のボディパーツです。
The relationships among the body parts of a compound object distinguishes it from other object types. These relationships are often represented by links internal to the object's components that reference the other components. Within a single operating environment the links are often file names, such links may be represented within a MIME message using content-IDs or the value of some other "Content-" headers.
複合オブジェクトのボディパーツ間の関係は、複合オブジェクトを他のオブジェクトタイプと区別します。これらの関係は、多くの場合、他のコンポーネントを参照するオブジェクトのコンポーネントの内部リンクによって表されます。単一の動作環境内では、リンクは多くの場合ファイル名です。このようなリンクは、コンテンツIDまたは他の「Content-」ヘッダーの値を使用してMIMEメッセージ内で表すことができます。
The type parameter must be specified and its value is the MIME media type of the "root" body part. It permits a MIME user agent to determine the content-type without reference to the enclosed body part. If the value of the type parameter and the root body part's content-type differ then the User Agent's behavior is undefined.
typeパラメータを指定する必要があり、その値は「ルート」ボディパーツのMIMEメディアタイプです。これにより、MIMEユーザーエージェントは、囲まれたボディパーツを参照せずにコンテンツタイプを判別できます。 typeパラメータの値とルートボディパーツのcontent-typeが異なる場合、ユーザーエージェントの動作は未定義です。
The start parameter, if given, is the content-ID of the compound object's "root". If not present the "root" is the first body part in the Multipart/Related entity. The "root" is the element the applications processes first.
開始パラメーターが指定されている場合は、複合オブジェクトの「ルート」のコンテンツIDです。存在しない場合、「ルート」はMultipart / Relatedエンティティの最初のボディパーツです。 「ルート」は、アプリケーションが最初に処理する要素です。
Additional information can be provided to an application by the start-info parameter. It contains either a string or points, via a content-ID, to another MIME entity in the message. A typical use might be to provide additional command line parameters or a MIME entity giving auxiliary information for processing the compound object.
start-infoパラメーターを使用して、アプリケーションに追加情報を提供できます。文字列が含まれるか、コンテンツIDを介して、メッセージ内の別のMIMEエンティティをポイントします。典型的な用途は、追加のコマンドラインパラメータを提供することや、複合オブジェクトを処理するための補助情報を提供するMIMEエンティティを提供することです。
Applications that use Multipart/Related must specify the interpretation of start-info. User Agents shall provide the parameter's value to the processing application. Processes can distinguish a start-info reference from a token or quoted-string by examining the first non-white-space character, "<" indicates a reference.
Multipart / Relatedを使用するアプリケーションは、start-infoの解釈を指定する必要があります。ユーザーエージェントは、処理アプリケーションにパラメーターの値を提供します。プロセスは、最初の空白以外の文字を調べることにより、start-info参照をトークンまたは引用文字列から区別できます。「<」は参照を示します。
related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent
cid-list := cid cid-list
cid-list：= cid cid-list
cid := msg-id ; c.f. [822]
value := token / quoted-string ; c.f. [MIME]
; value cannot begin with "<"
Note that the parameter values will usually require quoting. Msg-id contains the special characters "<", ">", "@", and perhaps other special characters. If msg-id contains quoted-strings, those quote marks must be escaped. Similarly, the type parameter contains the special character "/".
通常、パラメータ値には引用符が必要です。 Msg-idには、特殊文字「<」、「>」、「@」、およびおそらく他の特殊文字が含まれています。 msg-idに引用符付きの文字列が含まれている場合、それらの引用符はエスケープする必要があります。同様に、typeパラメータには特殊文字「/」が含まれています。
Content-Disposition Headers [DISP] suggest presentation styles for MIME body parts. [DISP] describes two presentation styles, called the disposition type, INLINE and ATTACHMENT. These, used within a multipart entity, allow the sender to suggest presentation information. [DISP] also provides for an optional storage (file) name. Content-Disposition headers could appear in one or more body parts contained within a Multipart/Related entity.
Content-Dispositionヘッダー[DISP]は、MIMEボディパーツのプレゼンテーションスタイルを提案します。 [DISP]は、配置タイプINLINEとATTACHMENTと呼ばれる2つの表示スタイルについて説明しています。これらは、マルチパートエンティティ内で使用され、送信者がプレゼンテーション情報を提案できるようにします。 [DISP]は、オプションのストレージ（ファイル）名も提供します。 Content-Dispositionヘッダーは、Multipart / Relatedエンティティ内に含まれる1つ以上のボディパーツに表示される可能性があります。
Using Content-Disposition headers in addition to Multipart/Related provides presentation information to User Agents that do not recognize Multipart/Related. They will treat the multipart as Multipart/Mixed and they may find the Content-Disposition information useful.
Multipart / Relatedに加えてContent-Dispositionヘッダーを使用すると、Multipart / Relatedを認識しないユーザーエージェントにプレゼンテーション情報が提供されます。彼らはマルチパートをマルチパート/混合として扱い、コンテンツ配置情報が役立つと感じるかもしれません。
With Multipart/Related however, the application processing the compound object determines the presentation style for all the contained parts. In that context the Content-Disposition header information is redundant or even misleading. Hence, User Agents that understand Multipart/Related shall ignore the disposition type within a Multipart/Related body part.
ただし、Multipart / Relatedでは、複合オブジェクトを処理するアプリケーションが、含まれているすべてのパーツの表示スタイルを決定します。そのコンテキストでは、Content-Dispositionヘッダー情報は冗長であり、誤解を招く可能性さえあります。したがって、Multipart / Relatedを理解するユーザーエージェントは、Multipart / Relatedボディパーツ内の処理タイプを無視します。
It may be possible for a User Agent capable of handling both Multipart/Related and Content-Disposition headers to provide the invoked application the Content-Disposition header's optional filename parameter to the Multipart/Related. The use of that information will depend on the specific application and should be specified when describing the handling of the corresponding compound object. Such descriptions would be appropriate in an RFC registering that object's media type.
Multipart / RelatedヘッダーとContent-Dispositionヘッダーの両方を処理できるユーザーエージェントが、呼び出されたアプリケーションにContent-Dispositionヘッダーのオプションのファイル名パラメーターをMultipart / Relatedに提供できる場合があります。その情報の使用は特定のアプリケーションに依存し、対応する複合オブジェクトの処理を説明するときに指定する必要があります。そのような記述は、そのオブジェクトのメディアタイプを登録するRFCで適切です。
The X-FixedRecord content-type consists of one or more octet-streams and a list of the lengths of each record. The root, which lists the record lengths of each record within the streams. The record length list, type Application/X-FixedRecord, consists of a set of INTEGERs in ASCII format, one per line. Each INTEGER gives the number of octets from the octet-stream body part that constitute the next "record".
X-FixedRecord content-typeは、1つ以上のオクテットストリームと各レコードの長さのリストで構成されます。ストリーム内の各レコードのレコード長をリストするルート。 Application / X-FixedRecordタイプのレコード長リストは、ASCII形式のINTEGERのセットで構成され、1行に1つです。各INTEGERは、次の「レコード」を構成するオクテットストリームボディパートからのオクテットの数を示します。
The example below, uses a single data block.
以下の例では、単一のデータブロックを使用しています。
Content-Type: Multipart/Related; boundary=example-1
start="<950120.aaCC@XIson.com>";
type="Application/X-FixedRecord"
start-info="-o ps"
--example-1
Content-Type: Application/X-FixedRecord
Content-ID: <950120.aaCC@XIson.com>
25 10 34 10 25 21 26 10 --example-1 Content-Type: Application/octet-stream Content-Description: The fixed length records Content-Transfer-Encoding: base64 Content-ID: <950120.aaCB@XIson.com>
25 10 34 10 25 21 26 10 --example-1 Content-Type：Application / octet-stream Content-Description：固定長レコードContent-Transfer-Encoding：base64 Content-ID：<950120.aaCB@XIson.com>
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo=
T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1 YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW NrIHF1YWNrCkUgSSBFIEkgTwo =
--example-1--
-例-1--
The Text/X-Okie is an invented markup language permitting the inclusion of images with text. A feature of this example is the inclusion of two additional body parts, both picture. They are referred to internally by the encapsulated document via each picture's body part content-ID. Usage of "cid:", as in this example, may be useful for a variety of compound objects. It is not, however, a part of the Multipart/Related specification.
Text / X-Okieは、テキストを含む画像を含めることを可能にする、発明されたマークアップ言語です。この例の特徴は、両方の画像の2つの追加のボディパーツが含まれていることです。それらは、カプセル化されたドキュメントによって、各画像のボディパーツコンテンツIDを介して内部的に参照されます。この例のように「cid：」を使用すると、さまざまな複合オブジェクトに役立つ場合があります。ただし、Multipart / Related仕様の一部ではありません。
Content-Type: Multipart/Related; boundary=example-2;
start="<950118.AEBH@XIson.com>"
type="Text/x-Okie"
--example-2
Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118.AEB0@XIson.com>"
Content-ID: <950118.AEBH@XIson.com>
Content-Description: Document
{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:950118.AECB@XIson.com}
{para}
Now this is an enlargement of the area ...
{image file=cid:950118:AFDH@XIson.com}
{/doc}
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AFDH@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture A
[encoded jpeg image]
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
[encoded jpeg image] --example-2--
[エンコードされたjpeg画像] --example-2--
In the above example each image body part could also have a Content-Disposition header. For example,
上記の例では、各画像の本文部分にContent-Dispositionヘッダーを含めることもできます。例えば、
--example-2
Content-Type: image/jpeg
Content-ID: <950118.AECB@XIson.com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
Content-Disposition: INLINE
[encoded jpeg image] --example-2--
[エンコードされたjpeg画像] --example-2--
User Agents that recognize Multipart/Related will ignore the Content-Disposition header's disposition type. Other User Agents will process the Multipart/Related as Multipart/Mixed and may make use of that header's information.
Multipart / Relatedを認識するユーザーエージェントは、Content-Dispositionヘッダーの処理タイプを無視します。他のユーザーエージェントはMultipart / RelatedをMultipart / Mixedとして処理し、そのヘッダーの情報を利用する場合があります。
User agents that do not recognize Multipart/Related shall, in accordance with [MIME], treat the entire entity as Multipart/Mixed. MIME User Agents that do recognize Multipart/Related entities but are unable to process the given type should give the user the option of suppressing the entire Multipart/Related body part shall be.
Multipart / Relatedを認識しないユーザーエージェントは、[MIME]に従って、エンティティ全体をMultipart / Mixedとして扱います。 Multipart / Relatedエンティティを認識しているが、特定のタイプを処理できないMIMEユーザーエージェントは、Multipart / Relatedボディパーツ全体を抑制するオプションをユーザーに提供する必要があります。
Existing MIME-capable mail user agents (MUAs) handle the existing media types in a straightforward manner. For discrete media types (e.g. text, image, etc.) the body of the entity can be directly passed to a display process. Similarly the existing composite subtypes can be reduced to handing one or more discrete types. Handling Multipart/Related differs in that processing cannot be reduced to handling the individual entities.
既存のMIME対応メールユーザーエージェント（MUA）は、既存のメディアタイプを簡単な方法で処理します。個別のメディアタイプ（テキスト、画像など）の場合、エンティティの本体を表示プロセスに直接渡すことができます。同様に、既存の複合サブタイプは、1つ以上の個別のタイプを処理するように削減できます。 Multipart / Relatedの処理は、処理を個々のエンティティの処理に限定できない点で異なります。
The following sections discuss what information the processing application requires.
次のセクションでは、処理アプリケーションに必要な情報について説明します。
It is possible that an application specific "receiving agent" will manipulate the entities for display prior to invoking actual application process. Okie, above, is an example of this; it may need a receiving agent to parse the document and substitute local file names for the originator's file names. Other applications may just require a table showing the correspondence between the local file names and the originator's. The receiving agent takes responsibility for such processing.
アプリケーション固有の「受信エージェント」は、実際のアプリケーションプロセスを呼び出す前に、エンティティを操作して表示することができます。上記のOkieはこの例です。ドキュメントを解析し、発信者のファイル名をローカルファイル名に置き換えるには、受信エージェントが必要な場合があります。他のアプリケーションでは、ローカルファイル名と発信者のファイル名の対応を示すテーブルが必要なだけかもしれません。受け取り側のエージェントがそのような処理を担当します。
MIME-capable mail user agents (MUAs) are required to provide the application: (a) the bodies of the MIME entities and the entity Content-* headers,
アプリケーションを提供するには、MIME対応のメールユーザーエージェント（MUA）が必要です。（a）MIMEエンティティの本体とエンティティのContent- *ヘッダー、
(b) the parameters of the Multipart/Related Content-type header, and
（b）Multipart / Related Content-typeヘッダーのパラメーター、および
(c) the correspondence between each body's local file name, that body's header data, and, if present, the body part's content-ID.
（c）各ボディのローカルファイル名、そのボディのヘッダーデータ、および存在する場合はボディパーツのコンテンツIDの間の対応。
The Multipart/Related media type will be used for objects that have internal linkages between the body parts. When the objects are stored the linkages may require processing by the application or its receiving agent.
マルチパート/関連メディアタイプは、ボディパーツ間に内部リンケージがあるオブジェクトに使用されます。オブジェクトが格納されると、リンケージはアプリケーションまたはその受信エージェントによる処理を必要とする場合があります。
MIME is a recursive structure. Hence one must expect a Multipart/Related entity to contain other Multipart/Related entities. When a Multipart/Related entity is being processed for display or storage, any enclosed Multipart/Related entities shall be processed as though they were being stored.
MIMEは再帰的な構造です。したがって、マルチパート/関連エンティティが他のマルチパート/関連エンティティを含むことを期待する必要があります。 Multipart / Relatedエンティティが表示または保存のために処理されている場合、囲まれたMultipart / Relatedエンティティは、保存されているかのように処理されます。
It is suggested that MUAs that use configuration mechanisms, see [CFG] for an example, refer to Multipart/Related as Multi-part/Related/<type>, were <type> is the value of the "type" parameter.
構成メカニズムを使用するMUA（例については[CFG]を参照）、Multipart / Related as Multi-part / Related / <type>を参照することをお勧めします。<type>は「type」パラメーターの値です。
Security considerations relevant to Multipart/Related are identical to those of the underlying content-type.
Multipart / Relatedに関連するセキュリティの考慮事項は、基になるコンテンツタイプの考慮事項と同じです。
This proposal is the result of conversations the author has had with many people. In particular, Harald A. Alvestrand, James Clark, Charles Goldfarb, Gary Houston, Ned Freed, Ray Moody, and Don Stinchfield, provided both encouragement and invaluable help. The author, however, take full responsibility for all errors contained in this document.
この提案は、著者が多くの人々と行った会話の結果です。特に、Harald A. Alvestrand、James Clark、Charles Goldfarb、Gary Houston、Ned Freed、Ray Moody、Don Stinchfieldは、励ましと計り知れない助けの両方を提供してくれました。ただし、作成者は、このドキュメントに含まれるすべてのエラーについて全責任を負います。
[822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[822]クロッカーD。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[CID] 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.
[CID] Levinson、E。、およびJ. Clark、「Message / External-Body Content-ID Access Type」、RFC 1873、1995年12月、Levinson、E。、「Message / External-Body Content-ID Access Type」、進行中の作業。
[CFG] Borenstein, N., "A User Agent Configuration Mechanism For Multimedia Mail Format Information", RFC 1524, September 1993.
[CFG] Borenstein、N。、「マルチメディアメール形式情報のユーザーエージェント構成メカニズム」、RFC 1524、1993年9月。
[DISP] Troost, R., and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[DISP] Troost、R。、およびS. Dorner、「インターネットメッセージでのプレゼンテーション情報の伝達：Content-Dispositionヘッダー」、RFC 1806、1995年6月。
[MIME] Borenstein, N., and Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Borenstein、N。、およびFreed、N。、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
Edward Levinson 47 Clive Street Metuchen, NJ 08840-1060 USA
エドワードレビンソン47 Clive Street Metuchen、NJ 08840-1060 USA
Phone: +1 908 494 1606
EMail: XIson@cnj.digex.com
Corrected cid urls to conform to RFC 2111; the angle brackets were removed.
RFC 2111に準拠するようにcid urlを修正しました。山かっこが削除されました。
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。