idnits 2.17.00 (12 Aug 2021) /tmp/idnits49971/draft-rosenberg-simple-simple-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 622. 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 Copyright Line does not match the current year == Line 511 has weird spacing: '... Change in XM...' -- 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 23, 2007) is 5445 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: draft-ietf-simple-prescaps-ext has been published as RFC 5196 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 == Outdated reference: draft-ietf-simple-xcap-diff has been published as RFC 5874 == Outdated reference: draft-ietf-simple-xml-patch-ops has been published as RFC 5261 == Outdated reference: draft-ietf-simple-partial-publish has been published as RFC 5264 == Outdated reference: draft-ietf-simple-partial-pidf-format has been published as RFC 5262 == Outdated reference: draft-ietf-simple-message-sessions has been published as RFC 4975 == Outdated reference: draft-ietf-simple-msrp-relays has been published as RFC 4976 == Outdated reference: draft-ietf-xcon-framework has been published as RFC 5239 == Outdated reference: draft-ietf-simple-chat has been published as RFC 7701 == Outdated reference: draft-ietf-simple-imdn has been published as RFC 5438 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Informational June 23, 2007 5 Expires: December 25, 2007 7 SIMPLE made Simple: An Overview of the IETF Specifications for Instant 8 Messaging and Presence using the Session Initiation Protocol (SIP) 9 draft-rosenberg-simple-simple-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 25, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The IETF has produced many specifications related to Presence and 43 Instant Messaging with the Session Initiation Protocol (SIP). 44 Collectively, these specifications are known as SIMPLE - SIP for 45 Instant Messaging and Presence Leveraging Extensions. This document 46 serves as a guide to the SIMPLE suite of specifications. It breaks 47 them up into categories and explains what each is for and how they 48 relate to each other. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Core Protocol Machinery . . . . . . . . . . . . . . . . . 4 55 2.2. Presence Documents . . . . . . . . . . . . . . . . . . . . 5 56 2.3. Privacy and Policy . . . . . . . . . . . . . . . . . . . . 6 57 2.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.5. Optimizations . . . . . . . . . . . . . . . . . . . . . . 8 59 3. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. Page Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2. Session Mode . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3. IM Chat Rooms . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. IM Features . . . . . . . . . . . . . . . . . . . . . . . 10 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. Informative References . . . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 Intellectual Property and Copyright Statements . . . . . . . . . . 14 70 1. Introduction 72 The IETF has produced many specifications related to Presence and 73 Instant Messaging with the Session Initiation Protocol (SIP) [1]. 74 Collectively, these specifications are known as SIMPLE - SIP for 75 Instant Messaging and Presence Leveraging Extensions. These 76 specifications cover topics ranging from protocols for subscription 77 and publication, to presence document formats, to protocols for 78 managing privacy preferences. The large number of specifications can 79 make it hard to figure out exactly what exactly SIMPLE is, what 80 specifications cover it, what functionality it provides, and how 81 these specifications relate to each other. 83 This document serves to address this problem. It provides an 84 enumeration of the protocols which make up the SIMPLE suite of 85 specifications from IETF. It categorizes them into related areas of 86 functionality, and briefly explains the purpose of each and how the 87 specifications relate to each other. Each specification also 88 includes a letter that designates its category in the standards track 89 [34]. These values are: 91 S: Standards Track (Proposed Standard, Draft Standard, or Standard) 93 E: Experimental 95 B: Best Current Practice 97 I: Informational 99 2. Presence 101 SIMPLE provides for both presence and IM capabilities. Though both 102 of these fit underneath the broad SIMPLE umbrella, they are well 103 separated from each other and are supported by different sets of 104 specifications. That is a key part of the SIMPLE story; presence is 105 much broader than just IM, and it enables communications using voice 106 and video along with IM. 108 The SIMPLE presence specifications can be broken up into: 110 o The core protocol machinery, which provides the actual SIP 111 extensions for subscriptions, notifications and publications 113 o Presence documents, which are XML documents that provide for rich 114 presence and are carried by the core protocol machinery 116 o Privacy and policy, which are documents for expressing privacy 117 preferences about how those presence documents are to be shown (or 118 not shown) to other users 120 o Provisioning, which describes how users manage their privacy 121 policies, buddy lists and other pieces of information required for 122 SIMPLE presence to work 124 o Optimizations, which are improvements in the core protocol 125 machinery that were defined to improve the performance of SIMPLE, 126 particularly on wireless links 128 2.1. Core Protocol Machinery 130 RFC 3265, SIP-Specific Event Notification (S): RFC 3265 [2] defines 131 the SUBSCRIBE and NOTIFY methods for SIP, forming the core of the 132 SIP event notification framework. To actually use the framework, 133 extensions need to be defined for specific event packages. 134 Presence is defined as an event package within this framework. 135 Packages exist for other, non-presence related functions, such as 136 message waiting indicators and dialog state changes. 138 RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [3] defines 139 an event package for indicating user presence through SIP. 140 Through this package, a SIP user agent can ask to be notified of 141 the presence state of a presentity (presence entity). The content 142 of the NOTIFY messages in this package are presence documents, 143 discussed in Section 2.2 145 RFC 4662, A Session Initiation Protocol (SIP) Event Notification 146 Extension for Resource Lists (S): RFC 4662 [4] defines an extension 147 to RFC 3265 that allows a client to subscribe to a list of 148 resources using a single subscription. The server, called a 149 Resource List Server (RLS) will "expand" the subscription and 150 subscribe to each individual member of the list. Its primary 151 usage with presence is to allow subscriptions to "buddy lists". 152 Without RFC 4662, a UA would need to subscribe to each presentity 153 individually. With RFC 4662, they can have a single subscription 154 to all buddies. A user can manage the entries in their buddy list 155 using the provisioning mechanisms in Section 2.4. 157 RFC 3903, SIP Extension for Event State Publication (S): RFC 3903 158 [5] defines the PUBLISH method. With this method, a user agent 159 can publish its current state for any event package, including the 160 presence event package. Once an agent publishes its presence 161 state, the presence server would send notifications of this state 162 change using RFC 3856. 164 2.2. Presence Documents 166 Once a user has generated a subscription to presence using the core 167 protocol machinery, they will receive notifications (SIP NOTIFY 168 requests) which contain presence information. That presence 169 information is in the form of an XML presence document. Several 170 specifications have been defined to describe this document format, 171 focusing on rich, multimedia presence. 173 RFC 3863, Presence Information Data Format (S): RFC 3863 [6] defines 174 the baseline XML format for a presence document. It defines the 175 concept of a tuple as representing a basic communication modality, 176 and defines a simple status for it (open or closed). 178 RFC 4779, A Data Model for Presence (S): RFC 4779 [7] extends the 179 basic model in RFC 3863. It introduces the concepts of devices 180 and person status, and explains how these relate to each other. 181 It describes how presence documents are used to represent states 182 in communications systems in a consistent fashion. More than RFC 183 3863, it defines what a presence document is and what it means. 185 RFC 4480, RPID: Rich Presence Extensions to PIDF (S): RFC 4480 [8] 186 adds many more attributes to the presence document schema, 187 building upon the model in RFC 4779. It allows for indications of 188 activities, moods, places and place types, icons, and indications 189 of whether a user is idle or not. 191 RFC 4481, Timed Presence Extensions to the Presence Information Data 192 Format (PIDF) to Indicate Status Information for Past and Future Time 193 Intervals (S): RFC 4481 [9] adds additional attributes to the 194 presence document schema, again building upon the model in RFC 195 4779. It allows documents to indicate status for the future or 196 the past. For example, a user can indicate that they will be 197 unavailable for voice communications from 2pm to 3pm, due to a 198 meeting. 200 RFC 4482, CIPID: Contact Information for the Presence Information 201 Data Format (S): RFC 4482 [10] adds attributes to the presence 202 document schema for contact information, such as a vCard, display 203 name, homepage, icon, or sound (such as the pronunciation of their 204 name). 206 RFC XXXX, Session Initiation Protocol (SIP) User Agent Capability 207 Extension to Presence Information Data Format (PIDF) (S): RFC XXXX 208 [11] adds even more attributes to the presence document schema, 209 this time to allow indication of capabilities for the user agent. 210 For example, the extensions can indicate whether a UA supports 211 audio and video, what SIP methods it supports, and so on. 213 2.3. Privacy and Policy 215 The rich presence capabilities defined by the specifications in 216 Section 2.2 introduces a strong need for privacy preferences. Users 217 must be able to approve or deny subscriptions to their presence, and 218 indicate what information such watchers can see. In SIMPLE, this is 219 accomplished through policy documents, uploaded to the presence 220 server using the provisioning mechanisms in Section 2.4. 222 RFC 4745, Common Policy: A Document Format for Expressing Privacy 223 Preferences (S): RFC 4745 [12] defines a general XML framework for 224 expressing privacy preferences for both geolocation information 225 and presence information. It introduces the concepts of 226 conditions, actions and transformations that are applied to 227 privacy-sensitive data. The common policy framework provides 228 privacy-safety, a property by which network error or version 229 incompatibilities can never cause more information to be revealed 230 to a watcher than the user would otherwise desire. 232 RFC XXXX, Presence Authorization Rules (S): RFC XXXX [13] uses the 233 framework of RFC 4745 to define a policy document format for 234 describing presence privacy policies. Besides basic yes/no 235 approvals, this format allows a user to control what kind of 236 information a watcher is allowed to see. 238 RFC 3857, A Watcher Information Event Template Package for SIP (S): 239 RFC 3857 [14], also known as watcherinfo, provides a mechanism for 240 a user agent to find out what subscriptions are in place for a 241 particular event package. Though it was defined to be used for 242 any event package, it has particular applicability for presence. 243 It is used to provide reactive authorization. With reactive 244 authorization, a user gets alerted if someone tries to subscribe 245 to their presence, so that they may provide an authorization 246 decision. Watcherinfo is used to provide the alert that someone 247 has subscribed to a user's presence. 249 RFC 3858, An Extensible Markup Language (XML) Based Format for 250 Watcher Information (S): RFC 3858 [15] is the companion to RFC 3857. 251 It specifies the XML format of watcherinfo that is carried in 252 notifications for the event template package in RFC 3857. 254 2.4. Provisioning 256 Proper operation of a SIMPLE presence system requires that several 257 pieces of data are correctly managed by the users and provisioned 258 into the system. These include buddy lists (used by the resource 259 list subscription mechanism in RFC 4662) and privacy policies (such 260 as those described by the XML format in [13]). 262 In SIMPLE, management of this data is handled by the XML 263 Configuration Access Protocol (XCAP) [16]. XCAP is used by the user 264 agent to manipulate buddy lists, privacy policy, and other data that 265 is represented by XML documents stored on a server. 267 RFC 4825, The Extensible Markup Language (XML) Configuration Access 268 Protocol (XCAP) (S): RFC4825 [16] specifies XCAP. XCAP is a usage 269 of HTTP that allows a user agent to manipulate the contents of XML 270 documents stored on a server. It can be used to manipulate any 271 kind of XML, and the protocol itself is independent of the 272 particular schema of the data it is modifying. XML schemas have 273 been defined for buddy lists, privacy policies and offline 274 presence status, allowing all of those to be managed by a user 275 with XCAP. 277 RFC XXXX, Extensions to the Session Initiation Protocol (SIP) User 278 Agent Profile Delivery Change Notification Event Package for the 279 Extensible Markup Language Language Configuration Access Protocol 280 (XCAP) (S): RFC XXXX [19] defines an extension to the SIP user agent 281 configuration profile, allowing a user agent to learn about 282 changes in its documents on an XCAP server. With this mechanism, 283 there can be a change made by someone else to a buddy list or 284 privacy policy document, and a UA will find out that a new version 285 is available. 287 RFC XXXX, An Extensible Markup Language (XML) Document Format for 288 Indicating A Change in XML Configuration Access Protocol (XCAP) 289 Resources (S): RFC XXXX [20] defines an XML format for indicating 290 changes in XCAP documents. It makes use of an XML diff format 291 defined in [21]. It is used in conjunction with [19] to alert a 292 user agent of changes made by someone else to their provisioned 293 data. 295 RFC 4826, XML Formats for Representing Resource Lists (S): RFC 4826 296 [17] defines two XML document formats used to represent buddy 297 lists. One is simply a list of users (or more generally, 298 resources), and the other defines a buddy list whose membership is 299 composed of a list of users or resources. These lists can be 300 manipulated by XCAP, allowing a user to add or remove members from 301 their buddy lists. The buddy list is also accessed by the 302 resource list server specified in RFC 4662 for processing resource 303 list subscriptions. 305 RFC 4827, An Extensible Markup Language (XML) Configuration Access 306 Protocol (XCAP) Usage for Manipulating Presence Document Contents 307 (S): RFC 4827 [18] defines an XCAP usage that allows a user to store 308 an "offline" presence document. This is a presence status that is 309 used by a presence server when there are no presence documents 310 published for that user by any user agents currently running. 312 2.5. Optimizations 314 When running over wireless links, presence can be a very expensive 315 service. Notifications often get sent when the change is not really 316 relevant to the watcher. Furthermore, when a notification is sent, 317 it contains the full presence state of the watcher, rather than just 318 an indication of what changed. Optimizations have been defined to 319 address both of these cases. 321 RFC 4660, Functional Description of Event Notification Filtering 322 (S): RFC 4660 [22] defines a mechanism that allows a watcher to 323 include filters in its subscription. These filters limit the 324 cases in which notifications are sent. It is used in conjunction 325 with RFC 4661 [23] which specifies the XML format of the filters 326 themselves. The mechanism, though targeted for presence, can be 327 applied to any SIP event package. 329 RFC 4661, An Extensible Markup Language (XML)-Based Format for Event 330 Notification Filtering (S): RFC 4661 [23] defines an XML format used 331 with the event notification filtering mechanism defined in RFC 332 4660 [22]. 334 RFC XXXX, Presence Information Data format (PIDF) Extension for 335 Partial Presence (S): [25] defines a new XML format for representing 336 changes in presence documents, called a partial PIDF document. 337 This format contains an XML patch operation [21], that, when 338 applied to the previous presence document, yields the new presence 339 document. The partial PIDF document is included in presence 340 notifications when a watcher indicates that they support the 341 format. 343 RFC XXXX, Publication of Partial Presence Information (S): RFC XXXX 344 [24] defines a mechanism for publishing presence status using a 345 partial PIDF document. 347 RFC XXXX, An Extensible Markup Language (XML) Patch Operations 348 Framework Utilizing XML Path Language (XPath) Selectors (S): RFC 349 XXXX [21] defines an XML structure for representing changes in XML 350 documents. It is a form of "diff", but specifically for XML 351 documents. It is used by several of the optimization mechanisms 352 defined for SIMPLE. 354 3. Instant Messaging 356 SIMPLE defines two modes of instant messaging. These are page mode 357 and session mode. In page mode, instant messages are sent by sending 358 a SIP request that contains the contents of the instant message. In 359 session mode, IM is viewed as another media type - along with audio 360 and video - and an INVITE request is used to set up a session that 361 includes IM as a media type. While page mode is more efficient for 362 one or two message conversations, session mode is more efficient for 363 longer conversations since the messages are not sent through the SIP 364 servers. Furthermore, by viewing IM as a media type, all of the 365 features available in SIP signaling - third party call control, 366 forking, and so on, are available for IM. 368 3.1. Page Mode 370 RFC 3428, Session Initiation Protocol (SIP) Extension for Instant 371 Messaging (S): RFC 3428 [26] introduces the MESSAGE method, which 372 can be used to send an instant message through SIP signaling. 374 3.2. Session Mode 376 RFC XXXX, The Message Session Relay Protocol (MSRP) (S): RFC XXXX 377 [27] defines a small text-based protocol for exchanging 378 arbitrarily sized content of any time between users. An MSRP 379 session is set up by exchanging certain information, such as an 380 MSRP URI, within SIP and SDP signaling. 382 RFC 3862, Common Presence and Instant Messaging (CPIM): Message 383 Format (S): RFC 3862 [33] defines a wrapper around instant message 384 content, providing meta-data such as the sender and recipient 385 identity. The CPIM format is carried in MSRP. 387 RFC XXXX, Relay Extensions for the Message Sessions Relay Protocol 388 (MSRP) (S): RFC XXXX [28] adds support for relays to MSRP. These 389 relay servers receive MSRP messages and send them towards the 390 destination. They provide support for firewall and NAT traversal, 391 and allow for features such as recording and inspection to be 392 implemented. 394 3.3. IM Chat Rooms 396 In SIMPLE, IM multi-user chat, also known as chat-rooms, are provided 397 using regular SIP conferencing mechanisms. The framework for SIP 398 conferencing [29] and conference control [30] describe how all SIP- 399 based conferencing works, including joining and leaving, persistent 400 and temporary conferences, floor control and moderation, and learning 401 of conference membership, amongst other functions. All that is 402 necessary are extensions to provide features that are specific to IM. 404 RFC XXXX, Multi-party Instant Message (IM) Sessions Using the Message 405 Session Relay Protocol (MSRP) (S): RFC XXXX [31] defines how MSRP is 406 used to provide support for nicknames and private chat within an 407 IM conference. 409 3.4. IM Features 411 Several specifications have been written to provide IM-specific 412 features for SIMPLE. These include "is-typing" indications, allowing 413 a user to know when their messaging peer is composing a response, and 414 delivery notifications, allowing a user to know when their IM has 415 been received. 417 RFC 3994, Indication of Message Composition for Instant Messaging 418 (S): RFC 3994 [32] defines an XML format that can be sent in instant 419 messages that indicates the status of message composition. This 420 provides the familiar "is-typing" indication in IM systems, but 421 also supports voice, video and other message types. 423 RFC XXXX, Instant Message Disposition Notification (S): RFC XXXX 424 [35] provides delivery notifications of IM receipt. This allows a 425 user to know with certainty that a message has been received. 427 4. Security Considerations 429 This specification is an overview of existing specifications, and 430 does not introduce any security considerations on its own. 432 5. IANA Considerations 434 None. 436 6. Informative References 438 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 439 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 440 Session Initiation Protocol", RFC 3261, June 2002. 442 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 443 Notification", RFC 3265, June 2002. 445 [3] Rosenberg, J., "A Presence Event Package for the Session 446 Initiation Protocol (SIP)", RFC 3856, August 2004. 448 [4] Roach, A., Campbell, B., and J. Rosenberg, "A Session 449 Initiation Protocol (SIP) Event Notification Extension for 450 Resource Lists", RFC 4662, August 2006. 452 [5] Niemi, A., "Session Initiation Protocol (SIP) Extension for 453 Event State Publication", RFC 3903, October 2004. 455 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 456 J. Peterson, "Presence Information Data Format (PIDF)", 457 RFC 3863, August 2004. 459 [7] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and J. 460 Palet, "ISP IPv6 Deployment Scenarios in Broadband Access 461 Networks", RFC 4779, January 2007. 463 [8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, 464 "RPID: Rich Presence Extensions to the Presence Information 465 Data Format (PIDF)", RFC 4480, July 2006. 467 [9] Schulzrinne, H., "Timed Presence Extensions to the Presence 468 Information Data Format (PIDF) to Indicate Status Information 469 for Past and Future Time Intervals", RFC 4481, July 2006. 471 [10] Schulzrinne, H., "CIPID: Contact Information for the Presence 472 Information Data Format", RFC 4482, July 2006. 474 [11] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) 475 User Agent Capability Extension to Presence Information Data 476 Format (PIDF)", draft-ietf-simple-prescaps-ext-07 (work in 477 progress), July 2006. 479 [12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 480 J., and J. Rosenberg, "Common Policy: A Document Format for 481 Expressing Privacy Preferences", RFC 4745, February 2007. 483 [13] Rosenberg, J., "Presence Authorization Rules", 484 draft-ietf-simple-presence-rules-09 (work in progress), 485 March 2007. 487 [14] Rosenberg, J., "A Watcher Information Event Template-Package 488 for the Session Initiation Protocol (SIP)", RFC 3857, 489 August 2004. 491 [15] Rosenberg, J., "An Extensible Markup Language (XML) Based 492 Format for Watcher Information", RFC 3858, August 2004. 494 [16] Rosenberg, J., "The Extensible Markup Language (XML) 495 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 497 [17] Rosenberg, J., "Extensible Markup Language (XML) Formats for 498 Representing Resource Lists", RFC 4826, May 2007. 500 [18] Isomaki, M. and E. Leppanen, "An Extensible Markup Language 501 (XML) Configuration Access Protocol (XCAP) Usage for 502 Manipulating Presence Document Contents", RFC 4827, May 2007. 504 [19] Petrie, D., "Extensions to the Session Initiation Protocol 505 (SIP) User Agent Profile Delivery Change Notification Event 506 Package for the Extensible Markup Language Language 507 Configuration Access Protocol (XCAP)", 508 draft-ietf-sip-xcap-config-00 (work in progress), October 2006. 510 [20] Rosenberg, J., "An Extensible Markup Language (XML) Document 511 Format for Indicating A Change in XML Configuration Access 512 Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-05 513 (work in progress), March 2007. 515 [21] Urpalainen, J., "An Extensible Markup Language (XML) Patch 516 Operations Framework Utilizing XML Path Language (XPath) 517 Selectors", draft-ietf-simple-xml-patch-ops-02 (work in 518 progress), March 2006. 520 [22] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 521 Requena, "Functional Description of Event Notification 522 Filtering", RFC 4660, September 2006. 524 [23] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 525 Requena, "An Extensible Markup Language (XML)-Based Format for 526 Event Notification Filtering", RFC 4661, September 2006. 528 [24] Lonnfors, M., "Publication of Partial Presence Information", 529 draft-ietf-simple-partial-publish-06 (work in progress), 530 February 2007. 532 [25] Lonnfors, M., "Presence Information Data format (PIDF) 533 Extension for Partial Presence", 534 draft-ietf-simple-partial-pidf-format-08 (work in progress), 535 November 2006. 537 [26] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 538 D. Gurle, "Session Initiation Protocol (SIP) Extension for 539 Instant Messaging", RFC 3428, December 2002. 541 [27] Campbell, B., "The Message Session Relay Protocol", 542 draft-ietf-simple-message-sessions-19 (work in progress), 543 February 2007. 545 [28] Jennings, C., "Relay Extensions for the Message Sessions Relay 546 Protocol (MSRP)", draft-ietf-simple-msrp-relays-10 (work in 547 progress), December 2006. 549 [29] Rosenberg, J., "A Framework for Conferencing with the Session 550 Initiation Protocol (SIP)", RFC 4353, February 2006. 552 [30] Barnes, M., "A Framework for Centralized Conferencing", 553 draft-ietf-xcon-framework-08 (work in progress), May 2007. 555 [31] Niemi, A. and M. Garcia-Martin, "Multi-party Instant Message 556 (IM) Sessions Using the Message Session Relay Protocol 557 (MSRP)", draft-ietf-simple-chat-00 (work in progress), 558 June 2007. 560 [32] Schulzrinne, H., "Indication of Message Composition for Instant 561 Messaging", RFC 3994, January 2005. 563 [33] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging 564 (CPIM): Message Format", RFC 3862, August 2004. 566 [34] Bradner, S., "The Internet Standards Process -- Revision 3", 567 BCP 9, RFC 2026, October 1996. 569 [35] Burger, E. and H. Khartabil, "Instant Message Disposition 570 Notification", draft-ietf-simple-imdn-04 (work in progress), 571 May 2007. 573 Author's Address 575 Jonathan Rosenberg 576 Cisco 577 Edison, NJ 578 US 580 Phone: +1 973 952-5000 581 Email: jdrosen@cisco.com 582 URI: http://www.jdrosen.net 584 Full Copyright Statement 586 Copyright (C) The IETF Trust (2007). 588 This document is subject to the rights, licenses and restrictions 589 contained in BCP 78, and except as set forth therein, the authors 590 retain all their rights. 592 This document and the information contained herein are provided on an 593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 595 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 596 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 600 Intellectual Property 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; nor does it represent that it has 607 made any independent effort to identify any such rights. Information 608 on the procedures with respect to rights in RFC documents can be 609 found in BCP 78 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the use of 614 such proprietary rights by implementers or users of this 615 specification can be obtained from the IETF on-line IPR repository at 616 http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to implement 621 this standard. Please address the information to the IETF at 622 ietf-ipr@ietf.org. 624 Acknowledgment 626 Funding for the RFC Editor function is provided by the IETF 627 Administrative Support Activity (IASA).