RFC 4827

RFC 4827: An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents 💖

Okay bestie, first the basics 🎀 This RFC is numbered 4827, and its title is the big one above. It was written by M. Isomaki and E. Leppanen, both at Nokia, and it's from the Network Working Group. It's a Standards Track document, dated May 2007. The title block doesn't say it obsoletes or updates any other RFC, so it doesn't mess with anything that came before 🫶

---

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and the authors are openly asking for discussion and suggestions for improvements 🦋 If you want to know where this protocol actually stands, check the current edition of the "Internet Official Protocol Standards" (STD 1), since that's the official source for its standardization state and status. And the good news: distribution of this memo is unlimited 💅

Copyright Notice 🌸

Copyright (C) The IETF Trust (2007).

Abstract 💜

This document explains how to use the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) to manipulate the contents of Presence Information Data Format (PIDF) based presence documents 🧚 It's meant for Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can take that XCAP-manipulated presence document as one of its inputs, and then uses those inputs to build the overall presence state for the presentity. Main character energy, honestly 👑

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.  Relationship with Presence State Published Using SIP
    PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.  Application Usage ID  . . . . . . . . . . . . . . . . . . . . . 6
5.  MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.  Structure of Manipulated Presence Information . . . . . . . . . 6
7.  Additional Constraints  . . . . . . . . . . . . . . . . . . . . 6
8.  Resource Interdependencies  . . . . . . . . . . . . . . . . . . 6
9.  Naming Conventions  . . . . . . . . . . . . . . . . . . . . . . 6
10. Authorization Policies  . . . . . . . . . . . . . . . . . . . . 6
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
  13.1.  XCAP Application Usage ID  . . . . . . . . . . . . . . . . 9
14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
15. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
  15.1.  Normative References . . . . . . . . . . . . . . . . . . . 9
  15.2.  Informative References . . . . . . . . . . . . . . . . . . 9

---

1. Introduction ✨

Okay so the Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specs let a user, called a watcher, subscribe to another user, called a presentity, to find out its presence information [7]. The presence data model is specified in [10], and it's giving clean separation between person-, service-, and device-related information 🍓

There's a SIP-based mechanism for publishing presence state, the SIP PUBLISH method [4] 💅 With SIP PUBLISH, a Presence User Agent (PUA) can publish its own view of the presence state, without needing to know what states other PUAs have set. BUT, and this is the tea ☕ SIP PUBLISH has a limited scope and doesn't cover every requirement for setting presence state. The main problem is that it creates soft state, which expires after the negotiated lifetime unless it gets refreshed. So it's a no-go for situations where the state should stick around even when no active device is there to refresh it 😭

There are three main use cases where setting permanent presence state, independent of whether any particular device is active, is useful 🦋

The first one is person-related state. A presentity often wants to set its presence even when it has no active devices that could publish it, like when it's traveling, on vacation, and so on 🌴

The second one is about services that are open for communication, even if the presentity doesn't have a device running that service online 📧 Examples include e-mail, Multimedia Messaging Service (MMS), and Short Message Service (SMS). For these services, the presentity has a server set up that keeps the service persistently available, at least in certain forms, and it would be good to advertise that to the watchers. Now, it isn't realistic to expect every e-mail, MMS, or SMS server to publish presence state on its own, and even if it could, that state would almost never change. So some other device has to do it. And since the service doesn't depend on that device, it would be impractical to make that device be constantly active just to publish this availability 🙄

The third one is setting the default state of any person, service, or device when no device is around to actively publish it 🌈 For example, the presentity might want to advertise that its voice service is currently closed, just to let watchers know it might be open at some point. This default state doesn't depend on any particular device either, so it can be considered pretty persistent 💜

SIP PUBLISH is still the main way to publish presence state in SIMPLE-based presence systems, and it's especially good for publishing dynamic state (which presence mostly is). But it needs to be paired with the mechanism described in this document to handle the use cases above 🫶

XML Configuration Access Protocol (XCAP) [2] lets a client read, write, and modify application configuration data stored in XML format on a server. That data has no expiration time, so it has to be explicitly inserted and deleted 🧚 The protocol lets multiple clients manipulate the data, as long as they're authorized to do so. XCAP is already used in SIMPLE-based presence systems to manipulate presence lists and presence authorization policies, which makes it an ideal choice for device-independent presence document manipulation 👑

This document defines an XCAP application usage for manipulating the contents of a presence document. The Presence Information Document Format (PIDF) [3] is used as the presence document format, since the event state compositor already has to support it because SIP PUBLISH uses it ✨

Section 3 explains in detail how the presence document manipulated with XCAP relates to the soft state published with SIP PUBLISH 🎀

XCAP needs application usages to standardize several pieces of information, including a unique application usage ID (AUID) and an XML schema for the manipulated data. These are specified starting from Section 4 💖

2. Conventions 🧚

In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1], and they indicate requirement levels for compliant implementations 🌸

Comprehensive terminology for presence and event state publishing is provided in "Session Initiation Protocol (SIP) Extension for Event State Publication" [4] 📖

3. Relationship with Presence State Published Using SIP PUBLISH 🦋

Here's the big picture 🖼️ The framework for publishing presence state is shown in Figure 1. The central piece is the event state compositor element, whose job is to compose presence information from several sources into one coherent presence document 💅

The presence state manipulated with XCAP can be seen as one of the information sources for the compositor, to be combined with the soft state published using SIP PUBLISH. This is illustrated in Figure 1. In the normal case, there can be several PUAs publishing their separate views with SIP PUBLISH, but only a single XCAP-manipulated presence document. As the figure shows, multiple XCAP clients (for instance, on different physical devices) can manipulate the same document on the XCAP server, but that still only creates one input to the event state compositor 🫶 The XCAP server stores the XCAP-manipulated presence document under the "users" tree in the XCAP document hierarchy. Check Section 9 for the details and Section 11 for an example ✨

The presence states set by XCAP and by SIP PUBLISH are completely separate inputs, and you can't directly manipulate the state set by one mechanism using the other 🙅‍♀️ How the compositor treats XCAP-based inputs compared with SIP PUBLISH-based inputs is up to compositor policy, which is beyond the scope of this specification. The SIP PUBLISH specification already requires the compositor to be able to build the overall presence state from multiple inputs, which may contain non-orthogonal (or in some ways even conflicting) information. So this XCAP usage doesn't add any new requirements for the compositor's functionality 💜

            +---------------+         +------------+
            |   Event State |         |  Presence  |<-- SIP SUBSCRIBE
            |   Compositor  +---------+  Agent     |--> SIP NOTIFY
            |               |         |   (PA)     |
            +-------+-------+         +------------+
              ^     ^     ^
              |     |     |
              |     |     |       +---------------+
     +--------+     |     +-------|  XCAP server  |
     |              |             +-------+-------+
     |              |                 ^         ^
     | SIP Publish  |                 |  XCAP   |
     |              |                 |         |
  +--+--+        +--+--+         +-------+   +-------+
  | PUA |        | PUA |         | XCAP  |   | XCAP  |
  |     |        |     |         | client|   | client|
  +-----+        +-----+         +-------+   +-------+


     Figure 1: Framework for Presence Publishing and Event State
                             Composition

The protocol interface between the XCAP server and the event state compositor isn't specified here 🙈

4. Application Usage ID 🌈

XCAP needs application usages to define a unique application usage ID (AUID), either in the IETF tree or in a vendor tree. This specification defines the pidf-manipulation AUID within the IETF tree, via the IANA registration in Section 13 🎀

5. MIME Type 💖

The MIME type for this application usage is application/pidf+xml 🧚

6. Structure of Manipulated Presence Information 👑

The XML Schema for the presence information is defined in the Presence Information Data Format (PIDF) [3]. PIDF also defines a mechanism for extending presence information. For currently defined PIDF extensions and their XML Schemas, see [8], [9], [11], and [12] ✨

The namespace URI for PIDF is urn:ietf:params:xml:ns:pidf, which is also the XCAP default document namespace 🦋

7. Additional Constraints 🌸

There are no constraints on the document beyond those described in the XML schemas (PIDF and its extensions) and in the description of PIDF [3] 💅

8. Resource Interdependencies 🫶

There are no resource interdependencies beyond the possible interdependencies defined in PIDF [3] and XCAP [2] that need to be defined for this application usage 🔥

9. Naming Conventions 🎀

Okay bestie, naming rules time 🧚 The XCAP server MUST store only a single XCAP manipulated presence document for each user. ✨ That document MUST live under the "users" tree and use the filename "index". 📁 There's an example of this in Section 11 💖

10. Authorization Policies 🔐

This application usage doesn't touch the default XCAP authorization policy 🙌 That default lets a user (the owner) read, write, and modify their own documents, and nobody else's. 💅 A server can let privileged users edit documents they don't own, but how those policies get set up and signaled is outside the scope of this document 🦋

11. Example 🌸

This section walks through an example presence document that an XCAP Client sends to an XCAP Server 💌 Our main character is a (human) presentity who has left for vacation 🏖️ Before leaving, he set his presence so that he's only reachable by e-mail 📧 If there's no published soft state info, this document would be the only input the compositor uses to build the presence document 🧠 The example uses PIDF extensions from "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)" [8] and "CIPID: Contact Information in Presence Information Data Format" [9] 🫶

We're assuming the presentity is a SIP user with Address-of-Record (AOR) sip:someone@example.com 💜 The XCAP root URI for example.com is assumed to be http://xcap.example.com 🌐 The XCAP User Identifier (XUI) is assumed to match the SIP AOR, following XCAP recommendations 🍓 So the presence document lives at http://xcap.example.com/pidf-manipulation/users/sip:someone@example.com/index 🦋

Step one is creating the presence document with this XCAP operation 🎀

PUT /pidf-manipulation/users/sip:someone@example.com/index HTTP/1.1
Host: xcap.example.com
Content-Type: application/pidf+xml
...

<?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
           xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
           xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
           xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
           entity="sip:someone@example.com">

        <tuple id="x8eg92m">
          <status>
            <basic>closed</basic>
          </status>
          <rp:user-input>idle</rp:user-input>
          <rp:class>auth-1</rp:class>
          <contact priority="0.5">sip:user@example.com</contact>
          <note>I'm available only by e-mail.</note>
          <timestamp>2004-02-06T16:49:29Z</timestamp>
        </tuple>

        <tuple id="x8eg92n">
          <status>

            <basic>open</basic>
          </status>
          <rp:class>auth-1</rp:class>
          <contact priority="1.0">mailto:someone@example.com</contact>
          <note>I'm reading mail a couple of times a week</note>
        </tuple>

        <dm:person id="p1">
           <rp:class>auth-A</rp:class>
           <ci:homepage>http://www.example.com/~someone</ci:homepage>
           <rp:activities>
               <rp:vacation/>
           </rp:activities>
        </dm:person>

      </presence>

Later, when the user wants to update the note about e-mail service, they send this XCAP operation 💅

PUT /pidf-manipulation/users/sip:someone@example.com/index/
~~/presence/tuple%5b@id='x8eg92n'%5d/note HTTP/1.1
If-Match: "xyz"
Host: xcap.example.com
Content-Type: application/xcap-el+xml
...

<note>I'm reading mails on Tuesdays and Fridays</note>

12. Security Considerations 😭🔒

Okay, this part is seriously important 🚨 A presence document can hold highly sensitive info 🙈 Sending it to watchers has to follow the relevant authorization policies strictly, no exceptions 💀 It's also crucial that only authorized clients can change presence info 🛑

The XCAP base spec says all XCAP servers MUST implement HTTP Digest authentication, as specified in RFC 2617 [5] 🔑 On top of that, XCAP servers MUST implement HTTP over TLS [6] 🔐 It's recommended that server admins use an HTTPS URI as the XCAP root services' URI, so the digest client authentication happens over TLS 🌈 Using all of this together lets XCAP clients and servers protect the confidentiality and integrity of presence document operations, and makes sure only authorized clients can do them ✨👑

13. IANA Considerations 🌷

There's one IANA consideration for this spec 🦄

13.1. XCAP Application Usage ID 🪄

This section registers a brand new XCAP Application Usage ID (AUID) following the IANA procedures defined in [2] 📝

Name of the AUID: pidf-manipulation

Description: Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF-based presence documents. 💜

14. Acknowledgements 🫶

The authors want to thank Jari Urpalainen, Jonathan Rosenberg, Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu, Krisztian Kiss, Jose Costa-Requena, George Foti, and Paul Kyzivat for their comments 💖 Thank you, legends 👑

15. References 📚

15.1. Normative References 🔥

• [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅
• [2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 🌸
• [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. 🦋
• [4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. ✨
• [5] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 🔑
• [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🔐

15.2. Informative References 🧚

• [7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. 🌷
• [8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006. 🎀
• [9] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006. 💌
• [10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. 🍓
• [11] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, July 2006. 🚧
• [12] 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. ⏳

Authors' Addresses 💌

Markus Isomaki Nokia P.O. BOX 100 00045 NOKIA GROUP Finland

EMail: markus.isomaki@nokia.com

Eva Leppanen Nokia P.O. BOX 785 33101 Tampere Finland

EMail: eva-maria.leppanen@nokia.com

Full Copyright Statement ⚖️

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF doesn't take a position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights would be available 🤷‍♀️ It also doesn't claim it has independently checked for such rights. Info about the procedures for rights in RFC documents is in BCP 78 and BCP 79 📖

Copies of IPR disclosures made to the IETF Secretariat, assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users are all available from the IETF's online IPR repository at http://www.ietf.org/ipr 🔗

The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard 🙏 Send that info to ietf-ipr@ietf.org 💌

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💜