[要約] RFC 4483は、SIPメッセージ内のコンテンツ間接参照のためのメカニズムを提供するものであり、SIPプロトコルの拡張を目的としています。
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
セッション開始プロトコル（SIP）メッセージにおけるコンテンツ間接のメカニズム
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、URL MIME外部ボディアクセスタイプの拡張機能を定義して、セッション開始プロトコル（SIP）のコンテンツの間接要件を満たします。これらの拡張機能は、SIPメッセージのMIMEパーツをURIを介して間接的に参照できるようにすることを目的としています。
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人以上の参加者とセッションを作成、変更、または終了することです。HTTPのようなSIPメッセージは、スタートライン、1つ以上のヘッダー、およびオプションの本体で構成的に構成されています。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メッセージ本体のコンテンツを間接的に指定することが望ましい理由はたくさんあります。Cellular Wirelessなどの帯域幅が制限されたアプリケーションの場合、間接は（間接的な）コンテンツにMeta-Dataに注釈を付ける手段を提供します。これは、リソース制限リンクを介してコンテンツを取得するかどうかを判断するためにレシピエントが使用できます。
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タイプが使用されました。そのシンプルさ（末端マーカーによって区切られたURISのリスト）にとって魅力的ですが、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]は、RFC2046 [3]で最初に定義されたメッセージ/外部ボディMIMEタイプの拡張を定義しています。RFC 2017が作成する拡張機能により、Generic URIは、RFC2046で最初に定義されているように、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を記述する優先的な方法であり、エンティティヘッダーは（間接的な）コンテンツを記述する優先的な方法です。これらのエンティティヘッダーのほとんどとMIMEパラメーターのほとんどの説明については、RFC 2045 [2]を参照してください。
RFC 2119 [5] defines the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
RFC 2119 [5]は、キーワードを「必須」、「必須」、「必須」、「しなければ」、「そうでない」、「はない」、「推奨」、「5月」、「オプション」を定義します。「。
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サーバー上のプレゼンスドキュメントを指すHTTP URIを返します。これは、HTTP GETを使用してWatcherが取得できます。
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.
インスタントメッセージングの会話の間、有用なサービスはドキュメント共有であり、1つの当事者は、リモートパーティによってレンダリングされることを意図したドキュメントへの間接的なポインターを備えたIM（メッセージ要求）を送信します。このようなドキュメントをメッセージ要求に直接持ち込むことは、信号チャネルの適切な使用ではありません。さらに、共有されるドキュメントは、発信者の当事者のサーバーから完全に独立したサーバーに存在する場合があります。
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の会話をしているユーザーUAとWebサーバーに保存したJPEG画像を交換したいと考えています。彼女はIMの会話でJPEGをインラインでレンダリングするつもりです。メッセージリクエストの受信者は、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.
o UACとUASがこのコンテンツの間接メカニズムのサポートを示すことが可能でなければなりません。当事者の1つがコンテンツの間接をサポートできない場合、フォールバックメカニズムを指定する必要があります。
o It MUST be possible for the UAC and UAS to negotiate the type of the indirect content when using the content indirection mechanism.
o コンテンツ間接メカニズムを使用する場合、UACとUASが間接コンテンツのタイプをネゴシエートすることが可能である必要があります。
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.
o UACとUASが、コンテンツの間接メカニズムで使用されるURIスキームのサポートを交渉することが可能である必要があります。これは、コンテンツタイプをネゴシエートする機能に追加されます。
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は、受け入れヘッダーにメッセージ/外部ボディ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]に記載されているように、UACのセッション確立リクエスト（例：招待、購読）に対するUAS応答のコンタクトヘッダーのスキームパラメーターの代替アクセススキームを宣伝する場合があります。
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は、この応答の受け入れヘッダーにメッセージ/外部ボディ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によって間接的に参照されるコンテンツが変更されたかどうかを判断するために、コンテンツIDエンティティヘッダーが使用されます。このヘッダーの構文は、RFC 2045 [2]で定義されています。URIによって言及されている基礎となるコンテンツの変更は、そのURIに関連するコンテンツIDの変更をもたらす必要があります。同じコンテンツを参照するURIを運ぶ複数のSIPメッセージは、同じコンテンツIDを再利用して、受信者がこのコンテンツをキャッシュし、不必要な検索を避けるために、同じコンテンツIDを再利用する必要があります。Content-IDはグローバルにユニークであることを目的としており、SIPダイアログ全体で一時的に一意である必要があります。
For example:
例えば：
Content-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.
コンテンツタイプのヘッダーが提供するURIは、無期限にアクセスできるか有効にする必要はありません。むしろ、URIのサプライヤーは、このURIが有効でアクセス可能な期間を指定する必要があります。これは、コンテンツタイプの「有効期限」パラメーターによって行われます。この有効期限パラメーターの形式は、RFC 1123 [12]日付時間値です。これは、このアプリケーションでさらに制限され、GMT時間のみを使用して、SIPのヘッダーと一致しています。これは必須パラメーターです。日付の値は数分から数日、あるいは数年の範囲であることに注意してください。
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メカニズムをサポートするには、コンテンツタイプのエンティティヘッダーがエンティティ（ペイロード）自体に存在する必要があります。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.
事前に知られている場合、バイト内の間接コンテンツのサイズは、コンテンツタイプのヘッダーのサイズパラメーターを介して提供する必要があります。これは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を送信する必要がある場合は、適切なマルチパートMIMEタイプ[3]を使用する必要があります。各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
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
--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.
SIP [9]は、セッションに関する追加情報、特定のエラー応答、またはアラートに関する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>
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
--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/image2.png";
size=233811
Content-Type: image/png
Content-ID: <1134299224244@example.net>
Content-Disposition: render
Content-Description: Peter on his tricycle
--zz993453--
-zz993453---
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を使用する場合、このコンテンツ間接メソッドを実装するアプリケーションは、StartTLSを使用して、コンテンツの安全な転送のためにHTTPS URIスキームをサポートし、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が信頼するUACからURIを受け取ったからといって、UASはURIプロバイダーとの独自の信頼関係を確立せずに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は証明書検証手順の結果を無視し、代わりに受信した（正規化された）コンテンツのハッシュがハッシュと一致することを確認する必要があります。Content-Indirection Hashパラメーターで表示されます。
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.
Sean Olson、seanol@microsoft.comは、最初のIESGレビューによる編集を含む、このドキュメントのコンテンツの大部分を提供しました。ディーン・ウィリスは次にそれに触れました。
Eric Burger edited the document and addressed IESG comments, including the access protocol negotiation mechanism.
Eric Burgerはドキュメントを編集し、アクセスプロトコルネゴシエーションメカニズムを含む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] Freed、N。およびK. Moore、「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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3] Freed、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] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[6] Daniel、R。、「urn解像度でHTTPを使用するための些細な条約」、RFC 2169、1997年6月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[8] Eastlake、D。and P. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[10] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[10] Burger、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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[12] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[12] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[13] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[13] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、1998年8月。
Author's Address
著者の連絡先
Eric Burger (editor) Cantata Technolgy, Inc.
Eric Burger（編集者）Cantata Technolgy、Inc。
EMail: eburger@cantata.com
URI: http://www.cantata.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。