RFC4483 日本語訳
4483 A Mechanism for Content Indirection in Session InitiationProtocol (SIP) Messages. E. Burger, Ed.. May 2006. (Format: TXT=36794 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Burger, Ed. Request for Comments: 4483 Cantata Technolgy, Inc. Category: Standards Track May 2006
エド、ワーキンググループE.バーガーをネットワークでつないでください。コメントのために以下を要求してください。 4483年のカンタータTechnolgy Inc.カテゴリ: 標準化過程2006年5月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントは、Session Initiationプロトコル(SIP)のための満足している間接指定要件を満たすためにURL MIME External-ボディーAccess-タイプと拡大を定義します。 これらの拡大は間接的に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
1. 序論…2 2. 用語…3 3. 事例を使用してください…3 3.1. 存在通知…4 3.2. 共有を記録してください…4 4. 要件…5 5. 満足している間接指定問題へのRFC2017のアプリケーション…6 5.1. 満足している間接指定のサポートを指定します…6 5.2. HTTP URIの義務的なサポート…7 5.3. 満足している間接指定を拒絶します…7 5.4. URIでContentのLocationを指定します…7 5.5. 間接的な内容が任意であるとマークします…7 5.6. URIのためのVersioning情報を指定します…8 5.7. URI生涯を指定します…8 5.8. Indirect Contentのタイプを指定します…8 5.9. 間接的な内容のサイズを指定します…9 5.10. 間接的な内容の目的を指定します…9 5.11. 満足している間接指定に複数のURIを指定します…10
Burger Standards Track [Page 1] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[1ページ]。
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
5.12. 間接的な内容にハッシュ値を指定します…10 5.13. 間接的な内容に関して追加コメントを供給します…11 5.14. 呼び出しインフォメーションとの関係、誤りインフォメーション、および注意深いインフォメーションヘッダー…11 6. 例…12 6.1. ただ一つの満足している間接指定…12 6.2. 満足している間接指定がある複合MIME…12 7. セキュリティ問題…13 8. 貢献…15 9. 承認…15 10. 参照…15 10.1. 標準の参照…15 10.2. 有益な参照…16
1. Introduction
1. 序論
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.
Session Initiationプロトコル[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メッセージボディーの内容を指定するのが望ましいかもしれない多数の理由があります。 セルワイヤレスなどの帯域幅で限られたアプリケーションのために、間接指定はリソースで限られたリンクの上に内容を検索するかどうか決定するのに受取人によって使用されるかもしれないメタデータで(間接的)の内容を注釈する手段を提供します。
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.
また、シナリオが運ばれる必要があるセッション関連のデータ(ボディー)が終点かUserエージェントの上に直接ないところにあるかもしれません。 そのようなシナリオでは、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
満足している間接指定の目的は純粋にSIP MIME身体の部分への代替の移送機構を提供することです。 移送機構を除いて、間接的な身体の部分はそうです。
Burger Standards Track [Page 2] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[2ページ]。
equivalent to, and should have the same treatment as, in-line body parts.
相当する、同じ処理を持つべきである、インライン身体の部分。
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の目的の、より一般的な内容間接指定メカニズムのための多くの要件を満たしませんでした。 最も著しく欠けるのは1URIあたり1個のベースで様々な属性を指定する能力です。 これらの属性はバージョン情報、参照をつけられた内容の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.
RFC2017はuriテキスト/リストMIMEの種類との交換の有力な候補を定義します。 RFC2017[1]は元々RFC2046[3]で定義された外部のメッセージ/ボディーMIMEの種類と拡大を定義します。 RFC2017がする拡大で、ジェネリックURIはFTPのためのRFC2046の元々定義されているとしてのプロトコル特有のパラメタなどよりむしろ内容の位置を指定できます。 SIPの満足している間接指定メカニズムに必要である機能性の大部分を提供しますが、それ自体でRFC2017は完全解ではありません。 このドキュメントは満足している間接指定のために概説された要求にこたえるのに必要なRFC2017の使用法を指定します。
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、または、内容自体に適用するとして要件を分類できます。間接的に、URIは必要な内容に参照をつけます。 可能であるところでは、既存のMIMEパラメタと実体ヘッダーが、それらの要件を満たすのに使用されます。 MIME(コンテントタイプ)パラメタはURIについて説明する都合のよい方法です、実体ヘッダーが(間接的)の内容について説明する都合のよい方法ですが。 これらの実体ヘッダーとMIMEパラメタの大部分の記述のためのRFC2045[2]を見てください。
2. Terminology
2. 用語
RFC 2119 [5] defines the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
“SHALL"、RFC2119[5]が“MUST"、「必須NOT」が「必要である」というキーワードを定義する、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはそうするべきです。
3. Use Case Examples
3. 事例を使用してください。
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.
満足している間接指定メカニズムを使用するいくつかの例があります。 これらは、例専用であり、メカニズムの範囲か適用性を制限することを意図しません。
Burger Standards Track [Page 3] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[3ページ]。
3.1. Presence Notification
3.1. 存在通知
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)要求のためにお勧めのサイズを超えるかもしれません、特にドキュメントが複数の終点から集められた情報を載せるなら。 そのような状況で、間接的な指針があるNOTIFY要求を存在ドキュメントに送るのは望ましいでしょう。(次に、例えば、HTTPはドキュメントを検索できました)。
Watcher Presence Server
| |
| SUBSCRIBE |
|-------------------------->|
| 200 OK |
|<--------------------------|
| |
| NOTIFY |
|<--------------------------|
| 200 OK |
|-------------------------->|
| |
| NOTIFY (w/URI) |
|<--------------------------|
| 200 |
|-------------------------->|
| |
| HTTP GET |
|-------------------------->|
| |
| application/cpim-pidf+xml |
|<--------------------------|
| |
ウォッチャー存在サーバ| | | 登録| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 通知してください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 200 OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 通知してください(URIで)。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 200 | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| HTTPは得られます。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| アプリケーション/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を返します。
3.2. Document Sharing
3.2. ドキュメント共有
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(MESSAGE要求)をリモートパーティーによってレンダリングされることになっているドキュメントに送ります)。 直接MESSAGE要求でそのようなドキュメントを運ぶのは、シグナリングチャンネルが適切な使用ではありません。 その上、共有されるべきドキュメントは完全に独立しているサーバに起因するパーティーのものからあるかもしれません。
Burger Standards Track [Page 4] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[4ページ]。
UAC UAS Web Server
(User Agent (User Agent |
Client) Server) |
| | |
| MESSAGE w/URI | |
|------------------->| |
| 200 | |
|<-------------------| |
| | |
| | HTTP GET |
| |--------------->|
| | image/jpeg |
| |<---------------|
| | |
UAC UASウェブサーバー(ユーザエージェント(ユーザエージェント| クライアント)サーバ)| | | | | URIがあるメッセージ| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 200 | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、| HTTPは得られます。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| イメージ/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イメージを交換したがっています。 彼女はJPEGをIMの会話でインラインにするつもりです。 MESSAGE要求の受取人は、JPEGイメージを検索するためにHTTP GET要求にウェブサーバーに着手します。
4. Requirements
4. 要件
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が参照される内容をラベルしていて、したがって、事実上、ラベルが内容自体の「メタデータ」であると述べてください。
Burger Standards Track [Page 5] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[5ページ]。
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がこの満足している間接指定メカニズムのサポートを示すのは、可能であるに違いありません。 後退メカニズムSHOULD、パーティーのひとりが満足している間接指定をサポートすることができないなら、指定されてください。
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体系も満足している間接指定メカニズムで使用されるためにサポートを交渉するのは、可能であるに違いありません。 これはcontent typeを交渉する能力に加えています。
o It SHOULD be possible to ensure the integrity and confidentiality
of the URI when it is received by the remote party.
o それ、SHOULD、それがリモートパーティーによって受け取られるとき、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メッセージの内容の間接的な移転も考慮しなければなりません。
5. Application of RFC 2017 to the Content Indirection Problem
5. 満足している間接指定問題へのRFC2017のアプリケーション
The following text describes the application of RFC 2017 to the requirements for content indirection.
以下のテキストはRFC2017のアプリケーションについて満足している間接指定のための要件に説明します。
5.1. Specifying Support for Content Indirection
5.1. 満足している間接指定のサポートを指定します。
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 MAYは、それが受け入れても構わないと直接か満足している間接指定を通して思っているcontent typeを示すためにAcceptヘッダーで加算値を供給します。 内容をサポートするユーザエージェント間接指定はアプリケーション/sdp MIMEの種類の満足している間接指定をサポートしなければなりません。
For example:
例えば:
Accept: message/external-body, image/*, application/sdp
受け入れます: 外部のメッセージ/ボディー、イメージ/*、アプリケーション/sdp
Burger Standards Track [Page 6] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[6ページ]。
5.2. Mandatory support for HTTP URI
5.2. HTTP URIの義務的なサポート
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体系は使用されるかもしれませんが、それであるなら間接的な内容のためにHTTP URIを受けるUAC/UAS MUSTサポートは満足している間接指定のサポートの広告を出します。
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 MAYは設立が要求するUACのセッションへのUAS応答における、Contactヘッダーの体系パラメタの代替のアクセス体系の広告を出します(例えば、INVITE、登録)、RFC3840[11]で説明されるように。
5.3. Rejecting Content Indirection
5.3. 満足している間接指定を拒絶します。
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がサポートしたくはありませんし、UASが満足している間接指定ペイロードを含むSIP要求を受け取って、またそのようなcontent typeをサポートしたくないなら、それは.13セクション21.4SIP[9]で定義されるように415UnsupportedメディアType応答で要求を拒絶しなければなりません。 特に、UACは、UASが特定のメディアにタイプをサポートしないのを示すためにUASが、内容が間接指定、または要求されたコメントの特定のMIMEの種類の不在であるとサポートしないのを示すためにこの応答のAcceptヘッダーの外部のメッセージ/ボディーMIMEの種類の不在に注意するはずです。
5.4. Specifying the Location of the Content via a URI
5.4. URIでContentのLocationを指定します。
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によって参照をつけられるのを示します。 HTTP URI仕様はRFC2396[7]に従わなければなりません。
For example:
例えば:
Content-Type: message/external-body; access-type="URL";
URL="http://www.example.com/the-indirect-content"
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 URL= " http://www.example.com/the-indirect-content "
5.5. Marking Indirect Content Optional
5.5. 間接的な内容が任意であるとマークします。
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.
フェッチか変換失敗があれば、何らかの内容はコミュニケーションの文脈に重要ではありません。 満足している間接指定メカニズムはRFC3459[10]で説明されたCritical-内容メカニズムを使用します。 UASが任意の身体の部分をとって来るか、またはレンダリングできないなら、特に、サーバは誤りをUACに返してはいけません。
Burger Standards Track [Page 7] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[7ページ]。
5.6. Specifying Versioning Information for the URI
5.6. URIのためのVersioning情報を指定します。
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実体ヘッダーは使用されています。 このヘッダーの構文はRFC2045[2]で定義されます。 URIによって示された基本的な内容における変化はそのURIに関連しているContent IDの変化をもたらさなければなりません。 同じ内容SHOULDについて言及するURIを運ぶ複数のSIPメッセージが、受信機がこの内容をキャッシュして、不要なretrievalsを避けるのを許容するために同じコンテントIDを再利用します。 コンテントIDがグローバルに特有であることを意図して、SHOULDは時間的に意図します。SIP対話の向こう側にユニークです。
For example:
例えば:
Content-ID: <4232423424@www.example.com>
コンテントID: <4232423424@www.example.com>。
5.7. Specifying the URI Lifetime
5.7. URI生涯を指定します。
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が有効であって、アクセスしやすい期間を指定しなければなりません。 コンテントタイプの「満了」パラメタを通してこれをします。 この満了パラメタの形式はRFC1123[12]日付時間的価値です。 これは、グリニッジ標準時だけの時間を費やすためにこのアプリケーションでさらに制限されていて、日付:と一致しています。 SIPのヘッダー。 これは義務的なパラメタです。 日付時間的価値が何日も数分から何年もさえ及ぶことができることに注意してください。
For example:
例えば:
Content-Type: message/external-body;
expiration="Mon, 24 June 2002 09:00:00 GMT"
コンテントタイプ: 外部のメッセージ/ボディー。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」
5.8. Specifying the type of the Indirect Content
5.8. Indirect Contentのタイプを指定します。
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.
content typeの交渉のためのSIPメカニズム、コンテントタイプ実体ヘッダーSHOULDを存在にサポートするには、実体(ペイロード)自体で存在してください。 URIのプロトコル(体系)が、それ自身の満足している交渉がメカニズム(例えば、HTTP)であるとサポートするなら、このヘッダーは省略されるかもしれません。 しかしながら、受信機がURI体系に基本的なプロトコルを使用することによって適切なMIMEの種類を交渉できないなら、送付者は受領者が満足している間接指定を拒絶する用意ができていなければなりません。
Burger Standards Track [Page 8] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[8ページ]。
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>
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.com/the-indirect-content "<CRLF>コンテントタイプと等しいです: sdp Contentアプリケーション/気質: セッション<CRLF>。
5.9. Specifying the Size of the Indirect Content
5.9. 間接的な内容のサイズを指定します。
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.
あらかじめ知られていると、間接的サイズはバイトでSHOULDを満足させます。コンテントタイプヘッダーに関するサイズ・パラメータで、供給してください。 これは、RFC2017の拡大ですが、RFC2046の外部のメッセージ/ボディー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
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.com/the-indirect-content "と等しいです。 サイズ=4123
5.10. Specifying the Purpose of the Indirect Content
5.10. 間接的な内容の目的を指定します。
A Content-Disposition entity header MUST be present for all indirect content.
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
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.com/the-indirect-content "<CRLF>コンテントタイプと等しいです: jpeg Contentイメージ/気質: レンダリングします。
Burger Standards Track [Page 9] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[9ページ]。
5.11. Specifying Multiple URIs for Content Indirection
5.11. 満足している間接指定に複数のURIを指定します。
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].
以下に注意してください。 特に複合の/は、RFC2387[13]で説明されるようにこの仕様が様々な複合風味の意味を変えないと話しました。
For example:
例えば:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary42
MIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
--boundary42コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、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
2002年6月のための会社の発表は続きます: --boundary42コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.com/announcements/07242002 "と等しいです。 サイズ=4123
Content-Type: text/html
Content-Disposition: render
コンテントタイプ: html Contentテキスト/気質: レンダリングします。
--boundary42--
--boundary42--
5.12. Specifying a Hash Value for the Indirect Content
5.12. 間接的な内容にハッシュ値を指定します。
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]ハッシュを入れます。 それが含まれているなら、ハッシュは、値がハッシュをコード化する16進であるcontent type「外部のメッセージ/ボディー」のための「ハッシュ」パラメタを含むようにMIME構文[3]を広げることによって、コード化されます。
Burger Standards Track [Page 10] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[10ページ]。
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
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.com/the-indirect-content.au "と等しいです。 サイズ=52723。 ハッシュは10AB568E91245681AC1Bの<のCRLFの>の満足している気質と等しいです: レンダリングします。
5.13. Supplying Additional Comments about the Indirect Content
5.13. 間接的な内容に関して追加コメントを供給します。
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.
間接的な内容を批評するために任意の自由形状テキストを提供するのに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";
size=52723
<CRLF>
Content-Description: Multicast gaming session
Content-Disposition: render
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.com/the-indirect-content "と等しいです。 サイズは52723<CRLF>Content-記述と等しいです: マルチキャストゲーミングセッションContent-気質: レンダリングします。
5.14. Relationship to Call-Info, Error-Info, and Alert-Info Headers
5.14. 呼び出しインフォメーション、誤りインフォメーション、および注意深いインフォメーションヘッダーとの関係
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 MUSTを定義しました。このメカニズムに優先して適切であるところで使用されてください、それらのヘッダーの明確な意味論のために。
Burger Standards Track [Page 11] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[11ページ]。
6. Examples
6. 例
6.1. Single Content Indirection
6.1. ただ一つの満足している間接指定
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
INVITE一口: boromir@example.com SIP/2.0From: <一口: gandalf@example.net 、gt;、;=347242To:にタグ付けをしてください <一口: boromir@example.com 、gt;、呼び出しID: 3573853342923422@example.net CSeq: 2131年の招待は応じます: 外部のメッセージ/ボディーアプリケーション/sdpコンテントタイプ: 外部のメッセージ/ボディー。 アクセス型はURLと等しいです。 URLは" http://www.example.net/party/06/2002/announcement "と等しいです。 満了=「グリニッジ標準時2002年6月20日土曜日12時0分0秒」。 サイズは231のContent-長さと等しいです: 105
Content-Type: application/sdp
Content-Disposition: session
Content-ID: <4e5562cd1214427d@example.net>
コンテントタイプ: sdp Contentアプリケーション/気質: セッションコンテントID: <4e5562cd1214427d@example.net>。
6.2. Multipart MIME with Content Indirection
6.2. 満足している間接指定がある複合MIME
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
MESSAGE一口: boromir@example.com SIP/2.0From: <一口: gandalf@example.net 、gt;、;=34589882To:にタグ付けをしてください <一口: boromir@example.com 、gt;、呼び出しID: 9242892442211117@example.net CSeq: 388メッセージは受け入れます: 外部のメッセージ/ボディー、テキスト/html、テキスト/平野、イメージ/*、x-顔文字MIMEテキスト/バージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界=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
--zz993453コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.net/company_picnic/image1.png "と等しいです。 サイズ=234422
Content-Type: image/png
Content-ID: <9535035333@example.net>
Content-Disposition: render
Content-Description: Kevin getting dunked in the wading pool
コンテントタイプ: イメージ/pngコンテントID: <の9535035333@example.netの>の満足している気質: Content-記述をレンダリングしてください: 子供用プールでダンクされるケビン
--zz993453
--zz993453
Burger Standards Track [Page 12] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[12ページ]。
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
コンテントタイプ: 外部のメッセージ/ボディー。 アクセス型は「URL」と等しいです。 満了=「グリニッジ標準時2002年6月24日月曜日9時0分0秒」。 URLは" http://www.example.net/company_picnic/image2.png "と等しいです。 サイズ=233811
Content-Type: image/png
Content-ID: <1134299224244@example.net>
Content-Disposition: render
Content-Description: Peter on his tricycle
コンテントタイプ: イメージ/pngコンテントID: <の1134299224244@example.netの>の満足している気質: Content-記述をレンダリングしてください: 彼の三輪車の上のピーター
--zz993453--
--zz993453--
7. Security Considerations
7. セキュリティ問題
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要求にそれを発行するように受取人に頼むのがBasic認証挑戦をもたらします)。
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は内部のユーザ名(1つのHTTP URLの一部としての)かことによるとgeolocation情報などの創始者に関する機密情報を明らかにすることができます。
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
間接指定メカニズムがメカニズムが概説したセキュリティを当てにする秘密性、保全、および認証、この内容のために
Burger Standards Track [Page 13] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[13ページ]。
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.
RFC3261。 特に、RFC3261のセクション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が使用されているなら、この満足している間接指定メソッドがSHOULDであると実装するアプリケーションは、内容の安全な転送のためにHTTPS URI体系をサポートして、接続のアップグレードをTLSにサポートしなければなりません、starttlsを使用することによって。 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 SHOULD NOTはそれとなく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 SHOULDは満足している間接指定によるハッシュパラメタを含んでいます。 ハッシュパラメタは間接的な内容の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 MUSTは、証明書合法化手順の結果を無視して、(canonicalizedしました)内容のハッシュがハッシュが満足している間接指定ハッシュパラメタに示したマッチを受けたことを代わりに確かめます。
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.
ハッシュパラメタが含まれていないなら、送付者SHOULD使用はその申し出メッセージの保全を計画するだけです(httpsなどのように:)。 ハッシュパラメタが含まれていなくて、証明書を使用するセキュリティが使用されているとき、UAS MUSTはどんなサーバ証明書についても確かめます、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.
間接的な内容を論じ尽くすのが使用されていないなら、間接指定の運動で受取人に返された内容は送付者によって意図されたそれから変更されたかもしれません。
Burger Standards Track [Page 14] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[14ページ]。
8. Contributions
8. 貢献
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.
エリックBurgerはアクセス・プロトコル交渉メカニズムを含むドキュメントと扱われたIESGコメントを編集しました。
9. Acknowledgements
9. 承認
Cullen Jennings and Nancy Greene provided a through review and valuable comments and suggestions.
カレンのジョニングスとナンシー・グリーンはレビュー、貴重なコメント、および提案でaを提供しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Freed, N. and K. Moore, "Definition of the URL MIME External-
Body Access-Type", RFC 2017, October 1996.
解放された[1]とN.とK.ムーア、「URLのMIMEの外部のボディーアクセス型の定義」、RFC2017、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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を分けます」。 「メディアタイプ」、RFC2046、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.、Gettys、J.、ムガール人、J.、ニールセン、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997.
[6] ダニエル、R.、「つぼの解決にHTTPを使用するための些細なコンベンション」、RFC2169、1997年6月。
[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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[8] イーストレークとD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
Burger Standards Track [Page 15] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[15ページ]。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[10] Burger, E., "Critical Content Multi-purpose Internet Mail
Extensions (MIME) Parameter", RFC 3459, January 2003.
[10] バーガー、E.、「重要な満足している多目的のインターネットメール拡大(MIME)パラメタ」、RFC3459、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、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[12] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989.
[12] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
10.2. Informative Reference
10.2. 有益な参照
[13] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
[13] レヴィンソン、1998年8月、E.、「MIMEの複合の、または、関連の文書内容」RFC2387。
Author's Address
作者のアドレス
Eric Burger (editor) Cantata Technolgy, Inc.
エリックバーガー(エディタ)カンタータTechnolgy Inc.
EMail: eburger@cantata.com URI: http://www.cantata.com
メール: eburger@cantata.com ユリ: http://www.cantata.com
Burger Standards Track [Page 16] RFC 4483 Content Indirection in SIP Messages May 2006
バーガー規格は2006年5月に一口メッセージでのRFC4483の満足している間接指定を追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Burger Standards Track [Page 17]
バーガー標準化過程[17ページ]
一覧
スポンサーリンク
