idnits 2.17.1 draft-ietf-speermint-consolidated-presence-im-usecases-05.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 (June 2008) is 5787 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 == Outdated reference: A later version (-19) exists of draft-ietf-speermint-voip-consolidated-usecases-08 == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-02 == Outdated reference: A later version (-11) exists of draft-ietf-mmusic-file-transfer-mech-08 Summary: 2 errors (**), 0 flaws (~~), 5 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: Informational E. Aoki 5 Expires: December 3, 2008 AOL LLC 6 S. Parameswar 7 Microsoft Corporation 8 June 2008 10 Presence & Instant Messaging Peering Use Cases 11 draft-ietf-speermint-consolidated-presence-im-usecases-05.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 December 3, 2008. 38 Abstract 40 The document describes several use cases of peering of non-VoIP 41 services between two or more Service Providers. These Service 42 Providers create a peering relationship between themselves thus 43 enabling their users to collaborate with users on the other Service 44 Provider network. The target of the document is to drive 45 requirements for peering between domains that provide the non-VoIP 46 based collaboration services and presence and Instant Messaging (IM) 47 in particular. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Simple Interdomain Subscription . . . . . . . . . . . . . 3 54 2.2. List Based Interdomain Subscription . . . . . . . . . . . 4 55 2.3. Authorization Migration . . . . . . . . . . . . . . . . . 4 56 2.4. Page Mode IM . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.5. Session Based IM . . . . . . . . . . . . . . . . . . . . . 5 58 2.6. Other Services . . . . . . . . . . . . . . . . . . . . . . 5 59 2.7. Federation & Clearing House . . . . . . . . . . . . . . . 5 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 67 1. Introduction 69 The document uses the terminology as defined in [1] unless otherwise 70 stated. 72 Real Time Collaboration (RTC) services become as prevalent and 73 essential for users on the Internet as email. While RTC services can 74 be implemented directly by users in a point-to-point fashion, they 75 are often provided for or on behalf of a Peer Network of users within 76 an administrative domain. As the use of these services grows, users 77 increasingly have the need to communicate with users not only within 78 their own Peer Network but with those in other Peer Networks as well 79 (similar to the old Public Switched Telephony Network (PSTN) that 80 enabled global readability). In practice, each Peer Network is 81 controlled by some domain, and so there is a need to provide for 82 easier establishment of connectivity between Peer Networks, and the 83 management of the relationships between the Peer Networks. This 84 document describes a set of use cases that describe how peering 85 between Peer Networks may be used in non Voice over IP (VoIP) RTC 86 services. The use cases are intended to help in identifying and 87 capturing requirements that will guide and then enable a secure and 88 easier peering between Peer Networks that provide non-VoIP RTC 89 services. The use cases for the VoIP RTC services are described in 90 [2]. 92 Note that this document does not define requirements for a new 93 protocol or for protocol extensions. It caputres the way that 94 presence and Instant Messaging are currently used within enterprises 95 and operator domains. 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 (hosted in Peer Network A), wants to subscribe to 103 user Bob@example.net (hosted in Peer Network B) and get his presence 104 information. In order to do so, Alice@example.com could connect 105 directly to example.net and subscribe to Bob's presence information. 106 However, Peer Network B is willing to accept subscriptions and route 107 IMs only when they are coming from its users or from other Peer 108 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 to Bob via 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 that in this case Alice subscribes to a Uniform Resource 119 Identifier (URI) [8] that represents a list of users in Peer Network 120 B [9] [3] 122 There are several types of lists that Alice may subscribe to: 124 o Personal group - A list that was created and maintained by Alice 125 and includes Alice's watch list. 126 o Public group - A list that is created and maintained by an 127 administrator and is typically referred to as a public group. 128 Public groups usually contains a list of specific people that have 129 some common characteristic e.g. support group of a company. 130 o Ad-hoc group - A list that is short lived and is usually created 131 in a context of some activity that Alice is doing. An ad-hoc 132 group may be created by Alice or by some application. Typical 133 examples may be the list of people that participate with Alice in 134 a conference or a game. 136 2.3. Authorization Migration 138 If many users from one Peer Network watch presentities [6] in another 139 Peer Network, it may be possible that many watchers [6] from one Peer 140 Network will subscribe to the same user in the other Peer Network. 141 However, due to privacy constraints that enable a user to provide 142 different presence documents to different watchers, each Peer Network 143 will have to send multiple copies of the watched presence document. 144 The need to send multiple copies between the Peer Networks is very 145 inefficient and causes redundant traffic between the Peer Networks. 147 In order to make the subscription between Peer Networks more 148 efficient there needs to be a way to enable Peer Networks to agree to 149 share privacy information between them. This will enable sending a 150 single copy (the full copy) of the presence document of the watched 151 user and letting the receiving Peer Network to be responsible for 152 sending the right values to the right watchers according to the 153 delegated privacy policies of the watched users. 155 Instead of sharing watcher's privacy policies between the Peer 156 Networks, it is also possible to send different copies of the 157 presence document with a list of the watchers that the presence 158 document is intended for. For example, if there is a set of watchers 159 in the other Peer Network that may see the location of the presentity 160 and another set of users in the other Peer Network that may not see 161 the location information, two presence documents will be sent, each 162 one is associated with a list of watchers that should receive it. 164 One presence document will contain the location information and will 165 be associated with a list of users that may see it and the other 166 presence document will not contain the location information and will 167 be associated with a list of users that may not see the location 168 information. 170 2.4. Page Mode IM 172 In this use case a user from one Peer Network sends a page mode [7] 173 IM to a user on another Peer Network. 175 2.5. Session Based IM 177 In this use case a user from one Peer Network creates a Message 178 Session Relay Protocol (MSRP) [10] session with a user from another 179 Peer Network. 181 2.6. Other Services 183 In addition to VoIP sessions which are out of scope for this document 184 only presence and IM have been ratified as RFCs. In addition to 185 presence and IM, there are many other services that are being 186 standardized or may be implemented using minimal extensions to 187 existing standards. These include: 189 o N-way chat - Enable a multi-participant textual chat that will 190 include users from multiple Peer Networks. See [4] for more 191 details. 192 o File transfer - Send files from a user in one Peer Network to a 193 user in another Peer Network. See [5] for more details. 194 o Document sharing - Sharing and editing a document between users in 195 different Peer Networks. 197 Note: Document sharing is mentioned in this document only for 198 completeness of use cases. It is not being standardized by the 199 IETF and will not be included the requirements draft that will 200 result from this document. 202 The list above is of course not exhaustive as new developments in the 203 world of non-VOIP RTC will surface new services. Enabling peering 204 between networks for some of the services will create a basis for 205 enabling peering also for future services. 207 2.7. Federation & Clearing House 209 A Federation as defined in [1] enables peering between multiple Peer 210 Networks. A federation may be implemented by means of a central 211 service providing a hub for the Peer Networks or, alternatively, Peer 212 Networks may connect to each other in a peer-to-peer fashion. One of 213 the most important services that this type of federation should 214 provide is authorized interconnection that enables each Peering 215 Network to securely identify other Peering Networks. Other services 216 that might be provided include an N-way chat server, lawful 217 interception, logging and more. This type of federation is also 218 known as a "Clearing House". 220 As non-VoIP services are usually text-based and consume less 221 bandwidth, they may benefit from having a central service that will 222 do central services such as logging for them. For example, instead 223 of requiring each Peer Network to log all messages that are being 224 sent to the other Peer-Network, this service can be done by the 225 Clearing House. 227 3. IANA Considerations 229 This document has no actions for IANA. 231 4. Security Considerations 233 When Peer Network A peers with Peer Network B, there are several 234 security issues that the administrator of each Peer Network will need 235 mechanisms to verify: 237 o All communication channels between Peer Network and between each 238 Peer Network and the clearing house have their authenticity and 239 confidentiality protected. 240 o The other Peer Network is really the Peering Network that it 241 claims to be. 242 o The other Peer Network is secure and trustful such that 243 information that is passed to it, will not reach a third party. 244 This includes information about specific users as well as 245 information about the authorization policies associated with user 246 information. 247 o The other Peer Network is secure and trustful such that it will 248 not modify or falsify data that it presents to its users except as 249 required by the authorization policy provided. 250 o If there is a third party (e.g. a clearing house) involved in the 251 connection between the two Peering Networks that element is also 252 verified to be secure. 254 The same issues of security are even more important from the point of 255 view of the users of the Peer Networks. Users will have the concern 256 on how their privacy is being adhered to when their presence 257 information is being sent to the other Peer Network. Users today are 258 concerned about providing their email address to a third party when 259 they register to a domain; Presence contains much more sensitive 260 information and the concern of users here will be even deeper. 262 The privacy issue is even harder if we take into account that in 263 order to enable scalable peering between big Peer Networks there are 264 some optimizations that may require migration of the privacy 265 definitions of users between Peer Network (see Section 2.3). We can 266 imagine the fiasco if a user of one Peer Network will be able to see 267 the privacy information and will learn he/she are listed in a block 268 list of a close friend. 270 This document discusses use cases for peering between Peer Networks. 271 It is out of scope for the document to provide solutions for 272 security. Nevertheless, it is obvious that the protocols that will 273 enable the use cases that are described here will have to provide for 274 the security considerations described here. 276 5. Acknowledgments 278 We would like to thank Jonathan Rosenberg, Jon Peterson, Rohan Mahy, 279 Jason Livingood, Alexander Mayrhofer, Joseph Salowey, Henry Sinnreich 280 and Mohamed Boucadir for their valuable input. 282 6. Informative References 284 [1] Malas, D. and D. Meyer, "SPEERMINT Terminology", 285 draft-ietf-speermint-terminology-16 (work in progress), 286 February 2008. 288 [2] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 289 draft-ietf-speermint-voip-consolidated-usecases-08 (work in 290 progress), May 2008. 292 [3] Camarillo, G. and A. Roach, "Framework and Security 293 Considerations for Session Initiation Protocol (SIP) Uniform 294 Resource Identifier (URI)-List Services", 295 draft-ietf-sipping-uri-services-07 (work in progress), 296 November 2007. 298 [4] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party 299 Instant Message (IM) Sessions Using the Message Session Relay 300 Protocol (MSRP)", draft-ietf-simple-chat-02 (work in progress), 301 February 2008. 303 [5] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and 304 P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer 305 Mechanism to Enable File Transfer", 306 draft-ietf-mmusic-file-transfer-mech-08 (work in progress), 307 May 2008. 309 [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 310 and Instant Messaging", RFC 2778, February 2000. 312 [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 313 D. Gurle, "Session Initiation Protocol (SIP) Extension for 314 Instant Messaging", RFC 3428, December 2002. 316 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 317 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 318 January 2005. 320 [9] Roach, A., Campbell, B., and J. Rosenberg, "A Session 321 Initiation Protocol (SIP) Event Notification Extension for 322 Resource Lists", RFC 4662, August 2006. 324 [10] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 325 Relay Protocol (MSRP)", RFC 4975, September 2007. 327 Authors' Addresses 329 Avshalom Houri 330 IBM 331 Science Park Building 18/D 332 Rehovot, 333 Israel 335 Email: avshalom@il.ibm.com 337 Edwin Aoki 338 AOL LLC 339 360 W. Caribbean Drive 340 Sunnyvale, CA 94089 341 USA 343 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 (2008). 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.