RFC4975 日本語訳
4975 The Message Session Relay Protocol (MSRP). B. Campbell, Ed., R.Mahy, Ed., C. Jennings, Ed.. September 2007. (Format: TXT=144254 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Campbell, Ed.
Request for Comments: 4975 Estacado Systems
Category: Standards Track R. Mahy, Ed.
Plantronics
C. Jennings, Ed.
Cisco Systems, Inc.
September 2007
ワーキンググループのB.キャンベル、エドをネットワークでつないでください。コメントのために以下を要求してください。 4975年のエスタカードシステムカテゴリ: エド標準化過程R.マーイ、エドPlantronics C.ジョニングス、シスコシステムズInc.2007年9月
The Message Session Relay Protocol (MSRP)
メッセージセッションリレープロトコル(MSRP)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
このドキュメントはMessage Session Relayプロトコル(セッションの文脈の一連の関連するインスタントメッセージを伝えるためのプロトコル)について説明します。 ランデブーを通したセットかSession Initiationプロトコルなどのセッション作成プロトコルであるときに、メッセージセッションはいかなる他のメディアストリームのようにも扱われます。
Campbell, et al. Standards Track [Page 1] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions .....................................................5
3. Applicability of MSRP ...........................................5
4. Protocol Overview ...............................................6
5. Key Concepts ....................................................9
5.1. MSRP Framing and Message Chunking ..........................9
5.2. MSRP Addressing ...........................................10
5.3. MSRP Transaction and Report Model .........................11
5.4. MSRP Connection Model .....................................12
6. MSRP URIs ......................................................14
6.1. MSRP URI Comparison .......................................15
6.2. Resolving MSRP Host Device ................................16
7. Method-Specific Behavior .......................................17
7.1. Constructing Requests .....................................17
7.1.1. Sending SEND Requests ..............................18
7.1.2. Sending REPORT Requests ............................21
7.1.3. Generating Success Reports .........................22
7.1.4. Generating Failure Reports .........................23
7.2. Constructing Responses ....................................24
7.3. Receiving Requests ........................................25
7.3.1. Receiving SEND Requests ............................25
7.3.2. Receiving REPORT Requests ..........................27
8. Using MSRP with SIP and SDP ....................................27
8.1. SDP Connection and Media-Lines ............................28
8.2. URI Negotiations ..........................................29
8.3. Path Attributes with Multiple URIs ........................30
8.4. Updated SDP Offers ........................................31
8.5. Connection Negotiation ....................................31
8.6. Content Type Negotiation ..................................32
8.7. Example SDP Exchange ......................................34
8.8. MSRP User Experience with SIP .............................35
8.9. SDP Direction Attribute and MSRP ..........................35
9. Formal Syntax ..................................................36
10. Response Code Descriptions ....................................38
10.1. 200 ......................................................38
10.2. 400 ......................................................38
10.3. 403 ......................................................38
10.4. 408 ......................................................39
10.5. 413 ......................................................39
10.6. 415 ......................................................39
10.7. 423 ......................................................39
10.8. 481 ......................................................39
10.9. 501 ......................................................39
10.10. 506 .....................................................40
1. 序論…4 2. コンベンション…5 3. MSRPの適用性…5 4. 概要について議定書の中で述べてください…6 5. 重要概念…9 5.1. MSRP縁どりとメッセージ分魂化…9 5.2. MSRPアドレシング…10 5.3. MSRPトランザクションとレポートはモデル化されます…11 5.4. MSRP接続モデル…12 6. MSRP URI…14 6.1. MSRP URI比較…15 6.2. MSRPホストデバイスを決議します…16 7. メソッド特有の振舞い…17 7.1. 要求を構成します…17 7.1.1. 発信して、要求を送ってください…18 7.1.2. 送付レポート要求…21 7.1.3. 成功を生成するのは報告します…22 7.1.4. 失敗を生成するのは報告します…23 7.2. 応答を構成します…24 7.3. 要求を受け取ります…25 7.3.1. 受信して、要求を送ってください…25 7.3.2. 受信報告書要求…27 8. 一口があるMSRPとSDPを使用します…27 8.1. SDP接続とメディア線…28 8.2. URI交渉…29 8.3. 複数のURIがある経路属性…30 8.4. SDP申し出をアップデートします…31 8.5. 接続交渉…31 8.6. content type交渉…32 8.7. 例のSDP交換…34 8.8. 一口のMSRPユーザー・エクスペリエンス…35 8.9. SDP方向の属性とMSRP…35 9. 正式な構文…36 10. 応答コード記述…38 10.1. 200 ......................................................38 10.2. 400 ......................................................38 10.3. 403 ......................................................38 10.4. 408 ......................................................39 10.5. 413 ......................................................39 10.6. 415 ......................................................39 10.7. 423 ......................................................39 10.8. 481 ......................................................39 10.9. 501 ......................................................39 10.10. 506 .....................................................40
Campbell, et al. Standards Track [Page 2] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[2ページ]。
11. Examples ......................................................40
11.1. Basic IM Session .........................................40
11.2. Message with XHTML Content ...............................42
11.3. Chunked Message ..........................................43
11.4. Chunked Message with Message/CPIM Payload ................43
11.5. System Message ...........................................44
11.6. Positive Report ..........................................44
11.7. Forked IM ................................................45
12. Extensibility .................................................48
13. CPIM Compatibility ............................................48
14. Security Considerations .......................................49
14.1. Secrecy of the MSRP URI ..................................50
14.2. Transport Level Protection ...............................50
14.3. S/MIME ...................................................51
14.4. Using TLS in Peer-to-Peer Mode ...........................52
14.5. Other Security Concerns ..................................53
15. IANA Considerations ...........................................55
15.1. MSRP Method Names ........................................55
15.2. MSRP Header Fields .......................................55
15.3. MSRP Status Codes ........................................56
15.4. MSRP Port ................................................56
15.5. URI Schema ...............................................56
15.5.1. MSRP Scheme .......................................56
15.5.2. MSRPS Scheme ......................................57
15.6. SDP Transport Protocol ...................................57
15.7. SDP Attribute Names ......................................58
15.7.1. Accept Types ......................................58
15.7.2. Wrapped Types .....................................58
15.7.3. Max Size ..........................................58
15.7.4. Path ..............................................58
16. Contributors and Acknowledgments ..............................59
17. References ....................................................59
17.1. Normative References .....................................59
17.2. Informative References ...................................60
11. 例…40 11.1. 基本的な不-セッション…40 11.2. XHTML内容があるメッセージ…42 11.3. メッセージをChunkedしました…43 11.4. メッセージ/CPIM有効搭載量でメッセージをChunkedしました…43 11.5. システムメッセージ…44 11.6. 積極的なレポート…44 11.7. 股状、不-、…45 12. 伸展性…48 13. CPIMの互換性…48 14. セキュリティ問題…49 14.1. MSRP URIの秘密保持…50 14.2. 平らな保護を輸送してください…50 14.3. S/MIME…51 14.4. ピアツーピアモードでTLSを使用します…52 14.5. 他のセキュリティ関心…53 15. IANA問題…55 15.1. MSRPメソッド名…55 15.2. MSRPヘッダーフィールド…55 15.3. MSRPステータスコード…56 15.4. MSRPポート…56 15.5. URI図式…56 15.5.1. MSRPは計画します…56 15.5.2. MSRPSは計画します…57 15.6. SDPはプロトコルを輸送します…57 15.7. SDPは名前を結果と考えます…58 15.7.1. タイプを受け入れてください…58 15.7.2. タイプを包装します…58 15.7.3. マックスSize…58 15.7.4. 経路…58 16. 貢献者と承認…59 17. 参照…59 17.1. 標準の参照…59 17.2. 有益な参照…60
Campbell, et al. Standards Track [Page 3] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[3ページ]。
1. Introduction
1. 序論
A series of related instant messages between two or more parties can be viewed as part of a "message session", that is, a conversational exchange of messages with a definite beginning and end. This is in contrast to individual messages each sent independently. Messaging schemes that track only individual messages can be described as "page-mode" messaging, whereas messaging that is part of a "session" with a definite start and end is called "session-mode" messaging.
「メッセージセッション」(すなわち、明確な首尾があるメッセージの会話の交換)の一部として2回以上のパーティーの間の一連の関連するインスタントメッセージを見なすことができます。 これはそれぞれ独自に送られた個々のメッセージと対照的になっています。 個々のメッセージだけを追跡するメッセージング体系は「ページモード」メッセージングとして記述できますが、明確な始めと終わりとの「セッション」の一部であるメッセージングは「セッションモード」メッセージングと呼ばれます。
Page-mode messaging is enabled in SIP via the SIP [4] MESSAGE method [22]. Session-mode messaging has a number of benefits over page-mode messaging, however, such as explicit rendezvous, tighter integration with other media-types, direct client-to-client operation, and brokered privacy and security.
ページモードメッセージングはSIPでSIP[4]MESSAGEメソッド[22]で可能にされます。 しかしながら、セッションモードメッセージングは明白なランデブー、他のメディアタイプ、クライアントからクライアントへのダイレクト操作、仲介されたプライバシー、およびセキュリティがある、よりきつい統合などのようにページモードメッセージングの上に多くの利益を持っています。
This document defines a session-oriented instant message transport protocol called the Message Session Relay Protocol (MSRP), whose sessions can be negotiated with an offer or answer [3] using the Session Description Protocol (SDP) [2]. The exchange is carried by some signaling protocol, such as SIP [4]. This allows a communication user agent to offer a messaging session as one of the possible media-types in a session. For instance, Alice may want to communicate with Bob. Alice doesn't know at the moment whether Bob has his phone or his IM client handy, but she's willing to use either. She sends an invitation to a session to the address of record she has for Bob, sip:bob@example.com. Her invitation offers both voice and an IM session. The SIP services at example.com forward the invitation to Bob at his currently registered clients. Bob accepts the invitation at his IM client, and they begin a threaded chat conversation.
このドキュメントは[3] Session記述プロトコル(SDP)[2]を使用することで申し出か答えとセッションを交渉できるMessage Session Relayプロトコル(MSRP)と呼ばれるセッション指向のインスタントメッセージトランスポート・プロトコルを定義します。 交換はSIP[4]などの何らかのシグナリングプロトコルによって運ばれます。 これで、コミュニケーションユーザエージェントはセッションのときに可能なメディアタイプのひとりとしてメッセージングセッションを提供できます。 例えば、アリスはボブとコミュニケートしたがっているかもしれません。 アリスは、現在、ボブが彼の電話か彼のIMクライアントを便利にするかどうかを知りませんが、彼女は、どちらかを使用しても構わないと思っています。 彼女は彼女が一口: ボブ、 bob@example.com のために持っている記録されている住所へのセッションへの招待状を送ります。 彼女の招待は声とIMセッションの両方を提供します。 example.comでのSIPサービスは彼の現在登録されたクライアントでボブへの招待を進めます。 ボブは彼のIMクライアントで招待に応じます、そして、彼らは糸を通されたチャットの会話を始めます。
When a user uses an Instant Messaging (IM) URL, RFC 3861 [32] defines how DNS can be used to map this to a particular protocol to establish the session such as SIP. SIP can use an offer/answer model to transport the MSRP URIs for the media in SDP. This document defines how the offer/answer exchange works to establish MSRP connections and how messages are sent across the MSRP, but it does not deal with the issues of mapping an IM URL to a session establishment protocol.
ユーザがInstant Messaging(IM)URLを使用すると、RFC3861[32]はSIPなどのセッションを証明するために特定のプロトコルにこれを写像するのにどうDNSを使用できるかを定義します。 SIPは、SDPのメディアのためにMSRP URIを輸送するのに申し出/答えモデルを使用できます。 このドキュメントは、申し出/答え交換がMSRP接続を証明するためにどのように働くか、そして、メッセージがMSRPの向こう側にどのように送られるかを定義しますが、それはセッション設立プロトコルにIM URLを写像する問題に対処しません。
This session model allows message sessions to be integrated into advanced communications applications with little to no additional protocol development. For example, during the above chat session, Bob decides Alice really needs to be talking to Carol. Bob can transfer [21] Alice to Carol, introducing them into their own messaging session. Messaging sessions can then be easily integrated into call-center and dispatch environments using third-party call control [20] and conferencing [19] applications.
このセッションモデルは、メッセージセッションが追加議定書開発がないことへの少しでアドバンスド・コミュニケーションアプリケーションと統合されるのを許容します。 例えば、上のチャットセッションの間、ボブは、アリスが、本当にキャロルと話す必要であると決めます。 それら自身のメッセージングセッションにそれらを取り入れて、ボブは[21] アリスをキャロルに移すことができます。 そして、第三者呼び出しコントロール[20]と会議[19]アプリケーションを使用することでコールセンターと発信環境と容易にメッセージングセッションを統合できます。
Campbell, et al. Standards Track [Page 4] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[4ページ]。
This document specifies MSRP behavior only for peer-to-peer sessions, that is, sessions crossing only a single hop. MSRP relay devices [23] (referred to herein as "relays") are specified in a separate document. An endpoint that implements this specification, but not the relay specification, will be unable to introduce relays into the message path, but will still be able to interoperate with peers that do use relays.
このドキュメントはすなわち、単にピアツーピアセッション、単一のホップだけに交差するセッションとしてMSRPの振舞いを指定します。 MSRPリレーデバイス[23](ここに「リレー」に言及されます)は別々のドキュメントで指定されます。 リレー仕様ではなく、この仕様を履行する終点は、メッセージ経路にリレーを取り入れることができませんが、リレーを使用する同輩と共にまだ共同利用できるでしょう。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
This document consistently refers to a "message" as a complete unit of MIME or text content. In some cases, a message is split and delivered in more than one MSRP request. Each of these portions of the complete message is called a "chunk".
このドキュメントは一貫してMIMEかテキスト内容の完成品一式に「メッセージ」について言及します。 いくつかの場合、メッセージは、MSRPが要求する1つ以上で分けられて、提供されます。 それぞれの完全なメッセージのこれらの部分は「塊」と呼ばれます。
3. Applicability of MSRP
3. MSRPの適用性
MSRP is not designed for use as a standalone protocol. MSRP MUST be used only in the context of a rendezvous mechanism meeting the following requirements:
MSRPは使用のためにスタンドアロンプロトコルとして設計されていません。 MSRP MUST、以下の必要条件を満たしながら、ランデブーメカニズムの文脈だけで使用されてください:
o The rendezvous mechanism MUST provide both MSRP URIs associated
with an MSRP session to each of the participating endpoints. The
rendezvous mechanism MUST implement mechanisms to protect the
confidentiality of these URIs -- they MUST NOT be made available
to an untrusted third party or be easily discoverable.
o ランデブーメカニズムはMSRP URIがそれぞれの参加へのMSRPセッションに関連づけた両方に終点を提供しなければなりません。 ランデブーメカニズムはこれらのURIの秘密性を保護するためにメカニズムを実装しなければなりません--それらは、信頼されていない第三者にとって利用可能に作られていなくて、容易に発見可能であるはずがありません。
o The rendezvous mechanism MUST provide mechanisms for the
negotiation of any supported MSRP extensions that are not
backwards compatible.
o ランデブーメカニズムはMSRP拡張子であると後方にないサポートされたいずれの交渉にメカニズムを提供しなければなりません。互換性がある。
o The rendezvous mechanism MUST be able to natively transport im:
URIs or automatically translate im: URIs [27] into the addressing
identifiers of the rendezvous protocol.
o ランデブーメカニズムが輸送をネイティブであることができなければならない、不-、: URI、自動的に翻訳してください、不-、: ランデブーに関するアドレシング識別子へのURI[27]は議定書を作ります。
To use a rendezvous mechanism with MSRP, an RFC MUST be prepared that describes how it exchanges MSRP URIs and meets these requirements listed here. This document provides such a description for the use of MSRP in the context of SIP and SDP.
MSRP、RFC MUSTがあるランデブーメカニズムを使用するために、準備されていて、それはそれがどうMSRP URIを交換して、ここにリストアップされたこれらの必要条件を満たすかを説明します。 このドキュメントはSIPとSDPの文脈におけるMSRPの使用のためのそのような記述を提供します。
SIP meets these requirements for a rendezvous mechanism. The MSRP URIs are exchanged using SDP in an offer/answer exchange via SIP.
SIPはランデブーメカニズムのためにこれらの必要条件を満たします。 SIPを通して申し出/答え交換にSDPを使用することでMSRP URIを交換します。
Campbell, et al. Standards Track [Page 5] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[5ページ]。
The exchanged SDP can also be used to negotiate MSRP extensions. This SDP can be secured using any of the mechanisms available in SIP, including using the sips mechanism to ensure transport security across intermediaries and Secure/Multipurpose Internet Mail Extensions (S/MIME) for end-to-end protection of the SDP body. SIP can carry arbitrary URIs (including im: URIs) in the Request-URI, and procedures are available to map im: URIs to sip: or sips: URIs. It is expected that initial deployments of MSRP will use SIP as its rendezvous mechanism.
また、MSRP拡張子を交渉するのに交換されたSDPを使用できます。 このSDPは一口を使用するのを含むSIPで利用可能なメカニズムの機密保護している使用しているどれかが終わりから終わりへのSDPボディーの保護のために仲介者とSecure/マルチパーパスインターネットメールエクステンション(S/MIME)の向こう側に輸送セキュリティを確実にするメカニズムであったならそうすることができます。 SIPが任意のURIを運ぶことができる、(包含、不-、: URI) Request-URIで手順が写像するために利用可能である、不-、: ちびちび飲むURI: 一口: URI。 MSRPの初期の展開がランデブーメカニズムとしてSIPを使用すると予想されます。
4. Protocol Overview
4. プロトコル概要
MSRP is a text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME [8] content, especially instant messages. This section is a non-normative overview of how MSRP works and how it is used with SIP.
MSRPは、任意(2進の)のMIME[8]内容、特にインスタントメッセージを交換するためのテキストベースの、そして、接続指向のプロトコルです。 このセクションはMSRPがどのように働くか、そして、それがSIPと共にどのように使用されるかに関する非標準の概要です。
MSRP sessions are typically arranged using SIP the same way a session of audio or video media is set up. One SIP user agent (Alice) sends the other (Bob) a SIP invitation containing an offered session- description that includes a session of MSRP. The receiving SIP user agent can accept the invitation and include an answer session- description that acknowledges the choice of media. Alice's session description contains an MSRP URI that describes where she is willing to receive MSRP requests from Bob, and vice versa. (Note: Some lines in the examples are removed for clarity and brevity.)
MSRPセッションはSIPを使用することで通常アレンジされて、同じように、オーディオかビデオメディアのセッションがセットアップされるということです。 1人のSIPユーザエージェント(アリス)がMSRPのセッションを含んでいる提供されたセッション記述を含むSIP招待状をもう片方(ボブ)に送ります。 受信SIPユーザエージェントは、招待に応じて、答えを入れることができます。メディアの選択を承諾するセッション記述。 アリスのセッション記述は彼女が、どこでボブからMSRP要求を受け取っても構わないと思っているかを説明するMSRP URIを含んでいます、逆もまた同様に。 (注意: 明快と簡潔さのために例のいくつかの系列を取り除きます。)
Alice sends to Bob:
アリスはボブに発信します:
INVITE sip:bob@biloxi.example.com SIP/2.0 To: <sip:bob@biloxi.example.com> From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp
INVITE一口: bob@biloxi.example.com SIP/2.0To: <一口: bob@biloxi.example.com 、gt;、From: <一口: alice@atlanta.example.com 、gt;、; タグは786呼び出しIDと等しいです: 3413an89KUコンテントタイプ: アプリケーション/sdp
c=IN IP4 atlanta.example.com m=message 7654 TCP/MSRP * a=accept-types:text/plain a=path:msrp://atlanta.example.com:7654/jshA7weztas;tcp
=経路: タイプ: テキスト/平野msrp://を受け入れているメッセージ7654TCP/MSRP*a IN IP4 atlanta.example.com c=m==atlanta.example.com: 7654/jshA7weztas; tcpします。
Campbell, et al. Standards Track [Page 6] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[6ページ]。
Bob sends to Alice:
ボブはアリスに発信します:
SIP/2.0 200 OK To: <sip:bob@biloxi.example.com>;tag=087js From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU Content-Type: application/sdp
一口/2.0 200OK To: <一口: bob@biloxi.example.com 、gt;、;=087js From:にタグ付けをしてください <一口: alice@atlanta.example.com 、gt;、; タグは786呼び出しIDと等しいです: 3413an89KUコンテントタイプ: アプリケーション/sdp
c=IN IP4 biloxi.example.com m=message 12763 TCP/MSRP * a=accept-types:text/plain a=path:msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
=経路: タイプ: テキスト/平野msrp://を受け入れているメッセージ12763TCP/MSRP*a IN IP4 biloxi.example.com c=m==biloxi.example.com: 12763/kjhd37s2s20w2a; tcpします。
Alice sends to Bob:
アリスはボブに発信します:
ACK sip:bob@biloxi SIP/2.0 To: <sip:bob@biloxi.example.com>;tag=087js From: <sip:alice@atlanta.example.com>;tag=786 Call-ID: 3413an89KU
ACK一口: bob@biloxi SIP/2.0To: <一口: bob@biloxi.example.com 、gt;、;=087js From:にタグ付けをしてください <一口: alice@atlanta.example.com 、gt;、; タグは786呼び出しIDと等しいです: 3413an89KU
Figure 1: Session Setup
図1: セッションセットアップ
MSRP defines two request types, or methods. SEND requests are used to deliver a complete message or a chunk (a portion of a complete message), while REPORT requests report on the status of a previously sent message, or a range of bytes inside a message. When Alice receives Bob's answer, she checks to see if she has an existing connection to Bob. If not, she opens a new connection to Bob using the URI he provided in the SDP. Alice then delivers a SEND request to Bob with her initial message, and Bob replies indicating that Alice's request was received successfully.
MSRPは2つの要求タイプ、またはメソッドを定義します。 SEND要求は完全なメッセージか塊(完全なメッセージの部分)を提供するのに使用されます、REPORT要求が以前に送られたメッセージの状態か、メッセージのさまざまなバイト中において報告しますが。 アリスがボブの答えを受けるとき、彼女は、ボブに彼女が既存の接続がいるかどうか確認するためにチェックします。 そうでなければ、彼女は、彼がSDPに供給したURIを使用することで新しい接続をボブに公開します。 次に、アリスは彼女の初期のメッセージでSEND要求をボブに提供します、そして、アリスの要求が首尾よく受け取られたのを示しながら、ボブは返答します。
Campbell, et al. Standards Track [Page 7] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[7ページ]。
MSRP a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp Message-ID: 87652491 Byte-Range: 1-25/25 Content-Type: text/plain
MSRP a786hjs2 SEND To-経路: msrp://biloxi.example.com: 12763/kjhd37s2s20w2a; tcp From-経路、: msrp://atlanta.example.com: 7654/jshA7weztas; tcp Message ID: 87652491バイト範囲: 1-25/25コンテントタイプ: テキスト/平野
Hey Bob, are you there? -------a786hjs2$
ほら、ボブ、あなたはそこにいますか? -------a786hjs2$
MSRP a786hjs2 200 OK To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp -------a786hjs2$
MSRP a786hjs2 200OK To-経路: msrp://atlanta.example.com: 7654/jshA7weztas; tcpに経路: msrp://biloxi.example.com: 12763/kjhd37s2s20w2a; tcp-------a786hjs2$
Figure 2: Example MSRP Exchange
図2: 例のMSRP交換
Alice's request begins with the MSRP start line, which contains a transaction identifier that is also used for request framing. Next she includes the path of URIs to the destination in the To-Path header field, and her own URI in the From-Path header field. In this typical case, there is just one "hop", so there is only one URI in each path header field. She also includes a message ID, which she can use to correlate status reports with the original message. Next she puts the actual content. Finally, she closes the request with an end-line of seven hyphens, the transaction identifier, and a "$" to indicate that this request contains the end of a complete message.
アリスの要求はMSRPスタート系列で始まります。(それは、また、要求縁どりに使用されるトランザクション識別子を含みます)。 次に、彼女はTo-経路ヘッダーフィールドにおける目的地、およびFrom-経路ヘッダーフィールドにおける彼女自身のURIにURIの経路を入れます。 この典型的な場合には、それぞれの経路ヘッダーフィールドに1つのURIしかなくて、ちょうど1「ホップ」があります。 また、彼女はメッセージIDを入れます。(彼女は、オリジナルのメッセージで現状報告を関連させるのにそれを使用できます)。 次に、彼女は実際の内容を置きます。 最終的に、彼女は、この要求が完全なメッセージの終わりを含むのを示すために7つのハイフン、トランザクション識別子、および「$」のEND行で要求を終えます。
If Alice wants to deliver a very large message, she can split the message into chunks and deliver each chunk in a separate SEND request. The message ID corresponds to the whole message, so the receiver can also use it to reassemble the message and tell which chunks belong with which message. Chunking is described in more detail in Section 5.1. The Byte-Range header field identifies the portion of the message carried in this chunk and the total size of the message.
アリスが非常に大きいメッセージを提供したいなら、彼女は、メッセージを塊に分けて、別々のSEND要求で各塊を提供できます。 メッセージIDが全体のメッセージに対応しているので、また、受信機はメッセージを組み立て直して、どの塊がどのメッセージで属するかを言うのにそれを使用できます。 分魂化はさらに詳細にセクション5.1で説明されます。 Byte-範囲ヘッダーフィールドはこの塊で伝えられるメッセージの部分とメッセージの総サイズを特定します。
Alice can also specify what type of reporting she would like in response to her request. If Alice requests positive acknowledgments, Bob sends a REPORT request to Alice confirming the delivery of her complete message. This is especially useful if Alice sent a series of SEND requests containing chunks of a single message. More on requesting types of reports and errors is described in Section 5.3.
また、アリスは、彼女の要求に対応してどんなタイプの報告が欲しいかを指定できます。 アリスが肯定応答を要求するなら、ボブは彼女の完全なメッセージの配送を確認するアリスにREPORT要求を送ります。 アリスがただ一つのメッセージの塊を含む一連のSEND要求を送ったなら、これは特に役に立ちます。 レポートと誤りのタイプを要求するときの以上はセクション5.3で説明されます。
Alice and Bob choose their MSRP URIs in such a way that it is difficult to guess the exact URI. Alice and Bob can reject requests to URIs they are not expecting to service and can correlate the specific URI with the probable sender. Alice and Bob can also use
アリスとボブは正確なURIを推測するのが難しいような方法でそれらのMSRP URIを選びます。 アリスとボブは、彼らが修理すると予想していないURIに要求を拒絶できて、ありえそうな送付者と共に特定のURIを関連させることができます。 また、アリスとボブは使用できます。
Campbell, et al. Standards Track [Page 8] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[8ページ]。
TLS [1] to provide channel security over this hop. To receive MSRP requests over a TLS protected connection, Alice or Bob could advertise URIs with the "msrps" scheme instead of "msrp".
提供するTLS[1]はこのホップの上にセキュリティを向けます。 MSRP要求をTLSの上に受け取るために、"msrps"体系が"msrp"の代わりにある状態で、保護された接続、アリスまたはボブがURIの広告を出すことができました。
MSRP is designed with the expectation that MSRP can carry URIs for nodes on the far side of relays. For this reason, a URI with the "msrps" scheme makes no assertion about the security properties of other hops, just the next hop. The user agent knows the URI for each hop, so it can verify that each URI has the desired security properties.
MSRPによる期待で設計されていて、そのMSRPがリレーを越してノードのためにURIを運ぶことができるということです。 この理由で、"msrps"体系があるURIは他のホップのセキュリティ所有地の周りの主張ではなく、まさしく次のホップを作ります。 ユーザエージェントが各ホップでURIを知っているので、それは、各URIには必要なセキュリティの特性があることを確かめることができます。
MSRP URIs are discussed in more detail in Section 6.
さらに詳細にセクション6でMSRP URIについて議論します。
An adjacent pair of busy MSRP nodes (for example, two relays) can easily have several sessions, and exchange traffic for several simultaneous users. The nodes can use existing connections to carry new traffic with the same destination host, port, transport protocol, and scheme. MSRP nodes can keep track of how many sessions are using a particular connection and close these connections when no sessions have used them for some period of time. Connection management is discussed in more detail in Section 5.4.
忙しいMSRPノード(例えば、2個のリレー)の隣接している組は数人の同時のユーザのために容易にいくつかのセッション、および交換トラフィックを持つことができます。 ノードは、同じあて先ホスト、ポート、トランスポート・プロトコル、および体系で新しいトラフィックを運ぶのに既存の接続を使用できます。 どんなセッションもいつかの期間の間それらを使用していないとき、MSRPノードは、いくつのセッションが特定の接続を使用するかに関する道を保って、これらの接続を終えることができます。 さらに詳細にセクション5.4で接続管理について議論します。
5. Key Concepts
5. 重要な考え
5.1. MSRP Framing and Message Chunking
5.1. MSRP縁どりとメッセージ分魂化
Messages sent using MSRP can be very large and can be delivered in several SEND requests, where each SEND request contains one chunk of the overall message. Long chunks may be interrupted in mid- transmission to ensure fairness across shared transport connections. To support this, MSRP uses a boundary-based framing mechanism. The start line of an MSRP request contains a unique identifier that is also used to indicate the end of the request. Included at the end of the end-line, there is a flag that indicates whether this is the last chunk of data for this message or whether the message will be continued in a subsequent chunk. There is also a Byte-Range header field in the request that indicates the overall position of this chunk inside the complete message.
MSRPが使用させられたメッセージは、非常に大きい場合があり、いくつかのSEND要求で提供できます。そこでは、それぞれのSEND要求が総合的なメッセージの1つの塊を含みます。 長い塊は、共有された輸送の接続の向こう側に公正を確実にするために中間のトランスミッションで中断されるかもしれません。 これをサポートするために、MSRPは境界ベースの縁どりメカニズムを使用します。 MSRP要求のスタート系列はまた、要求の終わりを示すのに使用されるユニークな識別子を含んでいます。 END行の終わりに含まれていて、これがこのメッセージのためのデータの最後の塊であるかどうかかそれともメッセージがその後の塊で続けられるかどうかを示す旗があります。 また、完全なメッセージでこの塊のオーバーオール・ポジションを示す要求にはByte-範囲ヘッダーフィールドがあります。
For example, the following snippet of two SEND requests demonstrates a message that contains the text "abcdEFGH" being sent as two chunks.
例えば、2つのSEND要求の以下の切れ端は2つの塊として送られるテキスト"abcdEFGH"を含むメッセージを示します。
Campbell, et al. Standards Track [Page 9] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[9ページ]。
MSRP dkei38sd SEND
Message-ID: 4564dpWd
Byte-Range: 1-*/8
Content-Type: text/plain
MSRP dkei38sd SEND Message-ID: 4564dpWdバイト範囲: 1*/8コンテントタイプ: テキスト/平野
abcd
-------dkei38sd+
abcd-------dkei38sd+
MSRP dkei38ia SEND
Message-ID: 4564dpWd
Byte-Range: 5-8/8
Content-Type: text/plain
MSRP dkei38ia SEND Message-ID: 4564dpWdバイト範囲: 5-8/8コンテントタイプ: テキスト/平野
EFGH
-------dkei38ia$
EFGH-------dkei38ia$
Figure 3: Breaking a Message into Chunks
図3: メッセージを塊に細かく分けます。
This chunking mechanism allows a sender to interrupt a chunk part of the way through sending it. The ability to interrupt messages allows multiple sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection, or even the same MSRP session. Any chunk that is larger than 2048 octets MUST be interruptible. While MSRP would be simpler to implement if each MSRP session used its own TCP connection, there are compelling reasons to conserve connections. For example, the TCP peer may be a relay device that connects to many other peers. Such a device will scale better if each peer does not create a large number of connections. (Note that in the above example, the initial chunk was interruptible for the sake of example, even though its size is well below the limit for which interruptibility would be required.)
この分魂化メカニズムで、送付者は、それを送ることで方法の塊部分を中断できます。 メッセージを中断する能力は、複数のセッションがTCP接続を共有するのを許容するか、または同じ接続を共有する他のメッセージを妨げていない間に効率的に送られるべき大きいメッセージ、または同じMSRPセッションのためにさえそうします。 2048の八重奏より大きいどんな塊もinterruptibleであるに違いありません。 それぞれのMSRPセッションがそれ自身のTCP接続を使用するなら、MSRPは実装するのが、より簡単でしょうにが、接続を保存するやむにやまれない理由があります。 例えば、TCPは多くに接続するリレーデバイスが他の同輩であったかもしれないならじっと見ます。 各同輩が多くの接続を創造しないと、そのようなデバイスは、よりよく比例するでしょう。 (初期の塊が例のために上記の例では、interruptibleであったことに注意してください、サイズがinterruptibilityが必要である限界のかなり下にありますが。)
The chunking mechanism only applies to the SEND method, as it is the only method used to transfer message content.
分魂化メカニズムは、それがメッセージ内容を移すのに使用される唯一のメソッドであるので、SENDメソッドに適用されるだけです。
5.2. MSRP Addressing
5.2. MSRPアドレシング
MSRP entities are addressed using URIs. The MSRP URI schemes are defined in Section 6. The syntax of the To-Path and From-Path header fields each allows for a list of URIs. This was done to allow the protocol to work with relays, which are defined in a separate document, to provide a complete path to the end recipient. When two MSRP nodes communicate directly, they need only one URI in the To- Path list and one URI in the From-Path list.
MSRP実体は、URIを使用することで扱われます。 MSRP URI体系はセクション6で定義されます。 To-経路とFrom-経路ヘッダーフィールドの構文はそれぞれURIのリストを考慮します。 プロトコルが完全な経路を終わりの受取人に提供するために別々のドキュメントで定義されるリレーで働くのを許容するためにこれをしました。 2つのMSRPノードが直接伝達するとき、彼らはTo経路リストの1つのURIとFrom-経路リストの1つのURIだけを必要とします。
Campbell, et al. Standards Track [Page 10] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[10ページ]。
5.3. MSRP Transaction and Report Model
5.3. MSRPトランザクションとレポートモデル
A sender sends MSRP requests to a receiver. The receiver MUST quickly accept or reject the request. If the receiver initially accepted the request, it still may then do things that take significant time to succeed or fail. For example, if the receiver is an MSRP to Extensible Messaging and Presence Protocol (XMPP) [30] gateway, it may forward the message over XMPP. The XMPP side may later indicate that the request did not work. At this point, the MSRP receiver may need to indicate that the request did not succeed. There are two important concepts here: first, the hop-by-hop delivery of the request may succeed or fail; second, the end result of the request may or may not be successfully processed. The first type of status is referred to as "transaction status" and may be returned in response to a request. The second type of status is referred to as "delivery status" and may be returned in a REPORT transaction.
送付者は受信機への要求をMSRPに送ります。受信機は、すぐに要求を受け入れなければならないか、または拒絶しなければなりません。 受信機が初めは要請を受け入れたなら、それはまだ成功するか、または失敗する重要な時間を取るものにしているかもしれません。 例えば、受信機がExtensible MessagingへのMSRPとPresenceプロトコル(XMPP)[30]ゲートウェイであるなら、それはXMPPの上にメッセージを転送するかもしれません。 XMPP側は、後で要求が働かなかったのを示すかもしれません。 ここに、MSRP受信機は、要求が成功しなかったのを示す必要があるかもしれません。 2つの重要な概念がここにあります: まず最初に、ホップごとの要求の配送は、成功するか、または失敗するかもしれません。 2番目に、要求の結末は首尾よく処理されるかもしれません。 最初のタイプの状態は、「トランザクション状態」と呼ばれて、要求に対応して返されるかもしれません。 2番目のタイプの状態は、「配送状態」と呼ばれて、REPORTトランザクションで返されるかもしれません。
The original sender of a request can indicate if they wish to receive reports for requests that fail, and can independently indicate if they wish to receive reports for requests that succeed. A receiver only sends a success REPORT if it knows that the request was successfully delivered, and the sender requested a success report. A receiver only sends a failure REPORT if the request failed to be delivered and the sender requested failure reports.
要求の元の送り主は、失敗する要求のために彼らがレポートを受け取りたがっているかどうかを示すことができて、成功する要求のために彼らがレポートを受け取りたがっているかどうかを独自に示すことができます。 それが、要求が首尾よく提供されたのを知っている場合にだけ、受信機は成功REPORTを送ります、そして、送付者は成功レポートを要求しました。 要求が提供されないで、送付者が異常報告書を要求した場合にだけ、受信機は失敗REPORTを送ります。
This document describes the behavior of MSRP endpoints. MSRP
relays will introduce additional conditions that indicate a
failure REPORT should be sent, such as the failure to receive a
positive response from the next hop.
This document describes the behavior of MSRP endpoints. MSRP relays will introduce additional conditions that indicate a failure REPORT should be sent, such as the failure to receive a positive response from the next hop.
Two header fields control the sender's desire to receive reports. The Success-Report header field can have a value of "yes" or "no" and the Failure-Report header field can have a value of "yes", "no", or "partial".
Two header fields control the sender's desire to receive reports. The Success-Report header field can have a value of "yes" or "no" and the Failure-Report header field can have a value of "yes", "no", or "partial".
The combinations of reporting are needed to meet the various scenarios of currently deployed IM systems. Success-Report might be "no" in many public systems to reduce load, but might be "yes" in certain enterprise systems, such as systems used for securities trading. A Failure-Report value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a response explosion to the sender. A Failure-Report of "yes" is used by many systems that wish to notify the user if the message failed. A Failure-Report of "partial" is a way to report errors other than timeouts. Timeout error reporting requires the sending hop to run a timer and the receiving hop to send an
The combinations of reporting are needed to meet the various scenarios of currently deployed IM systems. Success-Report might be "no" in many public systems to reduce load, but might be "yes" in certain enterprise systems, such as systems used for securities trading. A Failure-Report value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a response explosion to the sender. A Failure-Report of "yes" is used by many systems that wish to notify the user if the message failed. A Failure-Report of "partial" is a way to report errors other than timeouts. Timeout error reporting requires the sending hop to run a timer and the receiving hop to send an
Campbell, et al. Standards Track [Page 11] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 11] RFC 4975 MSRP September 2007
acknowledgment to stop the timer. Some systems don't want the overhead of doing this. "Partial" allows them to choose not to do so, but still allows error responses to be sent in many cases.
acknowledgment to stop the timer. Some systems don't want the overhead of doing this. "Partial" allows them to choose not to do so, but still allows error responses to be sent in many cases.
The term "partial" denotes that the hop-by-hop acknowledgment
mechanism that would be required with a Failure-Report value of
"yes" is not invoked. Thus, each device uses only "part" of the
set of error detection tools available to them. This allows a
compromise between no reporting of failures at all, and reporting
every possible failure. For example, with "partial", a sending
device does not have to keep transaction state around waiting for
a positive acknowledgment. But it still allows devices to report
other types of errors. The receiving device could still report a
policy violation such as an unacceptable content-type, or an ICMP
error trying to connect to a downstream device.
The term "partial" denotes that the hop-by-hop acknowledgment mechanism that would be required with a Failure-Report value of "yes" is not invoked. Thus, each device uses only "part" of the set of error detection tools available to them. This allows a compromise between no reporting of failures at all, and reporting every possible failure. For example, with "partial", a sending device does not have to keep transaction state around waiting for a positive acknowledgment. But it still allows devices to report other types of errors. The receiving device could still report a policy violation such as an unacceptable content-type, or an ICMP error trying to connect to a downstream device.
5.4. MSRP Connection Model
5.4. MSRP Connection Model
When an MSRP endpoint wishes to send a request to a peer identified by an MSRP URI, it first needs a transport connection, with the appropriate security properties, to the host specified in the URI. If the sender already has such a connection, that is, one associated with the same host, port, and URI scheme, then it SHOULD reuse that connection.
When an MSRP endpoint wishes to send a request to a peer identified by an MSRP URI, it first needs a transport connection, with the appropriate security properties, to the host specified in the URI. If the sender already has such a connection, that is, one associated with the same host, port, and URI scheme, then it SHOULD reuse that connection.
When a new MSRP session is created, the initiating endpoint MUST act as the "active" endpoint, meaning that it is responsible for opening the transport connection to the answerer, if a new connection is required. However, this requirement MAY be weakened if standardized mechanisms for negotiating the connection direction become available and are implemented by both parties to the connection.
When a new MSRP session is created, the initiating endpoint MUST act as the "active" endpoint, meaning that it is responsible for opening the transport connection to the answerer, if a new connection is required. However, this requirement MAY be weakened if standardized mechanisms for negotiating the connection direction become available and are implemented by both parties to the connection.
Likewise, the active endpoint MUST immediately issue a SEND request. This initial SEND request MAY have a body if the sender has content to send, or it MAY have no body at all.
Likewise, the active endpoint MUST immediately issue a SEND request. This initial SEND request MAY have a body if the sender has content to send, or it MAY have no body at all.
The first SEND request serves to bind a connection to an MSRP
session from the perspective of the passive endpoint. If the
connection is not authenticated with TLS, and the active endpoint
did not send an immediate request, the passive endpoint would have
no way to determine who had connected, and would not be able to
safely send any requests towards the active party until after the
active party sends its first request.
The first SEND request serves to bind a connection to an MSRP session from the perspective of the passive endpoint. If the connection is not authenticated with TLS, and the active endpoint did not send an immediate request, the passive endpoint would have no way to determine who had connected, and would not be able to safely send any requests towards the active party until after the active party sends its first request.
When an element needs to form a new connection, it looks at the URI to decide on the type of connection (TLS, TCP, etc.) then connects to the host indicated by the URI, following the URI resolution rules in Section 6.2. Connections using the "msrps" scheme MUST use TLS. The
When an element needs to form a new connection, it looks at the URI to decide on the type of connection (TLS, TCP, etc.) then connects to the host indicated by the URI, following the URI resolution rules in Section 6.2. Connections using the "msrps" scheme MUST use TLS. The
Campbell, et al. Standards Track [Page 12] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 12] RFC 4975 MSRP September 2007
SubjectAltName in the received certificate MUST match the hostname part of the URI and the certificate MUST be valid according to RFC 3280 [16], including having a date that is valid and being signed by an acceptable certification authority. At this point, the device that initiated the connection can assume that this connection is with the correct host.
SubjectAltName in the received certificate MUST match the hostname part of the URI and the certificate MUST be valid according to RFC 3280 [16], including having a date that is valid and being signed by an acceptable certification authority. At this point, the device that initiated the connection can assume that this connection is with the correct host.
The rules on certificate name matching and CA signing MAY be relaxed when using TLS peer-to-peer. In this case, a mechanism to ensure that the peer used a correct certificate MUST be used. See Section 14.4 for details.
The rules on certificate name matching and CA signing MAY be relaxed when using TLS peer-to-peer. In this case, a mechanism to ensure that the peer used a correct certificate MUST be used. See Section 14.4 for details.
If the connection used mutual TLS authentication, and the TLS client presented a valid certificate, then the element accepting the connection can verify the identity of the connecting device by comparing the hostname part of the target URI in the SDP provided by the peer device against the SubjectAltName in the client certificate.
If the connection used mutual TLS authentication, and the TLS client presented a valid certificate, then the element accepting the connection can verify the identity of the connecting device by comparing the hostname part of the target URI in the SDP provided by the peer device against the SubjectAltName in the client certificate.
When mutual TLS authentication is not used, the listening device MUST wait until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description.
When mutual TLS authentication is not used, the listening device MUST wait until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description.
When the first request arrives, its To-Path header field should contain a URI that the listening element provided in the SDP for a session. The element that accepted the connection looks up the URI in the received request, and determines which session it matches. If a match exists, the node MUST assume that the host that formed the connection is the host to which this URI was given. If no match exists, the node MUST reject the request with a 481 response. The node MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response.
When the first request arrives, its To-Path header field should contain a URI that the listening element provided in the SDP for a session. The element that accepted the connection looks up the URI in the received request, and determines which session it matches. If a match exists, the node MUST assume that the host that formed the connection is the host to which this URI was given. If no match exists, the node MUST reject the request with a 481 response. The node MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response.
If it were legal to have multiple connections associated with the
same session, a security problem would exist. If the initial SEND
request is not protected, an eavesdropper might learn the URI, and
use it to insert messages into the session via a different
connection.
If it were legal to have multiple connections associated with the same session, a security problem would exist. If the initial SEND request is not protected, an eavesdropper might learn the URI, and use it to insert messages into the session via a different connection.
If a connection fails for any reason, then an MSRP endpoint MUST consider any sessions associated with the connection as also having failed. When either endpoint notices such a failure, it MAY attempt to re-create any such sessions. If it chooses to do so, it MUST use a new SDP exchange, for example, in a SIP re-INVITE. If a replacement session is successfully created, endpoints MAY attempt to resend any content for which delivery on the original session could not be confirmed. If it does this, the Message-ID values for the
If a connection fails for any reason, then an MSRP endpoint MUST consider any sessions associated with the connection as also having failed. When either endpoint notices such a failure, it MAY attempt to re-create any such sessions. If it chooses to do so, it MUST use a new SDP exchange, for example, in a SIP re-INVITE. If a replacement session is successfully created, endpoints MAY attempt to resend any content for which delivery on the original session could not be confirmed. If it does this, the Message-ID values for the
Campbell, et al. Standards Track [Page 13] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 13] RFC 4975 MSRP September 2007
resent messages MUST match those used in the initial attempts. If the receiving endpoint receives more than one message with the same Message-ID, it SHOULD assume that the messages are duplicates. The specific action that an endpoint takes when it receives a duplicate message is a matter of local policy, except that it SHOULD NOT present the duplicate messages to the user without warning of the duplication. Note that acknowledgments as needed based on the Failure-Report and Success-Report settings are still necessary even for requests containing duplicate content.
resent messages MUST match those used in the initial attempts. If the receiving endpoint receives more than one message with the same Message-ID, it SHOULD assume that the messages are duplicates. The specific action that an endpoint takes when it receives a duplicate message is a matter of local policy, except that it SHOULD NOT present the duplicate messages to the user without warning of the duplication. Note that acknowledgments as needed based on the Failure-Report and Success-Report settings are still necessary even for requests containing duplicate content.
When endpoints create a new session in this fashion, the chunks for a given logical message MAY be split across the sessions. However, endpoints SHOULD NOT split chunks between sessions under non-failure circumstances.
When endpoints create a new session in this fashion, the chunks for a given logical message MAY be split across the sessions. However, endpoints SHOULD NOT split chunks between sessions under non-failure circumstances.
If an endpoint attempts to re-create a failed session in this manner, it MUST NOT assume that the MSRP URIs in the SDP will be the same as the old ones.
If an endpoint attempts to re-create a failed session in this manner, it MUST NOT assume that the MSRP URIs in the SDP will be the same as the old ones.
A connection SHOULD NOT be closed while there are sessions associated with it.
A connection SHOULD NOT be closed while there are sessions associated with it.
6. MSRP URIs
6. MSRP URIs
URIs using the "msrp" and "msrps" schemes are used to identify a session of instant messages at a particular MSRP device, as well as to identify an MSRP relay in general. This document describes the former usage; the latter usage is described in the MSRP relay specification [23]. MSRP URIs that identify sessions are ephemeral; an MSRP device will use a different MSRP URI for each distinct session. An MSRP URI that identifies a session has no meaning outside the scope of that session.
URIs using the "msrp" and "msrps" schemes are used to identify a session of instant messages at a particular MSRP device, as well as to identify an MSRP relay in general. This document describes the former usage; the latter usage is described in the MSRP relay specification [23]. MSRP URIs that identify sessions are ephemeral; an MSRP device will use a different MSRP URI for each distinct session. An MSRP URI that identifies a session has no meaning outside the scope of that session.
An MSRP URI follows a subset of the URI syntax in Appendix A of RFC 3986 [10], with a scheme of "msrp" or "msrps". The syntax is described in Section 9.
An MSRP URI follows a subset of the URI syntax in Appendix A of RFC 3986 [10], with a scheme of "msrp" or "msrps". The syntax is described in Section 9.
MSRP URIs are primarily expected to be generated and exchanged between systems, and are not intended for "human consumption". Therefore, they are encoded entirely in US-ASCII.
MSRP URIs are primarily expected to be generated and exchanged between systems, and are not intended for "human consumption". Therefore, they are encoded entirely in US-ASCII.
The constructions for "authority", "userinfo", and "unreserved" are detailed in RFC 3986 [10]. URIs designating MSRP over TCP MUST include the "tcp" transport parameter.
The constructions for "authority", "userinfo", and "unreserved" are detailed in RFC 3986 [10]. URIs designating MSRP over TCP MUST include the "tcp" transport parameter.
Campbell, et al. Standards Track [Page 14] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 14] RFC 4975 MSRP September 2007
Since this document only specifies MSRP over TCP, all MSRP URIs
herein use the "tcp" transport parameter. Documents that provide
bindings on other transports should define respective parameters
for those transports.
Since this document only specifies MSRP over TCP, all MSRP URIs herein use the "tcp" transport parameter. Documents that provide bindings on other transports should define respective parameters for those transports.
The MSRP URI authority field identifies a participant in a particular MSRP session. If the authority field contains a numeric IP address, it MUST also contain a port. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device. A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the "authority" governing a namespace for the session-id.
The MSRP URI authority field identifies a participant in a particular MSRP session. If the authority field contains a numeric IP address, it MUST also contain a port. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device. A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the "authority" governing a namespace for the session-id.
A scheme of "msrps" indicates that the underlying connection MUST be protected with TLS.
A scheme of "msrps" indicates that the underlying connection MUST be protected with TLS.
MSRP has an IANA-registered recommended port defined in Section 15.4. This value is not a default, as the URI negotiation process described herein will always include explicit port numbers. However, the URIs SHOULD be configured so that the recommended port is used whenever appropriate. This makes life easier for network administrators who need to manage firewall policy for MSRP.
MSRP has an IANA-registered recommended port defined in Section 15.4. This value is not a default, as the URI negotiation process described herein will always include explicit port numbers. However, the URIs SHOULD be configured so that the recommended port is used whenever appropriate. This makes life easier for network administrators who need to manage firewall policy for MSRP.
The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. A userinfo part MUST NOT contain password information.
The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. A userinfo part MUST NOT contain password information.
The following is an example of a typical MSRP URI:
The following is an example of a typical MSRP URI:
msrp://host.example.com:8493/asfd34;tcp
msrp://host.example.com:8493/asfd34;tcp
6.1. MSRP URI Comparison
6.1. MSRP URI Comparison
In the context of the MSRP protocol, MSRP URI comparisons MUST be performed according to the following rules:
In the context of the MSRP protocol, MSRP URI comparisons MUST be performed according to the following rules:
1. The scheme MUST match. Scheme comparison is case insensitive.
1. The scheme MUST match. Scheme comparison is case insensitive.
2. If the authority component contains an explicit IP address and/or
port, these are compared for address and port equivalence.
Percent-encoding normalization [10] applies; that is, if any
percent-encoded nonreserved characters exist in the authority
component, they must be decoded prior to comparison. Userinfo
2. If the authority component contains an explicit IP address and/or port, these are compared for address and port equivalence. Percent-encoding normalization [10] applies; that is, if any percent-encoded nonreserved characters exist in the authority component, they must be decoded prior to comparison. Userinfo
Campbell, et al. Standards Track [Page 15] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 15] RFC 4975 MSRP September 2007
parts are not considered for URI comparison. Otherwise, the
authority component is compared as a case-insensitive character
string.
parts are not considered for URI comparison. Otherwise, the authority component is compared as a case-insensitive character string.
3. If the port exists explicitly in either URI, then it MUST match
exactly. A URI with an explicit port is never equivalent to
another with no port specified.
3. If the port exists explicitly in either URI, then it MUST match exactly. A URI with an explicit port is never equivalent to another with no port specified.
4. The session-id part is compared as case sensitive. A URI without
a session-id part is never equivalent to one that includes one.
4. The session-id part is compared as case sensitive. A URI without a session-id part is never equivalent to one that includes one.
5. URIs with different "transport" parameters never match. Two URIs
that are identical except for transport are not equivalent. The
transport parameter is case insensitive.
5. URIs with different "transport" parameters never match. Two URIs that are identical except for transport are not equivalent. The transport parameter is case insensitive.
Path normalization [10] is not relevant for MSRP URIs.
Path normalization [10] is not relevant for MSRP URIs.
6.2. Resolving MSRP Host Device
6.2. Resolving MSRP Host Device
An MSRP host device is identified by the authority component of an MSRP URI.
An MSRP host device is identified by the authority component of an MSRP URI.
If the authority component contains a numeric IP address and port, they MUST be used as listed.
If the authority component contains a numeric IP address and port, they MUST be used as listed.
If the authority component contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query and use the port as listed.
If the authority component contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query and use the port as listed.
If a connection attempt fails, the device SHOULD attempt to connect to the addresses returned in any additional A or AAAA records, in the order the records were presented.
If a connection attempt fails, the device SHOULD attempt to connect to the addresses returned in any additional A or AAAA records, in the order the records were presented.
This process assumes that the connection port is always known
prior to resolution. This is always true for the MSRP URI uses
described in this document, that is, URIs exchanged in the SDP
offer and answer. The introduction of relays creates situations
where this is not the case. For example, when a user configures
her client to use a relay, it is desirable that the relay's MSRP
URI is easy to remember and communicate to humans. Often this
type of MSRP will omit the port number. Therefore, the relay
specification [23] describes additional steps to resolve the port
number.
This process assumes that the connection port is always known prior to resolution. This is always true for the MSRP URI uses described in this document, that is, URIs exchanged in the SDP offer and answer. The introduction of relays creates situations where this is not the case. For example, when a user configures her client to use a relay, it is desirable that the relay's MSRP URI is easy to remember and communicate to humans. Often this type of MSRP will omit the port number. Therefore, the relay specification [23] describes additional steps to resolve the port number.
MSRP devices MAY use other methods for discovering other such devices, when appropriate. For example, MSRP endpoints may use other mechanisms to discover relays, which are beyond the scope of this document.
MSRP devices MAY use other methods for discovering other such devices, when appropriate. For example, MSRP endpoints may use other mechanisms to discover relays, which are beyond the scope of this document.
Campbell, et al. Standards Track [Page 16] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 16] RFC 4975 MSRP September 2007
7. Method-Specific Behavior
7. Method-Specific Behavior
7.1. Constructing Requests
7.1. Constructing Requests
To form a new request, the sender creates a transaction identifier and uses this and the method name to create an MSRP request start line. The transaction identifier MUST NOT collide with that of other transactions that exist at the same time. Therefore, it MUST contain at least 64 bits of randomness.
To form a new request, the sender creates a transaction identifier and uses this and the method name to create an MSRP request start line. The transaction identifier MUST NOT collide with that of other transactions that exist at the same time. Therefore, it MUST contain at least 64 bits of randomness.
Next, the sender places the target path in a To-Path header field, and the sender's URI in a From-Path header field. If multiple URIs are present in the To-Path, the leftmost is the first URI visited; the rightmost URI is the last URI visited. The processing then becomes method specific. Additional method-specific header fields are added as described in the following sections.
Next, the sender places the target path in a To-Path header field, and the sender's URI in a From-Path header field. If multiple URIs are present in the To-Path, the leftmost is the first URI visited; the rightmost URI is the last URI visited. The processing then becomes method specific. Additional method-specific header fields are added as described in the following sections.
After any method-specific header fields are added, processing continues to handle a body, if present. If the request has a body, it MUST contain a Content-Type header field. It may contain other MIME-specific header fields. The Content-Type header field MUST be the last field in the message header section. The body MUST be separated from the header fields with an extra CRLF.
After any method-specific header fields are added, processing continues to handle a body, if present. If the request has a body, it MUST contain a Content-Type header field. It may contain other MIME-specific header fields. The Content-Type header field MUST be the last field in the message header section. The body MUST be separated from the header fields with an extra CRLF.
Non-SEND requests are not intended to carry message content, and are therefore not interruptible. Non-SEND request bodies MUST NOT be larger than 10240 octets.
Non-SEND requests are not intended to carry message content, and are therefore not interruptible. Non-SEND request bodies MUST NOT be larger than 10240 octets.
Although this document does not discuss any particular usage of
bodies in non-SEND requests, they may be useful in the future for
carrying security or identity information, information about a
message in progress, etc. The 10K size limit was chosen to be
large enough for most of such applications, but small enough to
avoid the fairness issues caused by sending arbitrarily large
content in non-interruptible method bodies.
Although this document does not discuss any particular usage of bodies in non-SEND requests, they may be useful in the future for carrying security or identity information, information about a message in progress, etc. The 10K size limit was chosen to be large enough for most of such applications, but small enough to avoid the fairness issues caused by sending arbitrarily large content in non-interruptible method bodies.
A request with no body MUST NOT include a Content-Type or any other MIME-specific header fields. A request without a body MUST contain an end-line after the final header field. No extra CRLF will be present between the header section and the end-line.
A request with no body MUST NOT include a Content-Type or any other MIME-specific header fields. A request without a body MUST contain an end-line after the final header field. No extra CRLF will be present between the header section and the end-line.
Requests with no bodies are useful when a client wishes to send
"traffic", but does not wish to send content to be rendered to the
peer user. For example, the active endpoint sends a SEND request
immediately upon establishing a connection. If it has nothing to
say at the moment, it can send a request with no body. Bodiless
requests may also be used in certain applications to keep Network
Address Translation (NAT) bindings alive, etc.
Requests with no bodies are useful when a client wishes to send "traffic", but does not wish to send content to be rendered to the peer user. For example, the active endpoint sends a SEND request immediately upon establishing a connection. If it has nothing to say at the moment, it can send a request with no body. Bodiless requests may also be used in certain applications to keep Network Address Translation (NAT) bindings alive, etc.
Campbell, et al. Standards Track [Page 17] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 17] RFC 4975 MSRP September 2007
Bodiless requests are distinct from requests with empty bodies. A
request with an empty body will have a Content-Type header field
value and will generally be rendered to the recipient according to
the rules for that type.
Bodiless requests are distinct from requests with empty bodies. A request with an empty body will have a Content-Type header field value and will generally be rendered to the recipient according to the rules for that type.
The end-line that terminates the request MUST be composed of seven "-" (minus sign) characters, the transaction ID as used in the start line, and a flag character. If a body is present, the end-line MUST be preceded by a CRLF that is not part of the body. If the chunk represents the data that forms the end of the complete message, the flag value MUST be a "$". If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a "#". Otherwise, the flag MUST be a "+".
The end-line that terminates the request MUST be composed of seven "-" (minus sign) characters, the transaction ID as used in the start line, and a flag character. If a body is present, the end-line MUST be preceded by a CRLF that is not part of the body. If the chunk represents the data that forms the end of the complete message, the flag value MUST be a "$". If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a "#". Otherwise, the flag MUST be a "+".
If the request contains a body, the sender MUST ensure that the end- line (seven hyphens, the transaction identifier, and a continuation flag) is not present in the body. If the end-line is present in the body, the sender MUST choose a new transaction identifier that is not present in the body, and add a CRLF if needed, and the end-line, including the "$", "#", or "+" character.
If the request contains a body, the sender MUST ensure that the end- line (seven hyphens, the transaction identifier, and a continuation flag) is not present in the body. If the end-line is present in the body, the sender MUST choose a new transaction identifier that is not present in the body, and add a CRLF if needed, and the end-line, including the "$", "#", or "+" character.
Some implementations may choose to scan for the closing sequence as they send the body, and if it is encountered, simply interrupt the chunk at that point and start a new transaction with a different transaction identifier to carry the rest of the body. Other implementations may choose to scan the data and ensure that the body does not contain the transaction identifier before they start sending the transaction.
Some implementations may choose to scan for the closing sequence as they send the body, and if it is encountered, simply interrupt the chunk at that point and start a new transaction with a different transaction identifier to carry the rest of the body. Other implementations may choose to scan the data and ensure that the body does not contain the transaction identifier before they start sending the transaction.
Once a request is ready for delivery, the sender follows the connection management (Section 5.4) rules to forward the request over an existing open connection or create a new connection.
Once a request is ready for delivery, the sender follows the connection management (Section 5.4) rules to forward the request over an existing open connection or create a new connection.
7.1.1. Sending SEND Requests
7.1.1. Sending SEND Requests
When an endpoint has a message to deliver, it first generates a new Message-ID. The value MUST be highly unlikely to be repeated by another endpoint instance, or by the same instance in the future. If necessary, the endpoint breaks the message into chunks. It then generates a SEND request for each chunk, following the procedures for constructing requests (Section 7.1).
When an endpoint has a message to deliver, it first generates a new Message-ID. The value MUST be highly unlikely to be repeated by another endpoint instance, or by the same instance in the future. If necessary, the endpoint breaks the message into chunks. It then generates a SEND request for each chunk, following the procedures for constructing requests (Section 7.1).
The Message-ID header field provides a unique message identifier
that refers to a particular version of a particular message. The
term "Message" in this context refers to a unit of content that
the sender wishes to convey to the recipient. While such a
message may be broken into chunks, the Message-ID refers to the
entire message, not a chunk of the message.
The Message-ID header field provides a unique message identifier that refers to a particular version of a particular message. The term "Message" in this context refers to a unit of content that the sender wishes to convey to the recipient. While such a message may be broken into chunks, the Message-ID refers to the entire message, not a chunk of the message.
Campbell, et al. Standards Track [Page 18] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 18] RFC 4975 MSRP September 2007
The uniqueness of the message identifier is ensured by the host
that generates it. This message identifier is intended to be
machine readable and not necessarily meaningful to humans. A
message identifier pertains to exactly one version of a particular
message; subsequent revisions to the message each receive new
message identifiers. Endpoints can ensure sufficient uniqueness
in any number of ways, the selection of which is an implementation
choice. For example, an endpoint could concatenate an instance
identifier such as a MAC address, its idea of the number of
seconds since the epoch, a process ID, and a monotonically
increasing 16-bit integer, all base-64 encoded. Alternately, an
endpoint without an on-board clock could simply use a 64-bit
random number.
The uniqueness of the message identifier is ensured by the host that generates it. This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one version of a particular message; subsequent revisions to the message each receive new message identifiers. Endpoints can ensure sufficient uniqueness in any number of ways, the selection of which is an implementation choice. For example, an endpoint could concatenate an instance identifier such as a MAC address, its idea of the number of seconds since the epoch, a process ID, and a monotonically increasing 16-bit integer, all base-64 encoded. Alternately, an endpoint without an on-board clock could simply use a 64-bit random number.
Each chunk of a message MUST contain a Message-ID header field containing the Message-ID. If the sender wishes non-default status reporting, it MUST insert a Failure-Report and/or Success-Report header field with an appropriate value. All chunks of the same message MUST use the same Failure-Report and Success-Report values in their SEND requests.
Each chunk of a message MUST contain a Message-ID header field containing the Message-ID. If the sender wishes non-default status reporting, it MUST insert a Failure-Report and/or Success-Report header field with an appropriate value. All chunks of the same message MUST use the same Failure-Report and Success-Report values in their SEND requests.
If success reports are requested, i.e., the value of the Success- Report header field is "yes", the sending device MAY wish to run a timer of some value that makes sense for its application and take action if a success report is not received in this time. There is no universal value for this timer. For many IM applications, it may be 2 minutes while for some trading systems it may be under a second. Regardless of whether such a timer is used, if the success report has not been received by the time the session is ended, the device SHOULD inform the user.
If success reports are requested, i.e., the value of the Success- Report header field is "yes", the sending device MAY wish to run a timer of some value that makes sense for its application and take action if a success report is not received in this time. There is no universal value for this timer. For many IM applications, it may be 2 minutes while for some trading systems it may be under a second. Regardless of whether such a timer is used, if the success report has not been received by the time the session is ended, the device SHOULD inform the user.
If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. Regardless of the Failure-Report value, there is no requirement to wait for a response prior to sending the next request.
If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. Regardless of the Failure-Report value, there is no requirement to wait for a response prior to sending the next request.
The treatment of timers for success reports and failure reports is
intentionally inconsistent. An explicit timeout value makes sense
for failure reports since such reports will usually refer to a
message "chunk" that is acknowledged on a hop-by-hop basis. This
The treatment of timers for success reports and failure reports is intentionally inconsistent. An explicit timeout value makes sense for failure reports since such reports will usually refer to a message "chunk" that is acknowledged on a hop-by-hop basis. This
Campbell, et al. Standards Track [Page 19] RFC 4975 MSRP September 2007
Campbell, et al. Standards Track [Page 19] RFC 4975 MSRP September 2007
is not the case for success reports, which are end-to-end and may
refer to the entire message content, which can be arbitrarily
large.
is not the case for success reports, which are end-to-end and may refer to the entire message content, which can be arbitrarily large.
If no Success-Report header field is present in a SEND request, it MUST be treated the same as a Success-Report header field with a value of "no". If no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes". If an MSRP endpoint receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
If no Success-Report header field is present in a SEND request, it MUST be treated the same as a Success-Report header field with a value of "no". If no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes". If an MSRP endpoint receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
The Byte-Range header field value contains a starting value (range- start) followed by a "-", an ending value (range-end) followed by a "/", and finally the total length. The first octet in the message has a position of one, rather than a zero.
The Byte-Range header field value contains a starting value (range- start) followed by a "-", an ending value (range-end) followed by a "/", and finally the total length. The first octet in the message has a position of one, rather than a zero.
The first chunk of the message SHOULD, and all subsequent chunks MUST, include a Byte-Range header field. The range-start field MUST indicate the position of the first byte in the body in the overall message (for the first chunk this field will have a value of one). The range-end field SHOULD indicate the position of the last byte in the body, if known. It MUST take the value of "*" if the position is unknown, or if the request needs to be interruptible. The total field SHOULD contain the total size of the message, if known. The total field MAY contain a "*" if the total size of the message is not known in advance. The sender MUST send all chunks in Byte-Range order. (However, the receiver cannot assume that the requests will be delivered in order, as intervening relays may have changed the order.)
The first chunk of the message SHOULD, and all subsequent chunks MUST, include a Byte-Range header field. The range-start field MUST indicate the position of the first byte in the body in the overall message (for the first chunk this field will have a value of one). The range-end field SHOULD indicate the position of the last byte in the body, if known. It MUST take the value of "*" if the position is unknown, or if the request needs to be interruptible. The total field SHOULD contain the total size of the message, if known. The total field MAY contain a "*" if the total size of the message is not known in advance. The sender MUST send all chunks in Byte-Range order. (However, the receiver cannot assume that the requests will be delivered in order, as intervening relays may have changed the order.)
There are some circumstances where an endpoint may choose to send an empty SEND request. For the sake of consistency, a Byte-Range header field referring to nonexistent or zero-length content MUST still have a range-start value of 1. For example, "1-0/0".
いくつかの事情が終点が空のSEND要求を送るのを選ぶかもしれないところにあります。 一貫性のために、実在しないか無長さの内容を示すByte-範囲ヘッダーフィールドはまだ1の範囲スタート値を持たなければなりません。 例えば、「1-0/0インチ。」
To ensure fairness over a connection, senders MUST NOT send chunks with a body larger than 2048 octets unless they are prepared to interrupt them (meaning that any chunk with a body of greater than 2048 octets will have a "*" character in the range-end field). A sender can use one of the following two strategies to satisfy this requirement. The sender is STRONGLY RECOMMENDED to send messages larger than 2048 octets using as few chunks as possible, interrupting chunks (at least 2048 octets long) only when other traffic is waiting to use the same connection. Alternatively, the sender MAY simply send chunks in 2048-octet increments until the final chunk. Note that the former strategy results in markedly more efficient use of the connection. All MSRP nodes MUST be able to receive chunks of any size from zero octets to the maximum number of octets they can
接続の上で公正を確実にするために、それらがそれらを中断するように準備されない場合(2048以上の八重奏のボディーがあるどんな塊にも「*」キャラクタが範囲端の分野にあることを意味して)、ボディーが2048の八重奏より大きい状態で送付者は塊を送ってはいけません。 送付者は、この要件を満たすのに以下の2つの戦略の1つを使用できます。 送付者はできるだけわずかな塊しか使用しないことで2048の八重奏より大きいメッセージを送るSTRONGLY RECOMMENDEDです、他のトラフィックが、同じ接続を使用するのを待っているときだけ、塊(少なくとも2048八重奏長さ)を中断して。 あるいはまた、送付者は最終的な塊まで単に2048八重奏の増分における塊を送るかもしれません。 前の戦略が接続の著しく効率的な使用をもたらすことに注意してください。 すべてのMSRPノードが八重奏がないのからそれらがそうすることができる八重奏の最大数までどんなサイズの塊も受けることができなければなりません。
Campbell, et al. Standards Track [Page 20] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[20ページ]。
receive for a complete message. Senders SHOULD NOT break messages into chunks smaller than 2048 octets, except for the final chunk of a complete message.
完全なメッセージには、受信してください。 送付者SHOULD NOTはメッセージを完全なメッセージの最終的な塊以外の2048の八重奏より小さい塊に細かく分けます。
A SEND request is interrupted while a body is in the process of being written to the connection by simply noting how much of the message has already been written to the connection, then writing out the end- line to end the chunk. It can then be resumed in a another chunk with the same Message-ID and a Byte-Range header field range start field containing the position of the first byte after the interruption occurred.
メッセージのどのくらいが既に接続に書かれているかに単に注意することによって接続に書かれていることの途中にボディーがある間、SEND要求は中断されます、次に、塊を終わらせるために終わりの台詞を書き上げて。 そして、中断が発生した後に最初のバイトの位置を含む同じMessage-IDがある別の塊とByte-範囲ヘッダーフィールド範囲スタート分野でそれを再開できます。
SEND requests larger than 2048 octets MUST be interrupted if the sender needs to send pending responses or REPORT requests. If multiple SEND requests from different sessions are concurrently being sent over the same connection, the device SHOULD implement some scheme to alternate between them such that each concurrent request gets a chance to send some fair portion of data at regular intervals suitable to the application.
送付者が、未定の応答かREPORT要求を送る必要があるなら、2048の八重奏より大きいSEND要求を中断しなければなりません。 同時に異なったセッションからの複数のSEND要求を同じ接続の上に送るなら、デバイスSHOULDがそれらの間を行き来するために何らかの体系を実装するので、各同時要求はデータの何らかの公正な部分を送る機会をアプリケーションに一定の間隔を置いて適させます。
The sender MUST NOT assume that a message is received by the peer with the same chunk allocation with which it was sent. An intervening relay could possibly break SEND requests into smaller chunks, or aggregate multiple chunks into larger ones.
送付者は、メッセージがそれが送られたのと同じ塊配分で同輩によって受け取られると仮定してはいけません。 介入しているリレーは、ことによるとSEND要求をより小さい塊に始めるか、または、より大きいものへの複数の塊に集められることができました。
The default disposition of messages is to be rendered to the user. If the sender wants a different disposition, it MAY insert a Content- Disposition [9] header field. Values MAY include any from RFC 2183 [9] or the IANA registry it defines. Since MSRP can carry unencoded binary payloads, transfer encoding is always "binary", and transfer- encoding parameters MUST NOT be present.
メッセージのデフォルト気質はユーザに提供することです。 送付者が異なった気質が欲しいなら、それはContent気質[9]ヘッダーフィールドを挿入するかもしれません。 値はRFC2183[9]かそれが定義するIANA登録からのいずれも含むかもしれません。 MSRPが暗号化されていない2進のペイロードを運ぶことができるので、転送コード化はいつも「2進です」、そして、パラメタをコード化する転送は存在しているはずがありません。
7.1.2. Sending REPORT Requests
7.1.2. 送付レポート要求
REPORT requests are similar to SEND requests, except that report requests MUST NOT include Success-Report or Failure-Report header fields, and MUST contain a Status header field. REPORT requests MUST contain the Message-ID header field from the original SEND request.
REPORT要求はSEND要求と同様です、レポート要求がSuccess-レポートかFailure-レポートヘッダーフィールドを含んではいけなくて、Statusヘッダーフィールドを含まなければならないのを除いて。 REPORT要求はオリジナルのSEND要求からのMessage-IDヘッダーフィールドを含まなければなりません。
If an MSRP element receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
MSRP要素はそれが認識しないMessage-IDのためにREPORTを受けて、それはSHOULDです。静かにREPORTを無視してください。
An MSRP endpoint MUST be able to generate success REPORT requests.
MSRP終点は、成功がREPORT要求であると生成することができなければなりません。
REPORT requests will normally not include a body, as the REPORT request header fields can carry sufficient information in most cases. However, REPORT requests MAY include a body containing additional information about the status of the associated SEND request. Such a
通常、REPORT要求はボディーを含まないでしょう、REPORTが、多くの場合、ヘッダーフィールドが十分な情報を運ぶことができるよう要求するとき。 しかしながら、REPORT要求は関連SEND要求の状態に関する追加情報を含むボディーを含むかもしれません。 そのようなa
Campbell, et al. Standards Track [Page 21] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[21ページ]。
body is informational only, and the sender of the REPORT request SHOULD NOT assume that the recipient pays any attention to the body. REPORT requests are not interruptible.
ボディーが情報である、単に、そして、受取人がボディーに少しも注意を向けるというSHOULD NOTが仮定するREPORT要求の送付者。 REPORT要求はinterruptibleではありません。
Success-Report and Failure-Report header fields MUST NOT be present in REPORT requests. MSRP nodes MUST NOT send REPORT requests in response to REPORT requests. MSRP nodes MUST NOT send MSRP responses to REPORT requests.
成功レポートとFailure-レポートヘッダーフィールドはREPORT要求に存在しているはずがありません。 MSRPノードはREPORT要求に対応して要求をREPORTに送ってはいけません。 MSRPノードはREPORT要求への応答をMSRPに送ってはいけません。
Endpoints SHOULD NOT send REPORT requests if they have reason to believe the request will not be delivered. For example, they SHOULD NOT send a REPORT request for a session that is no longer valid.
それらに要求が提供されないと信じる理由があるなら、終点SHOULD NOTは要求をREPORTに送ります。 例えば、それら、SHOULD NOTはもう有効でないセッションを求めるREPORT要求を送ります。
7.1.3. Generating Success Reports
7.1.3. 成功がレポートであると生成します。
When an endpoint receives a message in one or more chunks that contain a Success-Report value of "yes", it MUST send a success report or reports covering all bytes that are received successfully. The success reports are sent in the form of REPORT requests, following the normal procedures (Section 7.1), with a few additional requirements.
終点が「はい」のSuccess-レポート値を含む1つ以上の塊におけるメッセージを受け取るとき、それで、成功レポートかレポートが首尾よく受け取られるすべてのバイトをカバーしなければなりません。 REPORT要求の形で成功レポートを送ります、正常な手順(セクション7.1)に従って、いくつかの追加要件で。
The receiver MAY wait until it receives the last chunk of a message, and send a success report that covers the complete message. Alternately, it MAY generate incremental success REPORTs as the chunks are received. These can be sent periodically and cover all the bytes that have been received so far, or they can be sent after a chunk arrives and cover just the part from that chunk.
受信機は、メッセージの最後の塊を受けるまで待っていて、完全なメッセージをカバーする成功レポートを送るかもしれません。 交互に、塊が受け取られているとき、それは、増加の成功がREPORTsであると生成するかもしれません。 これらが定期的に送られて、今までのところ受け取られたすべてのバイトをカバーできるか、それらは、塊が到着した後に送られて、その塊からまさしく部分をカバーできます。
It is helpful to think of a success REPORT as reporting on a
particular range of bytes, rather than on a particular chunk sent
by a client. The sending client cannot depend on the Byte-Range
header field in a given success report matching that of a
particular SEND request. For example, an intervening MSRP relay
may break chunks into smaller chunks, or aggregate multiple chunks
into larger ones. A side effect of this is, even if no relay is
used, the receiving client may report on byte ranges that do not
exactly match those in the original chunks sent by the sender. It
can wait until all bytes in a message are received and report on
the whole, it can report as it receives each chunk, or it can
report on any other received range. Reporting on ranges smaller
than the entire message contents allows certain improved user
experiences for the sender. For example, a sending client could
display incremental status information showing which ranges of
bytes have been acknowledged by the receiver. However, the choice
on whether to report incrementally is entirely up to the receiving
client. There is no mechanism for the sender to assert its desire
to receive incremental reports or not. Since the presence of a
特定の塊でというよりむしろ特定の範囲のバイトに関して報告するとしてのREPORTがクライアントで送った成功を考えるのは役立っています。 送付クライアントは、特定のSEND要求のものを合わせながら、与えられた成功レポートでByte-範囲ヘッダーフィールドに依存できません。 例えば、介入しているMSRPリレーは、塊をより小さい塊に細かく分けるか、または、より大きいものへの複数の塊に集められるかもしれません。 この副作用はそうです、どんなリレーも使用されていません、と受信クライアントはまさに送付者によって送られたオリジナルの塊におけるものに合っていないバイト範囲に関して報告するかもしれません。 メッセージのすべてのバイトが受け取られているまで待っていて、概して報告できます、と各塊を受けるとき、報告できますか、またはそれはいかなる他の容認された範囲に関しても報告できます。 全体のメッセージコンテンツが、ある改良されたユーザー・エクスペリエンスを許容するより小さい範囲に関して、送付者のために、報告します。 例えば、送付クライアントはどの範囲のバイトが受信機によって承認されたかを示す増加の状態情報を表示できました。しかしながら、報告するかどうかに関する選択は増加して完全な受信クライアント次第です。 送付者が増加のレポートを受け取る願望について断言するように、メカニズムは全くありません。 aの存在以来
Campbell, et al. Standards Track [Page 22] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[22ページ]。
relay can cause the receiver to see a very different chunk
allocation than the sender, such a mechanism would be of
questionable value.
受信機はリレーで非常に送付者と異なった塊配分を見ることができて、そのようなメカニズムには疑わしい価値があるでしょう。
When generating a REPORT request, the endpoint inserts a To-Path header field containing the From-Path value from the original request, and a From-Path header field containing the URI identifying itself in the session. The endpoint then inserts a Status header field with a namespace of "000", a status-code of "200", and an implementation-defined comment phrase. It also inserts a Message-ID header field containing the value from the original request.
REPORT要求を生成するとき、終点はオリジナルの要求、およびセッションのときにそれ自体を特定するURIを含むFrom-経路ヘッダーフィールドからFrom-経路値を含むTo-経路ヘッダーフィールドを挿入します。 そして、終点は「0インチ、「200」のステータスコード、および実装で定義されたコメント句」の名前空間でStatusヘッダーフィールドを挿入します。 また、それはオリジナルの要求から値を含むMessage-IDヘッダーフィールドを挿入します。
The namespace field denotes the context of the status-code field.
The namespace value of "000" means the status-code should be
interpreted in the same way as the matching MSRP transaction
response code. If a future specification uses the status-code
field for some other purpose, it MUST define a new namespace field
value.
名前空間分野はステータスコード分野の文脈を指示します。 「0インチは、合っているMSRPトランザクション応答コードと同様に、ステータスコードが解釈されるべきであることを意味する」名前空間値。 将来の仕様がある他の目的にステータスコード分野を使用するなら、それは新しい名前空間分野価値を定義しなければなりません。
The endpoint MUST NOT send a success report for a SEND request that either contained no Success-Report header field or contained such a field with a value of "no". That is, if no Success-Report header field is present, it is treated identically to one with a value of "no".
終点はどちらかがSuccess-レポートヘッダーフィールドを全く含まなかったか、または「いいえ」の値があるそのような分野を含んだというSEND要求のための成功レポートを送ってはいけません。 すなわち、どんなSuccess-レポートヘッダーフィールドも存在していないなら、それは同様に「いいえ」の値で1つに扱われます。
7.1.4. Generating Failure Reports
7.1.4. 失敗がレポートであると生成します。
If an MSRP endpoint receives a SEND request that it cannot process for some reason, and the Failure-Report header field either was not present in the original request or had a value of "yes", it SHOULD simply include the appropriate error code in the transaction response. However, there may be situations where the error cannot be determined quickly, such as when the endpoint is a gateway that waits for a downstream network to indicate an error. In this situation, it MAY send a 200 OK response to the request, and then send a failure REPORT request when the error is detected.
MSRP終点がSEND要求を受け取るなら、ある理由で処理できないで、Failure-レポートヘッダーフィールドには、オリジナルの要求に存在していなかったか、または「はい」の値があって、それがSHOULDであることはトランザクション応答に単に適切なエラーコードを含んでいます。 しかしながら、状況が誤りがすぐに決定できないところにあるかもしれません、終点が川下のネットワークが誤りを示すのを待つゲートウェイである時のように。 この状況で、誤りが検出されるとき、それは、200OK応答を要求に送って、次に、REPORTが要求する失敗を送るかもしれません。
If the endpoint receives a SEND request with a Failure-Report header field value of "no", then it MUST NOT send a failure REPORT request, and MUST NOT send a transaction response. If the value is "partial", it MUST NOT send a 200 transaction response to the request, but SHOULD send an appropriate non-200 class response if a failure occurs.
終点が「いいえ」のFailure-レポートヘッダーフィールド価値でSEND要求を受け取るなら、それはREPORTが要求して、送ってはいけない失敗にトランザクション応答を送ってはいけません。 値が「部分的である」なら、それは200トランザクション応答を要求に送ってはいけませんが、失敗が起こるなら、SHOULDは適切な非200クラス応答を送ります。
As stated above, if no Failure-Report header field is present, it MUST be treated the same as a Failure-Report header field with a value of "yes".
ヘッダーフィールドがFailure-レポートでないなら上に述べられているように存在している、同じように「はい」の値があるFailure-レポートヘッダーフィールドとしてそれを扱わなければなりません。
Campbell, et al. Standards Track [Page 23] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[23ページ]。
Construction of failure REPORT requests is identical to that for success REPORT requests, except the Status header field code field MUST contain the appropriate error code. Any error response code defined in this specification MAY also be used in failure reports.
REPORTがStatusヘッダーフィールドコード分野を除いて、成功REPORT要求にそれと同じであるよう要求する失敗の工事は適切なエラーコードを含まなければなりません。 また、この仕様に基づき定義されたどんな誤り応答コードも異常報告書で使用されるかもしれません。
If a failure REPORT request is sent in response to a SEND request that contained a chunk, it MUST include a Byte-Range header field indicating the actual range being reported on. It can take the range-start and total values from the original SEND request, but MUST calculate the range-end field from the actual body data.
塊を含んだSEND要求に対応してREPORTが要求する失敗を送るなら、それはオンであると報告される実際の範囲を示すByte-範囲ヘッダーフィールドを含まなければなりません。 それが範囲始めを取ることができて、オリジナルのSENDからの総価格は、実際のボディーデータからの範囲端の分野について要求しますが、計算しなければなりません。
This section only describes failure report generation behavior for
MSRP endpoints. Relay behavior is beyond the scope of this
document, and will be considered in a separate document [23]. We
expect failure reports to be more commonly generated by relays
than by endpoints.
このセクションはMSRP終点のための失敗レポート作成の振舞いについて説明するだけです。 リレーの振舞いは、このドキュメントの範囲を超えていて、別々のドキュメント[23]で考えられるでしょう。 私たちは、終点より異常報告書がリレーでさらに一般的に作られると予想します。
7.2. Constructing Responses
7.2. 応答を構成します。
If an MSRP endpoint receives a request that either contains a Failure-Report header field value of "yes" or does not contain a Failure-Report header field at all, it MUST immediately generate a response. Likewise, if an MSRP endpoint receives a request that contains a Failure-Report header field value of "partial", and the receiver is unable to process the request, it SHOULD immediately generate a response.
MSRP終点がどちらも「はい」のFailure-レポートヘッダーフィールド価値を含んでいるか、または全くFailure-レポートヘッダーフィールドを含んでいないという要求を受け取るなら、それはすぐに、応答を生成しなければなりません。 MSRP終点が要求を受け取るなら、同様に、それは「部分的」のFailure-レポートヘッダーフィールド価値を含んでいます、そして、受信機は要求を処理できません、それ。SHOULDはすぐに、応答を生成します。
To construct the response, the endpoint first creates the response start line, inserting the appropriate response code and optionally a comment. The transaction identifier in the response start line MUST match the transaction identifier from the original request.
適切な応答コードを挿入して、応答を構成するために、終点は最初に応答スタート系列を作成します、そして、任意に、aはコメントします。 応答スタート系列におけるトランザクション識別子はオリジナルの要求からトランザクション識別子に合わなければなりません。
The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the first (leftmost) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by copying the list of URIs from the From-Path of the original request into the To- Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above; however, we expect that extensions for gateways and relays will need such behavior.)
そして、終点は適切なTo-経路ヘッダーフィールドを挿入します。 応答の引き金となった要求がSEND要求であったなら、To-経路ヘッダーフィールドは、要求のFrom-経路ヘッダーフィールドにおける最初(一番左)のURIをコピーすることによって、形成されます。 (SEND要求への応答を前のホップだけに返します。) 他のすべての要求メソッドへの応答のために、To-経路ヘッダーフィールドは元の送り主へのフルパスの後部を含んでいます。 このフルパスは、オリジナルの要求のFrom-経路から応答のTo経路にURIのリストをコピーすることによって、生成されます。 (したがって、この仕様は上で説明された振舞いを運動させません; しかしながら、法的なREPORT要求は応答を要求しないで、私たちは、ゲートウェイとリレーのための拡張子がそのような振舞いを必要とすると予想します。)
Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. Since a response is never
最終的に、終点は最後のヘッダーフィールドの後のEND行があとに続いたセッションの文脈でそれを特定するURIを含むFrom-経路ヘッダーフィールドを挿入します。 応答が決してそうでないので
Campbell, et al. Standards Track [Page 24] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[24ページ]。
chunked, the continuation flag in the end-line will always contain a
dollar sign ("$"). The response MUST be transmitted back on the same
connection on which the original request arrived.
chunkedされていて、END行における継続旗はいつもドル記号(「$」)を含むでしょう。 オリジナルの要求が到着したのと同じ接続のときに応答を伝えなければなりません。
7.3. Receiving Requests
7.3. 要求を受け取ります。
The receiving endpoint MUST first check the URI in the To-Path to make sure the request belongs to an existing session. When the request is received, the To-Path will have exactly one URI, which MUST map to an existing session that is associated with the connection on which the request arrived. If this is not true, then the receiver MUST generate a 481 error and ignore the request. Note that if the Failure-Report header field had a value of "no", then no error report would be sent.
受信終点は、最初に、要求が既存のセッションに属するのを確実にするためにTo-経路でURIをチェックしなければなりません。 要求が受信されているとき、To-経路には、まさに1つのURIがあって、どれが既存のセッションまでそれを写像しなければならないかは、要求が到着した接続に関連しています。 これが本当でないなら、受信機は、481誤りを生成して、要求を無視しなければなりません。 Failure-レポートヘッダーフィールドに「いいえ」の値があるならエラー・レポートが全く送られないことに注意してください。
Further request processing by the receiver is method specific.
受信機による処理がメソッド特有であるようさらに要求してください。
7.3.1. Receiving SEND Requests
7.3.1. 受信して、要求を送ってください。
When the receiving endpoint receives a SEND request, it first determines if it contains a complete message or a chunk from a larger message. If the request contains no Byte-Range header field, or contains one with a range-start value of "1", and the closing line continuation flag has a value of "$", then the request contained the entire message. Otherwise, the receiver looks at the Message-ID value to associate chunks together into the original message. The receiver forms a virtual buffer to receive the message, keeping track of which bytes have been received and which are missing. The receiver takes the data from the request and places it in the appropriate place in the buffer. The receiver SHOULD determine the actual length of each chunk by inspecting the payload itself; it is possible the body is shorter than the range-end field indicates. This can occur if the sender interrupted a SEND request unexpectedly. It is worth noting that the chunk that has a termination character of "$" defines the total length of the message.
受信終点がSEND要求を受け取るとき、それは、最初に、より大きいメッセージから完全なメッセージか塊を含むかどうか決定します。 要求がByte-範囲ヘッダーフィールドを全く含んでいないか、または「1インチ、およびaが継続旗で評価する「$」の閉線、そして、要求は全体のメッセージを含んだ」範囲スタート値で1つを含んでいるなら。 さもなければ、受信機は、オリジナルのメッセージに塊を一緒に関連づけるためにMessage-ID値を見ます。 受信機は、メッセージ、どのバイトを受け取るか、そして、どれがなくなるかに関して動向をおさえることを受けるために仮想のバッファを形成します。 受信機は、要求からデータを取って、バッファの適切な場所にそれを置きます。 受信機SHOULDはペイロード自体を点検することによって、それぞれの塊の実際の長さを測定します。 ボディーが範囲端の分野が示すより短いのは、可能です。 送付者が不意にSEND要求を中断したなら、これは起こることができます。 「$」の行終了文字がいる塊がメッセージの全長を定義することに注意する価値があります。
It is technically illegal for the sender to prematurely interrupt
a request that had anything other than "*" in the last-byte
position of the Byte-Range header field. But having the receiver
calculate a chunk length based on actual content adds resilience
in the face of sender errors. Since this should never happen with
compliant senders, this only has a "SHOULD" strength.
送付者が早まってバイト範囲ヘッダーフィールドの最後のバイト位置の「*」を除いた何でも持っていた要求を中断するのは、技術的に不法です。 しかし、受信機に長さが基礎づけた塊を当てにさせて、実際の内容は送付者誤りに直面して弾力を加えます。 言いなりになっている送付者と共に決して起こるべきでないので、これには、“SHOULD"力があるだけです。
Receivers MUST not assume that the chunks will be delivered in order or that they will receive all the chunks with "+" flags before they receive the chunk with the "$" flag. In certain cases of connection failure, it is possible for information to be duplicated. If chunk data is received that overlaps already received data for the same
受信機は、塊が整然とした状態で提供されるか、または「$」旗で塊を受ける前に彼らが「+」 旗ですべての塊を受けると仮定してはいけません。 ある場合には、接続失敗では、情報がコピーされるのは、可能です。 塊データが受信されているなら、それは同じくらいのための既に受信されたデータを重ね合わせます。
Campbell, et al. Standards Track [Page 25] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[25ページ]。
message, the last chunk received SHOULD take precedence (even though this may not have been the last chunk transmitted). For example, if bytes 1 to 100 were received and a chunk arrives that contains bytes 50 to 150, this second chunk will overwrite bytes 50 to 100 of the data that had already been received. Although other schemes work, this is the easiest for the receiver and results in consistent behavior between clients.
メッセージ、最後の塊容認されたSHOULDは優先します(これが伝えられた最後の塊でないかもしれませんが)。 例えば、バイトであるなら1〜100を受け取りました、そして、50〜150にバイトを含む塊は到着します、そして、この2番目の塊は既に受け取られたデータのバイト50〜100を上書きするでしょう。 他の体系はうまくいきますが、クライアントの間の一貫した振舞いにおける受信機と結果に、これは最も簡単です。
There are situations in which the receiver may not be able to give
precedence to the last chunk received when chunks overlap. For
example, the recipient might incrementally render chunks as they
arrive. If a new chunk arrives that overlaps with a previously
rendered chunk, it would be too late to "take back" any
conflicting data from the first chunk. Therefore, the requirement
to give precedence to the most recent chunk is specified at a
"SHOULD" strength. This requirement is not intended to disallow
applications where this behavior does not make sense.
受信機が塊が重なるとき受け取られた最後の塊に優先権を与えることができないかもしれない状況があります。 例えば、到着するとき、受取人は塊を増加してレンダリングするかもしれません。 以前にレンダリングされた塊に重なる新しい塊が到着するなら、どんな闘争データも最初の塊からの「取り戻す」であることは遅過ぎるでしょう。 したがって、最新の塊に優先権を与えるという要件は“SHOULD"の強さで指定されます。 この要件がこの振舞いが理解できないアプリケーションを禁じることを意図しません。
The seven "-" in the end-line are used so that the receiver can search for the value "----", 32 bits at a time to find the probable location of the end-line. This allows most processors to locate the boundaries and copy the memory at the same rate that a normal memory copy could be done. This approach results in a system that is as fast as framing based on specifying the body length in the header fields of the request, but also allows for the interruption of messages.
「7、受信機が値を捜し求めることができるようにEND行における「-」が使用されている、」----「END行のありえそうな位置を見つける時間の32ビット」 これで、ほとんどのプロセッサが、正常なメモリコピーをできたのと同じレートで境界の場所を見つけて、メモリをコピーします。 このアプローチは、ヘッダーのボディーの長さを指定することに基づいて要求の分野を縁どるのと同じくらい速いシステムをもたらしますが、メッセージの中断をまた考慮します。
What is done with the body is outside the scope of MSRP and largely determined by the MIME Content-Type and Content-Disposition. The body MAY be rendered after the whole message is received or partially rendered as it is being received.
ボディーで行われることは、MSRPの範囲の外にあって、MIMEコンテントタイプとContent-気質で主に断固としています。 それを受け取っているように全体のメッセージを受け取るか、または部分的に伝えた後にボディーをレンダリングするかもしれません。
If the SEND request contained a Content-Type header field indicating an unsupported media-type, and the Failure-Report value is not "no", the receiver MUST generate a response with a status code of 415. All MSRP endpoints MUST be able to receive the multipart/mixed [15] and multipart/alternative [15] media-types.
SEND要求がサポートされないメディアタイプを示すコンテントタイプヘッダーフィールドを含んで、Failure-レポート値が「いいえ」でないなら、受信機は415のステータスコードで応答を生成しなければなりません。 すべてのMSRP終点が複合の、または、複雑な[15]と複合の、または、代替の[15]メディアタイプを受けることができなければなりません。
If the Success-Report header field was set to "yes", the receiver must construct and send one or more success reports, as described in Section 7.1.3.
Success-レポートヘッダーフィールドが「はい」に設定されたなら、受信機は、1つ以上の成功レポートを構成して、送らなければなりません、セクション7.1.3で説明されるように。
Campbell, et al. Standards Track [Page 26] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[26ページ]。
7.3.2. Receiving REPORT Requests
7.3.2. 受信報告書要求
When an endpoint receives a REPORT request, it correlates the report to the original SEND request using the Message-ID and the Byte-Range, if present. If it requested success reports, then it SHOULD keep enough state about each outstanding sent message so that it can correlate REPORT requests to the original messages.
終点がREPORT要求を受け取るとき、オリジナルのSEND要求にMessage-IDとByte-範囲を使用することでレポートを関連させます、存在しているなら。 それであるなら、要求された成功は報告して、次に、それは十分がオリジナルのメッセージにREPORT要求を関連させることができるようにそれぞれの傑出している送信されたメッセージに関して述べるSHOULD生活費です。
An endpoint that receives a REPORT request containing a Status header field with a namespace field of "000" MUST interpret the report in exactly the same way it would interpret an MSRP transaction response with a response code matching the status-code field.
「0インチは応答コードがステータスコード分野に合っているMSRPトランザクション応答を解釈するだろうというまさに同じようにレポートを解釈しなければならない」名前空間分野でStatusヘッダーフィールドを含むREPORT要求を受け取る終点。
It is possible to receive a failure report or a failure transaction response for a chunk that is currently being delivered. In this case, the entire message corresponding to that chunk SHOULD be aborted, by including the "#" character in the continuation field of the end-line.
現在提供されている塊のための異常報告書か失敗トランザクション応答を受け取るのは可能です。 この場合END行の継続欄で堕胎されて、「#」キャラクタを含むその塊SHOULDに対応する全体のメッセージ。
It is possible that an endpoint will receive a REPORT request on a session that is no longer valid. The endpoint's behavior if this happens is a matter of local policy. The endpoint is not required to take any steps to facilitate such late delivery; i.e., it is not expected to keep a connection active in case late REPORTs might arrive.
終点がもう有効でないセッションに関するREPORT要求を受け取るのは、可能です。 これが起こるなら、終点の振舞いはローカルの方針の問題です。 終点はそのような納品遅延を容易にするためにどんな方法も採るのに必要ではありません。 故REPORTsが到着するかもしれないといけないので接続をアクティブに保たないと予想されます。
When an endpoint that sent a SEND request receives a failure REPORT indicating that a particular byte range was not received, it MUST treat the session as failed. If it wishes to recover, it MUST first re-negotiate the URIs at the signaling level then resend that range of bytes of the message on the resulting new session.
SEND要求を送った終点が失敗を受けるとき、特定のバイトが及ぶのを示すREPORTが受け取られないで、それは失敗されるとしてセッションを扱わなければなりません。 回復したいなら、それは最初に、次にレベルが再送する及ぶ結果として起こる新しいセッションに関するメッセージのバイトのシグナリングでURIを再交渉しなければなりません。
MSRP nodes MUST NOT send MSRP REPORT requests in response to other REPORT requests.
MSRPノードは他のREPORT要求に対応して要求をMSRP REPORTに送ってはいけません。
8. Using MSRP with SIP and SDP
8. 一口があるMSRPとSDPを使用します。
MSRP sessions will typically be initiated using the Session Description Protocol (SDP) [2] via the SIP offer/answer mechanism [3].
MSRPセッションは、SIP申し出/答えメカニズム[3]でSession記述プロトコル(SDP)[2]を使用することで通常開始されるでしょう。
This document defines a handful of new SDP parameters to set up MSRP sessions. These are detailed below and in the IANA Considerations section.
このドキュメントは、MSRPセッションをセットアップするために一握りの新しいSDPパラメタを定義します。 これらは部の下と、そして、IANA Considerations部で詳細です。
An MSRP media-line (that is, a media-line proposing MSRP) in the session description is accompanied by a mandatory "path" attribute. This attribute contains a space-separated list of URIs to be visited
セッション記述におけるMSRPメディア系列(すなわち、MSRPを提案するメディア系列)は義務的な「経路」属性によって伴われます。 この属性は訪問されるべきURIのスペースで切り離されたリストを含んでいます。
Campbell, et al. Standards Track [Page 27] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[27ページ]。
to contact the user agent advertising this session description. If more than one URI is present, the leftmost URI is the first URI to be visited to reach the target resource. (The path list can contain multiple URIs to allow for the deployment of gateways or relays in the future.) MSRP implementations that can accept incoming connections without the need for relays will typically only provide a single URI here.
このセッション記述の広告を出すユーザエージェントに連絡するために。 1つ以上のURIが存在しているなら、一番左URIは目標リソースに達するように訪問されるべき最初のURIです。 (経路リストは将来ゲートウェイかリレーの展開のために許容する複数のURIを含むことができます。) リレーの必要性なしで接続要求を受け入れることができるMSRP実装はただ一つのURIをここに通常提供するだけでしょう。
An MSRP media line is also accompanied by an "accept-types" attribute, and optionally an "accept-wrapped-types" attribute. These attributes are used to specify the media-types that are acceptable to the endpoint.
また、MSRPメディア系列が伴われる、「タイプを受け入れる、」 属性、任意に、「包装されたタイプを受け入れてください」という属性。 これらの属性は、終点に許容しているメディアタイプを指定するのに使用されます。
8.1. SDP Connection and Media-Lines
8.1. SDP接続とメディア線
An SDP connection-line takes the following format:
SDP接続系列は以下の形式を取ります:
c=<network type> <address type> <connection address>
<ネットワークタイプ><アドレスタイプ><c=接続アドレス>。
Figure 4: Standard SDP Connection Line
図4: 標準のSDP接続線
The network type and address type fields are used as normal for SDP. The connection address field MUST be set to the IP address or fully qualified domain name from the MSRP URI identifying the endpoint in its path attribute.
ネットワークタイプとアドレスタイプ分野はSDPに標準として使用されます。 接続アドレス・フィールドは経路属性における終点を特定するMSRP URIからのIPアドレスか完全修飾ドメイン名へのセットであるに違いありません。
The general format of an SDP media-line is:
SDPメディア系列の一般形式は以下の通りです。
m=<media> <port> <protocol> <format list>
m=<メディア><ポート><プロトコル><形式リスト>。
Figure 5: Standard SDP Media Line
図5: 標準のSDPメディア線
An offered or accepted media-line for MSRP over TCP MUST include a protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS. The media field value MUST be "message". The format list field MUST be set to "*".
TCPの上のMSRPのための提供されたか受け入れられたメディア系列は"TCP/MSRP"、またはTLSのための「TCP/TLS/MSRP」のプロトコル分野価値を含まなければなりません。 メディア分野価値は「メッセージ」であるに違いありません。 「*」に形式リスト分野を設定しなければなりません。
The port field value MUST match the port value used in the endpoint's MSRP URI in the path attribute, except that, as described in [3], a user agent that wishes to accept an offer, but not a specific media- line, MUST set the port number of that media-line to zero (0) in the response. Since MSRP allows multiple sessions to share the same TCP connection, multiple m-lines in a single SDP document may share the same port field value; MSRP devices MUST NOT assume any particular relationship between m-lines on the sole basis that they have matching port field values.
ポート分野価値は終点のMSRP URIで経路属性に使用されるポート値に合わなければなりません、特定のメディア系列ではなく、申し出に応じたがっているユーザエージェントが、[3]で説明されるようにそのメディア系列のポートナンバーに応答における(0)のゼロを合わせるように設定しなければならないのを除いて。 MSRPが複数のセッションに同じTCP接続を共有させるので、ただ一つのSDPドキュメントの複数のm系列が同じポート分野価値を共有するかもしれません。 MSRPデバイスは、ポート分野値を合わせながら、それらが持っている唯一ベースでm系列の間の少しの特定の関係も仮定してはいけません。
Campbell, et al. Standards Track [Page 28] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[28ページ]。
MSRP devices do not use the c-line address field, or the m-line
port and format list fields to determine where to connect.
Rather, they use the attributes defined in this specification.
The connection information is copied to the c-line and m-line for
purposes of backwards compatibility with conventional SDP usages.
While MSRP could theoretically carry any media-type, "message" is
appropriate.
MSRPデバイスは、どこに接続するかを決定するのにc-系列アドレス・フィールドか、m系列ポートと形式リスト分野を使用しません。 むしろ、彼らはこの仕様に基づき定義された属性を使用します。 接続情報は従来のSDP用法との後方にの目的のためのc-系列とm系列互換性にコピーされます。 MSRPは理論的にどんなメディアタイプも運ぶことができましたが、「メッセージ」は適切です。
8.2. URI Negotiations
8.2. URI交渉
Each endpoint in an MSRP session is identified by a URI. These URIs are negotiated in the SDP exchange. Each SDP offer or answer that proposes MSRP MUST contain a "path" attribute containing one or more MSRP URIs. The path attribute is used in an SDP a-line, and has the following syntax:
MSRPセッションにおける各終点はURIによって特定されます。 これらのURIはSDP交換で交渉されます。 MSRP MUSTを提案する各SDP申し出か答えが1つ以上のMSRP URIを含む「経路」属性を含んでいます。 経路属性は、SDPで1系列で使用されて、以下の構文を持っています:
path = path-label ":" path-list
path-label = "path"
path-list= MSRP-URI *(SP MSRP-URI)
「経路=経路ラベル」:、」 経路リスト経路ラベル=「経路」経路リストはMSRP-URI*と等しいです。(SP MSRP-ユリ)
Figure 6: Path Attribute
図6: 経路属性
where MSRP-URI is an "msrp" or "msrps" URI as defined in Section 6. MSRP URIs included in an SDP offer or answer MUST include explicit port numbers.
MSRP-URIがセクション6で定義される"msrp"か"msrps"URIであるところ。 SDP申し出か答えにMSRP URIを含んでいると、明白なポートナンバーは包含しなければなりません。
An MSRP device uses the URI to determine a host address, port, transport, and protection level when connecting, and to identify the target when sending requests and responses.
要求と応答を送るとき、MSRPデバイスは接続するとき、ホスト・アドレス、ポート、輸送、および保護レベルを決定して、目標を特定するURIを使用します。
The offerer and answerer each selects a URI to represent itself and sends that URI to its peer in the SDP document. Each peer stores the path value received from the other peer and uses that value as the target for requests inside the resulting session. If the path attribute received from the peer contains more than one URI, then the target URI is the rightmost, while the leftmost entry represents the adjacent hop. If only one entry is present, then it is both the peer and adjacent hop URI. The target path is the entire path attribute value received from the peer.
それぞれがそれ自体を表すためにURIを選択して、同輩へのそのURIを送るSDPが記録する申出人とanswerer。 各同輩は、もう片方の同輩から経路対価領収を保存して、結果として起こるセッションのときに要求のための目標としてその値を使用します。 同輩から受け取られた経路属性が1つ以上のURIを含んでいるなら、目標URIは一番右です、一番左エントリーが隣接しているホップを表しますが。 1つのエントリーだけが存在しているなら、それは同輩と隣接しているホップURIの両方です。 目標経路は同輩から受け取られた全体の経路属性値です。
The following example shows an SDP offer with a session URI of "msrp://alice.example.com:7394/2s93i9ek2a;tcp"
以下の例は「msrp://alice.example.com: 7394/2s93i9ek2a; tcpする」セッションURIとのSDP申し出を示しています。
Campbell, et al. Standards Track [Page 29] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[29ページ]。
v=0
o=alice 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alice.example.com:7394/2s93i9ek2a;tcp
v=0 o=alice2890844526 2890844527IN IP4 alice.example.com s=--=経路: タイプ: テキスト/平野msrp://を受け入れている=alice.example.com: メッセージ7394TCP/MSRP*0 0IN c=IP4 alice.example.com t=m=7394/2s93i9ek2a; tcp
Figure 7: Example SDP with Path Attribute
図7: 経路属性がある例のSDP
The rightmost URI in the path attribute MUST identify the endpoint that generated the SDP document, or some other location where that endpoint wishes to receive requests associated with the session. It MUST be assigned for this particular session, and MUST NOT duplicate any URI in use for any other session in which the endpoint is currently participating. It SHOULD be hard to guess, and protected from eavesdroppers. This is discussed in more detail in Section 14.
経路属性における一番右のURIはSDPドキュメントを作った終点、またはその終点がセッションに関連している要求を受け取りたがっているある他の位置を特定しなければなりません。 それは、この特定のセッションのために割り当てなければならなくて、終点が現在参加するいかなる他のセッションのためにも使用中のどんなURIもコピーしてはいけません。 それ、SHOULDは推測しにくくて、立ち聞きする者から保護しました。 さらに詳細にセクション14でこれについて議論します。
8.3. Path Attributes with Multiple URIs
8.3. 複数のURIがある経路属性
As mentioned previously, this document describes MSRP for peer-to- peer scenarios, that is, when no relays are used. The use of relays is described in a separate document [23]. In order to allow an MSRP device that only implements the core specification to interoperate with devices that use relays, this document must include a few assumptions about how relays work.
すなわち、どんなリレーも使用されていないとき、既述のとおり、このドキュメントは同輩から同輩へのシナリオのためにMSRPについて説明します。 リレーの使用は別々のドキュメント[23]で説明されます。 コア仕様を履行するだけであるMSRP装置がリレーを使用する装置で共同利用するのを許容するために、このドキュメントはリレーがどう働くかに関するいくつかの仮定を含まなければなりません。
An endpoint that uses one or more relays will indicate that by putting a URI for each device in the relay chain into the SDP path attribute. The final entry will point to the endpoint itself. The other entries will indicate each proposed relay, in order. The first entry will point to the first relay in the chain from the perspective of the peer, that is, the relay to which the peer device, or a relay operating on its behalf, should connect.
1個以上のリレーを使用する終点は、各装置のためのURIをリレーチェーンに入れることによって、SDP経路属性にそれを示すでしょう。 最終記入は終点自体を示すでしょう。 他のエントリーはオーダーにおけるそれぞれの提案されたリレーを示すでしょう。 初記入は同輩(すなわち、同輩装置、または利益を作動させるリレーが接続するはずであるリレー)の見解からチェーンで最初のリレーを示すでしょう。
Endpoints that do not wish to insert a relay, including those that do not support relays at all, will put exactly one URI into the path attribute. This URI represents both the endpoint for the session and the connection point.
全くリレーを支えないものを含んでいて、リレーを挿入したがっていない終点がまさに1つのURIを経路属性に入れるでしょう。 このURIはセッションのための終点と接続拠点の両方を表します。
Even though endpoints that implement only this specification will never introduce a relay, they need to be able to interoperate with other endpoints that do use relays. Therefore, they MUST be prepared to receive more than one URI in the SDP path attribute. When an endpoint receives more than one URI in a path attribute, only the
この仕様だけを履行する終点がリレーを決して導入しないでしょうが、それらは、リレーを使用する他の終点で共同利用できる必要があります。 したがって、SDP経路属性における1つ以上のURIを受けるようにそれらを準備しなければなりません。 終点が経路属性における1つ以上のURIを受けるとき唯一
Campbell, et al. Standards Track [Page 30] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[30ページ]。
first entry is relevant for purposes of resolving the address and port, and establishing the network connection, as it describes the first adjacent hop.
初記入はアドレスとポートを決議して、ネットワーク接続を確立する目的のために関連しています、最初の隣接しているホップについて説明するとき。
If an endpoint puts more than one URI in a path attribute, the final URI in the path attribute (the peer URI) identifies the session, and MUST not duplicate the URI of any other session in which the endpoint is currently participating. Uniqueness requirements for other entries in the path attribute are out of scope for this document.
終点が経路属性に1つ以上のURIを入れるなら、経路属性(同輩URI)における最終的なURIは、セッションを特定して、終点が現在参加するいかなる他のセッションのURIもコピーしてはいけません。 このドキュメントのための範囲の外に経路属性における他のエントリーのためのユニークさの要件があります。
8.4. Updated SDP Offers
8.4. アップデートされたSDP申し出
MSRP endpoints may sometimes need to send additional SDP exchanges for an existing session. They may need to send periodic exchanges with no change to refresh state in the network, for example, SIP session timers or the SIP UPDATE [24] request. They may need to change some other stream in a session without affecting the MSRP stream, or they may need to change an MSRP stream without affecting some other stream.
MSRP終点は、時々既存のセッションのために追加SDP交換を送る必要があるかもしれません。 彼らは、ネットワークで状態をリフレッシュするために変化なしで周期的な交換を送る必要があるかもしれません、と例えば、SIPセッションタイマかSIP UPDATE[24]が要求します。 彼らが、セッションのときにMSRPの流れに影響しないである他の流れを変える必要があるかもしれませんか、または彼らは、ある他の流れに影響しないでMSRPの流れを変える必要があるかもしれません。
Either peer may initiate an updated exchange at any time. The endpoint that sends the new offer assumes the role of offerer for all purposes. The answerer MUST respond with a path attribute that represents a valid path to itself at the time of the updated exchange. This new path may be the same as its previous path, but may be different. The new offerer MUST NOT assume that the peer will answer with the same path it used previously.
どちらの同輩もいつでも、アップデートされた交換を起こすかもしれません。 新しい申し出を送る終点はすべての目的のために申出人の役割を引き受けます。 answererはアップデートされた交換時点で有効な経路をそれ自体に表す経路属性で応じなければなりません。 この新しい経路は、前の経路と同じであるかもしれませんが、異なっているかもしれません。 新しい申出人は、同輩がそれが以前に使用した同じ経路で答えると仮定してはいけません。
If either party wishes to send an SDP document that changes nothing at all, then it MUST use the same o-line as in the previous exchange.
何れの当事者がSDPドキュメントを送りたいなら、それは全く何も変えません、それが前の交換に同じo-線を使用しなければならないその時。
8.5. Connection Negotiation
8.5. 接続交渉
Previous versions of this document included a mechanism to negotiate the direction for any required TCP connection. The mechanism was loosely based on the Connection-Oriented Media (COMEDIA) [26] work done by the MMUSIC working group. The primary motivation was to allow MSRP sessions to succeed in situations where the offerer could not accept connections but the answerer could. For example, the offerer might be behind a NAT, while the answerer might have a globally routable address.
このドキュメントの旧バージョンは、どんな必要なTCP接続のためにも指示を交渉するためにメカニズムを含んでいました。 メカニズムは緩くMMUSICワーキンググループによって行われたConnectionが指向のメディア(COMEDIA)[26]仕事に基づきました。 第一の動機が申出人が接続を受け入れることができなかったところにMSRPセッションが状況に成功するのを許容することでしたが、answererは許容できました。 例えば、申出人はNATの後ろにいるかもしれませんが、answererには、グローバルに発送可能なアドレスがあるかもしれません。
The SIMPLE working group chose to remove that mechanism from MSRP, as it added a great deal of complexity to connection management. Instead, MSRP now specifies a default connection direction. The party that sent the original offer is responsible for connecting to its peer.
SIMPLEワーキンググループは、MSRPからそのメカニズムを取り外すのを選びました、多くの複雑さを接続管理に追加したので。 代わりに、MSRPは現在、デフォルト接続指示を指定します。 オリジナルの申し出を送ったパーティーは同輩に接するのに責任があります。
Campbell, et al. Standards Track [Page 31] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[31ページ]。
8.6. Content Type Negotiation
8.6. 満足しているタイプ交渉
An SDP media-line proposing MSRP MUST be accompanied by an accept- types attribute.
MSRP MUSTを提案するSDPメディア線、伴われる、タイプ属性を受け入れてください。
An entry of "*" in the accept-types attribute indicates that the sender may attempt to send content with media-types that have not been explicitly listed. Likewise, an entry with an explicit type and a "*" character as the subtype indicates that the sender may attempt to send content with any subtype of that type. If the receiver receives an MSRP request and is able to process the media-type, it does so. If not, it will respond with a 415 response. Note that all explicit entries SHOULD be considered preferred over any non-listed types. This feature is needed as, otherwise, the list of formats for rich IM devices may be prohibitively large.
タイプを受け入れている属性における、「*」のエントリーは、送付者が、明らかに記載されていないメディアタイプで内容を送るのを試みるかもしれないのを示します。 同様に、「副-タイプ」としての明白なタイプと「*」キャラクタとのエントリーは、送付者が、そのタイプのどんな「副-タイプ」がある内容も送るのを試みるかもしれないのを示します。 受信機がMSRP要求を受け取って、メディアタイプを処理できるなら、それはそうします。 そうでなければ、それは415応答で応じるでしょう。 すべての明白なエントリーSHOULDが考えられることにどんな非記載されたタイプでも都合のよいのを注意してください。 さもなければ、豊かなIM装置のための形式のリストが法外に大きいときに、この特徴が必要です。
This specification requires the support of certain data formats. Mandatory formats MUST be signaled like any other, either explicitly or by the use of a "*".
この仕様はあるデータ形式のサポートを必要とします。 いかなる他の、明らかまたは「*」の使用でも義務的な形式に合図しなければなりません。
The accept-types attribute may include container types, that is, MIME formats that contain other types internally. If compound types are used, the types listed in the accept-types attribute may be used as the root payload or may be wrapped in a listed container type. Any container types MUST also be listed in the accept-types attribute.
タイプを受け入れている属性は容器タイプ、すなわち、内部的に他のタイプを含むMIME形式を含むかもしれません。 合成タイプが使用されているなら、タイプを受け入れている属性で記載されたタイプは、根のペイロードとして使用されるか、または記載された容器タイプで包装されるかもしれません。 また、タイプを受け入れている属性でどんな容器タイプも記載しなければなりません。
Occasionally, an endpoint will need to specify a MIME media-type that can only be used if wrapped inside a listed container type.
時折、終点は、記載された容器タイプの中で包装される場合にだけ使用できるMIMEメディアタイプを指定する必要があるでしょう。
Endpoints MAY specify media-types that are only allowed when wrapped inside compound types using the "accept-wrapped-types" attribute in an SDP a-line.
終点は1線で合成タイプの中でSDPで「包装されたタイプを受け入れてください」という属性を使用することで包装されると許容されているだけであるメディアタイプを指定するかもしれません。
The semantics for accept-wrapped-types are identical to those of the accept-types attribute, with the exception that the specified types may only be used when wrapped inside container types listed in the accept-types attribute. Only types listed in the accept-types attribute may be used as the "root" type for the entire body. Since any type listed in accept-types may be both used as a root body and wrapped in other bodies, format entries from accept-types SHOULD NOT be repeated in this attribute.
意味論、包装されたタイプを受け入れてください、タイプを受け入れている属性のものと同じです、例外で、容器タイプの中で包装されると指定されたタイプが使用されるだけであるかもしれないのはタイプを受け入れている属性で記載しました。 全身に「根」タイプとしてタイプを受け入れている属性で記載されたタイプだけを使用してもよいです。 根として使用される両方がボディーであったかもしれないならタイプを受け入れるところに記載されて、タイプを受け入れているSHOULD NOTからの他のボディー、形式エントリーで包装されたあらゆるタイプ以来、この属性で繰り返されてください。
This approach does not allow for specifying distinct lists of acceptable wrapped types for different types of containers. If an endpoint understands a media-type in the context of one wrapper, it is assumed to understand it in the context of any other acceptable wrappers, subject to any constraints defined by the wrapper types themselves.
このアプローチは、異なったタイプの容器のための許容包装されたタイプの異なったリストを指定すると考慮しません。 終点が1つの包装紙の文脈でメディアタイプを理解しているなら、いかなる他の許容できる包装紙の文脈でも包装紙のタイプ自体によって定義されたどんな規制を条件としてそれを理解していると思われます。
Campbell, et al. Standards Track [Page 32] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[32ページ]。
The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a
Common Presence and Instant Messaging (CPIM) [12] gateway device
may require all messages to be wrapped inside message/cpim bodies,
but may allow several content types inside the wrapper. If the
gateway were to specify the wrapped types in the accept-types
attribute, its peer might attempt to use those types without the
wrapper.
ある包装紙の使用を強制できる容器の内部が別々に第一のペイロードから許容されているだけであるタイプが終点をタイプする指定のアプローチ。 例えば、Common PresenceとInstant Messaging(CPIM)[12]ゲートウェイ装置は、すべてのメッセージ/cpimボディーの中で包装されるべきメッセージを必要としますが、包装紙の中のいくつかの満足しているタイプを許容するかもしれません。 ゲートウェイがタイプを受け入れている属性で包装されたタイプを指定するなら、同輩は、包装紙なしでそういったタイプの人を使用するのを試みるでしょうに。
If the recipient of an offer does not understand any of the payload types indicated in the offered SDP, it SHOULD indicate that using the appropriate mechanism of the rendezvous protocol. For example, in SIP, it SHOULD return a SIP 488 response.
申し出の受取人が分からないなら、ペイロードのどれかは提供されたSDPで示された状態でタイプされます、それ。SHOULDは、ランデブーの適切な手段を使用するのが議定書を作るのを示します。 例えばSIPでそれ、SHOULDはSIP488応答を返します。
An MSRP endpoint MUST NOT send content of a type not signaled by the peer in either an accept-types or an accept-wrapped-types attribute. Furthermore, it MUST NOT send a top-level (i.e., not wrapped) MIME document of a type not signaled in the accept-types attribute. In either case, the signaling could be explicit, or implicit through the use of the "*" character.
MSRP終点がどちらも同輩によって合図されなかったタイプの内容を送ってはいけない、タイプを受け入れる、または、包装されたタイプを受け入れている属性。 その上、それはタイプを受け入れている属性で合図しなかったタイプのトップレベル(すなわち、包装されない)MIMEドキュメントを送ってはいけません。 どちらかの場合では、シグナリングは、明白であるか、または「*」キャラクタの使用で暗黙であるかもしれません。
An endpoint MAY indicate the maximum size message it wishes to receive using the max-size a-line attribute. Max-size refers to the complete message in octets, not the size of any one chunk. Senders SHOULD NOT exceed the max-size limit for any message sent in the resulting session. However, the receiver should consider max-size value as a hint.
最大サイズの1線の属性を使用して、終点はそれが受け取りたがっている最大サイズメッセージを示すかもしれません。 マックス-サイズはどんな塊のサイズではなく、八重奏における完全なメッセージも示します。 送付者SHOULD NOTは結果として起こるセッションのときに送られたどんなメッセージのための最大サイズ限界も超えています。 しかしながら、受信機は、最大サイズ値がヒントであるとみなすはずです。
Media format entries may include parameters. The interpretation of such parameters varies between media-types. For the purposes of media-type negotiation, a format-entry with one or more parameters is assumed to match the same format-entry with no parameters.
メディア形式エントリーはパラメタを含むかもしれません。 そのようなパラメタの解釈はメディアタイプの間で異なります。 メディアタイプ交渉の目的のために、1つ以上のパラメタがある形式エントリーがパラメタなしで同じ形式エントリーに合っていると思われます。
Campbell, et al. Standards Track [Page 33] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[33ページ]。
The formal syntax for these attributes is as follows:
これらの属性のための正式な構文は以下の通りです:
accept-types = accept-types-label ":" format-list
accept-types-label = "accept-types"
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
format-list = format-entry *( SP format-entry)
format-entry = ( ( (type "/" subtype)
/ (type "/" "*") )
*( ";" type-param ) )
/ ("*")
「タイプを受け入れる、= タイプラベルを受け入れてください、」、:、」 「タイプラベルを受け入れている形式リスト=、「タイプを受け入れる、」 包装されたタイプを受け入れている=包装されたタイプラベル、」、:、」 「形式エントリー*(SP形式エントリー)形式= 「包装されたタイプを受け入れてください」という形式リスト包装されたタイプラベル形式リスト=エントリーは/(」 /」 「*」) *(「;」タイプ-param)をタイプする)/と等しいです(」 」 /「副-タイプ」をタイプします)。("*")
type = token
subtype = token
type-param = parm-attribute "=" parm-value
parm-attribute = token
parm-value = token / quoted-string
象徴parm parm-属性「=」parm-値のparm象徴「副-タイプ」タイプ==象徴タイプ-param=属性=価値は象徴/引用文字列と等しいです。
max-size = max-size-label ":" max-size-value
max-size-label = "max-size"
max-size-value = 1*(DIGIT) ; max size in octets
「最大サイズは最大サイズラベルと等しい」:、」 最大サイズ価値最大サイズラベル=「最大サイズ」最大サイズ価値は1*(DIGIT)と等しいです。 八重奏における最大サイズ
Figure 8: Attribute Syntax
エイト環: 属性構文
8.7. Example SDP Exchange
8.7. 例のSDP交換
Endpoint A wishes to invite Endpoint B to an MSRP session. A offers the following session description:
MSRPセッションにEndpoint Bを招待するという終点A願望。 Aは以下のセッション記述を提供します:
v=0
o=usera 2890844526 2890844527 IN IP4 alice.example.com
s= -
c=IN IP4 alice.example.com
t=0 0
m=message 7394 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://alice.example.com:7394/2s93i93idj;tcp
v=0 o=usera2890844526 2890844527IN IP4 alice.example.com s=--=タイプ: メッセージ/cpimを受け入れているテキスト/プレーンテキスト/html a=経路: msrp://alice.example.com: メッセージ7394TCP/MSRP*0 0IN c=IP4 alice.example.com t=m=7394/2s93i93idj; tcp
Figure 9: SDP from Endpoint A
図9: 終点AからのSDP
Campbell, et al. Standards Track [Page 34] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[34ページ]。
B responds with its own URI:
Bはそれ自身のURIで応じます:
v=0
o=userb 2890844530 2890844532 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8493 TCP/MSRP *
a=accept-types:message/cpim text/plain
a=path:msrp://bob.example.com:8493/si438dsaodes;tcp
v=0 o=userb2890844530 2890844532IN IP4 bob.example.com s=--=経路: タイプ: メッセージ/cpimテキスト/平野msrp://を受け入れている=bob.example.com: メッセージ8493TCP/MSRP*0 0IN c=IP4 bob.example.com t=m=8493/si438dsaodes; tcp
Figure 10: SDP from Endpoint B
図10: 終点BからのSDP
8.8. MSRP User Experience with SIP
8.8. 一口のMSRPユーザー・エクスペリエンス
In typical SIP applications, when an endpoint receives an INVITE request, it alerts the user, and waits for user input before responding. This is analogous to the typical telephone user experience, where the callee "answers" the call.
終点がINVITE要求を受け取るときの典型的なSIPアプリケーションでは、それは、ユーザを警告して、応じる前に、ユーザ入力を待ちます。 訪問される人が呼び出しに「答えるところ」でこれは典型的な電話ユーザー・エクスペリエンスに類似しています。
In contrast, the typical user experience for instant messaging applications is that the initial received message is immediately displayed to the user, without waiting for the user to "join" the conversation. Therefore, the principle of least surprise would suggest that MSRP endpoints using SIP signaling SHOULD allow a mode where the endpoint quietly accepts the session and begins displaying messages.
対照的に、インスタントメッセージングアプリケーションのための典型的なユーザー・エクスペリエンスはすぐに初期の受信されたメッセージをユーザに表示するということです、ユーザが会話を「接合すること」を待たない。 したがって、少しの驚きの原則は、SIPシグナリングSHOULDを使用するMSRP終点が終点が静かにセッションを受け入れて、メッセージを表示し始めるモードを許容するのを示すでしょう。
This guideline may not make sense for all situations, such as for
mixed-media applications, where both MSRP and audio sessions are
offered in the same INVITE. In general, good application design
should take precedence.
このガイドラインはすべての状況のために理解できないかもしれません、混合媒体アプリケーションなどのように。そこでは、MSRPとオーディオセッションの両方が同じINVITEで提供されます。 一般に、良いアプリケーション設計は優先するべきです。
SIP INVITE requests may be forked by a SIP proxy, resulting in more than one endpoint receiving the same INVITE. SIP early media [29] techniques can be used to establish a preliminary session with each endpoint so the initial message(s) are displayed on each endpoint, and canceling the INVITE transaction for any endpoints that do not send MSRP traffic after some period of time, so that they cease receiving MSRP traffic from the inviter.
同じINVITEを受ける1つ以上の終点をもたらして、SIPプロキシはSIP INVITE要求を分岐させるかもしれません。 各終点との予備のセッションを証明するのにSIPの早めのメディア[29]テクニックを使用できて、初期のメッセージは、いつかの期間の後に交通をMSRPに送らないどんな終点としても、各終点に表示するので、INVITE取引を中止しています、inviterからのMSRP交通を受けるのをやめるように。
8.9. SDP Direction Attribute and MSRP
8.9. SDP指示属性とMSRP
SDP defines a number of attributes that modify the direction of media flows. These are the "sendonly", "recvonly", "inactive", and "sendrecv" attributes.
SDPはメディア流れの方向を変更する多くの属性を定義します。 これらは「recvonlyであっ」て、「不活発である」"sendonly"、および"sendrecv"属性です。
Campbell, et al. Standards Track [Page 35] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[35ページ]。
If a "sendonly" or "recvonly" attribute modifies an MSRP media description line, the attribute indicates the direction of MSRP SEND requests that contain regular message payloads. Unless otherwise specified, these attributes do not affect the direction of other types of requests, such as REPORT. SEND requests that contain some kind of control or reporting protocol rather than regular message payload (e.g., Instant Message Delivery Notification (IMDN) reports) should be generated according to the protocol rules as if no direction attribute were present.
「sendonlyである」か「recvonlyな」属性がMSRPメディア記述線を変更するなら、属性は通常のメッセージペイロードを含むMSRP SEND要求の指示を示します。 別の方法で指定されない場合、これらの属性は他のタイプのREPORTなどの要求の指示に影響しません。 まるでどんな指示属性も存在していないかのようにプロトコル規則に従って、ある種のコントロールを含むSEND要求か通常のメッセージペイロードよりむしろプロトコルを報告するのが(例えば、Instant Message Delivery Notification(IMDN)レポート)発生するべきです。
9. Formal Syntax
9. 正式な構文
MSRP is a text protocol that uses the UTF-8 [14] transformation format.
MSRPはUTF-8[14]変化形式を使用するテキストプロトコルです。
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [6].
以下の構文仕様はRFC4234[6]で説明されるように増大しているBN記法(BNF)を使用します。
msrp-req-or-resp = msrp-request / msrp-response msrp-request = req-start headers [content-stuff] end-line msrp-response = resp-start headers end-line
msrp-応答msrp msrp-reqかresp=msrp-要求/要求=req-スタートヘッダー[満足しているものの]END行msrp-応答はresp-スタートヘッダーEND行と等しいです。
req-start = pMSRP SP transact-id SP method CRLF resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF comment = utf8text
req-始めはイドを商取引しているpMSRP SP SPステータスコード[SPコメント]CRLFイドを商取引しているpMSRP SP SP方法CRLF resp-始め=コメント=utf8textと等しいです。
pMSRP = %x4D.53.52.50 ; MSRP in caps transact-id = ident method = mSEND / mREPORT / other-method mSEND = %x53.45.4e.44 ; SEND in caps mREPORT = %x52.45.50.4f.52.54; REPORT in caps
pMSRP=%x4D.53.52.50。 他のmSEND/mREPORT/方法identキャップでイドを商取引しているMSRP=方法=mSENDは%x53.45.4e.44と等しいです。 キャップmREPORT=%x52.45.50.4f.52.54のSEND。 キャップのREPORT
other-method = 1*UPALPHA
status-code = 3DIGIT ; any code defined in this document
; or an extension document
1*UPALPHA他の方法=ステータスコードは3DIGITと等しいです。 本書では定義されたどんなコードも。 または、拡大ドキュメント
MSRP-URI = msrp-scheme "://" authority
["/" session-id] ";" transport *( ";" URI-parameter)
; authority as defined in RFC3986
「MSRP-URI=はmsrpに」 ://を計画する」という権威[「/」セッションイド]、」、;、」 *を輸送してください、(「」、;、ユリ-パラメタ)、。 RFC3986で定義される権威
msrp-scheme = "msrp" / "msrps"
session-id = 1*( unreserved / "+" / "=" / "/" )
; unreserved as defined in RFC3986
transport = "tcp" / 1*ALPHANUM
URI-parameter = token ["=" token]
「"msrps"セッションmsrp-計画="msrp"/イド=1*、(無遠慮な/「+」/が「」 /と等しい」という/、」、)、。 定義されるとして、1*ALPHANUM URI RFC3986輸送="tcp"/パラメタ=象徴では、無遠慮です。[「=」象徴]
headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
ヘッダーは経路へのCRLF From-経路CRLF1*と等しいです。(ヘッダーCRLF)
Campbell, et al. Standards Track [Page 36] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[36ページ]。
header = Message-ID
/ Success-Report
/ Failure-Report
/ Byte-Range
/ Status
/ ext-header
extバイト失敗ヘッダー=成功Message ID/レポート/レポート/範囲/状態/ヘッダー
To-Path = "To-Path:" SP MSRP-URI *( SP MSRP-URI )
From-Path = "From-Path:" SP MSRP-URI *( SP MSRP-URI )
Message-ID = "Message-ID:" SP ident
Success-Report = "Success-Report:" SP ("yes" / "no" )
Failure-Report = "Failure-Report:" SP ("yes" / "no" / "partial" )
Byte-Range = "Byte-Range:" SP range-start "-" range-end "/" total
range-start = 1*DIGIT
range-end = 1*DIGIT / "*"
total = 1*DIGIT / "*"
経路への=、「経路:、」 経路からのSP MSRP-URI*(SP MSRP-URI)=、「経路:、」 SP MSRP-URI*(SP MSRP-URI)Message IDが等しい、「Message ID:」 = 「成功して報告してください。」とSP ident Success報告してください。 = 「失敗して報告してください。」と、SP(「はい」/「いいえ」)は失敗して報告します。 SPの(「はい」/「いいえ」/「部分的」)のバイト範囲=、「バイト範囲:」 」 総範囲スタート=1*ケタ範囲終わり=1*ケタ/「*」が合計する「SP範囲スタート「-」範囲終わり」/は1*ケタ/「*」と等しいです。
Status = "Status:" SP namespace SP status-code [SP comment] namespace = 3(DIGIT); "000" for all codes defined in this document.
状態が等しい、「状態:」 SP名前空間SPステータスコード[SPコメント]名前空間=3(DIGIT)。 「本書では定義されたすべてのコードのための0インチ。」
ident = ALPHANUM 3*31ident-char ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="
「identはALPHANUM3*31ident-炭のident炭=ALPHANUM/と等しい」、」 / "-" / "+" / "%" / "="
content-stuff = *(Other-Mime-header CRLF)
Content-Type 2CRLF data CRLF
満足しているものの=*(他のパントマイムヘッダーCRLF)コンテントタイプ2CRLFデータCRLF
Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *( ";" gen-param ) type = token subtype = token
コンテントタイプが等しい、「コンテントタイプ:」 」 「SPメディアタイプメディアタイプはタイプと等しく」/「副-タイプ」*(-paramに情報を得ている「;」)タイプは象徴「副-タイプ」=象徴と等しいです。
gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string
paramに情報を得ている=pname[pvalと「等しい」]pnameは象徴pval=象徴/引用文字列と等しいです。
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E
/ %x30-39 / %x41-5A / %x5E-7E)
; token is compared case-insensitive
象徴は1*(%x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E)と等しいです。 象徴が比較される、大文字と小文字を区別しなさ
quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE
qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E
/ UTF8-NONASCII
qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE)
BACKSLASH = "\"
UPALPHA = %x41-5A
ALPHANUM = ALPHA / DIGIT
「\」(BACKSLASH BACKSLASH)/(BACKSLASH DQUOTE)引用文字列=DQUOTE*(qdtext / qd-esc)DQUOTE qdtext=SP / HTAB /%x21/%x23-5B/%x5D-7E / UTF8-NONASCII qd-esc=BACKSLASH=UPALPHA=%x41-5A ALPHANUMはアルファー/ケタと等しいです。
Campbell, et al. Standards Track [Page 37] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[37ページ]。
Other-Mime-header = (Content-ID
/ Content-Description
/ Content-Disposition
/ mime-extension-field)
他のパントマイムヘッダー=(パントマイム拡大満足している満足しているコンテントID/記述/気質/分野)
; Content-ID, and Content-Description are defined in RFC2045.
; Content-Disposition is defined in RFC2183
; MIME-extension-field indicates additional MIME extension
; header fields as described in RFC2045
; コンテントID、およびContent-記述はそうです。RFC2045では、定義されます。 ; 満足している気質はRFC2183で定義されます。 MIME拡大分野は追加MIME拡大を示します。 RFC2045で説明されるヘッダーフィールド
data = *OCTET end-line = "-------" transact-id continuation-flag CRLF continuation-flag = "+" / "$" / "#"
「データは*OCTET END行=と等しいです」-------「イドを商取引している継続旗CRLF継続旗=「+」/「$」/「#」」
ext-header = hname ":" SP hval CRLF hname = ALPHA *token hval = utf8text
「ext-ヘッダー=hname」:、」 SP hval CRLF hnameはアルファー*象徴hval=utf8textと等しいです。
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
utf8textは*と等しいです。(HTAB/%x20-7E / UTF8-NONASCII)
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-Fb 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
UTF8-NONASCII=%xC0-DF 1UTF8-CONT/%xE0-EF 2UTF8-CONT/%xF0-F7 3UTF8-CONT/%xF8-Fb 4UTF8-CONT/%xFC-FD 5UTF8-CONT UTF8-CONT=%x80-BF
Figure 11: MSRP ABNF
図11: MSRP ABNF
10. Response Code Descriptions
10. 応答コード記述
This section summarizes the semantics of various response codes that may be used in MSRP transaction responses. These codes may also be used in the Status header field in REPORT requests.
このセクションはMSRP取引応答に使用されるかもしれない様々な応答コードの意味論をまとめます。 また、これらのコードはREPORT要求におけるStatusヘッダーフィールドに使用されるかもしれません。
10.1. 200
10.1. 200
The 200 response code indicates a successful transaction.
200応答コードはうまくいっている取引を示します。
10.2. 400
10.2. 400
A 400 response indicates that a request was unintelligible. The sender may retry the request after correcting the error.
400応答は、要求が難解であったのを示します。 送付者はエラーを修正した後に、要求を再試行するかもしれません。
10.3. 403
10.3. 403
A 403 response indicates that the attempted action is not allowed. The sender should not try the request again.
403応答は、試みられた動作が許容されていないのを示します。 送付者は再び要求を試みるべきではありません。
Campbell, et al. Standards Track [Page 38] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[38ページ]。
10.4. 408
10.4. 408
A 408 response indicates that a downstream transaction did not complete in the allotted time. It is never sent by any elements described in this specification. However, 408 is used in the MSRP relay extension; therefore, MSRP endpoints may receive it. An endpoint MUST treat a 408 response in the same manner as it would treat a local timeout.
408応答は、川下の取引が割り当てで時間を完成しなかったのを示します。 この仕様で説明されたどんな要素でもそれを決して送りません。 しかしながら、408はMSRPリレー拡張子が使用されています。 したがって、MSRP終点はそれを受けるかもしれません。 地方のタイムアウトを扱うように終点は同じ方法で408応答を扱わなければなりません。
10.5. 413
10.5. 413
A 413 response indicates that the receiver wishes the sender to stop sending the particular message. Typically, a 413 is sent in response to a chunk of an undesired message.
413応答は、受信機が、送付者が、特定のメッセージを送るのを止める必要であるのを示します。 通常、望まれないメッセージの塊に対応して413を送ります。
If a message sender receives a 413 in a response, or in a REPORT request, it MUST NOT send any further chunks in the message, that is, any further chunks with the same Message-ID value. If the sender receives the 413 while in the process of sending a chunk, and the chunk is interruptible, the sender MUST interrupt it.
メッセージ送付者が応答、またはREPORT要求に413を受け取るなら、それはメッセージのどんなさらなる塊、すなわち、同じMessage-ID値があるどんなさらなる塊も送ってはいけません。 送付者が塊を送ることの途中に、413を受け取って、塊がinterruptibleであるなら、送付者はそれを中断しなければなりません。
10.6. 415
10.6. 415
A 415 response indicates that the SEND request contained a media type that is not understood by the receiver. The sender should not send any further messages with the same content-type for the duration of the session.
415応答は、SEND要求が受信機に解釈されないメディアタイプを含んだのを示します。送付者はセッションの持続時間のための同じ満足しているタイプでどんなさらなるメッセージも送るべきではありません。
10.7. 423
10.7. 423
A 423 response indicates that one of the requested parameters is out of bounds. It is used by the relay extensions to this document.
423応答は、要求されたパラメタの1つが区域外にあるのを示します。 それはこのドキュメントへのリレー拡大で使用されます。
10.8. 481
10.8. 481
A 481 response indicates that the indicated session does not exist. The sender should terminate the session.
481応答は、示されたセッションが存在しないのを示します。 送付者はセッションを終えるべきです。
10.9. 501
10.9. 501
A 501 response indicates that the recipient does not understand the request method.
501応答は、受取人が要求方法を理解していないのを示します。
The 501 response code exists to allow some degree of method
extensibility. It is not intended as a license to ignore methods
defined in this document; rather, it is a mechanism to report lack
of support of extension methods.
501応答コードは、いくらかの方法伸展性を許容するために存在しています。 それは本書では定義された方法を無視するライセンスとして意図しません。 むしろ、それは拡大方法のサポートの不足を報告するメカニズムです。
Campbell, et al. Standards Track [Page 39] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[39ページ]。
10.10. 506
10.10. 506
A 506 response indicates that a request arrived on a session that is already bound to another network connection. The sender should cease sending messages for that session on this connection.
506応答は、要求が既に別のネットワーク接続に縛られるセッションに到達したのを示します。 送付者は、この接続のそのセッションへのメッセージを送るのをやめるべきです。
11. Examples
11. 例
11.1. Basic IM Session
11.1. 基本的な不-セッション
This section shows an example flow for the most common scenario. The example assumes SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the example, assume that the offerer is sip:alice@example.com and the answerer is sip:bob@example.com.
このセクションは最も一般的なシナリオのために例の流動を示しています。 例は、SIPがSDP交換を輸送するのに使用されると仮定します。 SIPメッセージとSIPプロキシインフラストラクチャの詳細は簡潔にするために省略されます。 例では、answererは一口です: 申出人が: alice@example.com をちびちび飲むことであり、 bob@example.com と仮定してください。
Alice Bob
| |
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
|(4) (MSRP) SEND |
|----------------------->|
|(5) (MSRP) 200 OK |
|<-----------------------|
|(6) (MSRP) SEND |
|<-----------------------|
|(7) (MSRP) 200 OK |
|----------------------->|
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
アリス・ボブ| | | | |(1) (一口) 招待| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(2) (一口) 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(3) (一口) ACK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(4) (MSRP) 発信してください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(5) (MSRP) 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(6) (MSRP) 発信してください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |(7) (MSRP) 200 OK| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(8) (一口) さようなら| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |(9) (一口) 200 OK| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|
Figure 12: Basic IM Session Example
図12: 基本の不-セッションの例
Campbell, et al. Standards Track [Page 40] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[40ページ]。
1. Alice constructs a local URI of
msrp://alicepc.example.com:7777/iau39soe2843z;tcp .
1. アリスはmsrp://alicepc.example.com: 7777/iau39soe2843zの地方のURIを構成します; tcp。
Alice->Bob (SIP): INVITE sip:bob@example.com
アリス->はたたかれます(一口): INVITE一口: bob@example.com
v=0
o=alice 2890844557 2890844559 IN IP4 alicepc.example.com
s= -
c=IN IP4 alicepc.example.com
t=0 0
m=message 7777 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://alicepc.example.com:7777/iau39soe2843z;tcp
v=0 o=alice2890844557 2890844559IN IP4 alicepc.example.com s=--=経路: タイプ: テキスト/平野msrp://を受け入れている=alicepc.example.com: メッセージ7777TCP/MSRP*0 0IN c=IP4 alicepc.example.com t=m=7777/iau39soe2843z; tcp
2. Bob listens on port 8888, and sends the following response:
2. ボブは、ポート8888の上で聴いて、以下の応答を送ります:
Bob->Alice (SIP): 200 OK
>をたたいているアリス(一口): 200 OK
v=0
o=bob 2890844612 2890844616 IN IP4 bob.example.com
s= -
c=IN IP4 bob.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=accept-types:text/plain
a=path:msrp://bob.example.com:8888/9di4eae923wzd;tcp
v=0oはボブの2890844612 2890844616IN IP4 bob.example.com s=--=経路: タイプ: テキスト/平野msrp://を受け入れている=bob.example.com: メッセージ8888TCP/MSRP*0 0IN c=IP4 bob.example.com t=m=8888/9di4eae923wzd; tcpと等しいです。
3. Alice->Bob (SIP): ACK sip:bob@example.com
3. アリス->はたたかれます(一口): ACK一口: bob@example.com
4. (Alice opens connection to Bob.) Alice->Bob (MSRP):
4. (アリスは接続をボブに公開します。) アリス->はたたかれます(MSRP):
MSRP d93kswow SEND
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-16/16
Content-Type: text/plain
MSRP d93kswow SEND To-経路: msrp://bob.example.com: 8888/9di4eae923wzd; tcp From-経路、: msrp://alicepc.example.com: 7777/iau39soe2843z; tcp Message-ID、: 12339sdqwerバイト範囲: 1-16/16コンテントタイプ: テキスト/平野
Hi, I'm Alice!
-------d93kswow$
こんにちは、私はアリスです! -------d93kswow$
5. Bob->Alice (MSRP):
5. >をたたいているアリス(MSRP):
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$
MSRP d93kswow200OK To-経路: msrp://alicepc.example.com: 7777/iau39soe2843z; tcp From-経路、: msrp://bob.example.com: 8888/9di4eae923wzd; tcp-------d93kswow$
Campbell, et al. Standards Track [Page 41] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[41ページ]。
6. Bob->Alice (MSRP):
6. >をたたいているアリス(MSRP):
MSRP dkei38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
Message-ID: 456s9wlk3
Byte-Range: 1-21/21
Content-Type: text/plain
MSRP dkei38sd SEND To-経路: msrp://alicepc.example.com: 7777/iau39soe2843z; tcp From-経路、: msrp://bob.example.com: 8888/9di4eae923wzd; tcp Message-ID、: 456s9wlk3バイト範囲: 1-21/21コンテントタイプ: テキスト/平野
Hi, Alice! I'm Bob!
-------dkei38sd$
こんにちは、アリス! 私はボブです! -------dkei38sd$
7. Alice->Bob (MSRP):
7. アリス->はたたかれます(MSRP):
MSRP dkei38sd 200 OK
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
-------dkei38sd$
MSRP dkei38sd200OK To-経路: msrp://bob.example.com: 8888/9di4eae923wzd; tcp From-経路、: msrp://alicepc.example.com: 7777/iau39soe2843z; tcp-------dkei38sd$
8. Alice->Bob (SIP): BYE sip:bob@example.com
8. アリス->はたたかれます(一口): BYE一口: bob@example.com
Alice invalidates local session state.
アリスは地方のセッション状態を無効にします。
9. Bob invalidates local state for the session.
9. ボブはセッションのために地方の状態を無効にします。
Bob->Alice (SIP): 200 OK
>をたたいているアリス(一口): 200 OK
11.2. Message with XHTML Content
11.2. XHTML内容があるメッセージ
MSRP dsdfoe38sd SEND To-Path: msrp://alice.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 456so39s Byte-Range: 1-374/374 Content-Type: application/xhtml+xml
MSRP dsdfoe38sd SEND To-経路: msrp://alice.example.com: 7777/iau39soe2843z; tcp From-経路、: msrp://bob.example.com: 8888/9di4eae923wzd; tcp Message-ID、: 456so39sバイト範囲: 1-374/374コンテントタイプ: アプリケーション/xhtml+xml
Campbell, et al. Standards Track [Page 42] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[42ページ]。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"_http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>FY2005 Results</title>
</head>
<body>
<p>See the results at <a
href="http://example.org/">example.org</a>.</p>
</body>
</html>
-------dsdfoe38sd$
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ_「><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML1.0の厳しい//アン」」 http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd_ 、「><html xmlnsは" http://www.w3.org/1999/xhtml "xmlと等しいです: ラングが「アン」ラング=と等しい、「アン、「</タイトル></ヘッド><ボディー><p>が<aにおける結果を見るという><ヘッド><タイトル>2005年度の結果が=をhrefする、「 http://example.org/ 、「>example.org</a></p></ボディー></html>」-------dsdfoe38sd$
Figure 13: Example Message with XHTML
図13: XHTMLがある例のメッセージ
11.3. Chunked Message
11.3. メッセージをChunkedしました。
For an example of a chunked message, see the example in Section 5.1.
chunkedメッセージの例に関しては、セクション5.1で例を見てください。
11.4. Chunked Message with Message/CPIM Payload
11.4. メッセージ/CPIM有効搭載量でメッセージをChunkedしました。
This example shows a chunked message containing a CPIM message that wraps a text/plain payload. It is worth noting that MSRP considers the complete CPIM message before chunking the message; thus, the CPIM headers are included in only the first chunk. The MSRP Content-Type and Byte-Range headers, present in both chunks, refer to the whole CPIM message.
この例はテキスト/明瞭なペイロードを包装するCPIMメッセージを含むchunkedメッセージを示しています。 MSRPが、分魂化の前の完全なCPIMメッセージがメッセージであると考えることに注意する価値があります。 したがって、CPIMヘッダーは最初の塊だけに含まれています。 両方の塊で出席しているMSRPコンテントタイプとByte-範囲ヘッダーは全体のCPIMメッセージを示します。
MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-137/148
Content-Type: message/cpim
MSRP d93kswow SEND To-経路: msrp://bobpc.example.com: 8888/9di4eae923wzd; tcp From-経路、: msrp://alicepc.example.com: 7654/iau39soe2843z; tcp Message-ID、: 12339sdqwerバイト範囲: 1-137/148コンテントタイプ: メッセージ/cpim
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Type: text/plain
To: ボブ<一口: bob@example.com 、gt;、From: アリス<一口: alice@example.com 、gt;、DateTime: 2006-05-15 T15: 2時31分から3時0分コンテントタイプ: テキスト/平野
ABCD
-------d93kswow+
ABCD-------d93kswow+
Figure 14: First Chunk
図14: 最初の塊
Campbell, et al. Standards Track [Page 43] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[43ページ]。
Alice sends the second and last chunk.
アリスは2番目と最後の塊を送ります。
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 138-148/148
Content-Type: message/cpim
MSRP op2nc9a SEND To-経路: msrp://bobpc.example.com: 8888/9di4eae923wzd; tcp From-経路、: msrp://alicepc.example.com: 7654/iau39soe2843z; tcp Message-ID、: 12339sdqwerバイト範囲: 138-148/148コンテントタイプ: メッセージ/cpim
1234567890
-------op2nc9a$
1234567890 -------op2nc9a$
Figure 15: Second Chunk
図15: 第2塊
11.5. System Message
11.5. システムメッセージ
Sysadmin->Alice (MSRP):
Sysadmin>のアリス(MSRP):
MSRP d93kswow SEND To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp From-Path: msrp://example.com:7777/iau39soe2843z;tcp Message-ID: 12339sdqwer Byte-Range: 1-38/38 Failure-Report: no Success-Report: no Content-Type: text/plain
MSRP d93kswow SEND To-経路: msrp://alicepc.example.com: 8888/9di4eae923wzd; tcp From-経路、: msrp://example.com: 7777/iau39soe2843z; tcp Message-ID、: 12339sdqwerバイト範囲: 1-38/38 異常報告書: Success-レポートがありません: コンテントタイプがありません: テキスト/平野
This conference will end in 5 minutes -------d93kswow$
この会議は5分で終わるでしょう。-------d93kswow$
11.6. Positive Report
11.6. 積極的なレポート
Alice->Bob (MSRP):
アリス->はたたかれます(MSRP):
MSRP d93kswow SEND To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Success-Report: yes Failure-Report: no Content-Type: text/html
MSRP d93kswow SEND To-経路: msrp://bob.example.com: 8888/9di4eae923wzd; tcp From-経路、: msrp://alicepc.example.com: 7777/iau39soe2843z; tcp Message-ID、: 12339sdqwerバイト範囲: 1-106/106 成功レポート: はいFailure-レポート: コンテントタイプがありません: テキスト/html
Campbell, et al. Standards Track [Page 44] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[44ページ]。
<html><body> <p>Here is that important link... <a href="http://www.example.com/foobar">foobar</a> </p> </body></html> -------d93kswow$
<html><ボディー><p>Hereはその重要なリンクです… <a hrefが等しい、「 http://www.example.com/foobar 「>foobar</a></p></ボディー></html>」-------d93kswow$
Figure 16: Initial SEND Request
図16: イニシャルは要求を送ります。
Bob->Alice (MSRP):
>をたたいているアリス(MSRP):
MSRP dkei38sd REPORT To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp Message-ID: 12339sdqwer Byte-Range: 1-106/106 Status: 000 200 OK -------dkei38sd$
MSRP dkei38sd REPORT To-経路: msrp://alicepc.example.com: 7777/iau39soe2843z; tcp From-経路、: msrp://bob.example.com: 8888/9di4eae923wzd; tcp Message-ID、: 12339sdqwerバイト範囲: 1-106/106状態: 000 200OK-------dkei38sd$
Figure 17: Success Report
図17: 成功レポート
11.7. Forked IM
11.7. 股状、不-
Traditional IM systems generally do a poor job of handling multiple simultaneous IM clients online for the same person. While some do a better job than many existing systems, handling of multiple clients is fairly crude. This becomes a much more significant issue when always-on mobile devices are available, but it is desirable to use them only if another IM client is not available.
一般に、伝統的なIMシステムは同じ人にとっての、オンラインの複数の同時のIMクライアントを取り扱いの不十分な仕事にします。 或るものは多くの既存のシステムより良い仕事をしますが、複数のクライアントの取り扱いはかなり粗雑です。 いつもオンなモバイル機器が利用可能であるときに、これははるかに重要な問題になりますが、別のIMクライアントが手があかない場合にだけ、それらを使用するのは望ましいです。
Using SIP makes rendezvous decisions explicit, deterministic, and very flexible. In contrast, "page-mode" IM systems use implicit implementation-specific decisions that IM clients cannot influence. With SIP session-mode messaging, rendezvous decisions can be under control of the client in a predictable, interoperable way for any host that implements callee capabilities [31]. As a result, rendezvous policy is managed consistently for each address of record.
SIPを使用するのに、ランデブー決定は明白で、決定論で、非常にフレキシブルになります。 対照的に、「ページモード」IMシステムはIMクライアントが影響を及ぼすことができない暗黙の実現特有の決定を使用します。 SIPセッションモードが通信している状態で、訪問される人能力[31]を実行するどんなホストにとっても、ランデブー決定は予測できて、共同利用できる方法でクライアントで制御されている場合があります。 その結果、ランデブー方針は各記録されている住所のために一貫して管理されます。
The following example shows Juliet with several IM clients where she can be reached. Each of these has a unique SIP contact and MSRP session. The example takes advantage of SIP's capability to "fork" an invitation to several contacts in parallel, in sequence, or in combination. Juliet has registered from her chamber, the balcony, her PDA, and as a last resort, you can leave a message with her nurse. Juliet's contacts are listed below. The q-values express relative preference (q=1.0 is the highest preference).
以下の例は、どこに彼女に連絡できるかを数人のIMクライアントと一緒にいるジュリエットに示します。 それぞれのこれらには、ユニークなSIP接触とMSRPセッションがあります。 例は平行な数個の接触、連続して、または組み合わせにおける招待状を「分岐させる」SIPの能力を利用します。 ジュリエットは彼女の部屋から登録しました、バルコニー、彼女のPDA、そして、最後の手段として、あなたが彼女の看護婦にメッセージを預けることができます。 ジュリエットの接触は以下に記載されています。 q-値は相対的選好を言い表します(q=1.0は最も高い好みです)。
Campbell, et al. Standards Track [Page 45] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[45ページ]。
When Romeo opens his IM program, he selects Juliet and types the message "art thou hither?" (instead of "you there?"). His client sends a SIP invitation to sip:juliet@thecapulets.example.com. The proxy there tries first the balcony and the chamber simultaneously. A client is running on each of those systems, both of which set up early sessions of MSRP with Romeo's client. The client automatically sends the message over MSRP to the two MSRP URIs involved. After a delay of a several seconds with no reply or activity from Juliet, the proxy cancels the invitation at her first two contacts, and forwards the invitation on to Juliet's PDA. Since her father is talking to her about her wedding, she selects "Do Not Disturb" on her PDA, which sends a "Busy Here" response. The proxy then tries the nurse, who answers and tells Romeo what is going on.
ロメオが彼のIMプログラムを開くと、彼がジュリエットを選んで、メッセージをタイプする、「芸術、なんじ、こちらに、」 の代わりにする、(「あなた、そこ?、」、) 彼のクライアントはちびちび飲むSIP招待状を送ります: juliet@thecapulets.example.com 。 そこのプロキシは同時に、最初に、バルコニーと部屋を試みます。 クライアントはそれぞれのそれらのシステムで動いています。その両方がロメオのクライアントとのMSRPの前場をセットアップします。 クライアントは自動的にURIがかかわった2MSRPへのMSRPの上にメッセージを送ります。 ジュリエットから回答も活動のない数秒の遅れの後に、プロキシは、彼女の最初の2つの接触で招待を中止して、ジュリエットのPDAに招待を送ります。 彼女の父親が彼女の結婚式に関して彼女と話しているので、彼女は彼女のPDAの上で「擾乱しないでください」を選択します。PDAは「ここの忙しさに」応答を送ります。 そして、プロキシは看護婦を裁きます。(その看護婦は、何が起こっているかをロメオに答えて、言います)。
Campbell, et al. Standards Track [Page 46] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[46ページ]。
Romeo Juliet's Juliet/ Juliet/ Juliet/ Nurse
Proxy balcony chamber PDA
| | | | | |
|--INVITE--->| | | | |
| |--INVITE--->| | | |
| |<----180----| | | |
|<----180----| | | | |
|---PRACK---------------->| | | |
|<----200-----------------| | | |
|<===Early MSRP Session==>| art thou hither? | |
| | | | | |
| |--INVITE---------------->| | |
| |<----180-----------------| | |
|<----180----| | | | |
|---PRACK----------------------------->| | |
|<----200------------------------------| | |
|<========Early MSRP Session==========>| art thou hither? |
| | | | | |
| | | | | |
| | .... Time Passes .... | | |
| | | | | |
| | | | | |
| |--CANCEL--->| | | |
| |<---200-----| | | |
| |<---487-----| | | |
| |----ACK---->| | | |
| |--CANCEL---------------->| | |
| |<---200------------------| | |
| |<---487------------------| | |
| |----ACK----------------->| | |
| |--INVITE---------------------------->| romeo wants
| | | | | to IM w/ you
| |<---486 Busy Here--------------------| |
| |----ACK----------------------------->| |
| | | | | |
| |--INVITE---------------------------------------->|
| |<---200 OK---------------------------------------|
|<--200 OK---| | | | |
|---ACK------------------------------------------------------->|
|<================MSRP Session================================>|
| | | | | |
| Hi Romeo, Juliet is |
| with her father now |
| can I take a message?|
| |
| Tell her to go to confession tomorrow.... |
ロメオ・ジュリエットのJuliet/ Juliet/ Juliet/看護婦Proxyバルコニー部屋PDA| | | | | | |--招待--->|、|、|、|、|、| |--招待--->|、|、|、|、| | <、-、-、--180----| | | | | <、-、-、--180----| | | | | |---PRACK---------------->|、|、|、| | <、-、-、--200-----------------| | | | |<==早めのMSRPセッション=>| 芸術、なんじ、こちらに? | | | | | | | | | |--招待---------------->|、|、|、| | <、-、-、--180-----------------| | | | <、-、-、--180----| | | | | |---PRACK----------------------------->|、|、| | <、-、-、--200------------------------------| | | |<====早めのMSRPセッション==========>| 芸術、なんじ、こちらに? | | | | | | | | | | | | | | | .... 時間は経過します… | | | | | | | | | | | | | | | | |--キャンセル--->|、|、|、|、| | <、-、--200-----| | | | | | <、-、--487-----| | | | | |----ACK---->|、|、|、|、| |--キャンセル---------------->|、|、|、| | <、-、--200------------------| | | | | <、-、--487------------------| | | | |----ACK----------------->|、|、|、| |--招待---------------------------->| romeo必需品| | | | | あなたがいるIMに| | <、-、--486はここで忙しくします。--------------------| | | |----ACK----------------------------->|、|、|、|、|、|、|、|、| |--招待---------------------------------------->|、| | <、-、--200 OK---------------------------------------| | <--200 OK---| | | | | |---ACK------------------------------------------------------->| |<========MSRPセッション================================>|、|、|、|、|、|、|、| こんにちは、ロメオ、ジュリエットはそうです。| | 現在の彼女の父親と共に| | 私が伝言をいただいてもよいか、|| | | 明日懺悔に行くように彼女に言ってください… |
Figure 18: Forking Example
図18: 例を分岐させます。
Campbell, et al. Standards Track [Page 47] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[47ページ]。
12. Extensibility
12. 伸展性
MSRP was designed to be only minimally extensible. New MSRP methods, header fields, and status codes can be defined in standards-track RFCs. MSRP does not contain a version number or any negotiation mechanism to require or discover new features. If an extension is specified in the future that requires negotiation, the specification will need to describe how the extension is to be negotiated in the encapsulating signaling protocol. If a non-interoperable update or extension occurs in the future, it will be treated as a new protocol, and MUST describe how its use will be signaled.
MSRPは、最少量でだけ広げることができるように設計されました。 標準化過程RFCsで新しいMSRP方法、ヘッダーフィールド、およびステータスコードを定義できます。 MSRPは新機能を必要である、または発見するバージョン番号かどんな交渉メカニズムも含んでいません。 拡大が交渉を必要とする未来に指定されると、仕様は、プロトコルに合図しながら要約で交渉される拡大がことである方法を説明する必要があるでしょう。 非共同利用できるアップデートか拡大が将来起こるなら、それは、新しいプロトコルとして扱われて、使用がどう合図されるかを説明しなければなりません。
In order to allow extension header fields without breaking interoperability, if an MSRP device receives a request or response containing a header field that it does not understand, it MUST ignore the header field and process the request or response as if the header field was not present. If an MSRP device receives a request with an unknown method, it MUST return a 501 response.
MSRP装置がそれが理解していないヘッダーフィールドを含む要求か応答を受け取るなら壊れている相互運用性なしで拡大ヘッダーフィールドを許容するために、まるでヘッダーフィールドが存在していないかのように、それは、ヘッダーフィールドを無視して、要求か応答を処理しなければなりません。 MSRP装置が未知の方法で要求を受け取るなら、それは501応答を返さなければなりません。
MSRP was designed to use lists of URIs instead of a single URI in the To-Path and From-Path header fields in anticipation of relay or gateway functionality being added. In addition, "msrp" and "msrps" URIs can contain parameters that are extensible.
MSRPは、加えられるリレーかゲートウェイの機能性を予測してTo-経路とFrom-経路ヘッダーフィールドにおけるただ一つのURIの代わりにURIのリストを使用するように設計されました。 さらに、"msrp"と"msrps"URIは広げることができるパラメタを含むことができます。
13. CPIM Compatibility
13. CPIMの互換性
MSRP sessions may go to a gateway to other Common Profile for Instant Messaging (CPIM) [27] compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics, which do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [12] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP accept-types attribute. MSRP endpoints sending instant messages to a peer that has included "message/cpim" as the first entry in the accept-types attribute SHOULD encapsulate all instant message bodies in "message/ cpim" wrappers. All MSRP endpoints MUST support the message/cpim type, and SHOULD support the S/MIME[7] features of that format.
MSRPセッションはInstant Messaging(CPIM)の[27]コンパチブルプロトコルに他のCommon Profileへのゲートウェイに行くかもしれません。 これが起こるなら、ゲートウェイは、セッション状態を維持しなければならなくて、MSRPセッション意味論とCPIM意味論の間で翻訳されなければなりません。意味論はセッションの概念を含んでいません。 セッションのある終点がCPIMゲートウェイであるときに、その上、瞬間は包装されたコネが「メッセージ/cpim」[12]ボディーであったならSHOULDを通信させます。 そのようなゲートウェイは初記入としてタイプを受け入れているSDP属性に「メッセージ/cpim」を含まなければなりません。 初記入としてタイプを受け入れている属性SHOULDに「メッセージ/cpim」を含んでいた同輩にインスタントメッセージを送るMSRP終点が「メッセージ/cpim」包装紙ですべてのインスタントメッセージ本体を要約します。 すべてのMSRP終点がメッセージ/cpimタイプを支持しなければなりません、そして、SHOULDはその形式のS/MIME[7]機能を支持します。
If a message is to be wrapped in a message/cpim envelope, the wrapping MUST be done prior to breaking the message into chunks, if needed.
メッセージを塊に細かく分ける前にメッセージがメッセージ/cpim封筒で包装することであるなら、ラッピングをしなければなりません、必要であるなら。
Campbell, et al. Standards Track [Page 48] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[48ページ]。
All MSRP endpoints MUST recognize the From, To, DateTime, and Require header fields as defined in RFC 3862. Such applications SHOULD recognize the CC header field, and MAY recognize the Subject header field. Any MSRP application that recognizes any message/cpim header field MUST understand the NS (name space) header field.
すべてのMSRP終点がRFC3862で定義されるようにFrom、To、DateTime、およびRequireヘッダーフィールドを認識しなければなりません。 そのようなアプリケーションSHOULDは、CCヘッダーがSubjectヘッダーフィールドをさばいて、認めるかもしれないと認めます。 どんなメッセージ/cpimヘッダーフィールドも認識するどんなMSRPアプリケーションもNS(名前スペース)ヘッダーフィールドを理解しなければなりません。
All message/cpim body parts sent by an MSRP endpoint MUST include the From and To header fields. If the message/cpim body part is protected using S/MIME, then it MUST also include the DateTime header field.
MSRP終点によって送られたすべてのメッセージ/cpim身体の部分がFromとToヘッダーフィールドを含まなければなりません。 また、メッセージ/cpim身体の部分がS/MIMEを使用することで保護されるなら、それはDateTimeヘッダーフィールドを含まなければなりません。
The NS, To, and CC header fields may occur multiple times. Other header fields defined in RFC 3862 MUST NOT occur more than once in a given message/cpim body part in an MSRP message. The Require header field MAY include multiple values. The NS header field MAY occur zero or more times, depending on how many name spaces are being referenced.
NS、To、およびCCヘッダーフィールドは複数の回現れるかもしれません。 RFC3862で定義された他のヘッダーフィールドはMSRPメッセージの与えられたメッセージ/cpim身体の部分の一度より起こってはいけません。 Requireヘッダーフィールドは複数の値を含むかもしれません。 いくつの名前空間が参照をつけられているかによって、NSヘッダーフィールドはゼロか、より多くの回起こるかもしれません。
Extension header fields MAY occur more than once, depending on the definition of such header fields.
拡大ヘッダーフィールドは一度より起こるかもしれなくて、そのようなものの定義への依存はヘッダーフィールドです。
Using message/cpim envelopes is also useful if an MSRP device
wishes to send a message on behalf of some other identity. The
device may add a message/cpim envelope with the appropriate From
header field value.
また、MSRP装置がある他のアイデンティティを代表してメッセージを送りたいなら、メッセージ/cpim封筒を使用するのも役に立ちます。 装置は適切なFromヘッダーフィールド価値でメッセージ/cpim封筒を加えるかもしれません。
14. Security Considerations
14. セキュリティ問題
Instant messaging systems are used to exchange a variety of sensitive information ranging from personal conversations, to corporate confidential information, to account numbers and other financial trading information. IM is used by individuals, corporations, and governments for communicating important information. IM systems need to provide the properties of integrity and confidentiality for the exchanged information, and the knowledge that you are communicating with the correct party, and they need to allow the possibility of anonymous communication. MSRP pushes many of the hard problems to SIP when SIP sets up the session, but some of the problems remain. Spam and Denial of Service (DoS) attacks are also very relevant to IM systems.
インスタントメッセージングシステムは、数を説明するために個人的な会話から法人の秘密情報まで及ぶさまざまな機密情報と他の財政的な取り引き情報を交換するのに使用されます。 IMは、重要情報を伝えるのに個人、会社、および政府によって使用されます。 IMシステムは、交換された情報、およびあなたが正しいパーティーとコミュニケートしていて、匿名のコミュニケーションの可能性を許容するのが必要であるという知識に保全と秘密性の資産を提供する必要があります。 SIPがセッションをセットアップするとき、MSRPは難問の多くをSIPに押しますが、問題のいくつかが残っています。 また、スパムとサービス妨害(DoS)攻撃もIMシステムに非常に関連しています。
MSRP needs to provide confidentiality and integrity for the messages it transfers. It also needs to provide assurances that the connected host is the host that it meant to connect to and that the connection has not been hijacked.
MSRPは、それが移すメッセージに秘密性と保全を提供する必要があります。 また、それは、接続ホストが接するそれが、意味したホストであり、接続がハイジャックされていないという保証を提供する必要があります。
Campbell, et al. Standards Track [Page 49] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[49ページ]。
14.1. Secrecy of the MSRP URI
14.1. MSRP URIの秘密主義
When an endpoint sends an MSRP URI to its peer in a rendezvous protocol, that URI is effectively a secret shared between the peers. If an attacker learns or guesses the URI prior to the completion of session setup, it may be able to impersonate one of the peers.
終点がランデブープロトコルでMSRP URIを同輩に送るとき、事実上、そのURIは同輩の間で共有された秘密です。 攻撃者がセッションセットアップの完成の前にURIを学ぶか、または推測するなら、同輩のひとりをまねることができるかもしれません。
Assuming the URI exchange in the rendezvous protocol is sufficiently protected, it is critical that the URI remain difficult to "guess" via brute force methods. Most components of the URI, such as the scheme and the authority components, are common knowledge. The secrecy is entirely provided by the session-id component.
獣の力の方法で「推測すること」が難しいままでURIが残っているのは、URIがランデブープロトコルで交換であると仮定するのが十分保護されることに批判的です。 URIの計画や権威コンポーネントなどのほとんどの部品が周知の事実です。 セッションイドコンポーネントは秘密主義を完全に提供します。
Therefore, when an MSRP device generates an MSRP URI to be used in the initiation of an MSRP session, the session-id component MUST contain at least 80 bits of randomness.
したがって、MSRP装置がMSRPセッションの開始に使用されるためにMSRP URIを発生させるとき、セッションイドコンポーネントは偶発性の少なくとも80ビットを含まなければなりません。
14.2. Transport Level Protection
14.2. 平らな保護を輸送してください。
When using only TCP connections, MSRP security is fairly weak. If host A is contacting host B, B passes its hostname and a secret to A using a rendezvous protocol. Although MSRP requires the use of a rendezvous protocol with the ability to protect this exchange, there is no guarantee that the protection will be used all the time. If such protection is not used, anyone can see this secret. Host A then connects to the provided hostname and passes the secret in the clear across the connection to B. Host A assumes that it is talking to B based on where it sent the SYN packet and then delivers the secret in plain text across the connections. Host B assumes it is talking to A because the host on the other end of the connection delivered the secret. An attacker that could ACK the SYN packet could insert itself as a man-in-the-middle in the connection.
TCP接続だけを使用するとき、MSRPセキュリティはかなり弱いです。 ホストAがホストBに連絡しているなら、Bは、ランデブープロトコルを使用することでホスト名と秘密をAに通過します。 MSRPはこの交換を保護する能力でランデブープロトコルの使用を必要としますが、絶えず、保護が使用されるという保証が全くありません。 そのような保護が使用されていないなら、だれでもこの秘密を見ることができます。 ホストAは、Host Aが仮定するB.とのそれがそれがどこにSYNパケットを送って、次に、接続の向こう側にプレーンテキストの秘密を果たすかに基づくBと話している接続の向こう側の明確で次に、提供されたホスト名に接続して、秘密を通過します。 ホストBは、接続のもう一方の端のホストが秘密を送ったのでそれがAと話していると仮定します。 そうすることができた攻撃者、ACK、SYNパケットは中央の接続という男性としてそれ自体を挿入するかもしれません。
When using TLS connections, the security is significantly improved. We assume that the host accepting the connection has a certificate from a well-known certification authority. Furthermore, we assume that the signaling to set up the session is protected by the rendezvous protocol. In this case, when host A contacts host B, the secret is passed through a confidential channel to A. A connects with TLS to B. B presents a valid certificate, so A knows it really is connected to B. A then delivers the secret provided by B, so that B can verify it is connected to A. In this case, a rogue SIP Proxy can see the secret in the SIP signaling traffic and could potentially insert itself as a man-in-the-middle.
TLS接続を使用するとき、セキュリティはかなり向上されています。 私たちは、接続を受け入れるホストが周知の証明権威からの証明書を持っていると思います。 その上、私たちは、セッションに設定するシグナリングがランデブープロトコルによって保護されると思います。 ホストAがこの場合ホストBに連絡するとき、秘密がAがBが有効な証明書を提示するB.へのTLSに接続するA.への秘密のチャンネルに通り抜けるので、Aは、それが本当に次にAがBによって提供された秘密を送るB.に接続されて、したがって、Bがそれについて確かめることができるのがA.In本件に関連づけられて、凶暴なSIP ProxyがSIPの秘密が交通を示しているのを見ることができて、中央の男性として潜在的にそれ自体を挿入できたのを知っています。
Realistically, using TLS with certificates from well-known certification authorities is difficult for peer-to-peer connections, as the types of hosts that end clients use for sending instant
現実的に、ピアツーピア接続には、周知の証明当局からの証明書があるTLSを使用するのは難しいです、終わりのクライアントが発信瞬間に使用するホストのタイプとして
Campbell, et al. Standards Track [Page 50] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[50ページ]。
messages are unlikely to have long-term stable IP addresses or DNS names that the certificates can bind to. In addition, the cost of server certificates from well-known certification authorities is currently expensive enough to discourage their use for each client. Using TLS in a peer-to-peer mode without well-known certificates is discussed in Section 14.4.
メッセージには、長期の安定したIPアドレスか証明書が付くことができるDNS名がありそうにはありません。 さらに、周知の証明当局からのサーバ証明書の費用は現在、彼らのそれぞれのクライアントの使用に水をさすことができるくらい高価です。 セクション14.4で周知の証明書なしでピアツーピアモードでTLSを使用するのと議論します。
TLS becomes much more practical when some form of relay is introduced. Clients can then form TLS connections to relays, which are much more likely to have TLS certificates. While this specification does not address such relays, they are described by a companion document [23]. That document makes extensive use of TLS to protect traffic between clients and relays, and between one relay and another.
何らかの形式のリレーを導入するとき、TLSははるかに実用的になります。 そして、クライアントはTLS接続をリレーに形成できます。(リレーはTLS証明書をはるかに持っていそうです)。 この仕様がそのようなリレーを記述していない間、それらは仲間ドキュメント[23]によって説明されます。 そのドキュメントは、クライアントとリレーと、1個のリレーと別のものの間の交通を保護するためにTLSの大規模な使用をします。
TLS is used to authenticate devices and to provide integrity and confidentiality for the header fields being transported. MSRP elements MUST implement TLS and MUST also implement the TLS ClientExtendedHello extended hello information for server name indication as described in [11]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [13] MUST be supported (other cipher- suites MAY also be supported).
TLSは、装置を認証して、保全と秘密性を輸送されるヘッダーフィールドに提供するのに使用されます。 MSRP要素がTLSを実行しなければならなくて、また、広げられたTLS ClientExtendedHelloを実行しなければならない、こんにちは、[11]で説明されるサーバー名指示のための情報。 TLS_RSA_WITH_AES_128_CBC_SHA[13]のTLS暗号スイートを支えなければなりません(また、他の暗号スイートは支えられるかもしれません)。
14.3. S/MIME
14.3. S/MIME
The only strong security for non-TLS connections is achieved using S/MIME.
唯一の非TLS接続に、強いセキュリティが、S/MIMEを使用することで達成されます。
Since MSRP carries arbitrary MIME content, it can trivially carry S/MIME protected messages as well. All MSRP implementations MUST support the multipart/signed media-type even if they do not support S/MIME. Since SIP can carry a session key, S/MIME messages in the context of a session could also be protected using a key-wrapped shared secret [28] provided in the session setup. MSRP can carry unencoded binary payloads. Therefore, MIME bodies MUST be transferred with a transfer encoding of binary. If a message is both signed and encrypted, it SHOULD be signed first, then encrypted. If S/MIME is supported, SHA-1, SHA-256, RSA, and AES-128 MUST be supported. For RSA, implementations MUST support key sizes of at least 1024 bits and SHOULD support key sizes of 2048 bits or more.
MSRPが任意のMIME内容を運ぶので、それはまた、S/MIMEの保護されたメッセージを些細なことに伝えることができます。 S/MIMEを支持しないでも、すべてのMSRP実現が複合の、または、サインされたメディアタイプを支持しなければなりません。 SIPがセッションキーを運ぶことができるので、また、セッションセットアップに提供されたキーで包装された共有秘密キー[28]を使用することでセッションの文脈のS/MIMEメッセージを保護できるでしょう。 MSRPは暗号化されていない2進のペイロードを運ぶことができます。 したがって、転送がバイナリーをコード化している状態で、MIME本体を移さなければなりません。 メッセージは、aであるならサインされて、かつコード化されていて、それはSHOULDです。最初に、サインされて、次に、コード化されます。 S/MIMEが支持されるか、そして、SHA-1、SHA-256、RSA、およびAES-128 MUST、支持されてください。 RSAに関しては、実現は少なくとも1024ビットの主要なサイズを支持しなければなりません、そして、SHOULDは2048ビット以上の主要なサイズを支持します。
This does not actually require the endpoint to have certificates from a well-known certification authority. When MSRP is used with SIP, the Identity [17] and Certificates [25] mechanisms provide S/MIME- based delivery of a secret between A and B. No SIP intermediary except the explicitly trusted authentication service (one per user) can see the secret. The S/MIME encryption of the SDP can also be used by SIP to exchange keying material that can be used in MSRP.
これは、実際に終点には周知の証明権威からの証明書があるのを必要としません。 MSRPがSIPと共に使用されるとき、Identity[17]とCertificates[25]メカニズムはAとBとの間に秘密のS/MIMEのベースの配送を提供します。明らかに信じられた認証サービス(1ユーザあたり1つ)以外のどんなSIP仲介者も秘密を見ることができません。 また、SIPはMSRPで使用できる材料を合わせる交換にSDPのS/MIME暗号化を使用できます。
Campbell, et al. Standards Track [Page 51] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[51ページ]。
The MSRP session can then use S/MIME with this keying material to sign and encrypt messages sent over MSRP. The connection can still be hijacked since the secret is sent in clear text to the other end of the TCP connection, but the consequences are mitigated if all the MSRP content is signed and encrypted with S/MIME. Although out of scope for this document, the SIP negotiation of an MSRP session can negotiate symmetric keying material to be used with S/MIME for integrity and privacy.
MSRPセッションは、次に、サインするために材料を合わせるこれと共にS/MIMEを使用して、MSRPの上に送られたメッセージをコード化できます。 クリアテキストで秘密を送るので、TCP接続のもう一方の端までまだ接続をハイジャックできますが、すべてのMSRP内容がS/MIMEでサインされて、コード化されるなら、結果は緩和されます。 MSRPセッションのSIP交渉は保全とプライバシーにS/MIMEと共に使用されるために材料を合わせながら、このドキュメントのための範囲から左右対称の状態で交渉されることができますが。
14.4. Using TLS in Peer-to-Peer Mode
14.4. ピアツーピアモードでTLSを使用します。
TLS can be used with a self-signed certificate as long as there is a mechanism for both sides to ascertain that the other side used the correct certificate. When used with SDP and SIP, the correct certificate can be verified by passing a fingerprint of the certificate in the SDP and ensuring that the SDP has suitable integrity protection. When SIP is used to transport the SDP, the integrity can be provided by the SIP Identity mechanism [17]. The rest of this section describes the details of this approach.
反対側が正しい証明書を使用したのを確かめるために両側へのメカニズムがある限り、自己署名入りの証書と共にTLSを使用できます。 SDPとSIPと共に使用されると、SDPの証明書の指紋を渡して、SDPには適当な保全保護があるのを確実にすることによって、正しい証明書について確かめることができます。 SDPを輸送するのにSIPを使用するとき、SIP Identityメカニズム[17]は保全を提供できます。 このセクションの残りはこのアプローチの詳細について説明します。
If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the URI of the user. In SIP, this URI of the user is the User's Address of Record (AOR). This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. Unlike normal TLS operations in this protocol, when doing peer-to-peer TLS, the subjectAltName is not an important component of the certificate verification. If the endpoint is also able to make anonymous sessions, a distinct, unique certificate MUST be used for this purpose. For a client that works with multiple users, each user SHOULD have its own certificate. Because the generation of public/private key pairs is relatively expensive, endpoints are not required to generate certificates for each session.
自己署名入りの証書が使用されているなら、証明書におけるsubjectAltName属性の内容はユーザのURIを使用するかもしれません。 SIPでは、ユーザのこのURIはUserのRecord(AOR)のAddressです。 これは、デバッグ目的だけの役に立って、コミュニケーション終点の1つに証明書を縛るのに必要ではありません。 ピアツーピアTLSをするときのこのプロトコルにおける通常のTLS操作と異なって、subjectAltNameは証明書検証の重要なコンポーネントではありません。 また、終点が匿名のセッションをすることができるなら、このために異なって、ユニークな証明書を使用しなければなりません。 複数のユーザと共に働いているクライアントに関しては、それぞれのユーザSHOULDには、それ自身の証明書があります。 公衆/秘密鍵組の世代が比較的高価であるので、終点は各セッションのための証明書を作るのに必要ではありません。
A certificate fingerprint is the output of a one-way hash function computed over the Distinguished Encoding Rules (DER) form of the certificate. The endpoint MUST use the certificate fingerprint attribute as specified in [18] and MUST include this in the SDP. The certificate presented during the TLS handshake needs to match the fingerprint exchanged via the SDP, and if the fingerprint does not match the hashed certificate then the endpoint MUST tear down the media session immediately.
証明書指紋は証明書のDistinguished Encoding Rules(DER)フォームで計算された片道ハッシュ関数の出力です。 終点は、[18]の指定されるとしての証明書指紋属性を使用しなければならなくて、SDPにこれを含まなければなりません。 TLS握手の間に提示された証明書は、SDPを通して交換された指紋を合わせる必要があります、そして、指紋が論じ尽くされた証明書に合っていないなら、終点はすぐに、メディアセッションを取りこわさなければなりません。
When using SIP, the integrity of the fingerprint can be ensured through the SIP Identity mechanism [17]. When a client wishes to use SIP to set up a secure MSRP session with another endpoint, it sends an SDP offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, the fingerprint of the
SIPを使用するとき、SIP Identityメカニズム[17]を通して指紋の保全を確実にすることができます。 クライアントが別の終点との安全なMSRPセッションをセットアップするのにSIPを使用したがっているとき、それはSIPメッセージにおけるSDP申し出をもう片方の終点に送ります。 この申し出はSDPペイロードの一部としての指紋を含んでいます。
Campbell, et al. Standards Track [Page 52] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[52ページ]。
certificate that the endpoint wants to use. The SIP message containing the offer is sent to the offerer's SIP proxy, which will add an Identity header according to the procedures outlined in [17]. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header. Since the Identity header is a digital signature across several SIP headers, in addition to the body or bodies of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was added to the SIP message.
終点が使用したがっている証明書。 申し出を含むSIPメッセージを申出人のSIPプロキシに送ります。([17]に概説された手順によると、プロキシはIdentityヘッダーを加えるでしょう)。 遠い終点がSIPメッセージを受け取るとき、それは、Identityヘッダーを使用することで送付者のアイデンティティについて確かめることができます。 Identityヘッダーが数個のSIPヘッダーの向こう側のデジタル署名であるので、SIPメッセージのボディーかボディーに加えて、受信機もまた、デジタル署名がSIPメッセージに追加された後にメッセージがいじられていないのを確信している場合があります。
An example of SDP with a fingerprint attribute is shown in the following figure. Note the fingerprint is shown spread over two lines due to formatting consideration but should all be on one line.
指紋属性があるSDPに関する例は以下の図に示されます。 指紋が形式の考慮のため2つ以上の系列を広げてくださいが、すべてが1つの系列にあるべきであるのが示されることに注意してください。
c=IN IP4 atlanta.example.com
m=message 7654 TCP/TLS/MSRP *
a=accept-types:text/plain
a=path:msrps://atlanta.example.com:7654/jshA7weso3ks;tcp
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
メッセージ..受け入れる..タイプ..テキスト..平野..経路..指紋を採取する..西暦
Figure 19: SDP with Fingerprint Attribute
図19: 指紋属性があるSDP
14.5. Other Security Concerns
14.5. 他の安全上の配慮
MSRP cannot be used as an amplifier for DoS attacks, but it can be used to form a distributed attack to consume TCP connection resources on servers. The attacker, Mallory, sends a SIP INVITE with no offer to Alice. Alice returns a 200 with an offer and Mallory returns an answer with SDP indicating that his MSRP address is the address of Tom. Since Alice sent the offer, Alice will initiate a connection to Tom using up resources on Tom's server. Given the huge number of IM clients, and the relatively few TCP connections that most servers support, this is a fairly straightforward attack.
DoSのためのアンプが攻撃されるとき、MSRPを使用できませんが、サーバに関するTCP接続リソースを消費するために分配された攻撃を形成するのにそれを使用できます。 攻撃者(Mallory)はノー・オファーがあるSIP INVITEをアリスに送ります。 アリスは申し出と共に200を返します、そして、SDPが、彼のMSRPアドレスがトムのアドレスであることを示していて、Malloryは返答します。 アリスが申し出を送ったので、アリスはトムのサーバに関するリソースを使いきるトムに接続を開始するでしょう。IMクライアントの巨大な数、およびほとんどのサーバがサポートする比較的わずかなTCP接続を考えて、これはかなり簡単な攻撃です。
SIP is attempting to address issues in dealing with spam. The spam issue is probably best dealt with at the SIP level when an MSRP session is initiated and not at the MSRP level.
SIPは、スパムに対処する際に問題を扱うのを試みています。 SIPレベルでMSRPセッションが開始されていずれのMSRPレベルにもないとき、たぶんスパム問題に対処するのは最も良いです。
If a sender chooses to employ S/MIME to protect a message, all S/MIME operations apply to the complete message, prior to any breaking of the message into chunks.
送付者が、メッセージを保護するのにS/MIMEを使うのを選ぶなら、すべてのS/MIME操作が完全なメッセージに適用されます、塊へのメッセージをどんな壊すことの前に。
The signaling will have set up the session to or from some specific URIs that will often have "im:" or "sip:" URI schemes. When the signaling has been set up to a specific end user, and S/MIME is implemented, then the client needs to verify that the name in the SubjectAltName of the certificate contains an entry that matches the
シグナリングがURI、または、それがしばしば持っているいくつかの特定のURIからのセッションをセットアップしてしまうだろう、「不-、:、」 または、「ちびちび飲んでください」 URI体系。 シグナリングは特定のエンドユーザまで設定されました、そして、S/MIMEは実装されます、そして、次に、クライアントは証明書のSubjectAltNameの名前が合っているエントリーを含むことを確かめる必要があります。
Campbell, et al. Standards Track [Page 53] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[53ページ]。
URI that was used for the other end in the signaling. There are some cases, such as IM conferencing, where the S/MIME certificate name and the signaled identity will not match. In these cases, the client should ensure that the user is informed that the message came from the user identified in the certificate and does not assume that the message came from the party they signaled.
シグナリングへのもう一方の端に使用されたURI。 IM会議などのいくつかのケースがあります。(そこでは、S/MIME証明書名と合図されたアイデンティティが合わないでしょう)。 これらの場合では、クライアントは、ユーザにメッセージが証明書で特定されたユーザから来たと知らされるのを保証するべきであり、メッセージがそれらが合図したパーティーから来たと仮定しません。
In some cases, a sending device may need to attribute a message to some other identity, and may use different identities for different messages in the same session. For example, a conference server may send messages on behalf of multiple users on the same session. Rather than add additional header fields to MSRP for this purpose, MSRP relies on the message/cpim format for this purpose. The sender may envelop such a message in a message/cpim body, and place the actual sender identity in the From field. The trustworthiness of such an attribution is affected by the security properties of the session in the same way that the trustworthiness of the identity of the actual peer is affected, with the additional issue of determining whether the recipient trusts the sender to assert the identity.
いくつかの場合、送付デバイスは、メッセージをある他のアイデンティティの結果と考えるのが必要であり、同じセッションのときに異なったメッセージに異なったアイデンティティを使用するかもしれません。 例えば、会議サーバは同じセッションでの複数のユーザを代表してメッセージを送るかもしれません。 むしろ、MSRPはこのために追加ヘッダーフィールドをMSRPに加えるよりこのためにメッセージ/cpim形式を当てにします。 送付者は、メッセージ/cpimボディーでそのようなメッセージをおおって、実際の送付者のアイデンティティをFrom分野に置くかもしれません。 実際の同輩のアイデンティティの信頼できることが同じようにおけるセッションのセキュリティの特性ですが、受取人が、送付者がアイデンティティについて断言すると信じるかどうか決定する追加設定で影響を受けて、属性が影響を受けるそのようなものの信頼できること。
This approach can result in nesting of message/cpim envelopes. For example, a message originates from a CPIM gateway, and is then forwarded by a conference server onto a new session. Both the gateway and the conference server introduce envelopes. In this case, the recipient client SHOULD indicate the chain of identity assertions to the user, rather than allow the user to assume that either the gateway or the conference server originated the message.
このアプローチはメッセージ/cpim封筒の巣篭もりをもたらすことができます。 メッセージは、例えば、CPIMゲートウェイから発して、会議サーバによって新しいセッションに送られたその時です。 ゲートウェイと会議サーバの両方が封筒を紹介します。 この場合、ユーザが、ゲートウェイか会議サーバのどちらかがメッセージを溯源したと仮定するのを許容するより受取人クライアントSHOULDはむしろアイデンティティ主張のチェーンをユーザに示します。
It is possible that a recipient might receive messages that are attributed to the same sender via different MSRP sessions. For example, Alice might be in a conversation with Bob via an MSRP session over a TLS protected channel. Alice might then receive a different message from Bob over a different session, perhaps with a conference server that asserts Bob's identity in a message/cpim envelope signed by the server.
受取人が異なったMSRPセッションで同じ送付者の結果と考えられるメッセージを受け取るのは、可能です。 例えば、アリスはMSRPを通したボブとの会話では、TLSの上のセッションがチャンネルを保護したということであるかもしれません。 次に、アリスは異なったセッションの間、ボブと異なったメッセージを受け取るかもしれません、恐らくサーバによって署名されるメッセージ/cpim封筒でボブのアイデンティティについて断言する会議サーバで。
MSRP does not prohibit multiple simultaneous sessions between the same pair of identities. Nor does it prohibit an endpoint sending a message on behalf of another identity, such as may be the case for a conference server. The recipient's endpoint should determine its level of trust of the authenticity of the sender independently for each session. The fact that an endpoint trusts the authenticity of the sender on any given session should not affect the level of trust it assigns for apparently the same sender on a different session.
MSRPは同じ組のアイデンティティの間の複数の同時のセッションを禁止しません。 また、それは会議サーバのためのケースであるかもしれない別のアイデンティティを代表してメッセージを送る終点を禁止しません。受取人の終点は各セッションのために独自に送付者の信憑性の信頼のレベルを決定するべきです。 終点がどんな与えられたセッションのときにも送付者の信憑性を信じるという事実はそれが異なったセッションのときに明らかに同じ送付者のために割り当てる信頼のレベルに影響するべきではありません。
Campbell, et al. Standards Track [Page 54] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[54ページ]。
When MSRP clients form or acquire a certificate, they SHOULD ensure that the subjectAltName has a GeneralName entry of type uniformResourceIdentifier for each URI corresponding to this client and should always include an "im:" URI. It is fine if the certificate contains other URIs such as "sip:" or "xmpp:" URIs.
MSRPクライアントが証明書を形成するか、または入手するとき彼ら、SHOULDが各URIのためのタイプuniformResourceIdentifierのGeneralNameエントリーをこのクライアントにとって対応するようにして、subjectAltNameがいつもするべきであるのを確実にする、包含、「不-、:、」 ユリ。 証明書が「以下をちびちび飲みます」のような他のURIを含んでいるなら、すばらしいです。 「以下をxmppします」 URI。
MSRP implementors should be aware of a potential attack on MSRP devices that involves placing very large values in the byte-range header field, potentially causing the device to allocate very large memory buffers to hold the message. Implementations SHOULD apply some degree of sanity checking on byte-range values before allocating such buffers.
MSRP作成者はMSRPデバイスにおける非常に大きい値をバイト範囲ヘッダーフィールドに置くことを伴う起こり得るかもしれない攻撃を意識しているべきです、デバイスがメッセージを保持するために非常に大きいメモリ・バッファを割り当てることを潜在的に引き起こして。 そのようなバッファを割り当てる前にバイト範囲値について検査して、実装SHOULDはいくらかの正気を適用します。
15. IANA Considerations
15. IANA問題
This specification instructs IANA to create a new registry for MSRP parameters. The MSRP Parameter registry is a container for sub- registries. This section further introduces sub-registries for MSRP method names, status codes, and header field names.
この仕様は、MSRPパラメタのために新しい登録を作成するようIANAに命令します。 MSRP Parameter登録はサブ登録へのコンテナです。 このセクションはMSRPメソッド名、ステータスコード、およびヘッダーフィールド名のためにさらにサブ登録を導入します。
Additionally, Section 15.4 through Section 15.7 register new parameters in existing IANA registries.
さらに、セクション15.7を通したセクション15.4は既存のIANA登録に新しいパラメタを示します。
15.1. MSRP Method Names
15.1. MSRPメソッド名
This specification establishes the Methods sub-registry under MSRP Parameters and initiates its population as follows. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission).
この仕様はMSRP Parametersの下にサブ登録しているMethodsと以下の人口の開始を設立します。 RFC(IETF服従かRFC Editor服従としての)でこのサブ登録の新しいパラメタを発表しなければなりません。
SEND - [RFC4975]
REPORT - [RFC4975]
発信してください--[RFC4975]が報告する、-[RFC4975]
The following information MUST be provided in an RFC publication in order to register a new MSRP method:
新しいMSRPメソッドを登録するために以下の情報をRFC刊行物に提供しなければなりません:
o The method name. o The RFC number in which the method is registered.
o メソッドはメソッドが登録されているRFC番号と. oを命名します。
15.2. MSRP Header Fields
15.2. MSRPヘッダーフィールド
This specification establishes the header field-Field sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined as follows:
この仕様はMSRP Parametersの下にサブ登録しているヘッダー分野分野を確立します。 RFC(IETF服従かRFC Editor服従としての)でこのサブ登録の新しいパラメタを発表しなければなりません。 初期の人口は以下の通り定義されます:
Campbell, et al. Standards Track [Page 55] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[55ページ]。
To-Path - [RFC4975]
From-Path - [RFC4975]
Message-ID - [RFC4975]
Success-Report - [RFC4975]
Failure-Report - [RFC4975]
Byte-Range - [RFC4975]
Status - [RFC4975]
経路([RFC4975]経路([RFC4975]Message ID)の[RFC4975]成功レポート)の[RFC4975]異常報告書--[RFC4975]バイト範囲--[RFC4975]状態、-[RFC4975]
The following information MUST be provided in an RFC publication in order to register a new MSRP header field:
新しいMSRPヘッダーフィールドを示すために以下の情報をRFC刊行物に提供しなければなりません:
o The header field name. o The RFC number in which the method is registered.
o ヘッダーは名前○ メソッドが登録されているRFC番号をさばきます。
15.3. MSRP Status Codes
15.3. MSRPステータスコード
This specification establishes the Status-Code sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). Its initial population is defined in Section 10. It takes the following format:
この仕様はMSRP Parametersの下にサブ登録しているStatus-コードを確立します。 RFC(IETF服従かRFC Editor服従としての)でこのサブ登録の新しいパラメタを発表しなければなりません。 初期の人口はセクション10で定義されます。 それは以下の形式を取ります:
Code [RFC Number]
コード[RFC番号]
The following information MUST be provided in an RFC publication in order to register a new MSRP status code:
新しいMSRPステータスコードを登録するために以下の情報をRFC刊行物に提供しなければなりません:
o The status code number. o The RFC number in which the method is registered.
o 状態は数○ メソッドが登録されているRFC番号をコード化します。
15.4. MSRP Port
15.4. MSRPポート
MSRP uses TCP port 2855, from the "registered" port range. Usage of this value is described in Section 6.
MSRPは「登録された」ポート範囲からTCPポート2855を使用します。 この価値の用法はセクション6で説明されます。
15.5. URI Schema
15.5. URI図式
This document requests permanent registration the URI schemes of "msrp" and "msrps".
このドキュメントは永久的な登録の"msrp"のURI体系と「msrps」を要求します。
15.5.1. MSRP Scheme
15.5.1. MSRP体系
URI Scheme Name: "msrp"
URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in
Section 9 of RFC 4975.
URI Scheme Semantics: See Section 6 of RFC 4975.
Encoding Considerations: See Section 6 of RFC 4975.
URI体系名: "msrp"URI体系構文: 「MSRP-ユリ」のためにRFC4975のセクション9でABNF工事を見てください。 URI体系意味論: RFC4975のセクション6を見てください。 問題をコード化します: RFC4975のセクション6を見てください。
Campbell, et al. Standards Track [Page 56] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[56ページ]。
Applications/Protocols that use this URI Scheme: The Message Session
Relay Protocol (MSRP).
Interoperability Considerations: MSRP URIs are expected to be used
only by implementations of MSRP. No additional interoperability
issues are expected.
Security Considerations: See Section 14.1 of RFC 4975 for specific
security considerations for MSRP URIs, and Section 14 of RFC 4975
for security considerations for MSRP in general.
Contact: Ben Campbell (ben@estacado.net).
Author/Change Controller: This is a permanent registration request.
Change control does not apply.
このURI Schemeを使用するアプリケーション/プロトコル: メッセージセッションリレープロトコル(MSRP)。 相互運用性問題: MSRPの実装だけによってMSRP URIが使用されると予想されます。 どんな追加相互運用性問題も予想されません。 セキュリティ問題: 一般に、MSRPに関してMSRP URIのための特定のセキュリティ問題のためのRFC4975のセクション14.1、およびセキュリティ問題のためのRFC4975のセクション14を見てください。 接触: ベン・キャンベル( ben@estacado.net )。 コントローラを書くか、または変えてください: これは永久的な登録要求です。 変化コントロールは申請されません。
15.5.2. MSRPS Scheme
15.5.2. MSRPS体系
URI Scheme Name: "msrps"
URI Scheme Syntax: See the ABNF construction for "MSRP-URI" in
Section 9 of RFC 4975.
URI Scheme Semantics: See Section 6 of RFC 4975.
Encoding Considerations: See Section 6 of RFC 4975.
Applications/Protocols that use this URI Scheme: The Message Session
Relay Protocol (MSRP).
Interoperability Considerations: MSRP URIs are expected to be used
only by implementations of MSRP. No additional interoperability
issues are expected.
Security Considerations: See Section 14.1 of RFC 4975 for specific
security considerations for MSRP URIs, and Section 14 of RFC 4975
for security considerations for MSRP in general.
Contact: Ben Campbell (ben@estacado.net).
Author/Change Controller: This is a permanent registration request.
Change control does not apply.
URI体系名: "msrps"URI体系構文: 「MSRP-ユリ」のためにRFC4975のセクション9でABNF工事を見てください。 URI体系意味論: RFC4975のセクション6を見てください。 問題をコード化します: RFC4975のセクション6を見てください。 このURI Schemeを使用するアプリケーション/プロトコル: メッセージセッションリレープロトコル(MSRP)。 相互運用性問題: MSRPの実装だけによってMSRP URIが使用されると予想されます。 どんな追加相互運用性問題も予想されません。 セキュリティ問題: 一般に、MSRPに関してMSRP URIのための特定のセキュリティ問題のためのRFC4975のセクション14.1、およびセキュリティ問題のためのRFC4975のセクション14を見てください。 接触: ベン・キャンベル( ben@estacado.net )。 コントローラを書くか、または変えてください: これは永久的な登録要求です。 変化コントロールは申請されません。
15.6. SDP Transport Protocol
15.6. SDPトランスポート・プロトコル
MSRP defines the new SDP protocol field values "TCP/MSRP" and "TCP/ TLS/MSRP", which should be registered in the sdp-parameters registry under "proto". This first value indicates the MSRP protocol when TCP is used as an underlying transport. The second indicates that TLS over TCP is used.
MSRPは新しいSDPプロトコル分野値の"TCP/MSRP"と「TCP/TLS/MSRP」を定義します。(それは、"proto"の下のsdp-パラメタ登録に登録されるべきです)。 TCPが基本的な輸送として使用されるとき、この最初の値はMSRPプロトコルを示します。 2番目は、TCPの上のTLSが使用されているのを示します。
Specifications defining new protocol values must define the rules for the associated media format namespace. The "TCP/MSRP" and "TCP/TLS/ MSRP" protocol values allow only one value in the format field (fmt), which is a single occurrence of "*". Actual format determination is made using the "accept-types" and "accept-wrapped-types" attributes.
新しいプロトコル値を定義する仕様は関連メディア形式名前空間のために規則を決めなければなりません。 "TCP/MSRP"と「TCP/TLS/MSRP」プロトコル値は形式分野(fmt)の1つの値だけを許容します。(分野は「*」のただ一つの発生です)。 実際の形式決断を使用するようにする、「タイプを受け入れる、」 「包装されたタイプを受け入れてください」という属性。
Campbell, et al. Standards Track [Page 57] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[57ページ]。
15.7. SDP Attribute Names
15.7. SDP属性名
This document registers the following SDP attribute parameter names in the sdp-parameters registry. These names are to be used in the SDP att-name field.
このドキュメントはsdp-パラメタ登録に以下のSDP属性パラメタ名を登録します。 これらの名前はSDP att-名前欄で使用されることです。
15.7.1. Accept Types
15.7.1. タイプを受け入れてください。
Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: accept-types
Long-form Attribute Name: Acceptable media types
Type: Media level
Subject to Charset Attribute: No
Purpose and Appropriate Values: The "accept-types" attribute
contains a list of media types that the endpoint is willing to
receive. It may contain zero or more registered media-types, or
"*" in a space-delimited string.
問い合わせ先: ベン・キャンベル( ben@estacado.net )属性名: タイプを受け入れているLong-フォームAttribute Name: 許容できるメディアはTypeをタイプします: メディアはCharset AttributeにSubjectを平らにします: 目的がなくて適切な値: 「タイプを受け入れる、」 属性は終点が受けても構わないと思っているメディアタイプのリストを含んでいます。 それはゼロ、より登録されたメディアタイプ、またはスペースで区切られたストリングの「*」を含むかもしれません。
15.7.2. Wrapped Types
15.7.2. 包装されたタイプ
Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: accept-wrapped-types
Long-form Attribute Name: Acceptable media types Inside Wrappers
Type: Media level
Subject to Charset Attribute: No
Purpose and Appropriate Values: The "accept-wrapped-types" attribute
contains a list of media types that the endpoint is willing to
receive in an MSRP message with multipart content, but may not be
used as the outermost type of the message. It may contain zero or
more registered media-types, or "*" in a space-delimited string.
問い合わせ先: ベン・キャンベル( ben@estacado.net )属性名: 包装されたタイプを受け入れているLong-フォームAttribute Name: 許容できるメディアはInside Wrappers Typeをタイプします: メディアはCharset AttributeにSubjectを平らにします: 目的がなくて適切な値: 「包装されたタイプを受け入れてください」という属性は、複合内容で終点がMSRPメッセージで受けても構わないと思っているメディアタイプのリストを含んでいますが、メッセージの一番はずれのタイプとして使用されないかもしれません。 それはゼロ、より登録されたメディアタイプ、またはスペースで区切られたストリングの「*」を含むかもしれません。
15.7.3. Max Size
15.7.3. マックスSize
Contact Information: Ben Campbell (ben@estacado.net)
Attribute-name: max-size
Long-form Attribute Name: Maximum message size
Type: Media level
Subject to Charset Attribute: No
Purpose and Appropriate Values: The "max-size" attribute indicates
the largest message an endpoint wishes to accept. It may take any
whole numeric value, specified in octets.
問い合わせ先: ベン・キャンベル( ben@estacado.net )属性名: 最大サイズLong-フォームAttribute Name: 最大のメッセージサイズType: メディアはCharset AttributeにSubjectを平らにします: 目的がなくて適切な値: 「最大サイズ」属性は終点が受け入れたがっている中で最も大きいメッセージを示します。 それは八重奏で指定されたどんな全体の数値も取るかもしれません。
15.7.4. Path
15.7.4. 経路
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: path Long-form Attribute Name: MSRP URI Path Type: Media level
問い合わせ先: ベン・キャンベル( ben@estacado.net )属性名: 経路Long-フォームAttribute Name: MSRP URI経路タイプ: メディアレベル
Campbell, et al. Standards Track [Page 58] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[58ページ]。
Subject to Charset Attribute: No
Purpose and Appropriate Values: The "path" attribute indicates a
series of MSRP devices that must be visited by messages sent in
the session, including the final endpoint. The attribute contains
one or more MSRP URIs, delimited by the space character.
Charsetを条件として、以下を結果と考えてください。 目的がなくて適切な値: 「経路」属性は、メッセージで訪問しなければならない一連のMSRPデバイスがセッションのときに発信したのを示します、最終的な終点を含んでいて。 属性は間隔文字によって区切られた1つ以上のMSRP URIを含んでいます。
16. Contributors and Acknowledgments
16. 貢献者と承認
In addition to the editors, the following people contributed extensive work to this document: Chris Boulton, Paul Kyzivat, Orit Levin, Hans Persson, Adam Roach, Jonathan Rosenberg, and Robert Sparks.
エディタに加えて、以下の人々はこのドキュメントに大規模な仕事を寄付しました: クリス・ボールトン、ポールKyzivat、Oritレヴィン、ハンス・ペルソン、アダム・ローチ、ジョナサン・ローゼンバーグ、およびロバート・スパークス。
The following people contributed substantial discussion and feedback to this ongoing effort: Eric Burger, Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Aki Niemi, Hisham Khartabil, Pekka Pessi, Miguel Garcia, Peter Ridler, Sam Hartman, and Jean Mahoney.
以下の人々はこの進行中の取り組みにかなりの議論とフィードバックを寄付しました: エリックBurger、アリソン・マンキン、ジョン・ピーターソン、ブライアン・ローゼン、ディーン・ウィリス、アキNiemi、Hisham Khartabil、ペッカPessi、ミゲル・ガルシア、ピーター・リドラー、サム・ハートマン、およびジーン・マホニー。
17. References
17. 参照
17.1. Normative References
17.1. 引用規格
[1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[1] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[2] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[4] 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.
[4] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[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] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[6] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[7]、RFC3851、2004年7月。
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[8]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Campbell, et al. Standards Track [Page 59] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[59ページ]。
[9] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[9] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「内容気質ヘッダーフィールド」、RFC2183、1997年8月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[10]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[11] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[11] ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。
[12] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.
[12]Klyne、G.、およびD.アトキンス、「一般的な存在とインスタントメッセージング(CPIM):」 「メッセージ・フォーマット」、RFC3862、2004年8月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[13]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[14]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[15]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[16] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[16]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[17] ピーターソン、J.、およびC.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
[18] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
[18] レノックス、J.、「トランスポート層セキュリティ(TLS)の接続指向のメディア輸送はセッション記述プロトコル(SDP)で議定書を作ります」、RFC4572、2006年7月。
17.2. Informative References
17.2. 有益な参照
[19] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
Call Control - Conferencing for User Agents", BCP 119, RFC
4579, August 2006.
[19] ジョンストン、A.、およびO.レヴィン、「セッション開始プロトコル(一口)は、ユーザエージェントのためにコントロール--会議を召集します」、BCP119、RFC4579、2006年8月。
[20] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[20] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
Campbell, et al. Standards Track [Page 60] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[60ページ]。
[21] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation
Protocol Call Control - Transfer", Work in Progress, October
2006.
[21] R.、ジョンストン、A.、D.ピートリー、「セッション開始プロトコル呼び出しコントロール--移す」というスパークは、進歩、2006年10月に働いています。
[22] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[22] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[23] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the
Message Session Relay Protocol (MSRP)", RFC 4976, September
2007.
[23] ジョニングス、C.、マーイ、R.、およびA.ローチは「メッセージセッションリレープロトコル(MSRP)のための拡大をリレーします」、RFC4976、2007年9月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[24] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデートメソッド」、RFC3311、2002年10月。
[25] Jennings, C., Peterson, J., and J. Fischl, "Certificate
Management Service for SIP", Work in Progress, July 2007.
[25] ジョニングス、C.、ピーターソン、J.、およびJ.フィッシュル、「一口のための証明書管理サービス」は進歩、2007年7月に働いています。
[26] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Session Description Protocol (SDP)", RFC 4145, September 2005.
[26] あそこのものとD.とG.キャマリロ、「セッション記述プロトコル(SDP)におけるTCPベースのメディア輸送」、RFC4145、2005年9月。
[27] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
RFC 3860, August 2004.
[27] ピーターソン、J.、「インスタントメッセージング(CPIM)のための一般的なプロフィール」、RFC3860、2004年8月。
[28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001.
[28]Housley、R.、「三重のDESとRC2の主要なラッピング」、RFC3217、2001年12月。
[29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.
[29] キャマリロ、G.、およびH.Schulzrinne、「早くメディアと鳴るのはセッション開始プロトコル(一口)における世代に調子を変えます」、RFC3960、2004年12月。
[30] Saint-Andre, P., "Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence", RFC 3921, October
2004.
[30] サンアンドレ、P.、「広げることができるメッセージングと存在は以下について議定書の中で述べ(XMPP)」。 「インスタントメッセージングと存在」、RFC3921、10月2004日
[31] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[31] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[32] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[32] ピーターソン、J.、「インスタントメッセージングと存在のためのアドレス解決」、RFC3861、2004年8月。
Campbell, et al. Standards Track [Page 61] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[61ページ]。
Authors' Addresses
作者のアドレス
Ben Campbell (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 USA
ベンキャンベル(エディタ)エスタカードシステム17210キャンベル道路Suite250テキサス75252ダラス(米国)
EMail: ben@estacado.net
メール: ben@estacado.net
Rohan Mahy (editor) Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
Rohanマーイ(エディタ)Plantronics345Encincal通りカリフォルニア95060サンタクルス(米国)
EMail: rohan@ekabal.com
メール: rohan@ekabal.com
Cullen Jennings (editor) Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA
カレンジョニングス(エディタ)シスコシステムズInc.170の西タスマン博士MS: SJC-21/2カリフォルニア95134サンノゼ(米国)
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 408 421-9990 メールしてください: fluffy@cisco.com
Campbell, et al. Standards Track [Page 62] RFC 4975 MSRP September 2007
キャンベル、他 規格はMSRP2007年9月にRFC4975を追跡します[62ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Campbell, et al. Standards Track [Page 63]
キャンベル、他 標準化過程[63ページ]
一覧
スポンサーリンク
