RFC5344 日本語訳

Network Working Group                                           A. Houri
Request for Comments: 5344                                           IBM
Category: Informational                                          E. Aoki
                                                                 AOL LLC
                                                           S. Parameswar
                                                  Microsoft  Corporation
                                                            October 2008

コメントを求めるワーキンググループA.天女要求をネットワークでつないでください: 5344年のIBMカテゴリ: 情報のE.の青木AOL LLC S.Parameswarマイクロソフト社2008年10月

            Presence and Instant Messaging Peering Use Cases

存在とインスタントメッセージングのじっと見るのはケースを使用します。

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document describes several use cases of peering of non-VoIP
   (Voice over IP) services between two or more Service Providers.
   These Service Providers create a peering relationship between
   themselves, thus enabling their users to collaborate with users on
   the other Service Provider network.  The target of this document is
   to drive requirements for peering between domains that provide the
   non-VoIP based collaboration services with presence and, in
   particular, Instant Messaging (IM).

このドキュメントは非VoIP(ボイス・オーバー IP)をじっと見るケースが2Service Providersの間で修理する数個の使用について説明します。 これらのService Providersは自分たちの間のじっと見る関係を作成します、その結果、彼らのユーザがもう片方のService Providerネットワークにユーザと協力するのを可能にします。 このドキュメントの目標は存在と特にInstant Messaging(IM)を非VoIPのベースの共同サービスに提供するドメインの間をじっと見るための要件を追い立てることです。

   Table of Contents

目次

   1. Introduction ....................................................2
   2. Use Cases .......................................................2
      2.1. Simple Interdomain Subscription ............................2
      2.2. List Based Interdomain Subscription ........................3
      2.3. Authorization Migration ....................................3
      2.4. Pager Mode IM ..............................................4
      2.5. Session Based IM ...........................................4
      2.6. Other Services .............................................4
      2.7. Federation and Clearing House ..............................5
   3. Security Considerations .........................................5
   4. Acknowledgments .................................................6
   5. Informative References ..........................................6

1. 序論…2 2. ケースを使用してください…2 2.1. 簡単なInterdomain購読…2 2.2. ベースのInterdomain購読を記載してください…3 2.3. 承認移行…3 2.4. ポケットベルモード、不-、…4 2.5. セッションを基づかせた、不-、…4 2.6. 他のサービス…4 2.7. 連邦とクリアリングハウス…5 3. セキュリティ問題…5 4. 承認…6 5. 有益な参照…6

Houri, et al.                Informational                      [Page 1]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[1ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

1.  Introduction

1. 序論

   This document uses the terminology as defined in [1] unless otherwise
   stated.

このドキュメントは別の方法で述べられない場合[1]で定義されるように用語を使用します。

   Real Time Collaboration (RTC) services have become as prevalent and
   essential for users on the Internet as email.  While RTC services can
   be implemented directly by users in a point-to-point fashion, they
   are often provided for, or on behalf of, a Peer Network of users
   within an administrative domain.  As the use of these services grows,
   users increasingly have the need to communicate with users not only
   within their own Peer Network but with those in other Peer Networks
   as well (similar to the old Public Switched Telephony Network (PSTN)
   that enabled global reachability).  In practice, each Peer Network is
   controlled by some domain, and so there is a need to provide for
   easier establishment of connectivity between Peer Networks and for
   the management of the relationships between the Peer Networks.  This
   document describes a set of use cases that describe how peering
   between Peer Networks may be used in non-VoIP RTC services.  The use
   cases are intended to help in identifying and capturing requirements
   that will guide and then enable a secure and easier peering between
   Peer Networks that provide non-VoIP RTC services.  The use cases for
   the VoIP RTC services are described in [2].

本当のTime Collaboration(RTC)サービスはインターネットでユーザにとってメールと同じくらい一般的で同じくらい不可欠になりました。 直接ユーザは二地点間ファッションでRTCサービスを実装することができますが、Peer Networkか管理ドメインの中のユーザのPeer Networkしばしば彼らを提供します。 これらのサービスの使用が成長するとき、ユーザはますますまた(グローバルな可到達性を可能にした古いPublic Switched Telephony Network(PSTN)と同様の)、他のPeer Networksにそれら自身のPeer Networkだけでコミュニケートするのではなく、それらでもユーザとコミュニケートする必要性を持っています。 実際には、各Peer Networkが何らかのドメインによって制御されるので、そして、Peer Networksの間と、そして、Peer Networksの間の関係の管理ように接続性の、より簡単な確立に備える必要があります。 このドキュメントは中古のコネが非VoIP RTCサービスであったならPeer Networksの間をじっと見ながらその方法を説明するケースが説明する使用のセットについて説明します。 要件がそれであると特定して、キャプチャする際に助けるケースが意図する使用は、非VoIP RTCサービスを提供するPeer Networksの間の安全でより簡単なじっと見ることを誘導して、次に、可能にするでしょう。 VoIP RTCのためのケースが修理する使用は[2]で説明されます。

   Note that this document does not define requirements for a new
   protocol or for protocol extensions.  It captures the way that
   presence and Instant Messaging are currently used within enterprises
   and operator domains.

このドキュメントが新しいプロトコルかプロトコル拡大のための要件を定義しないことに注意してください。 それは存在とInstant Messagingが現在企業とオペレータドメインの中で使用される方法を得ます。

2.  Use Cases

2. ケースを使用してください。

2.1.  Simple Interdomain Subscription

2.1. 簡単なInterdomain購読

   Assume two Peer Networks, Peer Network A and Peer Network B.  User
   Alice@example.com (hosted in Peer Network A) wants to subscribe to
   user Bob@example.net (hosted in Peer Network B) and get his presence
   information.  In order to do so, Alice@example.com could connect
   directly to example.net and subscribe to Bob's presence information.
   However, Peer Network B is willing to accept subscriptions and route
   IMs only when they are coming from its users or from other Peer
   Networks that Peer Network B trusts.

Peer Network B.User Alice@example.com (Peer Network Aでは、接待される)は2Peer Networks、Peer Network Aを仮定して、ユーザ Bob@example.net (Peer Network Bでは、接待される)に加入し、彼の存在情報を得たがっています。 そうするために、 Alice@example.com は直接example.netに接続して、ボブの存在情報に加入できました。 しかしながら、Peer Network Bは、彼らがユーザ、または、Peer Network Bが信じる他のPeer Networksから来る予定であるときだけ、購読とルートIMsを受け入れても構わないと思っています。

   In reality, what will happen is Peer Network A will connect to Peer
   Network B and send Alice's subscription to Bob via Peer Network B.
   When Peer Network B has new information on Bob, it will send
   notifications to Peer Network A, which will pass them to Alice.

起こることはほんとうは、AがPeer Network B.When Peer Network Bを通してPeer Network Bに接続して、ボブのアリスの購読を送るPeer Networkがボブの新情報を持って、Peer Network Aに通告を送るということです。(Peer Network Aはそれらをアリスに渡すでしょう)。

Houri, et al.                Informational                      [Page 2]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[2ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

2.2.  List-Based Interdomain Subscription

2.2. リストベースのInterdomain購読

   This is similar to the simple interdomain subscription use case,
   except in this case Alice subscribes to a Uniform Resource Identifier
   (URI) [8] that represents a list of users in Peer Network B [9] [3].

これは、購読使用がケースに入れる簡単なinterdomainと同様であり、この場合アリスを除いて、Peer Network B[9][3]にユーザーズ・リストを表すUniform Resource Identifier(URI)[8]に加入します。

   There are several types of lists that Alice may subscribe to:

アリスが加入するかもしれないいくつかのタイプのリストがあります:

   o  Personal group - a list that is created and maintained by Alice
      and includes Alice's watch list.

o 個人的なグループ--アリスによって作成されて、維持されて、アリスの警戒リストを含んでいるリスト。

   o  Public group - a list that is created and maintained by an
      administrator.  Public groups usually contain a list of specific
      people that have some common characteristic, e.g., support group
      of a company.

o 公衆は分類します--管理者によって作成されて、維持されるリスト。 通常、公立のグループは何らかの共通する特徴を持っている特定の人々、例えば、会社のサポートグループのリストを含みます。

   o  Ad-hoc group - a list that is short lived and is usually created
      in the context of some activity that Alice is doing.  An ad-hoc
      group may be created by Alice or by some application.  Typical
      examples may be the list of people that participate with Alice in
      a conference or a game.

o 専門家班--短いリストは、生きていて、通常、アリスがしている何らかの活動の文脈で作成されます。 専門家班はアリスか何らかのアプリケーションで創設されるかもしれません。 典型的な例は、アリスと共に会議に参加する人々のリストかゲームであるかもしれません。

2.3.  Authorization Migration

2.3. 承認移行

      If many users from one Peer Network watch presentities [6] in
      another Peer Network, it may be possible that many watchers [6]
      from one Peer Network will subscribe to the same user in the other
      Peer Network.  However, due to privacy constraints that enable a
      user to provide different presence documents to different
      watchers, each Peer Network will have to send multiple copies of
      the watched-presence document.  The need to send multiple copies
      between the Peer Networks is very inefficient and causes redundant
      traffic between the Peer Networks.

1Peer Networkからの多くのユーザが別のPeer Networkでpresentities[6]を見るなら、1Peer Networkからの多くのウォッチャー[6]がもう片方のPeer Networkで同じユーザに加入するのは、可能であるかもしれません。 しかしながら、ユーザが異なった存在ドキュメントを異なったウォッチャーに提供するのを可能にするプライバシー規制のため、各Peer Networkは見られた存在ドキュメントの複本を送らなければならないでしょう。 Peer Networksの間に複本を送る必要性は、非常に効率が悪く、Peer Networksの間の余分なトラフィックを引き起こします。

      In order to make the subscription between Peer Networks more
      efficient there needs to be a way to enable Peer Networks to agree
      to share privacy information between them.  This will enable
      sending a single copy (the full copy) of the presence document of
      the watched user and letting the receiving Peer Network be
      responsible for sending the right values to the right watchers
      according to the delegated privacy policies of the watched users.

Peer Networksの間の購読をより効率的にするように、Peer Networksが、彼らの間のプライバシー情報を共有するのに同意するのを可能にする方法があるのが必要です。 見られたユーザの存在ドキュメントのただ一つのコピー(完全なコピー)を送って、受信Peer Networkは見られたユーザの代表として派遣されたプライバシーに関する方針に応じて正しい値を正しいウォッチャーに送るのに責任があらせながら、これが可能にされるでしょう。

      Instead of sharing the watched user's privacy policies between the
      Peer Networks, it is also possible to send different copies of the
      presence document with a list of the watchers the presence
      document is intended for.  For example, if there is a set of
      watchers in one Peer Network that may see the location of the
      presentity and another set of users in the same Peer Network that

また、Peer Networksの間の見られたユーザのプライバシーに関する方針を共有することの代わりに、存在ドキュメントが意図するウォッチャーのリストがある存在ドキュメントの異なったコピーを送るのも可能です。 例えば、1セットのウォッチャーが1Peer Networkにいればそれが同じPeer Networkのpresentityともう1セットのユーザの位置を見るかもしれない、それ

Houri, et al.                Informational                      [Page 3]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[3ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

      may not see the location information, two presence documents will
      be sent--each associated with a list of watchers that should
      receive it.  One presence document will contain the location
      information and will be associated with a list of users that may
      see it, and the other presence document will not contain the
      location information and will be associated with a list of users
      that may not see the location information. See [11].

位置情報を見ないかもしれません、存在が送られると記録する2--それを受けるはずであるウォッチャーのリストに関連づけられたそれぞれ。 1通の存在ドキュメントが位置情報を含んで、それを見るかもしれないユーザのリストに関連して、もう片方の存在ドキュメントは、位置情報を含まないで、位置情報を見ないかもしれないユーザのリストに関連するでしょう。 [11]を見てください。

2.4.  Pager Mode IM

2.4. ポケットベルモード、不-

      In this use case, a user from one Peer Network sends a pager mode
      [7] IM to a user on another Peer Network.

この使用がケースに入れるコネ、あるPeer Networkからのユーザは別のPeer Networkで[7] aポケットベルモードIMをユーザに送ります。

2.5.  Session Based IM

2.5. セッションを基づかせた、不-

      In this use case, a user from one Peer Network creates a Message
      Session Relay Protocol (MSRP) [10] session with a user from
      another Peer Network.

この使用がケースに入れるコネ、あるPeer Networkからのユーザは別のPeer NetworkからユーザとのMessage Session Relayプロトコル(MSRP)[10]セッションを作成します。

2.6.  Other Services

2.6. 他のサービス

      In addition to VoIP sessions, which are out of scope for this
      document, only presence and IM have been ratified as RFCs.  In
      addition to presence and IM, there are many other services that
      are being standardized or that may be implemented using minimal
      extensions to existing standards.  These include:

VoIPセッションに加えて、存在とIMだけがRFCsとして批准されました。このドキュメントのための範囲の外にセッションがあります。 存在とIMに加えて、標準化されているか、または既存の規格に最小量の拡張子を使用することで実装されるかもしれない他の多くのサービスがあります。 これらは:

   o  N-way chat - enable a multi-participant textual chat that will
      include users from multiple Peer Networks.  See [4] for more
      details.

o N-道のチャット--複数のPeer Networksからユーザを含んでいるマルチ関係者の原文のチャットを可能にしてください。 その他の詳細のための[4]を見てください。

   o  File transfer - send files from a user in one Peer Network to a
      user in another Peer Network.  See [5] for more details.

o ファイル転送--1Peer Networkのユーザから別のPeer Networkのユーザにファイルを送ってください。 その他の詳細のための[5]を見てください。

   o  Document sharing - sharing and editing a document between users in
      different Peer Networks.

o 共有を記録してください--異なったPeer Networksのユーザの間のドキュメントを共有して、編集すること。

      Note: Document sharing is mentioned in this document only for
      completeness of use cases.  It is not being standardized by the
      IETF and will not be included in the requirements document that
      will result from this document.

以下に注意してください。 ドキュメント共有は完全性だけにおいて、役に立つこのドキュメントがケースに入れる言及されたコネです。 それは、IETFによって標準化されないで、またこのドキュメントから生じる要件ドキュメントに含まれないでしょう。

   The list above is of course not exhaustive, as new developments in
   the world of non-VoIP RTC will surface new services.  Enabling
   peering between networks for some of the services will create a basis
   for enabling peering for future services also.

上記のリストはもちろん徹底的ではありません、非VoIP RTCの世界での新しい開発が新種業務の表面を仕上げるとき。 サービスのいくつかのためにネットワークの間のじっと見ることを可能にすると、今後のサービスのためのじっと見ることを可能にする基礎も作成されるでしょう。

Houri, et al.                Informational                      [Page 4]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[4ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

2.7.  Federation and Clearing House

2.7. 連邦とクリアリングハウス

   A federation as defined in [1] enables peering between multiple Peer
   Networks.  A federation may be implemented by means of a central
   service providing a hub for the Peer Networks or, alternatively, Peer
   Networks may connect to each other in a peer-to-peer fashion.  One of
   the most important services that this hub type of federation should
   provide is authorized interconnection that enables each Peering
   Network to securely identify other Peering Networks.  Other services
   that might be provided include an N-way chat server, lawful
   interception, logging, and more.  This hub type of federation is also
   known as a "Clearing House".

[1]で定義される連邦は複数のPeer Networksの間のじっと見ることを可能にします。 連邦がハブをPeer Networksに供給する主要なサービスによって実装されるかもしれませんか、またはあるいはまた、Peer Networksはピアツーピアファッションで互いに接するかもしれません。 このハブタイプの連邦が提供するべきである中で最も重要なサービスの1つは各Peering Networkがしっかりと他のPeering Networksを特定するのを可能にする認可されたインタコネクトです。 提供されるかもしれない他のサービスはN-道のチャットサーバ、合法的な妨害、伐採、およびその他を含んでいます。 また、このハブタイプの連邦は「クリアリングハウス」として知られています。

   As non-VoIP services are usually text-based and consume less
   bandwidth, they may benefit from having a central service that will
   do central services such as logging for them.  For example, instead
   of requiring each Peer Network to log all messages that are being
   sent to the other Peer-Network, this service can be done by the
   Clearing House.

非VoIPサービスが通常、テキストベースであり、より少ない帯域幅を消費するのに従って、それらはそれらのための伐採などの主要なサービスをする主要なサービスを持つのから利益を得るかもしれません。 例えば、各Peer Networkがもう片方のPeer-ネットワークに送られるすべてのメッセージを登録するのが必要であることの代わりに、Clearing家はこのサービスができます。

3.  Security Considerations

3. セキュリティ問題

   When Peer Network A peers with Peer Network B, there are several
   security issues for which the administrator of each Peer Network will
   need mechanisms to verify:

Peer Network AがPeer Network Bと共にじっと見るとき、それぞれのPeer Networkの管理者が確かめるメカニズムを必要とするいくつかの安全保障問題があります:

   o  All communication channels between Peer Networks and between each
      Peer Network and the Clearing House have their authenticity and
      confidentiality protected.

o Peer Networksと各Peer NetworkとClearing家の間のすべての通信チャネルで、彼らの信憑性と秘密性を保護します。

   o  The other Peer Network is really the Peering Network that it
      claims to be.

o もう片方のPeer Networkは本当にそれが主張するPeering Networkです。

   o  The other Peer Network is secure and trustworthy, such that
      information that is passed to it will not reach a third party.
      This includes information about specific users as well as
      information about the authorization policies associated with user
      information.

o もう片方のPeer Networkは安全であって、信頼できます、それに通過される情報が第三者に届かないように。 これはユーザー情報に関連している承認方針の情報と同様に特定のユーザの情報を含んでいます。

   o  The other Peer Network is secure and trustworthy, such that it
      will not modify or falsify data that it presents to its users
      except as required by the authorization policy provided.

o もう片方のPeer Networkは安全であって、信頼できます、必要に応じて承認方針で提供しているのを除いて、ユーザに提示するデータを変更もしませんし、改竄もしないように。

   o  If there is a third party (e.g., a Clearing House) involved in the
      connection between the two Peering Networks that element is also
      secure.

o また、2Peering Networksの間の接続にかかわる第三者(例えば、Clearing家)がいれば、その要素も安全です。

Houri, et al.                Informational                      [Page 5]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[5ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

   The same issues of security are even more important from the point of
   view of the users of the Peer Networks.  Users will be concerned
   about how their privacy is being adhered to when their presence
   information is sent to the other Peer Network.  Users today are
   concerned about providing their email address to a third party when
   they register to a domain; presence contains much more sensitive
   information, and the concern of users here will be even greater.

セキュリティの同じ問題はPeer Networksのユーザの観点からさらに重要です。 ユーザは彼らの存在情報をもう片方のPeer Networkに送るとき、どう彼らのプライバシーを固く守るかに関して心配するでしょう。 今日のユーザは彼らがドメインに登録するとき彼らのEメールアドレスを第三者に提供することに関して心配しています。 存在はずっと多くの機密情報を含んでいます、そして、ここのユーザの関心はさらに大きくなるでしょう。

   The privacy issue is even harder when we take into account that, in
   order to enable scalable peering between big Peer Networks, there are
   some optimizations that may require migration of the privacy
   definitions of users between Peer Network (see Section 2.3).  We can
   imagine the fiasco that would ensue if a user of one Peer Network
   were able to see the privacy information and learn he/she is listed
   in the block list of a close friend.

私たちが、Peer Networkの間には、ユーザのプライバシー定義の移行を必要とするかもしれないいくつかの最適化が大きいPeer Networksの間のスケーラブルなじっと見ることを可能にするためにあるのを考慮に入れるとき(セクション2.3を見てください)、プライバシーの問題はさらに困難です。 私たちは、1Peer Networkのユーザがプライバシー情報を見ることができるなら続く大失敗を想像して、その人が親友のブロックリストに記載されていることを学ぶことができます。

   This document discusses use cases for peering between Peer Networks.
   It is out of the scope of this document to provide solutions for
   security.  Nevertheless, it is obvious that the protocols that will
   enable the use cases described here will have to provide for the
   security considerations also described here.

このドキュメントは使用について議論します。Peer Networksの間をじっと見るためのケース。 解決法をセキュリティに提供するために、このドキュメントの範囲の外にそれはあります。 それにもかかわらず、ケースがここで説明した使用を可能にするプロトコルがまた、ここで説明されたセキュリティ問題に備えなければならないのは、明白です。

4.  Acknowledgments

4. 承認

   We would like to thank Jonathan Rosenberg, Jon Peterson, Rohan Mahy,
   Jason Livingood, Alexander Mayrhofer, Joseph Salowey, Henry
   Sinnreich, and Mohamed Boucadir for their valuable input.

彼らの貴重な入力についてジョナサン・ローゼンバーグ、ジョン・ピーターソン、Rohanマーイ、ジェイソンLivingood、アレクサンダー・マイルホーファー、ジョゼフSalowey、ヘンリーSinnreich、およびモハメドBoucadirに感謝申し上げます。

5.  Informative References

5. 有益な参照

   [1]   Malas, D. and D. Meyer, "SPEERMINT Terminology", Work in
         Progress, February 2008.

[1] 「SPEERMINT用語」というマラス、D.、およびD.マイヤーは進歩、2008年2月に働いています。

   [2]   Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Work in
         Progress, May 2008.

[2] 「VoIP一口のじっと見るのはケースを使用する」というUzelac、A.、およびY.リーは進歩、2008年5月に働いています。

   [3]   Camarillo, G. and A. Roach, "Framework and Security
         Considerations for Session Initiation Protocol (SIP) URI-List
         Services", Work in Progress, November 2007.

[3] 「セッション開始プロトコル(一口)URIリストサービスのためのフレームワークとセキュリティ問題」というキャマリロ、G.、およびA.ローチは進行中(2007年11月)で働いています。

   [4]   Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party
         Instant Message (IM) Sessions Using the Message Session Relay
         Protocol (MSRP)", Work in Progress, February 2008.

[4]Niemi、A.、ガルシア-マーチン、M.、およびG.Sandbakken、「マルチパーティインスタントメッセージ、(不-、)、メッセージセッションを使用するセッションがプロトコル(MSRP)をリレーする、」、進行中(2008年2月)では、働いてください。

   [5]   Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and
         P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer
         Mechanism to Enable File Transfer", Work in Progress, May 2008.

[5] ガルシア-マーチン、M.、M.、キャマリロ、G.、ロレト、S.、およびP.Kyzivat、「ファイル転送を可能にするセッション記述プロトコル(SDP)申し出/答えメカニズム」というIsomakiは進行中(2008年5月)で働いています。

Houri, et al.                Informational                      [Page 6]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[6ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

   [6]   Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.

2000年2月の[6] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。

   [7]   Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C.,
         and D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

[7] キャンベル、B.(エド)、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」RFC3428(2002年12月)。

   [8]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。

   [9]   Roach, A., Campbell, B., and J. Rosenberg, "A Session
         Initiation Protocol (SIP) Event Notification Extension for
         Resource Lists", RFC 4662, August 2006.

[9] ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、「リソースのためのセッション開始プロトコル(一口)イベント通知拡張子は記載します」、RFC4662、2006年8月。

   [10]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
         Message Session Relay Protocol (MSRP)", RFC 4975, September
         2007.

[10] キャンベル、B.(エド)、マーイ、R.(エド)、およびC.ジョニングス(エド)、「メッセージセッションはプロトコル(MSRP)をリレーします」、RFC4975、2007年9月。

   [11]  Rosenberg, J., Donovan, S., and K. McMurry. "Optimizing
         Federated Presence with View Sharing", Work in Progress, July
         2008.

[11] ローゼンバーグ、J.、ドノヴァン、S.、およびK.マクマーリ。 「視点共有で連邦化された存在を最適化し」て、進歩、2008年7月に働いてください。

Houri, et al.                Informational                      [Page 7]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[7ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

Authors' Addresses

作者のアドレス

   Avshalom Houri
   IBM
   3 Pekris Street
   Science Park
   Rehovot,
   Israel

Avshalom天女IBM3Pekris通りサイエンスパークレホボト(イスラエル)

   EMail: avshalom@il.ibm.com

メール: avshalom@il.ibm.com

   Edwin Aoki
   AOL LLC
   401 Ellis Street
   Mountain View, CA 94043
   USA

エドウィン青木AOL LLC401エリス・通りカリフォルニア94043マウンテンビュー(米国)

   EMail: aoki@aol.net

メール: aoki@aol.net

   Sriram Parameswar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

Sriram Parameswarマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)

   EMail: Sriram.Parameswar@microsoft.com

メール: Sriram.Parameswar@microsoft.com

Houri, et al.                Informational                      [Page 8]

RFC 5344           Presence and IM Peering Use Cases        October 2008

天女、他 情報[8ページ]のRFC5344存在と不-のじっと見るのは2008年10月にケースを使用します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Houri, et al.                Informational                      [Page 9]

天女、他 情報[9ページ]