idnits 2.17.1 draft-ietf-speermint-consolidated-presence-im-usecases-04.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 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 389. 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 (February 15, 2008) is 5914 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-05 == 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-06 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: August 18, 2008 AOL LLC 6 S. Parameswar 7 Microsoft Corporation 8 February 15, 2008 10 Presence & Instant Messaging Peering Use Cases 11 draft-ietf-speermint-consolidated-presence-im-usecases-04.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 August 18, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The document describes several use cases of peering of non-VoIP 45 services between two or more Service Providers. 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. Informative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 1. Introduction 73 The document uses the terminology as defined in [1] unless otherwise 74 stated. 76 Real Time Collaboration (RTC) services become as prevalent and 77 essential for users on the Internet as email. While RTC services can 78 be implemented directly by users in a point-to-point fashion, they 79 are often provided for or on behalf of a Peer Network of users within 80 an administrative domain. As the use of these services grows, users 81 increasingly have the need to communicate with users not only within 82 their own Peer Network but with those in other Peer Networks as well 83 (similar to the old Public Switched Telephony Network (PSTN) that 84 enabled global readability). In practice, each Peer Network is 85 controlled by some domain, and so there is a need to provide for 86 easier establishment of connectivity between Peer Networks, and the 87 management of the relationships between the Peer Networks. This 88 document describes a set of use cases that describe how peering 89 between Peer Networks may be used in non Voice over IP (VoIP) RTC 90 services. The use cases are intended to help in identifying and 91 capturing requirements that will guide and then enable a secure and 92 easier peering between Peer Networks that provide non-VoIP RTC 93 services. The use cases for the VoIP RTC services are described in 94 [2]. 96 2. Use Cases 98 2.1. Simple Interdomain Subscription 100 Assume two Peer Networks, Peer Network A and Peer Network B. User 101 Alice@example.com (hosted in Peer Network A), wants to subscribe to 102 user Bob@example.net (hosted in Peer Network B) and get his presence 103 information. In order to do so, Alice@example.com could connect 104 directly to example.net and subscribe to Bob's presence information. 105 However, Peer Network B is willing to accept subscriptions and route 106 IMs only when they are coming from its users or from other Peer 107 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) [8] that represents a list of users in Peer Network 119 B [9] [3] 121 There are several types of lists that Alice may subscribe to: 123 o Personal group - A list that was created and maintained by Alice 124 and includes Alice's watch list. 125 o Public group - A list that is created and maintained by an 126 administrator and is typically referred to as a public group. 127 Public groups usually contains a list of specific people that have 128 some common characteristic e.g. support group of a company. 129 o Ad-hoc group - A list that is short lived and is usually created 130 in a context of some activity that Alice is doing. An ad-hoc 131 group may be created by Alice or by some application. Typical 132 examples may be the list of people that participate with Alice in 133 a conference or a game. 135 2.3. Authorization Migration 137 If many users from one Peer Network watch presentities [6] in another 138 Peer Network, it may be possible that many watchers [6] from one Peer 139 Network will subscribe to the same user in the other Peer Network. 140 However, due to privacy constraints that enable a user to provide 141 different presence documents to different watchers, each Peer Network 142 will have to send multiple copies of the watched presence document. 143 The need to send multiple copies between the Peer Networks is very 144 inefficient and causes redundant traffic between the Peer Networks. 146 In order to make the subscription between Peer Networks more 147 efficient there needs to be a way to enable Peer Networks to agree to 148 share privacy information between them. This will enable sending a 149 single copy (the full copy) of the presence document of the watched 150 user and letting the receiving Peer Network to be responsible for 151 sending the right values to the right watchers according to the 152 delegated privacy policies of the watched users. 154 Instead of sharing watcher's privacy policies between the Peer 155 Networks, it is also possible to send different copies of the 156 presence document with a list of the watchers that the presence 157 document is intended for. For example, if there is a set of watchers 158 in the other Peer Network that may see the location of the presentity 159 and another set of users in the other Peer Network that may not see 160 the location information, two presence documents will be sent, each 161 one is associated with a list of watchers that should receive it. 162 One presence document will contain the location information and will 163 be associated with a list of users that may see it and the other 164 presence document will not contain the location information and will 165 be associated with a list of users that may not see the location 166 information. 168 2.4. Page Mode IM 170 In this use case a user from one Peer Network sends a page mode [7] 171 IM to a user on another Peer Network. 173 2.5. Session Based IM 175 In this use case a user from one Peer Network creates a Message 176 Session Relay Protocol (MSRP) [10] session with a user from another 177 Peer Network. 179 2.6. Other Services 181 In addition to VoIP sessions which are out of scope for this document 182 only presence and IM have been ratified as RFCs. In addition to 183 presence and IM, there are many other services that are being 184 standardized or may be implemented using minimal extensions to 185 existing standards. These include: 187 o N-way chat - Enable a multi-participant textual chat that will 188 include users from multiple Peer Networks. See [4] for more 189 details. 190 o File transfer - Send files from a user in one Peer Network to a 191 user in another Peer Network. See [5] for more details. 192 o Document sharing - Sharing and editing a document between users in 193 different Peer Networks. 195 Note: Document sharing is mentioned in this document only for 196 completeness of use cases. It is not being standardized by the 197 IETF and will not be included the requirements draft that will 198 result from this document. 200 The list above is of course not exhaustive as new developments in the 201 world of non-VOIP RTC will surface new services. Enabling peering 202 between networks for some of the services will create a basis for 203 enabling peering also for future services. 205 2.7. Federation & Clearing House 207 A Federation as defined in [1] enables peering between multiple Peer 208 Networks. A federation may be implemented by means of a central 209 service providing a hub for the Peer Networks or, alternatively, Peer 210 Networks may connect to each other in a peer-to-peer fashion. One of 211 the most important services that this type of federation should 212 provide is authorized interconnection that enables each Peering 213 Network to securely identify other Peering Networks. Other services 214 that might be provided include an N-way chat server, lawful 215 interception, logging and more. This type of federation is also 216 known as a "Clearing House". 218 As non-VoIP services are usually text-based and consume less 219 bandwidth, they may benefit from having a central service that will 220 do central services such as logging for them. For example, instead 221 of requiring each Peer Network to log all messages that are being 222 sent to the other Peer-Network, this service can be done by the 223 Clearing House. 225 3. IANA Considerations 227 This document has no actions for IANA. 229 4. Security Considerations 231 When Peer Network A peers with Peer Network B, there are several 232 security issues that the administrator of each Peer Network will need 233 mechanisms to verify: 235 o All communication channels between Peer Network and between each 236 Peer Network and the clearing house have their authenticity and 237 confidentiality protected. 238 o The other Peer Network is really the Peering Network that it 239 claims to be. 240 o The other Peer Network is secure and trustful such that 241 information that is passed to it, will not reach a third party. 242 This includes information about specific users as well as 243 information about the authorization policies associated with user 244 information. 245 o The other Peer Network is secure and trustful such that it will 246 not modify or falsify data that it presents to its users except as 247 required by the authorization policy provided. 248 o If there is a third party (e.g. a clearing house) involved in the 249 connection between the two Peering Networks that element is also 250 verified to be secure. 252 The same issues of security are even more important from the point of 253 view of the users of the Peer Networks. Users will have the concern 254 on how their privacy is being adhered to when their presence 255 information is being sent to the other Peer Network. Users today are 256 concerned about providing their email address to a third party when 257 they register to a domain; Presence contains much more sensitive 258 information and the concern of users here will be even deeper. 260 The privacy issue is even harder if we take into account that in 261 order to enable scalable peering between big Peer Networks there are 262 some optimizations that may require migration of the privacy 263 definitions of users between Peer Network (see Section 2.3). We can 264 imagine the fiasco if a user of one Peer Network will be able to see 265 the privacy information and will learn he/she are listed in a block 266 list of a close friend. 268 This document discusses use cases for peering between Peer Networks. 269 It is out of scope for the document to provide solutions for 270 security. Nevertheless, it is obvious that the protocols that will 271 enable the use cases that are described here will have to provide for 272 the security considerations described here. 274 5. Acknowledgments 276 We would like to thank Jonathan Rosenberg, Jon Peterson, Rohan Mahy, 277 Jason Livingood, Alexander Mayrhofer, Joseph Salowey, Henry Sinnreich 278 and Mohamed Boucadir for their valuable input. 280 6. Informative References 282 [1] Malas, D. and D. Meyer, "SPEERMINT Terminology", 283 draft-ietf-speermint-terminology-16 (work in progress), 284 February 2008. 286 [2] Uzelac, A., "VoIP SIP Peering Use Cases", 287 draft-ietf-speermint-voip-consolidated-usecases-05 (work in 288 progress), February 2008. 290 [3] Camarillo, G. and A. Roach, "Framework and Security 291 Considerations for Session Initiation Protocol (SIP) Uniform 292 Resource Identifier (URI)-List Services", 293 draft-ietf-sipping-uri-services-07 (work in progress), 294 November 2007. 296 [4] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party 297 Instant Message (IM) Sessions Using the Message Session Relay 298 Protocol (MSRP)", draft-ietf-simple-chat-02 (work in progress), 299 February 2008. 301 [5] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and 302 P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer 303 Mechanism to Enable File Transfer", 304 draft-ietf-mmusic-file-transfer-mech-06 (work in progress), 305 December 2007. 307 [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 308 and Instant Messaging", RFC 2778, February 2000. 310 [7] 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 [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 315 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 316 January 2005. 318 [9] 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 [10] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 323 Relay Protocol (MSRP)", RFC 4975, September 2007. 325 Authors' Addresses 327 Avshalom Houri 328 IBM 329 Science Park Building 18/D 330 Rehovot, 331 Israel 333 Email: avshalom@il.ibm.com 335 Edwin Aoki 336 AOL LLC 337 360 W. Caribbean Drive 338 Sunnyvale, CA 94089 339 USA 341 Email: aoki@aol.net 343 Sriram Parameswar 344 Microsoft Corporation 345 One Microsoft Way 346 Redmond, WA 98052 347 USA 349 Email: Sriram.Parameswar@microsoft.com 351 Full Copyright Statement 353 Copyright (C) The IETF Trust (2008). 355 This document is subject to the rights, licenses and restrictions 356 contained in BCP 78, and except as set forth therein, the authors 357 retain all their rights. 359 This document and the information contained herein are provided on an 360 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 361 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 362 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 363 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 364 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 367 Intellectual Property 369 The IETF takes no position regarding the validity or scope of any 370 Intellectual Property Rights or other rights that might be claimed to 371 pertain to the implementation or use of the technology described in 372 this document or the extent to which any license under such rights 373 might or might not be available; nor does it represent that it has 374 made any independent effort to identify any such rights. Information 375 on the procedures with respect to rights in RFC documents can be 376 found in BCP 78 and BCP 79. 378 Copies of IPR disclosures made to the IETF Secretariat and any 379 assurances of licenses to be made available, or the result of an 380 attempt made to obtain a general license or permission for the use of 381 such proprietary rights by implementers or users of this 382 specification can be obtained from the IETF on-line IPR repository at 383 http://www.ietf.org/ipr. 385 The IETF invites any interested party to bring to its attention any 386 copyrights, patents or patent applications, or other proprietary 387 rights that may cover technology that may be required to implement 388 this standard. Please address the information to the IETF at 389 ietf-ipr@ietf.org. 391 Acknowledgment 393 Funding for the RFC Editor function is provided by the IETF 394 Administrative Support Activity (IASA).