Subject: [Simple] Single / multiple tuples

From: Cnaan Oded <[email-masked]>
Date: Mon, 23 Jun 2003 09:24:08 +0300

Single tuple
----------------
There are cases, where a PS would prefer using a single tuple to represent
each device (or service) and specify all the services (devices) associated
with it. For example, a tuple that represents a mobile phone that has an IM,
PTT and voice services.
 
This structure can be achieved using PIDF but the result would be very hard
to manage or even understand. Following the above example, the tuple may
look like that:
 
<presence>
  <tuple id="A1">
    <status>
      <basic>online</basic>
      <im:im>busy</im:im>
       <ext:voice-call>meeting</ext:voice-call> 
       <ext:ptt>offline</ext:ptt>
    </status>
    <contact>im:[email-masked]</contact> 
    <contact>sip:[email-masked]</contact>
    <contact>tel:+44-254-54462211</contact>
  </tuple>
</presence>
 
There are several problem with this representation:
1. There is no way to associate each of the services with its matching
contact. In other words, a UA cannot determine that the second contact
element should be used for PTT.
2. There is no specification of a service name/ID. If a UA is running 2 IM
clients (e.g., MSN and AOL), there is no way to determine which one is
specified by the im:im element. Moreover, any additional information within
the tuple cannot be associated with a specific service since there is no
sufficient internal structuring.
3. The PS and UA must have a-priori agreed on the _extended_ elements and
their meaning
4. There is no way to determine if the tuple represents a device or a
service.
5. There is no way to specify, when a tuple represents a device, the device
type (e.g., mobile phone)
 
Note that RPIDS, which adds some information elements to the PIDF structure,
does not provide any solutions to these problems as well.
 
Several steps can be taken to fix these problems:
1. The first problem can be solved in several ways. One alternative would be
to create an internal tuple format that structures the elements for each
services. 
2. A collection of elements (representing a device/service) would be given a
name/ID that will be used for both UI representation (e.g., "MSN Messenger")
and parsing.
3. This problem will probably not be completely solved and integration will
be required.
4. Add an attribute to the tuple element that specifies what it represents.
I understand that there is a big discussion on "what a tuple is" but we can
also define 2-3 values and leave it to implementers to add their own.
 5. Add an attribute to the tuple element specifying the device type. Again,
some obvious values can be determined, leaving implementers to add their own
in the future.
 
Oded