SIMPLE H. Schulzrinne Internet-Draft R. Shacham Expires: December 27, 2006 Columbia University W. Kellerer S. Thakolsri DoCoMo Eurolabs June 25, 2006 Composing Presence Information draft-schulzrinne-simple-composition-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Composition creates a presence document from multiple components published by one or more sources. This document identifies sources of information that a compositor might draw on presence composition and describes steps for composition. The composing function can be complex, so we intentionally restrict the discussion to cases that Schulzrinne, et al. Expires December 27, 2006 [Page 1] Internet-Draft Composition June 2006 are likely to be common across many users of presence systems. We present an XML format for specifying a composition policy, based on our discussion. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Types of Information sources . . . . . . . . . . . . . . . . . 4 3. Composition Steps . . . . . . . . . . . . . . . . . . . . . . 6 4. Discarding . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Deriving Presence Information . . . . . . . . . . . . . . . . 7 6. Resolving Conflicts . . . . . . . . . . . . . . . . . . . . . 9 6.1. Sources of Information Conflict . . . . . . . . . . . . . 9 6.2. Detecting information conflicts . . . . . . . . . . . . . 9 6.3. Handling Information Conflicts . . . . . . . . . . . . . . 11 7. Tuple Merging . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Service tuples . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Person tuples . . . . . . . . . . . . . . . . . . . . . . 13 8. Default Policy . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Composition Policy Format . . . . . . . . . . . . . . . . . . 14 9.1. Discard step . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Derive step . . . . . . . . . . . . . . . . . . . . . . . 14 9.3. Resolve Conflicts Step . . . . . . . . . . . . . . . . . . 15 9.4. Merging . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Schulzrinne, et al. Expires December 27, 2006 [Page 2] Internet-Draft Composition June 2006 1. Introduction Composition combines multiple presence or event sources into one view, which is then delivered, after various filtering operations, to watchers [6] [7]. Composition is required whenever there are several sources contributing information about a single presentity or event. [Note: The content in this draft overlaps with the Processing Model draft and needs to be reconciled. Here, the emphasis is on developing the foundations for a composition policy language, and deal with merging tuples.] For notational simplicity and since most of the discussion has focused on presence rather than general events, we will restrict our attention to presence information using the Presence Information Data Format (PIDF) [3] and extensions such as the Rich Presence Information Data format (RPID) [4], keeping in mind that other types of events or status may well be able to use many of the same mechanisms. We assume that a presentity is a single human being. There are other presentities, such as the collection of customer service agents in a call center, where consistency is much harder to define. We assume that the composition operation does not depend on the watcher identity, as there seems little functional gain by introducing per-watcher composing operations. The composed document contains the maximum set of information, i.e., no watcher can obtain more information than is contained in the composed raw presence document. (In some cases, a presentity wants to "polite block" a person by providing presence information that offers no information to the watcher, but avoids indicating that the watcher's subscription request has either not yet been processed or that it has been turned down. For those cases, a simple template that reflects a minimal PIDF document is sufficient, as it does not need to reflect presence inputs and does not change over time.) Composition at the presence agent is just one component of providing useful and correct information to the watcher. We assume that composition is algorithmic, although manual composition by the presentity is theoretically possible. Given the automated nature of composition, there may well be situations where the best course of action is to expose the underlying data to the watcher, even though it may be contradictory. Indeed, in many cases, a mechanical composer may not even be able to detect whether information is contradictory or not. The goals of composition are to remove information that is either stale, contradictory or redundant, to generate inferred presence Schulzrinne, et al. Expires December 27, 2006 [Page 3] Internet-Draft Composition June 2006 state and to represent presence information in a more useful way. Stale information has been superseded by other, newer information. Contradictory information makes two statements about the presentity that cannot both be true. Redundant presence information provides information that is no longer of interest. For example, a presentity may decide to drop information about services whose status is closed if there are open services and may drop a service record referring to another person via a element if the presentity itself is available. Inferred presence state uses presence elements or external information to derive new information. Location information seems particularly suitable for such inferences. For example, a location away from home might generate the activity indication 'away' or specific geospatial locations might be mapped to particular location types or activities. Presence information may be presented in a useful manner by merging non-contradictory information. Composition is not designed to reduce the size of notification messages or to protect information for privacy. Various compression schemes and partial notification [10] are better suited to reduce message sizes. Privacy filtering [8] has the role of tailoring information to individual recipients, based on the presentity's privacy policy. In our model, the composer is reactive. In other words, it only creates a new presence document if one of the publishers updates parts of the presence document. An active composer could, for example, generate a new presence document after a certain time interval has elapsed or when timed presence [5] information is transitioning from the future to the presence. The goal of this document is to outline options and then to derive a composition policy language that allows the user to control the steps that produce his presence document according to the aforementioned goals. Alternatively, a presence composition language can focus on the XML document and its components. Such a general presence composition language would have to be a full programming language, as it would need to support standard programming constructs such as conditionals, operations on XML elements in a document object model, history and external sources. This document focuses on content-aware policies rather than simple tools for mechanical transformations of XML presence documents. 2. Types of Information sources Presence information can be contributed by many different sources, either directly, by publishers using PUBLISH requests or by a presence agent acting as a watcher receiving NOTIFY requests. We Schulzrinne, et al. Expires December 27, 2006 [Page 4] Internet-Draft Composition June 2006 describe each mode of delivery operation in the following. In direct mode, the composer has direct access, without presence protocol mediation, to this information, e.g., via REGISTER requests or layer-2 operations or access to user keyboard activity. Secondly, sources can use SIP PUBLISH requests to update presence information. Finally, presence agents can in turn subscribe to presence information and receive NOTIFY requests. However, the mechanism of data delivery is likely to be less important than the original data source and how the information was derived. Thus, to the extent possible, information about the original source should be preserved as otherwise information might become more credible simply because it has been re-published. We focus here on the semantic source of the data, i.e., how it was derived, not how it was injected into the presence system. For simplicity, we do not try to assess the veracity of the presence document. In order to evaluate the usefulness of a presence document, we only care whether the presentity would want the information to appear that way, not whether this corresponds to observable facts. Thus, a presence document is correct in that sense if it indicates that the presentity is in a meeting even though the presentity has actually gone fishing if the presentity would like the rest of the world to believe that he is at work. It may, however, well be the case that composition policies find it easier to maintain the truth than keep lies consistent across sources of presence information. We can distinguish the following sources of presence data: Reported current: Reported current information has been provided by the presentity within processing time delays of the current time. A presentity can update status information manually, by setting any of the element in a presence document. This update may be made by sending a PUBLISH request, by using XCAP as specified in [11] , or by a more direct update, such as editing it in a web GUI. We assume that this information is correct when entered, but the trustworthiness of the information is likely to decay as time goes on, given that most human users will find it difficult to continuously keep presence information up-to-date. Reported scheduled: For reported scheduled information, a presentity indicates its plans for the future rather than the present, e.g., in a calendar. The reliability of this information depends largely on the diligence of the user in updating calendars and similar sources. Schulzrinne, et al. Expires December 27, 2006 [Page 5] Internet-Draft Composition June 2006 Measured device information: Measured device information uses observed user behavior on communication devices, such as the act of placing or receiving calls or typing. The main source of error is that a device may not be able to tell whether the presentity itself is using the device or some other person. Measured by sensors: Presence information measured by sensors reflects the status of the presentity, e.g., its location, type of location, activity or other environmental factors. Examples of sensors include Global Positioning System (GPS) information for location or a BlueTooth beacon that announces the type of location, such as "theater", a person finds itself in. Sensors have the advantage that they do not rely on humans to keep the information up-to-date, but sensors are naturally subject to measurement errors. In particular, in quantum mechanical fashion, it is sometimes difficult to ascertain both the measured variable and the identity of the presentity. For example, a passive infrared sensor (PIR) can detect that somebody is in the office of the presentity, but cannot detect whether this is the presentity himself, cleaning staff or a dog. A GPS sensor cannot detect whether the cell phone is being used by the presentity or has been borrowed by the presentity's spouse. Derived: Presence information might be derived indirectly from other sources of data. For example, the basic open/closed status might be algorithmically derived from a variety of other, watcher- visible or not, elements. 3. Composition Steps In our model, presence takes a presence document, made up of a set of , and tuples, each tuple consisting of one or more elements, and creates another valid presence document based on this information. Based on the aforementioned goals of removing stale, contradictory or reduntant information, while providing additional useful data and representing the information in a useful manner, our model includes a sequence of operations on the input tuples. These operations are: discarding, derivation, conflict resolution and merging. Discarding tuples removes stale and redundant information. Derivation provides useful new data. Conflict resolution removes contradictory information. Merging presents the presence in a useful manner. Composition involves adding or removing information from a set of sources, and this may be done at a tuple or element granularity. Some of the steps operate at one granularity or another. While any of the operations may be done on any tuple type, some operations may be more likely performed on certain types. This information is summarized in Table 1. Each of the steps is listed, along with the Schulzrinne, et al. Expires December 27, 2006 [Page 6] Internet-Draft Composition June 2006 granularity on which it typically operates, and whether it is likely or unlikely to be used for each of the tuple types. The specific elements in the table will be discussed in later sections. +-----------------+----------------+----------+----------+----------+ | Operation | granularity | | | | +-----------------+----------------+----------+----------+----------+ | Discarding | tuple | likely | likely | likely | | Derivation | element | likely | likely | likely | | Conflict | tuple or | likely | unlikely | unlikely | | Resolution | element | | | | | Merging | element | likely | likely | unlikely | +-----------------+----------------+----------+----------+----------+ Table 1 4. Discarding Whole tuples may be discarded based on zero or more of the criteria below: Closed contacts: All s with a basic status of 'closed'. Old tuples: Tuples (, , or ) whose age is older than a given threshold. Since presence information should be automatically removed after its expiration time, this discarding applies only to tuples before their expiration. Unreferenced tuples: tuples that are not referenced by any service . (It should be noted that user activity information about these devices may still be useful even if the device itself is not part of any published service.) 5. Deriving Presence Information Certain presence sources may not be capable of publishing all relevant information, and users are unlikely to always update all information that requires their input. Such information may be derived in order to include it in the presence document. Derivation of new information makes it easier to identify a conflict with another presence source. For example, knowing the locations of two presence sources allows the compositor to determine that the user is only colocated with one of them, and the information from the other one is inaccurate. It can also provide information to the watcher indicating communication capability that may not otherwise be known. For example, a user's mobile device may easily be able to identify and publish that it is in a car. However, more relevant Schulzrinne, et al. Expires December 27, 2006 [Page 7] Internet-Draft Composition June 2006 information for the watcher is that the user is driving, which may be derived if this is usually true when the user is in a car (possibly during certain times, such as weekday mornings and evenings). The user may also wish to indicate that when he is "on-the-phone" (which may be published automatically by the UA once he has successfully set up a dialog), this means that he is "busy" and shouldn't be called except in an emergency. The user may know that a specific place does not allow for private communications, and he may automatically supplement his location information with privacy information. More complex rules could be derived that involve outside information such as time of day. For example, when user-input is "idle" between certain hours of the night, the user's activity should be set to "sleeping". Such derivations each have a predicate for defining the conditions of the derivation, and an addition of XML content. The predicate is one or more elements that must all be present in a tuple in order for the content to be added there. A special case of this is the supplementing of static information that doesn't depend on dynamically changing predicates. For example, a device may not support RPID extensions, but they may be added to its presence tuple and that of its associated service using derivation. Such a derivation would be declared using a specific value for the contact address or device-id as the predicate (for a service or device, respectively). There is another way that this static information can be supplemented. The XCAP mechanism described in [11] is used for updating a user's presence. XCAP does not manipulate the user's complete presence document, but, rather, a single presence document which is one of the sources input to the compositor, along with information sent by other presence sources, through PUBLISH or event notifications. XCAP may be used to create and tuples containing static information about the service or device. During the composition process, multiple reports for a single service (those containing identical s) and for a single device (those tuples containing identical s) are merged together. If no identical or tuple has been received from any other source, the static tuple will appear in the resulting raw presence document. If there is another identical tuple, the static and dynamic elements will be merged into a single tuple. The status of any service appearing in the XCAP document should be "closed" so that this becomes the default status and, when the service is published by another source with a status of "open", the resulting status will be "open", which is the union of the two. It should be noted that the technique described here is predicated on the merging of service s, which we are Schulzrinne, et al. Expires December 27, 2006 [Page 8] Internet-Draft Composition June 2006 currently leaving out of our model as discussed in Section 9.4, and plan to specify in the future. 6. Resolving Conflicts 6.1. Sources of Information Conflict Information conflict occurs when multiple sources give different views of the presentity, some of which may be outdated or incorrect. Information can be incorrect for any number of reasons, but some examples include: Location divergence: The publisher collecting the information may not be colocated with the presentity at this particular time. For example, Alice's home PC may report that the user is idle (not typing), but Alice is using the office PC. Update diligence: Some sources, particularly those updated manually, are prone to only approximate reality. For example, few users record all appointments or meetings in their calendar or, conversely, remove all canceled meetings. This is particularly true for regularly scheduled activities such as meals or commute times. Sensor failure: Sources that report their information differentially are subject to silence ambiguity. If such a source does not report new data, the receiver cannot tell whether the sensor is malfunctioning or whether the information last received is still current. This can be partially mitigated by requiring sources to report when they are no longer confident of the data. However, this does not deal with sudden source failures. Thus, some form of keep-alive mechanism may well be needed that overrides differential notification mechanisms. Even with keep-alive, there is likely to be a substantial period of time between source failure and failure detection, causing stale information. 6.2. Detecting information conflicts We would like to be able to detect information conflicts, so that appropriate processing logic can remove inaccurate information. There are many elements in tuples that could end up having conflicting values from different sources. However, this step is less relevant for service tuples. The elements found there are not likely to conflict, even if multiple tuples report information about the same service. For example, the basic status in a service tuple cannot be said to conflict with the status sent for a service on another device. In fact, for the static information derivation described in Section 5, the different values must not be treated as conflicting so that the tuples can be merged in the next step. Schulzrinne, et al. Expires December 27, 2006 [Page 9] Internet-Draft Composition June 2006 , , and describe a specific instance of the service and can all be true. Of course, if service tuples are merged as described in Section 7, the multiple values must be handled in some way, such as listing all of them or choosing one. Our discussion of conflict resolution is focused primarily on person information. Information conflicts can be classified as to whether they are detectable in a single element or only across elements and how easy it is to detect them. Single-element conflicts occur if two elements, say in RPID, in two sources cannot both be true or are highly unlikely to be true, without having to inspect any other element. A multi-element conflict occurs if only the combination of multiple elements indicates a conflict. Multi-element conflicts often have location, and properties known for this location, as the common element. For example, certain geospatial locations are known not to contain certain types of places. Thus, both the location and the information are, by themselves, each credible and possible, but are detectably wrong once considered together. These conflicts can be detected if location or time can be mapped to reliable information from external sources. As mentioned above, derived information can make conflict detection easier by supplementing information to create a single- element conflict. We distinguish three types of information conflict: obvious, probable and undetectable, described in turn below. For some pieces of presence information, information conflicts are obvious and readily detectable. For example, under the one-person- per-presentity assumption and common assumptions of physics, a single presentity can only be in one place at a time. Thus, if two sources report location information that differs by more than the margin of error, one must be wrong. In RPID, the , , , , and elements have exlusive values, although in some cases, below the element level. For example, the field has information for both audio and video, and thus two sources may report different information for and still both be correct as long as they refer to different media types. For other types of information, an automaton can guess with some probability that two sources of information contradict each other, but this may well depend on the values themselves. For example, the combination of Schulzrinne, et al. Expires December 27, 2006 [Page 10] Internet-Draft Composition June 2006 away, appointment, in-transit, meeting, on-the-phone, steering incrementally reported by different sources may well reflect the activity of the typical Wall Street commuter in the Lincoln Tunnel, speaking on his cell phone. One would hope, however, that combinations such as "steering, sleeping" are rarely true, although "sleeping, meeting" indicates that there are few activities that completely rule out others. The element is another one that may take different values, sometimes, but not always, contradictory. For example, the values "outdoors" and "stadium" differ only in their specificity. For these types of elements, two options seem possible. A table may be constructed with each value in both a separate row and a separate column, so that their relationships may be charted. The relationship of value A to B may be contradictory, more or less specific, or have no relationship. Alternatively, different values may always be treated as contradictory. The latter approach seems better suited for an element like where a single source is likely to have all relevant information and can be fully accurate by itself. However, this works less effectively for , for instance, where different sources inherently give different types of information. For example, a cell-phone says that the user is "on-the-phone", a sensor says the user is "steering", and a calendar says that the user is in a "meeting". Undetectable information conflicts are those where a machine lacking human intelligence cannot reliable detect that the two pieces of information cannot both be true. For example, an automaton is unlikely to be able to decide which of several notes or free-text fields is valid, without basing this on other information in the tuple, person or device element. 6.3. Handling Information Conflicts Once an information conflict is detected, a choice must be made about how to handle it. In some cases, no action should be taken. For an element such as or , for which different reported values makes sense and it is hard to distinguish which values really conflict, as mentioned above, the different values can be treated as non-conflicting. This means that both tuples are retained, and handling is deferred to the merging step, during which the multiple values will be unioned within a single tuple. For other elements, however, conflict is more easily detectable and multiple values are not sensical. A conservative approach to handling such a conflict would be to simply list all values. This is different from the approach mentioned earlier, because the tuples are kept distinct and not merged in the next step. Multiple versions are Schulzrinne, et al. Expires December 27, 2006 [Page 11] Internet-Draft Composition June 2006 presented which are admittedly conflicting, and the watcher may make a judgment about which is more correct. To limit the amount of information that the watcher must digest, it may be more useful to choose one value over the other. For this decision, a number of common heuristics may be used, which are listed below: Choose recent tuple: Choose the value from the tuple that was more recently published for the first time. Simply choosing the most recently updated value is likely to cause flip-flopping between dueling publishers. Choose trustworthy tuple: Choose the element from the more trustworthy tuple. Trustworthiness may be based on the source identity, such as a user's cell phone. Alternatively, it is based on the types of reporting listed in Section 2. For example, they may be ranked in the order "reported current", "measured device information", "measured by sensors", "reported scheduled", and finally "derived". Value of another element: Other elements may indicate that one version of the information should be trusted. For example, may indicate that one device that provides presence is being used by the user, and another is not. As a special case of this policy, tuples belonging to a certain sphere may be given precedence. For example, after a certain hour, it is more likely that the tuple with the sphere is up-to-date. Specific heuristics may be combined with external information, such as time of day. As new elements are added, they are likely to either fall into the category of elements where collecting all values makes most sense, such as activities and mood above, or where a choice among values needs to be made. When one value is chosen over another, the resulting presence document may be affected on the tuple level or on the element level. On the tuple level, the more trusted tuple is chosen and the other is discarded. On the element level, both tuples are maintained, but only the more trusted element is kept, while the other is discarded. Either of these approaches may have advantages in certain situations. However, we propose using only tuple-level conflict resolution to avoid inconsistencies in the final document. 7. Tuple Merging Merging combines several tuples that logically represent the same information. For example, a presence document should only contain Schulzrinne, et al. Expires December 27, 2006 [Page 12] Internet-Draft Composition June 2006 one report of information, so the multiple reports from different sources should be merged. It may also be useful to merge service s that have the same contact URI. (We leave aside for now the difficulty of deciding whether two URIs that are not lexically identical are indeed functionally the same) This may occur when the same service is being provided by a variety of devices, or in the example of static information in Section 5. Sometimes, it is better not to merge tuples. For example, some elements can contain timing information indicating the range of time that the information is believed to be valid. It is probably not a good idea to combine elements that cover different, although maybe overlapping, time intervals. In any of the above cases, the elements in the resulting tuple must be based on the original tuples. Although the original values should not conflict, following the previous step, some elements will have multiple non-conflicting values, when multiple services are merged or person tuples are merged which contain elements which are treated as non-conflicting, as described above. When this occurs, either element must be selected or they should be unioned. We discuss appropriate techniques for each element type below. 7.1. Service tuples When composing tuples, the following rules apply to their PIDF and RPID elements: basic status: The union of all values should be returned, so that the service is 'open' as long as one source reports 'open'. class: A single value needs to be chosen. deviceID: If a service is offered by multiple devices, it makes sense to enumerate all the device identifiers. privacy: Since the caller cannot select the device that satisfies specific privacy requirements, the appropriate choice is to provide the most conservative indication of the privacy to be expected, i.e., the least privacy indicated among all the tuples for the contact URI. relationship: If two tuples with the same contact URI differ in their relationship, the relationship element needs to be dropped. status icon: It is a local choice whether to present all status icons, as they may reflect specific capabilities, or choose one. user input: In a combined , it makes sense to reflect the most recent user input. 7.2. Person tuples As noted in the section on conflict handling, there are elements for which different values may be treated as non-conflicting. These may include , , and . For such elements, Schulzrinne, et al. Expires December 27, 2006 [Page 13] Internet-Draft Composition June 2006 all values are unioned in this step. 8. Default Policy The default composition policy is designed to lose no information, at the expense of presenting possibly contradictory information to watchers. This composition policy performs a union with replacement. Newly published elements replace earlier elements with the same 'id' attribute. We assume that each source chooses their own 'id' values. Other than this, all elements are simply enumerated as is, sorted by type (person, tuple, device). Elements within the , and elements are not modified at all, except possibly annotated with a source description (and timestamp?). This policy can also be seen as providing input to the following steps. 9. Composition Policy Format We define an XML format for specifying a policy for composition. It is expected that this format will be used by users themselves, and that standard composition documents be created by network administrators. The document is a sequence of composition steps, each with its own options for customization. The steps are "discard", "derive", "resolve-conflicts", and "merge". 9.1. Discard step This step allows for discarding of tuples. Three types of discarding may be specified: discard all service tuples with closed contacts, all tuples whose timestamps are older than a certain amount of time, and all device tuples not associated with a service. 9.2. Derive step This step contains rules for deriving new information based on existing information. The XML Patch format [12] is used to express the derivation of new content, using the element. The XML content following the element is the new content to be added, while the derivation conditions are expressed in the 'sel' attribute of that element. This attribute takes as its value an XPath [13] expression which identifies the location where the content is to be added. Xpath predicates can be used to select only tuples with specific children, which forms the condition of the derivation expression. Schulzrinne, et al. Expires December 27, 2006 [Page 14] Internet-Draft Composition June 2006 For example, the following Patch operation: adds the 'driving' activity to any person tuple that shows the 'place-type' as 'car'. In order to make derivation dependent on the time of day, the selecting Xpath expression may refer to the tuple's timestamp in the predicate. Functions built into Xpath 2.0 may be used to retrieve the desired part of the date/time expression. For example, if someone sleeps between the hours of midnight and 7 am unless he is working on a deadline, a derivation of his sleep based on his user- input may be expressed as follows: This states that if the user-input is 'idle' during normal sleeping hours, the user is sleeping. If the value is not 'idle' during those hours, he is likely working on a deadline. 9.3. Resolve Conflicts Step In this step, conflicts are identified and resolved using one of a number of policies. Identifying conflicts is a matter of local policy as it is not seen as something that users should specify. The element contains possibly several elements, each defining how conflict is to be resolved. An "element" attribute may be included so that the included policy applies only to that element. When this attribute is omitted, or has a value of "all", it applies to all elements. Options for resolution are "merge", "union", "most-recently- published", "source-precedence", or "other-attribute". Several policies may be listed, and conflict resolution is attempted with each in the order that they appear, until one succeeds. Schulzrinne, et al. Expires December 27, 2006 [Page 15] Internet-Draft Composition June 2006 , in effect, defines the given element as non-conflicting. Examples of elements appropriate for this are and . It is useful for this format be used to define these so that new presence elements may also be easily taken into account without requiring a configuration of the Presence Server. The use of for a given element precludes any other conflict resolution policy for that element. Choosing "union" causes both conflicting tuples to be included, and precludes any other policy for conflict resolution for the specified elements. It also ensures that the two tuples will remain distinct, even after the merging step, so that multiple versions will be represented, and the human watcher will be able to decide which is more likely to be accurate. This is the default value for the resolution of a conflict for any given element when an alternative policy is not given. The element directs the compositor to choose the tuple which was most recently published for the first time. This does not choose a tuple simply because it was refreshed more recently. The element lists a number of source types. This list may contain any of the following tokens at most once: "reported current", "reported scheduled", "measured device information", "measured by sensors", "derived". If each of the conflicting tuples is from one of the sources listed, the one with a higher value is chosen. If only one of the tuples is from a source with a listed value, that one is chosen. If neither of them are, the conflict is not resolved by this method. The element specifies that resolution be done based on another element besides the one in conflict. An attribute is included to specify the element. A list of elements gives the ordered preference of various values. 9.4. Merging This final step merges multiple tuples to present a final view of the user's presence before continuing to later steps such as privacy filtering. We currently consider only merging of tuples as this is the most likely to be useful. When multiple tuples are merged, they may have different values for the same attribute. The conflict resolution step is used to declare for which elements, such as multiple values should be listed, rather than be treated as conflicting. Therefore, no real specification is required by the user in this step for Schulzrinne, et al. Expires December 27, 2006 [Page 16] Internet-Draft Composition June 2006 tuples. It is expected that for the merging of service s, input from the user will be desired regarding whether to merge them and, if so, how to handle multiple values of elements. 10. XML Example reported current reported scheduled active idle 11. Security Considerations Composition itself does not create new data types, although it might create new elements by derivation. Thus, the security considerations are the same as those for the constituent presence information elements. 12. IANA Considerations Schulzrinne, et al. Expires December 27, 2006 [Page 17] Internet-Draft Composition June 2006 This document does not request any IANA actions. 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. 13.2. Informative References [4] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-10 (work in progress), December 2005. [5] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", draft-ietf-simple-future-05 (work in progress), December 2005. [6] Rosenberg, J., "A Data Model for Presence", draft-ietf-simple-presence-data-model-07 (work in progress), January 2006. [7] Rosenberg, J., "A Processing Model for Presence", draft-rosenberg-simple-presence-processing-model-01 (work in progress), August 2005. [8] Schulzrinne, H., "Common Policy: An XML Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-10 (work in progress), May 2006. [9] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), September 2004. [10] Lonnfors, M., "Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information", draft-ietf-simple-partial-notify-07 (work in progress), Schulzrinne, et al. Expires December 27, 2006 [Page 18] Internet-Draft Composition June 2006 June 2006. [11] Isomaki, M., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", draft-ietf-simple-xcap-pidf-manipulation-usage-02 (work in progress), October 2004. [12] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", draft-ietf-simple-xml-patch-ops-02 (work in progress), March 2006. [13] "XML Path Language (XPath) 2.0", W3C Candidate Recommendation 8 20060608, June 2006. Appendix A. Acknowledgments This document is based on discussions within the IETF SIMPLE working group. Paul Kyzivat provided helpful input. Schulzrinne, et al. Expires December 27, 2006 [Page 19] Internet-Draft Composition June 2006 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+simple@cs.columbia.edu URI: http://www.cs.columbia.edu Ron Shacham Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Email: shacham@cs.columbia.edu Wolfgang Kellerer DoCoMo Eurolabs Landsberger Str. 312 Munich 80687 Germany Email: kellerer@docomolab-euro.com Srisakul Thakolsri DoCoMo Eurolabs Landsberger Str. 312 Munich 80687 Germany Email: thakolsri@docomolab-euro.com Schulzrinne, et al. Expires December 27, 2006 [Page 20] Internet-Draft Composition June 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne, et al. Expires December 27, 2006 [Page 21]