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: [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.
 > >

---

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

> 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.
> 
> 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
>

---

From: Adam Roach <[email-masked]>
Date: Sun, 8 Jun 2003 12:08:32 -0500

Thanos Diacakis [mailto:[email-masked]] writes:

>...[T]his is related to the "what is a tuple"
> discussion, so we should take this into consideration when 
> having the "what is a tuple" discussion.

Actually, I would argue that the answer to this is not just
related to the "what is a tuple" discussion; based on the
arguments I've seen in this thread, it is *predicated* on
it. Almost every argument so far has made implicit or
explicit assumptions about tuples that may or may not end
up being true, pending the output of the "what is a tuple?"
team.

I would suggest that we table trying to solve the
identification problem until we actually have a
shared view of what it is we're trying to identify.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 9 Jun 2003 10:07:34 -0500

The consensus that was reached among the participants at
the interim meeting, by my recollection, is that
identification of subdocuments for publication was an
issue that would be decided on a package-by-package
basis. Given the wide variation in the body types that
have and will be developed for these event packages,
I contend that this is the only tractable way to
approach the problem, so revisiting this decision
seems pointless.

As far as I can tell, the ongoing conversation is
trying to solve the problem of how to perform
this identification for presence; i.e., how to
identify PIDF tuples. I think it's pretty self-
explanatory that trying to identify something
before we're even sure what that thing is won't
yield much progress.

To put it another way: I have a hunch that once
we come to consensus on what a tuple is, the
issue of how to identify one will become obvious.

/a

> From: Thanos Diacakis [mailto:[email-masked]]
> Sent: Monday, June 09, 2003 8:05
> To: Adam Roach; [email-masked]; [email-masked]
> Well, yes and no.  Although that appears as a valid way to go 
> about this, as
> you pointed out in your previous email, PUBLISH might be used 
> for other
> things, so defining what a tuple means for *presence* won't 
> really help us.
> We'd need to define what a tuple is in general.  This gives 
> the problem a
> very broad scope, where a tuple is just a container.  Then 
> one of the very
> few things we might be able to define is how to identify a tuple...
> 
> Thanos
> ---
> Thanos Diacakis
> Openwave Systems
> From: "Adam Roach" <[email-masked]>
> To: "'Thanos Diacakis'" <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Sunday, June 08, 2003 11:08 AM

---

From: Adam Roach <[email-masked]>
Date: Mon, 9 Jun 2003 10:07:34 -0500

/a

---

From: [email-masked]
Date: Tue, 10 Jun 2003 04:28:14 +0300

I agree. As you suggest, I think at this point it is probably best to table the identification issue, pending the "what is a tuple" results. Especially since I think this issue can be treated independently from the versioning issue, as well as independent from any text we may need to add explaining the generic property of "semantically identical" event segments.

Thanks,
Aki 

 > From: ext Adam Roach [mailto:[email-masked]]
 > Sent: 09 June, 2003 18:08
 > To: 'Thanos Diacakis'; Adam Roach; Niemi Aki (NMP/Helsinki);
 > [email-masked]

---

From: [email-masked]
Date: Tue, 10 Jun 2003 04:28:14 +0300

Thanks,
Aki

---

From: Cnaan Oded <[email-masked]>
Date: Sun, 22 Jun 2003 13:48:53 +0300

I hope that we can agree, that in a typical implementation, users will not
be exposed to tuples and might not even know that they exist. Tuples are
just a method for describing Presence information in a hierarchical way that
can be understood by UAs (and PSs). Saying that, it would be very rare to
have _users_ selecting tuple IDs or referring to tuples by their names. In
most cases, users will change their 'Video' availability and have their UA
handle the details for them.

I believe that the tuple identification problem is caused by using the same
Presence document for both PUBLISH and NOTIFY. Let's take for example user A
with the following Presence document, as generated by the PS (schematic
syntax):

<presence>
  <tuple id="A1" ext:device="mobile-phone">
    <status>
       <basic>online</basic>
       <im:im>busy</im:im>
       <ext:voice-call>meeting</ext:voice-call>
    </status>
    <contact>im:[email-masked]</contact>
    <contact>tel:+44-254-54462211</contact>
  </tuple>

  <tuple id="A2" ext:device="PC">
    <status>
       <basic>online</basic>
       <im:im>offline</im:im>
    </status>
    <contact>im:[email-masked]</contact>
  </tuple>
</presence>

The first tuple represents a mobile phone that runs an IM client and that is
capable of receiving phone calls. The latter describes a PC running an IM
client from the same service provider. Changing the IM availability on the
PC requires the PC to recognize that the phone has published voice
capabilities as part of the same tuple and even to re-publish information
related to the phone.

A different approach would be to have publishers send only raw information,
leaving the document composition task to the Presence Server. This allows
the PS to apply rules as well as transformations on the raw information,
without the need to 'identify' tuples. Doing so, also solves the problem of
tuple IDs as only the server now generates them.

When publishing Presence information, there are 3 basic questions to answer:
1. What is the information element that we would like to update (e.g., MSN
IM Service)
2. What is the new value of the information element (e.g., status is BUSY
and contact is ...)
3. To which device/service this element belongs (e.g., specific phone)

These questions can be used on any Presence view (i.e., Device/Service/Media
based). For example, in a service-view, the third answer may be "specific
service".

Now, let's see how this new approach facilitates the publication problems
identified by Thanos, Hisham and Aki.
1. Thanos showed that having 2 UAs publish using the same tuple ID may
result in a conflict on the PS. Here, tuple IDs are not used for
publication. If 2 UAs publish a new IM status, they do not relate to a
specific tuple, but to the same service.
2. Thanos also raised the problem of having PS change tuple IDs based on
some server based rules (e.g., transformation rules). Here, there is no
conflict as the UA publishes raw info regardless of the tuple structure.
3. Aki suggested to restrict the composer so that published tuples are never
merged or modified. This is no longer required as we've separated between
the published info and the Presence document sent to watchers.
4. Hisham raised the question of relating 2 tuples and mentioned that in
some circumstances, there would be a need to publish the whole document to
avoid conflicts.. This is a non-issue as we now publish raw info not related
to a specific tuple.

We can now build an XML document that will be used for publications. This
document needs to answer the above questions and, for optimization, allow
publishing more than one update at a time. It will be used as part of
PUBLISH messages while PIDF will continue to serve NOTIFY messages.

I understand that this idea conflicts previous PUBLISH drafts but I hope
you'll consider it as it solves many of the problems identified in this
thread.

Oded

---

From: [email-masked]
Date: Tue, 24 Jun 2003 16:10:41 +0300

Hi Oded,

Inline.

 > From: ext Cnaan Oded [mailto:[email-masked]]
 > Sent: 22 June, 2003 13:49
 > To: 'Thanos Diacakis'; Khartabil Hisham (NMP/Helsinki); Niemi Aki
 > (NMP/Helsinki); [email-masked]
 > can be understood by UAs (and PSs). 

Yes.

 > Saying that, it would be 
 > very rare to

I would even go further than that and say that in most cases the user won't manually change their 'video' availability, but instead the application will do it. For example, if a user is already on a video call, her presence might automagically show unavailability.

 >     <contact>tel:+44-254-54462211</contact>

As Paul pointed out in a separate thread, the <tuple> element is only supposed to contain a single <contact> element or no contact at all. Therefore I think that the tuple needs to be split into two separate tuples for this to work.

 > capabilities as part of the same tuple and even to 

This seems to be along the lines of a concept Thanos brought in, namely the concept of "semantically equivalent" tuples, or event segments. 

We need to have a way for the composer to detect when two independent publications are in fact two representations of a single tuple, instead of being representations of two separate tuples.

 > tuple IDs as only the server now generates them.

I think the problem still remains. How would the composer know if two chunks of raw data are representations of the same piece of presence state?
 
 > based). For example, in a service-view, the third answer may 

We have RPIDS defined for the PIDF already, so perhaps they could also work here?
 
 > PUBLISH messages while PIDF will continue to serve NOTIFY messages.

If I understand you correctly, the proposal is to specify a new XML document for publications instead of using PIDF directly?

This relates to another open item we have on whether to have the PUBLISH always carry a PIDF fragment, namely a tuple fragment or perhaps a presentity-level note fragment.

But overall, I still think it is important to maintain using PIDF in PUBLISH in some shape or form, because the identification problem still needs to be solved. I don't think it helps if we end up with different identification mechanisms for PUBLISH and NOTIFY. E.g., some new way in PUBLISH, and RPIDS+PIDF in NOTIFY.

Also, other event state may not share this problem in any case, so by default, the notification and the publication would share a common format.

Cheers,
Aki

---

From: [email-masked]
Date: Tue, 24 Jun 2003 16:10:41 +0300

Hi Oded,

Inline.

Yes.

 

Cheers,
Aki