idnits 2.17.1 draft-ietf-speermint-consolidated-presence-im-usecases-02.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 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 5, 2007) is 6133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 250, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-07 == Outdated reference: A later version (-19) exists of draft-ietf-speermint-voip-consolidated-usecases-02 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-06 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '6') (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: Informational E. Aoki 5 Expires: January 6, 2008 AOL LLC 6 S. Parameswar 7 Microsoft Corporation 8 July 5, 2007 10 Presence & Instant Messaging Peering Use Cases 11 draft-ietf-speermint-consolidated-presence-im-usecases-02.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 January 6, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The document describes several use cases of peering of non-VoIP 45 services between two or more Service Providers (SP). These Service 46 Providers create a peering relationship between themselves thus 47 enabling their users to collaborate with users on the other Service 48 Provider network. The target of the document is to drive 49 requirements for peering between domains that provide the non-VoIP 50 based collaboration services and presence and Instant Messaging (IM) 51 in particular. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Simple Interdomain Subscription . . . . . . . . . . . . . . 3 58 2.2. List Based Interdomain Subscription . . . . . . . . . . . . 3 59 2.3. Authorization Migration . . . . . . . . . . . . . . . . . . 4 60 2.4. Page Mode IM . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.5. Session Based IM . . . . . . . . . . . . . . . . . . . . . 5 62 2.6. Other Services . . . . . . . . . . . . . . . . . . . . . . 5 63 2.7. Federation & Clearing House . . . . . . . . . . . . . . . . 5 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 Intellectual Property and Copyright Statements . . . . . . . . . . 9 73 1. Introduction 75 The document uses the terminology as defined in [2] unless otherwise 76 stated. 78 Real Time Collaboration (RTC) services become as prevalent and 79 essential for users on the Internet as email. While RTC services can 80 be implemented directly by users in a point-to-point fashion, they 81 are often provided for or on behalf of a Peer Network of users within 82 an administrative domain. As the use of these services grows, users 83 increasingly have the need to communicate with users not only within 84 their own Peer Network but with those in other Peer Networks as well 85 (similar to the old PSTN that enabled global reachabilty). In 86 practice, each Peer Network is controlled by some domain, and so 87 there is a need to provide for easier establishment of connectivity 88 between Peer Networks, and the management of the relationships 89 between the Peer Networks. This document describes a set of use 90 cases that describe how peering between Peer Networks may be used in 91 non Voice over IP (VoIP) Real Time Collaboration (RTC) services. The 92 use cases are intended to help in identifying and capturing 93 requirements that will guide and then enable a secure and easier 94 peering between Peer Networks that provide non-VoIP RTC services. 95 The use cases for the VoIP RTC services are described in [3]. 97 2. Use Cases 99 2.1. Simple Interdomain Subscription 101 Assume two Peer Networks [2], peer network A and peer network B. User 102 Alice@example.com wants to subscribe to user Bob@.example.net and get 103 his presence information. In order to do so, Alice@ 104 domainA.example.com may connect directly to example.net and subscribe 105 to Bob's presence information. However, peer network B is not 106 willing to support subscriptions from any user in the network and is 107 willing only to support its users and users that are coming from 108 other peer networks that peer network B trusts. 110 In reality what will happen is that peer network A will connect to 111 peer network B and will send Alice's subscription on Bob to peer 112 network B. When peer network B has new information on Bob it will 113 send notifications to peer network A that will pass them to Alice. 115 2.2. List Based Interdomain Subscription 117 This is similar to the simple interdomain subscription use case 118 except in this case Alice subscribes to a Uniform Resource Identifier 119 (URI) [8] that represents a list of users in peer network B [9] [4] 120 There are two sub use cases here: 122 o The list that Alice subscribes to is a list that is configured by 123 the administrator and it is used to host the names of a group of 124 specific people, e.g. the support group of a company. 125 o A private group of Alice's friends and the reason that Alice will 126 be using the list instead of doing separate subscriptions is to 127 save on the number of SUBSCRIBE [6] sessions. 129 2.3. Authorization Migration 131 If many users from one Peer Network watch presentities [5] in another 132 Peer Network, it may be possible that many watchers [5] from one Peer 133 Network will subscribe to the same user in the other Peer Network. 134 However, due to privacy constraints, each Peer Network will have to 135 send multiple copies of the watched presence document. The privacy 136 constraints enable a user to provide different presence documents to 137 friends, co-workers etc. The need to send multiple copies between 138 the Peer Networks is very inefficient and causes redundant traffic 139 between the Peer Networks. 141 In order to make the subscription between Peer Networks more 142 efficient there needs to be a way to enable Peer Networks to agree to 143 share privacy information between them. This will enable sending a 144 single copy (the full copy) of the presence document of the watched 145 user and letting the receiving Peer Network to be responsible to send 146 the right values to the right watchers according to the privacy 147 definitions of the watched users who were delegated to it from the 148 Peer Network where the watched user resides. 150 Instead of sharing privacy between the Peer Networks, it is also 151 possible to send different copies of the presence document with a 152 list of the watchers that the presence document is intended to. For 153 example, if there is a set of watchers in the other Peer Network that 154 may see the location of the presentity and another set of users in 155 the other Peer Network that may not see the location information, two 156 presence documents will be sent, each one associated with a list of 157 users that should receive it. One presence document will contain the 158 location information and will be associated with a list of users that 159 may see it and the other presence document will not contain the 160 location information and will be associated with a list of users that 161 may not see the location information. 163 2.4. Page Mode IM 165 In this use case a user from one peer network sends a page mode [7] 166 IM to a user on another peer network. As with subscription, the 167 message will pass between the users through the Signaling path Border 168 Elements (SBE) [2] of the peer networks. 170 2.5. Session Based IM 172 In this use case a user from one peer network creates a Message 173 Session Relay Protocol (MSRP) [10] session with a user from another 174 peer network. The session establishment and the messages will pass 175 between the users through the SBEs [2] of the peer networks. 177 2.6. Other Services 179 In addition to VoIP sessions which are out of scope for this document 180 only presence and IM are nearing standardization completion. In 181 addition to presence and IM, there are many other services that are 182 being standardized or may be implemented using minimal extensions to 183 existing standards. These include: 185 o N-way chat - Enable a multi-participant chat that will include 186 users from multiple peer networks. 187 o File transfer - Send files from a user in one peer network to a 188 user in another peer network. 189 o Document sharing - Sharing and editing a document between users in 190 different peer networks. 191 o 192 * Note: Document sharing is mentioned in this document only for 193 completeness of use cases. It is not standardized by the IETF 194 and will not be included the requirements draft that will 195 result from this document. 197 The list above is of course not exhaustive as new developments in the 198 world of non-VOIP RTC will surface new services. Enabling peering 199 between networks for some of the services will create a basis for 200 enabling peeering also for future services. 202 2.7. Federation & Clearing House 204 Federation as defined in [2] enables peering between multiple Peer 205 Networks. One enablement of a federation can be via a central server 206 that provides services to the Peer Networks or using a peer to peer 207 model that enables many Peer Networks to connect to each other via 208 the peer to peer network. These services can be an N-way chat 209 server, security, lawful interception, logging and more. This type 210 of federation is known also known as a "clearing house". 212 Non-VoIP services as being usually more text based and consuming less 213 bandwidth may benefit from having a central service that will do 214 central services as logging for them. For example, instead of 215 requiring each Peer- Network to log all messages that are being sent 216 to the other Peer-Network, this service can be done by the clearing 217 house. 219 3. IANA Considerations 221 This document has no actions for IANA. 223 4. Security Considerations 225 This document discusses use cases for peering between Peer Networks. 226 It is very clear that the protocols that will enable and make such 227 peering easier will have significant security considerations. The 228 solutions for the security issues is out of scope for this document 229 but here are some examples of security issues that are implied by 230 this document: 232 When a message is received from a user on another Peer Network, 233 the receiving user, should trust that the other Peer Network have 234 authenticated the user and it is really the user he or she claim 235 to be. 236 In order to enable peering between big Peer Networks there are 237 some optimizations that will require users of one Peer Network to 238 trust the other Peer Network with respect to their privacy. 240 5. Acknowledgments 242 We would like to thank Jonathan Rosenberg, Rohan Mahy, Jason 243 Livingood, Alexander Mayhorfer, Henry Sinnreich and Mohamed Boucadir 244 for their valuable input. 246 6. References 248 6.1. Normative References 250 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 251 Levels", BCP 14, RFC 2119, March 1997. 253 6.2. Informative References 255 [2] Malas, D. and D. Meyer, "SPEERMINT Terminology", 256 draft-ietf-speermint-terminology-07 (work in progress), 257 June 2007. 259 [3] Uzelac, A., "VoIP SIP Peering Use Cases", 260 draft-ietf-speermint-voip-consolidated-usecases-02 (work in 261 progress), June 2007. 263 [4] Camarillo, G. and A. Roach, "Framework and Security 264 Considerations for Session Initiation Protocol (SIP) Uniform 265 Resource Identifier (URI)-List Services", 266 draft-ietf-sipping-uri-services-06 (work in progress), 267 September 2006. 269 [5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 270 and Instant Messaging", RFC 2778, February 2000. 272 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 273 Notification", RFC 3265, June 2002. 275 [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 276 D. Gurle, "Session Initiation Protocol (SIP) Extension for 277 Instant Messaging", RFC 3428, December 2002. 279 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 280 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 281 January 2005. 283 [9] Roach, A., Campbell, B., and J. Rosenberg, "A Session 284 Initiation Protocol (SIP) Event Notification Extension for 285 Resource Lists", RFC 4662, August 2006. 287 [10] Campbell, B., "The Message Session Relay Protocol", 288 draft-ietf-simple-message-sessions-19 (work in progress), 289 February 2007. 291 Authors' Addresses 293 Avshalom Houri 294 IBM 295 Science Park Building 18/D 296 Rehovot, 297 Israel 299 Email: avshalom@il.ibm.com 300 Edwin Aoki 301 AOL LLC 302 360 W. Caribbean Drive 303 Sunnyvale, CA 94089 304 USA 306 Email: aoki@aol.net 308 Sriram Parameswar 309 Microsoft Corporation 310 One Microsoft Way 311 Redmond, WA 98052 312 USA 314 Email: Sriram.Parameswar@microsoft.com 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2007). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).