Subject: RE: [Simple] PUBLISH: identification of presence segments

From: [email-masked]
Date: Fri, 6 Jun 2003 15:56:26 +0300

Hi Thanos,

I think you are right in that using the tuple ID makes the assumption that the composer never merges or modifies the individual tuples, so that the ID is carried over to the watchers intact.

You also touch on a very interesting related topic of how to identify two "semantically identical" presence segments. Since the tuple IDs are generated at the source of presence information, it could be so that two sources publish the same presence segment using a different ID. 

In this case, the composer would need to know that the segments are in fact two representations of the same presence segment, and instead of composing them both in the presence document it should only use the most recent one of the two (and indicate a collision to the publisher of the stale one).

I think the only use case we considered in the interim was one where a user goes home, sees that her work PC is still publishing OPEN IM status, and needs to "steal" that particular publication away from the work PC. In this scenario, merely knowing the tuple ID would suffice.

So we have two issues to resolve:
(1) Can we restrict the composer so that published tuples are never merged 
   or modified?

(2) Can we define a way for the composer (and EPAs as well) to identify 
   "semantically identical" tuples when they have different IDs?

I think (1) has a more wider scope that deals with the models we have envisioned for presence composition. As was also stated in the interim, there may be security implications related to a composer modifying tuples, and this also relates to another discussion on as to how for example geoloc information is applied to a presence document. Is it a separate tuple or part of other tuples.

Even when answering "yes" to (1), (2) would most probably still be needed because of the reasons you point out. I could imagine that for some other event segments, such a definition of "semantically identical" could be relatively straight forward. However, with presence it may not be so simple.

Any thoughts on this?

Cheers,
Aki

 > -----Original Message-----
 > From: ext Thanos Diacakis [mailto:[email-masked]]
 > Sent: 05 June, 2003 19:56
 > To: Niemi Aki (NMP/Helsinki); [email-masked]
 > Subject: Re: [Simple] PUBLISH: identification of presence segments
 > 
 > 
 > Hi Aki,
 > 
 > (I'm assuming you're referring to the presence aggregation problem)
 > 
 > I think I remember the consensus being along those lines, 
 > but I'm not sure
 > this will work.  Here's why...
 > 
 > Recap: If two entities (say P1 and P2) are publishing presence for a
 > particular presentity, that include two semantically 
 > identical tuples, it is
 > hard for them to co-ordinate the tuple-ids.  By 
 > "semantically identical" I
 > mean they contain information about the same segment of state.
 > 
 > The assumption I think that we were working on is that P1 
 > will first publish
 > a tuple T1 with tuple ID, say X1.  P2 will be a subscriber to this
 > information, and will have a way to figure out that the 
 > tuple T1 with ID X1
 > is "semantically identically" to the tuple it wants to 
 > publish (ignoring
 > that this is not trivial), and thus P2 will publish a tuple 
 > T2 with ID X1.
 > The aggregator at the Presence Service will then replace T2 
 > with T1 (subject
 > to the other mechanism we're discussing).
 > 
 > Now the first problem is that if P1 and P2 simultaneously 
 > decide to publish
 > T1 and T2 respectively, they will each assign unique ids to 
 > two tuples that
 > are semantically the same.  To solve this we need to have a 
 > central entity
 > that can identify tuples that are "semantically identical" , 
 > and there are
 > some ways of doing so.
 > 
 > The second problem is that this mechanism relies on the tuples being
 > published having the same ID as the tuples in notifications.  This is
 > possible in some simple cases, but won't work when the 
 > presence information
 > being notified is based upon (but not verbatim copies) of 
 > the presence being
 > published.  For example, if a particular presence 
 > implementation takes
 > tuples A and B, does some complex calculation and publishes 
 > tuple C, then we
 > have a problem as there is no direct way to map tuple IDs between the
 > publish and notify operations.  (This also affects the 
 > versioning mechanism,
 > as you may no longer assume that P1 and P2 can see all 
 > aspects of what each
 > other is doing)
 > 
 > Thanos
 > ---
 > Thanos Diacakis
 > Openwave Systems
 > [email-masked]
 > +1-303 385 6705
 > 
 > ----- Original Message ----- 
 > From: <[email-masked]>
 > To: <[email-masked]>
 > Sent: Thursday, June 05, 2003 9:25 AM
 > Subject: [Simple] PUBLISH: identification of presence segments
 > 
 > 
 > > Hi All,
 > >
 > > One of the open issues in the PUBLISH work is how to 
 > identify specific
 > segments of state. Each event is supposed to define a way to 
 > identify a
 > specific segment. So far, we've decided that in presence 
 > publication, a
 > tuple corresponds to such a segment.
 > >
 > > I think the conclusion we arrived at in the interim 
 > meeting was that tuple
 > IDs would be used to identiy a specific presence tuple 
 > instead of the RPIDS
 > label-element.
 > >
 > > Just making sure this was the consensus. Anyone against?
 > >
 > > Cheers,
 > > Aki
 > > _______________________________________________
 > > Simple mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/simple
 > >
 > 
 > 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Thanos Diacakis" <[email-masked]>
Date: Fri, 6 Jun 2003 09:58:04 -0600

Hi Aki,

On your two issues:

(1) I don't think we can assume that tuples are never to be merged or
modified (or split out for that matter).  The easiest use case for this is
when one wants to lie, which means that the tuples contents need to be
changed for some subscriber or group of subscribers.  A different use case
could be something along the lines of a "rule" in the presence server saying
"if my IM at work is open, publish my work phone # tuple".  In this case,
one tuple triggers the publication of another tuple, but the first tuple
never gets out.

My broader point is that by allowing the transformation of tuples you enable
a rich set of presence functionality, whereas if you mandate that tuples
need to go through the presence service intact, then you've dumbed down the
service to an unacceptable level, where no cool features can be added.

(2) I totally agree here and this is related to the "what is a tuple"
discussion, so we should take this into consideration when having the "what
is a tuple" discussion.

Thanos
---
Thanos Diacakis
Openwave Systems

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, June 06, 2003 6:56 AM
Subject: RE: [Simple] PUBLISH: identification of presence segments

> Hi Thanos,
>
> I think you are right in that using the tuple ID makes the assumption that
the composer never merges or modifies the individual tuples, so that the ID
is carried over to the watchers intact.
>
> You also touch on a very interesting related topic of how to identify two
"semantically identical" presence segments. Since the tuple IDs are
generated at the source of presence information, it could be so that two
sources publish the same presence segment using a different ID.
>
> In this case, the composer would need to know that the segments are in
fact two representations of the same presence segment, and instead of
composing them both in the presence document it should only use the most
recent one of the two (and indicate a collision to the publisher of the
stale one).
>
> I think the only use case we considered in the interim was one where a
user goes home, sees that her work PC is still publishing OPEN IM status,
and needs to "steal" that particular publication away from the work PC. In
this scenario, merely knowing the tuple ID would suffice.
> I think (1) has a more wider scope that deals with the models we have
envisioned for presence composition. As was also stated in the interim,
there may be security implications related to a composer modifying tuples,
and this also relates to another discussion on as to how for example geoloc
information is applied to a presence document. Is it a separate tuple or
part of other tuples.
>
> Even when answering "yes" to (1), (2) would most probably still be needed
because of the reasons you point out. I could imagine that for some other
event segments, such a definition of "semantically identical" could be
relatively straight forward. However, with presence it may not be so simple.

---

From: "Thanos Diacakis" <[email-masked]>
Date: Fri, 6 Jun 2003 09:58:04 -0600

Hi Aki,

On your two issues:

Thanos
---
Thanos Diacakis
Openwave Systems