RFC3428 日本語訳
3428 Session Initiation Protocol (SIP) Extension for InstantMessaging. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C.Huitema, D. Gurle. December 2002. (Format: TXT=41475 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのB.キャンベル、エドをネットワークでつないでください。コメントのために以下を要求してください。 3428年のJ.ローゼンバーグカテゴリ: 規格Track dynamicsoft H.Schulzrinneコロンビア大学C.Huitema D.Gurleマイクロソフト社2002年12月
Session Initiation Protocol (SIP) Extension for Instant Messaging
インスタントメッセージングのためのセッション開始プロトコル(一口)拡大
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
近いリアルタイムで即時のMessaging(IM)はユーザの間のメッセージの転送について言及します。 通常、急にあるのが必要でないのを除いて、これらのメッセージはそうです。 IMsは会話形モードでしばしば使用されます、すなわち、メッセージの転送。前後に、関係者がインタラクティブの会話を維持できるくらい速くあります。
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方法(Instant Messagesの転送を許容するSession Initiationプロトコル(SIP)への拡大)を提案します。 MESSAGE要求がSIPへの拡大であるので、それはそのプロトコルのすべての要求ルーティングとセキュリティ機能を引き継ぎます。 MESSAGE要求はMIME身体の部分の形で内容を運びます。 自分たちではなく、要求がするMESSAGEがSIP対話を開始します。 正常な用法の下では、各Instant Messageはポケットベルのメッセージのように単独で立ちます。 ある他のSIP要求で開始された対話の文脈でMESSAGE要求を送るかもしれません。
Campbell, et. al. Standards Track [Page 1] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[1ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[6]ということであり、対応する一口実現のために要件レベルを示すべきであるかをさせましょう。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 適用性. . . . . . . . . . . . . . . . . . . 3 3の範囲。 操作. . . . . . . . . . . . . . . . . . . 4 4の概観。 UAC処理. . . . . . . . . . . . . . . . . . . . . . . 5 5。 インスタントメッセージURI. . . . . . . . . . . . . . . . 6 6の使用。 プロキシ処理. . . . . . . . . . . . . . . . . . . . . . 6 7。 UAS処理. . . . . . . . . . . . . . . . . . . . . . . 7 8。 輻輳制御. . . . . . . . . . . . . . . . . . . . . 8 9。 方法定義. . . . . . . . . . . . . . . . . . . . . 9 10。 例のメッセージ. . . . . . . . . . . . . . . . . . . . . . 11 11。 セキュリティConsiderations. . . . . . . . . . . . . . . . . . 13 11.1Outbound.13 11.2の認証SIPS URI. . . . . . . . . . . . . . . . . . . . . . . . . 14 11.3Endから終わりへのProtection. . . . . . . . . . . . . . . . . . . 14 11.4Replay Prevention. . . . . . . . . . . . . . . . . . . . . 14 11.5Usingメッセージ/cpimボディー. . . . . . . . . . . . . . . . . 15 12。 IANA問題. . . . . . . . . . . . . . . . . . . . 15 13。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . 15 14。 承認. . . . . . . . . . . . . . . . . . . . . . 15 15。 引用規格. . . . . . . . . . . . . . . . . . . . 16 16。 情報の参照. . . . . . . . . . . . . . . . . . 16 17。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 17 18。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 18
1. Introduction
1. 序論
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.
即時のMessaging(IM)は近いリアルタイムで1セットの関係者の間の内容の交換と定義されます。 一般に、それはそうである必要はありませんが、内容は短いテキスト・メッセージです。 一般に、交換されるメッセージは格納されませんが、また、これはそうである必要はありません。 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
Campbell, et. al. Standards Track [Page 2] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[2ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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.
インスタントメッセージング、存在、およびセッション指向のコミュニケーションの統合は非常に強力です。 Session Initiationプロトコル(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.
このドキュメントはMESSAGE方法と呼ばれるSIPのために拡大方法を提案します。 通常、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.
RFC2778[3]とRFC2779[2]は存在とインスタントメッセージングプロトコルのためのモデルと要件を与えます。 MESSAGE方法SHALLの実現は適用性の範囲に関連しているRFC2779ですべてのインスタントメッセージ要件を支持します。
2. Scope of Applicability
2. 適用性の範囲
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.
このドキュメントが両用ポケットベルのものと同様の比喩を使用することでMESSAGE方法の送付インスタントメッセージの使用について説明するか、またはSMSは受話器を可能にしました。 すなわち、メッセージの間には、どんな明白な協会もありません。 各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つ以上の接触が会話に参加するよう誘うのを選ぶことができます。 ユーザが短いIMsの少ない数をシングルに送りたがっているとき、ポケットベルモデルが理解できる、(少ない数、)、受取人。 セッションモデルは拡張会話のために理解できます、チャットグループに加わって交際する必要があれば、会話はある他の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セッションを記述するのを計画しています。
Campbell, et. al. Standards Track [Page 3] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[3ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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のセッションをシミュレートする誘惑があるかもしれません、MESSAGE要求がその時その対話の文脈で発信して。 これはIMセッションのための適切な解決法ではありません、このアプローチがいかなる他のSIP要求とも同じネットワーク経路に続くというMESSAGE要求を強制するので、MESSAGE要求は論証上シグナリングよりむしろメディアを運びますが。 IMアプリケーションは通常高いボリュームです、そして、私たちはセッションにおけるIMボリュームがさらに高いと予想します。 輻輳制御のない輸送の上に送ると、これはおそらく混雑問題を引き起こすでしょう、そして、あるホップがMESSAGE要求をUDPの上に転送するのを防ぐために、どんな明確なメカニズムも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の自然で、既存の対話の上に送られたMESSAGE要求はその対話で送られたいかなる他の要求とも同じ目的地に行かなければなりません。 これは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をセッションに関連づけたがっているかもしれません。 しかし、実現SHOULD NOTは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を使用するのを禁止しないことに注意して、まさしくいかなる他のセッションのようなIMsでも作られたメディアセッションを開始してください。 本当に、私たちはIMセッションの解決策がその比喩を使用すると予想します。 読者は、SIP対話とメディアセッションの概念を混乱させるのを避けるべきです。
3. Overview of Operation
3. 操作の概観
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
1人のユーザが別のものにインスタントメッセージを送りたがっているとき、送付者は、このドキュメントによって定義された新しいMESSAGE方法を使用することでSIP要求を定式化して、出します。 この要求のRequest-URIは通常インスタントメッセージの受取人のための「記録されている住所」でしょうが、それはクライアントが受取人の位置に関する現行情報を持っている状況でデバイスアドレスであるかもしれません。 例えば、最新の装置接触を記録の与えられたアドレスに供給する存在システムにクライアントを結びつけることができました。 要求のボディーは渡されるべきメッセージを含むでしょう。 このボディーはメッセージ/cpim[7]を含むどんなMIMEの種類のものであることができます。 メッセージ/cpim形式が他のインスタントメッセージプロトコル、異なったIMプロトコルを使用する終点によって支持されますが、そうでなければ、ボディータイプができるべきであるというメッセージ/cpimを支持するのに予想されるので
Campbell, et. al. Standards Track [Page 4] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[4ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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.
ゲートウェイか他の仲介者による内容の変更なしでメッセージを交換してください。 これは、異なった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.
目的地に到着する前にさまざまな輸送を使用して、要求は1セットのSIPプロキシを横断するかもしれません。 各ホップのための目的地は、Instant Messaging(CPIM)[8]とSIP仕様にCommon Profileで詳細なアドレス解決規則を使用することで見つけられています。 縦断の間、各プロキシは利用可能なルーティング情報に基づく要求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要求ならも要求への暫定的で最終的な応答を送付者に返すでしょう。 通常、200OK応答は要求の最終的な受取人のユーザエージェントによって発生するでしょう。 これが、ユーザエージェントがメッセージを受け入れたのを示すことに注意してください、そして、ユーザはそれを見るというわけではありませんでした。
MESSAGE requests do not establish dialogs.
MESSAGE要求は対話を確立しません。
4. UAC Processing
4. UAC処理
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に送るようにMESSAGE方法を支持するすべてのUACsを準備しなければなりません。 彼らはタイプメッセージ/cpim[7]のボディーを送るかもしれません。
MESSAGE requests do not initiate dialogs. User Agents MUST NOT insert Contact header fields into MESSAGE requests.
MESSAGE要求は対話を開始しません。 ユーザエージェントはContactヘッダーフィールドをMESSAGE要求に挿入してはいけません。
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 MAYは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要求への200OK応答を受けるなら、それは、メッセージが最終的な送付先に届けられたと仮定するかもしれません。 それは、受取人が実際にインスタントメッセージを読んだと仮定してはいけません。 UACが202Accepted応答を受けるなら、ゲートウェイか店と前進のサーバか、結局メッセージを送るかもしれないある他のサービスにメッセージを届けました。 この場合、UAC MUST NOTは、メッセージが最終的な送付先に届けられたと仮定します。 それが202Acceptedと共に反応したメッセージのために配送の確認を必要とするなら、ある他のメカニズムでその確認を提供しなければなりません。(それは、この仕様の範囲にあります)。
Campbell, et. al. Standards Track [Page 5] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[5ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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 MUST NOTは、与えられた最終的な応答が要求を受け取る唯一の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 MAYは、メッセージ内容の正当性を制限するためにExpiresヘッダーフィールドを加えます。 UACがExpiresヘッダーを加えるなら、非ゼロで値をさばいてください、それ。また、メッセージが送られる時を含んでいて、SHOULDはDateヘッダーフィールドを加えます。
5. Use of Instant Message URIs
5. インスタントメッセージURIの使用
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.
最も一般に、即時の受信トレイがフォームでのInstant Message URI[8]によって参照をつけられるかもしれない、「不-、: user@domain 、」 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.
アドレスが瞬間に通信するとき、IM URIをUAに与えます、それ。SHOULDはMESSAGEのRequest-URIにおける結果として起こるURIが発信する前に要求するSIP URI、および場所にそれを決議します。 UAがIM URIを決議できないなら、Request-URIにIM URIを置くかもしれません、その結果、プロキシかゲートウェイなどの川下の装置へ解決を代表として派遣します。 この翻訳を実行すると気づかないかもしれない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要求はFromとToヘッダーフィールドの形に送付者と意図している受取人の論理的な識別子を含んでいます。 これらの識別子SHOULDは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を含んではいけません。 SIP[1]の規則に従って、これらのヘッダーフィールドはコンクリートSIPかSIPS URIを含んでいます。
6. Proxy Processing
6. プロキシ処理
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
SIP[1]の規則に従って、プロキシはMESSAGE要求を発送します。 MESSAGE要求が分岐するかもしれないことに注意してください。 これはユーザがそうであるいくつかの可能な端末にメッセージの配送を考慮します。 MESSAGE要求を分岐させるプロキシは非INVITEをフォーク状にするための規則が要求する正常なSIPの後をつけます。 特に、フォーク
Campbell, et. al. Standards Track [Page 6] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[6ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
results in multiple successful deliveries, the forking proxy will only forward one final response upstream.
複数のうまくいっている配送における結果であり、分岐しているプロキシは1つの最終的な応答上流しか進めないでしょう。
7. UAS Processing
7. UAS処理
A UAS that receives a MESSAGE request processes it following the rules of SIP [1].
SIP[1]の規則に従って、MESSAGE要求を受け取るUASはそれを処理します。
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は、SHOULDがすぐに最終的な応答で応じるよう要求します。 しかしながら、UASが応じる前か200OKで応じた後にユーザにメッセージを表示するのが強いられないことに注意してください。 すなわち、200OK応答は、必ずユーザがメッセージを読んだことを意味するというわけではありません。
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 MUST NOTはContactヘッダーフィールドを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、SHOULDはメッセージを受け入れましたが、配送を終わらせる終わりを保証していないのを示す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はタイプのボディーを「テキスト/明瞭に」受けて、するように準備しなければならなくて、タイプ「メッセージ/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要求は吐き出されると言われます。 満了時間は、Expiresヘッダーフィールドを調べることによって決定していて、存在しています。 ExpiresヘッダーフィールドのないMESSAGE要求は期限が切れません。 MESSAGEが、また、Expiresヘッダーフィールドを含んでいるとDateヘッダーフィールドが含むよう要求するなら、UAS SHOULDはDateヘッダーフィールド価値からのデルタ時間としてExpiresヘッダーフィールド価値を解釈します。 要求がDateヘッダーフィールドを含んでいないなら、UAS SHOULDはUASが要求を受け取った時からのデルタ時間としてExpiresヘッダー価値を解釈します。
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,
UASがユーザにメッセージを提示できる前にMESSAGEが期限が切れるなら、UAS SHOULDはローカルの方針に基づくメッセージを扱います。 この方針は以下を意味するかもしれません。 メッセージは非表示されていた状態で削除されます。
Campbell, et. al. Standards Track [Page 7] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[7ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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 SHOULDは、メッセージが期限が切れたのを明確にユーザに示します。
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がメッセージリレーとして機能していて、満了の前にメッセージを送ることができないなら、それはローカルの方針に基づく動作を選びます。 この動作は、そのままでそれを届けて、「非-渡」されたメッセージを削除することを伴うかもしれません、満期のメッセージ、またはいかなる他のローカルの方針も登録して。
8. Congestion Control
8. 輻輳制御
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要求と異なっています、IMsの形で、ペイロードとして。 従来の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は、SHOULDが終わりからエンドへの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.
MESSAGEのサイズは、メディアセッションの外部が1300バイトを超えてはいけないよう要求します、UACにメッセージがどんなホップでも混雑危険なリンクを横断しないか、メッセージサイズが少なくとも200バイトであるという積極的な知識が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がただ一つの管理ドメインによって完全に制御される些細なネットワークアーキテクチャ、またはネットワークの外でそのような知識を獲得するように、メカニズムは全くありません。 しかし、各ホップで輻輳制御を確実にするためのメカニズムが将来作成されるなら、この仕様への変化を必要としないで、MESSAGEクライアントはサイズ限界を弛緩できます。 作者は、そのようなメカニズムかメカニズムが近い将来作成されると予想します。
Campbell, et. al. Standards Track [Page 8] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[8ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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.
経路に基づいた1300年のバイトの限界を次のホップSIP装置へのMTUにするのと議論がありました。 SIP仕様は、限界を200バイト選ばないで、経路MTUよりちょうどそれをするか、または装置が経路MTUを知らないなら、1300バイトします。 1ホップあたり1個のベースで輸送決定をします。 しかしながら、この限界のポイントはどんな上流のプロキシも、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に、未定の前の対話で出ている取引があれば、A UAC MUST NOTは新しい対話で出ているMESSAGE取引を当然のことのURIに開始します。 同様に、A UAC SHOULD NOTは対話で重なっているMESSAGE取引を開始して、その対話に設定されたルートがあらゆるホップで混雑で制御された輸送を使用するというわけではないなら、そうしてはいけません。
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の間のフルパスに交差しなければなりません。 ネットワークが混雑するようになるのに従って、これに必要である時間は増加するでしょう。 これは、新しいMESSAGE要求の導入を同じ目的地に遅くするために適応型のメカニズムを提供します。
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方法を意識しないので。 したがって、MESSAGE要求はいかなる他の非INVITE方法とも同じ暫定的な応答処理を受けるでしょう、SIP仕様で説明されるように。
9. Method Definition
9. 方法定義
This specification defines a new SIP method, MESSAGE. The BNF for this method is:
MESSAGE、この仕様は新しいSIP方法を定義します。 この方法のためのBNFは以下の通りです。
MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
MESSAGEm=%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は追加コラムを加えることによって、SIP[1]のTables2と3を広げています、MESSAGE要求と応答に使用できるヘッダーフィールドを定義して。
Campbell, et. al. Standards Track [Page 9] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[9ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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
ヘッダーField、どこプロキシMESSAGE__________________________________________ Rを受け入れてください--2xxを受け入れてください--コード化を受け入れている*415m Rを受け入れてください--コード化を受け入れている2xx--コード化を受け入れている*言語を受け入れている415m R--言語を受け入れている2xx--言語を受け入れている415m*注意深いインフォメーションR--注意深いインフォメーション180--R o Allow 2xx o Allow r o Allow405m Authentication-インフォメーション2xx o Authorization R o Call-ID c rを許容してください; m Call-インフォメーションar o Contact R(接触1xx)は2xxに連絡します--3xx○o Expires o From c rあたり1o Error-インフォメーション300-699あたりのContentをコード化しているContact485のo Content-気質o o Content-言語o Content-長さのar tコンテントタイプ*CSeq c r m Date mに連絡してください、Inが答える、R o前方へマックスR amr m Organization ar o
Table 1: Summary of header fields, A--O
テーブル1: A--ヘッダーフィールドの概要、O
Campbell, et. al. Standards Track [Page 10] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[10ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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
ヘッダーField、どこプロキシMESSAGE__________________________________________ R ar oが407ar mにProxy認証する優先権がar mがWWW認証する401ar o R dr oがProxy必要とするProxy-認可R ar o Record-ルートar--○ o50万503o600,603o Route R adr o Server r o Subject R o Timestamp o To c(1)r m Unsupported420o User-エージェントo Via R amr m Via rc dr m Warning r oがWWW認証するRequire ar c後のRetry4044億1348万486に答え401をProxy認証する、407ar 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ヘッダーフィールドを使用して、MESSAGE要求はボディーを含むかもしれません。
10. Example Messages
10. 例のメッセージ
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に示されます。 メッセージ流動はUser1からUser2に送られた、初期のIM、同じドメインの両方のユーザに「ドメイン」を示しています、独身のプロキシを通して。
Campbell, et. al. Standards Track [Page 11] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[11ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
| F1 MESSAGE | |
|--------------------> | F2 MESSAGE |
| | ----------------------->|
| | |
| | F3 200 OK |
| | <-----------------------|
| F4 200 OK | |
|<-------------------- | |
| | |
| | |
| | |
User 1 Proxy User 2
| F1メッセージ| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| F2メッセージ| | | ----------------------->|、|、|、|、|、| F3 200OK| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F4 200OK| | |<-------------------- | | | | | | | | | | | 1人のユーザプロキシユーザ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一口: user2@domain.com SIP/2.0Via: 一口/2.0/TCP user1pc.domain.com; ブランチは前方へz9hG4bK776sgdkseマックスと等しいです: 70 From: 一口: user1@domain.com;tag =49583To: 一口: user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 メッセージコンテントタイプ: テキスト/明瞭なContent-長さ: 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を見上げて、ちびちび飲むために一口からの結合: 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一口: user2@domain.com SIP/2.0Via: 一口/2.0/TCP proxy.domain.com; ブランチは以下を通ってz9hG4bK123dsghdsと等しいです。 一口/2.0/TCP user1pc.domain.com; ブランチはz9hG4bK776sgdkseと等しいです。 容認された=1.2.3の.4のマックス-フォワード: 69 From: 一口: user1@domain.com;tag =49394To: 一口: user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 メッセージコンテントタイプ: テキスト/明瞭なContent-長さ: 18
Campbell, et. al. Standards Track [Page 12] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[12ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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
以下を通って一口/2.0 200OK 一口/2.0/TCP proxy.domain.com; ブランチはz9hG4bK123dsghdsと等しいです。 容認された=、192.0 .2 .1Via: SIP/2.0/TCP user1pc.domain.com。ブランチはz9hG4bK776sgdkseと等しいです。 容認された=1.2.3.4From: 一口: user1@domain.com;tag =49394To: 一口: user2@domain.com;tag はab8asdasd9 Call-IDと等しいです: asd88asd77a@1.2.3.4 CSeq: 1 メッセージコンテンツの長さ: 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、およびフォワードの片を次の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
以下を通って一口/2.0 200OK 一口/2.0/TCP user1pc.domain.com; ブランチはz9hG4bK776sgdkseと等しいです。 容認された=1.2.3.4From: 一口: user1@domain.com;; タグ=49394To: 一口: user2@domain.com;tag はab8asdasd9 Call-IDと等しいです: asd88asd77a@1.2.3.4 CSeq: 1 メッセージコンテンツの長さ: 0
11. Security Considerations
11. セキュリティ問題
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要求を支持するUAsは終わりから終わりへの認証、ボディー保全、およびボディー秘密性メカニズムを実行しなければなりません。
11.1 Outbound Authentication
11.1 外国行きの認証
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.
地元のプロキシが外国行きのメッセージの伝達に使用されるとき、RFC3261で指定されるプロキシ認証はRECOMMENDEDです。 これは、創始者のアイデンティティについて確かめて、由来しているネットワークにだまして、ばらまくのを防ぐために役に立ちます。
Campbell, et. al. Standards Track [Page 13] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[13ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
11.2 SIPS URIs
11.2はURIをちびちび飲みます。
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に関する知識なしで追加終点に届けられるというMESSAGE要求を許します。 ホップごとの保護だけが使用されているなら、ユーザは、チェーンのすべてのプロキシが権限のない目的地に要求を分岐させないと信じなければなりません。
11.3 End-to-End Protection
11.3 終わりから終わりへの保護
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ボディーを安全にしなければなりません。 これからMESSAGE方法で運ばれるために指定されたボディーが終わりから終わりへのセキュリティを提供する異なった手段を持っているなら、それらの仕様は用法を説明しなければなりません。 SIP MESSAGE終点は暗号化(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アルゴリズムはRFC3369[4]によって設定されます。 AES[10]アルゴリズムは好まれるべきです、AESが多くのプラットホームの能力に最もよく合うと予想されるとき。しかしながら、これのためのIETF仕様はこの書くことの時現在、まだ不完全です。
11.4 Replay Prevention
11.4 再生防止
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要求の再生を防ぐために、すべてがMESSAGE要求にサインしました、そして、応答はメッセージ署名でカバーされたDateヘッダーフィールドを含まなければなりません。 未来に過去の数分かそれともどちらが数分より多いかより日付で古いどんなメッセージ、応答を送らないで、そのようなメッセージが同じソースから繰り返して到着しないならSHOULDが400(不正確なDateかTime)メッセージで答えられて、その場合、それらは捨てられるかもしれません。 明らかに、この反射攻撃防止メカニズムは装置のために時計なしで動作しません。
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.
状況が聞き古したDateヘッダーフィールドが正常であるところにあることに注意してください。 例えば、受取人がオフラインであった間、MESSAGE要求は店と前進のサーバに格納されているかもしれません。 受取人が戻ると、そのサーバはメッセージを転送するかもしれません。 そして、元々それを送った後にメッセージの最終的な領収書はいつか、現れるでしょう。
Campbell, et. al. Standards Track [Page 14] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[14ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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 MAYはメッセージを受け入れますが、SHOULDは、メッセージが再演されたというリスクがあるとユーザに警告します。
11.5 Using message/cpim Bodies
11.5 メッセージ/cpim Bodiesを使用すること。
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ボディーはメッセージ/cpim Fromヘッダーフィールドを使用することで送付者に認証を備えることができます、メッセージがSIPヘッダーフィールドを理解していない別のCPIM対応することのインスタントメッセージサービスへのゲートウェイを越えても。
12. IANA Considerations
12. IANA問題
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]
メッセージ[RFC3428]
13. Contributors
13. 貢献者
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
14. Acknowledgments
14. 承認
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ビリービッグズ大学
Campbell, et. al. Standards Track [Page 15] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[15ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
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マウリシオArango太陽リチャードショッキーNeuStarヨルゲンBjorker HotsipヘンリーSinnreich MCI Worldcomロナルドエイカーズモトローラトーリーサール藍のソフトウェアRohanマーイシスコのクリスチャンの木立エリクソンアリソンマンキンISIが日焼けする、あなた、-、チン、ジーメンス
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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[2] 日、M.とAggarwalとS.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、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.菅野、「存在とインスタントメッセージングのためのモデル」、RFC2778、2000年2月。
[4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
August 2002.
[4]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3369、2002年8月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[6] Bradner, S., "Keywords for Use in RFC's to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「使用のための要件レベルを示すRFCのところのキーワード」、BCP14、RFC2119、1997年3月。
16. Informational References
16. 情報の参照
[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は進行中で働いています。
[10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm
and RSA-OAEP Key Transport in CMS", Work in Progress.
[10] 「cmにおけるAES暗号化アルゴリズムとRSA-OAEPの主要な輸送の使用」というSchaad、J.、およびR.Housleyは進行中で働いています。
Campbell, et. al. Standards Track [Page 16] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[16ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
[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 Winterコンファレンス(ダラス(テキサス))(1988年2月)における[11]DellaFera、C.、Eichin、M.、フランス人、R.、Jedlinski、D.、コール、J.、およびW.ゾンマーフェルト、「Zephyr通知サービス」。
17. Authors' Addresses
17. 作者のアドレス
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
プラノ、ベンキャンベルdynamicsoft5100テニソンパークウェイSuite1200テキサス 75024
EMail: bcampbell@dynamicsoft.com
メール: bcampbell@dynamicsoft.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デヴィッドGurleマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: dgurle@microsoft.com
メール: dgurle@microsoft.com
Campbell, et. al. Standards Track [Page 17] RFC 3428 SIP Message Extension December 2002
etキャンベル、アル。 標準化過程[17ページ]RFC3428はメッセージ拡大2002年12月にちびちび飲みます。
18. Full Copyright Statement
18. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Campbell, et. al. Standards Track [Page 18]
etキャンベル、アル。 標準化過程[18ページ]
一覧
スポンサーリンク
