SIMPLE J. Rosenberg Internet-Draft dynamicsoft Expires: January 7, 2005 July 9, 2004 A Data Model for Presence draft-rosenberg-simple-presence-data-model-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 7, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Over the last year of work, the SIMPLE group has tried to answer the question of "what is a tuple". This document tries to answer that question by proposing an abstract data model for presence, and then mapping that data model onto the Presence Information Data Format (PIDF). It then discusses the operations of publication, composition, filtering as they relate to presence data processing. Rosenberg Expires January 7, 2005 [Page 1] Internet-Draft Presence Data Model July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Presentity . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Devices . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Motivation for the Model . . . . . . . . . . . . . . . . . . . 12 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Presence Server Processing . . . . . . . . . . . . . . . . . . 16 7.1 Collection . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2 Composition . . . . . . . . . . . . . . . . . . . . . . . 18 7.2.1 Correlation . . . . . . . . . . . . . . . . . . . . . 18 7.2.2 Conflict Resolution . . . . . . . . . . . . . . . . . 19 7.2.3 Merging . . . . . . . . . . . . . . . . . . . . . . . 20 7.2.4 Splitting . . . . . . . . . . . . . . . . . . . . . . 22 7.3 Privacy Filtering . . . . . . . . . . . . . . . . . . . . 23 7.4 Watcher Filtering . . . . . . . . . . . . . . . . . . . . 23 7.5 Post-Processing Composition . . . . . . . . . . . . . . . 23 8. Extending the Presence Model . . . . . . . . . . . . . . . . . 24 9. Example Presence Documents . . . . . . . . . . . . . . . . . . 24 9.1 Basic IM Client . . . . . . . . . . . . . . . . . . . . . 24 9.2 VoIP Application . . . . . . . . . . . . . . . . . . . . . 27 9.3 Cellphone . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Proposed Plan of Action . . . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . 33 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 13. Informative References . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 36 Rosenberg Expires January 7, 2005 [Page 2] Internet-Draft Presence Data Model July 2004 1. Introduction Over the last year of work, the SIMPLE group has tried to answer the question of "what is a tuple". In particular, RFC 2778 [1] introduces the concept of a tuple, but merely states that it is an element of presence information consisting of status, communications address and other markup. As such, it can be used as a tool for modeling different concepts, but there has not been consensus on what, precisely, it models. At least four different concepts have been put forward: Service: In this view, a tuple models a communciations service, such as instant messaging or telephony. Device: In this view, a tuple models a communications device, such as a phone, PDA or PC. Presentity: In this view, a tuple models the user of the system, and includes information about the user and all of their communications modalities. Person: In this view, a tuple represents a person as a communications medium, i.e., face-to-face communications. Status: Dynamic information about a service, presentity or device. Characteristics: Static information about a service, presentity or device. Useful in providing context that identifies the service or device as different from another service or device. A service or characteristic. It represents a single piece of presence information. Publication: The act of pushing a piece of event state, including presence, to a state agent, such as a presence server. Back end subscriptions: A subscription made from a state agent, such as a presence server, to a source of presence, for the purpose of collecting event state in order to perform composition. The SIMPLE group has produced several documents in the process of trying to answer this question. A use case document [4] was developed to describe several different systems, and how a presence document would be constructed to describe the system. This effort quickly revealed that there was a lot of inconsistency in how documents generated to describe one device in one system would be interpreted in another system. In a related document, Roach documents a technique [5] for indicating the service associated with a tuple, by proposing that the service be deduced from service characteristics. Unfortunately, the question of "what is a tuple" still appears to be unanswered, and as a result of this, there remains confusion on how to properly specify several work items within the SIMPLE group. These work items are: Rosenberg Expires January 7, 2005 [Page 3] Internet-Draft Presence Data Model July 2004 RPID: RPID defines a set of extensions to the PIDF document for defining rich presence status [6]. This document defines a element which indicates whether the tuple is a device, service, in-person or presentity, but does not define what that means. Furthermore, most of the other extensions indicate whether or not they make sense in tuples of various types. There has been disagreement on this, ultimately due to the lack of definition on what these mean. Presence Authorization Rules: The presence authorization rules [7] defines a set of permissions that can be granted to watchers of presence. There is a desire to include rules that allow watchers access to tuples of a certain device or service, but little understanding of what this means. The SIMPLE group has also discussed concepts such as document composition, pivoting and filtering, and these discussions have also oftentimes suffered from confusion because of a disparity of understanding on what was being done. Ultimately, it is our belief that the problem is that the group has never agreed on a well defined model for presence data. Such a model gives the context that is necessary to talk about the various operations that one performs on presence data - extending it, encoding it, filtering it, and authorizing its usage. This document attempts to remedy this situation by proposing a concrete model for presence data, justifying the model based on the key goals of presence and presence systems, and then exploring the impacts on encoding, filtering, authorization, composition, and so on. 2. Definitions This document makes use of many new terms, which are defined here. Device: A device is a model that represents a common operating environment across services, which in and of itself has characteristics that defined and constrain the operation of those services. Typically, a device models a physical operating environment. Service: A service models a form of communications that can be used to interact with the user. Presentity: A presentity models the principal or user of the system, using a combination of presentity, device and service data elements. Data Element: One of the device, service, or presentity parts of a presence document. 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. Rosenberg Expires January 7, 2005 [Page 4] Internet-Draft Presence Data Model July 2004 Raw Presence Document The result of an initial composition operation, before privacy and watcher filtering operations have been applied. Privacy Filtering: The act of applying permissions to a presence document for the purposes of removing information that a watcher is not authorized to see. Watcher filtering The act of removing information from a presence document at the request of a watcher, to reduce the information flowing to that watcher. Pivot: A presence attribute used to select a set of services or devices that are to be combined as part of a composition operation. View: A view represents a stream of presence documents generated by a presentity after composition and authorization policies have been applied. Depending on how these policies are structured, each watcher to a presentity may get a different view, or they may all get the same view. Rosenberg Expires January 7, 2005 [Page 5] Internet-Draft Presence Data Model July 2004 3. The Model +----------------+ | | | | | Presentity | | | | |\ / +----------------+ \ / | \ / | \ / | \ / | \ / | \ / | \ V V V +----------------+ +----------------+ +----------------+ | | | | | | | | | | | | | Service | | Service | | Service | | | | | | | | | | | | | +----------------+ +----------------+ +----------------+ \ / \ \ / \ \ / \ \ / \ V V V +----------------+ +----------------+ | | | | | | | | | Device | | Device | | | | | | | | | +----------------+ +----------------+ Figure 1 The data model for presence is shown in Figure 1. There are three elements in the model. They are the presentity, the service, and the device. Each of these data elements contains information (called attributes) that provide a description about the service, presentity, or device. It is central to this model that these attributes are affilitated with the service, presentity, or device because they Rosenberg Expires January 7, 2005 [Page 6] Internet-Draft Presence Data Model July 2004 *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 a presentity element with an in-a-meeting attribute. The presence information may also include information on the cell phone as a device. However, even though it is that device which is reporting that the user is in a meeting, the busy indicator is not associated with the device, it is associated with the user. 3.1 Presentity The presentity element models information about the user whom the presence data is trying to describe. This information consists of an identifier for the presentity, characteristics and status. The URI for the presentity represents an identity for the user that is independent of any of the services or devices that they possess. 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. As such, it can either be a SIP URI for the user, to which SUBSCRIBE requests can be directed, or else it can be a pres URI [8]. Characteristics of a presentity are the static information about a user that does not change under normal circumstances. Such information might include physical characteristics, such as age and height. Status information about a presentity represent the dynamic information about a user. These typically are things the *user* is doing, places the *user* is at, feelings the *user* has, and so on. Examples of typical presentity status are "in a meeting", "on the phone", "out to lunch", "happy" and "writing Internet Drafts". In the model, there can only be one presentity element. It is possible for the presentity to model "users" that are in fact multiple people, for example, a customer support desk. Nothing in the model mandates that the entity being modeled is actually composed of a single user. The model only mandates that this "user" be represented by a single set of characteristics, and the characteristics that are available are tailored for the case where a single user is being modeled. 3.2 Service Each presentity has access to a number of services. Each of these represent a form of communications that can be used to interact with the user. Examples of services are telephony (that is, traditional circuit-based telephone service), push-to-talk, instant messaging, Rosenberg Expires January 7, 2005 [Page 7] Internet-Draft Presence Data Model July 2004 Short Message Service (SMS), and Multimedia Message Service (MMS). When a service is accessible over a communications network, it is represented with a URI that can be "hit" in order to access the service. However, some services are not accessible over a communications network (such as in-person communications or a written letter), and as such, may not utilize a URI. Each service is adorned with characteristics that describe the nature of the service that will be experienced when a watcher invokes that URI. Examples of such characteristics are the type of media that might be used, the directionality of communications that are permitted, the quality of the service, and so on. These 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 which help differentiate the services from each other, and give the watcher the context in which to make a choice. In this model, services are not explicitly enumerated. That is, there is no "service" attribute with values of "ptt" or "telephony". Rather, the service is identified in one of two ways. In many cases, the URI scheme is a clear indicator of service. An "sms" URI clearly indicates SMS, and a "tel" URI clearly indicates telephony. For some URIs, there may be many services available, for example, SIP. For those services, each service has a set of characteristics, each of which has a well-defined meaning, such that a system can unequivocally determine whether or not the service has that characteristic. This is discussed in more detail in [5]. [[NOTE: What attributes do we use to determine that the service is in-person communications or written communications?]] 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 a 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. Rosenberg Expires January 7, 2005 [Page 8] Internet-Draft Presence Data Model July 2004 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 presentity. 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. The URI 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 invokes the URI associated with that service. It is not necessary for the watcher to add additional information to a message generated by invoking that URI in order to reach the service described in the document. Specifically, it is not necessary for a watcher to add SIP caller preferences in order to request routing of the request to a service with the characteristics described in the document. As a result, each service in the presence document will have a different URI. The URI represents a weak form of contract; the presentity tells the watcher that, if the watcher invokes the URI as 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. Firstly, 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. Secondly, 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. The URI also plays another important role - it acts as the unique identifier for the service. When two presence user agents publish information about a service, the service URI is what indicates that the service information they are publishing is for the same or different services. For this reason, it is important that each PUA use unique service URIs, and that these service URIs also be persistent over time. These properties are readily met by using the Globally Routable User Agent URI (GRUU) [10] as the service URI. This is discussed further below. Each service is also associated with a priority, which represents the preference that the user has for usage of one service over another. This does not mean that, when a watcher wishes to communicate with the presentity, that they should always use the service with the highest priority. If that were the case, there would be no point in Rosenberg Expires January 7, 2005 [Page 9] Internet-Draft Presence Data Model July 2004 including multiple services in the presence document. Rather, the priority says, "If you, the watcher, cannot decide which of these to use, or if it is not important to you, this is the order in which I would like you to contact me. However, I am giving you a choice.". The priorities are relative to each other, and have no meaning as absolute numbers. If there are two services, and they have priorities of 1 and .5 respectively, this is identical to giving them priorities of .2 and .1 respectively. Each service also has a status. Status represents dynamic information about the availability of communications using that service. This is in constrast to characteristics, which describe fairly static properties of the various services. The simplest form of status is the basic status, which is a binary indicator of availability for communications using that service. 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 dyanmic 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 its 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. This service has dynamic states like whether or not 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 element of a presence document. Information is included only when it has a bearing on helping the watcher decide whether or not to initiate communications with that service, or helping them decide when to initiate it, if not now. As an example, whether a cell phone has roamed or not does not pass this litmus test. Knowing this is not likely to have an impact on a decision to use this service. 3.3 Devices Devices model the physical operating environment in which services execute. Examples of devices include cell phones, PCs, laptops, PDAs, consumer telephones, enterprise PBX extensions, and operator dispatch consoles. Rosenberg Expires January 7, 2005 [Page 10] Internet-Draft Presence Data Model July 2004 The mapping of services to devices are many to many. A single service can execute in multiple devices. Consider a SIP telephony service. Two SIP phones can register against a single address-of-record for this service. As a result, the SIP service is associated with two devices. Similarly, a single device can support a multiplicity of services. A cell phone can support a SIP telephony service, an SMS service, and an MMS service. Similarly, a PC can support a SIP telephony service and a SIP videophone service. Devices are identified with a device ID. A device ID is a URI that is a globally and temporally unique identifier for the device. The device ID is also persistent across time. This makes it useful as a correlation identifier, as discussed below. Practically speaking, it is difficult to obtain device identifiers with these guaranteed properties; however, there are many ways in which it can be done reasonably well. For a cell phone, the ESN (Electronic Serial Number) and MIN (Mobile Identification Number) are good choices. For an IP device, the mac address of the primary interface is a good choice, or the CPU serial number. In many cases, there might be multiple good choices. For example, a cell phone with IP connectivity might have an ESN, MIN and MAC address. In that case, one of them needs to be chosen, and used as the device identifier. Of course, if a device chooses to use two device identifiers, and hands out different ones to different services, this will manifest itself as two different devices as far as the model is concerned. That might be a feature in some cases, or a bug. The choice is left to local policy. Like services and presentities, devices have static characteristics and 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 or not 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. 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* if 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 Rosenberg Expires January 7, 2005 [Page 11] Internet-Draft Presence Data Model July 2004 acceptable to use this model to talk about that PC as being composed of two separate devices. 4. Motivation for the Model Presence is defined in [3] 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 presentity part of the model is targeted at conveying willingness and desire for communications. It is used to represent information about the user themselves that affects willingness and desire to communicate. Whether or not I am in a meeting, whether or not 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 seems essential. How do devices fit in? For many users, devices represent the ability to communicate, not services. Frequently, users my 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 devices, services, and presentities 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 presentity (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 Rosenberg Expires January 7, 2005 [Page 12] Internet-Draft Presence Data Model July 2004 information should only appear as part of devices or presentities, never services. Furthermore, it is possible and meaningful for location information to be conveyed for both a device and a presentity, and for these locations to be different. The fact that the presence system might try to determine the location of the presentity by extrapolation from the location of one of the devices is irrelevant from a data modeling perspective. Presentity location and device location are not the same thing. It is important to be clear about what it means for an attribute to be associated with a service, device or presentity. The lack of clarity on this point is a core part of the "what is a tuple" problem that the group has been facing. Furthermore, it is important to try and restrict an attribute to appearing in as few different types of tuples as possible. The more places an attribute can appear, with the same meaning, the greater the possibility of interoperability failures. Being concise on what the presence data represents, with as little choice about how the same thing is represented, is important. 5. Encoding Information represented according to the data model described above needs to be mapped into an on-the-wire format for transport and storage. The Presence Information Document Format [9] is used for representation of presence data. The approach suggested here is to use the element to represent presentity, service and device information. In order to indicate which one of these the tuple represents, an RPID parameter, , is used, with values of "service", "presentity" and "device". This approach was chosen largely because much of the existing presence work views "tuple" as the fundamental unit of information modelling. A more natural fit would have been to translate the data model directly into XML, by defining explicit , and elements. However, that seems to disruptive at this point. When a models a presentity, the element is omitted. Similarly, for a device, the element is also omitted. It is present only for a service. For services that are not readily representable by a URI, for example, in person communications or written communications, the element can be present, but with some kind of bogus URN [[Yuck!]]. The element needs to be there in order to contain the priority, which is meaningful even for services without a URI. Status information for devices, tuples and services are encoded Rosenberg Expires January 7, 2005 [Page 13] Internet-Draft Presence Data Model July 2004 within the element if their respective tuples. Characteristics (that is, static information) is encoded directly underneath . When a watcher receives a presence document that doesn't contain the element, the watcher assumes that the tuple is modeling a service. This is to provide backwards compatibility with simpler systems that don't use RPID and the data model described here. The entity attribute in the element is always present, and identifies the presentity described by the document. [[The terminology here is a bit confusing: we talk about the presentity as a data element, and presentity as the entire thing being modeled by the presence document, including the presentity element. Do we need two terms?]] Mapping of the data model into a PIDF document is done according to the following table: Data Element PIDF Encoding -------------------------------------------------------- Presentity a element URI "entity" attribute of characteristics children of the presentity status children of within the presentity Service a element URI the within the characteristics children of the service status children of within the service priority "priority" attribute of Device a element device ID child of the element characteristics children of the device status children of within the device It's important to note that the mapping of the presence data into a PIDF document is merely an exercise in syntax. Almost any of the choices will do; what is important is agreement on what this data represents. 6. Publication Publication is defined as the process by which an event publication Rosenberg Expires January 7, 2005 [Page 14] Internet-Draft Presence Data Model July 2004 agent (EPA) pushes event state into the network [11]. In this section, we consider how an EPA for the presence event package would generate the presence document it will publish. An EPA for presence (also known as a Presence User Agent (PUA)) computes the presence document as if it had full knowledge of the state of the presentity. That is, it represents the complete view of user presence as understood by that PUA. In particular, this means that the document will include information on the presentity - its URI, and any characteristics or status known to the PUA. The URI (encoded in the "entity" attribute) will typically be a SIP URI, and equal to the AOR of the presentity. This will also usually be the same as the request URI in the PUBLISH request itself, but it need not be so. The URI serve different purposes. As described in [11], the request URI serves as a means to route the request to the appropriate event state compositor, and identity the target of the publication. As such, it is primary a means for targeting the document. The entity about whom presence is reported is always taken from the "entity" of the presence document. As an example when the two might be different, consider an IT helpdesk. The IT helpdesk is modeled as a presentity, and as such, it has a SIP URI of the form sip:helpdesk@example.com. The compositor knows that there are three users in the IT department, sip:joe@example.com, sip:bob@example.com and sip:mary@example.com. Joe's PUA knows that it needs to inform the compositor about its state in order to compute the presence of the helpdesk. So, it might construct a PUBLISH request where the reuqest URI is sip:helpdesk@example.com, and the presentity URI is sip:joe@example.com. However, we anticipate that in the vast majority of cases, Joe's PUA would not have to explicitly do this. The compositor would know, based on provisioned composition logic, that the state of sip:helpdesk@example.com is based on the other three URI, and it would explicitly obtain the state of those presentities. A PUA will also publish the services it knows about, and the device its associated with. The service URI needs to be a unique identifier that defines the service as far as the PUA is concerned. That URI should be a GRUU, as discussed above. The device ID for the device is obtained from the local operating system. Its interesting to note that, if GRUU had been around before PUBLISH, we may have found it easier to have each PUA publish to its own GRUU as the request URI. This would eliminate the need for multiple "slots" of published data, etags, and some of the other complexity in the publish specification. Too late now... Rosenberg Expires January 7, 2005 [Page 15] Internet-Draft Presence Data Model July 2004 7. Presence Server Processing In this section, we outline the processing a server does on presence documents. The basic flow of operations is shown in Figure 3. +---------+ |Presence | | Source |\ +---------+ \ +-----------+ \ | | \ /------\ | Raw | //------\\ +---------+ \// Create \\ | Presence | || Privacy ||-----+ |Presence |----| View |-->| Document |->|| Filtering|| | | Source | \\ // | | \\------// | +---------+ / \------/ | | | / ^ +-----------+ ^ | / | | | +---------+ / +------------+ +------------+ | |Presence |/ | Composition| | Presence | | | Source | | Policy | | Auth | | +---------+ | (TBD) | | | | | | | | | +--------| | | | | | +------------+ +------------+ | | | V V ------ +-----------+ +-----------+ //// \\\\ | | ------ | | | Post | | Filtered | /// \\\ | Candidate | | Processing |<---| Presence |<--| Watcher | | Presence | | Composition | | Document | | Filter | <---| Document | \\\\ //// | | \\\ /// | | ------ | | ------ | | | +-----------+ +-----------+ | | | | V +-----------+ | | | Final | | Presence | | Document | | | Rosenberg Expires January 7, 2005 [Page 16] Internet-Draft Presence Data Model July 2004 | | +-----------+ Figure 3 7.1 Collection The first step is the process of collection. Collection is defined as the process of obtaining the set of event state that is necessary for performing the composition operation neccesary to create the initial view. A view is defined as the particular stream of presence documents seen by a watcher after the application of policy. In this case, the initial view is the view of the presentity before the application of authorization policies. The event state that is collected includes all of the presence documents that have been published for the presentity. This, by definition, is the set of documents whose "entity" attribute in the element in the presence document is the same as that of the presentity. However, it may also include other presence documents for other presentities, in cases where the presence server knows that the state of one presentity is a function of the state of another. An example is the helpdesk presentity, whose state is a function of the state of the users in the help desk. In addition to presence events, other event state can be used as well. As an example, registration state has a bearing on presence, as does dialog state, and the state of non-SIP systems, such as traditional telephony equipment, layer 2 devices, and so on. This state can be obtained by a presence server in several ways. Firstly, publishers for that state can send PUBLISH requests for it to the presence server. In another approach, the presence server acts as a watcher, and subscribes to the event state for the resources it needs. This is referred to as a back-end subscription. Each of these non-presence events can then be converted into a piece of presence state (presentity, device or service information) based on local policy. For example, if the presence server has somehow obtained information that says that the user's cell-phone is on, this can be converted into device state (using the device ID of the phone) along with service state, if the presence server knows about the services on the device. Registration state is of particular importance. It can be obtained by a presence server by having the presence server co-located with the registrar, or by having the presence server subscribe to the Rosenberg Expires January 7, 2005 [Page 17] Internet-Draft Presence Data Model July 2004 registration event package for the user [2]. Each registered contact is considered a service. The service URI (expressed in the element in each tuple of the presence document) is obtained from the GRUU for each contact, if it exists, else it is set to the Contact URI from the registration. Service parameters can be extracted from any callee capabilities provided in the registration [12]. The presentity URI is set to the address-of-record. This mapping has the advantage that it is readily correlated to any service information that might also be PUBLISHed explicitly by that UA. As such, a UA that registers should also PUBLISH its state, in the event the presence server cannot access registration information. Once the non-presence event state is converted into pieces of presence state, the compositor will have, at its disposal, a set of presence data, each of which is for the same presentity. 7.2 Composition The next step in the process is the composition operation, which produces the raw presence document, also known as the initial view, from the document sources. This document is "raw" because it contains more information than any watcher might actually see. Authorization policy may eliminate some of the data from the document. The means by which composition is done is a matter of local policy. However, there are some general tools and techniques that merit discussion. 7.2.1 Correlation A key part of composition is using information in one presence document, describing a presentity, service or device, to affect information in another. As an example, if the presence server has a document indicating that the user has a telephony service that is busy, the server can use this to extract information about the presentity - that they are on the phone. Similarly, if one document indicates that a device with ID 1 is off, and another document that indicates a telephony service is running on the device with ID 1, the server can determine that the telephony service is closed. The way in which the various input data impact each other are a matter of local policy. However, a key to performing such combination operations is the usage of a correlation identifier that can match services, devices, and presenties together across input sources. The presence document provides the service URI, presentity URI and device ID as correlation identifiers. All three of these identifiers have uniquess and temporal persistence properties that Rosenberg Expires January 7, 2005 [Page 18] Internet-Draft Presence Data Model July 2004 make them useful for purposes of correlation. Indeed, its not just that the identifiers have temporal persistence; its that they have a common value that is used persistently across different sources. In the example above, the device ID of 1 is useful for correlating the device state to the service state, if, and only if, the source indicating the device state uses the same device ID as the source indicating the service state. This makes selection of the device ID a critically important operation. 7.2.2 Conflict Resolution In some cases, there may be multiple sources that provide conflicting information about a service, presentity, or device. In this case, "conflicting" means that there are multiple presentity objects that say different things, multiple service objects for the same service (where the same service is defined as two services with the same service URI), or multiple device objects with the same device ID. Conflicting presentity information is very likely. Consider the case of a user that has an IM application running at work. This IM application was told by the user to indicate a status of "in a meeting". The status of "in a meeting" is presentity status. So, the IM client publishes a presence document with two tuples. One tuple is the presentity tuple, indicating that the user is in a meeting. The other tuple is the IM service tuple, indicating availability for IM service. The service URI is equal to the GRUU for that client. When the user gets home, they start another IM application on the same provider, for the same presentity. The user tells this application to set the status to "at home". This will cause the application to publish two tuples. One is a presentity tuple, with a status of "at home". The other is a service tuple for IM, indicating availablility. That IM service uses a different service URI than the one at work, since the two are running on separate UA instances. The presence server now has two documents about the same presentity. These documents have non-conflicting IM services (though there are two of them), but they both have a presentity tuple, and this tuple is different. Here, there is a conflict. The presence server can choose, based on administrator or user-provided policy, which presentity tuple to use (or indeed to combine them). A key way in which conflicts can be resolved is by measuring the likelihood that the information from each source is accurate. In this simple case, the presentity information is reported from two IM clients. However, one IM client may report an idle indicator for the device, whilst the other (the home IM client) reports that it is not idle. The presence server can use this information to believe the Rosenberg Expires January 7, 2005 [Page 19] Internet-Draft Presence Data Model July 2004 device which is not idle. More generally, when a source publishes information, it publishes its "world view", including information it thinks it knows about the presentity, about the service it is providing, and the device it runs on. The fact that all of these are reported together in a presence document is key. It provides additional context that can be used to determine the level of accuracy of a source for particular information. For example, if a cell phone reports that the user is in a meeting, the cell phone's document will include, in addition to the presentity status, cell phone device and cell phone service information. Simimlarly, if a calendaring application acts as a source, and indicates that the user is in a meeting, it would include only information about the meeting. The presence server might decide to trust the information that reports *just* the meeting, more than a cell phone that reports a meeting. The presence server may also know the source of the presence data, based on authenticated identities. For example, in the case above, the calendaring application may have a separate identity it uses to authenticate itself to the presence server. The presence server can be configured to know that the owner of that particular authenticated identity is a calendar application, and therefore, it can trust its information on meeting status information more than another source. [[OPEN ISSUE: do we want a attribute that can be used to explicitly define information about the publisher of the information?? How would this be authorized??]]. Conflicts of services or devices are less likely to occur in the model presented here, due to the unique nature of the service URI and device ID. However, it is possible. Indeed, a client might explicitly choose to publish with the same service URI as another client, if its goal is to explicitly override the service of the other. Using the same service ID is the "hint" to the presence server that conflicting data exists, and one needs to be chosen. 7.2.3 Merging Merging is an operation that allows a presence server to combine together a set of different services or devices into a single composite service or device. Two services are different if they have different service URIs, and two devices are different if they have different device IDs. This operation is a common one in composition operations. To merge a set of services, the characteristics and status of each service must be combined, and then a single composite service URI must be generated. How the characteristics and status are combined Rosenberg Expires January 7, 2005 [Page 20] Internet-Draft Presence Data Model July 2004 will vary for each attribute. For many attributes, if the value is the same across all services, the combination operation is easy - use that value. If the attribute differs across services, it is a matter of local policy as to how they are combined. As an example, consider the status as defined in [9]. The most sensible combination operation is the boolean OR operation. That is, a composite service is said to be available as long as one of its component services is available. One way to identify the set of services that will be combined is by defining a "pivot". A pivot is a particular attribute (either characteristic or status) of a service that is used as the selector. All of the services in the raw presence document for whom the pivot attribute has the same value, are all combined together, and the resulting service will clearly have that value for that particular pivot attribute. If the raw presence document has three distinct values for the pivot attribute, the presence document, after combination, will have three services. For example, if the video prescaps [13] attribute is used as the pivot, then all services that support video will be combined, and all of those that don't will be combined. The resulting presence document after mergin will have two services - one with a characteristic of video, and one with a characteristic of no-video. Combining service URIs is more complicated. If the service URIs are GRUUs within the same AOR, they can easily be combined by using the AOR as the result of the combination function. Indeed, even if the presence server is not combining multiple services together, it might make sense to change the GRUU to the AOR in the presence document delivered to a watcher. If the service URIs are SIP URIs but are not GRUUs, the presence server may need to create a URI which represents the collection of services. Requests made to that URI could fork to the set of services that were combined together. If the service URIs are not even the same URI scheme, for example, a mailto and a tel URI, there is little that can be done. In such a case, the URI should be removed from the document. There are some cases where URIs with distinct URI schemes can be combined. For example, if one service has a tel URI, and the other has a SIP URI, a combined service can be represented by a SIP URI generated by the presence server. If the watcher generates a request towards this SIP URI, the proxy server could fork the request to the original tel URI and the original SIP URI. This works in this specific case (sip and tel URI combination) because SIP requests can sensibly be directed to a tel URI. These cases aside, it is generally not a good idea to combine services together that have radically different URIs. Rosenberg Expires January 7, 2005 [Page 21] Internet-Draft Presence Data Model July 2004 The merging operation takes place for devices identically to the way it takes place for services. Fortunately, combining of device IDs is a bit less complicated than combining service URIs. The server can manufacture new device IDs that represent a "virtual" device that represents a collection of other devices. It is perfectly valid for the merging operation to eliminate all services from the final document, or all devices from the final document. A presence document that includes only presentity information is referred to as a "presentity view". A presence document that includes only service information is referred to as a "service view". A presence document that includes only device information is called a "device view". [[NOTE: Do we want to allow reduction to throw away all services? The presentity? Do we need at least one of each??]]. 7.2.4 Splitting Splitting is the process of taking a single service or device data element, and splitting into two services or devices. This is useful when the presence server or presence user agent wishes to model a complex application (such as a voice, video and IM enabled client) by a multiplicity of distinct services. The process of splitting involves taking the attributes (both status and characteristics) for the service, and determine which of the component services that attribute will describe. In some cases, a single attribute will be split so that it is present in both components. For example, if the composite service has an idle indication, meaning that the service has not been used in some time, the component services would both inherit the same value for the idle indicator. In other cases, an attribute gets assigned only to one service, or in other cases, its value is changed as it is split up. The way in which this is done is a matter of local policy. In all cases, it is important to remember that the purpose of having multiple services or devices described in a document is to give the watcher choice about what service to use. Therefore, the splitting operation should result in multiple services that have sufficient characteristics associated with them to differentiate them to a watcher. Splitting of a service URI is a relatively simple operation. The entity performing the split creates two new service URIs, each of which, should a request be received for that URI, would get translated to, or routed to, the composite service URI. If a presence user agent is performing the split, it can use the grid parameter of the GRUU to manufacture an infinite supply of URIs that Rosenberg Expires January 7, 2005 [Page 22] Internet-Draft Presence Data Model July 2004 all get routed to itself. If a presence server is doing the split, it can manufacture an entirely new URI (in conjunction with the domain owner, of course) as needed. When a service is split, there is usually no reason to split the device as well. The component services all run on the same device, and there is much benefit to indicating that this is the case. For example, it would allow a presence server that is compositing the presence document for the presentity, to determine that all of the component services are inactive if the device should fail. 7.3 Privacy Filtering Once the merging operation has been applied, the next step is to perform privacy filtering. Privacy filtering is a process by which information is removed or transformed in a raw presence document, for the purposes of withholding sensitive information that the presentity does not want a watcher to see. The exact privacy filtering operation that takes place depends on the identity of the watcher, and can also depend on other variables, such as time of day, the weather in Helsinki, and so on. Authorization policy is expressed using the document format defined in [7]. 7.4 Watcher Filtering Watcher filtering is the process by which information is further removed from the presence document. However, it is the watcher which specifies the information subset that they would like to receive. Watcher filtering is accomplished by including filter documents in subscription requests. These filters are then bound to the subscription, and applied to any presence document generated during the lifetime of that subscription. Filters are described using the document format defined in [14]. 7.5 Post-Processing Composition After the privacy and watcher filtering operations have been applied, the resulting presence document may contain service or device elements which no longer contain enough information to differentiate one from another. As discussed above, the purpose of having multiple services or devices described in a document is to give the watcher choice about which service to invoke. If the services defined in a document all appear the same, differing only in the service URI, there is no reason for a user to choose one over another. In such a case, composition rules, and in particular, merging of services, will Rosenberg Expires January 7, 2005 [Page 23] Internet-Draft Presence Data Model July 2004 need to be done. The result is the final presence document that can be delivered to watchers. 8. Extending the Presence Model When new presence attributes are added, any such extension has to consider the following questions: 1. Is the new attribute applicable to presentity, service or device data elements? If it is applicable to more than one, what is its meaning in each context? An extension should strive to have each attribute concisely defined for each area of applicability, so that a source can clearly determine to which type of data element it should be applied. 2. Is this new attribute a dynamic status, or a static characteristic? Characteristics are information that describe information about devices that help provide context for a consumer of the document to make a decision about whether communications is desired in one place or another. They are therefore descriptive in nature. 9. Example Presence Documents In this section, we give examples of different physical systems, present the model of that system using the concepts described here, and then show the resulting presence document. Some of the examples and content in this section are lifted from [4]. 9.1 Basic IM Client In this scenario, a provider is offering a service very similar to the instant messaging services offered today by the public providers like AOL, Yahoo, and MSN. In this service, each user has a "screen name" that identifies them in the service. A single client, generally a PC application, connects to the service at a time. When the client connects, this fact is made available to other watchers of that user in the system. The user has the ability to set a textual note that describes what they are doing, and this note is seen by the watchers in the system. The user can set one of several status messages - such as busy, in a meeting, etc., which are pre-defined notes that the system understands. If a user does not type anything on their keyboard for some time, their status changes to idle on the screens of the various watchers of the system. The system also indicates the amount of time that the user has been idle. Whenever a user is connected to the system, they are capable of receiving instant messages. A user can set their status to "invisible", which means that they appear as offline to other users. Rosenberg Expires January 7, 2005 [Page 24] Internet-Draft Presence Data Model July 2004 However, if an IM is sent to them, it will still be delivered. This system is modeled by representing each client in the system with three data elements - a presentity element, a service element, and a device element. The presentity elements describes the state of the user, including the note and the pre-defined status messages. These represent information about the user, so they are included in the presentity element. The service tuple represents the IM service. No characteristics are included. The service URI published by the client is set to the client's GRUU. The device element is used to model the PC. The device element includes the idle indicator, since the idleness refers to usage of the *device*, not the service. Inclusion of the idle indicator in a service tuple is permitted, but would imply something different - that the user hasnt used the service (i.e., has not used their IM client) in some time. The document published by the client would look like this: Rosenberg Expires January 7, 2005 [Page 25] Internet-Draft Presence Data Model July 2004 service mac:8asd7d7d70 MESSAGE OPTIONS open sip:gruu-someone-1@example.com presentity on-the-phone device mac:8asd7d7d70 It is worth commenting further on the value of having a separate device element just to convey the idle indicator. As described above, 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 say there is a voip application running on the same device. This application reports its presence information using the example below. Since it reports 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 their 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 Rosenberg Expires January 7, 2005 [Page 26] Internet-Draft Presence Data Model July 2004 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. 9.2 VoIP Application In this example, consider a SIP network. The user has a SIP AOR of sip:user@example.com. The user has a single SIP PC client that they run on their office machine. This is a simple SIP softphone, supporting audio only. The PC client publishes a presence document that has a single tuple, representing the service. It does not include any presentity or device elements, although it does include a device-id as part of its service characteristics. The document published by the client would look like this: service urn:mac:8asd7d7d70 INVITE OPTIONS BYE ACK CANCEL open Rosenberg Expires January 7, 2005 [Page 27] Internet-Draft Presence Data Model July 2004 sip:gruu2@example.com 9.3 Cellphone In this example, the user has a cellphone. This cellphone has an SMS client and a SIP push-to-talk client running. The phone also has a switch that allows the user to select "silent mode". This information is also used by the phone as an indicator of business. As it turns out, the SMS and PTT applications on the phone are totally separate, and each publishes its own information. Indeed, both happen to publish information about the silent mode switch. The SMS application models itself with three elements - a service element, representing the actual SMS service, a device element, modeling the phone, and a presentity element, modeling the user. Similarly, the PTT app has three elements, representing the PTT service, device, and presentity. If the user is in a PTT call, the PTT application might generate a document that looks like this. Note the inclusion of the busy element as part of the presentity state, which was set based on the silent switch: Rosenberg Expires January 7, 2005 [Page 28] Internet-Draft Presence Data Model July 2004 service urn:esn:600b40c7 INVITE OPTIONS BYE ACK CANCEL closed sip:gruu-aa@example.com presentity on-the-phone busy device urn:esn:600b40c7 mobile The SMS application would publish a document that looks like this: Rosenberg Expires January 7, 2005 [Page 29] Internet-Draft Presence Data Model July 2004 service urn:esn:600b40c7 open sms:1234567 presentity busy on-the-phone device urn:esn:600b40c7 The presence server now has two presence documents for a single user. It has conflicting information for the presentity and device elements. It knows it has two services, both of which run on the same device. It merges the two devices into one, and unions the information it has for them. It keeps the services as separate, but changes the PTT URI from the GRUU to the AOR. It merges the presentity information together, unioning that as well. The resulting raw presence document, after composition, would look like: service urn:esn:600b40c7 open Rosenberg Expires January 7, 2005 [Page 30] Internet-Draft Presence Data Model July 2004 sms:1234567 service urn:esn:600b40c7 INVITE OPTIONS BYE ACK CANCEL closed sip:someone@example.com presentity busy device urn:esn:600b40c7 mobile 10. Proposed Plan of Action The proposal is to accept this basic model as the presence data model that is the basis for the various working items in the SIMPLE group that relate to presence document management. If such a proposal is accepted, the following plan of action is proposed: o Accept this document as a working item of the SIMPLE group, targeted for informational. Rosenberg Expires January 7, 2005 [Page 31] Internet-Draft Presence Data Model July 2004 o Add a reference from RPID and the other documents to this document. Note that this is an informative reference. RPID, CIPID [16] and the other work can proceed quickly after some of the relatively minor modifications defined below. o Include the few normative statements in this document into RPID (namely, around how many tuples of each type need to be in a presence document) o Add the device-id element to RPID. Specify that it is a URN. Specify that, if the URN scheme is known, functional equality is used. If unknown, lexical equality. This gives us the ability to define URN formats for things like MAC addresses and ESNs later (see below). o Change the contact-type element in RPID to tuple-type, identify its values as device, service and presentity, and include a reference to this document for more information on it. o Change the existing attributes in RPID in the following ways: The activity element becomes applicable only to presentity tuples. Class can continue as defined. Idle becomes applicable to a service or device, but has very different meanings for the two. Clarify that. The placetype element becomes applicable to presentity and devices only. There are different meanings for the two. Clarify that. Specify that the privacy element is specific to services. Relationship is applicable to services and devices; it specifies that the service or device is "owned" by someone other than the presentity. Specify that sphere is only applicable to the presentity. In all cases, clarify which attributes are status, and which are characteristics. The schema already appropriately models the split. o Change prescaps in the following way. All of the information currently listed are characteristics, and thus belong as direct children of the tuple element, not status. Make this change. Specify that all of the prescaps elements are service characteristics, with the exception of class and mobility, which are device characteristics. Actor is tricky, but I believe its a service or device characteristic - it indicates whether the service or device connects to thepresentity, or whether its something else. Closely related to the relationship element in RPID, which effectively identifies the thing described by the actor. Also, add a reference to this document as informational. o Change CIPID to clearly indicate that all of the information is presentity characteristics. Add a reference to this document as informational. o Change timed-status [15] to indicate that it is applicable to presentities, devices and services. Clarify that it is applicable only to status information, since that is the only dynamic information. Add a reference to this document as informational. o One of the source of confusion around the XCAP manipulation of PIDF [17] is that it was unclear as to why one would use it as Rosenberg Expires January 7, 2005 [Page 32] Internet-Draft Presence Data Model July 2004 opposed to PUBLISH. The presence data model presented here sheds some light on that. PUBLISH is appropriate for communicating information about services and devices. PUBLISH is designed for the model where there can be more than one such source (as there is for devices and servcies), and where such state is soft-state (as it should be for devices and services). However, presentity state is not clearly soft-state, and the model here clearly indicates that each presence document can have a single presentity element. Thus, it might make sense to change the pidf-manipulation spec to only allow setting of presentity tuples. Now, that doesnt forbid a source from trying to PUBLISH presentity information, but there is clearly a need for a hard-state approach for setting presentity information. o The presence rules specification [7] should be updated to allow permissions that grant access to services and devices identified by service URI and device ID respectively. o Fold in the text from [5] and [4] into this specification. o Consider a new work item to define some URN formats that would be appropriate for usage within the device-id. MAC address, ESN are good examples. There does not appear to be URNs for these types. 11. Security Considerations The presence information described by the model defined here is very sensitive. It is for this reason that privacy filtering plays a key role in the processing of presence data, as described above. Presence systems based on this model need to provide such a privacy capability, and furthermore, need to protect the integrity and confidentiality of the data. 12. Acknowledgements This document is really a distillation of many ideas discussed over a long period of time. These ideas were contributed by many different participants in the SIMPLE working group. Henning Schulzrinne initially described the "pivot" operation described above for composition. Brian Rosen deserves credit for the "presentity view". Aki Niemi, Paul Kyzivat, Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam Roach, Hisham Khartabil, and Jon Peterson contributed many of the concepts that are described here. A special thanks to Steve Donovan for discussions on the topics discussed here. 13 Informative References [1] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Rosenberg Expires January 7, 2005 [Page 33] Internet-Draft Presence Data Model July 2004 Package for Registrations", RFC 3680, March 2004. [3] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [4] Sparks, R., "SIMPLE Presence Document Usage Examples", draft-sparks-simple-pdoc-usage-00 (work in progress), October 2003. [5] Roach, A., "Identification of Services in RPID (Rich Presence Information Data)", draft-roach-simple-service-features-00 (work in progress), February 2004. [6] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, "RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in progress), March 2004. [7] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-00 (work in progress), May 2004. [8] Peterson, J., "Common Profile for Presence (CPP)", draft-ietf-impp-pres-04 (work in progress), October 2003. [9] Sugano, H. and S. Fujimoto, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [10] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-01 (work in progress), February 2004. [11] Niemi, A., "An Event State Publication Extension to the Session Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in progress), May 2004. [12] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January 2004. [13] Lonnfors, M. and K. Kiss, "User agent capability presence status extension", draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004. [14] Khartabil, H., "An Extensible Markup Language (XML) Based Rosenberg Expires January 7, 2005 [Page 34] Internet-Draft Presence Data Model July 2004 Format for Event Notification Filtering", draft-ietf-simple-filter-format-01 (work in progress), June 2004. [15] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format(PIDF) to Indicate Presence Information for Past and Future Time Intervals", draft-ietf-simple-future-01 (work in progress), April 2004. [16] Schulzrinne, H., "CIPID: Contact Information in Presence Information Data Format", draft-ietf-simple-cipid-01 (work in progress), March 2004. [17] Isomaki, M., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", draft-ietf-simple-xcap-pidf-manipulation-usage-01 (work in progress), June 2004. Author's Address Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires January 7, 2005 [Page 35] Internet-Draft Presence Data Model July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires January 7, 2005 [Page 36]