SIMPLE H. Schulzrinne Internet-Draft R. Shacham Expires: September 6, 2006 Columbia University W. Kellerer S. Thakolsri DoCoMo Eurolabs March 5, 2006 Composing Presence Information draft-schulzrinne-simple-composition-01 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 September 6, 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 composer might draw upon and describes steps for composition. The composing function can be complex, so we intentionally restrict the discussion to cases that are likely to be Schulzrinne, et al. Expires September 6, 2006 [Page 1] Internet-Draft Composition March 2006 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. Scoping Composition . . . . . . . . . . . . . . . . . . . . . 4 3. Types of Information sources . . . . . . . . . . . . . . . . . 5 4. Discarding . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Deriving Presence Information . . . . . . . . . . . . . . . . 7 6. Information conflict . . . . . . . . . . . . . . . . . . . . . 9 6.1. Sources of Information Conflict . . . . . . . . . . . . . 9 6.2. Detecting information conflicts . . . . . . . . . . . . . 10 6.3. Resolving 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 . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. Resolve Conflicts Step . . . . . . . . . . . . . . . . . . 15 9.4. Merge Step . . . . . . . . . . . . . . . . . . . . . . . . 16 10. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Schulzrinne, et al. Expires September 6, 2006 [Page 2] Internet-Draft Composition March 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 September 6, 2006 [Page 3] Internet-Draft Composition March 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 or by dividing up services based on a common attribute. 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 present. 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. Scoping Composition In our model, presence takes a presence document, made up of a set of , and tuples, each tuple consisting of one Schulzrinne, et al. Expires September 6, 2006 [Page 4] Internet-Draft Composition March 2006 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 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 | likely | unlikely | | Resolution | element | | | | | Merging | element | likely | likely | unlikely | +------------------+----------------+----------+---------+----------+ Table 1 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. 3. 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 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, Schulzrinne, et al. Expires September 6, 2006 [Page 5] Internet-Draft Composition March 2006 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 [12] , 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. 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. Schulzrinne, et al. Expires September 6, 2006 [Page 6] Internet-Draft Composition March 2006 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. 4. Discarding Whole tuples may be discarded based on one of the criteria below: Closed contacts: All s with a basic status of 'closed'. It is generally appropriate to also delete the associated information, since it is meant to convey availability for a mode communication which is now being taken away. Old tuples: Tuples with a timestamp or time range older than a given threshold are discarded. This may apply to , , or tuples. 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 New presence information may be created based on existing data. This process, called presence derivation, takes presence data as input and results in new presence data being included in the document. Certain presence sources may not be capable of publishing all relevant information, and users may sometimes not update all information that requires their input. Schulzrinne, et al. Expires September 6, 2006 [Page 7] Internet-Draft Composition March 2006 Derivation of new information makes it easier to identify a conflict with another presence source. For example, filling in the location of a device that is incapable of publishing it for itself shows that two of the user's services are on devices that are far from each other. 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 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", 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". Derivation may be dynamic or static. Dynamic derivation, as in the above cases, is done based on changing information, such as the presentity's place type. This type of derivation only adds information under certain circumstances. Static derivation adds information that is always present because it is based on constant information. For example, a device may not be able to publish RPID extensions, but the capabilities of it and its associated service could be included through derivation. This would be done by treating only the contact address or device-id as the derivation input (for a service or device, respectively), and all new information as the result. Location information may also be added to tuples representing stationary devices, such as IP phones, that do not support the GEOPRIV extensions. A derivation may be specified to add location information to a service that has the device-id of a known device. Since location is one of the most reliable ways to perform conflict resolutions, the derived information may allow the determination that the user is not available on that device, since his cellphone reports him elsewhere. [It should be noted that [6] discourages the inclusion of location information in the service . The function described above should be made possible in a way that conforms with that document. An alternative is to create a new tuple containing the location, and associating it with the service tuple.] There is another way that this static information can be supplemented. The XCAP mechanism described in [12] is used for updating a user's presence. XCAP does not manipulate the user's complete presence document, but, rather, a single presence document Schulzrinne, et al. Expires September 6, 2006 [Page 8] Internet-Draft Composition March 2006 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. 6. Information conflict 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. Schulzrinne, et al. Expires September 6, 2006 [Page 9] Internet-Draft Composition March 2006 6.2. Detecting information conflicts We would like to be able to detect information conflicts, so that appropriate processing logic can remove inaccurate 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. We distinguish single-element from multi-element conflicts. 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 often make a multi-element conflict into a single-element conflict by supplementing information, and thus make conflict detection easier. 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 away, appointment, in-transit, meeting, on-the-phone, steering Schulzrinne, et al. Expires September 6, 2006 [Page 10] Internet-Draft Composition March 2006 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 that are sometimes, but not always, contradictory. For example, while "automobile" and "office" are distinct values, "outdoors" and "stadium" differ only in their specificity. For the types of elements that may or may not be contradictory, 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 specific, less specific, or 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". It should be noted that even these RFID elements may not serve as good indications of conflict between tuples. Differences in location, as mentioned above, is likely to be a much more effective means, albeit not always applicable. 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. Resolving Information Conflicts Once an information conflict is detected, a choice must be made between the conflicting elements in order to resolve the conflict. A method must be determined for choosing between the elements. Once an element is chosen, the scope of the resolution must be determined. That is, it must be decided whether one entire tuple should be removed, or only the element. There are a number of approaches for choosing between conflicting values. Specific methods may be combined with external information, such as time of day. A number of common methods are listed below: Schulzrinne, et al. Expires September 6, 2006 [Page 11] Internet-Draft Composition March 2006 Choose recent tuple: Choose the element from the most recent tuple only or from tuples no more than a certain age. Simply choosing the most recently published value is likely to cause flip-flopping between dueling publishers. Choose trustworthy tuple: Choose the element from the most trustworthy tuple. Trustworthiness may be based on the source identity, such as a user's cell phone. More likely, it is based on the types of reporting listed in Section 3. For example, they may be ranked in the order "reported current", "measured device information", "measured by sensors", "reported scheduled", and finally "derived". Note that "derived" here refers to a more complex derivation, not to the basic rules mentioned earlier, where the derived data is about as reliable as the original information. Omit contradictions: A conservative approach omits any information where two source tuples contradict each other. [Only the intersection of enumerated sets, with their associated notes, is used.] 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. 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. It is suggested that tuple-level conflict resolution be used to avoid inconsistencies in the composed document. 7. Tuple Merging Merging combines several tuples into one. This may be peformed on tuples that logically represent the same information. For example, a presence document should only contain one report of information, and the multiple reports from different sources must be merged. Service s that have the same contact URI should also be merged. (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. Multiple service s may also be Schulzrinne, et al. Expires September 6, 2006 [Page 12] Internet-Draft Composition March 2006 combined to create a new service. For example, a composer could take a variety of services (e.g., cell phone, home phone, office phone, PC IM client) available under different contact URIs and create a new service tuple that "hides" all these services behind a single SIP URI. In such a case, a decision must first be made about how to merge multiple tuples, based on the "pivot" model in [7]. In any of the above cases, the RPID elements in the resulting tuple must be based on the original tuples. Although the original values should not conflict, following the previous step, there must be either a selection from among the values or a union of all values. We discuss appropriate techniques for each element type below. 7.1. Service tuples When composing tuples, the following rules apply to their RPID elements: class: A single value needs to be chosen. device: 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. [TBD: Note, however, that there are proposals [11] to allow remote parties to indicate privacy requirements. 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 activities: As noted earlier, activities reported by a variety of sources can easily all be true, as they may report on different facets of a person. For example, for a driver talking on a cell phone, a car sensor may report "steering", while the phone can report "on-the-phone", and the calendar can indicate "appointment". One option may be to report all recent activities. class: As discussed for above. mood: This is similar to . Schulzrinne, et al. Expires September 6, 2006 [Page 13] Internet-Draft Composition March 2006 place-is: Selecting the least favorable value for each media type appears to be a safe default operation. place-type: One option may be to choose specific values over more general ones, where "stadium" would win over "public". privacy: As discussed for above. sphere: This element is also largely single-valued, so that a selection needs to be made. Certain sphere values may be preferred over others. status-icon: As discussed for above. user-input: As discussed for above. As other elements are added, they are likely to either fall into the category of elements where collecting all (recent) values makes most sense, such as activities and mood above, and where a choice among sources needs to be made. 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, discard all tuples whose timestamps are older than a certain amount Schulzrinne, et al. Expires September 6, 2006 [Page 14] Internet-Draft Composition March 2006 of time, and discard all device tuples not associated with a service. 9.2. Derive step This step contains rules for deriving new information based on existing information. Each rule contains an "inputs" and "results" section. The "inputs" section contains one or more inputs as conditions for adding one or more pieces of information in the "results" section. An input may be the existence or value of an attribute, or information external to the presence document, such as time of day. All inputs must be satisfied in order for the results section to be evaluated. In order to define an attribute as an input, Xpath is used. In RPID, attributes are specified by separate elements, such as , as opposed to text values. In such a case, Xpath may be used to refer to the existence of the attribute without performing any selection. For example, the existence of a person tuple showing the user in a meeting would be represented by '/person/activities/ meeting'. When the element is used, Xpath must do a selection based on the attribute value, such as 'person/ place-type[other="baby's room"]/other'. The "results" section contains one or more "add" statements. These are formatted based on [13]. The location of the addition is any person, service or device tuple that matches the requirements in the "inputs" section. 9.3. Resolve Conflicts Step In this step, conflicts are identified and resolved using one of a number of policies. 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 "default", it applies to all elements. We currently assume that the "geopriv" element value will signal to the compositor that the rule applies whenever it identifies a divergence of location (possibly by using a local algorithm to convert between civic and geodetic values). The element also has a "scope" attribute that takes a value of either "tuple" or "element." With the value of "tuple", once a conflict is identified, the less trusted tuple is removed entirely. With the value of "element", both tuples remain, but only the element from the more trusted tuple is kept. As mentioned above, element-level conflict resolution may introduce inconsistent data. Options for resolution are "union", "source-precedence", or "other- Schulzrinne, et al. Expires September 6, 2006 [Page 15] Internet-Draft Composition March 2006 attribute". Choosing "union" causes even conflicting information to be included, and precludes the inclusion of any other policy. Several policies may be listed, and conflict resolution is attempted with each in the order that they appear, until one succeeds. 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. The element specifies that resolution be done based on another element besides the one in conflict. An attribute is included to specify the attribute with Xpath. A list of elements gives the ordered preference of various values of the attribute. 9.4. Merge Step 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. Merging is done separately on , and tuples. Merging in this format involves two steps: pivoting and choosing values for attributes. We do not include an additional step mentioned in [7], which is choosing a single URI to represent the merged service. Pivoting is the process of merging all tuples into a smaller set based on a common attribute, where each new tuple represents all tuples with a certain value of the attribute. Services and devices may be grouped in this way. However, person information does not lend itself to multiple tuples, so all tuples are merged into a single one (note that this is a special case of pivoting). When multiple tuples are merged, they may have different values for the same attribute. This is because different values are often not contradictory. An example is the attribute, where two sources may give the values "outdoors" and "construction", and the value "construction" is simply more specific. A element is defined, which contains a list of one or more policies to be applied, such as , , or . Multiple s may be defined, with the "element" attribute distinguishing the element for which the list applies, so that different policies may be applied to different elements. If the attribute is not included, or has a value of "default", the policy applies to all elements. When no policy exists to distinguish Schulzrinne, et al. Expires September 6, 2006 [Page 16] Internet-Draft Composition March 2006 between two values, the default is to list all values. 10. XML Example [We plan to include an XML schema once the format is more or less agreed upon] 37:46:30N 122:25:10W active idle reported current reported scheduled Schulzrinne, et al. Expires September 6, 2006 [Page 17] Internet-Draft Composition March 2006 active idle 11. Security Considerations Composition itself does not create new data types, although it might create new elements by inference. Thus, the security considerations are the same as those for the constituent presence information elements. 12. IANA Considerations This document does not request any IANA actions. 13. 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 Schulzrinne, et al. Expires September 6, 2006 [Page 18] Internet-Draft Composition March 2006 J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [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., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-07 (work in progress), February 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-06 (work in progress), October 2005. [11] Shacham, R., "Use of the SIP Preconditions Framework for Media Privacy", draft-shacham-sip-media-privacy-01 (work in progress), November 2005. [12] 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. [13] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", draft-ietf-simple-xml-patch-ops-01 (work in progress), January 2006. Schulzrinne, et al. Expires September 6, 2006 [Page 19] Internet-Draft Composition March 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 September 6, 2006 [Page 20] Internet-Draft Composition March 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: rs2194@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 September 6, 2006 [Page 21] Internet-Draft Composition March 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 September 6, 2006 [Page 22]