idnits 2.17.1 draft-ietf-simple-simple-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 16, 2013) is 4087 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft jdrosen.net 4 Intended status: Informational February 16, 2013 5 Expires: August 20, 2013 7 SIMPLE made Simple: An Overview of the IETF Specifications for Instant 8 Messaging and Presence using the Session Initiation Protocol (SIP) 9 draft-ietf-simple-simple-09 11 Abstract 13 The IETF has produced many specifications related to Presence and 14 Instant Messaging with the Session Initiation Protocol (SIP). 15 Collectively, these specifications are known as SIMPLE - SIP for 16 Instant Messaging and Presence Leveraging Extensions. This document 17 serves as a guide to the SIMPLE suite of specifications. It 18 categorizes the specifications and explains what each is for and how 19 they relate to each other. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 20, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Core Protocol Machinery . . . . . . . . . . . . . . . . . 4 58 2.2. Presence Documents . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Privacy and Policy . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.5. Federation . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 8 63 3. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1. Page Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.2. Session Mode . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.3. IM Chat Rooms . . . . . . . . . . . . . . . . . . . . . . 10 67 3.4. IM Features . . . . . . . . . . . . . . . . . . . . . . . 11 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 The IETF has produced many specifications related to Presence and 77 Instant Messaging with the Session Initiation Protocol (SIP) 78 [RFC3261]. Collectively, these specifications are known as SIMPLE - 79 SIP for Instant Messaging and Presence Leveraging Extensions. These 80 specifications cover topics ranging from protocols for subscription 81 and publication, to presence document formats, to protocols for 82 managing privacy preferences. The large number of specifications can 83 make it hard to figure out exactly what exactly SIMPLE is, what 84 specifications cover it, what functionality it provides, and how 85 these specifications relate to each other. 87 This document serves to address this problem. It provides an 88 enumeration of the protocols which make up the SIMPLE suite of 89 specifications from IETF. It categorizes them into related areas of 90 functionality, and briefly explains the purpose of each and how the 91 specifications relate to each other. Each specification also 92 includes a letter that designates its category in the standards track 93 [RFC2026]. These values are: 95 S: Standards Track (Proposed Standard, Draft Standard, or Standard) 97 E: Experimental 99 B: Best Current Practice 101 I: Informational 103 2. Presence 105 SIMPLE provides for both presence and IM capabilities. Though both 106 of these fit underneath the broad SIMPLE umbrella, they are well 107 separated from each other and are supported by different sets of 108 specifications. That is a key part of the SIMPLE story; presence is 109 much broader than just IM, and it enables communications using voice 110 and video along with IM. 112 The SIMPLE presence specifications can be broken up into: 114 o The core protocol machinery, which provides the actual SIP 115 extensions for subscriptions, notifications and publications 117 o Presence documents, which are XML documents that provide for rich 118 presence and are carried by the core protocol machinery 120 o Privacy and policy, which are documents for expressing privacy 121 preferences about how those presence documents are to be shown (or 122 not shown) to other users 124 o Provisioning, which describes how users manage their privacy 125 policies, buddy lists and other pieces of information required for 126 SIMPLE presence to work 128 o Optimizations, which are improvements in the core protocol 129 machinery that were defined to improve the performance of SIMPLE, 130 particularly on wireless links 132 2.1. Core Protocol Machinery 134 RFC 6665, SIP-Specific Event Notification (S): RFC 6665 [RFC6665] 135 defines the SUBSCRIBE and NOTIFY methods for SIP, forming the core 136 of the SIP event notification framework. To actually use the 137 framework, extensions need to be defined for specific event 138 packages. Presence is defined as an event package [RFC3856] 139 within this framework. Packages exist for other, non-presence 140 related functions, such as message waiting indicators and dialog 141 state changes. 143 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [RFC3856] 144 defines an event package for indicating user presence through SIP. 145 Through this package, a SIP user agent can ask to be notified of 146 the presence state of a presentity (presence entity). The content 147 of the NOTIFY messages in this package are presence documents, 148 discussed in Section 2.2, below. 150 RFC 4662, A Session Initiation Protocol (SIP) Event Notification 151 Extension for Resource Lists (S): RFC 4662 [RFC4662] defines an 152 extension to RFC 6665 that allows a client to subscribe to a list 153 of resources using a single subscription. The server, called a 154 Resource List Server (RLS) will "expand" the subscription and 155 subscribe to each individual member of the list. Its primary 156 usage with presence is to allow subscriptions to "buddy lists". 157 Without RFC 4662, a UA would need to subscribe to each presentity 158 individually. With RFC 4662, they can have a single subscription 159 to all buddies. A user can manage the entries in their buddy list 160 using the provisioning mechanisms in Section 2.4, below. 162 RFC 5367, Subscriptions to Request-Contained Resource Lists in the 163 Session Initiation Protocol (SIP) (S): [RFC5367] is very similar to 164 RFC 4662. It allows a client to subscribe to a list of resources 165 using a single subscription. However, with this mechanism, the 166 list is included within the body of the SUBSCRIBE request. In RFC 167 4662, it is provisioned ahead of time on the server. 169 RFC 3903, SIP Extension for Event State Publication (S): RFC 3903 170 [RFC3903] defines the PUBLISH method. With this method, a user 171 agent can publish its current state for any event package, 172 including the presence event package. Once an agent publishes its 173 presence state, the presence server would send notifications of 174 this state change using RFC 3856. 176 2.2. Presence Documents 178 Once a user has generated a subscription to presence using the core 179 protocol machinery, they will receive notifications (SIP NOTIFY 180 requests) which contain presence information. That presence 181 information is in the form of an XML presence document. Several 182 specifications have been defined to describe this document format, 183 focusing on rich, multimedia presence. 185 RFC 3863, Presence Information Data Format (S): [RFC3863] defines 186 the baseline XML format for a presence document. It defines the 187 concept of a tuple as representing a basic communication modality, 188 and defines a simple status for it (open or closed). 190 RFC 4479, A Data Model for Presence (S): [RFC4479] extends the basic 191 model in RFC 3863. It introduces the concepts of devices and 192 person status, and explains how these relate to each other. It 193 describes how presence documents are used to represent states in 194 communications systems in a consistent fashion. More than RFC 195 3863, it defines what a presence document is and what it means. 197 RFC 4480, RPID: Rich Presence Extensions to PIDF (S): [RFC4480] adds 198 many more attributes to the presence document schema, building 199 upon the model in RFC 4479. It allows for indications of 200 activities, moods, places and place types, icons, and indications 201 of whether a user is idle or not. 203 RFC 4481, Timed Presence Extensions to the Presence Information Data 204 Format (PIDF) to Indicate Status Information for Past and Future Time 205 Intervals (S): [RFC4481] adds additional attributes to the presence 206 document schema, again building upon the model in RFC 4479. It 207 allows documents to indicate status for the future or the past. 208 For example, a user can indicate that they will be unavailable for 209 voice communications from 2pm to 3pm, due to a meeting. 211 RFC 4482, CIPID: Contact Information for the Presence Information 212 Data Format (S): [RFC4482] adds attributes to the presence document 213 schema for contact information, such as a vCard, display name, 214 homepage, icon, or sound (such as the pronunciation of their 215 name). 217 RFC 5196, Session Initiation Protocol (SIP) User Agent Capability 218 Extension to Presence Information Data Format (PIDF) (S): [RFC5196] 219 adds even more attributes to the presence document schema, this 220 time to allow indication of capabilities for the user agent. For 221 example, the extensions can indicate whether a UA supports audio 222 and video, what SIP methods it supports, and so on. 224 2.3. Privacy and Policy 226 The rich presence capabilities defined by the specifications in 227 Section 2.2 introduces a strong need for privacy preferences. Users 228 must be able to approve or deny subscriptions to their presence, and 229 indicate what information such watchers can see. In SIMPLE, this is 230 accomplished through policy documents, uploaded to the presence 231 server using the provisioning mechanisms in Section 2.4. 233 RFC 4745, Common Policy: A Document Format for Expressing Privacy 234 Preferences (S): [RFC4745] defines a general XML framework for 235 expressing privacy preferences for both geolocation information 236 and presence information. It introduces the concepts of 237 conditions, actions and transformations that are applied to 238 privacy-sensitive data. The common policy framework provides 239 privacy-safety, a property by which network error or version 240 incompatibilities can never cause more information to be revealed 241 to a watcher than the user would otherwise desire. 243 RFC 5025, Presence Authorization Rules (S): [RFC5025] uses the 244 framework of RFC 4745 to define a policy document format for 245 describing presence privacy policies. Besides basic yes/no 246 approvals, this format allows a user to control what kind of 247 information a watcher is allowed to see. 249 RFC 3857, A Watcher Information Event Template Package for SIP (S): 250 [RFC3857], also known as watcherinfo, provides a mechanism for a 251 user agent to find out what subscriptions are in place for a 252 particular event package. Though it was defined to be used for 253 any event package, it has particular applicability for presence. 254 It is used to provide reactive authorization. With reactive 255 authorization, a user gets alerted if someone tries to subscribe 256 to their presence, so that they may provide an authorization 257 decision. Watcherinfo is used to provide the alert that someone 258 has subscribed to a user's presence. 260 RFC 3858, An Extensible Markup Language (XML) Based Format for 261 Watcher Information (S): [RFC3858] is the companion to RFC 3857. It 262 specifies the XML format of watcherinfo that is carried in 263 notifications for the event template package in RFC 3857. 265 2.4. Provisioning 267 Proper operation of a SIMPLE presence system requires that several 268 pieces of data are correctly managed by the users and provisioned 269 into the system. These include buddy lists (used by the resource 270 list subscription mechanism in RFC 4662) and privacy policies (such 271 as those described by the XML format in [RFC5025]). 273 In SIMPLE, management of this data is handled by the XML 274 Configuration Access Protocol (XCAP) [RFC4825]. XCAP is used by the 275 user agent to manipulate buddy lists, privacy policy, and other data 276 that is represented by XML documents stored on a server. 278 RFC 4825, The Extensible Markup Language (XML) Configuration Access 279 Protocol (XCAP) (S): [RFC4825] specifies XCAP. XCAP is a usage of 280 HTTP that allows a user agent to manipulate the contents of XML 281 documents stored on a server. It can be used to manipulate any 282 kind of XML, and the protocol itself is independent of the 283 particular schema of the data it is modifying. XML schemas have 284 been defined for buddy lists, privacy policies and offline 285 presence status, allowing all of those to be managed by a user 286 with XCAP. 288 RFC 5875, An Extensible Markup Language (XML) Configuration Access 289 Protocol (XCAP) Diff Event Package (S): [RFC5875] defines an 290 extension to the SIP user agent configuration profile, allowing a 291 user agent to learn about changes in its documents on an XCAP 292 server. With this mechanism, there can be a change made by 293 someone else to a buddy list or privacy policy document, and a UA 294 will find out that a new version is available. 296 RFC 5874, An Extensible Markup Language (XML) Document Format for 297 Indicating A Change in XML Configuration Access Protocol (XCAP) 298 Resources (S): [RFC5874] defines an XML format for indicating 299 changes in XCAP documents. It makes use of an XML diff format 300 defined in [RFC5261]. It is used in conjunction with [RFC5875] to 301 alert a user agent of changes made by someone else to their 302 provisioned data. 304 RFC 4826, XML Formats for Representing Resource Lists (S): [RFC4826] 305 defines two XML document formats used to represent buddy lists. 306 One is simply a list of users (or more generally, resources), and 307 the other defines a buddy list whose membership is composed of a 308 list of users or resources. These lists can be manipulated by 309 XCAP, allowing a user to add or remove members from their buddy 310 lists. The buddy list is also accessed by the resource list 311 server specified in RFC 4662 for processing resource list 312 subscriptions. 314 RFC 4827, An Extensible Markup Language (XML) Configuration Access 315 Protocol (XCAP) Usage for Manipulating Presence Document Contents 316 (S): [RFC4827] defines an XCAP usage that allows a user to store an 317 "offline" presence document. This is a presence status that is 318 used by a presence server when there are no presence documents 319 published for that user by any user agents currently running. 321 2.5. Federation 323 Federation refers to the interconnection of different presence and 324 instant messaging systems for the purposes of communications. 325 Federation can be between domains or within a domain. A document has 326 been developed which describes how presence and IM federation works. 328 RFC 5344, Presence and Instant Messaging Peering Use Cases (I): 329 [RFC5344] describes a basic set of presence and instant messaging 330 use cases for federating between providers. 332 2.6. Optimizations 334 When running over wireless links, presence can be a very expensive 335 service. Notifications often get sent when the change is not really 336 relevant to the watcher. Furthermore, when a notification is sent, 337 it contains the full presence state of the watcher, rather than just 338 an indication of what changed. Optimizations have been defined to 339 address both of these cases. 341 RFC 4660, Functional Description of Event Notification Filtering 342 (S): [RFC4660] defines a mechanism that allows a watcher to include 343 filters in its subscription. These filters limit the cases in 344 which notifications are sent. It is used in conjunction with RFC 345 4661 [RFC4661] which specifies the XML format of the filters 346 themselves. The mechanism, though targeted for presence, can be 347 applied to any SIP event package. 349 RFC 4661, An Extensible Markup Language (XML)-Based Format for Event 350 Notification Filtering (S): [RFC4661] defines an XML format used 351 with the event notification filtering mechanism defined in RFC 352 4660 [RFC4660]. 354 RFC 5262, Presence Information Data format (PIDF) Extension for 355 Partial Presence (S): [RFC5262] defines a new XML format for 356 representing changes in presence documents, called a partial PIDF 357 document. This format contains an XML patch operation [RFC5261], 358 that, when applied to the previous presence document, yields the 359 new presence document. The partial PIDF document is included in 360 presence notifications when a watcher indicates that they support 361 the format. 363 RFC 5263, SIP Extension for Partial Notification of Presence 364 Information (S): [RFC5263] defines a mechanism for receiving 365 notifications that contain partial presence documents. 367 RFC 5264, Publication of Partial Presence Information (S): 368 [RFC5264] defines a mechanism for publishing presence status using 369 a partial PIDF document. 371 RFC 5261, An Extensible Markup Language (XML) Patch Operations 372 Framework Utilizing XML Path Language (XPath) Selectors (S): 373 [RFC5261] defines an XML structure for representing changes in XML 374 documents. It is a form of "diff", but specifically for XML 375 documents. It is used by several of the optimization mechanisms 376 defined for SIMPLE. 378 RFC 5112, The Presence-Specific Static Dictionary for Signaling 379 Compression (Sigcomp) (S): [RFC5112] defines a dictionary for usage 380 with Signaling Compression (Sigcomp) [RFC3320] to improve the 381 compressability of presence documents. 383 RFC 6446, Session Initiation Protocol (SIP) Event Notification 384 Extension for Notification Rate Control (S): [RFC6446] This document 385 specifies mechanisms for adjusting the rate of SIP event 386 notifications. These mechanisms can be applied in subscriptions 387 to all SIP event packages. 389 3. Instant Messaging 391 SIMPLE defines two modes of instant messaging. These are page mode 392 and session mode. In page mode, instant messages are sent by sending 393 a SIP request that contains the contents of the instant message. In 394 session mode, IM is viewed as another media type - along with audio 395 and video - and an INVITE request is used to set up a session that 396 includes IM as a media type. While page mode is more efficient for 397 one or two message conversations, session mode is more efficient for 398 longer conversations since the messages are not sent through the SIP 399 servers. Furthermore, by viewing IM as a media type, all of the 400 features available in SIP signaling - third party call control, 401 forking, and so on, are available for IM. 403 3.1. Page Mode 405 RFC 3428, Session Initiation Protocol (SIP) Extension for Instant 406 Messaging (S): [RFC3428] introduces the MESSAGE method, which can be 407 used to send an instant message through SIP signaling. 409 RFC 5365, Multiple-Recipient MESSAGE Requests in the Session 410 Initiation Protocol (SIP) (S): [RFC5365] defines a mechanism whereby 411 a client can send a single SIP MESSAGE to multiple recipients. 412 This is accomplished by including the list of recipients as an 413 object in the body, and having a network server send a copy to 414 each recipient. 416 3.2. Session Mode 418 RFC 4975, The Message Session Relay Protocol (MSRP) (S): [RFC4975] 419 defines a small text-based protocol for exchanging arbitrarily 420 sized content of any kind between users. An MSRP session is set 421 up by exchanging certain information, such as an MSRP URI, within 422 SIP and SDP signaling. 424 RFC 3862, Common Presence and Instant Messaging (CPIM): Message 425 Format (S): [RFC3862] defines a wrapper around instant message 426 content, providing meta-data such as the sender and recipient 427 identity. The CPIM format is carried in MSRP. 429 RFC 4976, Relay Extensions for the Message Sessions Relay Protocol 430 (MSRP) (S): [RFC4976] adds support for relays to MSRP. These relay 431 servers receive MSRP messages and send them towards the 432 destination. They provide support for firewall and NAT traversal, 433 and allow for features such as recording and inspection to be 434 implemented. 436 RFC 6135, An Alternative Connection Model for the Message Session 437 Relay Protocol (MSRP) (S): [RFC6135] Allows clients to negotiate 438 which endpoint in a session will establish the MSRP connection. 439 Without this specification, the client generating the SDP offer 440 would initiate the connection. 442 RFC 6714, Connection Establishment for Media Anchoring (CEMA) for the 443 Message Session Relay Protocol (MSRP) (S): [RFC6714] allows 444 middleboxes to anchor the MSRP connection, without the need for 445 middleboxes to modify the MSRP messages, and thus also enables a 446 secure end-to-end MSRP communication in networks where such 447 middleboxes are deployed. 449 3.3. IM Chat Rooms 451 In SIMPLE, IM multi-user chat, also known as chat-rooms, are provided 452 using regular SIP conferencing mechanisms. The framework for SIP 453 conferencing [RFC4353] and conference control [RFC5239] describe how 454 all SIP-based conferencing works, including joining and leaving, 455 persistent and temporary conferences, floor control and moderation, 456 and learning of conference membership, amongst other functions. All 457 that is necessary are extensions to provide features that are 458 specific to IM. 460 draft-ietf-simple-chat, Multi-party Chat Using the Message Session 461 Relay Protocol (MSRP) (S): [I-D.ietf-simple-chat] defines how MSRP 462 is used to provide support for nicknames and private chat within 463 an IM conference. 465 3.4. IM Features 467 Several specifications have been written to provide IM-specific 468 features for SIMPLE. These include "is-typing" indications, allowing 469 a user to know when their messaging peer is composing a response, and 470 delivery notifications, allowing a user to know when their IM has 471 been received. 473 RFC 3994, Indication of Message Composition for Instant Messaging 474 (S): [RFC3994] defines an XML format that can be sent in instant 475 messages that indicates the status of message composition. This 476 provides the familiar "is-typing" indication in IM systems, but 477 also supports voice, video and other message types. 479 RFC 5438, Instant Message Disposition Notification (S): [RFC5438] 480 provides delivery notifications of IM receipt. This allows a user 481 to know with certainty that a message has been received. 483 4. Security Considerations 485 This specification is an overview of existing specifications, and 486 does not introduce any security considerations on its own. 488 5. IANA Considerations 490 None. 492 6. Acknowledgements 494 Thanks to Vijay Gurbani, Barry Leiba, Stephen Hanna, and Salvatore 495 Loreto for their review and comments. 497 7. Informative References 499 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 500 A., Peterson, J., Sparks, R., Handley, M., and E. 502 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 503 June 2002. 505 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 506 July 2012. 508 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 509 Initiation Protocol (SIP)", RFC 3856, August 2004. 511 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 512 Initiation Protocol (SIP) Event Notification Extension for 513 Resource Lists", RFC 4662, August 2006. 515 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 516 for Event State Publication", RFC 3903, October 2004. 518 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 519 W., and J. Peterson, "Presence Information Data Format 520 (PIDF)", RFC 3863, August 2004. 522 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 523 July 2006. 525 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 526 Rosenberg, "RPID: Rich Presence Extensions to the Presence 527 Information Data Format (PIDF)", RFC 4480, July 2006. 529 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 530 Presence Information Data Format (PIDF) to Indicate Status 531 Information for Past and Future Time Intervals", RFC 4481, 532 July 2006. 534 [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the 535 Presence Information Data Format", RFC 4482, July 2006. 537 [RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol 538 (SIP) User Agent Capability Extension to Presence 539 Information Data Format (PIDF)", RFC 5196, September 2008. 541 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 542 Polk, J., and J. Rosenberg, "Common Policy: A Document 543 Format for Expressing Privacy Preferences", RFC 4745, 544 February 2007. 546 [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 547 December 2007. 549 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 550 Package for the Session Initiation Protocol (SIP)", 551 RFC 3857, August 2004. 553 [RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based 554 Format for Watcher Information", RFC 3858, August 2004. 556 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 557 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 559 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 560 for Representing Resource Lists", RFC 4826, May 2007. 562 [RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup 563 Language (XML) Configuration Access Protocol (XCAP) Usage 564 for Manipulating Presence Document Contents", RFC 4827, 565 May 2007. 567 [RFC5875] Urpalainen, J. and D. Willis, "An Extensible Markup 568 Language (XML) Configuration Access Protocol (XCAP) Diff 569 Event Package", RFC 5875, May 2010. 571 [RFC5874] Rosenberg, J. and J. Urpalainen, "An Extensible Markup 572 Language (XML) Document Format for Indicating a Change in 573 XML Configuration Access Protocol (XCAP) Resources", 574 RFC 5874, May 2010. 576 [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch 577 Operations Framework Utilizing XML Path Language (XPath) 578 Selectors", RFC 5261, September 2008. 580 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 581 Khartabil, "Session Initiation Protocol (SIP) Extension 582 for Partial Notification of Presence Information", 583 RFC 5263, September 2008. 585 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 586 Requena, "Functional Description of Event Notification 587 Filtering", RFC 4660, September 2006. 589 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 590 Requena, "An Extensible Markup Language (XML)-Based Format 591 for Event Notification Filtering", RFC 4661, 592 September 2006. 594 [RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 595 Partial Presence Information", RFC 5264, September 2008. 597 [RFC5262] Lonnfors, M., Leppanen, E., Khartabil, H., and J. 599 Urpalainen, "Presence Information Data Format (PIDF) 600 Extension for Partial Presence", RFC 5262, September 2008. 602 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 603 and D. Gurle, "Session Initiation Protocol (SIP) Extension 604 for Instant Messaging", RFC 3428, December 2002. 606 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 607 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 609 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 610 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 611 September 2007. 613 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 614 Session Initiation Protocol (SIP)", RFC 4353, 615 February 2006. 617 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 618 Centralized Conferencing", RFC 5239, June 2008. 620 [I-D.ietf-simple-chat] 621 Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party 622 Chat Using the Message Session Relay Protocol (MSRP)", 623 draft-ietf-simple-chat-18 (work in progress), 624 January 2013. 626 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 627 Instant Messaging", RFC 3994, January 2005. 629 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 630 Messaging (CPIM): Message Format", RFC 3862, August 2004. 632 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 633 3", BCP 9, RFC 2026, October 1996. 635 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 636 Notification (IMDN)", RFC 5438, February 2009. 638 [RFC5112] Garcia-Martin, M., "The Presence-Specific Static 639 Dictionary for Signaling Compression (Sigcomp)", RFC 5112, 640 January 2008. 642 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 643 Liu, Z., and J. Rosenberg, "Signaling Compression 644 (SigComp)", RFC 3320, January 2003. 646 [RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 647 MESSAGE Requests in the Session Initiation Protocol 648 (SIP)", RFC 5365, October 2008. 650 [RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and 651 Instant Messaging Peering Use Cases", RFC 5344, 652 October 2008. 654 [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection 655 Establishment for Media Anchoring (CEMA) for the Message 656 Session Relay Protocol (MSRP)", RFC 6714, August 2012. 658 [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 659 Request-Contained Resource Lists in the Session Initiation 660 Protocol (SIP)", RFC 5367, October 2008. 662 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 663 for the Message Session Relay Protocol (MSRP)", RFC 6135, 664 February 2011. 666 [RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 667 Protocol (SIP) Event Notification Extension for 668 Notification Rate Control", RFC 6446, January 2012. 670 Author's Address 672 Jonathan Rosenberg 673 jdrosen.net 675 Email: jdrosen@jdrosen.net 676 URI: http://www.jdrosen.net