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
The Message Session Relay Protocol (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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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.
この文書では、メッセージセッションリレープロトコル、セッションのコンテキストに関連したインスタントメッセージのシリーズを送信するためのプロトコルを記述しています。メッセージのセッションは、セッション開始プロトコルとしてランデブーまたはセッション作成プロトコルを介して設定し、他のメディアストリームのように扱われます。
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
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
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.
二つ以上の当事者間の関連インスタントメッセージのシリーズは、つまり、「メッセージセッション」の一環として、明確な始まりと終わりを持つメッセージの会話のやり取りを見ることができます。これは、それぞれが独立して送信された個々のメッセージとは対照的です。それは明確な開始と終了との「セッション」の一部であるメッセージングは、「セッションモード」メッセージングと呼ばれているのに対し、唯一の個々のメッセージを追跡メッセージングスキームは、「ページ・モード」のメッセージとして記述することができます。
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 [4] MESSAGE方法[22]を介して、SIPでイネーブルされています。セッションモードメッセージングは、ページモードメッセージングを超える多くの利点を持っている、しかし、そのような明示的なランデブー、他のメディアの種類、直接クライアントからクライアントへの操作との緊密な統合、および仲介、プライバシーやセキュリティなど。
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]セッション記述プロトコル（SDP）を使用して、回答メッセージセッションリレープロトコル（MSRP）、[2]。交換は、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.
ユーザは、インスタントメッセージング（IM）URLを使用する場合、RFC 3861 [32] DNSは、SIPのようにセッションを確立するために、特定のプロトコルにこれをマッピングするために使用することができる方法を定義します。 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]アプリケーションを使用して、コール・センター・発送の環境に統合することができます。
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]（「リレー」と呼ぶ）、別の文書で指定されています。この仕様を実装したエンドポイントではなく、リレーの仕様では、メッセージパスにリレーを導入することはできませんが、それでもリレーを使用しないピアとの相互運用することができるようになります。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[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要求で配信します。完全なメッセージのこれらの部分のそれぞれは、「チャンク」と呼ばれています。
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は、スタンドアロンプロトコルとして使用するために設計されていません。メーカー希望小売価格は、唯一のランデブーメカニズムの会議は、次の要件の文脈で使用する必要があります：
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セッションに関連付けられた両方のMSRP URIを提供しなければなりません。ランデブーメカニズムは、これらの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.
URIまたは自動IMを翻訳：Oランデブーメカニズムは、ネイティブIMを輸送できなければならない[27] URIをランデブー・プロトコルのアドレス指定識別子に。
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は、それが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は、ランデブーメカニズムのために、これらの要件を満たしています。 MSRPのURIは、SIP経由でオファー/アンサー交換にSDPを使用して交換されます。
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.
交換SDPはまた、MSRP拡張を交渉するために使用することができます。このSDPは、媒体を横切って輸送セキュリティを確保し、SDP本体のエンドツーエンドの保護のために/多目的インターネットメール拡張（S / MIME）を確保するためにSIPSメカニズムを使用することを含む、SIPで利用可能なメカニズムのいずれかを使用して固定することができます。 Request-URIに、および手順は、IMをマッピングするために利用可能である：SIPは、（URIのIMを含む）：任意のURIを運ぶことができ、SIPへのURI：またはSIPS：のURI。 MSRPの初期導入は、そのランデブーメカニズムとしてSIPを使用することが期待されます。
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は、任意の（バイナリ）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
3413an89KUたContent; bob@biloxi.example.com SIP / 2.0：<SIP：bob@biloxi.example.com>から：タグ= 786のCall-ID：<SIP alice@atlanta.example.com> SIPのINVITEタイプ：アプリケーション/ 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
C = IN IP4 atlanta.example.com M =メッセージ7654 TCP / MSRP * A =受け入れる - タイプ：text / plainの=パス：MSRP：//atlanta.example.com：7654 / jshA7weztas、TCP
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
SIP / 2.0 200 OKに：<SIP：bob@biloxi.example.com>;タグ= 087jsから：<SIP：alice@atlanta.example.com>;タグ= 786コールID：3413an89KUのContent-Type：アプリケーション/ 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
C = IN IP4 biloxi.example.com M =メッセージ12763 TCP / MSRP * A =受け入れる - タイプ：text / plainの=パス：MSRP：//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 SIP：ボブ@のビロクシSIP / 2.0 <SIP：bob@biloxi.example.com>;からタグ= 087js <SIP：alice@atlanta.example.com>;タグ= 786のCall-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は、二つの要求タイプ、またはメソッドを定義します。 SEND要求は、レポートは、以前に送信されたメッセージのステータス、またはメッセージ内のバイトの範囲でレポートを要求しながら、完全なメッセージまたはチャンク（完全なメッセージの部分）を送達するために使用されます。アリスはボブの答えを受けたとき、彼女はボブへの既存の接続を持っているかどうかを確認します。そうでない場合、彼女は彼がSDPで提供URIを使用してボブへの新しい接続を開きます。アリスは、彼女の最初のメッセージをボブにSEND要求を配信し、ボブはアリスの要求が正常に受信されたことを示す応答します。
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のパスへ：メーカー希望小売価格：//biloxi.example.com：12763 / kjhd37s2s20w2a; TCPからのパス：メーカー希望小売価格：//atlanta.example.com：7654 / jshA7weztas; TCPメッセージ-ID：87652491バイト範囲： 1-25 / 25のContent-Type：text / plainの
Hey Bob, are you there?
-------a786hjs2$
MSRP a786hjs2 200 OK
To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
From-Path: 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開始行で始まります。次の彼女はからパスヘッダフィールド内のパスへのヘッダフィールド内の宛先へのURIのパス、彼女自身のURIを含んでいます。この典型的なケースでは、ただ一つの「ホップ」があるので、唯一のURIは、各パスヘッダフィールドです。彼女はまた、彼女は元のメッセージとステータスレポートを関連付けるために使用できるメッセージIDが含まれています。次の彼女は、実際のコンテンツを置きます。最後に、彼女は7つのハイフンのエンドライン、トランザクション識別子、およびこの要求は完全なメッセージの終わりが含まれていることを示すために「$」とのリクエストを閉じます。
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でより詳細に記載されています。バイト範囲ヘッダーフィールドは、このチャンクで運ばメッセージおよびメッセージの合計サイズの部分を識別する。
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を関連付けることができます。アリスとボブにも使用することができます
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]このホップの上にチャネルセキュリティを提供します。 TLS保護接続を介してMSRP要求を受信するには、アリスまたはボブではなく、「MSRP」の「msrps」スキームで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.
メーカー希望小売価格は、メーカー希望小売価格は、リレーの向こう側のノードのURIを運ぶことができることを期待して設計されています。このため、「msrps」スキームURIは、他のホップのセキュリティプロパティ、ちょうど次のホップについての表明を行いません。ユーザエージェントは、各ホップのURIを知っているので、各URIは、所望のセキュリティ特性を有することを確認することができます。
MSRP URIs are discussed in more detail in Section 6.
MSRP URIは、第6節で詳しく説明されています。
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.
（例えば、2つのリレー）忙しいMSRPノードの隣接ペアは簡単にいくつかの同時ユーザーのためのいくつかのセッション、および交換トラフィックを持つことができます。ノードが同じ宛先ホスト、ポート、トランスポートプロトコル、およびスキームで新しいトラフィックを運ぶために既存の接続を使用することができます。 MSRPノードは、特定の接続を使用しているどのように多くのセッションを追跡し、何のセッションが一定の時間のためにそれらを使用していない時にこれらの接続を閉じることができます。接続管理は、5.4節で詳しく説明されています。
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要求は全体的なメッセージの1つのチャンクが含まれているいくつかのSEND要求に送達することができます。ロングチャンクは共有トランスポート接続間公平性を確保するために半ば伝送で中断することができます。これをサポートするために、MSRPは境界ベースのフレーミング・メカニズムを使用しています。 MSRP要求のスタートラインはまた、要求の終了を示すために使用される一意の識別子を含みます。エンドラインの最後に、これは、このメッセージまたはメッセージが後続のチャンクに継続されるかどうか、データの最後のチャンクであるかどうかを示すフラグがあります。完全メッセージ内のこのチャンクの全体的な位置を示す要求にバイト範囲ヘッダーフィールドもあります。
For example, the following snippet of two SEND requests demonstrates a message that contains the text "abcdEFGH" being sent as two chunks.
例えば、2つのSEND要求の次のスニペットは、「ABCDEFGH」は2つのチャンクとして送信されているテキストを含むメッセージを示しています。
MSRP dkei38sd SEND Message-ID: 4564dpWd Byte-Range: 1-*/8 Content-Type: text/plain
メーカー希望小売価格は、Message-IDを送信dkei38sd：4564dpWdバイト範囲：1 - * / 8のContent-Type：text / plainの
abcd
-------dkei38sd+
MSRP dkei38ia SEND Message-ID: 4564dpWd Byte-Range: 5-8/8 Content-Type: text/plain
4564dpWdバイト範囲：5-8 / 8のContent-Type：text / plainのMSRPは、メッセージIDを送信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オクテットよりも大きい任意のチャンクが割り込みでなければなりません。メーカー希望小売価格は各MSRPセッションは、独自のTCP接続を使用する場合は実装が簡単になりますが、接続を節約するために説得力のある理由があります。例えば、TCPピアは、多くの他のピアに接続する中継装置であってもよいです。各ピアが多数の接続を作成しない場合、そのようなデバイスは、より良好なスケールであろう。 （上記の例では、最初のチャンクは、その大きさが十分に割り込み可能が必要とされるであろうため限界以下であっても、実施例のために中断したことに注意してください。）
The chunking mechanism only applies to the SEND method, as it is the only method used to transfer message content.
それはメッセージの内容を転送するために使用される唯一の方法であるようにチャンキング機構のみ、SENDメソッドに適用されます。
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章、それぞれがURIのリストを可能にパスし、よりパスヘッダフィールドの構文で定義されています。これは、プロトコルは、エンド受信者への完全なパスを提供するために、別の文書で定義されているリレーで作業できるようにするために行われました。 2つのMSRPノードが直接通信するとき、彼らはTO-パスのリストから、パスリスト内の1つのURIで唯一のURIを必要としています。
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要求を送信します。受信機はすぐに要求を受け入れるか、または拒絶しなければなりません。受信機が最初に要求を受け入れた場合、それはまだ、その後成功するか失敗するかなりの時間がかかることを行うことがあります。受信機は、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）[30]ゲートウェイにMSRPである場合、例えば、それはXMPPオーバーメッセージを転送することができます。 XMPP側は、後で要求が機能しなかったことを示してもよいです。この時点で、MSRP受信機は、要求が成功しなかったことを示すために必要があるかもしれません。 2つの重要な概念がここにあります：最初、要求のホップバイホップの配信が成功するか失敗することがあります。第二、リクエストの最終的な結果は、または正常に処理してもしなくてもよいです。状態の第一のタイプは、「トランザクション状態」と呼ばれ、要求に応じて返されてもよいです。ステータスの第二のタイプは、「配達状態」と呼ばれ、レポートトランザクションに返されてもよいです。
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を送信し、送信者が成功のレポートを要求しました。リクエストが配信されるように失敗し、送信者が障害の報告を要求された場合、受信機は、障害レポートを送信します。
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.
この文書では、MSRPエンドポイントの動作を説明します。 MSRPリレーは、次のホップからの肯定応答を受信するための障害などの障害REPORTを送信する必要があることを示す追加条件を、ご紹介します。
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".
2つのヘッダフィールドは、報告書を受け取るために、送信者の欲求をコントロールします。成功-レポートヘッダフィールドには、「はい」、「いいえ」、または「部分」の値を持つことができ、「はい」または「いいえ」と失敗-レポートヘッダフィールドの値を持つことができます。
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 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.
報告の組み合わせは、現在展開IMシステムのさまざまなシナリオを満たすために必要とされています。成功-レポートは、負荷を軽減するために、多くの公共のシステムに「ノー」であるかもしれないが、そのような証券取引のために使用されるシステムなど、特定の企業システム、で「はい」であるかもしれません。 「いいえ」の失敗、報告書の値は、送信者に応答爆発を引き起こすことなく、「システムが5分に下がっている」などのシステムメッセージを送信するために有用です。 「はい」の失敗、報告書は、メッセージが失敗した場合、ユーザーに通知を希望する多くのシステムで使用されます。 「部分的」の失敗、報告書は、タイムアウト以外のエラーを報告するための方法です。タイムアウトエラー報告は、タイマーを停止する確認応答を送信するためにタイマーと受信ホップを実行するための送信ホップを必要とします。一部のシステムでは、これを行うためのオーバーヘッドを望んでいません。 「部分的には、」彼らがそうしないことを選択することができますが、それでもエラー応答は、多くの場合、送信することができます。
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.
用語「部分」とは、「はい」の失敗-Report値で必要とされるであろうホップバイホップ承認メカニズムが呼び出されていないことを意味します。このように、各デバイスは、それらに利用可能なエラー検出ツールのセットの唯一の「一部」を使用しています。これは、すべての障害の無い報告との間の妥協を可能にし、可能なすべての失敗を報告します。たとえば、「部分的」で、送信側デバイスは肯定応答を待っているの周りにトランザクションの状態を維持する必要はありません。しかし、それはまだデバイスは、他のタイプのエラーを報告することができます。受信装置は、依然として、そのような容認できないコンテンツタイプ、または下流のデバイスに接続しようとしたICMPエラーなどのポリシー違反を報告することができました。
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.
MSRP終点がMSRP URIによって識別されたピアに要求を送信したいとき、それは最初のURIで指定されたホストに、適切なセキュリティ特性を有する、トランスポート接続を必要とします。送信者がすでにあるような接続を持っている場合は、同じホスト、ポート、およびURIスキームに関連する一つは、それは、その接続を再利用する必要があります。
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.
新しいMSRPセッションが作成されると、開始エンドポイントは、新しい接続が必要な場合には、回答にトランスポート接続を開くための責任があることを意味し、「アクティブ」エンドポイントとして行動しなければなりません。接続方向を交渉するための標準メカニズムが使用可能になり、接続の両当事者により実現される場合は、この要件が弱くされるかもしれません。
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.
同様に、アクティブなエンドポイントは、直ちにSEND要求を発行しなければなりません。送信者が送信したコンテンツがある場合は、この最初のSEND要求は、ボディを持っているかもしれません、またはそれがまったく体を有していなくてもよいです。
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.
最初のSEND要求は、受動的エンドポイントの観点からMSRPセッションへの接続をバインドするのに役立ちます。接続がすぐに要求を送信しませんでしたTLS、およびアクティブなエンドポイントで認証されていない場合は、受動的なエンドポイントが接続されていた者を決定する方法はありません、そして安全に後までアクティブなパーティに向けた任意のリクエストを送信することはできませんアクティブパーティは、その最初の要求を送信します。
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
要素は、新しい接続を形成する必要がある場合、接続の種類（TLS、TCP、など）を決定するためにURIを見て、その後、セクション6.2でURI解決ルール以下、URIで示されたホストに接続します。 「msrps」方式を使用して、接続がTLSを使用しなければなりません。ザ・
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は、URIのホスト名の一部と一致しなければならないし、証明書が有効であり、許容される認証局によって署名された日付を有するなど、RFC 3280 [16]によれば有効でなければなりません。この時点で、接続を開始したデバイスは、この接続は正しいホストであると仮定することができます。
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.
TLSピア・ツー・ピアを使用している場合、証明書の名前の一致とCA署名に関する規則が緩和されます。この場合、ピアは正しい証明書を使用することを保証するためのメカニズムを使用しなければなりません。詳細については、セクション14.4を参照してください。
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.
接続は、相互TLS認証を使用し、TLSクライアントは有効な証明書を提示した場合は、接続を受け入れ要素は、反対ピアデバイスによって提供されるSDPにおける標的URIのホスト名部分を比較することにより、接続装置のIDを確認することができクライアント証明書でのSubjectAltName。
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.
相互TLS認証を使用しない場合、それが関連するセッション記述から接続装置のアイデンティティを推測その時点で接続上で要求を受信するまで、リスニングデバイスが待機しなければなりません。
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.
最初の要求が到着すると、それへのパスヘッダフィールドは、リスニング要素がセッションのSDP内に設けられていることURIを含むべきです。接続を受け入れた要素は、受信した要求でURIを検索し、それが一致するセッションを決定します。一致が存在する場合、ノードは接続を形成ホストはこのURIが与えられたホストであると仮定しなければなりません。一致が存在しない場合、ノードは、481応答で要求を拒絶しなければなりません。ノードは、必ずセッションが別の接続に使用されていないようにするためにチェックしなければなりません。セッションがすでに使用されている場合、それは506応答で要求を拒絶しなければなりません。
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.
それは同じセッションに関連付けられた複数の接続を持っていることは合法だった場合は、セキュリティ上の問題が存在することになります。最初のSEND要求が保護されていない場合、盗聴者は、URIを学び、そして異なる接続を介してセッションにメッセージを挿入するためにそれを使用する場合があります。
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 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.
接続が何らかの理由で失敗した場合、MSRP終点にも失敗したなどの接続に関連付けられているすべてのセッションを考慮する必要があります。ときにエンドポイントの通知などの障害のいずれか、それはどのようなセッションを再作成しようとします。それがそうすることを選択した場合、それはSIPで再INVITE、例えば、新しいSDP交換を使用しなければなりません。交換用のセッションが正常に作成された場合、エンドポイントは、元のセッションの配信が確認できなかった任意のコンテンツを再送信しようとすることができます。それがこれを行う場合は、再送信メッセージのメッセージIDの値は最初の試みで使用されているものと一致しなければなりません。受信エンドポイントが同じメッセージIDで複数のメッセージを受信すると、メッセージが重複していると仮定すべきです。エンドポイントは、それが重複したメッセージを受信したときにかかる具体的なアクションは、それが重複の警告なしにユーザーに重複したメッセージを提示してはならないことを除いて、ローカルポリシーの問題です。故障・レポートおよび成功、レポート設定に基づいて、必要に応じて確認応答でも重複したコンテンツを含む要求に対してまだ必要であることに注意してください。
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.
エンドポイントは、この方法で失敗したセッションを再作成しようとすると、それはSDP内のMSRP URIは古いものと同じになると仮定してはいけません。
A connection SHOULD NOT be closed while there are sessions associated with it.
それに関連付けられたセッションがある一方、接続がクローズしないでください。
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.
「MSRP」および「msrps」方式を使用してURIは特定のMSRP装置にインスタントメッセージのセッションを識別するために、並びに一般的にMSRPリレーを識別するために使用されます。この文書では、かつての使用法を説明します。後者の使用はMSRPリレー仕様[23]に記載されています。セッション識別短命ですMSRP URIを、 MSRPデバイスは、各個別のセッションに異なるMSRP URIを使用します。セッションを識別MSRP URIは、そのセッションの範囲外では意味がありません。
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 URIは、 "MSRP" または "msrps" の方式で、RFC 3986 [10]の付録AのURIの構文のサブセットに従います。構文はセクション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のURIは、主にシステム間で発生し、交換することが予想され、そして「人間の消費」のために意図されていません。そのため、彼らは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.
「権威」、「userinfoを」、及び「予約されていない」ための構造が、RFC 3986に詳述されている[10]。 TCP上のMSRPを指定するURIは、「TCP」のトランスポートパラメータを含まなければなりません。
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.
この文書は唯一のTCP上のMSRPを指定するので、すべてのMSRP URIは、本明細書では「TCP」トランスポート・パラメータを使用します。他のトランスポート上のバインディングを提供した文書は、これらのトランスポートの各パラメータを定義する必要があります。
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.
MSRP URIの権限フィールドは、特定のMSRPセッションで参加者を識別します。権限フィールドが数値のIPアドレスが含まれている場合、それはまた、ポートを含まなければなりません。セッションID部は、参加者の特定のセッションを識別する。セッションID部が存在しないことは、MSRPホストデバイスへの参照を示しているが、そのデバイスで特定のセッションを意味するものではありません。セッションIDの特定の値は、関連付けられた権限のコンテキストでのみ意味があります。従って、権限コンポーネントは、セッションIDの名前空間を管理する「権限」を特定するものと考えることができます。
A scheme of "msrps" indicates that the underlying connection MUST be protected with TLS.
「msrps」のスキームは、基になる接続が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.
メーカー希望小売価格は、15.4節で定義されたIANA登録をお勧めポートを持っています。ここに記載さURI交渉プロセスは、常に明示的なポート番号が含まれますので、この値は、デフォルトではありません。推奨ポートはいつでも適切に使用されるように、しかし、URIが構成されるべきです。これは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.
権限コンポーネントは、通常のUserInfoコンポーネントは含まれませんが、セッションが有効なユーザーアカウントを示すためにそうすることができます。これは、セッション自体を特定することと同じではないことに注意してください。ユーザ情報部分は、パスワード情報を含めることはできません。
The following is an example of a typical MSRP URI:
以下は、典型的なMSRP URIの一例です。
msrp://host.example.com:8493/asfd34;tcp
メーカー希望小売価格：//host.example.com：8493 / asfd34、TCP
In the context of the MSRP protocol, MSRP URI comparisons MUST be performed according to the following rules:
MSRPプロトコルの文脈では、MSRP URIの比較は、次の規則に従って実行する必要があります。
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 parts are not considered for URI comparison. Otherwise, the authority component is compared as a case-insensitive character string.
2.権限コンポーネントは、明示的なIPアドレスおよび/またはポートが含まれている場合、これらは、アドレスとポートの等価性を比較しています。パーセントエンコーディングの正規化[10]は適用され任意のパーセントエンコード非予約文字は権限コンポーネントに存在する場合つまり、彼らは比較に先立ってデコードする必要があります。ユーザ情報部分はURIの比較のために考慮されていません。それ以外の場合、権限コンポーネントは、大文字と小文字を区別しない文字列として比較されます。
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.ポートがURIのいずれかに明示的に存在している場合、それは正確に一致する必要があります。明示的なポートとURIが指定されていないポートを持つ別のと等価になることはありません。
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.セッションID部は、大文字と小文字を区別として比較されます。セッションID部なしのURIは、いずれかを含むものと等価になることはありません。
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. URIが一致することはありません。輸送を除いて同一である2つのURIは等価ではありません。輸送パラメータは大文字と小文字を区別しません。
Path normalization [10] is not relevant for MSRP URIs.
パスの正規化[10] MSRP URIの関連性はありません。
An MSRP host device is identified by the authority component of an MSRP URI.
MSRPホストデバイスは、MSRP URIの権限コンポーネントによって識別されます。
If the authority component contains a numeric IP address and port, they MUST be used as listed.
権限コンポーネントが数値IPアドレスとポートが含まれている場合は記載されているとして、彼らを使用しなければなりません。
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.
権限コンポーネントがホスト名とポートが含まれている場合は、接続するデバイスは、AまたはAAAAのDNSクエリを実行して、ホストアドレスを決定しなければならないと記載されたポートを使用します。
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.
接続に失敗した場合、デバイスは、レコードが提示された順序で、任意の追加のAまたはAAAAレコードに返されるアドレスへの接続を試みる必要があります。
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.
このプロセスは、接続ポートは常に前の解像度に知られていることを前提としています。これは、この文書で説明したURIを使用していますMSRPのために、常に真である、つまり、URIはSDPオファーとの回答で交換しました。リレーの導入はこれが当てはまらない状況を作成します。たとえば、ときに、ユーザーがリレーを使用するには、彼女のクライアントを設定し、リレーのMSRP URIを覚えていて、人間に伝えることは容易であることが望ましいです。多くの場合、MSRPのこのタイプは、ポート番号を省略します。したがって、リレー仕様[23]、ポート番号を解決するための追加の手順が記載されています。
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デバイスは、他のそのようなデバイスを発見するための他の方法を使用することができます。例えば、MSRPエンドポイントは、この文書の範囲を超えてリレーを発見するために他のメカニズムを使用してもよいです。
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.
新しい要求を形成するために、送信者はトランザクション識別子を作成し、MSRP要求開始ラインを作成するには、このとメソッド名を使用しています。トランザクション識別子が同時に存在する他のトランザクションのそれと衝突してはなりません。したがって、ランダムの、少なくとも64ビットを含まなければなりません。
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.
次に、送信者からパスヘッダフィールドでのパスへのヘッダフィールドにターゲットパスを配置し、送信者のURI。複数のURIは、TO-パスに存在している場合は、一番左は最初のURIが訪れています。右端のURIは、最後のURIが訪れています。処理は、方法、特定なります。以下のセクションで説明するような追加の方法、特定のヘッダフィールドが追加されます。
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.
いずれの方法に固有のヘッダフィールドが追加された後に存在する場合、処理は、本体を処理し続けます。リクエストが身体を持っている場合、それは、Content-Typeヘッダフィールドを含まなければなりません。これは、他のMIME特有のヘッダフィールドを含んでいてもよいです。 Content-Typeヘッダフィールドは、メッセージヘッダ部内の最後のフィールドでなければなりません。本体は、余分な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.
非SEND要求は、メッセージの内容を伝えることを意図していないので、中断されていません。非SEND要求体は10240個のオクテットより大きくすることはできません。
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.
この文書は非SEND要求に体のいずれかの特定の使用方法については説明しませんが、彼らは、セキュリティやアイデンティティ情報を運ぶために、将来的に有用である可能性が、進行中のメッセージに関する情報など10Kのサイズ制限は、十分に大きくなるように選択されましたこのようなアプリケーションのほとんどが、非中断メソッド本体に任意の大きさのコンテンツを送信することによって引き起こされる、公平性の問題を回避するのに十分に小さいため。
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.
無本体と、要求は、Content-Typeや他のMIME固有のヘッダフィールドを含んではいけません。本体無し要求は、最終的なヘッダフィールドの後に終了ラインを含まなければなりません。余分なCRLFは、ヘッダ部とエンドラインとの間に存在しないであろう。
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.
クライアントは、「トラフィック」を送信したいが、相手ユーザにレンダリングされるコンテンツを送信したくないときなし機関との要求が便利です。例えば、アクティブなエンドポイントは、接続を確立するとすぐにSEND要求を送信します。それは現時点では何も言うことを持っていない場合は、本文なしで要求を送信することができます。 Bodiless要求も、生きているなど、ネットワークアドレス変換（NAT）バインディングを維持するために、特定の用途に使用することができます
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リクエストは、空の機関との要求とは区別されます。空のボディを持つ要求は、Content-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 "+".
リクエストが7で構成されなければならない終了エンドライン「 - 」（マイナス記号）文字、スタートラインに使用されるように、トランザクションID、およびフラグ文字。体が存在する場合、エンド・ラインは、体の一部ではないCRLFが先行されなければなりません。チャンクが完全なメッセージの終わりを構成するデータを表す場合、フラグの値が「$」でなければなりません。送信者が不完全なメッセージを中止し、そのメッセージには、さらにチャンクを送信しないように意図している場合は、フラグが「＃」でなければなりません。それ以外の場合は、フラグが「+」でなければなりません。
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.
要求は、本体が含まれている場合、送信者は、エンドライン（7つのハイフン、トランザクション識別子、及び継続フラグ）が体内に存在しないことを確実にしなければなりません。 「$」、「＃」を含む、エンドラインが体内に存在する場合、送信者は、体内に存在しない新しいトランザクション識別子を選択する必要があり、必要に応じてCRLFを追加し、エンドライン、または「+」の文字。
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.
リクエストは、配信のための準備が整うと、送信者は、接続管理（5.4節）は、既存のオープン接続を介して要求を転送するか、新しい接続を作成するためのルールに従います。
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).
エンドポイントが提供するメッセージを有する場合、それは最初に新しいメッセージIDを生成します。値は、他のエンドポイント・インスタンスによって、または将来的に同じインスタンスで繰り返されることが非常にそうでなければなりません。必要に応じて、エンドポイントはチャンクにメッセージを破ります。その後、リクエストを構築するための手順（セクション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.
メッセージIDヘッダフィールドは、特定のメッセージの特定のバージョンを指す一意のメッセージ識別子を提供します。この文脈における用語「メッセージ」は、送信者が受信者に伝えたいコンテンツの単位を指します。そのようなメッセージは、チャンクに分割することができるが、メッセージIDはメッセージ全体ではなく、メッセージのチャンクを指します。
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.
メッセージ識別子の一意性は、それを生成するホストによって保証されます。このメッセージ識別子は、機械可読と人間に必ずしも意味のないことが意図されます。メッセージ識別子は、特定のメッセージのうちの正確に1つのバージョンに関する。メッセージへのその後の改正は、それぞれの新しいメッセージ識別子を受け取ります。エンドポイントは、いくつかの方法、実装上の選択肢であるかの選択に十分な一意性を保証することができます。例えば、エンドポイントは、MACアドレス、エポックからの秒数、プロセスID、および単調増加の16ビット整数、すべてのベース64符号化され、その思想としてのインスタンス識別子を連結可能性があります。代わりに、オンボードクロックのないエンドポイントは、単純に64ビットの乱数を使用することができます。
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.
メッセージの各チャンクは、Message-IDを含むメッセージ-IDヘッダフィールドを含まなければなりません。送信者がデフォルト以外のステータスレポートを希望する場合は、それが適切な値で失敗-報告書および/または成功-レポートヘッダフィールドを挿入しなければなりません。同じメッセージのすべてのチャンクは彼らのSEND要求で同じ失敗-レポートおよび成功-レポート値を使用しなければなりません。
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.
成功レポートが要求された場合、すなわち、成功、レポートヘッダフィールドの値が「はい」で、送信側デバイスは、そのアプリケーションのために理にかなって、いくつかの値のタイマーを実行することを望むかもしれないと成功のレポートが受信されない場合は行動を取ります今回インチこのタイマーのための普遍的な価値はありません。一部の取引システムのために、第2の下かもしれないが、多くのIMアプリケーションの場合、それは2分です。成功レポートは、セッションが終了した時点で受信されていない場合にかかわらず、このようなタイマーが使用されているかどうかの、装置は、ユーザに通知する必要があります。
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.
「失敗-報告書」の値を「はい」に設定されている場合は、その要求の送信者は、タイマーが実行されます。トランザクションに200応答が時間から30秒以内に受信されない場合は、トランザクションの最後のバイトが送信され、または送信するためのオペレーティング・システムに提出され、要素は、要求がおそらく失敗したことをユーザに通知しなければなりません。値が「部分的」に設定されている場合、トランザクションを送信する要素は、タイマーを実行する必要はありませんが、それはトランザクションに回復不能なエラー応答を受信した場合、ユーザーに通知する必要があります。かかわらず、失敗-Report値の、次の要求を送信する前に応答を待つ必要はありません。
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 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.
全く成功-レポートヘッダーフィールドは、SEND要求に存在しない場合は、「NO」の値が成功報知ヘッダフィールドと同じに扱われなければなりません。無故障・レポートのヘッダーフィールドが存在しない場合は、「はい」の値で失敗-レポートヘッダフィールドと同様に扱わなければなりません。 MSRP終点は、それが認識しないメッセージIDのレポートを受信した場合、それは黙っ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 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.)
メッセージの最初のチャンクは、以降のすべてのチャンクは、バイト範囲ヘッダーフィールドを含まなければならないべきです。範囲開始フィールドは、メッセージ全体（最初のチャンクのために、このフィールドが1の値を有するであろう）で、体内の最初のバイトの位置を示さなければなりません。知られている場合、範囲エンドフィールドは、体内での最後のバイトの位置を示す必要があります。位置が不明な場合は、「*」の値を取る必要があり、または要求が割り込み可能にする必要がある場合。既知の場合、合計欄には、メッセージの合計サイズを含むべきです。メッセージの合計サイズが事前に知られていない場合、合計欄には、「*」を含むかもしれません。送信者は、バイト範囲ために、すべてのチャンクを送らなければなりません。 （ただし、受信機は、介在するリレーが順序を変更された可能性があるとして、要求は、順番に配信されることを前提とすることはできません。）
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要求を送信することを選択するかもしれないいくつかの状況があります。一貫性のために、存在しないか、長さゼロの内容を参照バイト範囲ヘッダーフィールドは、依然として、例えば、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 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.
彼らはそれらを中断する用意がある場合を除き接続を介して、公平性を確保するために、送信者は、（より大きい2048オクテットの身体を持つ任意のチャンクがレンジ・に「*」の文字を持っているだろうことを意味2048オクテットより大きな体でチャンクを送ってはいけません終了フィールド）。送信者は、この要件を満たすために、次の2つの戦略のいずれかを使用することができます。送信者は強くトラフィックが同じ接続を使用するように待機している場合にのみ、他の（少なくとも2048オクテット長）チャンクを中断し、できるだけ少ないチャンクを使用して2048オクテットより大きなメッセージを送信することをお勧めします。また、送信者は、単に最後のチャンクまで2048オクテット単位でチャンクを送信することができます。なお、接続の著しくより効率的に使用されている旧戦略の結果。すべてのMSRPノードは、それらが完全なメッセージを受信することができるオクテットの最大数にゼロオクテットから任意のサイズのチャンクを受けることができなければなりません。送信者は、完全なメッセージの最後のチャンクを除いて、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要求が中断されます。これは、同じメッセージIDと割り込みが発生した後の最初のバイトの位置を含むバイト範囲ヘッダーフィールド範囲開始フィールドと別のチャンクに再開することができます。
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要求が同時に同じ接続を介して送信されている場合、装置は、各同時リクエストがアプリケーションに適した一定の間隔でデータのいくつかの公正な部分を送信する機会を得るように、それらの間で交互にいくつかのスキームを実装する必要があります。
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.
メッセージのデフォルトの配置は、ユーザーにレンダリングされます。送信者が異なる処分を望んでいるなら、それはコンテンツ・処分[9]ヘッダフィールドを挿入することができます。値は、RFC 2183から任意[9]又はそれが定義IANAレジストリを含むかもしれません。 MSRPは、エンコードされていないバイナリペイロードを運ぶことができるので、転送符号化は、常に「バイナリ」であり、転送符号化パラメータが存在してはなりません。
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要求からメッセージ-IDヘッダフィールドを含まなければなりません。
If an MSRP element receives a REPORT for a Message-ID it does not recognize, it SHOULD silently ignore the REPORT.
MSRP要素は、それが認識しないメッセージIDのレポートを受信した場合、それは黙っ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 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.
レポート要求のヘッダフィールドは、ほとんどの場合に十分な情報を運ぶことができるようにレポート要求は、通常、体を含みません。しかし、REPORT要求は、関連するSEND要求のステータスに関する追加情報を含むボディを含むかもしれません。このようなボディは、情報提供のみで、REPORTリクエストの送信者は受信者が身体に注意を払っていることを仮定するべきではありません。 REPORT要求は中断されません。
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.
成功-レポートと失敗-レポートヘッダフィールドは、REPORTリクエストに存在してはなりません。 MSRPノードはリクエストを報告して対応してREPORT要求を送ってはいけません。 MSRPノードは要求を報告するために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.
彼らは要求は配信されません信じる理由を持っている場合、エンドポイントは、REPORTリクエストを送るべきではありません。例えば、彼らはもはや有効でセッションのレポート要求を送信することはできません。
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.
エンドポイントが「はい」の成功-Report値を含む1つのまたは複数のチャンクでメッセージを受信すると、それが成功レポートまたは正常に受信されているすべてのバイトをカバーする報告書を送らなければなりません。成功レポートは、いくつかの追加要件を、通常の手順（7.1節）以下、REPORTリクエストの形式で送信されます。
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.
受信機は、メッセージの最後のチャンクを受信するまで待機し、完全なメッセージをカバー成功レポートを送信することができます。代わりに、それはチャンクが受信されると、増分成功レポートを生成してもよいです。これらは定期的に送信され、これまでに受信したすべてのバイトをカバーする、または彼らはチャンクが到着した後に送信され、そのチャンクから一部だけをカバーすることができますすることができます。
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 relay can cause the receiver to see a very different chunk allocation than the sender, such a mechanism would be of questionable value.
バイトの特定の範囲に関する報告としてではなく、クライアントから送信された特定のチャンクに成功REPORTを考えると便利です。送信クライアントは、特定のSEND要求のそれに一致する特定の成功レポートでバイト-Rangeヘッダフィールドに依存することはできません。例えば、介在MSRPリレーは、より大きなものに小さな塊、または集合体の複数のチャンクにチャンクを破ることができます。この副作用は全くリレーが使用されていない場合でも、ある、受信側のクライアントは、正確に送信者によって送信された元のチャンクのものと一致していないバイト範囲に報告することができます。これは、メッセージ内のすべてのバイトが受信されるまで待機し、全体的に報告することは、各チャンクを受信すると、それは、報告することができ、またはそれは、他の受信範囲に報告することができることができます。メッセージ全体の内容よりも小さい範囲に報告する送信者の特定の改善されたユーザ体験を可能にします。例えば、送信クライアントは、バイトの範囲の増分状態を示す情報を表示することができ、受信機によって承認されています。しかし、インクリメンタルに報告するかどうかの選択は完全に受信クライアント次第です。インクリメンタルレポートかどうかを受信するためにその願望を主張するために、送信者のためのメカニズムはありません。リレーの存在は、受信者が送信者とは非常に異なるチャンク割り当てを確認することがありますので、そのようなメカニズムは、疑わしい価値があるであろう。
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.
レポート要求を生成するときに、エンドポイントは、元の要求、セッション自体を識別するURIを含むからパスヘッダフィールドからからパス値を含むことにパスヘッダフィールドを挿入します。終点は、次いで、「000」の名前空間、「200」のステータスコード、および実装定義コメント句とステータスヘッダフィールドを挿入します。それはまた、元の要求からの値を含むメッセージ-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.
名前空間のフィールドは、ステータス・コード・フィールドのコンテキストを示しています。 「000」の名前空間の値は、ステータス・コードが一致する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".
エンドポイントは、どちらかが全く成功-レポートヘッダフィールドが含まれていませんか「いいえ」の値で、このようなフィールドが含まれていSEND要求の成功レポートを送ってはいけません。それには成功-レポートヘッダーフィールドが存在しない場合、それは「NO」の値を持つものに同様に処理されます。
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要求、障害、レポートヘッダーフィールドのいずれかの元の要求に存在していなかったか、「YES」の値を持っていたを受信した場合、それは単ににおける適切なエラーコードを含むべきですトランザクション応答。しかしながら、そのようなエンドポイントは、エラーを示すために、下流のネットワークを待つゲートウェイである場合など、エラーを迅速に決定することができない状況があるかもしれません。このような状況では、それはエラーが検出されたときに、故障REPORT要求を送信後、要求に対する200 OK応答を送信し、するかもしれません。
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.
エンドポイントが「ノー」の失敗、レポートヘッダフィールド値を持つSEND要求を受信した場合、それは障害報告要求を送ってはいけません、とトランザクション応答を送ってはいけません。値が「部分的」である場合は、その要求に200トランザクション応答を送ってはいけませんが、障害が発生した場合、適切な非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".
上述のように全く障害、レポートヘッダーフィールドが存在しない場合、それが「YES」の値を有する障害、レポートヘッダーフィールドと同じに扱われなければなりません。
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要求のためのものと同じです。この仕様で定義された任意のエラー応答コードも失敗レポートに使用されるかもしれません。
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要求に応答して送信される場合、それは上に報告される実際の範囲を示すバイト範囲ヘッダーフィールドを含まなければなりません。これは、元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]に考慮されます。私たちは、障害の報告書は、より一般的にエンドポイントによってよりリレーによって生成されることを期待しています。
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終点はどちらかが「はい」の失敗、レポートヘッダフィールド値が含まれているか、まったくの失敗、レポートヘッダフィールドが含まれていない要求を受信した場合、それはすぐにレスポンスを生成しなければなりません。 MSRPエンドポイントが「部分」の障害・レポートヘッダーフィールド値を含む要求を受信し、受信側が要求を処理できない場合は同様に、それは直ちに応答を生成する必要があります。
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.
応答を構築するために、エンドポイントは、最初に適切な応答コード、および必要に応じてコメントを挿入し、応答の開始行を作成します。応答開始ラインにおけるトランザクション識別子は、元の要求からトランザクション識別子と一致しなければなりません。
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.)
エンドポイントは、適切な対パスヘッダフィールドを挿入します。応答をトリガ要求がSEND要求であった場合にパスヘッダフィールドは要求のからパスヘッダフィールドの最初（左端）のURIをコピーすることによって形成されています。 （リクエストを送信するように応答が前のホップにのみ戻される。）他のすべてのリクエストメソッドに対する応答については、パスヘッダフィールドはフルパス元の送信者に含まれています。この完全なパスは、応答の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 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.
最後に、エンドポイントは、最後のヘッダフィールドの後にエンドラインに続く、セッションのコンテキストでそれを識別するURIを含むからパスヘッダフィールドを挿入します。応答がチャンク化されることはありませんので、最終ラインでの継続フラグは常にドル記号（「$」）を含んでいます。応答は、元の要求が到着した同じ接続で返送されなければなりません。
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.
受信エンドポイントは、最初の要求が既存のセッションに属していることを確認するために、パスにURIをチェックしなければなりません。要求を受信すると、へのパスは、要求が到着した接続に関連付けられている既存のセッションにマップする必要があります正確に一つのURIを、持っています。これが真でない場合、受信機は481エラーを生成し、要求を無視しなければなりません。故障・レポートのヘッダーフィールドが「いいえ」の値を持っていた場合、エラーレポートは送信されないであろうことに注意してください。
Further request processing by the receiver is method specific.
受信機によるさらなる要求処理方法特異的です。
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要求を受信すると、それは完全なメッセージ以上のメッセージからチャンクが含まれている場合、それは最初に決定します。要求がないバイト範囲ヘッダーフィールドを含まない、または「1」の範囲の開始値とのいずれかを含み、枠線の継続フラグが「$」の値を有する場合、その要求は、メッセージ全体を含んでいました。そうでなければ、受信機は、元のメッセージに一緒にチャンクを関連付けるためにメッセージID値を調べ。受信機は、受信されており、その欠落しているどのバイトを追跡する、メッセージを受信する仮想バッファを形成します。受信機は、リクエストからデータを受け取り、バッファ内の適切な場所に配置します。受信機は、ペイロード自体を検査することによって、各チャンクの実際の長さを決定すべきです。体が範囲エンドフィールドが示すよりも短いことも可能です。送信者が予期せず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 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.
レシーバは、チャンクが順番に配信されることを前提としなければならないではないか、彼らは「$」フラグを持つチャンクを受ける前に、彼らは「+」フラグですべてのチャンクを受信すること。情報を複製するための接続に失敗した特定の場合には、それが可能です。チャンクデータは、同じメッセージのためのデータを既に受信した重複する受信された場合、受信された最後のチャンク（これは最後のチャンクが送信されていなくても）優先順位を取るべきです。バイト1から100は、受信されたチャンクが到着した場合、例えば、それは、この第2のチャンクが既に受信されたデータの100バイト50が上書きされ、150バイト50を含んでいます。他のスキームは動作しますが、これは受信機のための最も簡単であるとクライアントの間で一貫性のある動作になります。
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.
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-TypeとContent-Dispositionによって決定します。メッセージ全体が受信またはそれが受信されているように部分的にレンダリングされた後に本体をレンダリングすることができます。
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要求がサポートされていないメディアタイプを示すContent-Typeヘッダフィールドに含まれ、故障・レポート値が「NO」でない場合、受信機は、すべてのMSRP終点ができなければならない415のステータスコードで応答を生成しなければなりません混合/マルチ[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.
成功-レポートヘッダフィールドが「はい」に設定した場合は、セクション7.1.3で説明したように、受信機は、一つ以上の成功のレポートを作成して送信する必要があります。
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.
エンドポイントがレポート要求を受信したときに存在する場合、それは、メッセージIDおよびバイト範囲を使用して、元のSEND要求にレポートを相関させます。それが成功の報告を求めた場合、それは元のメッセージにREPORT要求を関連付けることができるように、それはそれぞれの未解決の送信メッセージに関する十分な状態を維持する必要があります。
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.
「000」の名前空間フィールドでステータスヘッダフィールドを含むREPORT要求を受信するエンドポイントは、それは、ステータス・コード・フィールドに一致する応答コードとMSRPトランザクション応答の解釈とまったく同じようにレポートを解釈する必要があります。
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.
障害レポートや、現在配信されているチャンクの障害トランザクション応答を受信することが可能です。この場合、そのチャンクに対応するメッセージ全体は、エンドラインの継続フィールドに「＃」文字を含むことによって、中止されるべきです。
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要求を受信することが可能です。この問題が発生した場合、エンドポイントの動作はローカルポリシーの問題です。エンドポイントは、このような後半の配信を容易にするために、すべての手順を実行する必要はありません。すなわち、後半のレポートが到着した可能性がある場合は、アクティブな接続を維持することが期待されていません。
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要求を送信したエンドポイントが特定のバイト範囲が受信されなかったことを示す故障報告を受信したときに失敗したように、それはセッションを扱う必要があります。それが回復することを望む場合は、まず、シグナリング・レベルでURIを再交渉する、得られた新しいセッションにメッセージのバイトの範囲を再送しなければなりません。
MSRP nodes MUST NOT send MSRP REPORT requests in response to other REPORT requests.
MSRPノードは、他のREPORT要求に応じてMSRP REPORT要求を送ってはいけません。
MSRP sessions will typically be initiated using the Session Description Protocol (SDP) [2] via the SIP offer/answer mechanism [3].
MSRPセッションは、典型的には、セッション記述プロトコル（SDP）を使用して開始される[2] SIPオファー/アンサー機構を介して[3]。
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の考慮事項のセクションで詳述されています。
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 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.
MSRPメディアライン（つまり、MSRP提案メディアライン）セッション記述では、義務的な「パス」属性を伴っています。この属性は、このセッション記述を広告するユーザエージェントに連絡するために訪問するURIのスペース区切りのリストが含まれています。複数の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メディアラインは「受け入れる-タイプ」属性、および必要に応じて「受け入れ-ラップタイプ」属性を伴っています。これらの属性は、エンドポイントに許容されているメディアの種類を指定するために使用されています。
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.
[3]は、ユーザの提案を受け入れることを望む剤ではなく、特定のメディア・ライン、設定しなければならないに記載されているように、ポートフィールドの値は、それ以外は、パス属性にエンドポイントのMSRP URIで使用されるポート値と一致する必要があります応答でゼロへのメディア行のポート番号（0）。 MSRPは、複数のセッションが同じTCP接続を共有することを可能にするため、単一のSDP文書における複数のM行が同じポートフィールド値を共有することができます。 MSRPデバイスは、彼らがポートフィールドの値に一致している唯一の基準でM-線の間のいずれかの特定の関係を仮定してはいけません。
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行にコピーされます。メーカー希望小売価格は、理論的には任意のメディアタイプを運ぶことができる一方で、「メッセージ」は、適切なです。
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の交換で交渉されています。メーカー希望小売価格は、1つまたは複数のMSRP URIを含む「パス」属性が含まれなければならない提案している各SDP申し出か答え。パス属性は、SDP-ラインで使用され、以下の構文を有します。
path = path-label ":" path-list
path-label = "path"
path-list= MSRP-URI *(SP MSRP-URI)
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は、セクションで定義された「MSRP」または「msrps」URIです6. MSRP URIは、明示的なポート番号を含まなければならないSDPオファーまたは回答に含まれています。
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を選択し、SDPの文書におけるそのピアにそのURIを送信します。各ピア店はパス値は、他のピアから受信し、そして得られたセッション内の要求のターゲットとして、その値を使用します。ピアから受信パス属性は複数のURIが含まれている場合は、左端のエントリが隣接ホップを表す、ターゲットURIは右端です。唯一つのエントリが存在する場合、それは、ピアと隣接ホップURIの両方です。ターゲットパスは、ピアから受信したパス全体の属性値です。
The following example shows an SDP offer with a session URI of "msrp://alice.example.com:7394/2s93i9ek2a;tcp"
次の例は、 "：//alice.example.com; TCP 7394 / 2s93i9ek2a MSRP" のセッションURIとSDPオファーを示します
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 0 =アリス2890844526 2890844527 IN IP4 alice.example.com S = - C = IN IP4 alice.example.com T = 0、M =メッセージ7394 TCP / MSRP * A =受け入れる - タイプ：text / plainの=パス：メーカー希望小売価格：//alice.example.com：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.
path属性の右端URIはSDPドキュメントを生成し、エンドポイント、またはそのエンドポイントがセッションに関連付けられたリクエストを受信することを望む他の場所を識別しなければなりません。それは、この特定のセッションのために割り当てられなければならない、とエンドポイントは、現在参加している他のセッションのために使用中の任意のURIを複製してはなりません。推測するのは難しい、と盗聴者から保護されなければなりません。これは、第14章で詳しく説明されています。
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.
一つ以上のリレーを使用してエンドポイントがSDP経路属性に中継チェーン内の各デバイスのためにURIを置くことによってそれを示すことになります。最後のエントリは、エンドポイントそのものを指します。他のエントリは順番に、それぞれ提案されているリレーを示します。最初のエントリがピアの観点からチェーンにおける第1のリレーを指すことになる、すなわち、リレーにピアデバイス、またはその代わりに動作するリレーであり、接続しなければなりません。
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.
すべてのリレーをサポートしていないものを含め、リレーを挿入したくないエンドポイントは、path属性に正確に一つの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 first entry is relevant for purposes of resolving the address and port, and establishing the network connection, as it describes the first adjacent hop.
のみ、この仕様を実装するエンドポイントは、リレーを導入することはありませんにもかかわらず、彼らはリレーを使用して行う他のエンドポイントと相互運用できるようにする必要があります。したがって、それらは、SDP経路属性に複数のURIを受信するように準備しなければなりません。エンドポイントは、パス属性に複数のURIを受信したとき、それは最初の隣接ホップを記載しているように、最初のエントリは、アドレスとポートを解決し、ネットワーク接続を確立する目的のために適切です。
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.
エンドポイントは、パス属性に複数のURIを置く場合は、パス属性（ピアURI）の最後のURIは、セッションを識別し、エンドポイントが現在参加している他のセッションのURIを複製しないしなければなりません。 path属性内の他のエントリの一意性の要件は、この文書の範囲外です。
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.
いずれかのピアは随時更新交換を開始することができます。新しいプランを送信するエンドポイントは、すべての目的のために、オファーの役割を前提としています。回答は、更新の交換の時に自分自身への有効なパスを表すパス属性で応じなければなりません。この新しいパスは、その前のパスと同じであってもよいが、異なる場合があります。新しいオファー側は、ピアは、それが以前に使用したのと同じパスで答えると仮定してはいけません。
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ラインを使用しなければなりません。
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接続の方向を交渉するためのメカニズムが含まれていました。機構は緩く接続指向メディア（COMEDIA）MMUSICワーキンググループによって行われ[26]仕事に基づいていました。主な動機は、MSRPセッションは、オファー側が接続を受け入れることができなかったが、回答はできる状況で成功できるようにすることでした。回答は、グローバルにルーティング可能なアドレスを持っているかもしれないが例えば、オファー側は、NATの背後にあるかもしれません。
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は、デフォルトの接続方向を指定します。元のオファーを送った当事者はそのピアに接続するための責任があります。
An SDP media-line proposing MSRP MUST be accompanied by an accept-types attribute.
MSRPを提案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応答で応答します。すべての明示的なエントリが任意の非上場のタイプよりも優先考慮されるべきであることに注意してください。この機能は、そうでない場合は、豊富な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.
エンドポイントは、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.
受け入れるラップ・タイプのセマンティクスは受け入れる - タイプのものと同一である受け入れる - タイプに記載されている容器の種類内部属性に巻き付けたときに指定されたタイプにのみ使用されてもよいことを除いて、属性。受け入れ-種類に記載されている唯一のタイプは、体全体のための「ルート」型として使用することができる属性。受け入れる - タイプに記載されている任意のタイプは、両方のルート体として使用され、他の体に包まれてもよいので、受け入れる - タイプからフォーマットエントリは、この属性で繰り返されるべきではありません。
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つの包装の文脈におけるメディアタイプを理解する場合は、ラッパー型自体によって定義された制約を受ける、任意の他の許容されるラッパーの文脈でそれを理解することが想定されます。
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.
一次ペイロードタイプとは別にだけ容器の内部に許可されているタイプを特定のアプローチは、エンドポイントが特定のラッパーの使用を強制することを可能にします。例えば、共通のプレゼンスおよびインスタントメッセージング（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に示されているペイロードタイプのいずれかを理解していない場合は、ランデブー・プロトコルの適切なメカニズムを使用していることを示すべきです。例えば、SIPでは、SIP 488応答を返すべきです。
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.
エンドポイントは、それが最大サイズ・ライン属性を使用して受信したい最大サイズメッセージを示すかもしれません。最大サイズは、オクテットで完全なメッセージではなく、いずれかのチャンクの大きさを指します。送信者は、得られたセッションにおいて送信されたメッセージの最大サイズの制限を超えてはなりません。しかし、受信機は、ヒントとして、最大サイズの値を考慮する必要があります。
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.
Media形式のエントリは、パラメータを含むことができます。このようなパラメータの解釈は、メディアタイプの間で変化します。メディアタイプのネゴシエーションの目的のために、一つ以上のパラメータを持つ形式エントリは、パラメータなしで同じフォーマットのエントリと一致しているものとします。
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 ) )
/ ("*")
type = token subtype = token type-param = parm-attribute "=" parm-value parm-attribute = token parm-value = token / quoted-string
タイプ=トークンサブタイプ=トークンタイプのparam = PARM-属性 "=" PARM-値はPARM-属性=トークンPARM-値=トークン/引用符で囲まれた文字列
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：属性の構文
Endpoint A wishes to invite Endpoint B to an MSRP session. A offers the following session description:
エンドポイントAは、MSRPセッションにエンドポイントBを招待することを希望します。 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 0 =ユーザーA 2890844526 2890844527 IN IP4 alice.example.com S = - C = IN IP4 alice.example.com T = 0、M =メッセージ7394 TCP / MSRP * A =受け入れる-種類：メッセージ/ CPIMテキスト/プレーンテキスト/ htmlの=パス：メーカー希望小売価格：//alice.example.com：7394 / 2s93i93idj、TCP
Figure 9: SDP from Endpoint A
図9：エンドポイントAからSDP
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 0 =ユーザーB 2890844530 2890844532 IN IP4 bob.example.com S = - C = IN IP4 bob.example.com T = 0、M =メッセージ8493 TCP / MSRP * A =受け入れる-種類：メッセージ/ CPIMテキスト/平野=パス：メーカー希望小売価格：//bob.example.com：8493 / si438dsaodes、TCP
Figure 10: SDP from Endpoint B
図10：エンドポイントBからSDP
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シグナリングを使用して、その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.
このガイドラインは、このようなINVITE MSRPと音声セッションの両方が同じで提供されている混合メディアアプリケーション用としてすべての状況のために意味を持たないかもしれません。一般的には、優れたアプリケーション設計が優先されなければなりません。
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.
SIP INVITE要求は同じでINVITEを受信する複数のエンドポイントで、その結果、SIPプロキシによって二股されてもよいです。 SIP初期メディア[29]の手法は、最初のメッセージ（複数可）各エンドポイントに表示されているように、各エンドポイントと予備のセッションを確立するために使用され、一定の時間後にMSRPトラフィックを送信していない任意のエンドポイント用のINVITEトランザクションをキャンセルすることができます、彼らは招待者からのMSRPトラフィックの受信を中止するように。
SDP defines a number of attributes that modify the direction of media flows. These are the "sendonly", "recvonly", "inactive", and "sendrecv" attributes.
SDPは、メディアフローの方向を変更する属性の数を定義します。これらは "非アクティブ"、 "sendonlyの"、 "がrecvonly" であり、 "SENDRECVは" 属性。
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の方向は、通常のメッセージのペイロードを含む要求を送信示します。特に指定がない限り、これらの属性は、REPORTなどの要求の他のタイプ、の方向に影響を与えません。いくつかのコントロールまたはレポートプロトコルの種類ではなく、定期的なメッセージ・ペイロード（例えば、インスタント・メッセージ配信通知（IMDN）レポート）は、方向属性が存在しないかのようにプロトコル規則に従って生成されなければならないが含む要求を送信します。
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].
以下の構文仕様はRFC 4234に記載されているように拡張バッカスナウア記法（BNF）を使用する[6]。
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-REQ-OR-RESP = MSRP要求/ MSRP応答MSRP要求= REQスタートヘッダ[コンテンツスタッフ]エンドラインMSRP応答RESP =スタートヘッダエンドライン
req-start = pMSRP SP transact-id SP method CRLF resp-start = pMSRP SP transact-id SP status-code [SP comment] CRLF comment = utf8text
REQ-START = pMSRP SP用のTransact-ID SP法CRLFのRESPスタート= pMSRP SP用のTransact-ID SPステータスコード[SPコメント] CRLFコメント= 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。キャップ内のMSRPは、Transact-ID = IDENT方法= mSEND / mREPORT /他の方式mSEND =％x53.45.4e.44。キャップにSEND mREPORT =％x52.45.50.4f.52.54。キャップ内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-スキーム "：//" 権限[ "/" セッションID] ";"輸送*（ ";" URIパラメータ）; RFC3986で定義された権限
msrp-scheme = "msrp" / "msrps" session-id = 1*( unreserved / "+" / "=" / "/" ) ; unreserved as defined in RFC3986 transport = "tcp" / 1*ALPHANUM URI-parameter = token ["=" token]
MSRP-スキーム= "MSRP" / "msrps" セッションID = 1 *（予約されていません/ "+" / "=" / "/"）。予約されていないRFC3986輸送= "TCP" / 1 * ALPHANUM URIパラメータ=トークン[ "=" トークン]で定義されます
headers = To-Path CRLF From-Path CRLF 1*( header CRLF ) header = Message-ID / Success-Report / Failure-Report / Byte-Range / Status / ext-header
ヘッダ=のパスへのCRLFからパスCRLF 1 *（ヘッダーCRLF）ヘッダ=メッセージ-ID /成功-レポート/失敗-レポート/バイト範囲/ステータス/ EXT-ヘッダ
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を=「メッセージID ：」SP identを成功-報告書= "成功-レポート：" SP（ "はい" / "いいえ"）故障・レポート= "失敗-レポート：" SP（ "はい" / "いいえ ""/" 部分）バイト・範囲= "バイト範囲：" SP範囲スタート " - " 範囲エンド "/" 全範囲スタート= 1 * DIGIT範囲エンド= 1 * DIGIT / "*" トータル= 1 * DIGIT / "*"
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）。この文書で定義されたすべてのコードについては、「000」。
ident = ALPHANUM 3*31ident-char ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="
IDENT = ALPHANUM 3 * 31ident-CHAR identを-CHAR = ALPHANUM / "" / " - " / "+" / "％" / "="
content-stuff = *(Other-Mime-header CRLF) Content-Type 2CRLF data CRLF
コンテンツスタッフ= *（他-たMIMEヘッダCRLF）のContent-Type 2CRLFデータCRLF
Content-Type = "Content-Type:" SP media-type media-type = type "/" subtype *( ";" gen-param ) type = token subtype = token
Content-Typeの= "Content-Typeの" SPメディア型メディアタイプ=タイプ "/" サブタイプ*（ ";" GEN-paramは）=トークンのサブタイプを入力します=トークン
gen-param = pname [ "=" pval ] pname = token pval = token / quoted-string
GEN-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
引用符で囲んだ文字列= DQUOTE *（qdtext / QD-ESC）DQUOTE qdtext = SP / HTAB /％X21 /％x23-5B /％x5D-7E / UTF8-NONASCII QD-ESC =（バックスラッシュバックスラッシュ）/（バックスラッシュDQUOTE）BACKSLASH = "\" UPALPHA =％x41-5A ALPHANUM = ALPHA / DIGIT
Other-Mime-header = (Content-ID / Content-Description / Content-Disposition / mime-extension-field)
他の-マイム・ヘッダー=（コンテンツID /コンテンツ詳細/コンテンツの廃棄/ MIME拡張フィールド）
; 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
data = *OCTET
end-line = "-------" transact-id continuation-flag CRLF
continuation-flag = "+" / "$" / "#"
ext-header = hname ":" SP hval CRLF hname = ALPHA *token hval = utf8text
EXT-ヘッダ= hname "：" SP hval CRLF hname = ALPHA *トークンhval = utf8text
utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
UTF-8テキスト= *（TAB /％x20-7E / UTF-8 NON ASCII）
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 =％1UTF8-CONT XC0 DF / EF％xE0-2UTF8-CONT /％3UTF8 XF0-F7-CONT /％XF8 4UTF8-CONT-FB /％XFC-FD-UTF8 5UTF8-CONT CONT =％x80- BF
Figure 11: MSRP ABNF
図11：MSRP ABNF
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トランザクション応答で使用される様々な応答コードの意味をまとめたものです。これらのコードは、レポート要求でステータスヘッダフィールドに使用することができます。
The 200 response code indicates a successful transaction.
200レスポンスコードは、成功したトランザクションを示します。
A 400 response indicates that a request was unintelligible. The sender may retry the request after correcting the error.
400応答は、要求が不明瞭であったことを示しています。送信者は、エラーを訂正した後、要求を再試行することがあります。
A 403 response indicates that the attempted action is not allowed. The sender should not try the request again.
403応答は、試行されたアクションが許可されていないことを示しています。送信者は、要求を再試行してくださいべきではありません。
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応答を扱わなければなりません。
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.
メッセージの送信者が応答して、またはレポート要求413を受信した場合、それは、メッセージ内の任意の更なるチャンクを送ってはいけません、それは、同じMessage-ID値を持つ任意のさらなるチャンクです。送信者がチャンクを送信するプロセスで413しばらく受け取り、チャンクが中断された場合、送信者はそれを中断しなければなりません。
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要求を受信することによって理解されていないメディアタイプを含んでいたことを示しています。送信者は、セッションの間に同じコンテンツタイプを持つ任意の更なるメッセージを送るべきではありません。
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応答は、要求されたパラメータの一つが範囲外であることを示しています。それは、このドキュメントへのリレーの拡張機能で使用されています。
A 481 response indicates that the indicated session does not exist. The sender should terminate the session.
481応答は、示されたセッションが存在しないことを示しています。送信者は、セッションを終了する必要があります。
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応答コードは、メソッド拡張ある程度のを可能にするために存在します。それは、この文書で定義されたメソッドを無視するためのライセンスとして意図されていません。むしろ、拡張メソッドのサポートの欠如を報告するためのメカニズムです。
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応答は、要求がすでに別のネットワーク接続にバインドされたセッションに到着したことを示しています。送信者は、この接続でそのセッションのためにメッセージを送る中止すべきです。
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プロキシインフラストラクチャの詳細は簡潔にするために省略されています。 alice@example.com及び回答がSIPである：bob@example.com例では、申出がSIPであると仮定する。
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 |
|<-----------------------|
| |
| |
Figure 12: Basic IM Session Example
図12：基本的なIMセッションの例
1. Alice constructs a local URI of msrp://alicepc.example.com:7777/iau39soe2843z;tcp .
1.アリスはMSRPのローカルURIを構築します。//alicepc.example.com：7777 / iau39soe2843z; TCP。
Alice->Bob (SIP): INVITE sip:bob@example.com
Alice->ボブ（SIP）：SIP 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 0 =アリス2890844557 2890844559 IN IP4 alicepc.example.com S = - C = IN IP4 alicepc.example.com T = 0、M =メッセージ7777 TCP / MSRP * A =受け入れる - タイプ：text / plainの=パス：メーカー希望小売価格：//alicepc.example.com：7777 / iau39soe2843z、TCP
Bob->Alice (SIP): 200 OK
Bob->アリス（SIP）：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 = 0 0 =ボブ2890844612 2890844616 IN IP4 bob.example.com S = - C = IN IP4 bob.example.com T = 0、M =メッセージ8888 TCP / MSRP * A =受け入れる - タイプ：text / plainの=パス：メーカー希望小売価格：//bob.example.com：8888 / 9di4eae923wzd、TCP
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
Hi, I'm Alice!
-------d93kswow$
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
-------d93kswow$
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
Hi, Alice! I'm Bob!
-------dkei38sd$
MSRP dkei38sd 200 OK
To-Path: msrp://bob.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
-------dkei38sd$
Alice invalidates local session state.
アリスは、ローカルセッション状態を無効にします。
Bob->Alice (SIP): 200 OK
Bob->アリス（SIP）：200 OK
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のパスへ：メーカー希望小売価格：//alice.example.com：7777 / iau39soe2843z; TCPからのパス：メーカー希望小売価格：//bob.example.com：8888 / 9di4eae923wzd; TCPメッセージ-ID：456so39sバイト範囲： 1から374/374のContent-Type：アプリケーション/ XHTML + xmlの
<?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$
Figure 13: Example Message with XHTML
図13：XHTMLと例メッセージ
For an example of a chunked message, see the example in Section 5.1.
チャンクメッセージの例については、5.1節の例を参照してください。
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.
この例では、text / plainのペイロードをラップCPIMメッセージを含むチャンクメッセージを示しています。これは、MSRPメッセージをチャンクの前に完全なCPIMメッセージを考慮することは注目に値します。従って、CPIMヘッダーは最初のチャンクに含まれています。 MSRPコンテンツタイプとバイトレンジヘッダー、両方のチャンク内に存在するが、全体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
メーカー希望小売価格は、TO-パスSENDのd93kswow：メーカー希望小売価格：//bobpc.example.com：8888 / 9di4eae923wzd;からパスTCP：メーカー希望小売価格：//alicepc.example.com：7654 / iau39soe2843z; TCPメッセージ-ID：12339sdqwerバイト範囲： 1-137 / 148のContent-Type：メッセージ/ 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一口>：アリス<SIP：alice@example.com>日時：2006-05-15T15：02：31から03：00のContent-Type：text / plainの
ABCD
-------d93kswow+
Figure 14: First Chunk
図14：最初のチャンク
Alice sends the second and last chunk.
アリスは、第二と最後のチャンクを送信します。
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
メーカー希望小売価格は、TO-パスSENDのop2nc9a：メーカー希望小売価格：//bobpc.example.com：8888 / 9di4eae923wzd;からパスTCP：メーカー希望小売価格：//alicepc.example.com：7654 / iau39soe2843z; TCPメッセージ-ID：12339sdqwerバイト範囲： 138から148/148のContent-Type：メッセージ/ CPIM
1234567890
-------op2nc9a$
Figure 15: Second Chunk
図15：第二のチャンク
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
メーカー希望小売価格：//example.com：7777 / iau39soe2843z; TCPメッセージID：12339sdqwerバイトレンジ：1;メーカー希望小売価格：：：//alicepc.example.com TCPからパス8888 / 9di4eae923wzd MSRPはへパスを送るd93kswow 38/38失敗-レポート：なし成功-レポート：なしのContent-Type：text / plainの
This conference will end in 5 minutes
-------d93kswow$
Alice->Bob (MSRP):
Alice->ボブ（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
メーカー希望小売価格は、TO-パスSENDのd93kswow：メーカー希望小売価格：//bob.example.com：8888 / 9di4eae923wzd;からパスTCP：メーカー希望小売価格：//alicepc.example.com：7777 / iau39soe2843z; TCPメッセージ-ID：12339sdqwerバイト範囲： / 106 1-106成功-レポート：はい失敗-レポート：なしのContent-Type：text / htmlの
<html><body>
<p>Here is that important link...
<a href="http://www.example.com/foobar">foobar</a>
</p>
</body></html>
-------d93kswow$
Figure 16: Initial SEND Request
図16：初期SEND要求
Bob->Alice (MSRP):
Bob->アリス（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$
Figure 17: Success Report
図17：成功レポート
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が最高優先である）を発現します。
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プログラムを開いたとき、彼はジュリエットと種類のメッセージを選択し、「アート汝魅惑の？」 （代わりに、「あなたが？」の）。 juliet@thecapulets.example.com：彼のクライアントは、SIPにSIP招待状を送信します。プロキシは、最初バルコニーと同時にチャンバが試みます。クライアントは、ロミオのクライアントとのMSRPの早期セッションを設定し、どちらも、これらの各システム上で実行されています。クライアントが自動的に関与する2つのMSRPのURIにMSRPを超えるメッセージを送信します。ジュリエットからの応答なしまたは活性に数秒の遅延の後、プロキシは、彼女の最初の二つの接点での招待をキャンセルし、ジュリエットのPDA上への招待状を転送します。彼女の父親は彼女の結婚式についての彼女に話しているので、彼女が「ここにビジー」応答を送信する、彼女のPDAの「着信拒否」を選択します。プロキシは、次に答え、何が起こっているかロミオを告げる看護師を、しようとします。
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.... |
Figure 18: Forking Example
図18：フォーク例
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は最小限しか拡張できるように設計されました。新しいMSRPメソッド、ヘッダフィールド、およびステータスコードは標準トラックRFCで規定することができます。 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は、リレーやゲートウェイ機能が追加されるのを見越してパスおよびからパスヘッダフィールドに代えて、単一のURIのURIのリストを使用するように設計しました。また、「MSRP」および「msrps」URIは拡張可能なパラメータを含むことができます。
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セッションは、インスタントメッセージング（CPIM）[27]互換プロトコルの他の一般的なプロフィールへのゲートウェイへ行くことができます。この問題が発生した場合、ゲートウェイは、セッション状態を維持しなければならない、とのセッションの概念が含まれていないMSRPセッションのセマンティクスとCPIMセマンティクス、間を変換する必要があります。セッションのエンドポイントがCPIMゲートウェイである場合さらに、インスタントメッセージが「メッセージ/ CPIM」[12]体に包まれるべきです。そのようなゲートウェイは、SDP内の最初のエントリとして「メッセージ/ CPIM」を含まなければならない受け入れる-属性タイプ。最初のエントリとして「メッセージ/ CPIM」を含めたピアにインスタントメッセージを送信するMSRP終点受け入れる-タイプは「メッセージ/ CPIM」ラッパー内のすべてのインスタントメッセージのボディをカプセル化すべきである属性。全てMSRPエンドポイントは、メッセージ/ CPIMタイプをサポートしなければならない、および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エンベロープでラップする場合は、必要に応じて、ラッピングは、チャンクにメッセージを破壊する前に行う必要があります。
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エンドポイントは、に、日時から認識し、RFCで定義されている3862.このようなアプリケーションは、CCヘッダフィールドを認識すべきである、と件名ヘッダフィールドを認識することができるヘッダーフィールドを要求する必要があります。すべてのメッセージ/ 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身体の部分から含まなければなりません、そして、フィールドヘッダします。メッセージ/ CPIM本体部はS / MIMEを使用して保護されている場合、それはまた、日時のヘッダフィールドを含まなければなりません。
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、へ、そしてCCヘッダフィールドが複数回発生する可能性があります。 RFC 3862で定義されている他のヘッダフィールドは、MSRPメッセージ内の特定のメッセージ/ CPIM本体部に複数回発生してはいけません。 Requireヘッダーフィールドは、複数の値を含んでいてもよいです。 NSヘッダーフィールドは、多くの名前空間が参照されているかに応じて、0回以上起こり得ます。
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封筒を使用することも有用です。デバイスは、ヘッダフィールド値から適切とメッセージ/ CPIMエンベロープを追加することができます。
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システムが交換された情報、そしてあなたが正しい相手と通信している知識のための完全性と機密性の特性を提供する必要がある、と彼らは匿名通信の可能性を許可する必要があります。 MSRPは、SIPセッションを設定するとき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は、それが転送メッセージの機密性と完全性を提供する必要があります。また、接続されたホストは、それが、接続がハイジャックされていないことを接続することを意図したホストであることを保証を提供する必要があります。
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.
エンドポイントは、URIがピア間で共有される秘密が効果的であること、ランデブープロトコルでそのピアにMSRP URIを送信する場合。攻撃者は、前のセッションのセットアップの完了にURIを学習したり推測している場合、ピアの1つを偽装できる可能性があります。
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のほとんどのコンポーネントは、そのようなスキームや権限の構成要素として、一般的な知識です。秘密は完全にセッションIDコンポーネントによって提供されます。
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を生成する場合したがって、セッションIDコンポーネントは、ランダムの、少なくとも80ビットを含まなければなりません。
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は、ランデブー・プロトコルを使用するホスト名とシークレットを渡します。 MSRPはこの交換を保護する能力を持つランデブープロトコルを使用する必要がありますが、保護はすべての時間を使用するという保証はありません。そのような保護を使用しない場合は、誰もがこの秘密を見ることができます。その後、提供ホストに接続し、Aは、それがSYNパケットを送信した後、接続の両端の平文で秘密を配信する場所に基づいてBに話していると仮定B.ホストへの接続を介して明らかに秘密を渡すホスト。ホストBは、接続のもう一方の端のホストが秘密にしてお届けするので、それがに話している前提としています。 SYNパケットをACKができ、攻撃者は、接続中のman-in-the-middleとしての地位を挿入することができます。
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. Aに機密チャンネルを通過するB. BにTLSで接続されているAは、それが本当にB. Aに接続されている知っているので、有効な証明書を提示し、その後秘密を実現Bは、それがここでAに接続されていることを確認できるように、Bによって提供され、不正なSIPプロキシは、SIPシグナリングトラフィックに秘密を見ることができ、潜在的のman-in-the-middleとして自身を挿入することができました。
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 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名を持っている可能性が低いとして現実的には、よく知られた証明機関からの証明書とTLSを使用すると、ピア・ツー・ピア接続のために困難です証明書は、と結合することができます。また、よく知られた証明機関からのサーバー証明書のコストは、各クライアントのためのそれらの使用を阻止するのに十分な現在、高価です。周知の証明書なしでピア・ツー・ピア・モードでTLSを使用して、セクション14.4に記載されています。
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を実装しなければならないし、また、[11]に記載されているようにTLS ClientExtendedHelloサーバー名表示のhello拡張情報を実装しなければなりません。 TLS_RSA_WITH_AES_128_CBC_SHA [13]のTLS暗号スイートは、（他の暗号スイートもサポートすることができる）をサポートしなければなりません。
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で保護されたメッセージを運ぶことができます。すべてのMSRPの実装は、S / MIMEをサポートしていない場合でも、マルチパート/署名したメディアタイプをサポートしなければなりません。 SIPは、セッション鍵を運ぶことができるので、セッションのコンテキストでS / MIMEメッセージも使用して保護することができるキーラップの共有秘密[28]セッションセットアップに設けられました。 MSRPは、エンコードされていないバイナリペイロードを運ぶことができます。したがって、MIMEボディは、バイナリの転送エンコードで転送されなければなりません。メッセージが署名および暗号化されている両方の場合、それは、次に、暗号化、最初の署名されるべきです。 S / MIMEがサポートされている場合、SHA-1、SHA-256、RSAおよびAES-128をサポートしなければなりません。 RSAのために、実装は、少なくとも1024ビットのキーサイズをサポートしなければならないし、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で使用する場合、アイデンティティ[17]と証明書[25]メカニズムは見ることができ、明示的に信頼された認証サービス（ユーザ1つ）を除くAとBなしSIP仲介間の秘密のS / MIMEベースの送達を提供します秘密の。 SDPのS / MIME暗号化はまた、MSRPで使用することができる材料を合わせる交換するためにSIPで使用することができます。
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セッションは、MSRPを介して送信されるメッセージに署名して暗号化するために、この鍵素材でS / MIMEを使用することができます。秘密は、TCP接続のもう一方の端にクリアテキストで送信されますが、すべてのMSRPのコンテンツはS / MIMEで署名および暗号化されている場合の影響が軽減されるため、接続がまだハイジャックすることができます。この文書の範囲外ものの、MSRPセッションのSIPネゴシエーションは整合性とプライバシーのためのS / MIMEで使用される対称鍵素材を交渉することができます。
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は、適切な完全性保護を有することを確実にすることによって検証することができます。 SIPは、SDPを運ぶために使用される場合、完全性は、SIPアイデンティティ機構[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は、レコード（AOR）のユーザーのアドレスです。これはデバッグ目的のために有用であり、通信エンドポイントの1つに証明書をバインドする必要はありません。ピアツーピアTLSを行うこのプロトコルにおける通常のTLS動作とは異なり、のsubjectAltNameは、証明書検証の重要な構成要素ではありません。エンドポイントはまた、匿名のセッションをすることができる場合は、明確な、一意の証明書は、この目的のために使用しなければなりません。複数のユーザーで動作するクライアントの場合は、各ユーザーが独自の証明書を持っているべきです。公開鍵/秘密鍵ペアの生成は比較的高価であるため、エンドポイントは、各セッションの証明書を生成する必要はありません。
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.
証明書のフィンガープリントは、証明書の識別符号化規則（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 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]を介して確保することができます。クライアントが別のエンドポイントとの安全なMSRPセッションをセットアップするためにSIPを使用したい場合は、他のエンドポイントにSIPメッセージ内のSDPのオファーを送ります。このオファーは、SDPペイロード、エンドポイントが使用したい証明書のフィンガープリントの一部として、含まれています。オファーを含むSIPメッセージは、[17]に概説された手順に従ってIdentityヘッダを追加する申出のSIPプロキシに送られます。ファーエンドポイントがSIPメッセージを受信すると、アイデンティティ・ヘッダを使用して送信者の身元を確認することができます。 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
C = IN IP4 atlanta.example.com M =メッセージ7654 TCP / TLS / MSRP * A =受け入れる - タイプ：text / plainの=パス：msrps：//atlanta.example.com：7654 / jshA7weso3ks;のTCP A =指紋：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
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.
MSRPは、DoS攻撃用アンプとして使用することはできませんが、サーバー上でTCPコネクションリソースを消費するため、分散攻撃を形成するために使用することができます。攻撃者は、マロリーは、SIPがアリスにノープランでINVITEを送信します。アリスは申し出で200を返し、マロリーは彼のMSRPアドレスはトムのアドレスであることを示すSDPで答えを返します。アリスは申し出を送っているので、アリスはトムのサーバー上のリソースを使用して、トムへの接続を開始します。 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は、スパムに対処する上での問題に対処しようとしています。 MSRPセッションがMSRPレベルで開始していないときに、スパム問題はおそらく最高SIPレベルで扱われます。
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からのセッションを設定しているだろうか、「SIP：」URIスキーム。シグナリングは、特定のエンドユーザーに設定されている、およびS / MIMEが実装されている場合、クライアントは、証明書ののSubjectAltNameの名前が一致するエントリが含まれていることを確認する必要があります
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。 S / MIME証明書の名前と合図アイデンティティが一致しません、このようなIM会議などのいくつかのケースでは、あります。これらのケースでは、クライアントは、ユーザーがメッセージが証明書で特定されたユーザから来たことを知らされると、メッセージは、彼らが合図党から来たことを想定していないことを確認する必要があります。
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.
いくつかのケースでは、送信側デバイスは、いくつかの他のIDにメッセージを属性する必要があるかもしれませんし、同じセッションで異なるメッセージごとに異なるIDを使用することができます。例えば、会議サーバは、同じセッションで複数のユーザーの代わりにメッセージを送信することができます。この目的のために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ゲートウェイに由来し、新しいセッションに会議サーバによって転送されます。ゲートウェイ、会議サーバの両方が封筒をご紹介します。この場合、受信クライアントは、ユーザにIDアサーションの鎖を示すのではなく、ユーザがゲートウェイまたは会議サーバのいずれかがメッセージを発信したと仮定することが可能にすべきです。
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セッションを経由して、同じ送信者に帰属しているメッセージを受け取る可能性があることも可能です。例えば、アリスはTLSで保護チャネル上のMSRPセッションを経由して、ボブとの会話であるかもしれません。アリスはおそらく、サーバーによって署名されたメッセージ/ 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は、アイデンティティの同じペアの間で複数の同時セッションを禁止するものではありません。また、それは、エンドポイントが、会議サーバの場合のように、別のアイデンティティーに代わってメッセージを送信することを禁止ありません。受信者のエンドポイントは、セッションごとに独立して、送信者の真正性の信頼のそのレベルを決定する必要があります。エンドポイントは、任意のセッションで、送信者の信憑性を信頼しているという事実は、それが別のセッションで明らかに同じ送信者に割り当てる信頼のレベルに影響を与えるべきではありません。
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.
URI：MSRPクライアントが形成するか、または証明書を取得した場合、彼らはのsubjectAltNameは、このクライアントに対応する各URIのタイプuniformResourceIdentifierでののGeneralNameエントリを持つべきであり、常に「IM」が含まれていることを確認する必要があります。または「XMPP：」のURI：証明書は、このような「SIP」などの他の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デバイス上の潜在的な攻撃を認識しなければなりません。実装は、このようなバッファを割り当てる前にバイト範囲の値をチェックする正気のいくつかの程度を適用する必要があります。
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パラメータレジストリは、サブレジストリのコンテナです。このセクションでは、さらにMSRPメソッド名、ステータスコード、およびヘッダフィールド名のサブレジストリを導入します。
Additionally, Section 15.4 through Section 15.7 register new parameters in existing IANA registries.
また、15.7項によるセクション15.4は、既存のIANAレジストリで新しいパラメータを登録します。
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パラメータの下のメソッドサブレジストリを確立し、以下のようにその人口を開始します。このサブレジストリ内の新しいパラメータは、RFCで公開されている必要があり（いずれかIETF提出またはRFC編集者の提出など）。
SEND - [RFC4975] REPORT - [RFC4975]
送信 - [RFC4975] REPORT - [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番号。
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パラメータ下ヘッダフィールドのフィールドのサブレジストリを確立します。このサブレジストリ内の新しいパラメータは、RFCで公開されている必要があり（いずれかIETF提出またはRFC編集者の提出など）。次のようにその初期集団が定義されています。
To-Path - [RFC4975] From-Path - [RFC4975] Message-ID - [RFC4975] Success-Report - [RFC4975] Failure-Report - [RFC4975] Byte-Range - [RFC4975] Status - [RFC4975]
パス - [RFC4975]からのパス - [RFC4975]メッセージ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。 Oメソッドが登録されているRFC番号。
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パラメータの下でステータスコードのサブレジストリを確立します。このサブレジストリ内の新しいパラメータは、RFCで公開されている必要があり（いずれかIETF提出またはRFC編集者の提出など）。その初期集団は、それは次の形式をとり、セクション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番号。
MSRP uses TCP port 2855, from the "registered" port range. Usage of this value is described in Section 6.
MSRPは、「登録された」ポート範囲から、TCPポート2855を使用しています。この値の使用はセクション6に記載されています。
This document requests permanent registration the URI schemes of "msrp" and "msrps".
この文書は、「MSRP」と「msrps」のURIスキームを永久登録を要求します。
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スキームの構文：RFCのセクション9 4975. URIスキームの意味で "MSRP-URI" のためのABNFの構築を参照してください。RFC 4975のセクション6を参照してください：RFC 4975.エンコーディングの考慮事項のセクション6を参照してください。
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.
メッセージセッションリレープロトコル（MSRP）：このURIスキームを使用するアプリケーション/プロトコル。相互運用性に関する注意事項：MSRPのURIが唯一のMSRPの実装で使用されることが期待されます。追加の相互運用性の問題は予想されません。セキュリティに関する注意事項：一般的にはMSRPのためにMSRP URIの特定のセキュリティ上の考慮事項については、RFC 4975のセクション14.1、およびセキュリティ上の考慮事項については、RFC 4975のセクション14を参照してください。連絡先：ベン・キャンベル（ben@estacado.net）。著者/変更コントローラ：これは永久的な登録要求です。変更管理は適用されません。
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スキームの構文：RFC 4975. URIスキームの意味の第9項に「MSRP-URI」のためのABNF工事を参照してください：RFC 4975.アプリケーションのセクション6を参照してください：RFC 4975.エンコーディングの考慮事項のセクション6を参照してください。このURIスキームを使用/プロトコル：メッセージセッションリレープロトコル（MSRP）。相互運用性に関する注意事項：MSRPのURIが唯一のMSRPの実装で使用されることが期待されます。追加の相互運用性の問題は予想されません。セキュリティに関する注意事項：一般的にはMSRPのためにMSRP URIの特定のセキュリティ上の考慮事項については、RFC 4975のセクション14.1、およびセキュリティ上の考慮事項については、RFC 4975のセクション14を参照してください。連絡先：ベン・キャンベル（ben@estacado.net）。著者/変更コントローラ：これは永久的な登録要求です。変更管理は適用されません。
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パラメータのレジストリに登録されるべき新たなSDPプロトコル・フィールド値「TCP / MSRP」および「TCP / TLS / MSRP」を定義します。この最初の値は、TCPは、基礎となるトランスポートとして使用されるMSRPプロトコルを示しています。第二は、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）にのみつの値を許可します。実際のフォーマットの決意を「受け入れる-タイプ」と「受け入れ-ラップタイプ」属性を使用して行われます。
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-nameフィールドで使用されるべきです。
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）属性名：受け入れ-種類の長編属性名：許容可能なメディアタイプタイプ：charset属性に従いメディアレベル：いいえ目的と適切な値を：「-型を受け入れる」属性をエンドポイントが受信する意思があるメディアタイプのリストが含まれています。これは、スペースで区切られた文字列にゼロ以上の登録済みメディア・タイプ、または「*」が含まれていてもよいです。
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）属性名：受け入れ-ラップタイプのロングフォームは、属性名：許容可能なメディアタイプインサイドラッパータイプ：charset属性に従いメディアレベル：目的と適切な値はありません：「受け入れます-wrapped・タイプ」属性は、エンドポイントは、マルチパートコンテンツを含むMSRPメッセージ内で受信する意思があるが、メッセージの最も外側のタイプとして使用することができないメディアタイプのリストを含みます。これは、スペースで区切られた文字列にゼロ以上の登録済みメディア・タイプ、または「*」が含まれていてもよいです。
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）属性名：最大サイズロングフォームは、属性名：最大メッセージサイズの種類：charset属性に従いメディアレベル：目的と適切な値はありません：「最大サイズ」属性エンドポイントが受け入れることを望んで最大のメッセージを示します。これは、オクテットで指定された全体の数値をとることができます。
Contact Information: Ben Campbell (ben@estacado.net) Attribute-name: path Long-form Attribute Name: MSRP URI Path Type: Media level
お問い合わせ先：ベン・キャンベル（ben@estacado.net）属性名：パス長編属性名：MSRP URIのパスタイプ：メディアレベル
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デバイスのシリーズを示していません。属性は空白文字で区切られた一つ以上のMSRP URIを、含まれています。
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レヴィン、ハンスPerssonの、アダムローチ、ジョナサン・ローゼンバーグ、ロバート・スパークス：編集者に加えて、以下の人々は、このドキュメントに大規模な作業を貢献しました。
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.
エリック・バーガー、アリソンマンキン、ジョンピーターソン、ブライアン・ローゼン、ディーンウィリス、アキニエミ、ヒシャムKhartabil、ペッカPessi、ミゲル・ガルシア、ピーターRidler、サム・ハートマン、そしてジャン・マホーニー：次の人は、この継続的な努力にかなりの議論やフィードバックを貢献しました。
[1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[1]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[2]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、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と、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[6]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[7] Ramsdell、B.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[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.ムーア、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"、RFC 2183、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、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、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.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、RFC 4366、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）：メッセージの形式"、RFC 3862、2004年8月。
[13] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
、RFC 3268、2002年6月[13]のchown、P.、 "トランスポート層セキュリティ（TLS）用のAdvanced Encryption Standard（AES）暗号の組み合わせ"。
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[14] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[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：メディアタイプ"、RFC 2046、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.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、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.ジェニングス、 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、RFC 4474、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.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介してメディアトランスポート"、RFC 4572、2006年7月。
[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.レヴィン、 "セッション開始プロトコル（SIP）呼制御 - ユーザエージェントのための会議"、BCP 119、RFC 4579、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.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）で第三者呼制御（3PCC）のベストプラクティス現在" 、2004年4月。
[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、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、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）"、RFC 4976、2007年9月。
[24] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[24]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[25] Jennings, C., Peterson, J., and J. Fischl, "Certificate Management Service for SIP", Work in Progress, July 2007.
[25]ジェニングス、C.、ピーターソン、J.、およびJ. Fischl、 "SIPのための証明書管理サービス"、進歩、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.キャマリロ、 "セッション記述プロトコルでTCPベースのメディアトランスポート（SDP）"、RFC 4145、2005年9月。
[27] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[27]ピーターソン、J.、 "インスタントメッセージングのための共通プロファイル（CPIM）"、RFC 3860、2004年8月。
[28] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[28] Housley氏、R.、 "トリプルDESとRC2キーラッピング"、RFC 3217、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と、 "早期メディアとセッション開始プロトコル（SIP）にトーン生成リンギング"、RFC 3960、2004年12月。
[30] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[30]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"、RFC 3921、2004年10月。
[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、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[32] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[32]ピーターソン、J.、 "インスタントメッセージングとプレゼンスのためのアドレス解決"、RFC 3861、2004年8月。
Authors' Addresses
著者のアドレス
Ben Campbell (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 USA
ベン・キャンベル（エディタ）Estacadoシステム17210キャンベル道スイート250、ダラス、TX 75252 USA
EMail: ben@estacado.net
メールアドレス：ben@estacado.net
Rohan Mahy (editor) Plantronics 345 Encincal Street Santa Cruz, CA 95060 USA
ローハンリーヒー（エディタ）Plantronicsの345 Encincalストリートサンタクルス、CA 95060 USA
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
カレンジェニングス（エディタ）は、シスコシステムズ、株式会社170西タスマン博士MS：SJC-2分の21サンノゼ、CA 95134 USA
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
電話：+1 408 421-9990 Eメール：fluffy@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。