RFC 3863

Presence Information Data Format (PIDF)

📅 published August 2004, from ietf

RFC 3863: Presence Information Data Format (PIDF) 🦋

okay bestie, so this is RFC 3863 💅 It's from the Network Working Group, it's dated August 2004, and it's on the Standards Track ✨ The authors are H. Sugano and S. Fujimoto (Fujitsu), G. Klyne (Nine by Nine), A. Bateman (VisionTech), W. Carr (Intel), and J. Peterson (NeuStar) 🫶 The title block doesn't list anything it obsoletes or updates, so it's standing on its own 👑

Status of this Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2004).

Abstract ✨

Okay so the big idea 🧚 This memo lays out the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as one shared presence data format for CPP-compliant Presence protocols 💖 It also makes a brand new media type, "application/pidf+xml", to represent the XML MIME entity for PIDF 🎀

Table of Content 🍓

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Terminology and Conventions. . . . . . . . . . . . . . .  3
   2.  Design Decisions . . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.  Minimal Model. . . . . . . . . . . . . . . . . . . . . .  3
       2.2.  Added Features . . . . . . . . . . . . . . . . . . . . .  4
       2.3.  XML Encoding Decision. . . . . . . . . . . . . . . . . .  5
   3.  Overview of Presence Information Data Format . . . . . . . . .  5
       3.1.  The 'application/pidf+xml' Content Type. . . . . . . . .  5
       3.2.  Presence Information Contents. . . . . . . . . . . . . .  5
   4.  XML-encoded Presence Data Format . . . . . . . . . . . . . . .  6
       4.1.  XML Format Definitions . . . . . . . . . . . . . . . . .  6

             4.1.1. The <presence> element. . . . . . . . . . . . . .  6
             4.1.2. The <tuple> element . . . . . . . . . . . . . . .  7
             4.1.3. The <status> element. . . . . . . . . . . . . . .  8
             4.1.4. The <basic> element . . . . . . . . . . . . . . .  8
             4.1.5. The <contact> element . . . . . . . . . . . . . .  8
             4.1.6. The <note> element. . . . . . . . . . . . . . . .  9
             4.1.7. The <timestamp> element . . . . . . . . . . . . .  9
       4.2.  Presence Information Extensibility . . . . . . . . . . . 10
             4.2.1. XML Namespaces Background . . . . . . . . . . . . 10
             4.2.2. XML Namespaces In Presence Information. . . . . . 11
             4.2.3. Handling Of Unrecognized Element Names. . . . . . 12
             4.2.4. Status Value Extensibility. . . . . . . . . . . . 12
             4.2.5. Standardizing Status Extensions . . . . . . . . . 13
       4.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
             4.3.1. Default Namespace with Status Extensions. . . . . 14
             4.3.2. Presence with Other Extension Elements. . . . . . 15
             4.3.3. Example Mandatory To Understand Elements. . . . . 16
       4.4.  XML Schema Definitions . . . . . . . . . . . . . . . . . 16
   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
       5.1.  Content-type registration for 'application/pidf+xml' . . 18
       5.2.  URN sub-namespace registration for
             'urn:ietf:params:xml:ns:pidf'. . . . . . . . . . . . . . 19
       5.3.  URN sub-namespace registration for
             'urn:ietf:params:xml:ns:pidf:status' . . . . . . . . . . 20
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 21
   7.  Internationalization Considerations. . . . . . . . . . . . . . 22
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 22
       8.2.  Informative References . . . . . . . . . . . . . . . . . 23
   Appendix A. Document Type Definitions. . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28

1. Introduction 🌈

The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence (CPP) [CPP] specs define a set of operations and parameters so that different Instant Messaging and Presence protocols can talk to each other, as long as they meet RFC 2779 [RFC2779] 🤝

This memo goes further and defines the Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant presence protocols 💅 The payoff is that presence information can cross CPP-compliant protocol boundaries without modification, with the security and performance benefits that come along for the ride ✨

The format in this memo defines the base presence format and the extensibility that RFC 2779 [RFC2779] requires. It defines a minimal set of presence status values from the IMPP Model document [RFC2778]. But a presence application can define its own status values using the extensibility framework in this memo 🦋 Defining those extended status values is beyond the scope of this memo 🙈

Also, this memo only defines the format for a presence data payload, plus the extensibility framework for it. How the presence data gets transferred inside a specific protocol frame would be defined separately, in a protocol specification 📦

1.1. Terminology and Conventions 📖

This memo uses the vocabulary defined in the IMPP Model document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT mean the same thing here that they mean there 🧠

Bestie, read this next part carefully 👀 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

2. Design Decisions 🎀

We adopted the IMPP Model and Requirements documents [RFC2778, RFC2779] as our starting point. The two RFCs make a bunch of statements about presence information, and those act as a basic set of constraints for the format design 💭 We also took a minimalist approach based on them. Starting from the minimal model, we only included the features that are necessary to solve particular problems 🧩

2.1. Minimal Model 🧩

This specification is based on the minimal model pulled out of the IMPP Model and Requirements documents. The model has the following items. Each one comes with its corresponding RFCs and section numbers as grounds, e.g., (RFC2778:Sec.2.4) refers to Section 2.4 of RFC 2778.

  • (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, where a PRESENCE TUPLE consists of a STATUS, an optional COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is understood in this document to refer only to a URI (RFC2778:Sec.3).
  • (b) STATUS has at least the mutually-exclusive values OPEN and CLOSED, which have meaning for the acceptance of INSTANT MESSAGES, and may have meaning for other COMMUNICATION MEANS. There may be other values of STATUS that do not imply anything about INSTANT MESSAGE acceptance. These other values of STATUS may be combined with OPEN and CLOSED or they may be mutually-exclusive with those values (RFC2778:Sec.3, RFC2779:Sec.4.4.1-4.4.3).
  • (c) STATUS may consist of single or multiple values.(RFC2778:Sec.2.4)
  • (d) There must be a means of extending the common presence format to represent additional information not included in the common format. The extension and registration mechanisms must be defined for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP (RFC2779:Sec.3.1.4-3.1.5).
  • (e) The common presence format must include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported (RFC2779:Sec.3.1.2).
  • (f) The common presence format must allow the PRESENTITY to secure presence information sent to a WATCHER. The format must allow integrity, confidentiality and authentication properties to be applied to presence information (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 5.3.3).

2.2. Added Features ➕

In addition to the minimal model above, the format in this specification has the following features.

  • (a) Relative priorities of contact addresses are specifiable, so the source of PRESENCE INFORMATION can tell the receiver (WATCHER USER AGENTS) its preference over multiple contact means.
  • (b) The presence format is able to contain the timestamp of the creation of the PRESENCE INFORMATION. The timestamp in the presence document lets the receiver know the time of the creation of the data even if the message containing it is delayed. It can also be used to detect a replay attack, independent of the underlying signature mechanism. Note that this mechanism does not assume any global time synchronization system for watchers and presentities (see Appendix A of RFC2779, 8.1.4 A7), but rather assumes that the minimum length of time that might pass before presence information is considered stale is long enough that minor variations among system clocks will not lead to misjudgments of the freshness of presence information.

2.3. XML Encoding Decision 🌷

The Presence Information Data Format encodes presence information in XML (eXtensible Markup Language [XML]). Given the features of PRESENCE INFORMATION discussed above, namely that it has a hierarchical structure and that it should be fully extensible, XML is considered the most desirable framework over other candidates such as vCard [vCard].

3. Overview of Presence Information Data Format 🔍

This section gives an overview of the presence data format defined in this memo.

3.1. The 'application/pidf+xml' Content Type 💌

This memo defines a new content type "application/pidf+xml" for an XML MIME entity that contains presence information. This specification follows the recommendations and conventions in [RFC3023], including the naming convention for the type ('+xml' suffix) and the use of the 'charset' parameter.

Although the 'charset' parameter is defined as optional, using it is RECOMMENDED. If the 'charset' parameter is not specified, conforming XML processors MUST follow the requirements in section 4.3.3 of [XML].

3.2. Presence Information Contents ✨

okay so this subsection is basically the cheat sheet 📋 for what goes inside an "application/pidf+xml" doc. the full PIDF details live in Section 4, so this is the highlights reel 🎀

  • PRESENTITY URL: the "pres" URL of the PRESENTITY 💖
  • List of PRESENCE TUPLES 🧚
    • Identifier: a token that identifies this tuple inside the presence info 🏷️
    • STATUS: OPEN/CLOSED and/or extension status values 🔥
    • COMMUNICATION ADDRESS: the COMMUNICATION MEANS and CONTACT ADDRESS of this tuple (optional) 💌
    • Relative priority: a number showing how much priority this COMMUNICATION ADDRESS gets (optional) 👑
    • Timestamp: when this tuple last changed (optional) ⏰
    • Human readable comment: a free text memo about this tuple (optional) 📝
  • PRESENTITY human readable comment: a free text memo about the PRESENTITY (optional) 🌸
  1. XML-encoded Presence Data Format 🎀

okay this section is where the PIDF format gets officially defined 🤓 it's for use with CPP compliant systems. the PRESENTITY (the source of the PRESENCE INFORMATION) makes a presence payload in this format, and then the presence servers or gateways pass it along to the WATCHERS without any interpretation or modification. no poking at it, no editing it, just delivering it intact 💅

4.1. XML Format Definitions 💖

a PIDF object is a well formed XML document ✨

it MUST have the XML declaration, and it SHOULD contain an encoding declaration in the XML declaration, e.g., <?xml version='1.0' encoding='UTF-8'?> 🫶 if the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence 🌈

every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability 💜

4.1.1. The <presence> element 🦋

PIDF elements are associated with the XML namespace name urn:ietf:params:xml:ns:pidf, declared using an xmlns attribute, per [XML-NS]. the namespace may be a default namespace, or it may be tied to some namespace prefix (see section 4.2.2 for examples) 🧚

the root of an "application/pidf+xml" object is a <presence> element tied to the presence information namespace. it contains any number (including 0) of <tuple> elements, followed by any number (including 0) of <note> elements, followed by any number of OPTIONAL extension elements from other namespaces 🎀

the <presence> element MUST have an 'entity' attribute. the value of the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this presence document 🔥

the <presence> element MUST contain a namespace declaration ('xmlns') to indicate the namespace the presence document is based on. a presence document compliant with this specification MUST have the namespace urn:ietf:params:xml:ns:pidf: 💅

it MAY contain other namespace declarations for the extensions used in the presence XML document 🌸

4.1.2. The <tuple> element 🧚

the <tuple> element carries a PRESENCE TUPLE. it's made of a mandatory <status> element, then any number of OPTIONAL extension elements (possibly from other namespaces), then an OPTIONAL <contact> element, then any number of OPTIONAL <note> elements, and finally an OPTIONAL <timestamp> element 💖

tuples are a way of segmenting presence information ✨ protocols or applications may choose to segment the presence info for a presentity for any number of reasons. for example, components of the full presence info might come from distinct devices or different apps on the same device, or they might have been generated at different times 🦋 tuples SHOULD be preferred over other ways of segmenting presence information, such as creating multiple PIDF instances 👑

the <tuple> element MUST contain an 'id' attribute, which is used to tell this tuple apart from other tuples in the same PRESENTITY. the value of an 'id' attribute MUST be unique among the 'id' attribute values of other tuples for the same PRESENTITY 🫶 an 'id' value is used by applications processing the presence document to find the matching tuple in the previously acquired PRESENCE INFORMATION of the same PRESENTITY 🔍 the value of the 'id' attribute is an arbitrary string, with no significance beyond telling <tuple> values apart, as noted above 🌈

the <contact> element is OPTIONAL because a PRESENTITY might need to hide its COMMUNICATION ADDRESS, or there might be tuples not related to any COMMUNICATION MEANS 🙈 tuples that contain a <basic> status element SHOULD contain a <contact> address 💜 tuples MAY contain conflicting presence status. one <tuple> might give a <basic> <status> of OPEN, and another <tuple> in the same PIDF could give a <basic> <status> of CLOSED, even if they both contain the same <contact> address 💀

how a WATCHER USER AGENT understands segmented presence info really depends on its capabilities and on the presence application in question 🧠 without any application-specific or protocol-specific understanding of what tuples mean, WATCHER USER AGENTS MAY follow these guidelines. WATCHER USER AGENTS SHOULD note which tuples in the PIDF have changed their state since the last notification. they do this by matching the 'id' of each <tuple> with the ones received in previous notifications, then comparing both <status> values and <timestamp> elements, if any are present 🔥

4.1.3. The <status> element 💅

the <status> element contains one OPTIONAL <basic> element, followed by any number of OPTIONAL extension elements (possibly from other namespaces), with the restriction that at least one child element appears in the <status> element 🎀 these children hold the status values of this tuple. by allowing multiple status values in a single <tuple>, different types of status values (like reachability and location) can be represented by one <tuple> 🌸 see Section 4.3 for an example with multiple status values 🧚

this memo only defines the <basic> status value element. other status values may be included using the standard extensibility framework (see Section 4.2.4) ✨ applications that run into unrecognized elements within <status> MAY ignore them, unless they carry a mustUnderstand="true" or mustUnderstand="1" attribute (see Section 4.2.3) 🫶

note that, while the <status> element MUST have at least one status value element, this status value might not be the <basic> element 💖

4.1.4. The <basic> element 🦋

the <basic> element contains one of the following strings: "open" or "closed" 🌈

the values "open" and "closed" indicate availability to receive INSTANT MESSAGES if the <tuple> is for an instant messaging address 💬 they also indicate general availability for other communication means, but this memo doesn't specify those in detail 🙈

open: in the context of INSTANT MESSAGES, this means the associated <contact> element, if any, corresponds to an INSTANT INBOX that is ready to accept an INSTANT MESSAGE ✨

closed: in the context of INSTANT MESSAGES, this means the associated <contact> element, if any, corresponds to an INSTANT INBOX that is unable to accept an INSTANT MESSAGE 💀

4.1.5. The <contact> element 👑

the <contact> element contains a URL of the contact address. it optionally has a 'priority' attribute, whose value means a relative priority of this contact address over the others 💅 the value of the attribute MUST be a decimal number between 0 and 1 inclusive, with at most 3 digits after the decimal point. higher values mean higher priority 🔥 examples of priority values are 0, 0.021, 0.5, 1.00 🌸 if the 'priority' attribute is omitted, applications MUST assign the contact address the lowest priority 🫶 if the 'priority' value is out of the range, applications SHOULD ignore the value and process it as if the attribute wasn't there 🙈

applications SHOULD handle contacts with a higher priority as having precedence over those with lower priorities 👑 how they're actually treated is beyond this specification 🧠 also, how to handle contacts with the same priority is up to implementations 💜

4.1.6. The <note> element 🌈

the <note> element contains a string value, which is usually used for a human readable comment 💬 a <note> element MAY appear as a child of <presence> or as a child of the <tuple> element 🦋 in the former case the comment is about the PRESENTITY, and in the latter case the comment is about that particular tuple ✨

note that, wherever it appears, a <note> element SHOULD NOT be used, and interpreted, as a non-interoperable substitute for status of its parent element 🙅‍♀️

the <note> element SHOULD have a special attribute 'xml:lang' to specify the language used in the contents of this element, as defined in Section 2.12 of [XML] 🌍 the value of this attribute is the language identifier as defined by [RFC3066] 🧚 it MAY be omitted when the language is implied by the larger context, such as the encoding information of the contents, like an xml:lang attribute on an enclosing XML element, or a Content-language header [RFC3282] on an enclosing MIME wrapper 🫶

4.1.7. The <timestamp> element ⏰

the <timestamp> element contains a string indicating the date and time of the status change of this tuple 📅 the value of this element MUST follow the IMPP datetime format [RFC3339] 💖 timestamps that contain 'T' or 'Z' MUST use the capitalized forms 🔠

as a security measure, the <timestamp> element SHOULD be included in all tuples unless the exact time of the status change cannot be determined 🔐 for security guidelines for watchers receiving presence information with timestamps, see the Security Considerations 🛡️

a PRESENTITY MUST NOT generate successive <presence> elements containing the same timestamp 🚫

4.2. Presence Information Extensibility 🌸

the presence information extensibility framework is based on XML namespaces [XML-NS] 🧩

RFC 2779 requires that PIDF have a means of extending <status> values beyond <basic> 🙌 these extensions MUST NOT modify how <basic> is to be understood, and MUST NOT change the structure or semantics of PIDF bodies themselves 🚧 these extensions just let protocols and applications define richer presence data 🦋

4.2.1. XML Namespaces Background ✨

okay so every element and some attributes belong to a "namespace," and that namespace is tied to a globally unique URI 🌸 This is what lets any developer make up their own element names without bumping into somebody else's, as long as they pick a good namespace URI 💅

Inside the presence data, a name gets linked to its namespace with a prefix, which is the bit at the front before a colon (":") 🎀 It looks like this:

<prefix:element-name ...> ... </prefix:element-name>

Here 'prefix' is the header name prefix (yes, that's literally what it says 😭) and 'element-name' is a name scoped by whatever namespace the prefix points to. The prefix itself is pretty arbitrary, honestly. The URI is the thing that actually defines the naming scope 🦋 And if two different prefixes point at the same namespace URI, they mean the same namespace, so no drama there 💜

You can also declare a default namespace for elements that don't have a prefix. The default namespace does NOT apply to attribute names, though. Whether an unprefixed attribute means something depends on the element that contains it ✨

A namespace is identified by a URI, but here the URI is just a globally unique ID. It doesn't have to lead anywhere you can fetch a web resource from, and it doesn't need to do anything else either 🧚 Any legal globally unique URI MAY be used to identify a namespace. (By "globally unique," we mean it was built using some set of rules, so that nobody else is reasonably expected to use that same URI for something different 🙈)

For more details, check out the XML namespace specification [XML-NS] 📚

4.2.2. XML Namespaces In Presence Information 🌈

A URI used as a namespace identifier in PRESENCE INFORMATION data MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and URI-references containing fragment identifiers MUST NOT be used for this purpose 🙅‍♀️)

The namespace URI for the elements defined in this spec is a URN [URN], using the namespace identifier 'ietf' that's defined by [URN-NS-IETF] and extended by [XML-Registry] 💖

urn:ietf:params:xml:ns:pidf

So simple presence data could look like this 🍓

<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
    entity="pres:someone@example.com">
  <impp:tuple id="sg89ae">
    <impp:status>
      <impp:basic>open</impp:basic>
    </impp:status>
    <impp:contact priority="0.8">tel:+09012345678</impp:contact>
  </impp:tuple>
</impp:presence>

Or with a default XML namespace, which is giving cleaner and shorter vibes 💅

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
    entity="pres:someone@example.com">
  <tuple id="sg89ae">
    <status>
      <basic>open</basic>
    </status>
    <contact priority="0.8">tel:+09012345678</contact>
  </tuple>
</presence>

Like usual in XML with namespaces, the xmlns attribute can go on any element in the presence information. It can set the default namespace or attach a namespace to a prefix ✨

4.2.3. Handling Of Unrecognized Element Names 🙈

Except as noted below, a processor of PRESENCE INFORMATION MUST ignore any XML element with an unrecognized name (so, one with an unrecognized namespace URI, or an unrecognized local name inside that namespace). That includes all of the element's content, even if it looks like it has recognized names in it 🫣

Extensions to PIDF are informational. They add extra info on top of the <basic> status 💜 But sometimes, to understand a complicated extension, the nested elements inside it need to be marked as mandatory. When that happens, the element name gets a mustUnderstand='true' or mustUnderstand='1' attribute. See section 4.3.3 for an example 🎀

NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute inside an element that is being ignored is itself ignored. Whoever writes the nested mandatory-to-understand info is responsible for making sure any enclosing element also gets a mustUnderstand='true' or mustUnderstand='1' attribute, if needed 🫶

This spec defines (in section 4.1) elements in the 'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in CPP presence data. Processors MUST handle these as described, even if they don't carry a mustUnderstand attribute 👑 The XML Schema Definition (section 4.4) tells you which elements MUST be present in a valid presence information document 📋

If an agent gets PRESENCE INFORMATION with a <status> block that holds an unrecognized element with a mustUnderstand='true' (or '1') attribute, it should treat that whole element and all its content as unrecognized and not try to process it 🙅‍♀️

Last but not least, so that minimal implementations can still correctly process basic PIDF information, the mustUnderstand attribute MUST be used only within optional elements nested in a <status> element 🧚 That way, any trouble with an extension stays inside that extension and doesn't mess with the basic PIDF information defined in this spec 💖

4.2.4. Status Value Extensibility 🦋

This memo only defines the <basic> status value, with the values "open" and "closed." Other status values are possible using the standard namespace-based extensibility rules we just went over ✨

For example, a location status value could be included like this 📍

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:local="urn:example-com:pidf-status-type"
    entity="pres:someone@example.com">
  <tuple id="ub93s3">
    <status>
      <basic>open</basic>
      <local:location>home</local:location>
    </status>
    <contact>im:someone@example.com</contact>
  </tuple>
</presence>

Some new status values will 'extend' the value of the <basic> element. For example, a status value made for instant messaging might include things like 'away', 'busy' and 'offline' 💬 To keep some level of interoperability with user agents that don't recognize the new extension, the <basic> status value must also be included 🫶 This means extensions aren't obligated to define a mapping from each of their values to OPEN or CLOSED 🌸

4.2.5. Standardizing Status Extensions 📜

Even though the existing PIDF definition lets arbitrary elements show up in the <status> element, sometimes it's really useful to standardize extension status elements and their semantics (what particular statuses mean, and how they should be interpreted) 🎀 The URN 'urn:ietf:params:xml:ns:pidf:status' has been specified as an umbrella namespace for extensions to the <status> PIDF element. Those extensions should be specified under it (for example, urn:ietf:params:xml:ns:pidf:status:my-extension). New values under this namespace MUST be defined by a standards-track RFC 🔥

The example below is an XML Schema that defines an extension for <location> presence information, which can have the values 'home', 'office', or 'car' 🏠 If the <location> element were standardized, this document would be published in an RFC along with info about using the extension. These extensions should use the namespace 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an extension should register an extension name in that namespace with IANA 📬

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

  <xs:simpleType name="location">
    <xs:restriction base="xs:string">
      <xs:enumeration value="home"/>
      <xs:enumeration value="office"/>
      <xs:enumeration value="car"/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

Besides the XML Schema used to validate the extension and registering the extension name with IANA, RFCs defining extensions MUST discuss:

  • The domain of applicability of the extension. Is this extension exclusively valuable to IM clients, telephones, geolocators, etc.? What sorts of presence applications would use this extension, and under what circumstances? 📱
  • Semantics for the presence states defined in the extension. What disposition provokes an automated presentity to declare that it is in state X, or does a human select X from a drop-down menu? Is there any general guidance for watchers of presence information with state Y (for example, how they should best attempt to communicate with the presentity, if at all, when the principal is in state Y)? 🤔

Extensions SHOULD also discuss:

  • How, if at all, any presence states defined in the extension relate to <basic>, or to any relevant extension previously published in an RFC. For example, "state Z implies OPEN, so it MUST NOT be used if a basic state of CLOSED is expressed," or "you should use the extension in this document, not the extension in RFC QQQQ, if your circumstances are as follows...." 🧠

4.3. Examples 🎀

4.3.1. Default Namespace with Status Extensions 💅

The following instance document uses a hypothetical 'pidf:im' XML namespace as an example of the kind of status extension that might be developed for PIDF 💖

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:im="urn:ietf:params:xml:ns:pidf:im"
     xmlns:myex="http://id.example.com/presence/"
     entity="pres:someone@example.com">
  <tuple id="bs35r9">
    <status>
      <basic>open</basic>
      <im:im>busy</im:im>
      <myex:location>home</myex:location>
    </status>
    <contact priority="0.8">im:someone@mobilecarrier.net</contact>
    <note xml:lang="en">Don't Disturb Please!</note>
    <note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
    <timestamp>2001-10-27T16:49:29Z</timestamp>
  </tuple>
  <tuple id="eg92n8">
    <status>
      <basic>open</basic>
    </status>
    <contact priority="1.0">mailto:someone@example.com</contact>
  </tuple>
  <note>I'll be in Tokyo next week</note>
</presence>

4.3.2. Presence with Other Extension Elements 🦋

<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
     xmlns:myex="http://id.example.com/presence/"
     entity="pres:someone@example.com">
  <impp:tuple id="ck38g9">
    <impp:status>
      <impp:basic>open</impp:basic>
    </impp:status>
    <myex:mytupletag>Extended value in tuple</myex:mytupletag>
    <impp:contact priority="0.65">tel:+09012345678</impp:contact>
  </impp:tuple>
  <impp:tuple id="md66je">
    <impp:status>
      <impp:basic>open</impp:basic>
    </impp:status>
    <impp:contact priority="1.0">
       im:someone@mobilecarrier.net</impp:contact>
  </impp:tuple>
  <myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>

4.3.3. Example Mandatory To Understand Elements 🎀

okay so this example is giving "you can't just ignore me" energy 💅 Here's a presence document with a few extension bits tucked inside:

<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
     xmlns:myex="http://id.mycompany.com/presence/"
     entity="pres:someone@example.com">
  <impp:tuple id="tj25ds">
    <impp:status>
      <impp:basic>open</impp:basic>
    </impp:status>
    <myex:complexExtension>
      <myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
      <myex:ex2>val2</myex:ex2>
    </myex:complexExtension>
    <impp:contact priority="0.725">tel:+09012345678</impp:contact>
  </impp:tuple>
  <myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>

So the vibe here: <myex:ex1> must be understood, like, no skipping it 🫶 If your processor doesn't recognize it, then <myex:complexExtension> MUST be ignored 🙈 Meanwhile <myex:mytag> and <myex:ex2> are MAY be ignored if they aren't recognized, so they're the chill ones 🌸

4.4. XML Schema Definitions 📐

okay so this part hands you the XML Schema Definition [XMLSchema1] for the application/pidf+xml format 🎀 It's basically the official, formal version of the format, so treat it as the source of truth. Heads up though: the schema is NOT meant for on-the-fly validation of the presence XML document, so don't go trying to validate every message live with it ✨

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

  <!-- This import brings in the XML language attribute xml:lang-->
  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
    schemaLocation="http://www.w3.org/2001/xml.xsd"/>

  <xs:element name="presence" type="tns:presence"/>

  <xs:complexType name="presence">
    <xs:sequence>
      <xs:element name="tuple" type="tns:tuple" minOccurs="0"
         maxOccurs="unbounded"/>

      <xs:element name="note" type="tns:note" minOccurs="0"
         maxOccurs="unbounded"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="entity" type="xs:anyURI" use="required"/>
  </xs:complexType>

  <xs:complexType name="tuple">
    <xs:sequence>
      <xs:element name="status" type="tns:status"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
      <xs:element name="contact" type="tns:contact" minOccurs="0"/>
      <xs:element name="note" type="tns:note" minOccurs="0"
         maxOccurs="unbounded"/>
      <xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:ID" use="required"/>
  </xs:complexType>

  <xs:complexType name="status">
    <xs:sequence>
      <xs:element name="basic" type="tns:basic" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:simpleType name="basic">
    <xs:restriction base="xs:string">
      <xs:enumeration value="open"/>
      <xs:enumeration value="closed"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="contact">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="priority" type="tns:qvalue"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="note">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute ref="xml:lang"/>
      </xs:extension>

    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="qvalue">
    <xs:restriction base="xs:decimal">
      <xs:pattern value="0(.[0-9]{0,3})?"/>
      <xs:pattern value="1(.0{0,3})?"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- Global Attributes -->
  <xs:attribute name="mustUnderstand" type="xs:boolean" default="0">
    <xs:annotation>
      <xs:documentation>
      This attribute may be used on any element within an optional
      PIDF extension to indicate that the corresponding element must
      be understood by the PIDF processor if the enclosing optional
      element is to be handled.
      </xs:documentation>
    </xs:annotation>
  </xs:attribute>
</xs:schema>

5. IANA Considerations 🌈

okay so this part is for IANA, and it's basically the paperwork ✨ This memo asks IANA to do three things:

  • register a new MIME content-type application/pidf+xml, per [MIME],
  • register a new XML namespace URN per [XML-Registry].
  • register a new XML namespace URN for status extensions per [XML-Registry].

The registration templates for these are below. If you want more on status extensions, go check section 4.2.5 🦋

5.1. Content-type registration for 'application/pidf+xml' 💌

here's the template for the MIME type registration, verbatim:

To: ietf-types@iana.org
Subject: Registration of MIME media type application/pidf+xml

MIME media type name:  application

MIME subtype name:     pidf+xml

Required parameters:   (none)
Optional parameters:   charset
   Indicates the character encoding of enclosed XML.  Default is
   UTF-8.

Encoding considerations:
   Uses XML, which can employ 8-bit characters, depending on the
   character encoding used.  See RFC 3023 [RFC 3023], section 3.2.

Security considerations:
   This content type is designed to carry presence data, which may be
   considered private information.  Appropriate precautions should be
   adopted to limit disclosure of this information.

Interoperability considerations:
   This content type provides a common format for exchange of
   presence information across different CPP compliant protocols.

Published specification:
   RFC 3863

Applications which use this media type:
   Presence and instant messaging systems.

Additional information:
   Magic number(s):  File extension(s):  Macintosh File Type Code(s):

Person & email address to contact for further information:
   Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com

Intended usage:
   LIMITED USE

Author/Change controller:
   This specification is a work item of the IETF IMPP working group,
   with mailing list address <impp@iastate.edu>.

Other information:
   This media type is a specialization of application/xml [RFC 3023],
   and many of the considerations described there also apply to
   application/pidf+xml.

5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf' 🔖

URI:

urn:ietf:params:xml:ns:pidf

Description:

This is the XML namespace URI for XML elements defined by RFC 3863
to describe CPP presence information in application/pidf+xml
content type.

Registrant Contact:

IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>

XML:

BEGIN
  <?xml version="1.0"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
            "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type"
       content="text/html;charset=utf-8"/>
    <title>Namespace for CPP presence information</title>
  </head>
  <body>
    <h1>Namespace for CPP presence information</h1>
    <h2>urn:ietf:params:xml:ns:pidf</h2>
    <p>See <a
       href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
       RFC3863</a>.</p>
  </body>
  </html>
END

5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:status' ✨

URI:

urn:ietf:params:xml:ns:pidf:status

Description:

This is the XML namespace URI for XML elements defined by
RFC 3863 to describe extensions to the status of CPP presence
information in application/pidf+xml content type.

Registrant Contact:

IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>

XML:

BEGIN
  <?xml version="1.0"?>
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
            "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type"
       content="text/html;charset=utf-8"/>
    <title>Namespace for CPP status extensions</title>
  </head>
  <body>
    <h1>Namespace for CPP presence information extensions</h1>
    <h2>urn:ietf:params:xml:ns:pidf:status</h2>
  <p>See <a
    href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
    RFC3863</a>.</p>
  </body>
  </html>
END

6. Security Considerations 🔐

okay this section is SERIOUS, bestie, so pay attention 🙈 Presence is super privacy-sensitive info, so the protocol for presence information MUST have capabilities to protect PIDF from threats like eavesdropping, corruption, tampering, and replay attacks 😭 Those security mechanisms also have to work end-to-end between presentities and watchers, even when the watcher and the presentity use different presence protocols and talk through a CPP gateway 💀

Since the 'application/pidf+xml' MIME type is defined for this PIDF document, it seems appropriate to stage security for PIDF at the MIME level, with S/MIME [RFC3851]. So PIDF should follow the normative recommendations for using S/MIME, including the minimum ciphersuites, that are given in the core CPP specification 🔒

Also, timestamps in PIDF (see section 4.1.7) can give some rudimentary protection against replay attacks ⏰ If a watcher gets presence information that's outdated, it SHOULD be ignored 🗑️ There are a few ways a watcher can tell that presence info is outdated. The biggest one: if the newest timestamp in the presence information is older than the newest timestamp in the last presence information received, it should be considered outdated. Applications and protocols are also advised to make their own rules for how often presence information should be refreshed. For example, if presence information looks more than one hour old, it could be considered outdated. (A notification made for this presence information won't take anywhere near that long to reach a watcher, and if a presentity hasn't refreshed its presence state in the last hour, it's probably offline 👻)

7. Internationalization Considerations 🌍

okay so for internationalization, all processors conformant to this specification MUST be able to generate and accept UTF-8 encoding 💖 That's one of the mandatory character encodings for XML conforming processors, and it's also required by the policies set out in RFC 2277 [RFC2277].

Other character encodings MAY be accepted, but CPP compliant processors are strongly discouraged from emitting anything other than UTF-8 🫶

8. References 📚

The reference entries weren't included in the passage I was given, so I'm not going to make any up. This heading is just a placeholder until the list shows up 🙈

8.1. Normative References 📚✨

okay so these are the docs this spec literally can't work without, bestie 🫶

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
  • [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>
  • [MIME] This one is a whole family 👯‍♀️ Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
    • Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
    • Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
    • Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
    • Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
  • [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, March 1995.
  • [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
  • [XML-NS] Bray, T., Hollander, D., and A. Layman "Namespaces in XML", W3C recommendation: xml-names, 14 January 1999, <http://www.w3.org/TR/REC-xml-names>
  • [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
  • [URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
  • [XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
  • [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
  • [XMLSchema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.

8.2. Informative References 💡

these ones are just good background reading, no pressure 🌸

  • [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
  • [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
  • [CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
  • [CPP] Peterson, J., "Common Presence for Presence (CPP)", RFC 3859, August 2004.
  • [vCard] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
  • [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
  • [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.

Appendix A. Document Type Definitions 🧚

okay so this bit is the DTD for the application/pidf+xml format 💜 it's only here as a friendly little reference for anyone who isn't super familiar with XML Schema, so don't panic if it looks unfamiliar 🙈

heads up: the DTD does NOT show where extension elements can be added. for that info you need the XML Schema 🎀
<!ENTITY % URL         "CDATA">
<!ENTITY % URI         "CDATA">
<!ENTITY % TUPLEID     "CDATA">
<!ENTITY % DATETIME    "CDATA">
<!ENTITY % VALUETYPE   "CDATA">
<!ENTITY % PRIORITY    "CDATA">
<!ENTITY % NOTE        "CDATA">

<!ELEMENT presence ((tuple*),note?)>
<!ATTLIST presence
          xmlns     %URI;     #REQUIRED
          entity    %URL;     #REQUIRED
>

<!ELEMENT tuple (status,contact?,note?,timestamp?)>
<!ATTLIST tuple
          id   %TUPLEID;      #REQUIRED
>

<!ELEMENT status (basic?)>
<!ELEMENT basic CDATA>

<!ELEMENT contact %URL;>
<!ATTLIST contact
          priority %PRIORITY; #IMPLIED
>

<!ELEMENT note %NOTE;>

<!ELEMENT timestamp %DATETIME;>

Authors' Addresses 🫶

meet the team behind it, they're literally the best 💖

Hiroyasu Sugano
Fujitsu Laboratories Ltd.
64, Nishiwaki
Ohkubo-cho
Akashi 674-8555
Japan

EMail: sugano.h@jp.fujitsu.com


Shingo Fujimoto
Fujitsu Laboratories Ltd.
64, Nishiwaki
Ohkubo-cho
Akashi 674-8555
Japan

EMail: shingo_fujimoto@jp.fujitsu.com


Graham Klyne
Nine by Nine

EMail: GK@ninebynine.org


Adrian Bateman
VisionTech Limited
Colton, Staffordshire, WS15 3LD
United Kingdom

EMail: bateman@acm.org


Wayne Carr
Intel Corporation
2111 NE 25th Avenue
Hillsboro, OR 97124
USA

EMail: wayne.carr@intel.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA  94520
USA

Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz

the legal bit, but make it make sense 🌈

Copyright (C) The Internet Society (2004). 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 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 🔐

so basically, the IETF doesn't take a side on whether any patents or rights apply to the tech in here, and it hasn't checked for any either 👀 the procedures for rights in RFCs live in BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or results from trying to get a general license for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

thank you to the folks keeping the RFC Editor running! 🙏 funding for that function is currently provided by the Internet Society 💜

📦 where this page comes from