idnits 2.17.1 draft-ietf-simple-simple-06.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 (November 19, 2010) is 4900 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-18) exists of draft-ietf-simple-chat-07 == Outdated reference: A later version (-10) exists of draft-ietf-simple-msrp-acm-09 == Outdated reference: A later version (-13) exists of draft-ietf-simple-msrp-sessmatch-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 November 19, 2010 5 Expires: May 23, 2011 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-06 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 breaks 18 them up into categories and explains what each is for and how they 19 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 May 23, 2011. 38 Copyright Notice 40 Copyright (c) 2010 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. Informative References . . . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 The IETF has produced many specifications related to Presence and 76 Instant Messaging with the Session Initiation Protocol (SIP) 77 [RFC3261]. Collectively, these specifications are known as SIMPLE - 78 SIP for Instant Messaging and Presence Leveraging Extensions. These 79 specifications cover topics ranging from protocols for subscription 80 and publication, to presence document formats, to protocols for 81 managing privacy preferences. The large number of specifications can 82 make it hard to figure out exactly what exactly SIMPLE is, what 83 specifications cover it, what functionality it provides, and how 84 these specifications relate to each other. 86 This document serves to address this problem. It provides an 87 enumeration of the protocols which make up the SIMPLE suite of 88 specifications from IETF. It categorizes them into related areas of 89 functionality, and briefly explains the purpose of each and how the 90 specifications relate to each other. Each specification also 91 includes a letter that designates its category in the standards track 92 [RFC2026]. These values are: 94 S: Standards Track (Proposed Standard, Draft Standard, or Standard) 96 E: Experimental 98 B: Best Current Practice 100 I: Informational 102 2. Presence 104 SIMPLE provides for both presence and IM capabilities. Though both 105 of these fit underneath the broad SIMPLE umbrella, they are well 106 separated from each other and are supported by different sets of 107 specifications. That is a key part of the SIMPLE story; presence is 108 much broader than just IM, and it enables communications using voice 109 and video along with IM. 111 The SIMPLE presence specifications can be broken up into: 113 o The core protocol machinery, which provides the actual SIP 114 extensions for subscriptions, notifications and publications 116 o Presence documents, which are XML documents that provide for rich 117 presence and are carried by the core protocol machinery 119 o Privacy and policy, which are documents for expressing privacy 120 preferences about how those presence documents are to be shown (or 121 not shown) to other users 123 o Provisioning, which describes how users manage their privacy 124 policies, buddy lists and other pieces of information required for 125 SIMPLE presence to work 127 o Optimizations, which are improvements in the core protocol 128 machinery that were defined to improve the performance of SIMPLE, 129 particularly on wireless links 131 2.1. Core Protocol Machinery 133 RFC 3265, SIP-Specific Event Notification (S): RFC 3265 [RFC3265] 134 defines the SUBSCRIBE and NOTIFY methods for SIP, forming the core 135 of the SIP event notification framework. To actually use the 136 framework, extensions need to be defined for specific event 137 packages. Presence is defined as an event package within this 138 framework. Packages exist for other, non-presence related 139 functions, such as message waiting indicators and dialog state 140 changes. 142 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [RFC3856] 143 defines an event package for indicating user presence through SIP. 144 Through this package, a SIP user agent can ask to be notified of 145 the presence state of a presentity (presence entity). The content 146 of the NOTIFY messages in this package are presence documents, 147 discussed in Section 2.2 149 RFC 4662, A Session Initiation Protocol (SIP) Event Notification 150 Extension for Resource Lists (S): RFC 4662 [RFC4662] defines an 151 extension to RFC 3265 that allows a client to subscribe to a list 152 of resources using a single subscription. The server, called a 153 Resource List Server (RLS) will "expand" the subscription and 154 subscribe to each individual member of the list. Its primary 155 usage with presence is to allow subscriptions to "buddy lists". 156 Without RFC 4662, a UA would need to subscribe to each presentity 157 individually. With RFC 4662, they can have a single subscription 158 to all buddies. A user can manage the entries in their buddy list 159 using the provisioning mechanisms in Section 2.4. 161 RFC 5367, Subscriptions to Request-Contained Resource Lists in the 162 Session Initiation Protocol (SIP) (S): [RFC5367] is very similar to 163 RFC 4662. It allows a client to subscribe to a list of resources 164 using a single subscription. However, with this mechanism, the 165 list is included within the body of the SUBSCRIBE request. In RFC 166 4662, it is provisioned ahead of time on the server. 168 RFC 3903, SIP Extension for Event State Publication (S): RFC 3903 169 [RFC3903] defines the PUBLISH method. With this method, a user 170 agent can publish its current state for any event package, 171 including the presence event package. Once an agent publishes its 172 presence state, the presence server would send notifications of 173 this state change using RFC 3856. 175 2.2. Presence Documents 177 Once a user has generated a subscription to presence using the core 178 protocol machinery, they will receive notifications (SIP NOTIFY 179 requests) which contain presence information. That presence 180 information is in the form of an XML presence document. Several 181 specifications have been defined to describe this document format, 182 focusing on rich, multimedia presence. 184 RFC 3863, Presence Information Data Format (S): [RFC3863] defines 185 the baseline XML format for a presence document. It defines the 186 concept of a tuple as representing a basic communication modality, 187 and defines a simple status for it (open or closed). 189 RFC 4479, A Data Model for Presence (S): [RFC4479] extends the basic 190 model in RFC 3863. It introduces the concepts of devices and 191 person status, and explains how these relate to each other. It 192 describes how presence documents are used to represent states in 193 communications systems in a consistent fashion. More than RFC 194 3863, it defines what a presence document is and what it means. 196 RFC 4480, RPID: Rich Presence Extensions to PIDF (S): [RFC4480] adds 197 many more attributes to the presence document schema, building 198 upon the model in RFC 4479. It allows for indications of 199 activities, moods, places and place types, icons, and indications 200 of whether a user is idle or not. 202 RFC 4481, Timed Presence Extensions to the Presence Information Data 203 Format (PIDF) to Indicate Status Information for Past and Future Time 204 Intervals (S): [RFC4481] adds additional attributes to the presence 205 document schema, again building upon the model in RFC 4479. It 206 allows documents to indicate status for the future or the past. 207 For example, a user can indicate that they will be unavailable for 208 voice communications from 2pm to 3pm, due to a meeting. 210 RFC 4482, CIPID: Contact Information for the Presence Information 211 Data Format (S): [RFC4482] adds attributes to the presence document 212 schema for contact information, such as a vCard, display name, 213 homepage, icon, or sound (such as the pronunciation of their 214 name). 216 RFC 5196, Session Initiation Protocol (SIP) User Agent Capability 217 Extension to Presence Information Data Format (PIDF) (S): [RFC5196] 218 adds even more attributes to the presence document schema, this 219 time to allow indication of capabilities for the user agent. For 220 example, the extensions can indicate whether a UA supports audio 221 and video, what SIP methods it supports, and so on. 223 2.3. Privacy and Policy 225 The rich presence capabilities defined by the specifications in 226 Section 2.2 introduces a strong need for privacy preferences. Users 227 must be able to approve or deny subscriptions to their presence, and 228 indicate what information such watchers can see. In SIMPLE, this is 229 accomplished through policy documents, uploaded to the presence 230 server using the provisioning mechanisms in Section 2.4. 232 RFC 4745, Common Policy: A Document Format for Expressing Privacy 233 Preferences (S): [RFC4745] defines a general XML framework for 234 expressing privacy preferences for both geolocation information 235 and presence information. It introduces the concepts of 236 conditions, actions and transformations that are applied to 237 privacy-sensitive data. The common policy framework provides 238 privacy-safety, a property by which network error or version 239 incompatibilities can never cause more information to be revealed 240 to a watcher than the user would otherwise desire. 242 RFC 5025, Presence Authorization Rules (S): [RFC5025] uses the 243 framework of RFC 4745 to define a policy document format for 244 describing presence privacy policies. Besides basic yes/no 245 approvals, this format allows a user to control what kind of 246 information a watcher is allowed to see. 248 RFC 3857, A Watcher Information Event Template Package for SIP (S): 249 [RFC3857], also known as watcherinfo, provides a mechanism for a 250 user agent to find out what subscriptions are in place for a 251 particular event package. Though it was defined to be used for 252 any event package, it has particular applicability for presence. 253 It is used to provide reactive authorization. With reactive 254 authorization, a user gets alerted if someone tries to subscribe 255 to their presence, so that they may provide an authorization 256 decision. Watcherinfo is used to provide the alert that someone 257 has subscribed to a user's presence. 259 RFC 3858, An Extensible Markup Language (XML) Based Format for 260 Watcher Information (S): [RFC3858] is the companion to RFC 3857. It 261 specifies the XML format of watcherinfo that is carried in 262 notifications for the event template package in RFC 3857. 264 2.4. Provisioning 266 Proper operation of a SIMPLE presence system requires that several 267 pieces of data are correctly managed by the users and provisioned 268 into the system. These include buddy lists (used by the resource 269 list subscription mechanism in RFC 4662) and privacy policies (such 270 as those described by the XML format in [RFC5025]). 272 In SIMPLE, management of this data is handled by the XML 273 Configuration Access Protocol (XCAP) [RFC4825]. XCAP is used by the 274 user agent to manipulate buddy lists, privacy policy, and other data 275 that is represented by XML documents stored on a server. 277 RFC 4825, The Extensible Markup Language (XML) Configuration Access 278 Protocol (XCAP) (S): [RFC4825] specifies XCAP. XCAP is a usage of 279 HTTP that allows a user agent to manipulate the contents of XML 280 documents stored on a server. It can be used to manipulate any 281 kind of XML, and the protocol itself is independent of the 282 particular schema of the data it is modifying. XML schemas have 283 been defined for buddy lists, privacy policies and offline 284 presence status, allowing all of those to be managed by a user 285 with XCAP. 287 RFC 5875, An Extensible Markup Language (XML) Configuration Access 288 Protocol (XCAP) Diff Event Package (S): [RFC5875] defines an 289 extension to the SIP user agent configuration profile, allowing a 290 user agent to learn about changes in its documents on an XCAP 291 server. With this mechanism, there can be a change made by 292 someone else to a buddy list or privacy policy document, and a UA 293 will find out that a new version is available. 295 RFC 5874, An Extensible Markup Language (XML) Document Format for 296 Indicating A Change in XML Configuration Access Protocol (XCAP) 297 Resources (S): [RFC5874] defines an XML format for indicating 298 changes in XCAP documents. It makes use of an XML diff format 299 defined in [RFC5261]. It is used in conjunction with [RFC5875] to 300 alert a user agent of changes made by someone else to their 301 provisioned data. 303 RFC 4826, XML Formats for Representing Resource Lists (S): [RFC4826] 304 defines two XML document formats used to represent buddy lists. 305 One is simply a list of users (or more generally, resources), and 306 the other defines a buddy list whose membership is composed of a 307 list of users or resources. These lists can be manipulated by 308 XCAP, allowing a user to add or remove members from their buddy 309 lists. The buddy list is also accessed by the resource list 310 server specified in RFC 4662 for processing resource list 311 subscriptions. 313 RFC 4827, An Extensible Markup Language (XML) Configuration Access 314 Protocol (XCAP) Usage for Manipulating Presence Document Contents 315 (S): [RFC4827] defines an XCAP usage that allows a user to store an 316 "offline" presence document. This is a presence status that is 317 used by a presence server when there are no presence documents 318 published for that user by any user agents currently running. 320 2.5. Federation 322 Federation refers to the interconnection of different presence and 323 instant messaging systems for the purposes of communications. 324 Federation can be between domains or within a domain. A document has 325 been developed which describes how presence and IM federation works. 327 RFC 5344, Presence & Instant Messaging Peering Use Cases (I): 328 [RFC5344] describes a basic set of presence and instant messaging 329 use cases for federating between providers. 331 2.6. Optimizations 333 When running over wireless links, presence can be a very expensive 334 service. Notifications often get sent when the change is not really 335 relevant to the watcher. Furthermore, when a notification is sent, 336 it contains the full presence state of the watcher, rather than just 337 an indication of what changed. Optimizations have been defined to 338 address both of these cases. 340 RFC 4660, Functional Description of Event Notification Filtering 341 (S): [RFC4660] defines a mechanism that allows a watcher to include 342 filters in its subscription. These filters limit the cases in 343 which notifications are sent. It is used in conjunction with RFC 344 4661 [RFC4661] which specifies the XML format of the filters 345 themselves. The mechanism, though targeted for presence, can be 346 applied to any SIP event package. 348 RFC 4661, An Extensible Markup Language (XML)-Based Format for Event 349 Notification Filtering (S): [RFC4661] defines an XML format used 350 with the event notification filtering mechanism defined in RFC 351 4660 [RFC4660]. 353 RFC 5262, Presence Information Data format (PIDF) Extension for 354 Partial Presence (S): [RFC5262] defines a new XML format for 355 representing changes in presence documents, called a partial PIDF 356 document. This format contains an XML patch operation [RFC5261], 357 that, when applied to the previous presence document, yields the 358 new presence document. The partial PIDF document is included in 359 presence notifications when a watcher indicates that they support 360 the format. 362 RFC 5263, SIP Extension for Partial Notification of Presence 363 Information (S): [RFC5263] defines a mechanism for receiving 364 notifications that contain partial presence documents. 366 RFC 5264, Publication of Partial Presence Information (S): 367 [RFC5264] defines a mechanism for publishing presence status using 368 a partial PIDF document. 370 RFC 5261, An Extensible Markup Language (XML) Patch Operations 371 Framework Utilizing XML Path Language (XPath) Selectors (S): 372 [RFC5261] defines an XML structure for representing changes in XML 373 documents. It is a form of "diff", but specifically for XML 374 documents. It is used by several of the optimization mechanisms 375 defined for SIMPLE. 377 RFC 5112, The Presence-Specific Static Dictionary for Signaling 378 Compression (Sigcomp) (S): [RFC5112] defines a dictionary for usage 379 with Signaling Compression (Sigcomp) [RFC3320] to improve the 380 compressability of presence documents. 382 3. Instant Messaging 384 SIMPLE defines two modes of instant messaging. These are page mode 385 and session mode. In page mode, instant messages are sent by sending 386 a SIP request that contains the contents of the instant message. In 387 session mode, IM is viewed as another media type - along with audio 388 and video - and an INVITE request is used to set up a session that 389 includes IM as a media type. While page mode is more efficient for 390 one or two message conversations, session mode is more efficient for 391 longer conversations since the messages are not sent through the SIP 392 servers. Furthermore, by viewing IM as a media type, all of the 393 features available in SIP signaling - third party call control, 394 forking, and so on, are available for IM. 396 3.1. Page Mode 398 RFC 3428, Session Initiation Protocol (SIP) Extension for Instant 399 Messaging (S): [RFC3428] introduces the MESSAGE method, which can be 400 used to send an instant message through SIP signaling. 402 RFC 5365, Multiple-Recipient MESSAGE Requests in the Session 403 Initiation Protocol (SIP) (S): [RFC5365] defines a mechanism whereby 404 a client can send a single SIP MESSAGE to multiple recipients. 405 This is accomplished by including the list of recipients as an 406 object in the body, and having a network server send a copy to 407 each recipient. 409 3.2. Session Mode 411 RFC 4975, The Message Session Relay Protocol (MSRP) (S): [RFC4975] 412 defines a small text-based protocol for exchanging arbitrarily 413 sized content of any time between users. An MSRP session is set 414 up by exchanging certain information, such as an MSRP URI, within 415 SIP and SDP signaling. 417 RFC 3862, Common Presence and Instant Messaging (CPIM): Message 418 Format (S): [RFC3862] defines a wrapper around instant message 419 content, providing meta-data such as the sender and recipient 420 identity. The CPIM format is carried in MSRP. 422 RFC 4976, Relay Extensions for the Message Sessions Relay Protocol 423 (MSRP) (S): [RFC4976] adds support for relays to MSRP. These relay 424 servers receive MSRP messages and send them towards the 425 destination. They provide support for firewall and NAT traversal, 426 and allow for features such as recording and inspection to be 427 implemented. 429 draft-ietf-simple-msrp-acm, An Alternative Connection Model for the 430 Message Session Relay Protocol (MSRP) (S): 431 [I-D.ietf-simple-msrp-acm] defines an alternate method for 432 establishing MSRP connections. This alternative method allows for 433 the usage of ALGs, SBCs, and other SIP-based traversal mechanisms, 434 such as ICE and TURN, to be applied to MSRP, instead of using MSRP 435 relays as defined in RFC 4976. 437 draft-ietf-simple-msrp-sessmatch, Session Matching Update for the 438 Message Session Relay Protocol (MSRP)(S): 439 [I-D.ietf-simple-msrp-sessmatch] defines an alternate method for 440 mapping MRSP messages to sessions in a way which works in the 441 presence of application layer gateways (ALGs) which modify SDP 442 contents - often known as Session Border Controllers (SBCs). 444 3.3. IM Chat Rooms 446 In SIMPLE, IM multi-user chat, also known as chat-rooms, are provided 447 using regular SIP conferencing mechanisms. The framework for SIP 448 conferencing [RFC4353] and conference control [RFC5239] describe how 449 all SIP-based conferencing works, including joining and leaving, 450 persistent and temporary conferences, floor control and moderation, 451 and learning of conference membership, amongst other functions. All 452 that is necessary are extensions to provide features that are 453 specific to IM. 455 draft-ietf-simple-chat, Multi-party Instant Message (IM) Sessions 456 the Message Session Relay Protocol (MSRP) (S): 457 [I-D.ietf-simple-chat] defines how MSRP is used to provide support 458 for nicknames and private chat within an IM conference. 460 3.4. IM Features 462 Several specifications have been written to provide IM-specific 463 features for SIMPLE. These include "is-typing" indications, allowing 464 a user to know when their messaging peer is composing a response, and 465 delivery notifications, allowing a user to know when their IM has 466 been received. 468 RFC 3994, Indication of Message Composition for Instant Messaging 469 (S): [RFC3994] defines an XML format that can be sent in instant 470 messages that indicates the status of message composition. This 471 provides the familiar "is-typing" indication in IM systems, but 472 also supports voice, video and other message types. 474 RFC 5438, Instant Message Disposition Notification (S): [RFC5438] 475 provides delivery notifications of IM receipt. This allows a user 476 to know with certainty that a message has been received. 478 4. Security Considerations 480 This specification is an overview of existing specifications, and 481 does not introduce any security considerations on its own. 483 5. IANA Considerations 485 None. 487 6. Informative References 489 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 490 A., Peterson, J., Sparks, R., Handley, M., and E. 491 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 492 June 2002. 494 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 495 Event Notification", RFC 3265, June 2002. 497 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 498 Initiation Protocol (SIP)", RFC 3856, August 2004. 500 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 501 Initiation Protocol (SIP) Event Notification Extension for 502 Resource Lists", RFC 4662, August 2006. 504 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 505 for Event State Publication", RFC 3903, October 2004. 507 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 508 W., and J. Peterson, "Presence Information Data Format 509 (PIDF)", RFC 3863, August 2004. 511 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 512 July 2006. 514 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 515 Rosenberg, "RPID: Rich Presence Extensions to the Presence 516 Information Data Format (PIDF)", RFC 4480, July 2006. 518 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 519 Presence Information Data Format (PIDF) to Indicate Status 520 Information for Past and Future Time Intervals", RFC 4481, 521 July 2006. 523 [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the 524 Presence Information Data Format", RFC 4482, July 2006. 526 [RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol 527 (SIP) User Agent Capability Extension to Presence 528 Information Data Format (PIDF)", RFC 5196, September 2008. 530 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 531 Polk, J., and J. Rosenberg, "Common Policy: A Document 532 Format for Expressing Privacy Preferences", RFC 4745, 533 February 2007. 535 [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 536 December 2007. 538 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 539 Package for the Session Initiation Protocol (SIP)", 540 RFC 3857, August 2004. 542 [RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based 543 Format for Watcher Information", RFC 3858, August 2004. 545 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 546 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 548 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats 549 for Representing Resource Lists", RFC 4826, May 2007. 551 [RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup 552 Language (XML) Configuration Access Protocol (XCAP) Usage 553 for Manipulating Presence Document Contents", RFC 4827, 554 May 2007. 556 [RFC5875] Urpalainen, J. and D. Willis, "An Extensible Markup 557 Language (XML) Configuration Access Protocol (XCAP) Diff 558 Event Package", RFC 5875, May 2010. 560 [RFC5874] Rosenberg, J. and J. Urpalainen, "An Extensible Markup 561 Language (XML) Document Format for Indicating a Change in 562 XML Configuration Access Protocol (XCAP) Resources", 563 RFC 5874, May 2010. 565 [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch 566 Operations Framework Utilizing XML Path Language (XPath) 567 Selectors", RFC 5261, September 2008. 569 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 570 Khartabil, "Session Initiation Protocol (SIP) Extension 571 for Partial Notification of Presence Information", 572 RFC 5263, September 2008. 574 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 575 Requena, "Functional Description of Event Notification 576 Filtering", RFC 4660, September 2006. 578 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 579 Requena, "An Extensible Markup Language (XML)-Based Format 580 for Event Notification Filtering", RFC 4661, 581 September 2006. 583 [RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 584 Partial Presence Information", RFC 5264, September 2008. 586 [RFC5262] Lonnfors, M., Leppanen, E., Khartabil, H., and J. 587 Urpalainen, "Presence Information Data Format (PIDF) 588 Extension for Partial Presence", RFC 5262, September 2008. 590 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 591 and D. Gurle, "Session Initiation Protocol (SIP) Extension 592 for Instant Messaging", RFC 3428, December 2002. 594 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 595 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 597 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 598 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 599 September 2007. 601 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 602 Session Initiation Protocol (SIP)", RFC 4353, 603 February 2006. 605 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 606 Centralized Conferencing", RFC 5239, June 2008. 608 [I-D.ietf-simple-chat] 609 Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party 610 Chat Using the Message Session Relay Protocol (MSRP)", 611 draft-ietf-simple-chat-07 (work in progress), May 2010. 613 [RFC3994] Schulzrinne, H., "Indication of Message Composition for 614 Instant Messaging", RFC 3994, January 2005. 616 [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant 617 Messaging (CPIM): Message Format", RFC 3862, August 2004. 619 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 620 3", BCP 9, RFC 2026, October 1996. 622 [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition 623 Notification (IMDN)", RFC 5438, February 2009. 625 [RFC5112] Garcia-Martin, M., "The Presence-Specific Static 626 Dictionary for Signaling Compression (Sigcomp)", RFC 5112, 627 January 2008. 629 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 630 Liu, Z., and J. Rosenberg, "Signaling Compression 631 (SigComp)", RFC 3320, January 2003. 633 [RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient 634 MESSAGE Requests in the Session Initiation Protocol 635 (SIP)", RFC 5365, October 2008. 637 [RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and 638 Instant Messaging Peering Use Cases", RFC 5344, 639 October 2008. 641 [I-D.ietf-simple-msrp-acm] 642 Holmberg, C. and S. Blau, "An Alternative Connection Model 643 for the Message Session Relay Protocol (MSRP)", 644 draft-ietf-simple-msrp-acm-09 (work in progress), 645 June 2010. 647 [I-D.ietf-simple-msrp-sessmatch] 648 Holmberg, C. and S. Blau, "Session Matching Update for the 649 Message Session Relay Protocol (MSRP)", 650 draft-ietf-simple-msrp-sessmatch-08 (work in progress), 651 November 2010. 653 [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 654 Request-Contained Resource Lists in the Session Initiation 655 Protocol (SIP)", RFC 5367, October 2008. 657 Author's Address 659 Jonathan Rosenberg 660 jdrosen.net 661 Monmouth, NJ 662 US 664 Email: jdrosen@jdrosen.net 665 URI: http://www.jdrosen.net