[要約] RFC 2912は、MIMEコンテンツのメディア機能を示すための方法を提案しています。このRFCの目的は、クライアントとサーバーが互いのメディア機能を認識し、最適なコンテンツを提供するための標準化を促進することです。
Network Working Group G. Klyne
Request for Comments: 2912 Content Technologies
Category: Standards Track September 2000
Indicating Media Features for MIME Content
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags.
「メディア機能セットを説明するための構文」では、シンプルなメディア機能タグを使用してメディア機能機能を記述するための式形式が表示されます。
This memo defines a Multipurpose Internet Mail Extensions (MIME) 'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.
このメモは、この式形式を使用してMIMEメッセージパーツを注釈するために使用できる多目的インターネットメールエクステンション（MIME） 'コンテンツフィーチャーを定義し、使用される可能性のある方法を示します。
Table of Contents
目次
1. Introduction ............................................... 2
1.1 Terminology and document conventions ................... 2
2. Motivation and goals ....................................... 3
3. The 'Content-features:' MIME header ........................ 4
3.1 Whitespace and folding long headers .................... 4
3.2 Usage considerations ................................... 4
3.2.1 Simple message parts ............................... 4
3.2.2 Multipart and other composites ..................... 5
3.2.3 Reference to external data ......................... 5
4. Examples ................................................... 5
4.1 Simple message ......................................... 5
4.2 Fax message ............................................ 6
4.3 Multipart/alternative data ............................. 6
4.4 Reference to external message data ..................... 8
4.5 Compressed data ........................................ 8
4.6 Multipart/related data ................................. 8
5. Security Considerations .................................... 9
6. Acknowledgements ........................................... 10
7. References ................................................. 10
8. Author's Address ........................................... 10
Full Copyright Statement ...................................... 11
In "A Syntax for Describing Media Feature Sets" [1], an expression format is presented for describing media feature capabilities as a combination of simple media feature tags, registered according to "Media Feature Tag Registration Procedure" [2]. This provides a format for message handling agents to describe the media feature content of messages that they can handle.
「メディア機能セットを説明するための構文」[1]では、「メディア機能タグ登録手順」[2]に従って登録されているシンプルなメディア機能タグの組み合わせとしてメディア機能機能を説明するための式形式が提示されています。これにより、メッセージ処理エージェントが処理できるメッセージのメディア機能コンテンツを説明する形式が提供されます。
This memo defines a MIME 'Content-features:' header that can be used to annotate a MIME message part using these feature expressions. This header provides a means to indicate media-related features of message content that go beyond the MIME content type.
このメモは、これらの機能式を使用してMIMEメッセージパーツを注釈するために使用できるMimeの「コンテンツフィーチャー：」ヘッダーを定義します。このヘッダーは、MIMEコンテンツタイプを超えたメッセージコンテンツのメディア関連機能を示す手段を提供します。
Consideration is also given to how it may be used to present message media content information that is problematic to express within the basic MIME framework.
また、基本的なMIMEフレームワーク内で表現するのに問題があるメッセージメディアコンテンツ情報を提示するために使用する方法についても考慮されます。
This section defines a number of terms and other document conventions, which are used with specific meaning in this memo.
このセクションでは、このメモで特定の意味を持って使用される多くの用語とその他のドキュメント規則を定義します。
media feature information that indicates facilities assumed to be available for the message content to be properly rendered or otherwise presented. Media features are not intended to include information that affects message transmission.
メッセージコンテンツが適切にレンダリングまたは提示されるように利用可能であると想定される施設を示すメディア機能情報。メディア機能には、メッセージ伝達に影響を与える情報を含めることを意図したものではありません。
feature set some set of media features described by a media feature assertion, as described in "A Syntax for Describing Media Feature Sets" [1]. (See that memo for a more formal definition of this term.)
機能「メディア機能セットを説明するための構文」で説明されているように、メディア機能のアサーションで説明されているメディア機能のセットセット[1]。（この用語のより正式な定義については、そのメモを参照してください。）
feature set expression a string that describes some feature set, formulated according to the rules in "A Syntax for Describing Media Feature Sets" [1] (and possibly extended by other specifications).
機能セット式式「メディア機能セットを記述するための構文」のルールに従って定式化されたいくつかの機能セットを記述する文字列[1]（おそらく他の仕様によって拡張される可能性があります）。
This specification uses syntax notation and conventions described in RFC 2234 "Augmented BNF for Syntax Specifications: ABNF" [3].
この仕様では、RFC 2234で説明されている構文表記と規則を使用します。
NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth.
注：このようなコメントは、このドキュメントの背後にある根拠に関する追加の非必須情報を提供します。このような情報は、適切な実装を構築するために必要ではありませんが、設計をより深く理解したい人を助けるかもしれません。
It is envisaged that media feature labelling of message parts may be used in the following ways:
メッセージパーツのメディア機能のラベル付けは、次の方法で使用できることが想定されています。
o to supply more detailed media feature information about a message content than can be provided by the 'Content-type:' header.
o 「コンテンツタイプ：」ヘッダーで提供できるよりも、メッセージコンテンツに関するより詳細なメディア機能情報を提供する。
o to provide summary media feature information (possibly including MIME content types) about the content of a composite MIME message part (e.g. 'multipart' or 'message'), without having to open up the inner content of the message.
o メッセージの内部コンテンツを開くことなく、概要メディア機能情報（おそらくMIMEコンテンツタイプを含む）をコンポジットMIMEメッセージパーツ（「マルチパート」または「メッセージ」など）のコンテンツについて提供します。
o to supply media feature information about external data referenced by a message part (e.g. 'message/external-body' MIME type). This information would not be available by examination of the message content.
o メディアを提供するには、メッセージパーツ（「メッセージ/外部ボディ」MIMEタイプなど）で参照される外部データに関する情報情報。この情報は、メッセージコンテンツを調べても利用できません。
o to describe the content of a message that is encrypted or encoded using some application-specific file structure that hides the content from a MIME processor. This information also would not be generally available by examination of the message content.
o MIMEプロセッサからコンテンツを隠すアプリケーション固有のファイル構造を使用して、暗号化またはエンコードされたメッセージのコンテンツを説明します。この情報は、メッセージコンテンツを調べても一般的には利用できません。
A new header field is defined that extends the allowable formats for 'optional-field' [4] with the following syntax:
次の構文を使用して、「オプションフィールド」[4]の許容形式を拡張する新しいヘッダーフィールドが定義されています。
optional-field =/ "Content-features" ":" Feature-expr
Feature-expr = filter ; See [1], section 4.1
where 'filter' is the media feature expression format defined by "A Syntax for Describing Media Feature Sets" [1].
ここで、「フィルター」は、「メディア機能セットを説明するための構文」で定義されるメディア機能の表現形式です[1]。
This header provides additional information about the message content directly contained or indirectly referenced in the corresponding MIME message part.
このヘッダーは、対応するMIMEメッセージパーツに直接含まれるか、間接的に参照されるメッセージコンテンツに関する追加情報を提供します。
In some circumstances, media feature expressions can be very long.
状況によっては、メディア機能の表現は非常に長い場合があります。
According to "A Syntax for Describing Media Feature Sets" [1], whitespace is allowed between lexical elements of a media feature expression. Further, RFC822/MIME [4,5] allows folding of long headers at points where whitespace appears to avoid line length restrictions.
「メディア機能セットを記述するための構文」[1]によると、メディア機能表現の語彙要素間で白面は許可されています。さらに、RFC822/MIME [4,5]は、白人がラインの長さの制限を避けるように見えるポイントで長いヘッダーを折りたたむことができます。
Therefore, it is recommended that whitespace is included as permitted, especially in long media feature expressions, to facilitate the folding of headers by agents that do not otherwise understand the syntax of this field.
したがって、このフィールドの構文を理解していないエージェントによるヘッダーの折りたたみを容易にするために、特に長いメディア機能表現では、Whitespaceが許可されているように含まれることをお勧めします。
When applied to a simple MIME message part, the header should appear just once and is used to convey additional information about the message part content that goes beyond that provided by the MIME 'Content-type:' header field. The 'Content-features:' header may indicate a content type that is different than that given by the MIME 'Content-type:' header. This is possible but not recommended when applied to a non-composite body part: in any case, MIME content type processing must be performed in accordance with the 'Content-type:' header.
シンプルなMimeメッセージパーツに適用される場合、ヘッダーは1回だけ表示され、Mime 'Content-Type：'ヘッダーフィールドによって提供されるメッセージパーツコンテンツに関する追加情報を伝えるために使用されます。'Content-Features：'ヘッダーは、MIME 'Content-Type：'ヘッダーで与えられたコンテンツタイプとは異なるコンテンツタイプを示す場合があります。これは可能ですが、非コンポジットボディパーツに適用する場合は推奨されません。いずれにせよ、「コンテンツタイプ：」ヘッダーに従ってMIMEコンテンツタイプ処理を実行する必要があります。
NOTE: Once the message content has been delivered to an application, it is possible that subsequent processing may be affected by content type information indicated by the media feature expression. See example 4.5 below.
注：メッセージコンテンツがアプリケーションに配信されると、その後の処理がメディア機能の表現で示されるコンテンツタイプ情報の影響を受ける可能性があります。以下の例4.5を参照してください。
'Content-features:' headers may be applied to a MIME multipart indicating information about the inner content of the multipart.
'Content-Features：'ヘッダーは、マルチパートの内部コンテンツに関する情報を示すMIMEマルチパートに適用できます。
Implementations must not assume a one-to-one relationship between 'Content-features' headers and contained body parts. Headers may appear on a containing multipart wrapper in a different order than the body parts to which they refer; a single header may refer to more than one contained body part; several headers may refer to the same contained body part.
実装は、「コンテンツフィーチャー」ヘッダーと体の部分を含む1対1の関係を想定してはなりません。ヘッダーは、それらが参照する身体部分とは異なる順序で、マルチパートラッパーを含むマルチパートラッパーに表示される場合があります。単一のヘッダーは、複数の含まれているボディ部分を指す場合があります。いくつかのヘッダーは、同じ含まれるボディ部分を参照する場合があります。
If it is important to relate specific media features to specific contained MIME body parts, then the 'Content-features:' header should be applied directly to the body part concerned, rather than the surrounding composite.
特定のメディア機能を特定の含まれるMIMEボディ部分に関連付けることが重要な場合は、「コンテンツフィーチャー：」ヘッダーは、周囲の複合材ではなく、関係する身体部分に直接適用する必要があります。
NOTE: The intent here is to allow summary media feature information to be provided without having to open up and examine the inner content of the MIME message.
注：ここでの意図は、MIMEメッセージの内部コンテンツを開いて調べることなく、要約メディア機能情報を提供できるようにすることです。
Similar usage may apply when the message format is a non-MIME or opaque composite; e.g. 'application/zip', or an encrypted message. In these cases, the option of examining the message content to discover media feature information is not available.
メッセージ形式が非mimeまたは不透明な複合材である場合、同様の使用法が適用される場合があります。例えば「アプリケーション/zip」、または暗号化されたメッセージ。これらの場合、メディア機能情報を発見するためにメッセージコンテンツを調べるオプションは利用できません。
Media feature information about data indirectly referenced by a MIME body part rather than contained within a message can be conveyed using one or more 'Content-features:' headers.
メディアの特徴データに関するデータに関する情報は、メッセージ内に含まれるのではなく、MIMEボディの部分によって間接的に参照されています。
For example, media information --including contained MIME content type(s)-- about the data referenced by a MIME 'Message/external-body' may be conveyed.
たとえば、MIME「Message/external-body」が参照するデータに関するメディア情報（含まれているMIMEコンテンツタイプを含む）が伝えられる場合があります。
Mime-Version: 1.0
Content-type: text/plain;charset=US-ASCII
Content-features: (& (paper-size=A4) (ua-media=stationery) )
: (data) :
： （データ） ：
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="break"
Content-features:
(& (Type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-S)
(dpi=200)
(dpi-xyratio=200/100)
(paper-size=A4)
(image-coding=MH) (MRC-mode=0)
(ua-media=stationery) )
--break
Content-Type: image/tiff; name="coverpage.tiff"
Content-Transfer-Encoding: base64
Content-Description: This part is a coverpage
Content-Disposition: attachment; filename="coverpage.tiff"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA AAAAAAAAEAAAZAAAAAEAAAD+////AAAAAAAAAAD//////////////////// : (more data) : --break
0m8r4kgxgueaaaaaaaaaaaaaaaaaaaaaaaaaaaapgadap7/cqagaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Content-Type: image/tiff; name="document.tiff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.tiff"
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA : (more data) : --break--
aaaadgaaaaaaaaaaaaaaaaaaaaaaabiaaaaaaaaaaafaaaabuaaaafaaaafaaabg ggaaabsaaaaaaaaaaaaaaaab4aaaaaaaaaaaaaaaaaaaaaaceaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
This example illustrates three points:
この例は、3つのポイントを示しています。
o Information about the various parts in a multipart/alternative can be made available before the alternative body parts are processed. This may facilitiate optimum one-pass processing of multipart/alternative data.
o マルチパート/代替のさまざまな部分に関する情報を、代替体の部分が処理する前に利用可能にすることができます。これにより、マルチパート/代替データの最適なワンパス処理が促進される場合があります。
o There may be alternatives having the same basic MIME content-type, but differing in the content features that they use.
o 同じ基本的なMIMEコンテンツタイプを持っている代替手段があるかもしれませんが、使用するコンテンツ機能は異なります。
o There is NO defined correspondence between 'Content-features' headers and contained body parts.
o 「コンテンツフィーチャー」ヘッダーと体の部分が含まれている間に定義された対応はありません。
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="break"
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features:
(& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
Content-features:
(& (Type="text/html") (charset=ISO-8859-1) (color=binary) )
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=binary)
:
(data)
:
--break
Content-type: "text/plain";charset=US-ASCII
Content-features: (color=limited)
: (data) : --break
：（データ）： - ブレイク
Content-type: text/html;charset=iso-8859-1
Content-features: (color=binary)
:
(data)
:
--break
Content-type: text/html;charset=iso-8859-1
Content-features: (color=limited)
: (data) : --break--
：（データ）： - ブレイク -
Mime-Version: 1.0
Content-type: message/external-body; access-type=URL;
URL="http://www.foo.com/file1.html"
Content-type: Multipart/mixed
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features: (& (Type="image/tiff") (color=limited) )
<end>
<End>
This example shows how the 'Content-features' header can be used to overcome the problem noted in the MIME registration for 'Application/zip' regarding information about the data content.
この例は、「コンテンツフィーチャー」ヘッダーを使用して、データコンテンツに関する情報に関する「アプリケーション/zip」のMIME登録で指摘されている問題を克服する方法を示しています。
Mime-Version: 1.0
Content-type: application/zip
Content-features: (& (Type="text/plain") (charset=US-ASCII) )
Content-features: (& (Type="image/tiff") (color=limited) )
Content-transfer-encoding: base64
: (data) : <end>
：（データ）：<End>
(See also: RFC 2387, "The MIME Multipart/Related Content-type" [8])
（参照：RFC 2387、「The Mime MultiPart/関連コンテンツタイプ」[8]）
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"; start="<foo3@foo1@bar.net>"
Content-features: (& (type="text/html") (charset=US-ASCII) )
Content-features: (type="image/gif")
--boundary-example
Content-Type: text/html;charset=US-ASCII
Content-ID: <foo3@foo1@bar.net>
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo">
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
- Boundary-Exampleコンテンツロケーション：http：//www.ietf.cnri.reston.va.us/images/ietflogo.gif content-type：image/gif content-transfer-encoding：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach punvchlyawdodcaoqykgmtk5 nsbjrvglibvvbvvbmfmfmfmfmfmfmfmflibvvbvbvvvbvvvvbvvvvbvvvbvbvvvbvvvvvgbgljyxrpb24gchjvagliaxrzc4a等など...
--boundary-example--
- バウンドリー - 例 -
When applied to simple or multipart MIME formatted data, a media feature expression provides summary information about the message data, which in many cases can be determined by examination of the message content. Under these circumstances, no additional security considerations appear to be raised.
シンプルまたはマルチパートMIMEフォーマットデータに適用されると、メディア機能式はメッセージデータに関する要約情報を提供します。これは、多くの場合、メッセージコンテンツの調べによって決定できます。これらの状況では、追加のセキュリティ上の考慮事項は提起されていないようです。
When applied to other message composites, especially encrypted message content, feature expressions may disclose information that is otherwise unavailable. In these cases, some security considerations associated with media content negotiation [1,2] may have greater relevance.
他のメッセージコンポジット、特に暗号化されたメッセージコンテンツに適用されると、特徴式は、それ以外の場合は利用できない情報を開示する場合があります。これらの場合、メディアコンテンツの交渉に関連するいくつかのセキュリティ上の考慮事項[1,2]は、より大きな関連性を持っている可能性があります。
It is suggested here that media feature descriptions may be usefully employed with encrypted message content. In doing this, take care to ensure that the purpose of encryption is not compromised (e.g. encryption might be intended to conceal the fact that a particular application data format is being used, which fact might be disclosed by an injudiciously applied Content-features header).
ここでは、メディア機能の説明が暗号化されたメッセージコンテンツで有用に採用される可能性があることが示唆されています。これを行う際に、暗号化の目的が損なわれないように注意してください（たとえば、暗号化は、特定のアプリケーションデータ形式が使用されているという事実を隠すことを目的としている可能性があります。。
If a 'Content-features' header is applied to a multipart/signed object (or indeed outside any other form of signed data) the media feature information is not protected. This unprotected information could be tampered with, possibly fooling implementations into doing inappropriate things with the contained material. (Putting the media feature information inside the signed information would overcome this, at the cost of requiring implementations to parse the inner structure to find it.)
「コンテンツフィーチュア」ヘッダーがマルチパート/署名されたオブジェクト（または実際には他の形式の署名データの外側）に適用されている場合、メディア機能情報は保護されていません。この保護されていない情報は、抑制された資料で不適切なことを行うために実装をだまして改ざんする可能性があります。（署名された情報内にメディア機能情報を置くと、実装を解析するために実装を要求するためにこれを克服することができます。）
This proposal draws from discussions with Dan Wing. The fax message example was taken from a proposal by Mike Ruhl. The multipart/related example is developed from RFC 2557 [7].
この提案は、ダン・ウィングとの議論から引き出されます。FAXメッセージの例は、Mike Ruhlの提案から取得されました。マルチパート/関連例は、RFC 2557 [7]から開発されています。
The author would like to thank the following people who offered comments that led to significant improvements: Mr Hiroshi Tamura, Ted Hardie, Maurizio Codogno, Jacob Palme, Ned Freed.
著者は、大幅な改善につながったコメントを提供してくれた以下の人々に感謝したいと思います。タムラ氏、テッド・ハーディー、マウリツィオ・コドゴノ、ジェイコブ・パルメ、ネッド・フリード。
[1] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[1] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[2] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[2] Holtman、K.、Mutz、A。、およびT. Hardie、「メディア機能タグ登録手順」、RFC 2506、1999年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[4] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[4] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 1: Format of Internet message bodies", RFC 2045, November 1996.
[5] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[6] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[6] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。
[7] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[7] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集約文書のMIMEカプセル化」、RFC 2557、1999年3月。
Graham Klyne Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
Graham Klyne Content Technologies Ltd. 1220 Parkview、アーリントンビジネスパークシールリーディング、RG7 4SAイギリス
Phone: +44 118 930 1300
Fax: +44 118 930 1301
EMail: GK@ACM.ORG
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。