idnits 2.17.1 draft-ietf-speermint-consolidated-presence-im-usecases-03.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 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. 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 (November 16, 2007) is 6005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 275, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 307, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-13 == Outdated reference: A later version (-19) exists of draft-ietf-speermint-voip-consolidated-usecases-03 == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-00 == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-04 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '8') (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 7 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: May 19, 2008 AOL LLC 6 S. Parameswar 7 Microsoft Corporation 8 November 16, 2007 10 Presence & Instant Messaging Peering Use Cases 11 draft-ietf-speermint-consolidated-presence-im-usecases-03.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 May 19, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 readability). 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, 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@example.com could 104 connect directly to example.net and subscribe to Bob's presence 105 information. However, Peer Network B is willing to accept 106 subscriptions and route IMs only when they are coming from its users 107 or from other Peer Networks that Peer Network B trusts. 109 In reality what will happen is that Peer Network A will connect to 110 peer network B and will send Alice's subscription to Bob via Peer 111 Network B. When peer network B has new information on Bob it will 112 send notifications to Peer Network A that will pass them to Alice. 114 2.2. List Based Interdomain Subscription 116 This is similar to the simple interdomain subscription use case 117 except that in this case Alice subscribes to a Uniform Resource 118 Identifier (URI) [10] that represents a list of users in Peer Network 119 B [11] [4] 120 There are several types of lists that Alice may subscribe to: 122 o Personal group - A list that was created and maintained by Alice 123 and includes Alice's watch list. 124 o Public group - A list that is created and maintained by an 125 administrator and is typically referred to as a public group. 126 Public groups usually contains a list of specific people that have 127 some common characteristic e.g. support group of a company. 128 o Ad-hock group - A list that is short lived and is usually created 129 in a context of some activity that Alice is doing. A public group 130 may be created by Alice or by some application. Typical examples 131 may be the list of people that participate with Alice in a 132 conference or a game. 134 2.3. Authorization Migration 136 If many users from one Peer Network watch presentities [7] in another 137 Peer Network, it may be possible that many watchers [7] from one Peer 138 Network will subscribe to the same user in the other Peer Network. 139 However, due to privacy constraints that enable a user to provide 140 different presence documents to different watchers, each Peer Network 141 will have to send multiple copies of the watched presence document. 142 The need to send multiple copies between the Peer Networks is very 143 inefficient and causes redundant traffic between the Peer Networks. 145 In order to make the subscription between Peer Networks more 146 efficient there needs to be a way to enable Peer Networks to agree to 147 share privacy information between them. This will enable sending a 148 single copy (the full copy) of the presence document of the watched 149 user and letting the receiving Peer Network to be responsible for 150 sending the right values to the right watchers according to the 151 delegated privacy policies of the watched users. 153 Instead of sharing watcher's privacy policies between the Peer 154 Networks, it is also possible to send different copies of the 155 presence document with a list of the watchers that the presence 156 document is intended for. For example, if there is a set of watchers 157 in the other Peer Network that may see the location of the presentity 158 and another set of users in the other Peer Network that may not see 159 the location information, two presence documents will be sent, each 160 one is associated with a list of watchers that should receive it. 161 One presence document will contain the location information and will 162 be associated with a list of users that may see it and the other 163 presence document will not contain the location information and will 164 be associated with a list of users that may not see the location 165 information. 167 2.4. Page Mode IM 169 In this use case a user from one Peer Network sends a page mode [9] 170 IM to a user on another Peer Network. 172 2.5. Session Based IM 174 In this use case a user from one Peer Network creates a Message 175 Session Relay Protocol (MSRP) [12] session with a user from another 176 Peer Network. 178 2.6. Other Services 180 In addition to VoIP sessions which are out of scope for this document 181 only presence and IM have been fully standardized (became RFCs). In 182 addition to presence and IM, there are many other services that are 183 being standardized or may be implemented using minimal extensions to 184 existing standards. These include: 186 o N-way chat - Enable a multi-participant textual chat that will 187 include users from multiple Peer Networks. See [5] for more 188 details. 189 o File transfer - Send files from a user in one Peer Network to a 190 user in another Peer Network. See [6] for more details. 191 o Document sharing - Sharing and editing a document between users in 192 different Peer Networks. 194 Note: Document sharing is mentioned in this document only for 195 completeness of use cases. It is not being standardized by the 196 IETF and will not be included the requirements draft that will 197 result from this document. 199 The list above is of course not exhaustive as new developments in the 200 world of non-VOIP RTC will surface new services. Enabling peering 201 between networks for some of the services will create a basis for 202 enabling peering also for future services. 204 2.7. Federation & Clearing House 206 Federation as defined in [2] enables peering between multiple Peer 207 Networks. A federation may be implemented by means of a central 208 service providing a hub for the Peer Networks or, alternatively, Peer 209 Networks may connect each other via a peer-to-peer fashion. One of 210 the most important services that this type of federation should 211 provide is authorized interconnection that enables each Peering 212 Network to trust that the other Peering Network is who it claims to 213 be. Other services that might be provided include an N-way chat 214 server, lawful interception, logging and more. This type of 215 federation is also known as a "Clearing House". 217 As non-VoIP services are usually text-based and consume less 218 bandwidth, they may benefit from having a central service that will 219 do central services such as logging for them. For example, instead 220 of requiring each Peer Network to log all messages that are being 221 sent to the other Peer-Network, this service can be done by the 222 Clearing House. 224 3. IANA Considerations 226 This document has no actions for IANA. 228 4. Security Considerations 230 When Peer Network A peers with Peer Network B, there are several 231 security issues that the administrator of each Peer Network will need 232 mechanisms to verify: 234 o The other Peer Network is really the Peering Network that it 235 claims to be. 236 o The other Peer Network is secure and trustful such that 237 information that is passed to will not reach a third party. 238 o If there is a third party (e.g. a clearing house) involved in the 239 connection between the two Peering Networks that element is also 240 verified to be secure. 242 The same issues of security are even more important from the point of 243 view of the users of the Peer Networks. Users will have the concern 244 on how their privacy is being adhered to when their presence 245 information is being sent to the other Peer Network. We are seeing 246 today users are concerned with providing their email address to a 247 third party when they register to a domain. Presence contains much 248 more sensitive information and the concerns of the users here will be 249 much deeper. 251 The privacy issue is even harder if we take into account that in 252 order to enable scalable peering between big Peer Networks there are 253 some optimizations that may require migration of the privacy 254 definitions of users between Peer Network See Section 2.3. We can 255 imagine the fiasco if a user of one Peer Network will be able to see 256 the privacy information and will learn he/she are listed in a block 257 list of a close friend. 259 This document discusses use cases for peering between Peer Networks 260 and it is out of scope for the document to provide solutions for 261 security. Nevertheless, it is obvious that the protocols that will 262 enable the use cases that are described here will have to provide for 263 the security considerations described here. 265 5. Acknowledgments 267 We would like to thank Jonathan Rosenberg, Jon Peterson, Rohan Mahy, 268 Jason Livingood, Alexander Mayhorfer, Henry Sinnreich and Mohamed 269 Boucadir for their valuable input. 271 6. References 273 6.1. Normative References 275 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 276 Levels", BCP 14, RFC 2119, March 1997. 278 6.2. Informative References 280 [2] Malas, D. and D. Meyer, "SPEERMINT Terminology", 281 draft-ietf-speermint-terminology-13 (work in progress), 282 November 2007. 284 [3] Uzelac, A., "VoIP SIP Peering Use Cases", 285 draft-ietf-speermint-voip-consolidated-usecases-03 (work in 286 progress), November 2007. 288 [4] Camarillo, G. and A. Roach, "Framework and Security 289 Considerations for Session Initiation Protocol (SIP) Uniform 290 Resource Identifier (URI)-List Services", 291 draft-ietf-sipping-uri-services-07 (work in progress), 292 November 2007. 294 [5] Niemi, A. and M. Garcia-Martin, "Multi-party Instant Message 295 (IM) Sessions Using the Message Session Relay Protocol 296 (MSRP)", draft-ietf-simple-chat-00 (work in progress), 297 June 2007. 299 [6] Garcia-Martin, M., Isomaki, M., Camarillo, G., and S. Loreto, 300 "A Session Description Protocol (SDP) Offer/Answer Mechanism to 301 Enable File Transfer", draft-ietf-mmusic-file-transfer-mech-04 302 (work in progress), October 2007. 304 [7] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 305 and Instant Messaging", RFC 2778, February 2000. 307 [8] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 308 Notification", RFC 3265, June 2002. 310 [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 311 D. Gurle, "Session Initiation Protocol (SIP) Extension for 312 Instant Messaging", RFC 3428, December 2002. 314 [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 315 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 316 January 2005. 318 [11] Roach, A., Campbell, B., and J. Rosenberg, "A Session 319 Initiation Protocol (SIP) Event Notification Extension for 320 Resource Lists", RFC 4662, August 2006. 322 [12] Campbell, B., "The Message Session Relay Protocol", 323 draft-ietf-simple-message-sessions-19 (work in progress), 324 February 2007. 326 Authors' Addresses 328 Avshalom Houri 329 IBM 330 Science Park Building 18/D 331 Rehovot, 332 Israel 334 Email: avshalom@il.ibm.com 336 Edwin Aoki 337 AOL LLC 338 360 W. Caribbean Drive 339 Sunnyvale, CA 94089 340 USA 342 Email: aoki@aol.net 344 Sriram Parameswar 345 Microsoft Corporation 346 One Microsoft Way 347 Redmond, WA 98052 348 USA 350 Email: Sriram.Parameswar@microsoft.com 352 Full Copyright Statement 354 Copyright (C) The IETF Trust (2007). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Intellectual Property 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org. 392 Acknowledgment 394 Funding for the RFC Editor function is provided by the IETF 395 Administrative Support Activity (IASA).