RFC 4479
A Data Model for Presence
A Data Model for Presence 💖🎀
okay bestie, this is RFC 4479 🦋 It's a Standards Track doc from the Network Working Group, written by J. Rosenberg at Cisco Systems, dated July 2006. It doesn't obsolete or update anything, since the header doesn't list any. It's giving foundation, and it's the presence data model that SIMPLE presence agents use in SIP land 🧚
This is part 1 of 9. More parts are coming, so stay tuned 💅
Status of This Memo ✨
okay so this doc is an Internet standards track protocol for the Internet community 👑 It's open for discussion and suggestions for improvements, so send your feedback 💌 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited, so share it with everyone 🌸
Copyright Notice 🌈
Copyright (C) The Internet Society (2006). Mood 🫶
Abstract 💜
this doc defines the underlying presence data model that Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents use 🦋 It gives you guidance on mapping all sorts of communications systems into presence documents in a consistent way, which is so important 🙈
Table of Contents 🍓
1. Introduction ....................................................2
2. Definitions .....................................................3
3. The Model .......................................................5
3.1. Presentity URI .............................................6
3.2. Person .....................................................7
3.3. Service ....................................................8
3.3.1. Characteristics .....................................9
3.3.2. Reach Information ..................................10
3.3.3. Relative Information ...............................13
3.3.4. Status .............................................13
3.4. Device ....................................................15
3.5. Modeling Ambiguity ........................................17
3.6. The Meaning of Nothing ....................................19
3.7. Status vs. Characteristics ................................19
3.8. Presence Document Properties ..............................20
4. Motivation for the Model .......................................21
5. Encoding .......................................................22
5.1. XML Schemas ...............................................24
5.1.1. Common Schema ......................................24
5.1.2. Data Model .........................................25
6. Extending the Presence Model ...................................26
7. Example Presence Document ......................................26
7.1. Basic IM Client ...........................................27
8. Security Considerations ........................................29
9. Internationalization Considerations ............................29
10. IANA Considerations ...........................................30
10.1. URN Sub-Namespace Registration ...........................30
10.2. XML Schema Registrations .................................31
10.2.1. Common Schema .....................................31
10.2.2. Data Model ........................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................321. Introduction 🎀
okay so presence is basically about a user's ability and willingness to communicate across a bunch of devices 📱💻 RFC 2778 [10] gives a model and terminology for describing systems that provide presence info, and RFC 3863 [1] defines an XML [5] [6] [7] document format for representing it 🧚 In those specs, presence info is modeled as a series of tuples. Each tuple has a status, a communications address, and other markup. BUT neither spec tells you what a tuple is actually supposed to model, or how to map real-world systems (especially ones built around the Session Initiation Protocol (SIP) [11]) into a presence document 😭
the tea is that a few important concepts aren't clearly modeled or well delineated in RFCs 2778 and 3863. They are:
- Service: a communications service, like instant messaging (IM) or telephony, is a system for interaction between users that provides certain modalities or content 💬
- Device: a communications device is a physical component a user interacts with to make or receive communications. Examples are a phone, PDA, or PC 📱
- Person: a person is the end user, and for presence purposes, they're characterized by states like "busy" or "sad" that impact their ability and willingness to communicate 🥹
this spec fills in the gaps by defining these concepts more fully through a presence data model. It also concretely defines how to take real-world systems and map them into presence documents using that model. The data model is defined as an extension to RFC 3863 ✨
2. Definitions 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9]. Those are the important vibes, so read them carefully 🫶
this doc uses a bunch of new terms on top of the ones from RFC 2778 and RFC 3863. Here's the lineup:
- Device: a device models the physical environment where services show up for users. Devices have characteristics that help a user pick which communications service to use 📱
- Service: a service models a form of communication you can use to interact with the user 💬
- Person: a person models the human user and their states that matter to presence systems 🧚
- Occurrence: a single description of a particular service, a particular device, or a person. There can be multiple occurrences for a particular service or device, or multiple person occurrences in a Presence Information Data Format (PIDF) document, when there's ambiguity that's best resolved by the watcher 👀
- Presentity: a presentity combines devices, services, and person info for a complete picture of a user's presence status on the network 👑
- Presentity URI: a URI that acts as a unique identifier for a presentity and gives you a handle for getting presence info about that presentity 🔗
- Data Component: one of the device, service, or person parts of a presence document 🧩
- Status: presence info about a service, person, or device that typically changes over time, in contrast to characteristics, which are generally static ⏰
- Characteristics: presence info about a service, person, or device that's usually fixed over time and descriptive in nature. Characteristics give context that identifies the service or device as different from another one 🪪
- Attribute: a status or characteristic. It represents a single piece of presence info 🌸
- Presence Attribute: a synonym for attribute 💖
- Composition: the act of combining a set of presence and event data about a presentity into a coherent picture of that presentity's state 🌈
3. The Model 🦋
okay the diagram is giving main character energy, so here it is in all its glory 😭
+----------------------------------------------------------------+
| |
| +----------------+ |
| +----------------+| |
| | || |
| | || |
| | Person || |
| | ||\ |
| /| |+ \ |
| / +----------------+ \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| V V V |
| +----------------+ +----------------+ +----------------+ |
| +----------------+| +----------------+| +----------------+| |
| | || | || | || |
| | || | || | || |
| | Service || | Service || | Service || |
| | || | || | || |
| | |+ | |+ | |+ |
| +----------------+ +----------------+ +----------------+ |
| \ / \ |
| \ / \ |
| \ / \ |
| V V V |
| +----------------+ +----------------+ |
| +----------------+| +----------------+| |
| | || | || |
| | || | || |
| | Device || | Device || |
| | || | || |
| | |+ | |+ |
| +----------------+ +----------------+ |
| |
| |
| Presentity (URI) |
+----------------------------------------------------------------+
Figure 1so the data model for presence is shown in Figure 1 ✨ It's all about the presentity, which you identify with a presentity URI 🔗 There are three components: the person, the service, and the device 🧚 Each one holds info (called attributes) that describes some aspect of that service, person, or device 💜
here's the big idea 🔥: every attribute is affiliated with the service, person, or device it describes, because it describes them. That's different from a model where attributes are associated with something just because that thing reported them. For example, if a cell phone reports that a user is in a meeting, that info goes in the person part as a status of "in-a-meeting". The presence info can also include info about the cell phone as a device. Even though the device is the one reporting the meeting, "in a meeting" is a fact about the human, not their phone 🙈 So that attribute goes in the person component of the document 💅
(more coming in part 2 bestie, don't go anywhere 🫶🌈)
3.1. Presentity URI ✨
Okay so the presentity (the person or thing being described) gets its identity as a URI 💖. For every unique presentity on the network there's one or more presentity URIs, because a single presentity can be identified by a URI from the Presence (pres) scheme [12] and by a protocol-specific URI, like a SIP URI [11] or an Extensible Messaging and Presence Protocol Internationalized Resource Identifier (XMPP IRI) [13]. Or it's because a user has a bunch of aliases in one domain, and they're all equivalent identifiers for the same presentity 🦋.
When a document gets constructed, the presentity URI is ideally set to whatever identifier was used to request the document in the first place 🎀. For example, if a document was requested through a SIP SUBSCRIBE request, the presentity URI would match the Request URI of that SUBSCRIBE request. This is the principle of least surprise, bestie 🙈, because the entity asking might not even know about the presentity's other identifiers.
Irrespective of which scheme the URI comes from, the presentity URI is independent of any services or devices the presentity has 💅. But the URI is not just a name! It represents a resource that you can subscribe to in order to find out the status of the user ✨. When the URI is a SIP URI, it'll often be the Address of Record for the user, which is where SIP calls get directed. This equivalence isn't mandated by this specification, but it's a recommended configuration because it makes remembering and storing identifiers for users way easier 🧚.
3.2. Person 🌸
The person data component models the information about the user that the presence data is trying to describe. This info includes the user's characteristics and their status 💜.
Characteristics of a person are the static info about a user that doesn't change under normal circumstances 🍓. This could include physical traits, like age and height. Another example is an alias. An alias is a URI that identifies the same user but has a different presentity URI. Like, a presentity sip:bob@example.com might have a presence document with a person component that lists aliases of sip:robert@example.com and sip:r.smith@example.com 👑.
Status information about a presentity is the dynamic info about a user 🦋. This typically covers things the user is doing, places the user is at, feelings the user has, and so on. Examples of typical person status are "in a meeting", "on the phone", "out to lunch", "happy", and "writing Internet Drafts" 🔥. The line between static and dynamic status info is fuzzy, and it's not important to draw one. The model does not differentiate in a syntactically or semantically meaningful way between these two types of attributes 🤷♀️.
In the model, there can be only one person component per presentity 💅. In other words, the person component models a single human being, and includes the characteristics and statuses related to the communication states for that one human. Of course, the system has no way to verify that the human described by the person component is actually a single human being, as opposed to a group of users, or even a dog for that matter 🐶. As the saying goes, "on the Internet, no one knows you are a dog," and the same is true here 💀. The person component is a facade for a single person; anything that can be made to look like a single person can be modeled with that facade ✨.
Here's a fun one: picture using a presence document to describe a customer support help desk 🎧. The person component can be considered "busy" if none of the support staff are available, and "at lunch" if the help desk department is having a group lunch together 🥪. The watcher that receives the document will treat the help desk as a single person. Nothing in the document (except maybe the note element, if its value is "help desk" or something similar) tells the watcher that the person is actually a help desk 😭.
However, there can be multiple occurrences of the person component 🌈. This happens when the state of the person component is ambiguous, as discussed in Section 3.5 🫶.
3.3. Service 💖
Each presentity has access to a number of services 📱. Each one represents a point of reachability for communications that can be used to interact with the user. Examples are telephony (aka traditional circuit-based telephone service), push-to-talk, instant messaging, Short Message Service (SMS), and Multimedia Message Service (MMS) 💬.
Honestly, it's hard to give a precise definition for service 🙃. One reasonable approach is to model each software or hardware agent in the system as a service. So if a user starts a softphone app on their PC, that's a service. If a user has a videophone device, that's another service. This is basically a physical view of services 🖥️. But this definition starts to fall apart when a service is spread across multiple software agents or devices. For example, a SIP URI representing an address-of-record can be routed to a softphone, a videophone, or both 📞. In that case, you might try defining a service based on its address on the network instead. This definition also falls apart when you're modeling devices or apps that receive calls and dispatch them to different "helpers" based on potentially complex logic 🧠. For example, a cellular telephone might house multiple SIP applications, each of which can "register" different handlers based on the method or even the body type of the request. Each of those applications or handlers can rightfully be considered a service, but it doesn't have an address on the network that's distinct from the others 🌸.
Because defining a service precisely is so tricky 😩, the data model doesn't try to constrain what can count as a service. Instead, anything can be considered a service as long as it has a set of key properties defined by this model ✨. Specifically, each service is associated with characteristics that identify its nature and capabilities, reach information that indicates how to connect to it, status information representing its state, and relative information that describes how it relates to other services associated with the presentity 🎀.
As a result, services aren't explicitly enumerated in this model 🙌. There's no central registry where you can find identifiers for each service. That also means each service doesn't have a single "service" attribute with values like "ptt" or "telephony". That doesn't mean those consolidated monikers aren't useful, though! They're an essential summary of what the service is 💜. That kind of summarization is handy for making icons that let a user choose one service over another 🖼️. A watcher is free to create its own summarization from any of the info associated with a service. The reach information often gives you great material for that 🦋. Oftentimes, the scheme of the URI is synonymous with what a service is. An sms URI [14] clearly indicates SMS, for example 💌. For some URIs, though, there may be many services available, like with SIP or tel [15], so the scheme is less meaningful as a way to summarize 🤔. The reach information could also indicate that certain application software has to be invoked (like a videogame 🎮), in which case that part of the reach information would be useful for generating an iconic representation of the game 👾.
3.3.1. Characteristics ✨
Okay so every service gets characteristics that describe what it's like and what it can do when a watcher hits its URI 💖 The nature of a service is a set of properties that stay pretty much the same across sessions made to that service, and it tends to be descriptive. Like, it could be an interactive voice response or voicemail server, an automaton, or a telephony service used for work 📞 Capabilities are different. They're properties that might show up, and whether they do depends on negotiation and other dynamic stuff that happens during session establishment. Examples are the type of media that might be used, the directionality of communications that are permitted, the SIP extensions supported, and so on. Capabilities can get super complex! For instance, RFC 2533 [16] describes a model for representing capabilities through N-ary boolean functions 🧠 It's hard to tell a capability with one modality (like "this service only does voice") apart from a characteristic that represents the nature of a service. But honestly? It's not important to do so 🙈
Characteristics matter when multiple services are indicated. Why? Because listing multiple services in a presence document is all about giving the watcher a choice. The presentity is basically saying "hey, you can reach me through a bunch of different services!" 💅 To help the watcher pick, the presence document includes characteristics of each service that help tell the services apart and give the watcher the context they need to choose.
Capabilities exist mainly to facilitate choice, so they do not impose a requirement on how a user reaches the service. 🦋 For example, if a presence document includes two services, and one supports audio only while the other supports only video, that does not mean that when contacting the first service a user has to offer only an audio stream, or when contacting the second a user has to offer only a video stream. A user can use local policy at its discretion to decide what capabilities or communications modalities are offered when they connect with a service. And a watcher doesn't need to add SIP caller preferences [2] to request routing of the request to a service with the characteristics described in the presence document. Lowkey a huge relief 🫶
If, in order to reach a service, the user agent must generate a request that exhibits a particular capability or contains a specific header, then this is indicated separately in the reach information, described below.
One important characteristic of each service is the list of devices on which that service executes. Each device is identified uniquely by a device ID, so the service characteristics can include a list of device IDs 🎀 A presence document might also contain information on each device, but that's a separate part of the document. Indeed, the information on each device might not even be present in the document! In that case, the device IDs listed for each service are nothing more than correlation identifiers, useful for figuring out when two services run on the same device. The benefit of this model is that device information can be filtered out of a presence document, yet the service information, which includes the device IDs, stays useful and meaningful ✨
It's perfectly valid for a presence document to contain just a single service. This is permitted even if the presentity actually has multiple services at their disposal. The lack of multiple services in the document merely means the presentity isn't offering a choice to the watcher. In that case, the service characteristics are less important, but may still help a watcher decide whether they want to communicate at all 🌸
3.3.2. Reach Information 🗺️
The reach information for a service gives the recipient of a document the instructions for correctly contacting that service.
When a service is accessible over a communications network, reach information includes a URI that can be "hit" to access the service. This URI is called the service URI. However, some services aren't accessible over a communications network (like in-person communications or a written letter), so they may not use a URI 💌
Even for services reachable over a communications network, the URI alone may not be enough. For example, two applications may be running within a cellular telephone, both reachable through the user's SIP Address of Record. But one application launches when the INVITE request contains a body of a particular type, and the other launches for other body types 📱 As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In that case, even though the communications between instances use a standard protocol (such as SIP), the user experience won't be correct unless the applications are matched 😭
When the URI isn't sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information 🚫
Reach information is a big deal for the service! When the watcher decides which service of the presentity they want to access, they use the reach information for that service. So each service has to have a unique set of reach information. If that weren't the case, the user would have no way to choose between the services. This means reach information represents a unique identifier for the service. However, a presence document can contain multiple occurrences of a particular service, each of which contains the same reach information but differs in its occurrence identifier. Multiple occurrences of a service exist in a document when the state of the service is ambiguous, as discussed in Section 3.5 🧩
Because reach information serves as an identifier for a service, it's also a way to figure out whether a communications capability should be represented as one service or more. Something can't be a service unless there's a way to reach it separately from another service. Take a softphone application that is capable of audio and video. It is not possible to describe this softphone as two services, one capable of just audio and one capable of just video. That's because there's no way to reach the video-only service. For example, sending a INVITE with just a video stream doesn't suffice, since one can always add the audio stream later and it will work. So video and audio, in this case, represent capabilities for a single service 📹🎙️
Reach information represents a weak form of contract. The presentity tells the watcher that, if the watcher utilizes the reach information included in the presence document, the watcher might be connected to a service described by the characteristics included in the presence document. It's important to stress that this is not a guarantee in any way! It can't be one, for two reasons. First, the service in the document might actually be modelling a number of actual services used by the user, and it may not be possible to connect the watcher to a service with all of the characteristics described in the presence document. Second, the preferences of the presentity always take precedence. The caller might ask to be connected to the video service, but it's permissible to connect them to a different service if that's the wish of the presentity 🎭
This loose contract also gives some guidance on the type of URI that's most ideally suited for the service URI. A URN [3] can be used as the service URI. However, since a URN could be resolved to potentially any number of different URIs, the characteristics, status, and relative information need to be sensible for all of the URIs that can be resolved from the URN. As the URN becomes increasingly "vague" in terms of the service it identifies, the number of presence attributes that can be included decreases correspondingly 🌫️
The tel URI [11] shares similar properties with a URN, and the same considerations apply. If, for example, the telephone number exists in ENUM [18] and multiple ENUM services are defined, including voice and messaging, it's likely that very little characteristic information can be included in that service. If, however, a tel URI has only a single ENUM service defined, and it refers to a telephone service on the Public Switched Telephone Network (PSTN), more can be said about its characteristics, status, and relative priority ☎️
It's important to point out that there can be a many-to-one mapping of reach information to a service. That is, a particular service can potentially be reachable through an infinite number of reach information sets. This is true even if the reach information is just the service URI, since it's permissible for multiple service URIs to reach the same service. Within any particular document, for a particular service, there will be a single service URI. However, it's allowed and even valuable to provide different service URIs to different watchers, or to change the service URIs provided to a particular watcher over time. Doing so affords many benefits, in fact! It can allow the recipient of a communications attempt to determine the context for that attempt, meaning that the attempt was made as a result of trying to reach a particular service in a particular presence document. This can be used as a technique for preventing communications spam, for example [19] 🛡️
It's also possible for a presence document to contain a service that has no reach information at all. In such a case, the presentity is indicating that the service exists, but is electing not to offer the watcher the opportunity to connect to it. One such example would be letting a watcher know that a user has a telephony service and that they're busy, but in order to avoid receipt of a call, no reach information is provided 📵
In an ideal system, the URI alone would represent sufficient reach information for each service. A URI is supposed to provide sufficient context for reaching the resource associated with the URI, so in theory there's no need for additional context. However, sometimes additional information is needed. Since reach information has to be understood in order for the service to be utilized, reach information beyond the URI should be defined and used sparingly. Extensions to PIDF that define attributes that are reach information should clearly call those attributes out as such 🌈
3.3.3. Relative Information 💅
okay so every service also gets a priority 🎀, which is basically how much the user prefers one service over another. ngl this does NOT mean the watcher always has to pick the highest-priority service 🙈 because if that were the rule, why would you even list multiple services in the presence document?? the priority is more like saying, "if you can't decide which one to use, or it's not a big deal to you, this is the order I'd like you to reach me in. but I'm giving you a choice 💖" that's the whole vibe. priorities are only relative to each other and don't mean anything as absolute numbers ✨ so if you have two services with priorities of 1 and .5, that's literally the same as .2 and .1 🧚 (same ratio, iykyk).
3.3.4. Status 🦋
each service also has a status 💜. status is the generally dynamic info about whether communications through that service are actually available right now. this is different from characteristics, which describe pretty static properties of each service. the simplest kind of status is the basic status, which is a binary indicator of availability for communications using that service 🌸. it can be either "closed" or "open". "closed" means communication to the service will, in all likelihood, fail, won't reach the intended party, or won't result in communications as described by the characteristics of the service 💀. for example, if a call gets forwarded to voicemail when the user is busy or unavailable, the service is marked as "closed". same thing with a hotel phone number used as a service URI 🏨. after checkout, that number still rings, but it reaches the chambermaid or the next guest, so the presentity would declare it "closed". another one: if a user has a SIP URI pointing to a SIP softphone app, and the PC shuts down, calls to that URI return a 480 response code, and this service would also be declared "closed" 😭. "open" is the opposite. it means communications to this service will likely succeed and reach the desired target 🌈.
it's also possible to have status info that depends on the characteristics of the communications session that eventually gets set up 🔥. for example, a status attribute could say a softphone service is available if instant messaging is used, but unavailable if audio is used.
other status info might give more details on why a service is available or unavailable ✨. for example, a telephony service might have extra status showing that the user is on the phone, or that the user is handling 3 calls for that service 📞.
services have SO much dynamic state 👑. take a wireless telephony service (aka a cell phone). there are tons of dynamic statuses there: whether it's registered, whether it's roaming, which provider it roamed into, its signal strength, how many calls it has, what state those calls are in, how long the user has been in a call, and so on 🤯. an IM service is the same 💅: whether the user is registered, how long they've been registered, whether they have an IM conversation in progress, how many conversations are in progress, whether the user is typing, who they're typing to, and so on.
but not all of that dynamic state belongs inside a service data component of a presence document 🙅♀️. info only gets included when it helps the watcher decide whether to start communicating with that service, or helps them decide when to start it, if not right now 🎯. for example, whether a cell phone has strong signal strength or just good signal strength does NOT pass the litmus test 🧪. knowing that isn't likely to change anyone's decision to use the service, so it's left out 💖.
3.4. Device 📱
okay so devices are basically the physical setups where services actually run 💅 think cell phones, PCs, laptops, PDAs, consumer telephones, enterprise PBX extensions, and operator dispatch consoles. literally all the hardware bestie 🎀
the mapping between services and devices is many to many, and it's giving chaos in the best way ✨ one service can run on multiple devices. like, say you've got a SIP telephony service. two SIP phones can register against a single Address of Record for that service, so the SIP service is linked to two devices 📞 and it goes the other way too. one device can support a bunch of services. a cell phone can do SIP telephony, SMS, and MMS all at once 📱 and a PC can handle a SIP telephony service plus a SIP videophone service 💻 iconic multitasking
now here's the plot twist 🧚 a device can support zero services. in that case the device doesn't have useful presence info all by itself 😭 BUT if other documents describe that same device in relation to a service, you can glue them together and make a richer presence document 🫶 for example, take a Radio Frequency ID (RFID) tag. it's a device, but it doesn't run any services. it still has properties like location, and it might have network connectivity so it can report its status and characteristics 🏷️ now imagine a video telephone reports that it's running a video service, and one of its properties is that it's tagged with that RFID. a compositor can merge the two documents and use the RFID's location to say something about where the video telephony device is 🗺️ that's a whole glow-up
okay, device IDs next 🎀 a device ID is a URI that's a globally and temporally unique identifier for the device. specifically, a device ID is a URN. it has to be unique across all other devices for a particular presentity. it's also super desirable for it to be persistent across time, globally unique, and computable, so different systems are likely to refer to the same device with the same ID 💖 with those properties, presence info from different sources based on device status can be combined. the last one, being readily computable, is the MVP 👑 it lets a compositor combine totally different sources of info about one device, because they're all linked by a shared device ID that each source figured out on its own
the tea is that there's no single URN scheme that has all these properties, because there are sooo many kinds of devices 🙃 it's expected that multiple schemes will be defined, with different ones fitting different device types. for cellular telephones, the Electronic Serial Number (ESN) is a good identifier 📲 for IP devices, the MAC address is another good one 🌐 the MAC address is readily computable, but it's not persistent over time, since it would change if the interface card on the device got swapped 😬 for now, neither of these is tied to a URN scheme. in the meantime, the Universally Unique IDentifier (UUID) URN [20] can be used 🦋 for devices with a MAC address, version 1 UUIDs are RECOMMENDED, because they give you a time-based identifier that uses the MAC address 🕰️ for devices without a MAC, a version 4 UUID is RECOMMENDED. it's purely random, which gives you uniqueness 🎲 the UUID for a device would usually be picked at fabrication time and then saved in the device's flash or some other non-volatile storage 💾 the UUID URN is globally and temporally unique, but because of its random part it's not at all readily computable, so it's useless as a correlation ID with other presence sources on a network 💀 future specs are expected to bring in better device IDs, so stay tuned 🌈
even though each device has one unique device ID, a particular device can show up multiple times in a document ✨ each occurrence shares the same device ID but has its own occurrence identifier. this happens when the state of the device is ambiguous, which we get into in Section 3.5 🔍
this document doesn't mandate a particular implementation approach 🙏 but the device ID is most useful when every service on the device can get the device ID and get the same value 🫶 that's an argument for putting it in the operating system as a feature. OS developers who want to implement this spec are encouraged to provide APIs so applications can get the device ID 🍓 without those APIs, apps that report presence about their devices would have to generate their own device IDs, which means they might pick different IDs using different algorithms or data 😵 at worst, two services running on the same device might not appear to be on the same device at all 🙈
like services and person data components, device data components have generally static characteristics and generally dynamic status 🌸 characteristics are the device's physical dimensions and capabilities, like display size, CPU speed, and memory amount 📐 status is the dynamic stuff, like whether the device is on or off, how much battery is left, its geographic location, and so on 🔋
characteristics and status are there so the user can choose a service based on what the device is 🎀 they can't reliably be used to figure out what the service will be like on that device 🚫 for example, if the characteristics say the CPU is fast enough for high-quality video compression, that does NOT mean video quality will be good for a video service on that device, because other constraints on the system might reduce how much CPU the service gets 🙅♀️ if you want to say that higher-quality video is available on a device, you should include service characteristics that say exactly that 📺 the CPU speed might help a watcher tell a PC apart from a cell phone, though, say if the watcher wants to call the user's cell phone 📞
same deal with dynamic device status like on or off: if it affects the state of the service, you show that by adjusting the state of the service 🔄 unless a presence document consumer has a priori knowledge saying otherwise (presence agents often do, ngl), the state of a device has no bearing on the state of the service 🤷♀️
just like services, there's no enumeration of device types. no official list of PCs, PDAs, cell phones, etc. 🙅 instead, the device is defined by its characteristics, and a watcher can figure out whether it's a PDA, a cell phone, or whatever from those 🧠 very detective energy
important reminder: the device is a model of the underlying physical systems where services run 🪞 nothing says you can't use this model for systems where services run inside virtualized systems instead of real ones 🖥️ for example, if a PC is running a virtual machine and services are running inside that VM, it's totally fine to use this model and say the PC is made up of two separate devices 🤯 two devices, one PC, zero drama 💖
3.5. Modeling Ambiguity 🌀
okay, ambiguity is a real part of presence systems, and this spec models it explicitly 🫶 ambiguity happens when there are multiple pieces of info about a person, a particular device, or a particular service 😳 it naturally shows up when multiple elements publish info about the same person, service, or device. sometimes a compositor can resolve it automatically and combine the data about the person, device, or service into one coherent description ✨
other times it can't, maybe because the compositor just isn't able to do it 🤖
but in lots of cases, resolving the ambiguity is best left to the watcher who consumes the document 👀 that consumer could be an app with more info than the compositor, so it can do a better job 📊 or the info could be shown to a human, who can often sort it out 🙋♀️ honestly, a human can usually do this way better than a robot can 💅
to model ambiguity, the model lets each service, each device, or the person component contain multiple occurrences 🎀 each occurrence has a unique identifier called the occurrence identifier 🪪 that identifier is unique across all other occurrence identifiers for any service, device, or person. the scope is all the services, devices, and person elements for a particular presentity 🌍 ideally it persists over time, because it's a super valuable handle for setting composition and authorization policies 🔐 and even if there's only one occurrence for a device, service, or person, that occurrence still gets an occurrence identifier 💜
don't mix up the occurrence identifier with the instance ID defined in the SIP Outbound specification [27] 🙅♀️ a user agent instance is best modeled as a service, and a Globally Routable User Agent URI (GRUU) [22], which is derived from the instance ID, is a reasonable choice for a service URI 🦋 BUT if the status of such a UA instance can't be determined unambiguously, a presence document can include two or more occurrences of the service modeling that UA instance 🌈 in that case, each occurrence has a unique occurrence ID, but they all share the same service URI and, as a result, the same instance ID 🫠
when a document has multiple occurrences, it's really important that some attributes of the device, service, or person help the recipient resolve the ambiguity 🧩 for humans, the note field and timestamp are valuable tools 📝 for an automaton, pretty much any attribute of the device, service, or person can be used to resolve it 🤖 the timestamp is especially useful for both humans and automatons ⏰ as described in RFC 3863 [1], the timestamp gives the time of the most recent change for the tuple 🕓 this spec also defines the timestamp for person and device components, with the same meaning 💖 without other info, the person, device, or service that most recently changed can be treated as the more reliable source of data 🏆 BUT this resolution algorithm is not normatively required in any way, so do what makes sense for your system 🙌
3.6. The Meaning of Nothing 🫥
okay so this one is a total mind-bender 🤯 When a presence attribute shows up in a document, it tells a watcher something about its value. But what does it say when an attribute is just... missing? This data model follows the lead of RFC 3840 [17], which defines capabilities for SIP user agents. In that spec, if a capability declaration leaves out a particular feature tag, the agent is making no definitive statement either way about whether that feature tag is supported. Same energy here 💅 The absence of a presence attribute means a watcher cannot make any definitive statement about the value of that attribute. It might be missing because it's being withheld from the watcher, or because the presentity's software doesn't support it at all. Neither conclusion can be drawn 🙈
Because a missing attribute conveys no information whatsoever (zero, nada, nothing 💀), presence documents hit peak value when they have as many presence attributes as possible ✨ So it is RECOMMENDED that a presence document contain as many presence attributes as the presentity is willing to and able to provide to a watcher 🫶
3.7. Status vs. Characteristics 🎀
the data model tries to separate status info from characteristics, mostly by defining status as a relatively dynamic state about a person, device, or service, while a characteristic is relatively static. BUT ngl this line is kinda fake 😭 Almost any characteristic can change over time, and sometimes characteristics change pretty fast too. So the split between status and characteristics is really just a concept to help us understand the different types of presence info. Nothing in a presence document says whether an element is a characteristic vs. a status, and when a presence attribute is defined, it doesn't need to be labeled as one or the other. Presence documents let any presence attribute change at any time, whether you think of it as a characteristic or a status 🦋
Unfortunately, the original PIDF specification did have a separate part of a tuple for describing status, and the basic status was defined to live inside that part. This specification does not change PIDF; however, all future presence attributes MUST be defined as children of the <tuple> and not the <status> element. Furthermore, the schemas defined here do not contain a <status> element for either the <person> or <device> elements. bestie, that's the plot twist 🍓
3.8. Presence Document Properties 🧁
the overall presence document has a few important properties that are essential to this model, and they're honestly so cool 🌈
First, a presence document has a concrete meaning that doesn't depend on how it's transported or where it's found. The semantics are the same whether a document is published by a presence user agent to its compositor, or distributed from a presence agent to watchers. There are no required or implied behaviors for a recipient of a document. Instead, the document itself has well-defined semantics, and a recipient can take whatever actions it chooses based on those semantics 💖
A corollary of this is that presence systems are infinitely composeable 🧚 A presence user agent can publish a document to its presence server. That server can compose it with other documents and put the result in a notification to a watcher. And that watcher can be another presence agent, combining that document with others it has received and placing those results in yet another notify. it's like a presence Russian doll 🪆
Yet another corollary is that implied behaviors in reaction to the document can never be assumed. For example, just because a service indicates that it supports audio does NOT mean a watcher will offer audio in a communications attempt to that service. If doing so is necessary to reach the service, this must be indicated explicitly through reach information. no guessing allowed, periodt 🙅♀️
It's also important to get that the whole point of the presence document is to help a user pick a service from a set, and to know ahead of time, with as much certainty as possible, whether a communications attempt will succeed or fail. Success is a combination of many factors: Does the watcher understand the service URI? Can it act on all of the reach information? Does it support a subset of the capabilities associated with the service? Does the person information indicate that the user is likely to answer? All of these checks should ideally be made before attempting communication 👑
Because the presence document helps a user choose and establish communications, the presentity URI, as the index to that document, acts as a form of "one-number" communications 📞✨ Starting from this URI, all of the communication modalities and their URIs for a user can be discovered, and then used to invoke a particular communications service. Instead of handing out a separate phone number, email address, IM address, Voice over Internet Protocol (VoIP) address, and so on, you can just give out the presentity URI, and everything else can be learned from there. one link, all the vibes 🫧
4. Motivation for the Model 🌸
presence is defined in [21] as the ability, willingness, or desire to communicate across a set of devices. The core of that definition is conveying information about the ability, willingness, or desire for communications. So the presence data model needs to be shaped around conveying info that achieves this goal 🎯
the person data component is targeted at conveying willingness and desire for communications. It represents information about the users themselves that affects their willingness and desire to communicate. Whether I'm in a meeting, whether I'm on the phone: each of these says something about my willingness to communicate, so it makes sense to include them in a presence document 📝
The service component of the data model aims to convey information about the ability to communicate. That ability is defined by the services a user can be reached through, so including them is essential 💅
How do devices fit in? For a lot of users, devices represent the ability to communicate, not services. People say stuff like, "Call me on my cell phone" or "I'm at my desk" 📱 These are statements of preference for communicating through a specific device, as opposed to a service. So it's our expectation that users will want to represent devices as part of the presence data 🌷
And the concept of device adds the ability to correlate services together, which is so clever 🧠 The device models the underlying platform that supports all of the services on it, so its state impacts all of those services. For example, if a presence server can determine that a cell phone is off, that says something about the services running on it: they're all unavailable. So if services include indicators about the devices they run on, device state can be obtained and used to compute the state of the services on that device 🔥
The data model tries hard to keep device, service, and person as separate concepts. Part of that differentiation is that many attributes apply to some of these but not others. For example, geographic location is meaningful for a person (the user has a location) and for a device (the device has a location), but not for a service, since services don't inherently have locations 🗺️ Based on this, geographic location information should only appear as part of a device or person, never a service. It's also possible, and meaningful, for location info to be conveyed for both a device and a person, and for those locations to be different. The fact that a presence system might try to figure out the person's location by extrapolating from one of their devices' locations is irrelevant from a data modeling perspective. Person location and device location are not the same thing 🙃
[25] defines the <geopriv> XML element for conveying location information, and indicates that it's carried as a child of the <tuple> element in a PIDF document. [25] was developed before this specification, and unfortunately, its recommendation to include location objects underneath <tuple> runs contrary to the recommendations here 😩 So implementations based on this specification SHOULD include <geopriv> location objects as part of the person and/or device components of the document, but SHOULD be prepared to receive presence documents with that object as a child of <tuple>. A <geopriv> location object would be included in a person component when the document means to convey the location of the user, and within a device component when it means to convey the location of the device 📍🎀
5. Encoding 🎀
Okay so bestie, this is where the model gets turned into actual bytes on the wire 💅. Information shaped like the data model above has to be mapped into an on-the-wire format so it can be transported and stored. The Presence Information Data Format [1] is the one used for presence data, no cap.
The <presence> element holds the presence info for the presentity, and its entity attribute carries the presentity URI 🦋.
The existing <tuple> element in the PIDF document is used to represent the service. This matches what RFC 2778 and RFC 3863 were going for in the first place, and it keeps things backward compatible with implementations built before this model was finished 🥹. The <contact> element inside <tuple> is used to encode the service URI. New presence attributes, whether they show dynamic status or static characteristics, appear directly as children of <tuple> ✨. However, attributes that were defined before this spec was published as children of <status> (like <basic>) stay as children of <status> for backward compatibility. So a presence attribute describing a service could show up as a child of <status> or directly as a child of <tuple>, but never both 💀.
The id attribute of <tuple> conveys the service occurrence. Each <tuple> with the same <contact> URI represents a different occurrence of that particular service 🫶.
This spec introduces <person>, which can be a child of <presence>. There can be zero or more of these per document. Each one has a mandatory id attribute holding the occurrence identifier for that person. Each <person> contains any number of elements showing status and characteristic info, followed by zero or more optional <note> elements and an optional <timestamp>. Multiple <note> elements would appear to convey the same note in multiple languages 🌈.
RFC 3863 defines a <note> element, and zero or more of those can be present as a child of <presence> 📝. In the context of the model defined here, these <note> elements, if they're in a document, apply to all person occurrences that don't have any <note> elements of their own. In other words, if a <person> has one or more <note> elements, those are its notes 🙌. If a <person> doesn't have any of its own <note> elements, the <note> elements that are direct children of <presence> are the notes for that <person>. If there are no <note> elements underneath the <person> and no <note> elements that are direct children of <presence>, then that <person> has no notes at all 🫠.
This specification also introduces <device>, which can appear as a child of <presence>. There can be zero or more of these per document. The <device> element can appear either before or after the <person> element, because there are no constraints on order 🔄. Each <device> has a mandatory id attribute holding the occurrence identifier for that device. Just like <person>, <device> contains any number of elements showing status and characteristic info. It's then followed by <deviceID>, which contains the URN for the device ID for this device. After that come zero or more optional <note> elements and an optional <timestamp>. Multiple <note> elements would appear to convey the same note in multiple languages 🎧.
A client that receives a PIDF document containing <device> and <person> elements, but doesn't understand them (because it doesn't implement this specification), will simply ignore them 🙈. Also, since the semantics of service as defined here line up with the meaning of a tuple in RFC 2778 and RFC 3863, documents using the concepts in this model are compliant with older implementations 🫶.
It's important to note that mapping the presence data model into a PIDF document is merely an exercise in syntax. It's just making the shapes fit into XML, not changing what anything means 🧩.
Presence documents created according to this model MUST be valid, with the following exception. A compositor is permitted to create a presence document that it cannot fully validate, but that otherwise validates when processed according to the lax processing rules allowed by the schema of the compositor. Entities receiving these documents aren't expected to do schema validation; they'd just access the information from the document in the places they were expecting it to be 👀. Implementations SHOULD be prepared to receive documents that are not valid, and extract whatever information from them that they can parse. Ngl, that's a very gracious vibe 🌸.
5.1. XML Schemas
The XML schemas are broken into a common schema, called common-schema.xsd, which contains common type definitions, and the rest of the data model, data-model.xsd 🗂️.
5.1.1. Common Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="Timestamp_t">
<xs:annotation>
<xs:documentation>Timestamp type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>
<xs:simpleType name="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="Note_t">
<xs:annotation>
<xs:documentation>Note type</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:attributeGroup name="fromUntil">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:attributeGroup>
<xs:complexType name="empty"/>
</xs:schema>5.1.2. Data Model
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:pidf:data-model"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/>
<xs:element name="deviceID" type="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="device">
<xs:annotation>
<xs:documentation>Contains information about the
device</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="deviceID"/>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="person">
<xs:annotation>
<xs:documentation>Contains information about the human
user</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Characteristic and status
information</xs:documentation>
</xs:annotation>
</xs:any>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>6. Extending the Presence Model 🌱
So you want to add new presence attributes? Love that for you 🫶. Any extension has to think through the following questions first:
- Is the new attribute applicable to person, service, or device data components? If it applies to more than one, what does it mean in each context? An extension should aim to have each attribute concisely defined for each area of applicability, so that a source can clearly tell which type of data component it should be applied to 🎯.
- Does it belong in a new namespace, or an existing one? Generally, new presence attributes defined within the same specification SHOULD belong to the same namespace 🗃️. Presence attributes defined in separate specifications, but produced in a coordinated way by a centralized administration, MAY be placed in the same namespace. Doing that, however, requires the centralized administration to make sure there are no collisions of element names across those specifications 🚦. Also, if a new extension has elements meant to be placed as children of another element at a point of extensibility defined by
<any namespace="##other">, the new extension MUST use a different namespace than that of its parent elements. Main character rules, no exceptions 👑. - Does the extension itself require extensibility? If so, points of extension MUST be defined in the schema, and SHOULD be done using the
<any namespace="##other">construct 🧩.
7. Example Presence Document 🧚
Okay, this is my favourite bit 😭. In this section we look at an example of a physical system, present the model of that system using the concepts described here, and then show the resulting presence document. The example makes use of presence attributes defined in [23] and [24] 💜.
7.1. Basic IM Client
okay bestie, picture this 💖 a provider runs a service that's basically giving AOL, Yahoo!, and MSN instant messaging vibes ✨. Every user has a "screen name" that identifies them in the service. Usually one client, generally a PC app, is connected at a time 💻. When that client connects, the fact gets shared with the other watchers of that user 🦋. The user can set a textual note describing what they're doing, and the watchers see it 🌸. They can also pick one of several status messages (busy, in a meeting, etc.), which are pre-defined notes the system already understands 🎀. If they don't touch the keyboard for a while, their status flips to idle on everybody's screens 🙈, and the system shows how long they've been idle ⏳.
Whenever someone is connected, they can receive instant messages 💌. They can also go "invisible", which makes them look offline to other users 👻. But any IM sent to them still gets delivered, so invisible doesn't mean unreachable 💅.
This system gets modeled by giving each presentity three data components: person, service, and device 🧚. The person component describes the state of the user, including the note and the pre-defined status messages. Those are info about the human, so they live in the person component. The service tuple represents the IM service, and no characteristics are included. The service URI published by the client is set to the client's Address of Record (AOR). The device component models the PC, and it includes the <user-input> element [23] because the idleness is about the device being used, not the service 💜.
The document the client publishes looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
<caps:servcaps>
<caps:extensions>
<caps:supported>
<caps:pref/>
</caps:supported>
</caps:extensions>
<caps:methods>
<caps:supported>
<caps:MESSAGE/>
<caps:OPTIONS/>
</caps:supported>
</caps:methods>
</caps:servcaps>
<contact>sip:someone@example.com</contact>
</tuple>
<dm:person id="p1">
<rp:activities>
<rp:on-the-phone/>
</rp:activities>
</dm:person>
<dm:device id="pc122">
<rp:user-input>idle</rp:user-input>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device>
</presence>Okay, the separate device element that only carries the idle indicator is actually iconic 👑. The idle indication is really an indicator that the device is idle. By making that explicit, the presence server can use the idle indicator to affect the state of other services running on the same device 🎀. Say there's a VoIP application on the same device too. That app reports its presence state separately, but it says it runs on the same device. Since it said so, the presence server can use that service's status to refine the device's idle indicator 🦋. So if the user is on their VoIP app, the server knows the device is in use, even if the IM app says it's idle. That matters because idleness is usually determined by a lack of keyboard or mouse input, and neither might be used during a VoIP call 📞.
It's also useful in a simpler case. Reporting the idle indicator as part of the device status lets that indicator be used for other services on the same device 🌸. Back to the VoIP app on the same device: if the VoIP app doesn't report any device information, and a watcher isn't given info on the IM service, the presence document sent to that watcher can still include the device status 💖. Because of the device IDs and the device information, the presence server can match the device status reported by the IM application with the VoIP service, and use them together ✨.
8. Security Considerations 🔒
The presence information described by the model defined here is very sensitive 😭. That's why privacy filtering plays a key role in processing presence data. Privacy filtering is the act of applying permissions to a presence document to remove information a watcher isn't authorized to see. More generally, privacy filtering is a form of authorization 🫶. Privacy filtering can also make sure a watcher can't see any presence data for a presentity, and it can even make sure the presentity doesn't know it's being blocked 🙈. The SIP presence specifications (RFC 3856 [21]) require that this authorization processing be performed before presence information is divulged. Specifications have also been defined for conveying authorization policies to presence servers [26].
Integrity of presence information is also critical 🚨. Modification of presence data by an attacker can lead to diverted communications, for example. The protocols used to transport presence data, such as SIP for presence, are used to provide the necessary integrity functions 🔐.
9. Internationalization Considerations 🌍
This specification defines a data model that contains mostly tokens meant for programs to consume, not for humans to read directly 🤖. Programs are expected to translate those tokens into language-appropriate text strings according to the watcher's preferences 🫶.
Here's the thing though: this specification defines a <note> element that can contain free text 📝. This element, and any other elements defined by PIDF extensions that can contain free text, SHOULD be labeled with the xml:lang attribute to indicate their language and script 🌈. This specification allows multiple occurrences of the <note> element, so the presentity can convey the note in multiple scripts and languages 💜. If no xml:lang attribute is provided, the default value is "i-default" [8].
Since the presence model is represented in XML, it has native support for encoding information using the Unicode character set and its more compact representations, including UTF-8 ✨. Conformant XML processors recognize both UTF-8 and UTF-16. XML does have provisions to identify and use other character encodings through an "encoding" attribute in an <?xml?> declaration, but use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists 🎀.
10. IANA Considerations 📋
There are several IANA considerations associated with this specification 💅.
10.1. URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in [4] 🦋.
- URI:
urn:ietf:params:xml:ns:pidf:data-model - Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net)
- XML:
<?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=iso-8859-1"/>
<title>A Data Model for Presence</title>
</head>
<body>
<h1>Namespace for Presence Data Model</h1>
<h2>urn:ietf:params:xml:ns:pidf:data-model</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4479.txt">
RFC4479</a>.</p>
</body>
</html>10.2. XML Schema Registrations
This section registers two XML schemas per the procedures in [4] 🌸.
10.2.1. Common Schema
- URI:
urn:ietf:params:xml:schema:pidf:common-schema - Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net)
The XML for this schema can be found as the sole content of Section 5.1.1 ✨.
10.2.2. Data Model
- URI:
urn:ietf:params:xml:schema:pidf:data-model - Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net)
The XML for this schema can be found as the sole content of Section 5.1.2 💜.
11. Acknowledgements 🫶
This document is really a distillation of many ideas discussed over a long period of time 🕰️. Those ideas were contributed by many participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat, Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam Roach, Hisham Khartabil, and Jon Peterson contributed many of the concepts described here 👑. Example presence documents came from Robert Sparks' example presence documents specification, and the ideas on defining services through characteristics, rather than enumeration, came from Adam Roach's service features document 🎀. A special thanks to Steve Donovan for discussions on the topics covered here, and to Elwyn Davies for his final review of the document 🥹.
12. References 📚
12.1. Normative References
- [1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
- [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
- [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
- [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [5] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.
- [6] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004.
- [7] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
- [8] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
- [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References 📚
Okay, these are the bonus reads that back up the whole doc, bestie 💅 Every one is listed with its number, authors, title, and date:
- [10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
- [11] 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.
- [12] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
- [13] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, December 2005.
- [14] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message Service", Work in Progress, February 2006.
- [15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
- [16] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
- [17] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
- [18] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
- [19] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, March 2006.
- [20] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
- [21] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
- [22] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
- [23] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
- [24] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.
- [25] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
- [26] Rosenberg, J., "Presence Authorization Rules", Work in Progress, March 2006.
- [27] Jennings C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, March 2006.
Author's Address 🦋
Jonathan Rosenberg is the author, and you can find him at Cisco Systems:
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.netFull Copyright Statement 🌈
Copyright (C) The Internet Society (2006).
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 🎀
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. It also doesn't claim to have made any independent effort to identify any such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone who's interested to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💜
Acknowledgement 🌸
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🫶
📦 where this page comes from
- ietf: rfc4479 2006-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms