Network Working Group E. Burger, Ed.
Request for Comments: 4483 Cantata Technolgy, Inc.
Category: Standards Track May 2006
A Mechanism for Content Indirection
in Session Initiation Protocol (SIP) Messages
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI.
この文書では、セッション開始プロトコル（SIP）のためのコンテンツ間接の要件を満たすためにURL MIME外部-ボディアクセスタイプへの拡張を定義します。これらの拡張は、URIを介して間接的に参照されるSIPメッセージ内の任意のMIMEパートを可能にすることを目的としています。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Use Case Examples ...............................................3
3.1. Presence Notification ......................................4
3.2. Document Sharing ...........................................4
4. Requirements ....................................................5
5. Application of RFC 2017 to the Content Indirection Problem ......6
5.1. Specifying Support for Content Indirection .................6
5.2. Mandatory support for HTTP URI .............................7
5.3. Rejecting Content Indirection ..............................7
5.4. Specifying the Location of the Content via a URI ...........7
5.5. Marking Indirect Content Optional ..........................7
5.6. Specifying Versioning Information for the URI ..............8
5.7. Specifying the URI Lifetime ................................8
5.8. Specifying the type of the Indirect Content ................8
5.9. Specifying the Size of the Indirect Content ................9
5.10. Specifying the Purpose of the Indirect Content ............9
5.11. Specifying Multiple URIs for Content Indirection .........10
5.12. Specifying a Hash Value for the Indirect Content .........10
5.13. Supplying Additional Comments about the Indirect
Content ..................................................11
5.14. Relationship to Call-Info, Error-Info, and
Alert-Info Headers .......................................11
6. Examples .......................................................12
6.1. Single Content Indirection ................................12
6.2. Multipart MIME with Content Indirection ...................12
7. Security Considerations ........................................13
8. Contributions ..................................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
The purpose of the Session Initiation Protocol [9] (SIP) is to create, modify, or terminate sessions with one or more participants. SIP messages, like HTTP, are syntactically composed of a start line, one or more headers, and an optional body. Unlike HTTP, SIP is not designed as a general-purpose data transport protocol.
セッション開始プロトコル[9]（SIP）の目的は、作成、変更、または1つ以上の参加者とのセッションを終了することです。 SIPメッセージは、HTTPのように、構文的に開始行、一の以上のヘッダ、および任意の本体で構成されています。 HTTPとは異なり、SIPは、汎用データ・トランスポート・プロトコルとして設計されていません。
There are numerous reasons why it might be desirable to specify the content of the SIP message body indirectly. For bandwidth-limited applications such as cellular wireless, indirection provides a means to annotate the (indirect) content with meta-data, which may be used by the recipient to determine whether or not to retrieve the content over a resource-limited link.
間接的にSIPメッセージボディの内容を指定することが望ましいかもしれない多数の理由があります。セルラ無線などの帯域幅が制限された用途のために、間接はリソースが限られたリンクを介してコンテンツを取得するか否かを判定するために受信者によって使用され得るメタデータと（間接的）コンテンツを注釈するための手段を提供します。
It is also possible that the content size to be transferred might overwhelm intermediate signaling proxies, thereby unnecessarily increasing network latency. For time-sensitive SIP applications, this may be unacceptable. Indirect content can remedy this by moving the transfer of this content out of the SIP signaling network and into a potentially separate data transfer channel.
転送されるコンテンツのサイズが、それによって不必要にネットワーク待ち時間を増加させる、中間シグナリングプロキシを圧倒する可能性があることも可能です。時間に敏感なSIPアプリケーションでは、これは受け入れられないかもしれません。間接的なコンテンツは、SIPシグナリングネットワークのうち、潜在的に別々のデータ転送チャネルにこのコンテンツの転送を移動することによってこの問題を解決することができます。
There may also be scenarios where the session-related data (body) that needs to be conveyed does not directly reside on the endpoint or User Agent. In such scenarios, it is desirable to have a mechanism whereby the SIP message can contain an indirect reference to the desired content. The receiving party would then use this indirect reference to retrieve the content via a non-SIP transfer channel such as HTTP, FTP, or LDAP.
また、搬送する必要がセッション関連データ（体が）直接エンドポイントまたはユーザエージェントに常駐していない状況があるかもしれません。そのようなシナリオでは、SIPメッセージが所望のコンテンツへの間接参照を含むことができる機構を有することが望ましいです。受信側は、その後、HTTP、FTP、またはLDAPなどの非SIP転送チャネルを介してコンテンツを取得するために、この間接参照を使用します。
The purpose of content indirection is purely to provide an alternative transport mechanism for SIP MIME body parts. With the exception of the transport mechanism, indirect body parts are equivalent to, and should have the same treatment as, in-line body parts.
コンテンツ間接の目的は、純粋にSIP MIMEボディ部分のための代替的なトランスポート機構を提供することです。搬送機構を除いて、間接的な身体の部分は、と等価であり、インラインボディ部分と同じ処理を有するべきです。
Previous attempts at solving the content indirection problem made use of the text/uri-list [6] MIME type. While attractive for its simplicity (a list of URIs delimited by end-of-line markers), it failed to satisfy a number of the requirements for a more general-purpose content indirection mechanism in SIP. Most notably lacking is the ability to specify various attributes on a per-URI basis. These attributes might include version information, the MIME type of the referenced content, etc.
uriテキスト/リストの使用[6] MIMEタイプ作られたコンテンツ間接問題を解決する以前の試み。その単純さ（エンドオブラインマーカーによって区切られたURIのリスト）のための魅力が、それはSIPでより汎用コンテンツ間接メカニズムの多くの要件を満たすことができませんでした。最も顕著な欠けあたり-URI毎にさまざまな属性を指定する機能です。これらの属性は、などのバージョン情報、参照されるコンテンツのMIMEタイプを、含まれる場合があります
RFC 2017 defines a strong candidate for a replacement for the text/uri-list MIME type. RFC 2017 [1] defines an extension to the message/external-body MIME type originally defined in RFC2046 [3]. The extension that RFC 2017 makes allows a generic URI to specify the location of the content rather than protocol-specific parameters for FTP, etc., as originally defined in RFC2046. Although it provides most of the functionality needed for a SIP content indirection mechanism, RFC 2017 by itself is not a complete solution. This document specifies the usage of RFC 2017 necessary to fulfill the requirements outlined for content indirection.
RFC 2017には、uriテキスト/リストMIMEタイプの交換のための強力な候補者を定義します。 RFC 2017 [1] [3]元々RFC2046で定義されたメッセージ/外部ボディMIMEタイプに拡張を定義します。 RFC 2017が行う拡張は本来RFC2046で定義されている一般的なURIは、等FTP、のためのプロトコル固有のパラメータではなく、コンテンツの場所を指定することを可能にします。それはSIPコンテンツ間接メカニズムのために必要な機能のほとんどを提供していますが、それだけでRFC 2017は、完全なソリューションではありません。この文書は、RFCコンテンツ間接について概説要件を満たすために必要な2017の使用方法を指定します。
The requirements can be classified as applying either to the URI, which indirectly references the desired content, or to the content itself. Where possible, existing MIME parameters and entity headers are used to satisfy those requirements. MIME (Content-Type) parameters are the preferred manner of describing the URI, while entity headers are the preferred manner of describing the (indirect) content. See RFC 2045 [2] for a description of most of these entity headers and MIME parameters.
要件は、間接的に所望のコンテンツを参照する、またはコンテンツ自体のURI、のいずれかを適用するように分類することができます。可能であれば、既存のMIMEパラメータとエンティティヘッダは、これらの要件を満たすために使用されています。エンティティヘッダは、（間接的）コンテンツを記述する好ましい方法であるがMIME（コンテンツタイプ）パラメータは、URIを記述するのに好ましい方法です。 [2]これらのエンティティのヘッダと、MIMEパラメータの大部分については、RFC 2045を参照。
RFC 2119 [5] defines the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
RFC 2119 [5]、 "REQUIRED"、、、、、OPTIONAL」、 "MAY" "推奨"、および "NOTべきである"、 "すべきである" "SHALL NOT" "ものと" "てはならない"、キーワード "MUST" を定義します」。
There are several examples of using the content indirection mechanism. These are examples only and are not intended to limit the scope or applicability of the mechanism.
コンテンツ間接メカニズムを使用してのいくつかの例があります。これらは単なる例であり、機構の範囲又は適用性を限定するものではありません。
The information carried in a presence document could exceed the recommended size for a SIP (NOTIFY) request, particularly if the document carries aggregated information from multiple endpoints. In such a situation, it would be desirable to send the NOTIFY request with an indirect pointer to the presence document, which could then be retrieved by, for example, HTTP.
プレゼンス文書で搬送される情報は、文書が複数のエンドポイントから集約された情報を搬送する場合は特に、SIP（NOTIFY）要求の推奨サイズを超える可能性があります。そのような状況では、次いで、例えば、HTTP、によって取得することができるプレゼンス文書への間接的なポインタでNOTIFY要求を送信することが望ましいです。
Watcher Presence Server
| |
| SUBSCRIBE |
|-------------------------->|
| 200 OK |
|<--------------------------|
| |
| NOTIFY |
|<--------------------------|
| 200 OK |
|-------------------------->|
| |
| NOTIFY (w/URI) |
|<--------------------------|
| 200 |
|-------------------------->|
| |
| HTTP GET |
|-------------------------->|
| |
| application/cpim-pidf+xml |
|<--------------------------|
| |
In this example, the presence server returns an HTTP URI pointing to a presence document on the presence server, which the watcher can then fetch by using an HTTP GET.
この例では、プレゼンスサーバは、ウォッチャーは、次に、HTTPのGETを使用して取得することができ、プレゼンスサーバにプレゼンス文書を指すHTTP URIを返します。
During an instant messaging conversation, a useful service is document sharing, wherein one party sends an IM (MESSAGE request) with an indirect pointer to a document that is meant to be rendered by the remote party. Carrying such a document directly in the MESSAGE request is not an appropriate use of the signaling channel. Furthermore, the document to be shared may reside on a completely independent server from that of the originating party.
インスタントメッセージング会話中に、便利なサービスは、一方の当事者が相手によってレンダリングされることを意図された文書への間接的なポインタでIM（MESSAGE要求）を送信し、前記ドキュメント共有です。 MESSAGE要求に直接そのような文書を搬送する信号チャネルの適切な使用ではありません。さらに、共有される文書は、発信側のものから完全に独立したサーバ上に存在してもよいです。
UAC UAS Web Server
(User Agent (User Agent |
Client) Server) |
| | |
| MESSAGE w/URI | |
|------------------->| |
| 200 | |
|<-------------------| |
| | |
| | HTTP GET |
| |--------------->|
| | image/jpeg |
| |<---------------|
| | |
In this example, a user UAC wishes to exchange a JPEG image that she has stored on her web server with user UAS with whom she has an IM conversation. She intends to render the JPEG inline in the IM conversation. The recipient of the MESSAGE request launches an HTTP GET request to the web server to retrieve the JPEG image.
この例では、ユーザーUACは、彼女は彼女がIMの会話を持っている誰とユーザーUASと彼女のウェブサーバーに保存されていることをJPEG画像を交換したいです。彼女は、IMの会話の中でJPEGをインラインでレンダリングする予定。 MESSAGEリクエストの受信者は、JPEG画像を取得するために、WebサーバーへのHTTP GETリクエストを起動します。
o It MUST be possible to specify the location of content via a URI. Such URIs MUST conform with RFC2396 [7].
O URIを介してコンテンツの場所を指定することができなければなりません。そのようなURIは、RFC2396に準拠しなければならない[7]。
o It MUST be possible to specify the length of the indirect content.
O間接的なコンテンツの長さを指定することが可能でなければなりません。
o It MUST be possible to specify the type of the indirect content.
O間接的なコンテンツの種類を指定することが可能でなければなりません。
o It MUST be possible to specify the disposition of each URI independently.
O独立して、各URIの配置を指定することが可能でなければなりません。
o It MUST be possible to label each URI to identify if and when the content referred to by that URI has changed. Applications of this mechanism may send the same URI more than once. The intention of this requirement is to allow the receiving party to determine whether the content referenced by the URI has changed, without having to retrieve that content. Examples of ways the URI could be labeled include a sequence number, timestamp, and version number. When used with HTTP, the entity-tag (ETAG) mechanism, as defined in RFC2068 [4], may be appropriate. Note that we are labeling not the URI itself but the content to which the URI refers, and that the label is therefore effectively "metadata" of the content itself.
OそのURIによって参照されるコンテンツが変更された場合とするときを識別するために各URIを標識することができなければなりません。このメカニズムのアプリケーションでは、複数回同じURIを送信することができます。この要件の意図は、そのコンテンツを取得することなく、受信者はURIで参照されるコンテンツが変更されているかどうかを判断できるようにすることです。 URIを標識することができる方法の例には、シーケンス番号、タイムスタンプ、およびバージョン番号を含みます。 HTTPで使用される場合、RFC2068 [4]で定義されたエンティティタグ（ETAG）機構は、適切であり得ます。私たちはURIそのものではなく、URIが参照する内容ではないラベリング、およびラベルは、したがって、コンテンツ自体の効果「メタデータ」であるとされていることに注意してください。
o It MUST be possible to specify the time span for which a given URI is valid. This may or may not be the same as the lifetime for the content itself.
O与えられたURIが有効な期間を指定することが可能でなければなりません。これは、コンテンツ自体の寿命と同じであってもなくてもよいです。
o It MUST be possible for the UAC and the UAS to indicate support of this content indirection mechanism. A fallback mechanism SHOULD be specified in the event that one of the parties is unable to support content indirection.
UACとUASがこのコンテンツ間接メカニズムのサポートを示すためにのためにOことが可能でなければなりません。フォールバックメカニズムは、当事者の一方が、コンテンツ間接をサポートすることができない場合に指定する必要があります。
o It MUST be possible for the UAC and UAS to negotiate the type of the indirect content when using the content indirection mechanism.
コンテンツ間接メカニズムを使用する場合、UACとUASが間接コンテンツのタイプを交渉するためのOことが可能でなければなりません。
o It MUST be possible for the UAC and UAS to negotiate support for any URI scheme to be used in the content indirection mechanism. This is in addition to the ability to negotiate the content type.
UACとUASは、コンテンツ間接メカニズムで使用される任意のURIスキームのサポートを交渉するためのOことが可能でなければなりません。これは、コンテンツタイプを交渉する能力に加えています。
o It SHOULD be possible to ensure the integrity and confidentiality of the URI when it is received by the remote party.
Oそれは相手によって受信されたときにURIの完全性と機密性を確保することが可能です。
o It MUST be possible to process the content indirection without human intervention.
O人間の介入なしにコンテンツの間接化を処理することが可能でなければなりません。
o It MUST allow for indirect transference of content in any SIP message that would otherwise carry that content as a body.
Oそれ以外体としてそのコンテンツを運ぶ任意のSIPメッセージのコンテンツの間接的な転移を可能にしなければなりません。
The following text describes the application of RFC 2017 to the requirements for content indirection.
次のテキストは、コンテンツ間接の要件へのRFC 2017のアプリケーションを記述しています。
A UAC/UAS indicates support for content indirection by including the message/external-body MIME type in the Accept header. The UAC/UAS MAY supply additional values in the Accept header to indicate the content types that it is willing to accept, either directly or through content indirection. User-Agents supporting content indirection MUST support content indirection of the application/sdp MIME type.
UAC / UASは、Acceptヘッダー内のメッセージ/外部ボディMIMEタイプを含めることによって、コンテンツ間接のサポートを示しています。 UAC / UASは、直接または間接コンテンツを通して、受け入れても構わないと思っているコンテンツの種類を示すために、Acceptヘッダーに追加の値を供給することができます。コンテンツ間接をサポートするユーザーエージェントは、アプリケーション/ SDP MIMEタイプのコンテンツ間接をサポートしなければなりません。
For example:
例えば：
Accept: message/external-body, image/*, application/sdp
Applications that use this content indirection mechanism MUST support the HTTP URI scheme. Additional URI schemes MAY be used, but a UAC/UAS MUST support receiving a HTTP URI for indirect content if it advertises support for content indirection.
このコンテンツ間接メカニズムを使用するアプリケーションは、HTTP URIスキームをサポートしなければなりません。追加のURIスキームを使用することができるが、それはコンテンツ間接のサポートをアドバタイズ場合UAC / UASは、間接的なコンテンツのためのHTTP URIを受けてサポートしなければなりません。
The UAS MAY advertise alternate access schemes in the schemes parameter of the Contact header in the UAS response to the UAC's session establishment request (e.g., INVITE, SUBSCRIBE), as described in RFC 3840 [11].
UASは、RFC 3840 [11]に記載されているように、（例えば、INVITE SUBSCRIBE）UACのセッション確立要求にUAS応答のContactヘッダのスキームパラメータで代替アクセス方式を広告するかもしれません。
If a UAS receives a SIP request that contains a content indirection payload and the UAS cannot or does not wish to support such a content type, it MUST reject the request with a 415 Unsupported Media Type response as defined in section 21.4.13 of SIP [9]. In particular, the UAC should note the absence of the message/external-body MIME type in the Accept header of this response to indicate that the UAS does not support content indirection, or the absence of the particular MIME type of the requested comment to indicate that the UAS does not support the particular media type.
UASは、コンテンツ間接ペイロードを含むSIP要求を受信し、UASができない、またはそのようなコンテンツタイプをサポートすることを望まないSIPのセクション21.4.13に定義されているように、[415サポートされていないメディアタイプ応答で要求を拒絶しなければならない場合9]。具体的には、UACがUASを示すために、コンテンツ間接、又は要求されたコメントの特定のMIMEタイプが存在しないことをサポートしていないことを示すために、この応答の受け入れヘッダ内のメッセージ/外部ボディMIMEタイプが存在しないことを注意してくださいUASは、特定のメディアタイプをサポートしていないこと。
The URI for the indirect content is specified in a "URI" parameter of the message/external-body MIME type. An access-type parameter indicates that the external content is referenced by a URI. HTTP URI specifications MUST conform to RFC 2396 [7].
間接的なコンテンツのURIは、メッセージ/外部ボディMIME型の「URI」パラメータで指定されています。アクセス型のパラメータは、外部コンテンツはURIによって参照されることを示しています。 HTTP URIの仕様はRFC 2396に準拠しなければならない[7]。
For example:
例えば：
Content-Type: message/external-body; access-type="URL";
URL="http://www.example.com/the-indirect-content"
Some content is not critical to the context of the communication if there is a fetch or conversion failure. The content indirection mechanism uses the Critical-Content mechanism described in RFC 3459 [10]. In particular, if the UAS is unable to fetch or render an optional body part, then the server MUST NOT return an error to the UAC.
フェッチまたは変換障害が発生した場合、一部のコンテンツは、通信の状況には重要ではありません。コンテンツ間接メカニズムは、RFC 3459 [10]に記載のクリティカル・コンテンツメカニズムを使用します。 UASは、オプションの身体の一部を取得またはレンダリングすることができない場合は特に、サーバはUACにエラーを返してはなりません。
In order to determine whether the content indirectly referenced by the URI has changed, a Content-ID entity header is used. The syntax of this header is defined in RFC 2045 [2]. Changes in the underlying content referred to by a URI MUST result in a change in the Content-ID associated with that URI. Multiple SIP messages carrying URIs that refer to the same content SHOULD reuse the same Content-ID, to allow the receiver to cache this content and to avoid unnecessary retrievals. The Content-ID is intended to be globally unique and SHOULD be temporally unique across SIP dialogs.
間接的URIによって参照されるコンテンツが変更されたかどうかを決定するためには、Content-IDエンティティヘッダが使用されます。このヘッダの構文は、RFC 2045で定義されている[2]。 URIで参照される基本的な内容の変更は、そのURIに関連付けられているのContent-IDの変化をもたらさなければなりません。同じコンテンツを参照するURIを運ぶ複数のSIPメッセージは、受信者がこのコンテンツをキャッシュするために、不要な回収のを避けることができるように、同じコンテンツIDを再利用する必要があります。コンテンツIDは、グローバルに一意であること、およびSIPダイアログ全体で一時的にユニークであるべきことを意図しています。
For example:
例えば：
Content-ID: <4232423424@www.example.com>
コンテンツID：<4232423424@www.example.com>
The URI supplied by the Content-Type header is not required to be accessible or valid for an indefinite period of time. Rather, the supplier of the URI MUST specify the time period for which this URI is valid and accessible. This is done through an "EXPIRATION" parameter of the Content-Type. The format of this expiration parameter is an RFC 1123 [12] date-time value. This is further restricted in this application to use only GMT time, consistent with the Date: header in SIP. This is a mandatory parameter. Note that the date-time value can range from minutes to days or even years.
Content-Typeヘッダによって供給されたURIは、無期限にアクセスまたは有効である必要はありません。むしろ、URIのサプライヤーは、このURIが有効でアクセスされる期間を指定しなければなりません。これは、Content-Typeでの「EXPIRATION」パラメータを介して行われます。この有効期限パラメータのフォーマットは、RFC 1123 [12]日時値です。 SIPのヘッダー：これは、さらに日付と一致のみGMT時間を、使用するには、このアプリケーションに制限されています。これは必須パラメータです。日時の値は、数分から数日あるいは数年に及ぶことができることに注意してください。
For example:
例えば：
Content-Type: message/external-body;
expiration="Mon, 24 June 2002 09:00:00 GMT"
To support existing SIP mechanisms for the negotiation of content types, a Content-Type entity header SHOULD be present in the entity (payload) itself. If the protocol (scheme) of the URI supports its own content negotiation mechanisms (e.g., HTTP), this header may be omitted. The sender MUST, however, be prepared for the receiving party to reject content indirection if the receiver is unable to negotiate an appropriate MIME type by using the underlying protocol for the URI scheme.
コンテンツタイプのネゴシエーションのための既存のSIPメカニズムをサポートするために、Content-Typeのエンティティヘッダは、エンティティ（ペイロード）自体で存在すべきです。 URIのプロトコル（スキーム）は、自身のコンテンツネゴシエーションメカニズム（例えば、HTTP）をサポートしている場合は、このヘッダを省略してもよいです。送信者は、しかしながら、受信機は、URIスキームの基礎となるプロトコルを使用して、適切なMIMEタイプをネゴシエートすることができない場合、コンテンツ間接参照を拒否するように受信側のために準備されなければなりません。
For example:
例えば：
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content"
<CRLF>
Content-Type: application/sdp
Content-Disposition: session
<CRLF>
When known in advance, the size of the indirect content in bytes SHOULD be supplied via a size parameter on the Content-Type header. This is an extension of RFC 2017 but is in line with other access types defined for the message/external-body MIME type in RFC 2046. The content size is useful for the receiving party to make a determination about whether to retrieve the content. As with directly supplied content, a UAS may return a 513 error response in the event that the content size is too large. Size is an optional parameter.
事前に知られている場合、バイト単位で間接コンテンツのサイズは、Content-Typeヘッダにサイズパラメータを介して供給されるべきです。これは、RFC 2017の拡張であるが、コンテンツのサイズが受信者がコンテンツを取得するかどうかについての決意をするために有用であるRFC 2046にメッセージ/外部ボディMIMEタイプ用に定義された他のアクセスタイプと一致しています。直接供給されるコンテンツと同様に、UASは、コンテンツのサイズが大きすぎるた場合に513エラー応答を返すことができます。サイズはオプションのパラメータです。
For example:
例えば：
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content";
size=4123
A Content-Disposition entity header MUST be present for all indirect content.
コンテンツの廃棄エンティティヘッダは、全ての間接コンテンツのために存在していなければなりません。
For example:
例えば：
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content"
<CRLF>
Content-Type: image/jpeg
Content-Disposition: render
If there is a need to send multiple URIs for content indirection, an appropriate multipart MIME type [3] should be used. Each URI MUST be contained in a single entity. Indirect content may be mixed with directly-supplied content. This is particularly useful with the multipart/alternative MIME type.
コンテンツ間接ために複数のURIを送信する必要がある場合は、[3]適切なマルチパートMIMEタイプが使用されるべきです。各URIは、単一のエンティティに含まれなければなりません。間接的なコンテンツが直接供給されたコンテンツと混合してもよいです。これは、マルチパート/代替MIMEタイプと特に便利です。
NOTE: This specification does not change the meanings of the various multipart flavors, particularly multipart/related, as described in RFC 2387 [13].
注：RFC 2387 [13]に記載されているように、この明細書は、特にマルチ様々なマルチフレーバー、/関連の意味を変更しません。
For example:
例えば：
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary42
--boundary42 Content-Type: text/plain; charset=us-ascii
--boundary42のContent-Type：text / plainの。文字セット= US-ASCII
The company announcement for June, 2002 follows:
--boundary42
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/announcements/07242002";
size=4123
Content-Type: text/html Content-Disposition: render
コンテンツタイプ：text / htmlのコンテンツディスポジション：レンダリング
--boundary42--
--boundary42--
If the sender knows the specific content being referenced by the indirection, and if the sender wishes the recipient to be able to validate that this content has not been altered from that intended by the sender, the sender includes a SHA-1 [8] hash of the content. If it is included, the hash is encoded by extending the MIME syntax [3] to include a "hash" parameter for the content type "message/ external-body", whose value is a hexadecimal encoding of the hash.
送信者は、間接によって参照されている特定のコンテンツを知っており、送信者は受信者がこのコンテンツは、送信者が意図したものから変更されていないことを確認できるようにしたい場合、送信者は、SHA-1 [8]ハッシュが含まれている場合コンテンツの。それが含まれている場合、ハッシュは、MIME構文[3]の値ハッシュの進符号化されたコンテンツタイプ「メッセージ/外部ボディ」は、「ハッシュ」パラメータを含むように拡張することによって符号化されます。
For example:
例えば：
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content.au";
size=52723;
hash=10AB568E91245681AC1B
<CRLF>
Content-Disposition: render
One MAY use the Content-Description entity header to provide optional, freeform text to comment on the indirect content. This text MAY be displayed to the end user but MUST NOT used by other elements to determine the disposition of the body.
一つは、間接的なコンテンツにコメントするには、オプションの、自由形式のテキストを提供するために、コンテンツ記述エンティティヘッダを使用するかもしれません。このテキストは、エンドユーザーに表示されるかもしれないが、身体の処分を決定するために他の要素が使用してはなりません。
For example:
例えば：
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content";
size=52723
<CRLF>
Content-Description: Multicast gaming session
Content-Disposition: render
SIP [9] defines three headers that supply additional information with regard to a session, a particular error response, or alerting. All three of these headers allow the UAC or UAS to indicate additional information through a URI. They may be considered a form of content indirection. The content indirection mechanism defined in this document is not intended as a replacement for these headers. Rather, the headers defined in SIP MUST be used in preference to this mechanism, where applicable, because of the well-defined semantics of those headers.
[9] SIPセッション、特定のエラー応答、または警告に関する追加情報を提供する3つのヘッダを定義します。これらのヘッダのすべての3つは、UACまたはUASはURIによって追加の情報を示すことができます。彼らは、コンテンツ間接の形と考えることができます。この文書で定義されたコンテンツ間接メカニズムは、これらのヘッダの代替として意図されていません。むしろ、SIPで定義されたヘッダーがあるため、これらのヘッダの明確に定義されたセマンティクスを、適用可能な場合、このメカニズムに優先して使用されなければなりません。
INVITE sip:boromir@example.com SIP/2.0
From: <sip:gandalf@example.net>;tag=347242
To: <sip:boromir@example.com>
Call-ID: 3573853342923422@example.net
CSeq: 2131 INVITE
Accept: message/external-body application/sdp
Content-Type: message/external-body;
ACCESS-TYPE=URL;
URL="http://www.example.net/party/06/2002/announcement";
EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT";
size=231
Content-Length: 105
Content-Type: application/sdp Content-Disposition: session Content-ID: <4e5562cd1214427d@example.net>
コンテンツタイプ：アプリケーション/ SDPコンテンツディスポジション：セッションのContent-ID：<4e5562cd1214427d@example.net>
MESSAGE sip:boromir@example.com SIP/2.0
From: <sip:gandalf@example.net>;tag=34589882
To: <sip:boromir@example.com>
Call-ID: 9242892442211117@example.net
CSeq: 388 MESSAGE
Accept: message/external-body, text/html, text/plain,
image/*, text/x-emoticon
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=zz993453
--zz993453
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.net/company_picnic/image1.png";
size=234422
Content-Type: image/png Content-ID: <9535035333@example.net> Content-Disposition: render Content-Description: Kevin getting dunked in the wading pool
コンテンツタイプ：画像/ PNG形式のContent-ID：<9535035333@example.net>コンテンツ-処分：コンテンツの説明をレンダリング：ケビンは、子供用プールでdunked取得
--zz993453
--Zzsassa 453
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.net/company_picnic/image2.png";
size=233811
Content-Type: image/png Content-ID: <1134299224244@example.net> Content-Disposition: render Content-Description: Peter on his tricycle
コンテンツタイプ：画像/ PNG形式のContent-ID：<1134299224244@example.net>コンテンツ-処分：コンテンツの説明をレンダリング：ピーター彼の三輪車に
--zz993453--
--Zzsassa453--
Any content indirection mechanism introduces additional security concerns. By its nature, content indirection requires an extra processing step and information transfer. There are a number of potential abuses of a content indirection mechanism:
任意のコンテンツ間接メカニズムは、追加のセキュリティ上の問題を紹介します。その性質上、コンテンツの間接は、余分な処理ステップと情報伝達が必要です。コンテンツ間接メカニズムの潜在的な虐待の数があります。
o Content indirection allows the initiator to choose an alternative protocol with weaker security or known vulnerabilities for the content transfer (for example, asking the recipient to issue an HTTP request that results in a Basic authentication challenge).
O含有量間接は、イニシエータが弱いセキュリティやコンテンツ転送のための既知の脆弱性（例えば、基本認証チャレンジになりHTTPリクエストを発行するために、受信者を求めて）で代替プロトコルを選択することができます。
o Content indirection allows the initiator to ask the recipient to consume additional resources in the information transfer and content processing, potentially creating an avenue for denial-of-service attacks (for example, an active FTP URL consuming 2 connections for every indirect content message).
O含有量間接は、イニシエータが、潜在的にサービス拒否攻撃のために道を作る、情報伝達およびコンテンツ処理中に追加のリソースを消費するため、受信者に依頼することができます（例えば、すべての間接的な内容のメッセージのための2つの接続を消費するアクティブなFTP URL） 。
o Content indirection could be used as a form of port-scanning attack where the indirect content URL is actually a bogus URL pointing to an internal resource of the recipient. The response to the content indirection request could reveal information about open (and vulnerable) ports on these internal resources.
O含有量間接の間接的なコンテンツURLが実際に受信者の内部リソースを指す偽のURLでポートスキャン攻撃の形として使用することができます。コンテンツ間接要求に対する応答は、これらの内部リソースにオープン（脆弱な）ポートに関する情報を明らかにすることができました。
o A content indirection URL can disclose sensitive information about the initiator such as an internal user name (as part of an HTTP URL) or possibly geolocation information.
Oコンテンツ間接URLは、または場合によっては地理位置情報（HTTP URLの一部として）内部ユーザ名としてイニシエータに関する機密情報を開示することができます。
Fortunately, all of these potential threats can be mitigated through careful screening of both the indirect content URIs that are received and those that are sent. Integrity and confidentiality protection of the indirect content URI can prevent additional attacks as well.
幸いなことに、これらの潜在的な脅威のすべてが受信され、送信されているものをしている間接的なコンテンツのURIの両方の慎重なスクリーニングによって緩和することができます。間接的なコンテンツURIの完全性と機密性の保護だけでなく、追加の攻撃を防ぐことができます。
For confidentiality, integrity, and authentication, this content indirection mechanism relies on the security mechanisms outlined in
機密性、完全性、および認証の場合、このコンテンツ間接メカニズムはで概説したセキュリティ・メカニズムに依存しています
RFC 3261. In particular, the usage of S/MIME as defined in section 23 of RFC 3261 provides the necessary mechanism to ensure integrity, protection, and confidentiality of the indirect content URI and associated parameters.
特に、RFC 3261、RFC 3261のセクション23で定義されるようにS / MIMEの使用は、完全性保護、及び間接的なコンテンツURIと関連するパラメータの機密性を確保するために必要な機構を提供します。
Securing the transfer of the indirect content is the responsibility of the underlying protocol used for this transfer. If HTTP is used, applications implementing this content indirection method SHOULD support the HTTPS URI scheme for secure transfer of content and MUST support the upgrading of connections to TLS, by using starttls. Note that a failure to complete HTTPS or starttls (for example, due to certificate or encryption mismatch) after having accepted the indirect content in the SIP request is not the same as rejecting the SIP request, and it may require additional user-user communication for correction.
間接的なコンテンツの転送を確保することは、この転送に使用される基本的なプロトコルの責任です。 HTTPが使用される場合、このコンテンツ間接方法を実施するアプリケーションは、コンテンツを安全に転送するためのHTTPS URIスキームをサポートする必要があり、STARTTLSを使用して、TLSへの接続のアップグレードをサポートしなければなりません。 SIP要求における間接コンテンツを受け入れた後（これは、証明書や暗号化の不一致例えば、）HTTPSを完了する障害またはSTARTTLSは、SIP要求を拒否と同じではない、それはのための追加のユーザ・ユーザの通信を必要とするかもしれないことに注意してください補正。
Note that this document does not advocate the use of transitive trust. That is, just because the UAS receives a URI from a UAC that the UAS trusts, the UAS SHOULD NOT implicitly trust the object referred to by the URI without establishing its own trust relationship with the URI provider.
この文書は推移的な信頼を使用することを提唱していないことに注意してください。それはUASがUAS信託は、UASが暗黙的URIプロバイダと自身の信頼関係を確立することなくURIによって参照されるオブジェクトを信頼してはならないことUACからURIを受け取るという理由だけで、です。
Access control to the content referenced by the URI is not defined by this specification. Access control mechanisms may be defined by the protocol for the scheme of the indirect content URI.
URIによって参照されるコンテンツへのアクセス制御は、この仕様で定義されていません。アクセス制御メカニズムは、間接コンテンツURIのスキームのためのプロトコルによって定義してもよいです。
If the UAC knows the content in advance, the UAC SHOULD include a hash parameter in the content indirection. The hash parameter is a hexadecimal-encoded SHA-1 [8] hash of the indirect content. If a hash value is included, the recipient MUST check the indirect content against that hash and indicate any mismatch to the user.
UACは、事前に内容を知っている場合、UACは、コンテンツ・間接にハッシュパラメータを含めるべきです。ハッシュパラメータは間接的コンテンツの16進符号化されたSHA-1 [8]ハッシュです。ハッシュ値が含まれている場合、受信者はそのハッシュに対する間接的な内容を確認し、利用者への任意の不一致を示す必要があります。
In addition, if the hash parameter is included and the target URI involves setting up a security context using certificates, the UAS MUST ignore the results of the certificate validation procedure, and instead verify that the hash of the (canonicalized) content received matches the hash presented in the content-indirection hash parameter.
また、ハッシュパラメータが含まれていれば、ターゲットURIは、証明書を使用してセキュリティコンテキストを設定することを含む、UASは、証明書検証手順の結果を無視し、その代わりに（正規化）コンテンツのハッシュがハッシュに一致する受信したことを確認しなければなりませんコンテンツ・間接のハッシュパラメータで提示。
If the hash parameter is NOT included, the sender SHOULD use only schemes that offer message integrity (such as https:). When the hash parameter is not included and security using certificates is used, the UAS MUST verify any server certificates, by using the UAS's list of trusted top-level certificate authorities.
ハッシュパラメータが含まれていない場合、送信者はHTTPSなどのメッセージの整合性を提供するだけのスキームを（:)使用すべきです。ハッシュパラメータが含まれていないと証明書を使用してセキュリティを使用する場合、UASは信頼され、最上位の認証局のUASのリストを使用して、任意のサーバ証明書を確かめなければなりません。
If hashing of indirect content is not used, the content returned to the recipient by exercise of the indirection might have been altered from that intended by the sender.
間接的な内容のハッシュを使用しない場合、コンテンツは間接の行使により受信者に返され、送信者が意図したものから変更された可能性があります。
Sean Olson, seanol@microsoft.com, provided the vast majority of the content of this document, including editorship through the first IESG review. Dean Willis touched it next.
ショーン・オルソン、seanol@microsoft.comは、最初のIESGの見直しによる監修を含め、本文書の内容の大半を提供します。ディーン・ウィリスは、次のことに触れました。
Eric Burger edited the document and addressed IESG comments, including the access protocol negotiation mechanism.
エリック・バーガーは、文書を編集し、アクセスプロトコルのネゴシエーションメカニズムを含め、IESGのコメントを取り上げました。
Cullen Jennings and Nancy Greene provided a through review and valuable comments and suggestions.
カレン・ジェニングスとナンシー・グリーンは、レビューと貴重なコメントや提案を通じて提供しました。
[1] Freed, N. and K. Moore, "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996.
[1]フリード、N.とK.ムーア、 "URL MIME外部-ボディアクセスタイプの定義"、RFC 2017、1996年10月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[2]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[4]フィールディング、R.、ゲティス、J.、モーグル、J.、ニールセン、H.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[6]ダニエル、R.、RFC 2169、1997年6月、 "URNの解決にHTTPを使用するための些細な条約"。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[8]イーストレイク、D.とP.ジョーンズは、RFC 3174、2001年9月、 "米国は、ハッシュアルゴリズム1（SHA1）を固定します"。
[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[9]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[10] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[10]バーガー、E.、 "重要なコンテンツ多目的インターネットメール拡張（MIME）パラメータ"、RFC 3459、2003年1月。
[11] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[11]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[12] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[12]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[13] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[13]レビンソン、E.、 "MIMEマルチパート/関連コンテンツ・タイプ"、RFC 2387、1998年8月。
Author's Address
著者のアドレス
Eric Burger (editor) Cantata Technolgy, Inc.
エリック・バーガー（編集者）カンタータ・テクノロジー株式会社
EMail: eburger@cantata.com URI: http://www.cantata.com
電子メール：eburger@cantata.com URI：http://www.cantata.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。