Network Working Group J. Rosenberg Request for Comments: 4479 Cisco Systems Category: Standards Track July 2006 A Data Model for Presence Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion.
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 ...................................32 RFC 2778  defines a model and terminology for describing systems that provide presence information. RFC 3863  defines an XML    document format for representing presence information. In these specifications, presence information is modeled as a series of tuples, each of which contains a status, communications address, and other markup. However, neither specification gives guidance on exactly what a tuple is meant to model, or how to map real-world communications systems (and in
particular, those built around the Session Initiation Protocol (SIP) ) into a presence document. In particular, several important concepts are not clearly modeled or well delineated by RFCs 2778 and 3863. These are the following: Service: A communications service, such as 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 that a user interacts with in order to make or receive communications. Examples are a phone, PDA, or PC. Person: A person is the end user, and for the purposes of presence, is characterized by states, such as "busy" or "sad", that impact their ability and willingness to communicate. This specification defines these concepts more fully by means of a presence data model, and concretely defines how to take real-world systems and map them into presence documents using that model. This data model is defined in terms of an extension to RFC 3863. RFC 2119 . This document makes use of many additional terms beyond those defined in RFC 2778 and RFC 3863. These new terms are as follows: Device: A device models the physical environment in which services manifest themselves for users. Devices have characteristics that are useful in allowing a user to make a choice about which communications service to use. Service: A service models a form of communication that can be used to interact with the user. Person: A person models the human user and their states that are relevant to presence systems. Occurrence: A single description of a particular service, a particular device, or a person. There may be multiple occurrences for a particular service or device, or multiple person occurrences in a Presence Information Data Format (PIDF) document, in cases where there is ambiguity that is best resolved by the watcher.
Presentity: A presentity combines devices, services, and person information 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 provides a handle for obtaining presence information about that presentity. Data Component: One of the device, service, or person parts of a presence document. Status: Presence information about a service, person, or device that typically changes over time, in contrast to characteristics, which are generally static. Characteristics: Presence information about a service, person, or device that is usually fixed over time, and descriptive in nature. Characteristics are useful in providing context that identifies the service or device as different from another service or device. Attribute: A status or characteristic. It represents a single piece of presence information. 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 the state of that presentity.
+----------------------------------------------------------------+ | | | +----------------+ | | +----------------+| | | | || | | | || | | | Person || | | | ||\ | | /| |+ \ | | / +----------------+ \ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | | V V V | | +----------------+ +----------------+ +----------------+ | | +----------------+| +----------------+| +----------------+| | | | || | || | || | | | || | || | || | | | Service || | Service || | Service || | | | || | || | || | | | |+ | |+ | |+ | | +----------------+ +----------------+ +----------------+ | | \ / \ | | \ / \ | | \ / \ | | V V V | | +----------------+ +----------------+ | | +----------------+| +----------------+| | | | || | || | | | || | || | | | Device || | Device || | | | || | || | | | |+ | |+ | | +----------------+ +----------------+ | | | | | | Presentity (URI) | +----------------------------------------------------------------+ Figure 1
The data model for presence is shown in Figure 1. The model seeks to describe the presentity, identified by a presentity URI. There are three components in the model: the person, the service, and the device. These three data components contain information (called attributes) that provide a description of some aspect of the service, person, or device. It is central to this model that each attribute is affiliated with the service, person, or device because they describe that service, presentity, or device. This is in contrast to a model whereby the attributes are associated with the service, presentity, or device because they were reported by that service, presentity, or device. As an example, if a cell phone reports that a user is in a meeting, this would be done by including an attribute as part of the person information, indicating a status of "in-a-meeting". The presence information may also include information on the cell phone as a device. However, even though it is the device that is reporting that the user is in a meeting, "in a meeting" is a fact that describes the human user, not their physical device. Consequently, this attribute is placed in the person component of the document. 12] and a protocol-specific URI, such as a SIP URI  or an Extensible Messaging and Presence Protocol Internationalized Resource Identifier (XMPP IRI) . Or, it can be because a user has several aliases in a domain, all of which are equivalent identifiers for the presentity. When a document is constructed, the presentity URI is ideally set to the identifier 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 the SUBSCRIBE request. This follows the principle of least surprise, since the entity requesting the document may not be aware of the other identifiers for the presentity. Irrespective of the scheme from which the URI is taken, the presentity URI is independent of any of the services or devices that the presentity possesses. However, the URI is not just a name - it represents a resource that can be subscribed to, in order to find out the status of the user. When the URI is a SIP URI, it will often be the Address of Record for the user, to which SIP calls can be directed. This equivalence is not mandated by this specification, but is a recommended configuration for easing the burden of remembering and storing identifiers for users.
However, there can be multiple occurrences of the person component. This happens in cases where the state of the person component is ambiguous, as discussed in Section 3.5.
they represent an essential summary of what the service is. Such summarization is useful in creating icons that allow a user to choose one service over another. A watcher is free to create such summarization information from any of the information associated with a service. The reach information often provides valuable information for creating such a summarization. Oftentimes, the scheme of the URI is synonymous with the view of what a service is. An "sms" URI  clearly indicates SMS, for example. For some URIs, there may be many services available, for example, SIP or tel , in which case the scheme is less meaningful as a way of creating a summary. The reach information could also indicate that certain application software has to be invoked (such as a videogame), in which case that aspect of the reach information would be useful for generating an iconic representation of the game. RFC 2533  describes a model for representing capabilities through N-ary boolean functions. It is difficult to differentiate a capability with one modality (e.g., this service only does voice) from a characteristic that represents the nature of a service. However, it is not important to do so. Characteristics are important when multiple services are indicated. That is because the purpose of listing multiple services in a presence document is to give the watcher a *choice*. That is, the presentity is explicitly offering the watcher an opportunity to contact them using a multiplicity of different services. To help the watcher make a decision, the presence document includes characteristics of each service that help differentiate the services from each other and give the watcher the context in which to make a choice.
Because their purpose is primarily to facilitate choice, capabilities do not impose a requirement on the way in which a user reaches that service. For example, if a presence document includes two services, and one supports audio only while the other supports only video, this does not mean that, when contacting the first service, a user has to offer only an audio stream, or when contacting the second service, a user has to offer only a video stream. A user can use local policy at its discretion in determining what capabilities or communications modalities are offered when they choose to connect with a service. It is not necessary for a watcher to add SIP caller preferences  to request routing of the request to a service with the characteristics described in the presence document. 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. As such, the service characteristics can include a list of device IDs. A presence document might also contain information on each device, but this is 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 determining when two services run on the same device. The benefit of this model is that information on the devices can be filtered out of a presence document, yet the service information, which includes the device IDs, remains useful and meaningful. It is 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 that the presentity is not offering a choice to the watcher. In such a case, the service characteristics are less important, but may be helpful in allowing a watcher to decide if they wish to communicate at all.
accessible over a communications network (such as in-person communications or a written letter), and as such, may not utilize a URI. Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched 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 such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched. When the URI is not 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. The reach information is an important part of the service. When the watcher makes a decision about which service of the presentity they wish to access, the watcher utilizes the reach information for that service. For this reason, each service has to have a unique set of reach information. If this was not the case, the user would have no way to choose between the services. This means that the 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 the reach information serves as an identifier for a service, it also serves as a way to figure out whether a communications capability should be represented as one service or more. Something cannot be a service unless there is a way to reach it separately from another service. As an example, consider 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 is no way to reach the video-only service; for example, sending a SIP INVITE with just a video stream doesn't suffice, since one can always add the audio stream later and it will work. Video and audio, in this case, represent capabilities for a single service.
The 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 is important to stress that this is not a guarantee in any way. It cannot be a guarantee 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 is permissible to connect them to a different service if that is the wish of the presentity. This loose contract also provides some guidance on the type of URI that is most ideally suited for the service URI. A URN  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  shares similar properties with a URN, and the same considerations apply. If, for example, the telephone number exists in ENUM  and multiple ENUM services are defined, including voice and messaging, it is 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 is 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; it is 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 is 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 - 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 . It is 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 to let a watcher know that a user has a telephony service, and that they are 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, and thus in theory there is no need for additional context. However, sometimes, additional information is needed. Since the 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.
reach the intended party, or will not result in communications as described by the characteristics of the service. As an example, if a call is forwarded to voicemail if the user is busy or unavailable, the service is marked as "closed". Similarly, a presentity may include a hotel phone number as a service URI. After checkout, the phone number will still ring, but reach the chambermaid or the next guest. Thus, it would be declared "closed" by that presentity. As another example, if a user has a SIP URI as their service URI that points to a SIP softphone application, and the PC shuts down, calls to that SIP URI will return a 480 response code. This service would also be declared "closed". "Open" implies the opposite - that communications to this service will likely succeed and reach the desired target. It is also possible to have status information that is dependent on the characteristics of the communications session that eventually gets set up. For example, a status attribute can be defined that indicates that a softphone service is available if instant messaging is used, but unavailable if audio is used. Other status information might indicate more details on why the service is available or unavailable. For example, a telephony service might have additional status to indicate that the user is on the phone, or that the user is handling 3 calls for that service. Services inherently have a lot of dynamic state associated with them. For example, consider a wireless telephony service (i.e., a cell phone). There are many dynamic statuses of this service - whether or not the phone is registered, whether or not it is roaming, which provider it has roamed into, its signal strength, how many calls it has, what the state of those calls are, how long the user has been in a call, and so on. As another example, consider an IM service. The statuses in this service include whether the user is registered, how long they have been registered, whether they have an IM conversation in progress, how many IM conversations are in progress, whether the user is typing, to whom they are typing, and so on. However, not all of this dynamic state is appropriate to include within a service data component of a presence document. Information is included only when it has a bearing on helping the watcher decide whether to initiate communications with that service, or helping the watcher decide when to initiate it, if not now. As an example, whether a cell phone has strong signal strength or just good signal strength does not pass the litmus test. Knowing this is not likely to have an impact on a decision to use this service.
devices. For cellular telephones, the Electronic Serial Number (ESN), for example, is a good identifier. For IP devices, the MAC address is another good one. The MAC address has the property of being readily computable, but lacks persistence across time (it would change if the interface card on a device were to change). In any case, neither of these are associated with URN schemes at this time. In the interim, the Universally Unique IDentifier (UUID) URN  can be used. For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address. For devices without a MAC, a version 4 UUID is RECOMMENDED. This is a purely random identifier, providing uniqueness. The UUID for a device would typically be chosen at the time of fabrication in the device, and then persisted in the device within flash or some other kind of non-volatile storage. The UUID URN has the properties of being globally and temporally unique, but because of its random component, it is not at all readily computable, and therefore useless as a correlation ID with other presence sources on a network. It is anticipated that future specifications will be developed that provide additional, superior device IDs. Though each device is identified by a unique device ID, there can be multiple occurrences of a particular device represented in a document. Each one will share the same device ID, but differ in its occurrence identifier. Multiple occurrences of a device exist in a document when the state of the device is ambiguous, as discussed in Section 3.5. Though this document does not mandate a particular implementation approach, the device ID is most useful when all of the services on the device have a way to obtain the device ID and get the same value for it. This would argue for its placement as an operating system feature. Operating system developers interested in implementing this specification are encouraged to provide APIs that allow applications to obtain the device ID. Absent such APIs, applications that report presence information about their devices will have to generate their own device IDs. This leads to the possibility that the applications may choose different device IDs, using different algorithms or data. In the worst case, these may mean that two services that run on the same device, do not appear to. Like services and person data components, device data components have generally static characteristics and generally dynamic status. Characteristics of a device include its physical dimensions and capabilities - the size of its display, the speed of its CPU, and the amount of memory. Status information includes dynamic information about the device. This includes whether the device is powered on or off, the amount of battery power that remains in the device, the geographic location of the device, and so on.
The characteristics and status information reported about a device are for the purposes of choice - to allow the user to choose the service based on knowledge of what the device is. The device characteristics and status cannot, in any reliable way, be used to extract information about the nature of the service that will be received on the device. For example, if the device characteristics include the speed of the CPU, and the speed is sufficient to support high-quality video compression, this cannot be interpreted to mean that video quality would be good for a video service on that device. Other constraints on the system may reduce the amount of CPU available to that service. If there is a desire to indicate that higher-quality video is available on a device, that should be done by including service characteristics that say just that. The speed of the CPU might be useful in helping the watcher differentiate between a device that is a PC and one that is a cell phone, in the case where the watcher wishes to call the user's cell phone. Similarly, if there is dynamic device status (such as whether the device is on or off), and this state impacts the state of the service, this is represented by adjusting the state of the service. Unless a consumer of a presence document has a priori knowledge indicating otherwise (note that presence agents often do), the state of a device has no bearing on the state of the service. Just like services, there is no enumeration of device types - PCs, PDAs, cell phones, etc. Rather, the device is defined by its characteristics, from which a watcher can extrapolate whether the device is a PDA, cell phone, or what have you. It is important to point out that the device is a *model* of the underlying physical systems in which services execute. There is nothing that says that this model cannot be used to talk about systems where services run in virtualized systems, rather than real ones. For example, if a PC is executing a virtual machine and running services within that virtual machine, it is perfectly acceptable to use this model to talk about that PC as being composed of two separate devices.
In other cases, it cannot, perhaps because the compositor lacks the ability to do so. However, in many cases, the resolution of this ambiguity is best left to the watcher that consumes the document. This consumer could be an application with more information than the compositor, and thus be able to do a better job of resolving the ambiguity. Or, it may be presented to the human user, and the human can often resolve the ambiguity. Unsurprisingly, a human can often do this far better than an automaton can. To model ambiguity, the model allows each service, each device, or the person component to contain multiple occurrences. Each occurrence has a unique identifier, called the occurrence identifier. This identifier is unique across all other occurrence identifiers for any service, device, or person. That is, its uniqueness is scoped within all of the services, devices, and person elements for a particular presentity. The identifier ideally persists over time, since it serves as a valuable handle for setting composition and authorization policies. Even if there is a single occurrence for a particular device, service, or person, the occurrence has an occurrence identifier. The occurrence identifier is not to be confused with the instance ID defined in the SIP Outbound specification . A user agent instance is best modeled as a service, and indeed, a Globally Routable User Agent URI (GRUU) , which is derived from the instance ID, represents a reasonable choice for a service URI. However, if the status of such a UA instance could not be determined unambiguously, a presence document could include two or more occurrences of the service modeling that UA instance. In such a case, each occurrence has a unique occurrence ID, but they share the same service URI, and consequently, the same instance ID. When multiple occurrences exist in a document, it is important that some of the attributes of the device, service, or person help the recipient resolve the ambiguity. For humans, the note field and timestamp serve as valuable tools. For an automaton, nearly any attribute of the device, service, or person can be used to resolve the ambiguity. The timestamp in particular is very useful for both humans and automatons. As described in RFC 3863 , the timestamp provides the time of most recent change for the tuple. This specification defines the timestamp for person and device components as well, with the same meaning. Absent other information, the person, device, or service that most recently changed can be used as the more reliable source of data. However, such a resolution algorithm is not normatively required in any way.
RFC 3840 , which is used to define capabilities for SIP user agents. In that specification, if a capability declaration omits a particular feature tag, it means that the agent is making no definitive statement either way about whether this feature tag is supported. The same is true here - the absence of a presence attribute from a document means that a watcher cannot make any definitive statement about the value for that presence attribute. It may be absent because it is being withheld from the watcher, or it may be absent because that attribute is not supported by the presentity's software. Neither conclusion can be drawn. Because the absence of a presence attribute conveys no information whatsoever, presence documents achieve their maximum value when they have as many presence attributes as possible. As such, 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.
Protocol (VoIP) address, and so on, the presentity URI can be provided, and all of the others can be learned from there. 21] as the ability, willingness, or desire to communicate across a set of devices. The core of this definition is the conveyance of information about the ability, willingness, or desire for communications. Thus, the presence data model needs to be tailored around conveying information that achieves this goal. The person data component is targeted at conveying willingness and desire for communications. It is used to represent information about the users themselves that affects willingness and desire to communicate. Whether I am in a meeting, whether I am on the phone - each of these says something about my willingness to communicate, and thus makes sense for inclusion in a presence document. The service component of the data model aims to convey information on the ability to communicate. The ability to communicate is defined by the services by which a user is reachable. Thus, including them is essential. How do devices fit in? For many users, devices represent the ability to communicate, not services. Frequently, users make statements like, "Call me on my cell phone" or "I'm at my desk". These are statements for preference for communications using a specific device, as opposed to a service. Thus, it is our expectation that users will want to represent devices as part of the presence data. Furthermore, the concept of device adds the ability to correlate services together. The device models the underlying platform that supports all of the services on the phone. Its state therefore impacts all services. For example, if a presence server can determine that a cell phone is off, this says something about the services that run on that device: they are all not available. Thus, if services include indicators about the devices on which they run, device state can be obtained and thus used to compute the state of the services on the device. The data model tries hard to separate device, service, and person as different concepts. Part of this differentiation is that many attributes will be applicable to some of these, but not others. For example, geographic location is a meaningful attribute of the person (the user has a location) and of a device (the device has a location), but not of a service (services don't inherently have locations). Based on this, geographic location information should only appear as part of device or person, never service. Furthermore,
it is possible and meaningful for location information to be conveyed for both device and person, and for these locations to be different. The fact that the presence system might try to determine the location of the person by extrapolation from the location of one of the devices is irrelevant from a data modeling perspective. Person location and device location are not the same thing.  defines the <geopriv> XML element for conveying location information, and indicates that it is carried as a child of the <tuple> element in a PIDF document.  was developed prior to this specification, and unfortunately, its recommendation to include location objects underneath <tuple> runs contrary to the recommendations here. As such, implementations based on this specification SHOULD include <geopriv> location objects as part of person and/or device components of the document, but SHOULD be prepared to receive presence documents with that object as a child to <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. 1] is used for representation of presence data. The <presence> element contains the presence information for the presentity. The "entity" attribute of this element contains the presentity URI. The existing <tuple> element in the PIDF document is used to represent the service. This is consistent with the original intent of RFC 2778 and RFC 3863, and achieves backward compatibility with implementations developed before the model described here was complete. The <contact> element in the <tuple> element is used to encode the service URI. New presence attributes, whether they represent dynamic status or static characteristics, appear directly as children of <tuple>. However, attributes defined prior to publication of this specification that were defined as children of <status> (such as <basic>) remain as children of <status>, for purposes of backward compatibility. Consequently, a presence attribute describing a service could appear as either a child of <status> or directly as a child of <tuple>, but never both.
The "id" attribute of the <tuple> element conveys the service occurrence. Each <tuple> element with the same <contact> URI represents a different occurrence of a particular service. This specification introduces the <person> element, which can appear as a child to <presence>. There can be zero or more occurrences of this element per document. Each one has a mandatory "id" attribute, which contains the occurrence identifier for the person. Each <person> element contains any number of elements that indicate status and characteristic information. This is 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, zero or more of which can be present as a child to <presence>. As it relates to the model defined here, these note elements, if present in a document, apply to all person occurrences that do not have any of their own <note> elements. In other words, if a <person> element has one or more <note> elements, those are the <note> elements for that <person> element. If a <person> element does not have any of its own <note> elements, the <note> elements that are the direct children of <presence> are the <note> elements for that <person>. If there are no <note> elements underneath the <person> element, and there are no <note> elements that are a direct child of <presence>, then that <person> element has no <note> elements. This specification also introduces the <device> element, which can appear as a child to <presence>. There can be zero or more occurrences of this element per document. The <device> element can appear either before or after the <person> element; there are no constraints on order. Each <device> element has a mandatory "id" attribute, which contains the occurrence identifier for the device. Like <person>, <device> contains any number of elements that indicate status and characteristic information. This is followed by <deviceID>, which contains the URN for the device ID for this device. This is 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. A client that receives a PIDF document containing the <device> and <person> elements, but does not understand them (because it doesn't implement this specification), will ignore them. Furthermore, since the semantics of service as defined here are aligned with the meaning of a tuple as defined in RFC 2778 and RFC 3863, documents incorporating the concepts defined in this model are compliant with older implementations.
It's important to note that the mapping of the presence data model into a PIDF document is merely an exercise in syntax. 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. However, it is not expected that entities receiving these documents would perform schema validation; rather, they would merely 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.
</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>
<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> 23] and .
23], since the idleness refers to usage of the device, not the service. The document published by the client would look 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:firstname.lastname@example.org</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> It is worth commenting further on the value of having a separate device element just to convey the idle indicator. The idle indication of interest is really an indicator that the device is idle. By making that explicit, the idle indicator can be used by the presence server to affect the state of other services running on the same device. For example, let's say there is a VoIP application running on the same device. This application reports its presence state separately, but indicates that it runs on the same device. Since it has indicated that it runs on the same device, the presence server can use the status of the service to further refine the idle indicator of the device. Specifically, if the user is using its VoIP application, the presence server knows that the device is in use, even if the IM application reports that the device is idle. Typically, idleness is determined by lack of keyboard or mouse input, neither of which might be used during a VoIP call. In a more simplistic case, reporting the idle indicator as part of the device status allows that indicator to be used for other services on the same device. Taking, again, the example of the VoIP application on the same device, if the VoIP application does not report any device information, and a watcher is not provided information on the IM service, the presence document sent to the watcher can include the device status. Because of the usage of the
device IDs and the device information, the presence server can correlate the device status as reported by the IM application with the VoIP service, and use them together. RFC 3856 ) require that such authorization processing be performed before divulging presence information. Specifications have also been defined for conveying authorization policies to presence servers . Integrity of presence information is also critical. Modification of presence data by an attacker can lead to diverted communications, for example. Protocols used to transport presence data, such as SIP for presence, are used to provide necessary integrity functions. 8]. Since the presence model is represented in XML, it provides 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. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED in environments where parser encoding support incompatibility exists. 4] URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:data-model. Registrant Contact: IETF, SIMPLE working group, (email@example.com), Jonathan Rosenberg (firstname.lastname@example.org). 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=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> END
 Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.  Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.  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.  Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC- xmlschema-1-20041028, October 2004.  Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.  Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.  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.  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
 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.  Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message Service", Work in Progress, February 2006.  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.  Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.  Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, March 2006.  Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.  Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.  Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.  Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.  Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.  Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.  Rosenberg, J., "Presence Authorization Rules", Work in Progress, March 2006.
 Jennings C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, March 2006. http://www.jdrosen.net
Full 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).