Network Working Group B. Campbell, Ed.
Request for Comments: 3428 J. Rosenberg
Category: Standards Track dynamicsoft
H. Schulzrinne
Columbia University
C. Huitema
D. Gurle
Microsoft Corporation
December 2002
Session Initiation Protocol (SIP) Extension for Instant Messaging
セッション開始プロトコル（SIP）インスタントメッセージングのための拡張
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
インスタントメッセージング（IM）は、ほぼリアルタイムでユーザー間のメッセージの転送を指します。これらのメッセージは通常ですが、短いである必要はありません。インスタントメッセージが頻繁に会話モードで使用されている、それは、メッセージの転送が前後にインタラクティブな会話を維持するために、参加者のために十分な速さ、です。
This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request.
この文書では、インスタントメッセージの転送を可能にするMESSAGEメソッド、セッション開始プロトコル（SIP）の拡張を提案しています。 MESSAGE要求はSIPの拡張であるため、そのプロトコルのすべての要求のルーティングおよびセキュリティ機能を継承します。 MESSAGEリクエストは、MIMEボディパーツの形でコンテンツを運びます。 MESSAGEリクエスト自体はSIPダイアログを開始しません。通常の使用では、各インスタントメッセージは、多くのポケベルメッセージのように、一人で立っています。 MESSAGEリクエストは、いくつかの他のSIP要求によって開始ダイアログのコンテキストで送信することができます。
Terminology
用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [6] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 「OPTIONAL」はBCP 14、RFC 2119に記載されているように[6]に解釈されるべきであり、対応するSIP実装のために要求レベルを示します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of Applicability . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. UAC Processing . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use of Instant Message URIs . . . . . . . . . . . . . . . . 6
6. Proxy Processing . . . . . . . . . . . . . . . . . . . . . . 6
7. UAS Processing . . . . . . . . . . . . . . . . . . . . . . . 7
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
9. Method Definition . . . . . . . . . . . . . . . . . . . . . 9
10. Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 13
11.1 Outbound authentication . . . . . . . . . . . . . . . . . . 13
11.2 SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.3 End-to-End Protection . . . . . . . . . . . . . . . . . . . 14
11.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 14
11.5 Using message/cpim bodies . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
15. Normative References . . . . . . . . . . . . . . . . . . . . 16
16. Informational References . . . . . . . . . . . . . . . . . . 16
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
18. Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Instant Messaging (IM) is defined as the exchange of content between a set of participants in near real time. Generally, the content is short text messages, although that need not be the case. Generally, the messages that are exchanged are not stored, but this also need not be the case. IM differs from email in common usage in that instant messages are usually grouped together into brief live conversations, consisting of numerous small messages sent back and forth.
インスタントメッセージング（IM）は、ほぼリアルタイムで参加者の集合の間でコンテンツのやり取りのように定義されます。それはケースである必要はないが、一般的に、コンテンツは、短いテキストメッセージです。一般的には、交換されるメッセージが保存されていないが、これは、ケースである必要はありません。 IMは、そのインスタントメッセージでの一般的な用法では、電子メールとは異なり、通常は前後に送られた多数の小さなメッセージからなる、簡単なライブの会話にグループ化されています。
Instant messaging as a service has been in existence within intranets and IP networks for quite some time. Early implementations include zephyr [11], the UNIX talk application, and IRC. More recently, IM
サービスとしてのインスタントメッセージングは、かなりの時間のためのイントラネットおよびIPネットワーク内で存在していました。初期の実装は、ゼファー[11]、UNIXのトークアプリケーション、およびIRCが含まれます。さらに最近では、IM
has been used as a service coupled with presence and buddy lists; that is, when a friend comes online, a user can be made aware of this and have the option of sending the friend an instant message. The protocols for accomplishing this are all proprietary, which has seriously hampered interoperability.
プレゼンスとバディリストに連結されたサービスとして使用されてきました。それは、ユーザーがこのことを認識して作られたと友人にインスタントメッセージを送信するオプションを持つことができ、友人がオンラインになったとき、です。これを達成するためのプロトコルは、真剣に相互運用性を妨げている、すべて独自のもの。
The integration of instant messaging, presence, and session-oriented communications is very powerful. The Session Initiation Protocol (SIP) [1] provides mechanisms that are useful for presence applications, and for session-oriented communication applications, but not for instant messages.
インスタントメッセージング、プレゼンス、およびセッション指向通信の統合は非常に強力です。セッション開始プロトコル（SIP）は、[1]プレゼンスアプリケーションのための、セッション指向の通信アプリケーションのためではなく、インスタントメッセージのための有用な機構を提供します。
This document proposes an extension method for SIP called the MESSAGE method. MESSAGE requests normally carry the instant message content in the request body.
この文書では、SIP MESSAGEメソッドと呼ばれるための拡張メソッドを提案しています。 MESSAGEリクエストは、通常、リクエストボディでインスタントメッセージの内容を運びます。
RFC 2778 [3] and RFC 2779 [2] give a model and requirements for presence and instant messaging protocols. Implementations of the MESSAGE method SHALL support all the instant message requirements in RFC 2779 relevant to its scope of applicability.
RFC 2778 [3]及びRFC 2779 [2]モデルとプレゼンスおよびインスタントメッセージングプロトコルのための要件を与えます。 MESSAGEメソッドの実装は、適用のその範囲に関連するRFC 2779のすべてのインスタントメッセージの要件をサポートします。
This document describes the use of the MESSAGE method for sending instant messages using a metaphor similar to that of a two-way pager or SMS enabled handset. That is, there are no explicit association between messages. Each IM stands alone--any sense of a "conversation" only exists in the client user interface, or perhaps in the user's own imagination. We contrast this with a "session" model, where there is an explicit conversation with a clear beginning and end. In the SIP environment, an IM session would be a media session initiated with an INVITE transaction and terminated with a BYE transaction.
この文書では、双方向ページャやSMS対応ハンドセットと同様のメタファーを使用してインスタントメッセージを送信するためのMESSAGEメソッドの使用方法を説明します。つまり、メッセージ間の明示的な関連性はありません。各IMは一人で立っている - 「会話」のいずれかの感覚は、クライアント・ユーザー・インターフェースで、またはおそらく、ユーザー自身の想像力に存在します。我々は明確な始まりと終わりとの明示的な会話がある「セッション」モデルとは対照的。 SIP環境では、IMセッションは、メディアセッションのINVITEトランザクションを開始し、BYEトランザクションで終了となります。
There is value in each model. Most modern IM clients offer both user experiences. The user can choose to send an IM to a contact, or he can choose to invite one or more contacts to join a conversation. The pager model makes sense when the user wishes to send a small number of short IMs to a single (or small number of) recipients. The session model makes sense for extended conversations, joining chat groups, if there is a need to associate a conversation with some other SIP initiated session, etc.
各モデルの値があります。最近のほとんどのIMクライアントは、両方のユーザー体験を提供します。ユーザーが連絡先にIMを送信するように選択することができ、または彼が会話に参加するために、1人のまたは複数の連絡先を招待することを選択できます。ユーザが受信者単一（または少数）にショートインスタントメッセージの少数を送信したいときにページャモデルは理にかなっています。などいくつかの他のSIPセッションを開始、との会話を関連付ける必要がある場合、セッション・モデルは、チャットグループに参加し、拡張の会話のために理にかなっています
This document addresses the pager model only. We recognize the value of the session model as well, but we do not define it here. Such a solution will require additional work beyond that of this document. The SIMPLE work group currently plans to address IM sessions in a separate document.
この文書では、唯一のポケットベルのモデルに対応しています。我々としても、セッションモデルの価値を認識し、我々はここでそれを定義していません。このような解決策は、この文書のそれを超えた追加作業が必要になります。 SIMPLEワークグループは、現在、別の文書にIMセッションに対処する予定です。
There may be a temptation to simulate a session of IMs by initiating a dialog, then sending MESSAGE requests in the context of that dialog. This is not an adequate solution for IM sessions, in that this approach forces the MESSAGE requests to follow the same network path as any other SIP requests, even though the MESSAGE requests arguably carry media rather than signaling. IM applications are typically high volume, and we expect the IM volume in sessions to be even higher. This will likely cause congestion problems if sent over a transport without congestion control, and there is no clear mechanism in SIP to prevent some hop from forwarding a MESSAGE request over UDP.
そのダイアログのコンテキストでMESSAGEリクエストを送信し、ダイアログを開始することにより、インスタントメッセージのセッションをシミュレートする誘惑があるかもしれません。これはつまり、このアプローチはMESSAGEリクエストは間違いなく、むしろ、シグナリングよりもメディアを運ぶにもかかわらず、他のSIPリクエストと同じネットワークパスに従うことMESSAGE要求を強制的に、IMセッションの適切な解決策ではありません。 IMアプリケーションは、通常、高容量であり、我々は、セッション中にIMボリュームがさらに高くなることを期待しています。輻輳制御なしで輸送を介して送信される場合、これはおそらく輻輳問題を引き起こすだろう、とUDP上MESSAGE要求を転送するから、いくつかのホップを防ぐために、SIPには明確なメカニズムはありません。
Additionally, MESSAGE requests sent over an existing dialog must, by the nature of SIP, go to the same destination as any other request sent in that dialog. This prevents any separation between the IM endpoint and the signaling endpoint. This is not an acceptable limitation for the session-model of instant messaging.
さらに、既存のダイアログ上で送信されたメッセージの要求は、SIPの性質によって、そのダイアログに送られ、他のリクエストと同じ目的地に移動する必要があります。これは、IMのエンドポイントとシグナリングのエンドポイント間のいずれかの分離を防ぐことができます。これは、インスタントメッセージングのセッション・モデルのための許容可能な制限ではありません。
The authors recognize that there may be valid reasons to send MESSAGE requests in the context of a dialog. For example, one participant in a voice session may wish to send an IM to another participant, and associate that IM with the session. But implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE requests with one another.
著者は、ダイアログのコンテキストでMESSAGEリクエストを送信するために正当な理由があるかもしれないことを認識しています。例えば、音声セッション内の1人の参加者が他の参加者にIMを送信することを望むかもしれない、とのセッションでそのIMを関連付けます。しかし、実装は互いにMESSAGE要求を関連付けるの主な目的のためのダイアログを作成しないでください。
Note that this statement does not prohibit using SIP to initiate a media session made up of IMs, just like any other session. Indeed, we expect the solution for IM sessions to use that metaphor. The reader should avoid confusing the concepts of a SIP dialog and a media session.
この文は、ちょうど他のセッションのように、インスタントメッセージで構成されたメディアセッションを開始するために、SIPを使用して禁止していないことに注意してください。確かに、私たちはそのメタファーを使用するには、IMセッションのためのソリューションを期待しています。読者は、SIPダイアログとメディアセッションの概念を混乱させないようにしてください。
When one user wishes to send an instant message to another, the sender formulates and issues a SIP request using the new MESSAGE method defined by this document. The Request-URI of this request will normally be the "address of record" for the recipient of the instant message, but it may be a device address in situations where the client has current information about the recipient's location. For example, the client could be coupled with a presence system that supplies an up to date device contact for a given address of record. The body of the request will contain the message to be delivered. This body can be of any MIME type, including message/cpim [7]. Since the message/cpim format is expected to be supported by other instant message protocols, endpoints using different IM protocols, but otherwise supporting message/cpim body types, should be able to exchange messages without modification of the content by a gateway or other intermediary. This helps to enable end-to-end security between endpoints that use different IM protocols.
1人のユーザーが別のものにインスタントメッセージを送信しようとする場合、送信者は定式化し、この文書で定義された新しいMESSAGEメソッドを使用してSIP要求を発行します。このリクエストのRequest-URIは、通常、インスタントメッセージの受信者のための「レコードのアドレス」になりますが、それは、クライアントが受信者の位置に関する最新の情報を持っている状況で、デバイスのアドレスであってもよいです。例えば、クライアントは、レコードの指定されたアドレスの日付デバイス接触までを提供するプレゼンスシステムと結合することができます。リクエストのボディは、配信されるメッセージが含まれています。この本体は、メッセージ/ CPIM [7]を含む、任意のMIMEタイプのものとすることができます。メッセージ/ CPIMフォーマットが異なるIMプロトコルを使用し、それ以外のメッセージ/ CPIMボディータイプをサポートしている他のインスタントメッセージプロトコル、エンドポイントによってサポートされることが予想されるので、ゲートウェイまたは他の仲介によって、コンテンツを変更することなくメッセージを交換することができなければなりません。これは、異なるIMプロトコルを使用して、エンドポイント間のエンドツーエンドのセキュリティを有効にするのに役立ちます。
The request may traverse a set of SIP proxies, using a variety of transports, before reaching its destination. The destination for each hop is located using the address resolution rules detailed in the Common Profile for Instant Messaging (CPIM) [8] and SIP specifications. During traversal, each proxy may rewrite the request URI based on available routing information.
要求は、その宛先に到達する前に、トランスポートのさまざまな方法を使って、SIPプロキシのセットを横断することができます。各ホップの宛先は、インスタントメッセージング（CPIM）のための共通プロファイルに詳述アドレス解決規則[8]とSIPの仕様を使用して配置されています。トラバーサルの間に、各プロキシは、利用可能なルーティング情報に基づいて、リクエストURIを書き換えることができます。
Provisional and final responses to the request will be returned to the sender as with any other SIP request. Normally, a 200 OK response will be generated by the user agent of the request's final recipient. Note that this indicates that the user agent accepted the message, not that the user has seen it.
要求への暫定最終的な応答は、他のSIP要求のように送信者に返送されます。通常は、200 OK応答は、要求の最終受取人のユーザエージェントによって生成されます。これは、ユーザーがそれを見ているではないことを、ユーザエージェントがメッセージを受け入れたことを示していることに注意してください。
MESSAGE requests do not establish dialogs.
MESSAGEリクエストは、ダイアログを確立しません。
Unless stated otherwise in this document, MESSAGE requests and associated responses are constructed according to the rules in section 8.1 of the SIP specification [1].
本書では、特に断らない限り、MESSAGEリクエストと関連する応答は、SIP仕様[1]のセクション8.1のルールに従って構築されます。
All UACs which support the MESSAGE method MUST be prepared to send MESSAGE requests with a body of type text/plain. They may send bodies of type message/cpim [7].
MESSAGEメソッドをサポートするすべての求めるUACは、タイプtext / plainでの本体とMESSAGEリクエストを送信するために準備しなければなりません。これらはタイプのメッセージ/ CPIM [7]のボディを送信することができます。
MESSAGE requests do not initiate dialogs. User Agents MUST NOT insert Contact header fields into MESSAGE requests.
MESSAGEリクエストは、ダイアログを開始しません。ユーザエージェントはMESSAGEリクエストにContactヘッダーフィールドを挿入してはなりません。
A UAC MAY associate a MESSAGE request with an existing dialog. If a MESSAGE request is sent within a dialog, it is "associated" with any media session or sessions associated with that dialog.
UACは、既存のダイアログでMESSAGE要求を関連付けることができます。 MESSAGEリクエストがダイアログ内で送信されている場合は、そのダイアログに関連付けられたすべてのメディアセッションまたはセッションに「関連する」されます。
If the UAC receives a 200 OK response to a MESSAGE request, it may assume the message has been delivered to the final destination. It MUST NOT assume that the recipient has actually read the instant message. If the UAC receives a 202 Accepted response, the message has been delivered to a gateway, store and forward server, or some other service that may eventually deliver the message. In this case, the UAC MUST NOT assume the message has been delivered to the final destination. If confirmation of delivery is required for a message that has been responded to with a 202 Accepted, that confirmation must be delivered via some other mechanism, which is beyond the scope of this specification.
UACは、MESSAGE要求に対する200 OK応答を受信した場合、それはメッセージが最終的な宛先に配信されたと仮定してもよいです。これは、受信者が実際にインスタントメッセージを読んでいると仮定してはいけません。 UACは、202 ACCEPTEDレスポンスを受信した場合、メッセージは、ゲートウェイ、ストアアンドフォワードサーバーに配信、又は最終的にメッセージを配信することができるいくつかの他のサービスされています。この場合、UACは、メッセージが最終的な宛先に配信されたと仮定してはいけません。送達確認が202で受け入れに応答されたメッセージのために必要とされる場合、その確認は、本明細書の範囲を超えていくつかの他の機構を介して送達されなければなりません。
Note that a downstream proxy could fork a MESSAGE request. If this occurs, the forking proxy will forward one final response upstream, even though it may receive multiple final responses. The UAC will have no way to detect whether or not a fork occurs. Therefore the UAC MUST NOT assume that a given final response represents the only UAS that receives the request. For example, multiple branches of a fork could have resulted in 2xx responses. Even though the UAC only sees one of those responses, the request has in fact been received by the second device as well.
下流のプロキシはMESSAGEリクエストをフォーク可能性があることに注意してください。この問題が発生した場合、フォークプロキシは、それが複数の最終応答を受け取ることができるにもかかわらず、上流の1つの最終応答を転送します。 UACは、フォークが発生したか否かを検出する方法がありませんでしょう。したがって、UACは、与えられた最終的な応答が要求を受信するだけUASを表すと仮定してはいけません。例えば、フォークの複数のブランチは、2xx応答を得たが。 UACはのみのいずれかの応答を見ているにもかかわらず、要求は、実際には、同様第二の装置によって受信されています。
The UAC MAY add an Expires header field to limit the validity of the message content. If the UAC adds an Expires header field with a non-zero value, it SHOULD also add a Date header field containing the time the message is sent.
UACは、メッセージの内容の有効性を制限するために、有効期限ヘッダーフィールドを加えるかもしれ。 UACは、非ゼロ値を有するヘッダフィールドを期限切れ追加する場合、それはまた、メッセージが送信される時刻を含むDateヘッダーフィールドを追加する必要があります。
An instant inbox may be most generally referenced by an Instant Message URI [8] in the form of "im:user@domain". IM URIs are abstract, and will eventually be translated to concrete, protocol-dependent URI.
インスタント受信箱は、最も一般的にインスタントメッセージURIにより参照することができる[8]の形で「IM：ユーザー@ドメイン」。 IM URIは抽象的であり、最終的にはコンクリート、プロトコル依存URIに変換されます。
If a UA is presented with an IM URI as the address for an instant message, it SHOULD resolve it to a SIP URI, and place the resulting URI in the Request-URI of the MESSAGE request before sending. If the UA is unable to resolve the IM URI, it MAY place the IM URI in the Request-URI, thus delegating the resolution to a downstream device such as proxy or gateway. Performing this translation as early as possible allows SIP proxies, which may be unaware of the im: namespace, to route the requests normally.
UAは、インスタントメッセージのアドレスとしてIM URIが提示されている場合は、SIP URIにそれを解決し、送信する前のRequest-URI MESSAGE要求の結果としてURIを配置する必要があります。 UAはIM URIを解決できない場合、それは、このように、このようなプロキシまたはゲートウェイなどの下流の装置に解像度を委任、リクエストURIでIM URIを配置することができます。ルートの名前空間、通常の要求：可能な限り早期にこの変換を実行すると、IMに気づかないかもしれSIPプロキシは、ことができます。
MESSAGE requests also contain logical identifiers of the sender and intended recipient, in the form of the From and To header fields. These identifiers SHOULD contain SIP (or SIPS) URIs, but MAY include IM URIs if the SIP URIs are not known at the time of request construction.
MESSAGEリクエストはまた、からの形で、送信者と受信者の意図した論理的な識別子が含まれているとフィールドをToヘッダー。これらの識別子は、SIP（またはSIPS）URIを含有しなければならないが、SIPのURIはリクエストの建設の時点で知られていない場合はIM URIを含むかもしれません。
Record-Route and Route header fields MUST NOT contain IM URIs. These header fields contain concrete SIP or SIPS URIs according to the rules of SIP [1].
レコードルートとRouteヘッダーフィールドはIM URIを含めることはできません。これらのヘッダーフィールドは、[1] SIPの規則に従ってコンクリートSIPまたはSIPS URIを含みます。
Proxies route MESSAGE requests according to the rules of SIP [1]. Note that the MESSAGE request MAY fork; this allows for delivery of the message to several possible terminals where the user might be. A proxy forking a MESSAGE request follows the normal SIP rules for forking a non-INVITE request. In particular, even if the fork results in multiple successful deliveries, the forking proxy will only forward one final response upstream.
SIPの規則に従ってプロキシルートMESSAGEリクエストを[1]。 MESSAGEリクエストがフォークかもしれないことに注意してください。これは、ユーザがあるかもしれないいくつかの可能な端末へのメッセージの配信を可能にします。 MESSAGEリクエストをフォークプロキシは非INVITEリクエストをフォークするための通常のSIPルールに従います。具体的には、たとえ複数成功した配送の分岐結果、フォーキングプロキシ意志だけ前方に1つの最終応答上流。
A UAS that receives a MESSAGE request processes it following the rules of SIP [1].
MESSAGE要求を受信するUASは、SIPのルールに従ってそれを処理[1]。
A UAS receiving a MESSAGE request SHOULD respond with a final response immediately. Note, however, that the UAS is not obliged to display the message to the user either before or after responding with a 200 OK. That is, a 200 OK response does not necessarily mean the user has read the message.
MESSAGEリクエストを受信UASは、直ちに最終応答で応答する必要があります。 UASは、前または200 OKで応答した後、いずれかのユーザーにメッセージを表示することが義務付けされていないこと、しかし、注意してください。それは、200 OK応答は、必ずしもユーザーがメッセージを読んでいるという意味ではありません、です。
A 2xx response to a MESSAGE request MUST NOT contain a body. A UAS MUST NOT insert a Contact header field into a 2xx response.
MESSAGE要求に対する2xx応答はボディを含めることはできません。 UASは、2xx応答にContactヘッダーフィールドを挿入してはなりません。
A UAS which is, in fact, a message relay, storing the message and forwarding it later on, or forwarding it into a non-SIP domain, SHOULD return a 202 (Accepted) [5] response indicating that the message was accepted, but end to end delivery has not been guaranteed.
、実際には、メッセージ中継あるUASは、メッセージを格納し、後でそれを転送し、または非SIPドメインにそれを転送し、202（承認）を返すべきである[5]応答メッセージが受け入れられたことを示しているが、配信は保証されていないエンドツーエンド。
A 4xx or 5xx response indicates that the message was not delivered successfully. A 6xx response means it was delivered successfully, but refused.
4XXまたは5xxの応答メッセージが正常に配信されなかったことを示しています。 6xx応答は、それが正常に配信が、拒否したことを意味します。
A UAS that supports the MESSAGE method MUST be prepared to receive and render bodies of type "text/plain", and may support reception and rendering of bodies of type "message/cpim" [7].
MESSAGEメソッドをサポートUASは、「text / plainの」受信及びタイプのボディをレンダリングするために準備しなければなりません、そしてタイプ「メッセージ/ CPIM」の体の受信およびレンダリングをサポートすることができる[7]。
A MESSAGE request is said to be expired if its expiration time has passed. The expiration time is determined by examining the Expires header field, if present. MESSAGE requests without an Expires header field do not expire. If the MESSAGE request containing an Expires header field also contains a Date header field, the UAS SHOULD interpret the Expires header field value as delta time from the Date header field value. If the request does not contain a Date header field, the UAS SHOULD interpret the Expires header value as delta time from the time the UAS received the request.
MESSAGEリクエストは、その有効期限が過ぎた場合は有効期限が切れていると言われています。有効期限が存在する場合、期限切れヘッダフィールドを調べることによって決定されます。有効期限ヘッダーフィールドのないMESSAGEリクエストは期限切れになりません。含むMESSAGEリクエストヘッダフィールドはまた、日付ヘッダーフィールドが含まれている有効期限が切れた場合、UASは、日付ヘッダーフィールド値からデルタ時間としてヘッダフィールド値を有効期限と解釈すべきです。リクエストがDateヘッダーフィールドが含まれていない場合、UASは、UASがリクエストを受信した時刻からデルタ時間としてヘッダ値を有効期限を解釈すべきです。
If the MESSAGE expires before the UAS is able to present the message to the user, the UAS SHOULD handle the message based on local policy. This policy could mean: the message is deleted undisplayed, the message is still displayed to the user, or some other policy may be invoked. If the message is displayed, the UAS SHOULD clearly indicate to the user that the message has expired.
UASは、ユーザーにメッセージを提示することができる前にメッセージの有効期限が切れた場合、UASは、ローカルポリシーに基づいてメッセージを処理する必要があります。このポリシーは、意味するかもしれません：メッセージは、メッセージがまだユーザーに表示される、または他のいくつかのポリシーが起動することができる、非表示に削除されます。メッセージが表示された場合、UASは明らかにメッセージの有効期限が切れたユーザーに示す必要があります。
If the UAS is acting as a message relay, and is unable to deliver the message before expiration, it chooses an action based on local policy. This action could involve deleting the message undelivered, delivering it as is, logging the expired message, or any other local policy.
UASはメッセージリレーとして機能し、有効期限前にメッセージを届けることができないされている場合は、ローカルポリシーに基づいてアクションを選択します。このアクションは、期限切れのメッセージ、またはその他のローカルポリシーをログに記録する、であるとして、それを提供し、未配信のメッセージを削除関与し得ます。
Existing IM services have a history of very high volume usage. Additionally, MESSAGE requests differ from other sorts of SIP requests in that they carry media, in the form of IMs, as payload. Conventional SIP payloads carry signaling information about media, but not media itself. There is potential that when a SIP infrastructure is shared between call signaling and instant messaging, the IM traffic will interfere with call signaling traffic. Congestion control in general is an issue that should be addressed at the SIP specification level rather than for an individual method. But since the traffic patterns are likely to be different for MESSAGE than for most other methods, it makes sense to give MESSAGE special consideration.
既存のIMサービスは非常に高いボリュームの使用の歴史を持っています。彼らはメディアを運ぶことに加えて、MESSAGEリクエストはペイロードとして、インスタントメッセージの形で、SIPリクエストの他の種類は異なります。従来のSIPペイロードは、メディア自体をメディアの情報を、シグナリングではなく運びます。 SIPインフラストラクチャは、コールシグナリングおよびインスタントメッセージングの間で共有されている場合、IMトラフィックは、コールシグナリングトラフィックを妨害することを可能性があります。一般に輻輳制御は、SIP仕様レベルではなく、個々の方法のために取り組まなければならない問題です。トラフィックパターンは、ほとんどの他の方法に比べMESSAGEごとに異なる可能性が高いので、しかし、それはMESSAGEに特別な配慮をすることに意味があります。
Whenever possible, MESSAGE requests SHOULD be sent over transports that implement end-to-end congestion control, such as TCP or SCTP. However, SIP does not provide a mechanism to prevent a downstream hop from sending a request over UDP. Even the requirement to use TCP for requests over a certain size can be overridden by the receiver. Therefore use of a congestion-controlled transport by the UAC is not sufficient.
可能な限り、MESSAGEリクエストは、TCPやSCTPなどのエンドツーエンドの輻輳制御を実装するトランスポート、上で送信されるべきです。しかし、SIPはUDPオーバー要求を送信するから下流ホップを防止するための仕組みを提供していません。一定規模以上の要求のためにTCPを使用することであっても要件は、受信機によって上書きすることができます。したがって、UACによる輻輳制御トランスポートを使用することは十分ではありません。
The size of MESSAGE requests outside of a media session MUST NOT exceed 1300 bytes, unless the UAC has positive knowledge that the message will not traverse a congestion-unsafe link at any hop, or that the message size is at least 200 bytes less than the lowest MTU value found en route to the UAS. Larger payloads may be sent as part of a media session, or using some type of content-indirection.
UACは、メッセージがメッセージサイズよりも少なくとも200バイト以下であることが、任意のホップで輻輳危険なリンクを通過、またはしないことを肯定知識を持っていない限りメッセージのサイズが1300のバイトを超えてはならないメディアセッションの外に要求しますUASへの途中で見つかった最小のMTU値。大きなペイロードは、メディアセッションの一部として送信され、またはコンテンツ・間接のいくつかのタイプを使用することができます。
At the time of this writing, there is no mechanism for a UAC to gain such knowledge outside of trivial network architectures, or networks that are wholly controlled by a single administrative domain. But if a mechanism for ensuring congestion-control at each hop is created in the future, MESSAGE clients can relax the size limit without requiring a change to this specification. The authors expect that such a mechanism or mechanism will be created in the near future.
これを書いている時点で、些細なネットワークアーキテクチャ、または完全に単一の管理ドメインによって制御されるネットワークの外にそのような知識を得るためにUACのためのメカニズムはありません。各ホップで輻輳制御を確実にするための機構が将来作成される場合は、メッセージクライアントはこの仕様の変更を必要とせずにサイズの制限を緩和することができます。著者は、このようなメカニズムやメカニズムが近い将来に作成されることを期待しています。
There have been discussions on making the 1300 byte limit based on the path MTU to the next hop SIP device. The SIP specification does exactly that, choosing the limit 200 bytes less than the path MTU, or 1300 bytes if the device does not know the path MTU. Transport decisions are made on a per-hop basis. However, the point of this limit is to make sure that no upstream proxy chooses to send a MESSAGE request with large content over UDP. Since, except in trivial circumstances, a MESSAGE client is very unlikely to know the MTU for upstream devices beyond the next hop, an MTU based limit is not very useful.
ネクストホップのSIPデバイスへのパスMTUに基づいて、1300バイトの制限を行うことについての議論がありました。 SIP仕様はパスMTU、またはデバイスがパスMTUを知らない場合は1300バイトより200バイト以下の制限を選択する、まさにそれを行います。交通の決定はホップごとに作られています。しかし、この制限のポイントには、上流プロキシがUDPを超える大規模なコンテンツを持つMESSAGEリクエストを送信することを選択しないことを確認することです。 、些細な状況を除いて、MESSAGEクライアントは、次のホップを越えて上流デバイス用のMTUを知ることはほとんどありませんので、MTUベースの制限は非常に有用ではありません。
A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI. Similarly, A UAC SHOULD NOT initiate overlapping MESSAGE transactions inside a dialog, and MUST NOT do so unless the route set for that dialog uses a congestion-controlled transport at every hop.
同じURIのために保留中の前のアウトオブダイアログトランザクションがある場合、UACは、指定されたURIへの新しいアウトオブダイアログメッセージトランザクションを開始してはなりません。同様に、UACは、ダイアログ内の重複メッセージトランザクションを開始してはならず、そのダイアログに設定されたルートは、すべてのホップで輻輳制御のトランスポートを使用しない限り、そうはなりません。
The prohibition against overlapping MESSAGE request provides some degree of congestion-safe behavior. A request and its associated response must each cross the full path between the UAC and the UAS. The time required for this will increase as networks become congested. This provides an adaptive mechanism to slow the introduction of new MESSAGE requests to the same destination.
MESSAGEリクエストが重複の禁止は混雑安全な行動のいくつかの学位を提供します。要求とそれに関連する応答は、各UACとUASとの間の完全なパスを横切らなければなりません。ネットワークが混雑になると、このために必要な時間が増加します。これは、同じ宛先への新しいメッセージリクエストの導入を遅らせるための適応メカニズムを提供します。
It has been suggested that provisional responses should not be allowed for pager-model MESSAGE requests. However, it is not possible to require special treatment for MESSAGE, since many proxy servers will not be aware of the MESSAGE method. Therefore MESSAGE requests will receive the same provisional response treatment as any other non-INVITE method, as described in the SIP specification.
暫定応答がポケベルモデルMESSAGE要求のために許されるべきではないことが示唆されています。多くのプロキシサーバーはMESSAGEメソッドを認識しませんので、しかし、MESSAGEのための特別な治療を必要とすることはできません。 SIP仕様に記載されているように、したがってMESSAGEリクエストは、任意の他の非INVITEメソッドと同じ暫定応答処理を受けます。
This specification defines a new SIP method, MESSAGE. The BNF for this method is:
この仕様は新しいSIPメソッド、MESSAGEを定義します。このメソッドのBNFは、次のとおりです。
MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
MENSAGEm =％x4D.45.53.53.41.47.45;キャップでMESSAGE
As with all other methods, the MESSAGE method name is case sensitive.
他のすべてのメソッドと同様に、MESSAGEメソッド名は大文字と小文字が区別されます。
Tables 1 and 2 extend Tables 2 and 3 of SIP [1] by adding an additional column, defining the header fields that can be used in MESSAGE requests and responses.
表1および表2は、MESSAGE要求と応答に用いることができるヘッダーフィールドを定義する、追加の列を追加することによって、表2及びSIPの3 [1]を延ばします。
Header Field where proxy MESSAGE
__________________________________________
Accept R -
Accept 2xx -
Accept 415 m*
Accept-Encoding R -
Accept-Encoding 2xx -
Accept-Encoding 415 m*
Accept-Language R -
Accept-Language 2xx -
Accept-Language 415 m*
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date a o
Error-Info 300-699 a o
Expires o
From c r m
In-Reply-To R o
Max-Forwards R amr m
Organization ar o
Table 1: Summary of header fields, A--O
表1：ヘッダーフィールドの概要、A - O
Header Field where proxy MESSAGE
__________________________________________
Priority R ar o
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
Record-Route ar -
Reply-To o
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr o
Server r o
Subject R o
Timestamp o
To c(1) r m
Unsupported 420 o
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
(1): copied with possible addition of tag
（1）：タグの可能加えてコピー
Table 2: Summary of header fields, P--Z
表2：ヘッダフィールドの概要、P - Z
A MESSAGE request MAY contain a body, using the standard MIME header fields to identify the content.
MESSAGE要求は、コンテンツを識別するために、標準的なMIMEヘッダフィールドを使用して、本体を含むかもしれません。
An example message flow is shown in Figure 1. The message flow shows an initial IM sent from User 1 to User 2, both users in the same domain, "domain", through a single proxy.
例えば、メッセージ・フローは、メッセージフローは最初のIMを示す図1に示され、同じドメイン内の両方のユーザーが、「ドメイン」は、単一のプロキシを介して、ユーザ2へのユーザ1から送られてきました。
| F1 MESSAGE | |
|--------------------> | F2 MESSAGE |
| | ----------------------->|
| | |
| | F3 200 OK |
| | <-----------------------|
| F4 200 OK | |
|<-------------------- | |
| | |
| | |
| | |
User 1 Proxy User 2
Figure 1: Example Message Flow
図1：例メッセージフロー
Message F1 looks like:
メッセージF1は、次のようになります。
MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18
MESSAGE SIP：user2@domain.com SIP / 2.0経由：SIP / 2.0 / TCP user1pc.domain.com;ブランチ= z9hG4bK776sgdkseマックス・フォワード：70から：SIP：user1@domain.com;タグは= 49583へ：SIP：user2の@ domain.comコールIDを：asd88asd77a@1.2.3.4ののCSeq：1つのMESSAGEのContent-Type：text / plainのコンテンツの長さ：18
Watson, come here.
ワトソンは、ここに来ます。
User1 forwards this message to the server for domain.com. The proxy receives this request, and recognizes that it is the server for domain.com. It looks up user2 in its database (built up through registrations), and finds a binding from sip:user2@domain.com to sip:user2@user2pc.domain.com. It forwards the request to user2. The resulting message, F2, looks like:
User1はdomain.comのサーバにこのメッセージを転送します。プロキシがこの要求を受信し、それがdomain.comのサーバーであることを認識しています。これは、（登録を通じて築き上げ）そのデータベースにはuser2を検索し、SIPから結合見つけた：一口にuser2@domain.com：user2@user2pc.domain.com。これは、user2に要求を転送します。結果のメッセージ、F2は、次のようになります。
MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 Max-Forwards: 69 From: sip:user1@domain.com;tag=49394 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18
MESSAGEのSIP：user2@domain.com SIP / 2.0経由：SIP / 2.0 / TCP proxy.domain.com;ブランチ= z9hG4bK123dsghds経由：SIP / 2.0 / TCP user1pc.domain.com;ブランチ= z9hG4bK776sgdkse。 = 1.2.3.4マックス・フォワードを受け取っ：69から：SIP：user1@domain.com;タグ= 49394へ：SIP：user2@domain.comコールIDを：asd88asd77a@1.2.3.4ののCSeq：1つのメッセージのContent-Type：テキスト/無地のContent-Length：18
Watson, come here.
ワトソンは、ここに来ます。
The message is received by user2, displayed, and a response is generated, message F3, and sent to the proxy:
メッセージはUSER2によって受信され、表示され、応答が生成され、メッセージF3、及びプロキシに送られます。
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
Note that most of the header fields are simply reflected in the response. The proxy receives this response, strips off the top Via, and forwards to the address in the next Via, user1pc.domain.com, the result being message F4:
ヘッダフィールドのほとんどは単に応答に反映されることに留意されたいです。プロキシは次の経由、user1pc.domain.com、結果でメッセージF4内のアドレスを最経由取り除き、および転送し、この応答を受け取ります。
SIP/2.0 200 OK Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 From: sip:user1@domain.com;;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP user1pc.domain.com;ブランチ= z9hG4bK776sgdkse。受け取った= 1.2.3.4から：SIP：user1@domain.com ;;タグ= 49394へ：SIP：user2@domain.com;タグ= ab8asdasd9のCall-ID：asd88asd77a@1.2.3.4ののCSeq：1 MESSAGEのコンテンツの長さ：0
In normal usage, most SIP requests are used to setup and modify communication sessions. The actual communication between participants happens in the media sessions, not in the SIP requests themselves. The MESSAGE method changes this assumption; MESSAGE requests normally carry the actual communication between participants as payload. This implies that MESSAGE requests have a greater need for security than most other SIP requests. In particular, UAs that support the MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms.
通常の使用では、ほとんどのSIPリクエストをセットアップするために使用し、通信セッションを変更しています。参加者間の実際の通信は、SIPが自分自身を要求しないで、メディアセッションで行われます。 MESSAGEメソッドは、この仮定を変更します。 MESSAGEリクエストは、通常、ペイロードとして、参加者間の実際の通信を運びます。これは、MESSAGE要求は、他のほとんどのSIPリクエストよりセキュリティのための大きい必要性があることを意味します。具体的には、MESSAGE要求をサポートするUAは、エンドツーエンドの認証、身体の完全性、および身体の機密性メカニズムを実装しなければなりません。
When local proxies are used for transmission of outbound messages, proxy authentication, as specified in RFC 3261, is RECOMMENDED. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network.
ローカルプロキシは、発信メッセージ、プロキシ認証の伝送のために使用される場合、RFC 3261で指定されるように推奨されています。これは、発信者の身元を確認し、発信ネットワークでなりすましやスパムを防止するのに有用です。
The SIPS URI mechanism [1] allows a UA to assert that every hop must occur over a secure connection. This provides some level of integrity and privacy protection. However, this requires the users to trust that each proxy in the request path is well-behaved, that is, they do not violate the rules for routing SIPS URIs. Also, any unencrypted bodies are fully exposed to the proxies.
SIPS URI機構[1] UAがすべてのホップが安全な接続を介して行わなければならないと主張することを可能にします。これは、整合性とプライバシー保護のいくつかのレベルを提供します。しかし、これは要求パス内の各プロキシは行儀である、つまり、彼らはSIPS URIをルーティングするためのルールに違反していないことを信頼するように、ユーザーが必要です。また、任意の暗号化されていない体は完全にプロキシにさらされています。
Additionally, the possibility of a forking proxy allows a MESSAGE request to be delivered to additional endpoints without the knowledge of the UAC. If only hop-by-hop protection is used, the users must trust all proxies in the chain to not fork requests to unauthorized destinations.
また、フォーキングプロキシの可能性は、MESSAGE要求がUACの知識がなくても、追加のエンドポイントに配信されることを可能にします。唯一のホップバイホップ保護が使用されている場合は、ユーザーが不正な目的地への要求をforkしないようにチェーン内のすべてのプロキシを信頼する必要があります。
When the goal is to remedy the concerns stated above, the MESSAGE bodies MUST be secured with S/MIME. If bodies specified in future to be carried by the MESSAGE method have different means of providing end-to-end security, their specification MUST describe the usage. SIP MESSAGE endpoints MUST support encryption (CMS EnvelopeData) and S/MIME signatures (CMS SignedData).
目標は、上記の問題を改善することである場合には、メッセージ本文には、S / MIMEで保護されなければなりません。 MESSAGEメソッドによって運ばれるために、将来的に指定された遺体は、エンドツーエンドのセキュリティを提供するさまざまな手段を持っている場合は、その仕様が使用法を説明しなければなりません。 SIPメッセージエンドポイントは、暗号化（CMS EnvelopeData）とS / MIME署名（CMSのSignedData）をサポートしなければなりません。
The S/MIME algorithms are set by RFC 3369 [4]. The AES [10] algorithm should be preferred, as it is expected that AES best suits the capabilities of many platforms. However, an IETF specification for this is still incomplete as of the time of this writing.
S / MIMEアルゴリズムは、RFC 3369によって設定されている[4]。 AESは最高の多くのプラットフォームの能力に合っていることが予想されるとして、AES [10]アルゴリズムは、優先されなければなりません。しかし、このためのIETF仕様ではまだこの記事の執筆時点のように不完全です。
To prevent the replay of old SIP requests, all signed MESSAGE requests and responses MUST contain a Date header field covered by the message signature. Any message with a date older than several minutes in the past, or which is more than several minutes in the future, SHOULD be answered with a 400 (Incorrect Date or Time) message, unless such messages arrive repeatedly from the same source, in which case they MAY be discarded without sending a response. Obviously, this replay attack prevention mechanism does not work for devices without clocks.
古いSIPリクエストのリプレイを防ぐために、すべての署名されたメッセージの要求と応答は、メッセージの署名でカバーDateヘッダフィールドを含まなければなりません。このようなメッセージはここで、同じソースから繰り返し到着しない限り、将来的には、数分以上である任意の過去に数分よりも古い日付のメッセージ、または、400（不正な日付または時刻）メッセージで応答すべきである（SHOULD）ケースは、彼らが応答を送信せずに破棄されることがあります。明らかに、このリプレイ攻撃防止機構は、クロックなしのデバイスでは動作しません。
Note that there are situations where an stale Date header field is normal. For example, the MESSAGE request may have been stored in a store and forward server while the recipient was offline. When the recipient returns, that server might then forward the message. Final receipt of the message would then occur some time after it was originally sent.
失効日ヘッダーフィールドが正常である状況があることに注意してください。受信者がオフラインであった間例えば、MESSAGEリクエストは、ストアアンドフォワードサーバーに格納されている可能性があります。受信者が返されると、そのサーバーは、メッセージを転送することがあります。それが最初に送信された後にメッセージの最終的な領収書はその後、いくつかの時間を発生するであろう。
If a UAS receives a stale message that can be confirmed to have come from a known store and forward server (perhaps over a TLS connection), it makes sense for it to accept the message normally. Also, if one or more stale messages arrive shortly after an offline period, the UAS MAY accept the message, but SHOULD warn the user that there is a risk the message has been replayed.
UASは（おそらくTLS接続を介して）知らストアアンドフォワードサーバーから来ていることを確認することができます古いメッセージを受信した場合、それは通常のメッセージを受け入れるようにするために、それは理にかなっています。一つ以上の古いメッセージがオフライン期間の後まもなく到着した場合にも、UASはメッセージを受け入れるかもしれが、メッセージが再生されている危険性があることをユーザに警告すべきです。
The message/cpim format [7] allows for the S/MIME protection of metadata in addition to the message payload itself. In many cases, this metadata is redundant with SIP header fields. Still, message/cpim adds value in that the protection of metadata can extend across protocol boundaries. For example, a signed message/cpim body can provide sender authentication using the message/cpim From header field, even if the message crosses a gateway to another CPIM compliant instant message service that does not understand SIP header fields.
[7]メッセージ/ CPIMフォーマットは、メッセージ・ペイロード自体に加えて、メタデータのS / MIME保護を可能にします。多くの場合、このメタデータは、SIPヘッダフィールドを持つ冗長です。それでも、メッセージ/ CPIMは、メタデータの保護は、プロトコルの境界を越えて拡張できることに値を追加します。例えば、署名されたメッセージ/ CPIMボディは、メッセージがSIPヘッダフィールドを理解していない別のCPIM準拠インスタントメッセージサービスへのゲートウェイを横切る場合でも、ヘッダフィールドからのメッセージ/ CPIMを使用して送信者認証を提供することができます。
This specification registers the MESSAGE method in the http://www.iana.org/assignments/sip-parameters/Method registry, according to the following information:
この仕様は、次の情報に従って、http://www.iana.org/assignments/sip-parameters/MethodレジストリのMESSAGEメソッドを登録します。
MESSAGE [RFC3428]
MESSAGE [RFC3428]
The following people made substantial contributions to this work:
次の人は、この仕事にかなりの貢献をしました。
Bernard Aboba Microsoft Steve Donovan dynamicsoft Jonathan Lennox Columbia University Dave Oran Cisco Robert Sparks dynamicsoft Dean Willis dynamicsoft
バーナードAbobaマイクロソフトのスティーブ・ドノバンdynamicsoftジョナサンレノックスコロンビア大学デイブ・オランシスコロバート・スパークスのdynamicsoftディーンウィリスdynamicsoft
The authors would like to thank the following people for their support of the concept of SIP for IM, support for this work, and for their useful comments and insights:
著者は、IMのためのSIPの概念の彼らのサポート、この仕事のためのサポートのため、そして彼らの有益なコメントと洞察のために以下の方々に感謝したいと思います：
Jon Peterson NeuStar Sean Olson Microsoft Adam Roach dynamicsoft Billy Biggs University of Waterloo
ウォータールーのジョン・ピーターソンNeuStarショーン・オルソンマイクロソフトアダムローチのdynamicsoftビリービッグス大学
Stuart Barkley UUNet Mauricio Arango SUN Richard Shockey NeuStar Jorgen Bjorker Hotsip Henry Sinnreich MCI Worldcom Ronald Akers Motorola Torrey Searle Indigo Software Rohan Mahy Cisco Christian Groves Ericsson Allison Mankin ISI Tan Ya-Ching Siemens
スチュアートバークリーUUNETマウリシオ・アランゴ日リチャードショッキーNeuStarヨルゲンBjorker HotsipヘンリーSinnreich MCIワールドコムロナルド・エイカーズモトローラトーリーサールインディゴソフトウェアロハンマーイシスコクリスチャン・グローブス・エリクソンアリソンマンキンISIタン雅 - チンシーメンス
[1] 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.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[2]日、M.、アガルワル、S.とJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[3日目、M.、ローゼンバーグ、J.とH.菅野、 "プレゼンスのためのモデルとインスタントメッセージング"、RFC 2778、2000年2月。
[4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[4] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3369、2002年8月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[6] Bradner, S., "Keywords for Use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーの、S.、 "要件レベルを示すためにRFCのに使用するためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", Work in Progress.
[7]アトキンス、D.とG. Klyne、「一般的なプレゼンスとインスタントメッセージングのメッセージ形式」が進行中で働いています。
[8] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Address Resolution for Instant Messaging and Presence", Work in Progress.
[8]クロッカー、D.、Diacakis、A.、Mazzoldi、F.、のHuitema、C.、Klyne、G.、ローズ、M.、ローゼンバーグ、J.、スパークス、R.、菅野、H.及びJ.ピーターソン、「インスタントメッセージングとプレゼンスのためのアドレス解決」、進行中の作業。
[9] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
[9]ローゼンバーグ、J.、およびH. Schulzrinneと、 "SIP発信者の設定と呼び出し先機能"、ProgressのWork。
[10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", Work in Progress.
[10] Schaad、J.とR. Housley氏、 "AES暗号化アルゴリズムとCMSでのRSA-OAEPキー交通機関の利用" が進行中で働いています。
[11] DellaFera, C., Eichin, M., French, R., Jedlinski, D., Kohl, J. and W. Sommerfeld, "The Zephyr notification service", in USENIX Winter Conference (Dallas, Texas), Feb. 1988.
USENIX冬季大会（ダラス、テキサス州）2012年02月に[11] DellaFera、C.、Eichin、M.、フランス語、R.、Jedlinski、D.、コールズ、J.およびW.ゾンマーフェルト、 "ゼファー通知サービス"、 。1988年。
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
ベン・キャンベルdynamicsoft 5100テニソンパークウェイスイート1200プラノ、TX 75024
EMail: bcampbell@dynamicsoft.com
メールアドレス：bcampbell@dynamicsoft.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デビッド・グルマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: dgurle@microsoft.com
メールアドレス：dgurle@microsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。