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

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 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2003 09:45:33 -0400

Oded,

Your examples exhibit a misconception: they are using multiple <contact> 
  entries per tuple, but only one is permitted. I suspect that 
correcting that will require changes to your thesis, so I am not going 
to otherwise comment yet.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2003 09:45:33 -0400

Oded,

	Paul