idnits 2.17.1 draft-ietf-speermint-consolidated-presence-im-usecases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-ietf-speermint-consolidated-presence-im-usecases', is 54 characters long, but may be at most 50 characters Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 9, 2007) is 6195 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-06 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT WG A. Houri 3 Internet-Draft IBM 4 Intended status: Standards Track E. Aoki 5 Expires: November 10, 2007 AOL LLC 6 S. Parameswar 7 Microsoft Corporation 8 May 9, 2007 10 Presence & IM Use Cases 11 draft-ietf-speermint-consolidated-presence-im-usecases-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 10, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The document describes several use cases of peering between two or 45 more service providers that provide none VOIP based collaboration 46 services and presence and IM in particular. These service providers 47 create a peering relationship between themselves thus enabling their 48 users to collaborate with users on other communities. The target of 49 the document is to drive requirements for peering between domains 50 that provide the none VOIP based collaboration services. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Simple Interdomain Subscription . . . . . . . . . . . . . 5 58 3.2. List Interdomain Subscription . . . . . . . . . . . . . . 5 59 3.3. Authorization Migration . . . . . . . . . . . . . . . . . 5 60 3.4. Page mode IM . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.5. Session based IM . . . . . . . . . . . . . . . . . . . . . 6 62 3.6. Other services . . . . . . . . . . . . . . . . . . . . . . 6 63 3.7. Federation . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Intellectual Property and Copyright Statements . . . . . . . . . . 12 72 1. Requirements notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [1]. 78 2. Introduction 80 Real Time Collaboration (RTC) services are becoming as prevalent and 81 essential for users on the Internet as email. While RTC services 82 can, like email, be implemented directly by users in a point-to-point 83 fashion, they are often provided for or on behalf of a community of 84 users within an administrative domain. As the use of these services 85 grows, users increasingly have the need to communicate with users not 86 only within their own community but with those in other communities 87 as well. In practice, each community is controlled by some 88 authority, and so there is a need to provide for easier establishment 89 of connectivity between communities, and the management of the inter- 90 community link. This document contains a set of use cases that 91 describe how peering between communities may be used in none VOIP RTC 92 services. The use cases are intended to help in creating 93 requirements that will enable more secure and easier peering between 94 communities that provide none VOIP RTC services. 96 This document will use the terminology as defined in [2] unless 97 otherwise is stated. 99 The following sections provide several use cases followed by a 100 discussion on what these use cases may imply regarding the 101 functionalities that need to be provided for in order to implement 102 those use cases 104 3. Use Cases 106 3.1. Simple Interdomain Subscription 108 Assume that we have two peer networks [2], peer network A and peer 109 network B. User Alice@A.com wants to subscribe to user Bob@B.com and 110 get his presence information. In order to do so, Alice@A.com may 111 connect directly to B.com and subscribe to Bob's presence 112 information. However, peer network B is not willing to support 113 subscriptions from any user in the network and is willing only to 114 support its users and users that are coming from other peer networks 115 that peer network B trusts. 117 In reality what will happen is that peer network A will connect to 118 peer network B and will send Alice's subscription on Bob to peer 119 network B. When peer network B has new information on Bob it will 120 send notifications to peer network A that will pass them to Alice. 122 3.2. List Interdomain Subscription 124 This is the same as the simple interdomain subscription use case but 125 in this case Alice subscribes to a URI that represents a list of 126 users in peer network B [3] 128 There are two sub use cases here. One use case is when the list that 129 Alice subscribes to is a list that is configured by e.g. the 130 administrator and it is used to host the names of a group of specifc 131 people e.g. the support group of a company. The other usage is a 132 private group of Alice's friends and the reason that Alice will be 133 using the list instead of doing separate subscriptions is to save on 134 the number of the SUBSCRIBE sessions. 136 3.3. Authorization Migration 138 if many users from one peering network watch presentities in another 139 peering network, it may be possible that many watchers from one 140 peering network will subscribe to the same user in the peering 141 network. However, due to privacy constraints, each peering network 142 will have to send multiple copies of the watched presence document. 143 The privacy constraints enable a user to provide different persence 144 document to e.g. friends, co-workers etc. The need to send multiple 145 copies between the peering networks is very inefficient and causes 146 redundant traffic between the peering networks. 148 In order to make the subscription between peering networks more 149 efficient there needs to be a way to enable peering networks to agree 150 to share privacy information between them. This will enabble sending 151 a single copy (the full copy) of the presence document of of the 152 watched user and letting the receiving peering network to be 153 responsible to send the right values to the right watchers according 154 to the privacy definitions of the watched user that were delegated to 155 it from the peering network where the watched user resides. 157 Instead of sharin privacy between the communities, it is also 158 possible to send different copies of the presence document with a 159 list of the watchers that the presence document is intended to. For 160 exeample, if there is a set of watchers in the other community that 161 may see the location of the presentity and another set of users in 162 the other community that may not see the location informaiton, two 163 presence documents will be sent, each one associaed with a list of 164 users that should get it. One presence doucment will contain the 165 location infomrmation and will be associated with a list of users 166 that may see it and the otehr presence document will not contain the 167 location information and will be associated with a list of users that 168 may not see the location information. 170 3.4. Page mode IM 172 In this use case a user from one peer network sends a page mode [4] 173 IM to a user on another peer network. As with subscription, the 174 message will pass between the users through the SBEs [2] of the peer 175 networks. 177 3.5. Session based IM 179 In this use case a user from one peer network creates an MSRP [5] 180 session with a user from another peer network. The session 181 establishment and the messages will pass between the users through 182 the SBEs [2] of the peer networks. 184 3.6. Other services 186 In addition to VOIP sessions which are out of scope for this document 187 only presence and IM are more or less fully standardized. However 188 there are many other services that are being standardized or may be 189 implemented using minimal extensions to existing standards. These 190 include: 192 o N-way chat - Enable a multi participant chat that will include 193 users from many peer networks. 195 o File transfer - Send files from a user in one peer network to a 196 user in another peer network. 198 o Document sharing - Sharing and editing a document between users in 199 different peer networks. Note that document sharing is included 200 in this document more 202 There are many more collaboration services that can be thought about. 203 Enabling peering between networks for some of the services will 204 create a basis for defining many more services 206 3.7. Federation 208 Federation as defined in [2] is a use case also in real time 209 collaboration. 211 The none VOIP collaboration features as presence, IM and chat rooms 212 may benefit even more then VOIP services from federation. 213 Collaboration by its definition is something that is stronger where 214 there many more parties collaborating and federation is certainly a 215 good way to achieve greater collaboration. 217 Additional "side" services as security, lawful interception, logging 218 and more may be provided to the peer networks that are members of the 219 federation. 221 Note that federation is also known as clearing house in the real time 222 collaboration industry. 224 4. Security Considerations 226 This document discusses use cases for peering between communities. 227 It is very clear that the protocols that will enable and make such 228 peering easier will have significant security considerations, there 229 are out of scope for a use case document. 231 5. Acknowledgments 233 We would like to thank Jonathan Rosenberg and Roahn Mahy for their 234 input. 236 6. References 238 6.1. Normative References 240 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 241 Levels", BCP 14, RFC 2119, March 1997. 243 6.2. Informative References 245 [2] Meyer, D., "SPEERMINT Terminology", 246 draft-ietf-speermint-terminology-06 (work in progress), 247 September 2006. 249 [3] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation 250 Protocol (SIP) Event Notification Extension for Resource Lists", 251 RFC 4662, August 2006. 253 [4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 254 D. Gurle, "Session Initiation Protocol (SIP) Extension for 255 Instant Messaging", RFC 3428, December 2002. 257 [5] Campbell, B., "The Message Session Relay Protocol", 258 draft-ietf-simple-message-sessions-19 (work in progress), 259 February 2007. 261 Authors' Addresses 263 Avshalom Houri 264 IBM 265 Science Park Building 18/D 266 Rehovot, 267 Israel 269 Email: avshalom@il.ibm.com 271 Edwin Aoki 272 AOL LLC 273 360 W. Caribbean Drive 274 Sunnyvale, CA 94089 275 USA 277 Email: aoki@aol.net 279 Sriram Parameswar 280 Microsoft Corporation 281 One Microsoft Way 282 Redmond, WA 98052 283 USA 285 Email: Sriram.Parameswar@microsoft.com 287 Full Copyright Statement 289 Copyright (C) The IETF Trust (2007). 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 298 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 299 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 300 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Intellectual Property 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org. 327 Acknowledgment 329 Funding for the RFC Editor function is provided by the IETF 330 Administrative Support Activity (IASA).