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

From: [email-masked]
Date: Fri, 6 Jun 2003 17:05:53 +0300

We need something to identify not just the tuple in which the user wants to override from a terminal that doesn't own that tuple, but aspects within the tuple.

Imagine I have a device D1 (office PC) that publishes one device tuple T1 that describes all the services available in that device (IM, voice, video). Now I go home and only want to override the part of the device tuple T1 describing the IM, using my home device D2. I therefore have to publish a new tuple T2 from D2 that is just related to the part of the old tuple T1. The compositor has to relate the 2 tuples somehow. A solution for this is to mandate that no matter what part of the tuple a second device wants to modify from a second terminal, that second device MUST publish the whole tuple again. This makes it easier for the compositor in that it just replaces the original tuple instead of trying to compose T2 into parts of T1.

Having said that, the problem stays: How do you relate those 2 tuples, especially since the compositor can create tuple-ids on its own when composing separate tuples into one.

Can a human be involved in this? The human sets ids or keywords for services, devices or whatever s/he is publishing presence for. Taking the example above:

When I publish from work, I give unique Ids to IM, voice, and video (office-pc-im, office-pc-voice, office-pc-video, respectively) that I know about and remember. Regardless of how the implementation in the terminal interprets those and puts them in a tuples (one tuple or 3), I have now uniquely identified things for myself. When I go home and want to override my IM that I published from work, I input the id office-pc-im before I publish.

I haven't thought about the proposal too much, just thinking aloud, so don't hose me :)

Regards,
Hisham

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 06, 2003 3:56 PM
> To: [email-masked]; [email-masked]
> 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.
> 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Thanos Diacakis" <[email-masked]>
Date: Fri, 6 Jun 2003 10:05:32 -0600

Hi Hisham,

some comments inline.

Thanos
---
Thanos Diacakis
Openwave Systems

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

> We need something to identify not just the tuple in which the user wants
to override from a terminal that doesn't own that tuple, but aspects within
the tuple.
>
> Imagine I have a device D1 (office PC) that publishes one device tuple T1
that describes all the services available in that device (IM, voice, video).
Now I go home and only want to override the part of the device tuple T1
describing the IM, using my home device D2. I therefore have to publish a
new tuple T2 from D2 that is just related to the part of the old tuple T1.
The compositor has to relate the 2 tuples somehow. A solution for this is to
mandate that no matter what part of the tuple a second device wants to
modify from a second terminal, that second device MUST publish the whole
tuple again. This makes it easier for the compositor in that it just
replaces the original tuple instead of trying to compose T2 into parts of
T1.

Well, if you want the compositor to merge your presence information, you
must structure it in the units that it can deal with, and I think what we're
discussing here is that the compositor will be able to deal with tuple-sized
units.  If you don't want the compositor to do it, then you would need to
publish the whole thing again.

> Having said that, the problem stays: How do you relate those 2 tuples,
especially since the compositor can create tuple-ids on its own when
composing separate tuples into one.

Agreed.

>
> Can a human be involved in this? The human sets ids or keywords for
services, devices or whatever s/he is publishing presence for. Taking the
example above:
>
> When I publish from work, I give unique Ids to IM, voice, and video
(office-pc-im, office-pc-voice, office-pc-video, respectively) that I know
about and remember. Regardless of how the implementation in the terminal
interprets those and puts them in a tuples (one tuple or 3), I have now
uniquely identified things for myself. When I go home and want to override
my IM that I published from work, I input the id office-pc-im before I
publish.
> I haven't thought about the proposal too much, just thinking aloud, so
don't hose me :)

This could work, but I think the use cases it would support would be very
limited, given the manual input nature of the solution.  We need to come up
with a programatic solution that uniquely identifies two tuples as being
"semantically identical" while at the same time being careful not to kill
the presence format extensibility.

---

From: "Thanos Diacakis" <[email-masked]>
Date: Fri, 6 Jun 2003 10:05:32 -0600

Hi Hisham,

some comments inline.

Thanos
---
Thanos Diacakis
Openwave Systems

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

Agreed.