diff options
Diffstat (limited to 'doc/rfc/rfc6914.txt')
| -rw-r--r-- | doc/rfc/rfc6914.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc6914.txt b/doc/rfc/rfc6914.txt new file mode 100644 index 0000000..364b979 --- /dev/null +++ b/doc/rfc/rfc6914.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Rosenberg +Request for Comments: 6914 jdrosen.net +Category: Informational April 2013 +ISSN: 2070-1721 + + + SIMPLE Made Simple: An Overview of the IETF Specifications + for Instant Messaging and Presence Using + the Session Initiation Protocol (SIP) + +Abstract + + The IETF has produced many specifications related to Presence and + Instant Messaging with the Session Initiation Protocol (SIP). + Collectively, these specifications are known as SIP for Instant + Messaging and Presence Leveraging Extensions (SIMPLE). This document + serves as a guide to the SIMPLE suite of specifications. It + categorizes the specifications, explains what each is for, and how + they relate to each other. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6914. + + + + + + + + + + + + + + + + +Rosenberg Informational [Page 1] + +RFC 6914 Simple Made Simple April 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Core Protocol Machinery . . . . . . . . . . . . . . . . . 4 + 2.2. Presence Documents . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Privacy and Policy . . . . . . . . . . . . . . . . . . . . 6 + 2.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.5. Federation . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.6. Optimizations . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1. Page Mode . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2. Session Mode . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. IM Chat Rooms . . . . . . . . . . . . . . . . . . . . . . 11 + 3.4. IM Features . . . . . . . . . . . . . . . . . . . . . . . 11 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Informative References . . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + The IETF has produced many specifications related to Presence and + Instant Messaging with the Session Initiation Protocol (SIP) + [RFC3261]. Collectively, these specifications are known as SIP for + Instant Messaging and Presence Leveraging Extensions (SIMPLE). These + specifications cover topics ranging from protocols for subscription + and publication to presence document formats to protocols for + managing privacy preferences. The large number of specifications can + make it hard to figure out exactly what SIMPLE is, what + specifications cover it, what functionality it provides, and how + these specifications relate to each other. + + + + + +Rosenberg Informational [Page 2] + +RFC 6914 Simple Made Simple April 2013 + + + This document serves to address these problems. It provides an + enumeration of the protocols that make up the SIMPLE suite of + specifications from IETF. It categorizes them into related areas of + functionality, briefly explains the purpose of each, and how the + specifications relate to each other. Each specification also + includes a letter that designates its category [RFC2026]. These + values are: + + S: Standards Track + + E: Experimental + + B: Best Current Practice + + I: Informational + +2. Presence + + SIMPLE provides for both presence and instant messaging (IM) + capabilities. Though both of these fit underneath the broad SIMPLE + umbrella, they are well separated from each other and are supported + by different sets of specifications. That is a key part of the + SIMPLE story; presence is much broader than just IM, and it enables + communications using voice and video along with IM. + + The SIMPLE presence specifications can be broken up into: + + o The core protocol machinery, which provides the actual SIP + extensions for subscriptions, notifications, and publications + + o Presence documents, which are XML documents that provide for rich + presence and are carried by the core protocol machinery + + o Privacy and policy, which are documents for expressing privacy + preferences about how those presence documents are to be shown (or + not shown) to other users + + o Provisioning, which describes how users manage their privacy + policies, buddy lists, and other pieces of information required + for SIMPLE presence to work + + o Optimizations, which are improvements in the core protocol + machinery that were defined to improve the performance of SIMPLE, + particularly on wireless links + + + + + + + +Rosenberg Informational [Page 3] + +RFC 6914 Simple Made Simple April 2013 + + +2.1. Core Protocol Machinery + + RFC 6665, SIP-Specific Event Notification (S): [RFC6665] defines the + SUBSCRIBE and NOTIFY methods for SIP, forming the core of the SIP + event notification framework. To actually use the framework, + extensions need to be defined for specific event packages. + Presence is defined as an event package [RFC3856] within this + framework. Packages exist for other, non-presence related + functions, such as message waiting indicators and dialog state + changes. + + RFC 3856, A Presence Event Package for the Session Initiation + Protocol (SIP) (S): [RFC3856] defines an event package for + indicating user presence through SIP. Through this package, a SIP + user agent (UA) can ask to be notified of the presence state of a + presentity (presence entity). The contents of the NOTIFY messages + in this package are presence documents discussed in Section 2.2. + + RFC 4662, A Session Initiation Protocol (SIP) Event Notification + Extension for Resource Lists (S): [RFC4662] defines an extension + to [RFC3265] (which has now been obsoleted by RFC 6665) that + allows a client to subscribe to a list of resources using a single + subscription. The server, called a Resource List Server (RLS), + will "expand" the subscription and subscribe to each individual + member of the list. Its primary usage with presence is to allow + subscriptions to "buddy lists". Without RFC 4662, a UA would need + to subscribe to each presentity individually. With RFC 4662, they + can have a single subscription to all buddies. A user can manage + the entries in their buddy list using the provisioning mechanisms + in Section 2.4. + + RFC 5367, Subscriptions to Request-Contained Resource Lists in the + Session Initiation Protocol (SIP) (S): [RFC5367] is very similar + to RFC 4662. It allows a client to subscribe to a list of + resources using a single subscription. However, with this + mechanism, the list is included within the body of the SUBSCRIBE + request. In RFC 4662, it is provisioned ahead of time on the + server. + + RFC 3903, Session Initiation Protocol (SIP) Extension for Event State + Publication (S): [RFC3903] defines the PUBLISH method. With this + method, a UA can publish its current state for any event package, + including the presence event package. Once an agent publishes its + presence state, the presence server would send notifications of + this state change using RFC 3856. + + + + + + +Rosenberg Informational [Page 4] + +RFC 6914 Simple Made Simple April 2013 + + +2.2. Presence Documents + + Once a user has generated a subscription to presence using the core + protocol machinery, they will receive notifications (SIP NOTIFY + requests) that contain presence information. That presence + information is in the form of an XML presence document. Several + specifications have been defined to describe this document format, + focusing on rich, multimedia presence. + + RFC 3863, Presence Information Data Format (PIDF) (S): [RFC3863] + defines the baseline XML format for a presence document. It + defines the concept of a tuple as representing a basic + communication modality and defines a simple status for it (open or + closed). + + RFC 4479, A Data Model for Presence (S): [RFC4479] extends the basic + model in RFC 3863. It introduces the concepts of device and + person status and explains how these relate to each other. It + describes how presence documents are used to represent + communications systems states in a consistent fashion. More than + RFC 3863, it defines what a presence document is and what it + means. + + RFC 4480, RPID: Rich Presence Extensions to the Presence Information + Data Format (PIDF) (S): [RFC4480] adds many more attributes to + the presence document schema, building upon the model in RFC 4479. + It allows for indications of activities, moods, places and place + types, icons, and indications of whether or not a user is idle. + + RFC 4481, Timed Presence Extensions to the Presence Information Data + Format (PIDF) to Indicate Status Information for Past and Future + Time Intervals (S): [RFC4481] adds attributes to the presence + document schema, again building upon the model in RFC 4479. It + allows documents to indicate status for the future or the past. + For example, a user can indicate that they will be unavailable for + voice communications from 2 p.m. to 3 p.m. due to a meeting. + + RFC 4482, CIPID: Contact Information for the Presence Information + Data Format (S): [RFC4482] adds attributes to the presence + document schema for contact information, such as a vCard, display + name, homepage, icon, or sound (such as the pronunciation of their + name). + + RFC 5196, Session Initiation Protocol (SIP) User Agent Capability + Extension to Presence Information Data Format (PIDF) (S): + [RFC5196] adds even more attributes to the presence document + schema, this time to allow indication of capabilities for the user + + + + +Rosenberg Informational [Page 5] + +RFC 6914 Simple Made Simple April 2013 + + + agent. For example, the extensions can indicate whether a UA + supports audio and video, what SIP methods it supports, and so on. + +2.3. Privacy and Policy + + The rich presence capabilities defined by the specifications in + Section 2.2 introduces a strong need for privacy preferences. Users + must be able to approve or deny subscriptions to their presence and + indicate what information such watchers can see. In SIMPLE, this is + accomplished through policy documents uploaded to the presence server + using the provisioning mechanisms in Section 2.4. + + RFC 4745, Common Policy: A Document Format for Expressing Privacy + Preferences (S): [RFC4745] defines a general XML framework for + expressing privacy preferences for both geolocation information + and presence information. It introduces the concepts of + conditions, actions, and transformations that are applied to + privacy-sensitive data. The common policy framework provides + privacy safety, a property by which network error or version + incompatibilities can never cause more information to be revealed + to a watcher than the user would otherwise desire. + + RFC 5025, Presence Authorization Rules (S): [RFC5025] uses the + framework of RFC 4745 to define a policy document format for + describing presence-privacy policies. Besides basic yes/no + approvals, this format allows a user to control what kind of + information a watcher is allowed to see. + + RFC 3857, A Watcher Information Event Template-Package for the + Session Initiation Protocol (SIP) (S): [RFC3857], also known as + watcherinfo, provides a mechanism for a user agent to find out + what subscriptions are in place for a particular event package. + Though it was defined to be used for any event package, it has + particular applicability for presence. It is used to provide + reactive authorization. With reactive authorization, a user gets + alerted if someone tries to subscribe to their presence, so that + they may provide an authorization decision. Watcherinfo is used + to provide the alert that someone has subscribed to a user's + presence. + + RFC 3858, An Extensible Markup Language (XML) Based Format for + Watcher Information (S): [RFC3858] is the companion to RFC 3857. + It specifies the XML format of watcherinfo that is carried in + notifications for the event template package in RFC 3857. + + + + + + + +Rosenberg Informational [Page 6] + +RFC 6914 Simple Made Simple April 2013 + + +2.4. Provisioning + + Proper operation of a SIMPLE presence system requires that several + pieces of data are correctly managed by the users and provisioned + into the system. These include buddy lists (used by the resource + list subscription mechanism in RFC 4662) and privacy policies (such + as those described by the XML format in [RFC5025]). + + In SIMPLE, management of this data is handled by the Extensible + Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825]. + XCAP is used by the user agent to manipulate buddy lists, privacy + policy, and other data that is represented by XML documents stored on + a server. + + RFC 4825, The Extensible Markup Language (XML) Configuration Access + Protocol (XCAP) (S): [RFC4825] specifies XCAP, a usage of HTTP + that allows a user agent to manipulate the contents of XML + documents stored on a server. It can be used to manipulate any + kind of XML, and the protocol itself is independent of the + particular schema of the data it is modifying. XML schemas have + been defined for buddy lists, privacy policies, and offline + presence status, allowing all of those to be managed by a user + with XCAP. + + RFC 5875, An Extensible Markup Language (XML) Configuration Access + Protocol (XCAP) Diff Event Package (S): [RFC5875] defines an + extension to the SIP user agent configuration profile, allowing a + user agent to learn about changes in its documents on an XCAP + server. With this mechanism, there can be a change made by + someone else to a buddy list or privacy policy document, and a UA + will find out that a new version is available. + + RFC 5874, An Extensible Markup Language (XML) Document Format for + Indicating a Change in XML Configuration Access Protocol (XCAP) + Resources (S): [RFC5874] defines an XML format for indicating + changes in XCAP documents. It makes use of an XML diff format + defined in [RFC5261]. It is used in conjunction with [RFC5875] to + alert a user agent of changes made by someone else to their + provisioned data. + + RFC 4826, Extensible Markup Language (XML) Formats for Representing + Resource Lists (S): [RFC4826] defines two XML document formats + used to represent buddy lists. One is simply a list of users (or + more generally, resources), and the other defines a buddy list + whose membership is composed of a list of users or resources. + These lists can be manipulated by XCAP, allowing a user to add or + remove members from their buddy lists. The buddy list is also + + + + +Rosenberg Informational [Page 7] + +RFC 6914 Simple Made Simple April 2013 + + + accessed by the resource list server specified in RFC 4662 for + processing resource list subscriptions. + + RFC 4827, An Extensible Markup Language (XML) Configuration Access + Protocol (XCAP) Usage for Manipulating Presence Document Contents + (S): [RFC4827] defines an XCAP usage that allows a user to store + an "offline" presence document. This is a presence status that is + used by a presence server when there are no presence documents + published for that user by any user agents currently running. + +2.5. Federation + + Federation refers to the interconnection of different presence and + instant messaging systems for the purposes of communications. + Federation can be between domains or within a domain. A document has + been developed that describes how presence and IM federation works. + + RFC 5344, Presence and Instant Messaging Peering Use Cases (I): + [RFC5344] describes a basic set of presence and instant messaging + use cases for federating between providers. + +2.6. Optimizations + + When running over wireless links, presence can be a very expensive + service. Notifications often get sent when the change is not really + relevant to the watcher. Furthermore, when a notification is sent, + it contains the full presence state of the watcher, rather than just + an indication of what changed. Optimizations have been defined to + address both of these cases. + + RFC 4660, Functional Description of Event Notification Filtering + (S): [RFC4660] defines a mechanism that allows a watcher to + include filters in its subscription. These filters limit the + cases in which notifications are sent. It is used in conjunction + with RFC 4661, which specifies the XML format of the filters + themselves. The mechanism, though targeted for presence, can be + applied to any SIP event package. + + RFC 4661, An Extensible Markup Language (XML)-Based Format for Event + Notification Filtering (S): [RFC4661] defines an XML format used + with the event notification filtering mechanism defined in RFC + 4660 [RFC4660]. + + RFC 5262, Presence Information Data Format (PIDF) Extension for + Partial Presence (S): [RFC5262] defines a new XML format for + representing changes in presence documents, called a partial PIDF + document. This format contains an XML patch operation [RFC5261] + that, when applied to the previous presence document, yields the + + + +Rosenberg Informational [Page 8] + +RFC 6914 Simple Made Simple April 2013 + + + new presence document. The partial PIDF document is included in + presence notifications when a watcher indicates that they support + the format. + + RFC 5263, Session Initiation Protocol (SIP) Extension for Partial + Notification of Presence Information (S): [RFC5263] defines a + mechanism for receiving notifications that contain partial + presence documents. + + RFC 5264, Publication of Partial Presence Information (S): [RFC5264] + defines a mechanism for publishing presence status using a partial + PIDF document. + + RFC 5261, An Extensible Markup Language (XML) Patch Operations + Framework Utilizing XML Path Language (XPath) Selectors (S): + [RFC5261] defines an XML structure for representing changes in XML + documents. It is a form of "diff" but specifically for XML + documents. It is used by several of the optimization mechanisms + defined for SIMPLE. + + RFC 5112, The Presence-Specific Static Dictionary for Signaling + Compression (Sigcomp) (S): [RFC5112] defines a dictionary for + usage with Signaling Compression (Sigcomp) [RFC3320] to improve + the compressibility of presence documents. + + RFC 6446, Session Initiation Protocol (SIP) Event Notification + Extension for Notification Rate Control (S): [RFC6446] specifies + mechanisms for adjusting the rate of SIP event notifications. + These mechanisms can be applied in subscriptions to all SIP event + packages. + +3. Instant Messaging + + SIMPLE defines two modes of instant messaging. These are page mode + and session mode. In page mode, instant messages are sent by sending + a SIP request that contains the contents of the instant message. In + session mode, IM is viewed as another media type -- along with audio + and video -- and an INVITE request is used to set up a session that + includes IM as a media type. While page mode is more efficient for + one or two message conversations, session mode is more efficient for + longer conversations since the messages are not sent through the SIP + servers. Furthermore, by viewing IM as a media type, all of the + features available in SIP signaling -- third party call control, + forking, and so on, are available for IM. + + + + + + + +Rosenberg Informational [Page 9] + +RFC 6914 Simple Made Simple April 2013 + + +3.1. Page Mode + + RFC 3428, Session Initiation Protocol (SIP) Extension for Instant + Messaging (S): [RFC3428] introduces the MESSAGE method, which can + be used to send an instant message through SIP signaling. + + RFC 5365, Multiple-Recipient MESSAGE Requests in the Session + Initiation Protocol (SIP) (S): [RFC5365] defines a mechanism + whereby a client can send a single SIP MESSAGE to multiple + recipients. This is accomplished by including the list of + recipients as an object in the body and having a network server + send a copy to each recipient. + +3.2. Session Mode + + RFC 4975, The Message Session Relay Protocol (MSRP) (S): [RFC4975] + defines a small text-based protocol for exchanging arbitrarily + sized content of any kind between users. An MSRP session is set + up by exchanging certain information, such as an MSRP URI, within + SIP and Session Description Protocol (SDP) signaling. + + RFC 3862, Common Presence and Instant Messaging (CPIM): Message + Format (S): [RFC3862] defines a wrapper around instant message + content providing metadata, such as the sender and recipient + identity. The CPIM format is carried in MSRP. + + RFC 4976, Relay Extensions for the Message Sessions Relay Protocol + (MSRP) (S): [RFC4976] adds support for relays to MSRP. These + relay servers receive MSRP messages and send them towards the + destination. They provide support for firewall and NAT traversal + and allow for features such as recording and inspection to be + implemented. + + RFC 6135, An Alternative Connection Model for the Message Session + Relay Protocol (MSRP) (S): [RFC6135] allows clients to negotiate + which endpoint in a session will establish the MSRP connection. + Without this specification, the client generating the SDP offer + would initiate the connection. + + RFC 6714, Connection Establishment for Media Anchoring (CEMA) for the + Message Session Relay Protocol (MSRP) (S): [RFC6714] allows + middleboxes to anchor the MSRP connection, without the need for + middleboxes to modify the MSRP messages; thus, it also enables a + secure end-to-end MSRP communication in networks where such + middleboxes are deployed. + + + + + + +Rosenberg Informational [Page 10] + +RFC 6914 Simple Made Simple April 2013 + + +3.3. IM Chat Rooms + + In SIMPLE, IM multi-user chat (also known as chat-rooms) are provided + using regular SIP conferencing mechanisms. The framework for SIP + conferencing [RFC4353] and conference control [RFC5239] describe how + all SIP-based conferencing works; including joining and leaving, + persistent and temporary conferences, floor control and moderation, + and learning of conference membership, amongst other functions. All + that is necessary are extensions to provide features that are + specific to IM. + + Multi-party Chat Using the Message Session Relay Protocol (MSRP) + (Work in Progress): [SIMPCHAT] defines how MSRP is used to + provide support for nicknames and private chat within an IM + conference. + +3.4. IM Features + + Several specifications have been written to provide IM-specific + features for SIMPLE. These include "is-typing" indications, allowing + a user to know when their messaging peer is composing a response and + allowing a user to know when their IM has been received via delivery + notifications. + + RFC 3994, Indication of Message Composition for Instant Messaging + (S): [RFC3994] defines an XML format that can be sent in instant + messages that indicates the status of message composition. This + provides the familiar "is-typing" indication in IM systems, but + also supports voice, video, and other message types. + + RFC 5438, Instant Message Disposition Notification (IMDN) (S): + [RFC5438] provides delivery notifications of IM receipt. This + allows a user to know with certainty that a message has been + received. + +4. Security Considerations + + This specification is an overview of existing specifications and does + not introduce any security considerations on its own. + +5. Acknowledgements + + Thanks to Vijay Gurbani, Barry Leiba, Stephen Hanna, and Salvatore + Loreto for their review and comments. + + + + + + + +Rosenberg Informational [Page 11] + +RFC 6914 Simple Made Simple April 2013 + + +6. Informative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific + Event Notification", RFC 3265, June 2002. + + [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., + Liu, Z., and J. Rosenberg, "Signaling Compression + (SigComp)", RFC 3320, January 2003. + + [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, + C., and D. Gurle, "Session Initiation Protocol (SIP) + Extension for Instant Messaging", RFC 3428, + December 2002. + + [RFC3856] Rosenberg, J., "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004. + + [RFC3857] Rosenberg, J., "A Watcher Information Event Template- + Package for the Session Initiation Protocol (SIP)", + RFC 3857, August 2004. + + [RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based + Format for Watcher Information", RFC 3858, August 2004. + + [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant + Messaging (CPIM): Message Format", RFC 3862, August 2004. + + [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, + W., and J. Peterson, "Presence Information Data Format + (PIDF)", RFC 3863, August 2004. + + [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension + for Event State Publication", RFC 3903, October 2004. + + [RFC3994] Schulzrinne, H., "Indication of Message Composition for + Instant Messaging", RFC 3994, January 2005. + + [RFC4353] Rosenberg, J., "A Framework for Conferencing with the + Session Initiation Protocol (SIP)", RFC 4353, + February 2006. + + + +Rosenberg Informational [Page 12] + +RFC 6914 Simple Made Simple April 2013 + + + [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, + July 2006. + + [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. + Rosenberg, "RPID: Rich Presence Extensions to the + Presence Information Data Format (PIDF)", RFC 4480, + July 2006. + + [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the + Presence Information Data Format (PIDF) to Indicate + Status Information for Past and Future Time Intervals", + RFC 4481, July 2006. + + [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the + Presence Information Data Format", RFC 4482, July 2006. + + [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- + Requena, "Functional Description of Event Notification + Filtering", RFC 4660, September 2006. + + [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- + Requena, "An Extensible Markup Language (XML)-Based + Format for Event Notification Filtering", RFC 4661, + September 2006. + + [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session + Initiation Protocol (SIP) Event Notification Extension + for Resource Lists", RFC 4662, August 2006. + + [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., + Polk, J., and J. Rosenberg, "Common Policy: A Document + Format for Expressing Privacy Preferences", RFC 4745, + February 2007. + + [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) + Configuration Access Protocol (XCAP)", RFC 4825, + May 2007. + + [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats + for Representing Resource Lists", RFC 4826, May 2007. + + [RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup + Language (XML) Configuration Access Protocol (XCAP) Usage + for Manipulating Presence Document Contents", RFC 4827, + May 2007. + + [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message + Session Relay Protocol (MSRP)", RFC 4975, September 2007. + + + +Rosenberg Informational [Page 13] + +RFC 6914 Simple Made Simple April 2013 + + + [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions + for the Message Sessions Relay Protocol (MSRP)", + RFC 4976, September 2007. + + [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, + December 2007. + + [RFC5112] Garcia-Martin, M., "The Presence-Specific Static + Dictionary for Signaling Compression (Sigcomp)", + RFC 5112, January 2008. + + [RFC5196] Lonnfors, M. and K. Kiss, "Session Initiation Protocol + (SIP) User Agent Capability Extension to Presence + Information Data Format (PIDF)", RFC 5196, + September 2008. + + [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for + Centralized Conferencing", RFC 5239, June 2008. + + [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) + Patch Operations Framework Utilizing XML Path Language + (XPath) Selectors", RFC 5261, September 2008. + + [RFC5262] Lonnfors, M., Leppanen, E., Khartabil, H., and J. + Urpalainen, "Presence Information Data Format (PIDF) + Extension for Partial Presence", RFC 5262, + September 2008. + + [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. + Khartabil, "Session Initiation Protocol (SIP) Extension + for Partial Notification of Presence Information", + RFC 5263, September 2008. + + [RFC5264] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of + Partial Presence Information", RFC 5264, September 2008. + + [RFC5344] Houri, A., Aoki, E., and S. Parameswar, "Presence and + Instant Messaging Peering Use Cases", RFC 5344, + October 2008. + + [RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient + MESSAGE Requests in the Session Initiation Protocol + (SIP)", RFC 5365, October 2008. + + [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to + Request-Contained Resource Lists in the Session + Initiation Protocol (SIP)", RFC 5367, October 2008. + + + + +Rosenberg Informational [Page 14] + +RFC 6914 Simple Made Simple April 2013 + + + [RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition + Notification (IMDN)", RFC 5438, February 2009. + + [RFC5874] Rosenberg, J. and J. Urpalainen, "An Extensible Markup + Language (XML) Document Format for Indicating a Change in + XML Configuration Access Protocol (XCAP) Resources", + RFC 5874, May 2010. + + [RFC5875] Urpalainen, J. and D. Willis, "An Extensible Markup + Language (XML) Configuration Access Protocol (XCAP) Diff + Event Package", RFC 5875, May 2010. + + [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection + Model for the Message Session Relay Protocol (MSRP)", + RFC 6135, February 2011. + + [RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation + Protocol (SIP) Event Notification Extension for + Notification Rate Control", RFC 6446, January 2012. + + [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, + July 2012. + + [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection + Establishment for Media Anchoring (CEMA) for the Message + Session Relay Protocol (MSRP)", RFC 6714, August 2012. + + [SIMPCHAT] Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party + Chat Using the Message Session Relay Protocol (MSRP)", + Work in Progress, January 2013. + +Author's Address + + Jonathan Rosenberg + jdrosen.net + + EMail: jdrosen@jdrosen.net + URI: http://www.jdrosen.net + + + + + + + + + + + + + +Rosenberg Informational [Page 15] + |