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 <person> 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 <relationship> 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
   <tuple>, <person> and <device> 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  | <person> |  <tuple> | <device> |
   +-----------------+----------------+----------+----------+----------+
   | 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 <tuple>s with a basic status of 'closed'.
   Old tuples: Tuples (<person>, <tuple>, or <device>) 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: <device> tuples that are not referenced by any
      service <tuple>.  (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 <tuple> and <device>
   tuples containing static information about the service or device.
   During the composition process, multiple reports for a single service
   (those containing identical <contact>s) and for a single device
   (those <device> tuples containing identical <device-ID>s) are merged
   together.  If no identical <tuple> or <device> 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 <basic> 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 <tuples>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 <person> 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


   <deviceID>, <privacy>, and <user-input> 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 <activities> 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 <place-type> 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 <place-is>, <privacy>,
   <relationship>, <time-offset>, and <user-input> elements have
   exlusive values, although in some cases, below the element level.
   For example, the <privacy> field has information for both audio and
   video, and thus two sources may report different information for
   <privacy> 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
   <activities> 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 <place-type> 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 <place-type> where a single source is likely to have all
   relevant information and can be fully accurate by itself.  However,
   this works less effectively for <activity>, 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 <activities> or <mood>, 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, <user-
      input> 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 <home> 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 <person> information, so the multiple reports from
   different sources should be merged.  It may also be useful to merge
   service <tuple>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 <service> 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 <tuple>, 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 <activities>, <mood>, and <place-type>.  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 <person>, <tuple>
   and <device> 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 <add> element.  The XML
   content following the <add> 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:

   <add sel='//person[place-type/car]'>
     <activities>
       <driving />
     </activities>
   </add>

   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:

   <add sel='//person[user-input="idle"] \
   [fn:hours-from-dateTime(timestamp) > 0 \
   and fn:hours-from-dateTime(timestamp) < 7]'>
     <activities>
       <sleeping>
     </activities>
   </add>

   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 <resolve-conflicts> element contains possibly several <conflict>
   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


   <merge>, in effect, defines the given element as non-conflicting.
   Examples of elements appropriate for this are <activities> and
   <mood>.  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 <merge>
   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 <most-recently-published> 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 <source-precedence> 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 <other-element> 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 <person> 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 <activities> multiple values should be
   listed, rather than be treated as conflicting.  Therefore, no real
   specification is required by the user in this step for <person>



Schulzrinne, et al.     Expires December 27, 2006              [Page 16]


Internet-Draft                 Composition                     June 2006


   tuples.  It is expected that for the merging of service <tuple>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

   <discard>
     <old-tuples age="00:30:00.000" />
     <tuples-with-closed-contacts />
   </discard>
   <derive>
     <add sel='//person[place-type/car]'>
       <activities>
         <driving>
       </activities>
     </add>
   </derive>
   <resolve-conflicts>
     <conflict element="activities">
       <merge />
     </conflict>
     <conflict element="mood">
       <merge />
     </conflict>
     <conflict element="place-type">
       <source-precedence>
         <source>reported current</source>
         <source>reported scheduled</source>
       </source-precedence>
       <other-attribute attribute='person/user-input'>
         <value>active</value>
         <value>idle</value>
       </other-attribute>
     </conflict-element>
   </resolve-conflicts>


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]