Subject: [Simple] PUBLISH: identification of presence segments

From: [email-masked]
Date: Thu, 5 Jun 2003 18:25:11 +0300

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

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 5 Jun 2003 10:56:09 -0600

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.

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 5 Jun 2003 10:56:09 -0600

Hi Aki,

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: Sean Olson <[email-masked]>
Date: Thu, 5 Jun 2003 09:56:34 -0700 (PDT)

Agreed. The tuple ID is the only really guaranteed
unique value on which to base this.

--- [email-masked] wrote:
> 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.
> 

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Thu, 5 Jun 2003 09:56:34 -0700 (PDT)