distinguishing between the
source of information (which element derived this information) and the
scope (all the elements that are affected by it)
That is then another issue that needs to be aligned with the presence
data model draft.
The presence data model draft states that:
Each of these data elements contains information (called attributes)
that >provide a description about the service, person, or device. It is
central >to this model that each attribute is affiliated with the
service, person, >or device because they describe that service,
presentity or device. This is >in contrast to a model whereby the
attributes are associated with the >service, presentity, or device
because they were reported by that service, >presentity, or device.
So in the presence model draft, the cell phone service would report that
you are driving using the <person> tuple, and the PDA would report that
you are in a meeting also using the <person> tuple.
This would be the case because the information applies to the person
(although it is reported by various services). It is then up to the
composition policy to decide which information should be displayed. It
could merge the information so that potentially conflicting information
is displayed to the watcher if that is the composition policy in use.
/Dag
-----Original Message-----
From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
Sent: den 11 oktober 2004 15:17
To: Dag Ekengren
Cc: Simple WG
Subject: Re: [Simple] Updated RPID
As Jonathan noted, alignment efforts are under way. However, the issue
you raise is somewhat more general, namely distinguishing between the
source of information (which element derived this information) and the
scope (all the elements that are affected by it). This becomes relevant
if different devices may arrive at conflicting information. For example,
my cell phone service may know that I'm driving (since it can detect
movement based on my cell coordinates), while my PDA might consult its
calendar and determine that I'm in a meeting (which I'm actually late
for...).
We agreed, I believe, that in many cases, only the watcher can be
sufficiently intelligent to deal with conflicting information and thus,
there need to be facilities for each element to report such information,
so that the watcher can determine whom to believe or just be confused.
In some cases, a composer can merge the data and remove contradictions,
but since the RPID format is also used for publishing, we need to be
able to carry this information in the element that it belongs to.
Thus, activities can be reported by a (service) tuple, a person or a
device, depending on the particular circumstances.
Dag Ekengren wrote:
I think the relationship between the latest RPID document and the
presence
data model document is a little unclear.
In RPID, it says that the "<activities> element describes what the
presentity is currently doing, expressed as an enumeration of
<activity>
elements". I think this clearly belongs to the <person> element in the
presence data model. In the examples in the RPID draft, the activities
element is applied to service tuples. Maybe it should be mentioned
that
these should be used on the <person> element?
Wouldn't it be a good idea to include the definitions of <person> and
<device> in the RPID draft?
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple