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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jun 2003 09:30:27 -0400

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

Based on a 'regularized' proposal of tuple view that has been discussed, 
the problem is avoided by having each tuple have no more than one 
Contact (plus an AOR reference). This follows standard design rules for 
relational databases, where having multiple columns that have the same 
content is generally considered a bad idea. Once you have that, 
composition rules can be used by various entities to compose any desired 
view.

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

The new RPIDS drafts, submitted early this morning and found at 
http://www1.cs.columbia.edu/sip/drafts/draft-ietf-simple-rpids-00.txt, 
offers the 'class' attribute for this, if I understand you correctly. I 
didn't get to write up the tuple composition rules in the draft yet, 
unfortunately.

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

In my personal opinion, until somebody provides a clear and concise 
definitions of these 'what a tuple represents' labels, I see this doing 
more harm than good. Labeling conveys certainty where none exists and 
thus encourages brittle implementations that only deal with the set of 
labels that the implementor considers important (or existed at the time 
the implementation was written).

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

I'm afraid there are no 'obvious' values, but maybe you have suggestions.

> Oded

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Jun 2003 09:30:27 -0400

---

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

Oded,

As I commented in an earlier reply, you can't use multiple contacts in a 
single tuple, so your examples require some rework. However you do bring 
up something I want to ask about:

You talk about "IM, PTT and voice services". This concept of "service" 
has been bandied about here, but I have never been able to get a clear 
understanding of what it means. Can you define what you mean by 
"service"? How is it different from "device" or "media"?

	Paul

Cnaan Oded wrote:
> 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.
>  
> 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

---

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

Oded,

	Paul