[要約] RFC 3428は、SIPを拡張してインスタントメッセージングをサポートするための仕様です。目的は、SIPセッションの開始と終了時にインスタントメッセージングを可能にすることです。
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.
Copyright（c）The Internet Society（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）とは、ユーザー間でリアルタイム近くにメッセージの転送を指します。これらのメッセージは通常、短くする必要はありませんが、必要ありません。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.
このドキュメントでは、インスタントメッセージの転送を可能にするセッション開始プロトコル（SIP）の拡張機能であるメッセージメソッドを提案します。メッセージ要求はSIPの拡張機能であるため、そのプロトコルのすべての要求ルーティングとセキュリティ機能を継承します。メッセージリクエストは、マイムボディパーツの形でコンテンツを伝えます。メッセージリクエストは、SIPダイアログを開始するわけではありません。通常の使用法の下で、各インスタントメッセージは、ポケットベルメッセージによく似ています。メッセージリクエストは、他の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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうは思わない」、「そうでない」、「推奨」、「推奨」、「5月」「オプション」は、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）は、ほぼリアルタイムの参加者のセット間のコンテンツの交換として定義されます。一般的に、コンテンツは短いテキストメッセージですが、そうである必要はありません。一般に、交換されるメッセージは保存されませんが、これも当てはまる必要はありません。私は一般的に使用されているため、一般的な使用法で電子メールとは異なります。そのため、通常は簡単なライブ会話にグループ化され、多数の小さなメッセージで構成されています。
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 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.
サービスとしてのインスタントメッセージングは、かなり長い間、イントラネットとIPネットワーク内に存在しています。早期の実装には、Zephyr [11]、Unix Talk Application、およびIRCが含まれます。最近では、IMは存在感とバディリストと組み合わせたサービスとして使用されています。つまり、友人がオンラインで来たとき、ユーザーはこれを認識し、友人にインスタントメッセージを送信するオプションを持つことができます。これを達成するためのプロトコルはすべて独自のものであり、相互運用性を真剣に妨げています。
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の拡張メソッドを提案します。メッセージ要求は通常、リクエスト本文にインスタントメッセージコンテンツを運びます。
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]は、存在とインスタントメッセージングプロトコルのモデルと要件を与えます。メッセージメソッドの実装は、適用可能性の範囲に関連する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対応のハンドセットの比phorと同様のメタファーを使用してインスタントメッセージを送信するためのメッセージメソッドの使用について説明します。つまり、メッセージ間に明示的な関連性はありません。それぞれのIMは単独で立っています - 「会話」の感覚は、クライアントユーザーインターフェイス、またはおそらくユーザー自身の想像力にのみ存在します。これは、「セッション」モデルとは対照的です。ここでは、明確な開始と終了と明示的な会話があります。SIP環境では、IMセッションは、招待取引で開始されたメディアセッションで、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つ以上の連絡先を招待することを選択できます。ページャーモデルは、ユーザーが少数の短いIMを単一の（または少数の）受信者に送信したい場合に理にかなっています。セッションモデルは、会話を他の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 Work Groupは現在、別のドキュメントで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.
ダイアログを開始し、そのダイアログのコンテキストでメッセージ要求を送信することにより、IMSのセッションをシミュレートする誘惑があるかもしれません。これは、メッセージリクエストが他のSIP要求と同じネットワークパスに従うことを強制するという点で、メッセージのリクエストを強制するという点で、メッセージのリクエストを強制するという点で、メッセージのリクエストが、メッセージリクエストがシグナリングではなくメディアを間違いなく運ぶことです。IMアプリケーションは通常大量であり、セッションのIMボリュームがさらに高くなると予想しています。これにより、混雑制御なしで輸送を介して送信された場合、これはおそらく渋滞の問題を引き起こす可能性があり、SIPには、HopがUDPを介してメッセージ要求を転送するのを防ぐ明確なメカニズムはありません。
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.
著者は、ダイアログのコンテキストでメッセージ要求を送信する正当な理由があるかもしれないことを認識しています。たとえば、音声セッションの1人の参加者は、IMを別の参加者に送信し、そのIMをセッションに関連付けることをお勧めします。ただし、実装は、メッセージリクエストを互いに関連付けるという主要な目的のためのダイアログを作成するべきではありません。
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を使用して、他のセッションと同様にIMSで構成されるメディアセッションを開始することを禁止していないことに注意してください。確かに、IMセッションの解決策がその比phorを使用することを期待しています。読者は、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.
あるユーザーが別のユーザーにインスタントメッセージを送信したい場合、送信者はこのドキュメントで定義された新しいメッセージメソッドを使用してSIPリクエストを策定および発行します。このリクエストのリクエストは、通常、インスタントメッセージの受信者の「記録のアドレス」となりますが、クライアントが受信者の場所に関する現在の情報を持っている状況では、デバイスアドレスである可能性があります。たとえば、クライアントは、特定のレコードアドレスに最新のデバイスの連絡先を提供する存在システムと結合することができます。リクエストの本文には、配信されるメッセージが含まれます。このボディは、メッセージ/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.
メッセージリクエストはダイアログを確立しません。
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].
このドキュメントで特に述べられていない限り、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].
メッセージメソッドをサポートするすべてのUACは、タイプテキスト/プレーンのボディでメッセージリクエストを送信するために準備する必要があります。彼らはタイプメッセージ/cpimの本文を送るかもしれません[7]。
MESSAGE requests do not initiate dialogs. User Agents MUST NOT insert Contact header fields into MESSAGE requests.
メッセージリクエストはダイアログを開始しません。ユーザーエージェントは、連絡先ヘッダーフィールドをメッセージリクエストに挿入してはなりません。
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は、メッセージ要求を既存のダイアログに関連付けることができます。メッセージ要求がダイアログ内で送信される場合、そのダイアログに関連するメディアセッションまたはセッションに「関連付けられています」。
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がメッセージ要求に対する200 OK応答を受け取った場合、メッセージが最終目的地に配信されたと仮定する場合があります。受信者が実際にインスタントメッセージを読んだと仮定してはなりません。UACが202の受け入れられた応答を受信した場合、メッセージはゲートウェイ、ストア、フォワードサーバー、または最終的にメッセージを配信する可能性のあるその他のサービスに配信されました。この場合、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.
ダウンストリームプロキシはメッセージリクエストをフォークする可能性があることに注意してください。これが発生した場合、フォーキングプロキシは、複数の最終応答を受信する可能性がある場合でも、上流の1つの応答を1つ転送します。UACには、フォークが発生するかどうかを検出する方法はありません。したがって、UACは、特定の最終応答がリクエストを受信する唯一のUASを表すと仮定してはなりません。たとえば、フォークの複数のブランチが2xx応答をもたらす可能性があります。UACはこれらの応答の1つだけを見ていますが、実際には2番目のデバイスでもリクエストが受信されています。
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がゼロ以外の値でヘッダーフィールドの有効期限を追加する場合、メッセージが送信される時間を含む日付ヘッダーフィールドも追加する必要があります。
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.
インスタント受信トレイは、「im：user@domain」の形でインスタントメッセージURI [8]によって最も一般的に参照される場合があります。im urisは抽象的であり、最終的には具体的なプロトコル依存性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に解決し、結果のURIを送信前にメッセージ要求のリクエスト-URIに配置する必要があります。UAがIM URIを解決できない場合、IM URIをリクエスト-RIに配置する可能性があり、プロキシやゲートウェイなどの下流のデバイスに解像度を委任します。この翻訳をできるだけ早く実行することで、SIPプロキシが可能になります。これは、IM：名前空間に気付かない場合があります。
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.
メッセージリクエストには、FromとHeaderフィールドの形で、送信者と意図された受信者の論理識別子も含まれています。これらの識別子には、SIP（またはSIP）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].
レコードルートおよびルートヘッダーフィールドには、im urisが含まれてはなりません。これらのヘッダーフィールドには、SIPの規則に従って、コンクリートSIPまたはSIP URIが含まれています[1]。
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のルール[1]に従って、ROUTEメッセージリクエストをプロキシします。メッセージ要求がフォークする可能性があることに注意してください。これにより、ユーザーがある可能性のあるいくつかの可能な端末にメッセージを配信できます。メッセージ要求のプロキシフォークは、非インバイト要求を分岐するための通常のSIPルールに従います。特に、フォークが複数の成功した配信をもたらしたとしても、フォーキングプロキシは上流の1つの最終応答のみを転送します。
A UAS that receives a MESSAGE request processes it following the rules of SIP [1].
メッセージ要求を受信する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.
メッセージ要求を受信する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.
メッセージリクエストに対する2xx応答には、本文を含めてはなりません。UASは、連絡先ヘッダーフィールドを2xx応答に挿入してはなりません。
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.
実際、メッセージリレー、メッセージを保存して後で転送する、または非SIPドメインに転送するメッセージリレーであるUASは、メッセージが受け入れられたことを示す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].
メッセージメソッドをサポートするUASは、タイプ「テキスト/プレーン」の体を受信およびレンダリングするために準備し、「メッセージ/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.
有効期限が切れた場合、メッセージ要求は期限切れになると言われています。有効期限は、存在する場合、有効期限がヘッダーフィールドを調べることによって決定されます。ヘッダーフィールドの有効期限が切れないメッセージ要求は期限切れになりません。有効期限がヘッダーフィールドにも含まれている場合、Date Headerフィールドも含まれている場合、UASはDate Headerフィールド値からDelta時間としてヘッダーフィールド値の有効期限を解釈する必要があります。リクエストに日付ヘッダーフィールドが含まれていない場合、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サービスには、非常に大量の使用法の歴史があります。さらに、メッセージリクエストは、ペイロードとしてIMSの形でメディアを運ぶという点で、他の種類のSIP要求とは異なります。従来のSIPペイロードには、メディアに関するシグナル伝達情報が含まれていますが、メディア自体ではありません。SIPインフラストラクチャがコールシグナリングとインスタントメッセージングの間で共有される場合、IMトラフィックはコールシグナリングトラフィックに干渉する可能性があります。一般的な混雑制御は、個々の方法ではなく、SIP仕様レベルで対処すべき問題です。しかし、トラフィックパターンは他のほとんどの方法とは異なる可能性が高いため、メッセージを特別に考慮することは理にかなっています。
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.
可能な場合はいつでも、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よりも200バイト少ない200バイトを選択し、デバイスがパスMTUを知らない場合は1300バイトを選択します。輸送の決定は、ホップごとに行われます。ただし、この制限のポイントは、上流のプロキシがUDPを介して大きなコンテンツを含むメッセージ要求を送信することを選択しないことを確認することです。些細な状況を除いて、メッセージクライアントは次のホップを超えて上流のデバイスの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.
重複するメッセージ要求に対する禁止は、ある程度の混雑に安全な動作を提供します。リクエストとそれに関連する応答は、それぞれ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.
暫定的な回答は、ポケットベルモデルのメッセージリクエストに対して許可されるべきではないことが示唆されています。ただし、多くのプロキシサーバーがメッセージメソッドを認識しないため、メッセージの特別な処理を要求することはできません。したがって、メッセージリクエストは、SIP仕様で説明されているように、他の非インバイト法と同じ暫定応答処理を受けます。
This specification defines a new SIP method, MESSAGE. The BNF for this method is:
この仕様は、新しいSIPメソッド、メッセージを定義します。この方法のBNFは次のとおりです。
MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
As with all other methods, the MESSAGE method name is case sensitive.
他のすべてのメソッドと同様に、メッセージメソッド名はケースに敏感です。
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は、SIP [1]の表2と3を追加列を追加して、メッセージのリクエストと応答で使用できるヘッダーフィールドを定義します。
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
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.
メッセージリクエストには、標準の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.
メッセージフローの例を図1に示します。メッセージフローは、ユーザー1からユーザー2に送信された初期IM、同じドメイン「ドメイン」の両方のユーザーが単一のプロキシを介して送信されたことを示しています。
| 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
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からsip：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
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:
ヘッダーフィールドのほとんどは、単に応答に反映されていることに注意してください。プロキシはこの応答を受信し、上部から除去し、次のvia、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
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リクエスト自体ではなく、メディアセッションで発生します。メッセージメソッドはこの仮定を変更します。メッセージ要求は、通常、参加者間の実際の通信をペイロードとして運びます。これは、メッセージリクエストが他のほとんどのSIPリクエストよりもセキュリティの必要性が高いことを意味します。特に、メッセージ要求をサポートするUASは、エンドツーエンド認証、身体の完全性、および身体の機密性メカニズムを実装する必要があります。
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.
さらに、フォーキングプロキシの可能性により、UACの知識なしにメッセージリクエストを追加のエンドポイントに配信することができます。ホップバイホップ保護のみが使用されている場合、ユーザーはチェーン内のすべてのプロキシを信頼して、不正な目的地への要求を分岐しないようにする必要があります。
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で確保する必要があります。メッセージメソッドによって運ばれるように将来指定されたボディがエンドツーエンドのセキュリティを提供する異なる手段を持っている場合、その仕様は使用法を説明する必要があります。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 [10]アルゴリズムは、AESが多くのプラットフォームの機能に最適な機能に最適であると予想されるため、推奨される必要があります。ただし、この執筆時点では、このための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リクエストのリプレイを防ぐために、すべての署名されたメッセージリクエストと応答には、メッセージ署名でカバーされている日付ヘッダーフィールドを含める必要があります。過去に数分以内の日付、または将来数分以上のメッセージは、そのようなメッセージが同じソースから繰り返し到着しない限り、400（誤った日付または時刻）メッセージで回答する必要があります。ケースは、応答を送信せずに破棄される場合があります。明らかに、このリプレイ攻撃防止メカニズムは、時計のないデバイスでは機能しません。
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.
古い日付ヘッダーフィールドが正常な状況があることに注意してください。たとえば、メッセージリクエストは、受信者がオフラインである間にストアとフォワードサーバーに保存されている可能性があります。受信者が返されると、そのサーバーはメッセージを転送する可能性があります。その後、メッセージの最終受領は、最初に送信された後に発生します。
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接続を介して）から来たことが確認できる古いメッセージを受信した場合、メッセージを正常に受け入れることは理にかなっています。また、1つ以上の古いメッセージがオフライン期間の直後に到着した場合、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.
メッセージ/CPIM形式[7]により、メッセージペイロード自体に加えて、メタデータの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 [RFC3428]
メッセージ[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
バーナード・アボバ・マイクロソフト・スティーブ・ドノヴァン・ダイナミクス・ジョナサン・レノックス・レノックス・コロンビア大学
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 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
ジョン・ピーターソン・ノイスター・ショーン・オルソン・マイクロソフト・アダム・ローチ・ダイナミクス・ビリー・ビッグス大学ウォータールー大学スチュアート・バークリー・ウネット・マウリシオ・アラゴ・サン・リチャード・ショッキー・ノイスター・ショッキー・ノイスター・ヨルゲン・ビョルカー・ヘンリー・シンリーッヒ・シンリーッヒ・マクイ・ワールドコム・ロナルド・エイカーチンシーメンス
15.Normative References
15.正規参照
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[2] Day、M.、Aggarwal、S。、およびJ. Vincent、「インスタントメッセージング /存在プロトコル要件」、RFC 2779、2000年2月。
[3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[3] Day、M.、Rosenberg、J。、およびH. Sugano、「存在感とインスタントメッセージングのモデル」、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] Roach、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] Bradner、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] Atkins、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] Crocker、D.、Diacakis、A.、Mazzoldi、F.、Huitema、C.、Klyne、G.、Rose、M.、Rosenberg、J.、Sparks、R.、Sugano、H。and J. Peterson、インスタントメッセージングと存在の解決策」、進行中の作業。
[9] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
[9] Rosenberg、J。およびH. Schulzrinne、「SIP Callerの好みとCallee能力」、進行中の作業。
[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、「CMSにおけるAES暗号化アルゴリズムと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.
[11] Dellafera、C.、Eichin、M.、French、R.、Jedlinski、D.、Kohl、J。and W. Sommerfeld、「The Zephyr Notification Service」、Usenix Winter Conference（テキサス州ダラス）、1988年2月。
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
Ben Campbell Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024
EMail: bcampbell@dynamicsoft.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: huitema@microsoft.com
David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
David Gurle Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: dgurle@microsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。