RFC 6914

SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) 💖

okay bestie, this is RFC 6914 🎀 and it's giving "the map you wish you'd had years ago." It's Request for Comments: 6914, written by J. Rosenberg (jdrosen.net), and it's marked Category: Informational 📚 from April 2013. The ISSN is 2070-1721 ✨, in case you need to cite it like a responsible adult 💅

Abstract

The IETF has made SO many specs about Presence and Instant Messaging with the Session Initiation Protocol (SIP) 🦋 Together they're called SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This doc is basically the guide to the whole SIMPLE suite 🗺️ It sorts the specs into categories, explains what each one is for, and shows how they're connected 🫶

Status of This Memo

This document is not an Internet Standards Track specification 🙈 It's published for informational purposes, so no pressure, it's just here to explain things 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the deets 👑

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6914 🧚

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) as they stood on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 made tons of specs about Presence and Instant Messaging with the Session Initiation Protocol (SIP) [RFC3261]. Together they're called SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) 💅 The topics go from subscription and publication protocols, to presence document formats, to protocols for managing privacy preferences. Honestly, with this many specs it's hard to tell what SIMPLE even is, which specs cover it, what it actually does, and how they all link up 😭

This doc fixes that 🎀 It lists the protocols that make up the SIMPLE suite from the IETF, sorts them into related areas of functionality, briefly explains what each one is for, and shows how they relate. Each spec also has a letter that marks its category [RFC2026] 🦋 The letters are:

• S: Standards Track
• E: Experimental
• B: Best Current Practice
• I: Informational

2. Presence 💜

SIMPLE does both presence and instant messaging (IM) 🌈 Even though both sit under the big SIMPLE umbrella, they're pretty separate and different sets of specs support each one. That's a key part of the SIMPLE story, bestie. Presence is WAY bigger than just IM, because it also enables voice and video communication along with IM 📞

The SIMPLE presence specs break down into:

• The core protocol machinery, which provides the actual SIP extensions for subscriptions, notifications, and publications
• Presence documents, which are XML documents that provide rich presence and get carried by the core protocol machinery
• Privacy and policy, which are documents for expressing privacy preferences about how presence documents are to be shown (or not shown) to other users
• Provisioning, which describes how users manage their privacy policies, buddy lists, and other info needed for SIMPLE presence to work
• Optimizations, which are improvements to the core protocol machinery that were defined to boost SIMPLE's performance, especially on wireless links ⚡

2.1. Core Protocol Machinery 🍓

RFC 6665, SIP-Specific Event Notification (S): [RFC6665] defines the SUBSCRIBE and NOTIFY methods for SIP, and it's the core of the SIP event notification framework 🔥 To actually use the framework, you need to define extensions for specific event packages. Presence is defined as an event package [RFC3856] inside this framework. Other packages exist for non-presence stuff too, like 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 ✨ With this package, a SIP user agent (UA) can ask to be notified of a presentity's (presence entity's) presence state. The contents of the NOTIFY messages in this package are the presence documents we'll get to in Section 2.2 💖

RFC 4662, A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists (S): [RFC4662] is an extension to [RFC3265] (which has now been obsoleted by RFC 6665) that lets a client subscribe to a list of resources with 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 main use with presence is letting you subscribe to "buddy lists". Without RFC 4662, a UA would have to subscribe to each presentity one at a time 😩 With RFC 4662, they get one single subscription to all their 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 super similar to RFC 4662 💅 It also lets a client subscribe to a list of resources with a single subscription. The difference is that here, the list is included inside the body of the SUBSCRIBE request. In RFC 4662, the list 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 it, 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 sends notifications of that state change using RFC 3856 🫶

2.2. Presence Documents 🌈

Once a user has made a subscription to presence using the core protocol machinery, they'll get notifications (SIP NOTIFY requests) carrying presence info ✨ That info comes as an XML presence document. Several specs describe this document format, focused on rich, multimedia presence 📸

RFC 3863, Presence Information Data Format (PIDF) (S): [RFC3863] defines the baseline XML format for a presence document 💜 It introduces a tuple, which represents a basic communication modality, and gives it a simple status of either open or closed 🔓

RFC 4479, A Data Model for Presence (S): [RFC4479] extends the basic model from RFC 3863 🧠 It introduces the concepts of device and person status and explains how they relate to each other. It describes how presence documents represent communications system states in a consistent way. More than RFC 3863, it's the one that 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 a LOT more attributes to the presence document schema, building on the model in RFC 4479 🌟 It allows indications of activities, moods, places and place types, icons, and whether 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 on the model in RFC 4479 ⏰ It lets documents indicate status for the future or the past. For example, a user can say they'll be unavailable for voice communications from 2 p.m. to 3 p.m. because of a meeting 📅

RFC 4482, CIPID: Contact Information for the Presence Information Data Format (S): [RFC4482] adds attributes to the presence document schema for contact info, like a vCard, display name, homepage, icon, or sound (such as how to pronounce 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 it lets a user agent indicate its capabilities. For example, the extensions can show whether a UA supports audio and video, which SIP methods it supports, and so on 🦋

2.3. Privacy and Policy 🔒

Okay bestie, the rich presence stuff from Section 2.2 is giving major privacy energy 🙈 so users need real privacy preferences. Users must be able to approve or deny subscriptions to their presence and decide what info each watcher can see. In SIMPLE, this happens 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 brings in the concepts of conditions, actions, and transformations that get applied to privacy-sensitive data. The common policy framework gives us privacy safety 🛡️ which means network errors or version incompatibilities can never accidentally reveal more info to a watcher than the user would actually want. Iconic behaviour, no notes 💅
• 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 lets a user 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, gives a user agent a way to find out what subscriptions are in place for a particular event package 👀 It was defined for any event package, but it's especially useful for presence. It powers reactive authorization, where a user gets alerted when someone tries to subscribe to their presence so they can make the call. Watcherinfo is the thing that sends that alert 🔔
• 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 gets carried in notifications for the event template package in RFC 3857 💜

2.4. Provisioning 📦

Okay so a SIMPLE presence system only runs properly when a bunch of data is managed correctly by the users and provisioned into the system 🧚 That includes buddy lists (used by the resource list subscription mechanism in RFC 4662) and privacy policies (like the ones described by the XML format in [RFC5025]).

In SIMPLE, all of that data gets managed through the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] 🌸 The user agent uses XCAP to manipulate buddy lists, privacy policy, and other data that's 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 lets a user agent manipulate the contents of XML documents stored on a server. It works with any kind of XML, and the protocol itself doesn't depend on the schema of the data it's changing. XML schemas exist for buddy lists, privacy policies, and offline presence status, so a user can manage all of those 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, letting a user agent learn about changes to its documents on an XCAP server. So if someone else changes a buddy list or privacy policy document, the UA finds out 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 uses an XML diff format defined in [RFC5261] and gets used together with [RFC5875] to alert a user agent when someone else has changed its provisioned data 💅
• RFC 4826, Extensible Markup Language (XML) Formats for Representing Resource Lists (S): [RFC4826] defines two XML document formats for representing buddy lists. One is a plain list of users (or, more generally, resources), and the other is a buddy list whose membership is made up of a list of users or resources. XCAP can manipulate these lists, so a user can add or remove members from their buddy lists 📝 The resource list server in RFC 4662 also accesses the buddy list to process 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 lets a user store an "offline" presence document 🌙 That's the presence status a presence server uses when no presence documents are currently being published for that user by any user agents that are running.

2.5. Federation 🌈

Federation is the interconnection of different presence and instant messaging systems so they can communicate ✨ It can happen between domains or within a single 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 🚀

Okay real talk, presence can be a seriously expensive service when you're running over wireless links 😭 Notifications often get sent even when the change isn't really relevant to the watcher. And when a notification does get sent, it carries the watcher's full presence state instead of just what changed. Optimizations have been defined to tackle both of these problems 🫶

• RFC 4660, Functional Description of Event Notification Filtering (S): [RFC4660] defines a mechanism that lets a watcher include filters in its subscription. Those filters limit the cases in which notifications get sent. It's used together with RFC 4661, which specifies the XML format of the filters themselves. The mechanism was targeted at presence, but it 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. It contains an XML patch operation [RFC5261] that, when applied to the previous presence document, produces the new presence document 🪄 The partial PIDF document gets included in presence notifications when a watcher says 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's a kind of "diff", but specifically for XML 🔍 Several of the optimization mechanisms defined for SIMPLE use it.
• RFC 5112, The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) (S): [RFC5112] defines a dictionary for use with Signaling Compression (Sigcomp) [RFC3320] to improve how well presence documents compress 🗜️
• 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 has two modes of instant messaging, page mode and session mode 💖 In page mode, an instant message gets sent by sending a SIP request that contains the contents of the message. In session mode, IM is treated as another media type, alongside audio and video, and an INVITE request sets up a session that includes IM as a media type. Page mode is more efficient for one or two message conversations, but session mode is better for longer chats since the messages don't go through the SIP servers. Also, by treating IM as a media type, all the features of SIP signaling (third party call control, forking, and so on) are available for IM too 👑

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 where a client can send a single SIP MESSAGE to multiple recipients 🍓 It works by putting the list of recipients as an object in the body, and then 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 gets set up by exchanging certain information, like 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 that provides metadata, like 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 on toward the destination. They provide support for firewall and NAT traversal and allow features like recording and inspection to be implemented.
• RFC 6135, An Alternative Connection Model for the Message Session Relay Protocol (MSRP) (S): [RFC6135] lets clients 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] lets middleboxes anchor the MSRP connection without needing to modify the MSRP messages 🧚 So it also enables secure end-to-end MSRP communication in networks where those middleboxes are deployed 🔐

3.3. IM Chat Rooms ✨

okay so IM group chats in SIMPLE are just built on regular SIP conferencing 💬 no need to reinvent anything. [RFC4353] and [RFC5239] basically explain how all SIP-based conferencing works, bestie: joining and leaving, persistent and temporary conferences, floor control and moderation, and how you find out who's in the room 👑 all of that is already covered. The only things left to add are the extensions for features that are specifically about IM 🎀

• Multi-party Chat Using the Message Session Relay Protocol (MSRP) (Work in Progress): [SIMPCHAT] is the one that explains how MSRP handles nicknames and private chat inside an IM conference 🦋 it's still a work in progress, so keep an eye on it 👀

3.4. IM Features

ngl the IM-specific stuff is so cute 🥹 a few specs cover it for SIMPLE. The big ones are "is-typing" indications, so you can tell when your bestie is actively composing a reply 💅 and delivery notifications, so you know your message actually got through 🫶

• RFC 3994, Indication of Message Composition for Instant Messaging (S): [RFC3994] defines an XML format that can ride along inside instant messages to show the status of message composition 💖 this is the familiar "is-typing" thing from every IM app, but it also works for voice, video, and other message types 🔥
• RFC 5438, Instant Message Disposition Notification (IMDN) (S): [RFC5438] gives you delivery notifications for IM receipt 🌸 so you can know for certain that your message was received, no more guessing 🙈✨

4. Security Considerations

okay this one is lowkey serious 💀 this spec is just an overview of specs that already exist, so it does not introduce any security considerations on its own 🔒 but the security stuff in those underlying specs is still very much a thing, so go read them 💜

5. Acknowledgements

big thanks to Vijay Gurbani, Barry Leiba, Stephen Hanna, and Salvatore Loreto for reviewing and commenting 🫶🌈 you're all iconic 👑

6. Informative References

the full reference list is below, copied exactly 📚🧚

[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.

[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.

[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.

[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

the author's contact info, exactly as listed 💌

Jonathan Rosenberg
jdrosen.net

EMail: jdrosen@jdrosen.net
URI:   http://www.jdrosen.net

---

that's the whole spec, bestie!! 🌈💖✨ go build something iconic 🦋🎀