RFC 5262

RFC 5262: Presence Information Data Format (PIDF) Extension for Partial Presence 🦋

okay bestie, this one is a Standards Track spec from September 2008 in the Network Working Group 💖 It's written by four people: M. Lonnfors (Nokia), E. Leppanen (writing as an Individual), H. Khartabil (Ericsson Australia), and J. Urpalainen (Nokia). It doesn't list anything it obsoletes or updates, so it's a fresh standalone extension. The whole point is making presence updates smaller so they work on slow, laggy links 🐢✨

---

Status of This Memo 📋

This document is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions 🌸 If you want the current standardization state of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💅

Abstract 🌈

Okay so the Presence Information Document Format (PIDF) is the baseline XML format for describing presence info, like whether you're online, busy, or ignoring the group chat 😭 The catch is that every PIDF document has to carry all the presence info for the presentity, every single time. That's a lot 💀 On low-bandwidth, high-latency links, that's a lot of data to push across the wire, so it's really helpful to send less. This doc adds a new MIME type that lets you send either just the changed bits or the full PIDF info. Efficiency era 🧚

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. Conventions .....................................................3
   3. Structure of PIDF Diff Documents ................................3
      3.1. 'version' Attribute ........................................4
      3.2. 'entity' Attribute .........................................4
   4. Usage of 'application/pidf-diff+xml' ............................4
   5. IANA Considerations .............................................5
      5.1. URN Sub-Namespace Registration for
           'urn:ietf:params:xml:ns:pidf-diff' .........................5
      5.2. application/pidf-diff+xml MIME Type ........................6
      5.3. XML Schema Registration ....................................7
   6. Examples ........................................................8
   7. XML Schema .....................................................11
   8. Interoperability Considerations ................................12
   9. Security Considerations ........................................13
   10. Internationalization Considerations ...........................13
   11. Error Handling ................................................13
   12. Acknowledgments ...............................................13
   13. References ....................................................13
      13.1. Normative references .....................................13
      13.2. Informative references ...................................14

---

1. Introduction ✨

So PIDF [RFC3863] is the XML-based format for presence info, and it always has to carry the full picture for the presentity 💅 That's fine on a good connection, but in places with slow, laggy links, it's honestly wasteful to resend everything. Making the transported info smaller is literally the whole mission here 🦋

This doc brings in a new MIME-Type, 'application/pidf-diff+xml' 🎀 With it, you can send either only the parts that changed, or the full PIDF presence info. The root element tells you which one you got, so the receiver always knows what they're looking at 👑

Note: With this new MIME-Type, applications can easily negotiate the support of partial updates of presence by using the Accept header. If PIDF had initially been designed for partial updates, a new separate MIME-Type would have been unnecessary. 🙈

2. Conventions 📚

Here's the key-word part 🫶 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119], and they show the requirement levels for compliant implementations. Those words are the official rules, so treat them seriously 💖

This memo also uses the vocabulary from RFC 2778 [RFC2778]. On top of that, a few terms get defined here:

Full presence document: This is a presence document with all of the presentity's presence info that's available to a particular watcher 🌸

Partial presence document: This is a presence document that's just a fragment of the full one. It only makes sense in context of the full presence document, because it modifies a cached copy of the full one 🧩 Think of it like a patch that only works on the version it was written for 🦋

3. Structure of PIDF Diff Documents 🧚

The MIME type 'application/pidf-diff+xml' is the new content type for partial PIDF documents 🎀

The XML Schema imports the PIDF [RFC3863] schema, so you can transport the full PIDF document with an added 'version' attribute. The root element of that document is <pidf-full>, and the 'version' attribute can go right inside it. Otherwise, the content of the <pidf-full> element is exactly what you'd have gotten if you'd used the 'application/pidf+xml' content type. The XML Schema also lets you use <presence> as the document root element, but applications using this document format aren't allowed to do that 🙅‍♀️

When only the changes are transported, the model from XML patch operations [RFC5261] is used. The root element is then <pidf-diff> 💅 The patch operation elements are <add>, <remove>, and <replace>, and together they let you change the partial content of the cached local copy of the full presence document. <add> adds new content, <replace> updates existing content, and <remove> removes it 🔥

The optional 'version' attribute, which can appear on either of the two possible document root elements, holds a sequence number. It goes up by one between subsequent document updates, so a newer update always has a higher 'version' value than the one before it 🌈 Recipients use this number to put received documents in order and to spot whether any updates got lost, which keeps things consistent 🫶 This attribute is what enables the "state delta" processing described in [RFC3265]. Partial notification [RFC5263] uses a similar model. The counter ticks up on its own whether <pidf-full> or <pidf-diff> content is sent, so there's one single version counter shared across <pidf-full> and <pidf-diff> documents 🧮

Implementations using this document format MUST follow the guidelines in the PIDF [RFC3863] and the PIDF extension formats. Examples include DataModel [RFC4479], Rich Presence Information Data (RPID) [RFC4480], and Contact Information in PIDF (CIPID) [RFC4482]. Those specs MUST support the use of the XML schema data type ID [W3C.REC-xmlschema-2-20041028] that they list. Specifically, the XML document MUST be well formed and SHOULD be valid ✅ This spec uses XML namespaces to identify presence documents and document fragments. The namespace URI for elements defined here is a URN [RFC2141], using the 'ietf' namespace identifier from RFC 2648 [RFC2648] as extended by RFC 3688 [RFC3688]. The URN is:

urn:ietf:params:xml:ns:pidf-diff

3.1. 'version' Attribute 🔢

Every presence document that complies with this specification MAY contain a 'version' attribute within the <pidf-diff> and <pidf-full> element. 💜

3.2. 'entity' Attribute 🏷️

Every presence document that complies with this specification MAY contain an 'entity' attribute within the <pidf-diff> element. When it does, its content, a presentity URI, MUST be the same as the 'entity' attribute value of the <presence> element described in [RFC3863]. You can read more about how that presentity URI gets used in Section 3.1 of [RFC4479] 🧸

4. Usage of 'application/pidf-diff+xml' 🎯

Here's the golden rule for the partial presence document: it SHOULD only contain the elements or attributes that actually changed 💖 If there are a lot of changes, though, you can just send the full presence document content instead. Efficiency, but make it make sense 🍓

---

to be continued... Part 2 picks up with Section 5, IANA Considerations 🦋

5.3. XML Schema Registration 🎀

okay so this section asks IANA to register a brand-new XML Schema 💅, and the whole schema lives in Section 7 ✨. here's the registration info:

URI:
urn:ietf:params:xml:schema:pidf-diff

Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>

6. Examples 🌸

bestie, this is the fun part 🦋. first up is an application/pidf-diff+xml document that holds the full state presence info, so everything is right there in one go 💜:

<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
       xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
       xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
       xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
       entity="pres:someone@example.com"
       version="567">

 <tuple id="sg89ae">
  <status>
   <basic>open</basic>
  </status>
  <c:servcaps>
   <c:audio>true</c:audio>
   <c:message>true</c:message>
   <c:video>false</c:video>
  </c:servcaps>
  <contact priority="0.8">tel:09012345678</contact>
 </tuple>

 <tuple id="cg231jcr">
  <status>
   <basic>open</basic>
  </status>
  <contact priority="1.0">im:pep@example.com</contact>
 </tuple>

 <tuple id="r1230d">
  <status>
   <basic>closed</basic>
  </status>
  <ci:homepage>http://example.com/~pep/</ci:homepage>
  <ci:icon>http://example.com/~pep/icon.gif</ci:icon>
  <ci:card>http://example.com/~pep/card.vcd</ci:card>
  <contact priority="0.9">sip:pep@example.com</contact>
 </tuple>

 <note xml:lang="en">Full state presence document</note>

 <dm:person id="p123">
  <r:activities>

   <r:on-the-phone/>
   <r:busy/>
  </r:activities>
 </dm:person>
 <dm:device id="u600b40c7">
  <c:devcaps>
   <c:mobility>
    <c:supported>
     <c:mobile/>
    </c:supported>
   </c:mobility>
  </c:devcaps>
  <dm:deviceID>urn:esn:600b40c7</dm:deviceID>
 </dm:device>

</p:pidf-full>

next up is an example partial update document, the one with the <pidf-diff> root element 🧚:

<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-diff
     xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
     xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
     xmlns:d="urn:ietf:params:xml:ns:pidf:data-model"
     entity="pres:someone@example.com"
     version="568">

<p:add sel="presence/note" pos="before">
 <tuple id="ert4773">
  <status>
   <basic>open</basic>
  </status>
  <contact priority="0.4">mailto:pep@example.com</contact>
  <note xml:lang="en">This is a new tuple inserted
       between the last tuple and person element</note>
 </tuple>
</p:add>

<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
   >open</p:replace>

<p:remove sel="*/d:person/r:activities/r:busy" ws="after"/>

<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
   >0.7</p:replace>

</p:pidf-diff>

and here's what the local composition presence document looks like once those patches have been applied ✨:

<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
       xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
       xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
       xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
       xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
       entity="pres:someone@example.com"
       version="568">

 <tuple id="sg89ae">
  <status>
   <basic>open</basic>
  </status>
  <c:servcaps>
   <c:audio>true</c:audio>
   <c:message>true</c:message>
   <c:video>false</c:video>
  </c:servcaps>
  <contact priority="0.8">tel:09012345678</contact>
 </tuple>

 <tuple id="cg231jcr">
  <status>
   <basic>open</basic>
  </status>
  <contact priority="0.7">im:pep@example.com</contact>
 </tuple>

 <tuple id="r1230d">
  <status>
   <basic>open</basic>
  </status>
  <ci:homepage>http://example.com/~pep/</ci:homepage>
  <ci:icon>http://example.com/~pep/icon.gif</ci:icon>
  <ci:card>http://example.com/~pep/card.vcd</ci:card>
  <contact priority="0.9">sip:pep@example.com</contact>
 </tuple>

 <tuple id="ert4773">
  <status>
   <basic>open</basic>
  </status>
  <contact priority="0.4">mailto:pep@example.com</contact>
  <note xml:lang="en">This is a new tuple inserted
      between the last tuple and note element</note>
 </tuple>

 <note xml:lang="en">Full state presence document</note>

 <dm:person id="p123">
  <r:activities>
   <r:on-the-phone/>
  </r:activities>
 </dm:person>

 <dm:device id="u600b40c7">
  <c:devcaps>
   <c:mobility>
    <c:supported>
     <c:mobile/>
    </c:supported>
   </c:mobility>
  </c:devcaps>
  <dm:deviceID>urn:esn:600b40c7</dm:deviceID>
 </dm:device>

</p:pidf-full>

7. XML Schema 💜

this is the XML schema for the application/pidf-diff+xml data format 🔥. the included schema "urn:ietf:params:xml:schema:xml-patch-ops" is defined in [RFC5261], and the PIDF Schema "pidf.xsd" gets imported from [RFC3863] 🫶.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
    targetNamespace="urn:ietf:params:xml:ns:pidf-diff"
    xmlns:tns="urn:ietf:params:xml:ns:pidf-diff"
    xmlns:pidf="urn:ietf:params:xml:ns:pidf"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified">

 <!-- include patch-ops type definitions -->
 <xsd:include
      schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>

 <!-- import PIDF definitions -->
 <xsd:import namespace="urn:ietf:params:xml:ns:pidf"
             schemaLocation="pidf.xsd"/>

 <!-- partial updates -->
 <xsd:element name="pidf-diff">
  <xsd:complexType>
   <xsd:sequence minOccurs="0" maxOccurs="unbounded">
    <xsd:choice>
     <xsd:element name="add" type="tns:add"/>
     <xsd:element name="replace" type="tns:replace"/>
     <xsd:element name="remove" type="tns:remove"/>
    </xsd:choice>
   </xsd:sequence>
   <xsd:attribute name="version" type="xsd:unsignedInt"/>
   <xsd:attribute name="entity" type="xsd:anyURI"/>
  </xsd:complexType>
 </xsd:element>

 <!-- full PIDF in addition to optional version -->
 <xsd:element name="pidf-full">
  <xsd:complexType>
   <xsd:complexContent>
    <xsd:extension base="pidf:presence">
     <xsd:attribute name="version" type="xsd:unsignedInt"/>
    </xsd:extension>
   </xsd:complexContent>
  </xsd:complexType>
 </xsd:element>

</xsd:schema>

8. Interoperability Considerations 🦋

okay so systems that follow the Common Profile for Presence (CPP) [RFC3859] won't be able to use this spec by default 🙈. but don't panic, this won't cause any interop drama, because every endpoint and gateway must support the default MIME type (application/pidf+xml) whether or not they support this spec ✨. so if a gateway or another end point doesn't get this spec, it just won't be used 💅. in SIMPLE-based systems, the use of this MIME type gets negotiated with the SIP content type negotiation mechanism, as laid out in partial notification [RFC5263] 🌈.

other CPP-compliant systems that aren't SIP-based can also support this spec, as long as they have some way to signal that they support it 🍓. if they do, you can build a gateway that keeps end-to-end integrity with partial PIDF 🫶.

9. Security Considerations 💀

ngl this one is serious 😭. every security consideration identified for PIDF [RFC3863] applies here, unchanged, because presence information may contain highly sensitive information 🔒. on top of that, the protocol SHOULD provide authorization policies that say what presence information can be given to which watchers, and when, see [RFC5025] 👑.

10. Internationalization Considerations 🌍

the PIDF [RFC3863] format is written in XML, which does all its character processing in terms of the Universal Character Set (UCS) 💜. conformant XML processors MUST support both UTF-8 and UTF-16 encodings of the UCS. UTF-8 is the RECOMMENDED encoding for this partial presence format 🌸.

if a receiving application has accepted the character set of the initial <pidf-full> document, it MUST continue to accept that same character set with the later <pidf-diff> documents ✨. however, it MUST NOT need to accept a possible character set change 🙅‍♀️.

11. Error Handling 🚨

error conditions MAY be indicated by the errors defined in [RFC5261] 🎀. this document doesn't define any extra error elements 🙈. if the 'version' or 'entity' attributes have incorrect content, it MAY be indicated by the <invalid-attribute-value> error element 💅.

12. Acknowledgments 🫶

the authors want to say a big thank you to Jose Costa-Requena, Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Miguel Garcia, Krisztian Kiss, Ben Cambell, Robert Sparks, Anders Kristenssen, Aki Niemi, Jon Peterson, Gonzalo Camarillo, Lars Eggert, Lakshminath Dondeti, and Chris Newman for their valuable comments and contributions 💖.

13. References 📚

13.1. Normative references

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
• [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
• [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
• [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
• [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
• [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
• [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.
• [RFC4482] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006.
• [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
• [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

13.2. Informative references

• [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
• [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
• [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
• [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
• [RFC5263] Lonnfors, M., "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information", RFC 5263, September 2008.

Authors' Addresses ✨

Meet the squad behind this spec 🫶

Mikko Lonnfors 💜 Nokia Itamerenkatu 11-13 00180 Helsinki Finland

Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com

Eva Leppanen 🦋 Individual Lempaala Finland

EMail: eva.leppanen@saunalahti.fi

Hisham Khartabil 🌸 Ericsson Australia P.O. Box 256c Melbourne, VIC 3001 Australia

EMail: hisham.khartabil@gmail.com

Jari Urpalainen 🎀 Nokia Itamerenkatu 11-13 00180 Helsinki Finland

Phone: +358 7180 37686 EMail: jari.urpalainen@nokia.com

---

Full Copyright Statement 💅

Copyright (C) The IETF Trust (2008) 🌈

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 contained herein 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 🔥

Okay so, legal stuff but make it cute 🧚 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💖

And that's the whole spec, bestie! Thank you for reading, you're literally the best 🫶✨