Subject: RE: [Simple] Tuple references and device coupling

From: [email-masked]
Date: Tue, 1 Apr 2003 11:40:51 +0300

I agree. First and foremost, a tuple should represent a service. Providing the device on which the service is running is also valuable, but I think this is the correct relationship between the two.

Also, seems to me that RPIDS provides you with exactly this with the help of <class> and <devicetype> elements. Do we need something more than that?

Cheers,
Aki
 
 -----Original Message-----
From: ext Cnaan Oded [mailto:[email-masked]]
Sent: 01 April, 2003 10:03
To: 'Sean Olson'; Rosen, Brian; Jonathan Rosenberg
Cc: [email-masked]
Subject: RE: [Simple] Tuple references and device coupling

I think that forcing all tuples to represent devices would be too limiting in the real world. As I mentioned in my previous email, there are also services without devices (e.g., email) and cases where the service is using an unknown device. A more general solution would be to allow a tuple to represent either a service or a device.
I believe that solving the problem of relationship between tuples and tuple context would not be enough. The issue of how a service (application) reports on which device it is running is crucial for the completeness of the solution.
 
Oded Cnaan 

> -----Original Message----- 
> From: Sean Olson [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2003 4:25 AM 
> To: Rosen, Brian; Jonathan Rosenberg 
> Cc: Cnaan Oded; [email-masked] 
> Subject: RE: [Simple] Tuple references and device coupling 
> 
> 
> Sounds like a reasonable way forward. My only 
> comment is that we might wish to model applications 
> independent of a device, but that could be a future 
> improvement. 
> 
> Based on this understanding, it would seem that 
> tuple == device? 
> 
> 
> 
> --- "Rosen, Brian" <[email-masked]> wrote: 
> > Perhaps the time has come to take this particular 
> > bull by the horns 
> > and make it EXPLICIT what the tuple represents. 
> > We've had 
> > too many disagreements on mechanisms where the 
> > parties want the 
> > tuple to represent different things.  Our solutions 
> > thus far 
> > usually mean widening options to make all things 
> > possible. 
> > 
> > Pehaps we can make an explicit tree shaped hierarchy 
> > where a 
> >     User may have a series of 
> >             Devices, each one of which      may have a number of 
> >                     Applications 
> > Each of these can provide presence. 
> > 
> > If we were to go this far, I'd like links between 
> > them (parent/sibling) 
> > so that in a real world mixed environment, you have 
> > a chance to 
> > figure out what is happening. 
> > 
> > Brian 
> > 
> > > -----Original Message----- 
> > > From: Sean Olson [mailto:[email-masked]] 
> > > Sent: Monday, March 31, 2003 1:11 PM 
> > > To: Jonathan Rosenberg 
> > > Cc: Cnaan Oded; [email-masked] 
> > > Subject: Re: [Simple] Tuple references and device 
> > coupling 
> > > 
> > > 
> > > Understood... now the next immediate question is: 
> > > 
> > > Does the syntax provided by PIDF contain the 
> > > semantics of device, application, and user? 
> > > 
> > > Of course you can build this with the syntax of 
> > > a tuple. The problem is that you can build this 
> > > in more than one way and there is no clear 
> > > standard way to do this. 
> > > 
> > > I was hoping that RPIDS would solve this, at 
> > > least for the SIMPLE community. 
> > > 
> > > Am I wrong? 
> > > 
> > > --- Jonathan Rosenberg <[email-masked]> 
> > > wrote: 
> > > > It all comes back to the same problem - what 
> > does a 
> > > > tuple represent? 
> > > > 
> > > > Ultimately, tuples (and in general, a presence 
> > > > document) are tools for 
> > > > modeling real-world systems that have components 
> > > > like people, devices, 
> > > > applications, and so on. We NEED to have 
> > agreed-upon 
> > > > definitions of what 
> > > > a tuple is, and how it is used to model 
> > real-world 
> > > > systems, or these 
> > > > problems will continue to plague us. 
> > > > 
> > > > What Oded is saying is that the presence 
> > document 
> > > > has to take into 
> > > > account the fact that there are relationships 
> > > > between devices and 
> > > > applications in the real world, and the model 
> > needs 
> > > > to take that into 
> > > > account. 
> > > > 
> > > > -Jonathan R. 
> > > > 
> > > > Sean Olson wrote: 
> > > > > There seems to be a third option which is 
> > popular 
> > > > > as well. The tuple ID is just an ordering 
> > > > mechanism 
> > > > > within an XML document to determine when 
> > tuples 
> > > > are 
> > > > > added and removed. Additional syntax is then 
> > > > required 
> > > > > to achieve the semantics of device/service 
> > that 
> > > > you 
> > > > > mention below. This appears to be the approach 
> > 
> > > > > adopted in the RPIDS draft. Perhaps Henning or 
> > > > Paul 
> > > > > can comment? 
> > > > > 
> > > > > Regards, 
> > > > > Sean 
> > > > > 
> > > > > --- Cnaan Oded <[email-masked]> 
> > wrote: 
> > > > > 
> > > > >>Although the question "what a tuple 
> > represents" 
> > > > has 
> > > > >>not been discussed in 
> > > > >>depth yet, it seems that most implementation 
> > have 
> > > > >>chosen to either represent 
> > > > >>devices or services. For example, a tuple may 
> > > > >>represent a cell phone but can 
> > > > >>also represent an IM client running on a 
> > mobile 
> > > > >>phone. 
> > > > >> 
> > > > >>Here is a simple example of 2 such tuples: 
> > > > >> 
> > > > >><?xml version="1.0" encoding="UTF-8"?> 
> > > > >><presence 
> > xmlns="urn:ietf:params:xml:ns:cpim-pidf" 
> > > > >>  entity="pres:[email-masked]"> 
> > > > >> 
> > > > >>   <tuple id="phone"> 
> > > > >>      <status> 
> > > > >>         <basic>open</basic> 
> > > > >>      </status> 
> > > > >>      <contact>tel:09012345678</contact> 
> > > > >>    </tuple> 
> > > > >> 
> > > > >>   <tuple id="mobile-im"> 
> > > > >>      <status> 
> > > > >>         <basic>open</basic> 
> > > > >>         <im:im>busy</im:im> 
> > > > >>      </status> 
> > > > >>      <contact>sip:[email-masked]</contact> 
> > > > >>    </tuple> 
> > > > >> 
> > > > >></presence> 
> > > > >> 
> > > > >> 
> > > > >>There are cases where there is a relationship 
> > > > >>between these tuples. For 
> > > > >>example, in the above example, the IM client 
> > is 
> > > > >>running on the same device 
> > > > >>described by the first tuple, meaning that 
> > there 
> > > > >>might be some information 
> > > > >>(e.g., location) that is related to both 
> > tuples. 
> > > > >> 
> > > > >>One approach to handle it would be to 
> > duplicate 
> > > > this 
> > > > >>information. Having 
> > > > >>'Location' described in the tuple representing 
> > the 
> > > > >>device as well as the one 
> > > > >>representing the service. This approach is not 
> > > > >>efficient in terms of volume 
> > > > >>as many tuples might relate to the same 
> > > > information. 
> > > > >> 
> > > > >>Another possible solution would be to create a 
> > > > >>reference between tuples, in 
> > > > >>this example between a "service tuple" and a 
> > > > "device 
> > > > >>tuple". In this case, 
> > > > >>the information is described only once but is 
> > > > >>referenced from other tuples. 
> > > > >>For example: 
> > > > >> 
> > > > >>   <tuple id="mobile-im" ref="phone"> 
> > > > >>      <status> 
> > > > >>         <basic>open</basic> 
> > > > >>         <im:im>busy</im:im> 
> > > > >>      </status> 
> > > > >>      <contact>sip:[email-masked]</contact> 
> > > > >>    </tuple> 
> > > > >> 
> > > > >>Following the latter option, the device 
> > status, 
> > > > >>location, LCD resolution or 
> > > > >>any other attributes associated with the 
> > device 
> > > > may 
> > > > >>be picked up from the 
> > > > >>"phone" tuple so that the "mobile-im" tuple 
> > > > >>represents only the service 
> > > > >>characteristics. 
> > > > >> 
> > > > >>Following the above example, if the user is on 
> > a 
> > > > >>call, and his device state 
> > > > >>changes from "open" to "call" (assuming this 
> > is a 
> > > > >>valid value), the "phone" 
> > > > >>tuple is the only one that changes (and will 
> > be 
> > 
> === message truncated === 
> 
> 
> __________________________________________________ 
> Do you Yahoo!? 
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! 
> http://platinum.yahoo.com 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Tue, 1 Apr 2003 13:51:52 +0300

Hi,
 
As Aki already said RPIDS should give the flexibility to express what
tuple represents. At a moment application can give the content
information in <contact> element so that correct address can be
contacted. Are you saying that there is a need to have some addition
indentifier for the actual device or would this be enough?
 
- Mikko 

	-----Original Message-----
	From: ext Cnaan Oded [mailto:[email-masked]] 
	Sent: Tuesday, April 01, 2003 10:03 AM
	To: 'Sean Olson'; Rosen, Brian; Jonathan Rosenberg
	Cc: [email-masked]
	Subject: RE: [Simple] Tuple references and device coupling

	I think that forcing all tuples to represent devices would be
too limiting in the real world. As I mentioned in my previous email,
there are also services without devices (e.g., email) and cases where
the service is using an unknown device. A more general solution would be
to allow a tuple to represent either a service or a device.

	I believe that solving the problem of relationship between
tuples and tuple context would not be enough. The issue of how a service
(application) reports on which device it is running is crucial for the
completeness of the solution.

	Oded Cnaan

---

From: Ben Campbell <[email-masked]>
Date: 01 Apr 2003 14:21:23 -0600

> independent of a device, but that could be a future

I was thinking this exact same thing. Using the IM example, I may want
to say something about my reachability by IM in general, and something
else about any given device I might be reachable via IM at the moment.

---

From: Cnaan Oded <[email-masked]>
Date: Wed, 2 Apr 2003 16:09:25 +0300

The question that arises here is why do we actually need to 
 define what a tuple is. Tuples are associated with contact 
 addresses so that you can describe both devices and services 
 without defining what they are.
 
 In my mind, the 4 major differences between services and devices are:
 
 1. A service may be available simultaneously from more than one device
 2. A service may be available each time from a different device
 3. A service may not be associated with any device (e.g., email)
 4. The presence information of a service _may_ be affected by 
 the presence info of the device (but not the other way around)
 
 Presence tuples should be able to describe a complex world of 
 services and devices, and since services might be running on 
 specific devices, there is coupling between the two. You can 
 either duplicate the data or reference another tuple but you 
 still need to compose the tuples in a way that the combined 
 device-service information is understood by watchers.
 
 If we want to have only one type of tuple, I would go for the 
 opposite solution where a device can be considered a service. 
 For example, my mobile phone, which has several 
 communications capabilities (e.g., voice, sms, mms etc.) may 
 be considered as a "phone service". 
  
 Oded Cnaan
 
> > From: Ben Campbell [mailto:[email-masked]]
> > Sent: Wednesday, April 02, 2003 12:15 AM
> > To: Rosen, Brian
> > Cc: Cnaan Oded; 'Sean Olson'; Jonathan Rosenberg; Simple WG
> > On Tue, 2003-04-01 at 14:45, Rosen, Brian wrote:
> > > You aren't helping :)
> > 
> > Sorry, I am having some difficulty expressing the concept.
> > 
> > > 
> > > Do you see a useful distinction between a "user" and a "service"
> > > in the context of presence?  By that do you see a need for
> > > one person to have multiple services where there is a need show,
> > > for a single presentity each of the services?
> > 
> > 
> > So, what does the word "service" mean in this context? Is IM 
> > in general
> > a service, where I might have multiple URIs at which I can 
> > accept IMs at
> > some time or another? Or is a "service" something that runs on a
> > particular address and port (i.e., on a device), If you mean 
> > the second,
> > then I can construct a URI that refers to the service, which I think
> > makes the distinction between service and device irrelevant. 
> > 
> > But I _think_ we mean the first. So, I _think_ your question 
> > refers to,
> > for example, the idea that I might have a voice service and an IM
> > service, each of which has several possible contact 
> > addresses. Further,
> > I might want to assert something about the IM service, that 
> applies to
> > _all_ IM contacts. I think this idea has some use, but could 
> > be modeled
> > by simply applying the same attribute to each IM related 
> tuple, rather
> > than having some special "service" tuple. 
> > 
> > Sorry if this continues to not help, but I honestly think that not
> > everyone participating in this tread shares the same 
> definition of the
> > term "service"
> > 
> > 
> > > 
> > > I'm having trouble here.  I don't like showing devices, but too
> > > many people think there is value in having a single 
> presence system
> > > that implements a presentity that publishes presence for each of
> > > the devices.  Here I want to ask if there is need to show presence
> > > for separate applications/services?
> > > 
> > > Brian
> > >

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Apr 2003 08:20:30 -0500

Oded

We need to define what a tuple is because we keep getting
wrapped around the axle on what it means when we define the contents
of one, or the relationship between them.  We can certainly
ignore the problem, the only consequence of which is that
many watchers won't interpret information presentities think is
perfectly obvious.

If your watcher registers at my presence service, I'm going to
send you ONE tuple, with ONE URI that tells you how available
I am for voice, video and IM.  What is your watcher going to do?

If your presence service delivers my watcher a dozen tuples,
each describing presence for one service on one device, how is
my watcher supposed to figure out the relationships?
Worse, if you as a user have six service providers each of which
provide a few of these tuples, what do you suppose the chances
that my watcher can provide a coherent display of your presence are?

Brian

-----Original Message-----
From: Cnaan Oded [mailto:[email-masked]]
Sent: Wednesday, April 02, 2003 8:00 AM
To: 'Ben Campbell'; Rosen, Brian
Cc: 'Sean Olson'; Jonathan Rosenberg; Simple WG
Subject: RE: [Simple] Tuple references and device coupling

The question that arises here is why do we actually need to define what a
tuple is. Tuples are associated with contact addresses so that you can
describe both devices and services without defining what they are.
In my mind, the 4 major differences between services and devices are: 
1. A service may be available simultaneously from more than one device 
2. A service may be available each time from a different device 
3. A service may not be associated with any device (e.g., email) 
4. The presence information of a service _may_ be affected by the presence
info of the device (but not the other way around)
Presence tuples should be able to describe a complex world of services and
devices, and since services might be running on specific devices, there is
coupling between the two. You can either duplicate the data or reference
another tuple but you still need to compose the tuples in a way that the
combined device-service information is understood by watchers.
If we want to have only one type of tuple, I would go for the opposite
solution where a device can be considered a service. For example, my mobile
phone, which has several communications capabilities (e.g., voice, sms, mms
etc.) may be considered as a "phone service". 
 
Oded Cnaan 
> I might want to assert something about the IM service, that applies to 
> by simply applying the same attribute to each IM related tuple, rather 
> everyone participating in this tread shares the same definition of the 
> term "service" 
> 
> 
> > 
> > many people think there is value in having a single presence system 
> > > Sent: Tuesday, April 01, 2003 3:33 PM 
> > > To: Cnaan Oded 
> > > Cc: 'Sean Olson'; Rosen, Brian; Jonathan Rosenberg; Simple WG 
> > > As I think about this, I come to the conclusion that the 
> distinction 
> > > between services and devices is not entirely clear in 
> this context. 
> > > Brian modeled as devices running one or more services, but I think 
> > > others may be thinking of a service as something that may run 
> > > on one or 
> > > more devices. 
> > > 
> > > Is the distinction that a device is something we can 
> represent with a 
> > > URI, and a service is not? That seems a little unnatural. 
> Applications 
> > > running on a device typically _can_ be represented by URIs, 
> > > at least if 
> > > we are expected to talk to them. Even in your email 
> example, there may 
> > > not be a clear device, but there _is_ an addressable entity; 
> > > that is, I 
> > > could get a mailto: URL in a tuple contact, and do something 
> > > useful with 
> > > it. 
> > > 
> > > If we are thinking in terms of multiple addressable entities 
> > > being part 
> > > of a service, that would seem to impy a way to assign a value 
> > > to a group 
> > > of tuples. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Tue, 2003-04-01 at 01:02, Cnaan Oded wrote: 
> > > > I think that forcing all tuples to represent devices 
> would be too 
> > > > limiting in the real world. As I mentioned in my previous 
> > > email, there 
> > > > are also services without devices (e.g., email) and 
> cases where the 
> > > > service is using an unknown device. A more general 
> solution would be 
> > > tuples and 
> > > > tuple context would not be enough. The issue of how a service

---

From: Cnaan Oded <[email-masked]>
Date: Wed, 2 Apr 2003 16:34:51 +0300

Brian,

I totally agree with you and this is exactly why I started this thread. In
my previous email I related to Ben Campbell's observations regarding the
need to have tuples that represent services.
 
Oded Cnaan

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2003 4:21 PM
> To: 'Cnaan Oded'; 'Ben Campbell'
> define what a
> the presence
> services and

---

From: [email-masked]
Date: Wed, 2 Apr 2003 17:03:10 +0300

How useful is a device that does not have any services on it? Pretty useless. What does it mean when a device publishes a tuple saying that this device is OPEN? Open for what? There must be a service running on it.

You might ask "what about email?". Well, that's a service. If a device is going to publish presence info about another device, then it's really publishing presence info about the services on that device.

Can a tuple, representing a device, carry presence info about all services on that device?
Can a tuple, representing a service, carry presence info about all devices enabled with that service?

If not, then each device has to publish a separate tuple for a service. It is the job of the compositor to combine those. I fail to see how those can be combined per device.

Regards,
Hisham

-----Original Message-----
From: ext Cnaan Oded [mailto:[email-masked]]
Sent: Wednesday, April 02, 2003 4:35 PM
To: 'Rosen, Brian'; Cnaan Oded; 'Ben Campbell'
Cc: 'Sean Olson'; Jonathan Rosenberg; Simple WG
Subject: RE: [Simple] Tuple references and device coupling

Brian, 
I totally agree with you and this is exactly why I started this thread. In my previous email I related to Ben Campbell's observations regarding the need to have tuples that represent services.
 
Oded Cnaan

---

From: [email-masked]
Date: Wed, 2 Apr 2003 17:16:20 +0300

Brian, all,

Some comments/questions below.

 > From: ext Rosen, Brian [mailto:[email-masked]]
 > Sent: 02 April, 2003 16:21

By device, do you mean that each one has a unique contact address, some other unique identifier, or a specific device type (phone, mobile, PDA)?

Also, can you elaborate a little bit on what the relationship beyond belonging to the same presentity we need for those tuples?

 > that my watcher can provide a coherent display of your presence are?

Isn't it just as likely for a user to be a principal of several presentities, each provided by a different service provider? In that case the chances are no better or worse.

Cheers,
Aki

---

From: Cnaan Oded <[email-masked]>
Date: Wed, 2 Apr 2003 17:50:36 +0300

inline
 
Oded Cnaan

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2003 5:03 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> How useful is a device that does not have any services on it? 
> Pretty useless. What does it mean when a device publishes a 
> tuple saying that this device is OPEN? Open for what? There 
> must be a service running on it.
> 

A device with no service might be very meaningful as it still allows you to
make decisions regarding how to communicate. Remember that devices (although
not all devices, and these might not have a tuple) such as mobile phones are
capable of communicating without running any services. A mobile phone tuple
may represent the ability to call, send SMS or leave a VM, depending on the
device status (on/off/call).

BTW, in one of my previous email I even suggested that such a device may be
treated as a service of its own.

> You might ask "what about email?". Well, that's a service. If 
> a device is going to publish presence info about another 
> device, then it's really publishing presence info about the 
> services on that device.
> 

I agree that email is a service and not a device.

> all services on that device?

This is one approach but it has limitations:
1. Change in a service will require sending ALL the device information again
2. It would be very complicated to parse and understand the hierarchy
3. It's very difficult to create child/sibling relationship, not to mention
inheritance.
4. How would you reference a specific service within the device (for example
for publishing purposes)

> Can a tuple, representing a service, carry presence info 
> about all devices enabled with that service?
> 

Same as above

> If not, then each device has to publish a separate tuple for 
> a service. It is the job of the compositor to combine those. 
> I fail to see how those can be combined per device.
> 

I agree and think that this is a very good solution to have a separate tuple
for each service and each device with references that save data duplication.

---

From: [email-masked]
Date: Wed, 2 Apr 2003 17:52:31 +0300

Brian,

Ok, I think I understand the problem you're referring to about forming a coherent picture of a user. I think part of (if not all) the problem is in the publishing side, namely multiple PUAs publishing the same "service".

In the publish work, the composer is assumed to reconcile these collisions, so that the watcher always has a coherent view. I believe the <label> element in RPIDS is meant to help the composer in determining when tuples from different PUAs are in collision.

If in fact this is the same problem, then in my opinion, we should make sure that the composer has enough tools to reconcile the collisions, and leave it at that. I think provided the composer has a way of aggregating multiple PUA input, having the tuples in a presence document be stand-alone elements, intended to be interpreted as such is a feature and not a bug.

Cheers,
Aki

 > Sent: 02 April, 2003 17:35
 > To: Niemi Aki (NMP/Helsinki); [email-masked];
 > > By device, do you mean that each one has a unique contact 
 > > address, some other unique identifier, or a specific device 
 > > type (phone, mobile, PDA)?
 > Yes
 > 
 > > 
 > > Also, can you elaborate a little bit on what the relationship 
 > > beyond belonging to the same presentity we need for those tuples?
 > It seems that some want to know either all the service on one device
 > or all the devices on one service.
 > 
 > > 
 > > Isn't it just as likely for a user to be a principal of 
 > > several presentities, each provided by a different service 
 > > provider? In that case the chances are no better or worse.
 > If we make PDIF/RPIDS straightforward enough, then a compositor
 > can aggregate, and a watcher can produce a coherent picture of
 > the user.  If we have a zillion different ways of representing
 > the information, then there is no such hope.  Right now,
 > without more definition and more linkages, I think there is no
 > way to do that.  I'm already worried about Jonathan's URI
 > per device (actually I think he wants URI per service per device)
 > and my single URI being tough to reconcile between implementations.  
 > This adds yet more ways to have implementations non-interoperable.  
 > Just the one multiple device per service vs. multiple services per 
 > device is enough confusion.  Both clearly will occur.  The question 
 > is how to represent it so the relationships are obvious.
 > 
 > Brian
 >

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 2 Apr 2003 15:27:36 -0500

I think the issue is that we have to have information in the tuples
that unambiguously allows us to understand the relationships between
them.  Just a label is not enough.

We know that they all refer to one user, or they would be in separate
documents

We need to know unambiguously, which tuples refer to the same device
We need to know unambiguously, which tuples refer to the same service

I don't think we have agreement on what a tuple is, let alone
how to encode device and service unambiguously within it.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 02, 2003 9:53 AM
> To: [email-masked]; [email-masked];
> Ok, I think I understand the problem you're referring to 
> about forming a coherent picture of a user. I think part of 
> (if not all) the problem is in the publishing side, namely 
> multiple PUAs publishing the same "service".
> 
> In the publish work, the composer is assumed to reconcile 
> these collisions, so that the watcher always has a coherent 
> view. I believe the <label> element in RPIDS is meant to help 
> the composer in determining when tuples from different PUAs 
> are in collision.
> 
> If in fact this is the same problem, then in my opinion, we 
> should make sure that the composer has enough tools to 
> reconcile the collisions, and leave it at that. I think 
> provided the composer has a way of aggregating multiple PUA 
> input, having the tuples in a presence document be 
> stand-alone elements, intended to be interpreted as such is a 
> feature and not a bug.
> 
> Cheers,
> Aki
>

---

From: [email-masked]
Date: Thu, 3 Apr 2003 10:36:57 +0300

-----Original Message-----
From: ext Cnaan Oded [mailto:[email-masked]]
Sent: Wednesday, April 02, 2003 5:51 PM
To: Khartabil Hisham (NMP/Helsinki); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Simple] Tuple references and device coupling

inline 
  
Oded Cnaan 

> must be a service running on it. 
A device with no service might be very meaningful as it still allows you to make decisions regarding how to communicate. Remember that devices (although not all devices, and these might not have a tuple) such as mobile phones are capable of communicating without running any services. A mobile phone tuple may represent the ability to call, send SMS or leave a VM, depending on the device status (on/off/call).
BTW, in one of my previous email I even suggested that such a device may be treated as a service of its own.

[Hisham] A mobile phone certainly has a service, its voice. If you have a device that allows you to make decisions regarding how to communicate, then this device is advertising available services on other devices and the tuples in publishes are tuples about services in other devices. A caller will never have to contact such device and a contact URI for that device is useless.

/Hisham

This is one approach but it has limitations: 
1. Change in a service will require sending ALL the device information again 
2. It would be very complicated to parse and understand the hierarchy 
3. It's very difficult to create child/sibling relationship, not to mention inheritance. 
4. How would you reference a specific service within the device (for example for publishing purposes) 
Same as above 
> I fail to see how those can be combined per device. 
I agree and think that this is a very good solution to have a separate tuple for each service and each device with references that save data duplication.

---

From: Cnaan Oded <[email-masked]>
Date: Thu, 3 Apr 2003 10:42:57 +0300

inline
 
Oded Cnaan

> Sent: Thursday, April 03, 2003 1:09 AM
> To: Rosen, Brian
> Cc: [email-masked]'; Cnaan Oded; Sean Olson; Jonathan 
> Rosenberg; Simple WG
> I think you _can_ make this interoperable without too much difficulty.
> Say your (that is, Brian's) service returns a single tuple, with a
> single contact URI. That tuple is valid for IM (among other 
> things.). 
> If I want to IM you, I send an IM to the contact in the tuple. Presumably
> your SIP routing mesh takes care of getting it to the right place.
> 

If the same URI is used for different purposes as you indicated, how would
the underlying SIP routing know whether the INVITE I am sending is for PTT
or IM? The only difference would be in the message body. Different services
need to use different URIs as long they don't reply on a special SIP method
that can be routed to a specific service (e.g., IM for MESSAGE).

>  Jonathan's service returns a bunch of IM tuples, each one with a
> different URI. Lets further assume, for the sake of example, that each
> of these URIs represents a device contact for some device of 
> his. I can
> send an IM directly to that device without going through a proxy.
> 

You are describing a scenario where either a user has more than one IM
client active at the same time from the same service OR these IM clients
belong to different services (e.g., Yahoo and MSN).

In the first case, I would expect the URIs to be the same for all IM tuples
as they represent the same presentity. The IM server would need to route the
message to the right device according to the recipient's preferences (or
presence). 

To continue this example, let's say that you have 2 devices running the same
IM service (can be any other service as well). The first device is a desktop
client and the second is a mobile phone. The user is driving his car so that
his location (detected by the PS) changes. If you use a single tuple to
describe the IM service, how would you correlate the location (of 2 devices)
to the service? You would need to - somehow - specify within the single
tuple that the location of one of the devices has changed.

If you use multiple tuples, the first tuple would reference the phone tuple
(and by that associate its location to the IM client) and the second would
show the static desktop client (although not necessarily as a desktop client
might not be interesting for itself).

In the second case, there should be different tuples as these are different
services.

> Now, lets assume _my_ watcher simply expects one _or_more_ tuples for
> IM. It doesn't have any idea whether a given tuple represents a single
> device, or a SIP proxy, or whatever. The only important thing 
> is it can
> assume that for an open IM tuple, it has a high chance of 
> being able to
> get an IM to the target user by sending it to the contact URI. It
> _could_ present multiple choices to me, or it could simply 
> tell me that
> both Brian and Jonathan are available via IM, and automatically choose
> the best tuple to use. If there is only one such tuple, that choice is
> trivial. If there is a bunch of tuples, then it can pick the best one
> based on some sense of "most present", explicit priority 
> values, or some
> local policy applied to the RPIDS attributes.
> 
> So, here I think I am proposing that a tuple represents a set of
> availability and communication type attributes 
> _associated_with_a_URI_.
> Whether that URI represents a service, or a device, or whatever is not
> relevant to the watcher.

---

From: [email-masked]
Date: Thu, 3 Apr 2003 11:38:01 +0300

Oded, can you please switch to text, thanks.

Comments inline...

-----Original Message-----
From: ext Cnaan Oded [mailto:[email-masked]]
Sent: Thursday, April 03, 2003 11:13 AM
To: Khartabil Hisham (NMP/Helsinki); [email-masked]; [email-masked]
Cc: [email-masked]; Niemi Aki (NMP/Helsinki); [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Simple] Tuple references and device coupling

> Sent: Thursday, April 03, 2003 10:48 AM 
> To: [email-masked]; [email-masked] 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 
> A tuple represents a service (communcation medium), the 
> contact address represents the device where that service is 
> running. How does that sound? If I choose not to include a 
> contact, then I'm just publishing that I'm available for that service. 
> 
> A copositor will have to combine tuples representing the same 
> service (medium) that don't have contact addresses and 
> possibly remove them completely if there is a tuple with a contact. 
> 
How would you represent an email service? It has no device but does have a contact address? 

[Hisham] Well, the contact address can certainly be an IM address, email or an Address of Record of some sort. I was suggesting if people want to explicitly point to service on a certain device, they can put the device address in the contact. The tuple still represents a service (communication medium).

I extend my suggestion above to say that a compositor and combine tuples if the contact address in common among them.

/Hisham

---

From: [email-masked]
Date: Fri, 4 Apr 2003 10:36:10 +0300

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, April 04, 2003 6:58 AM
> To: Jonathan Rosenberg
> Cc: Sean Olson; Ben Campbell; Rosen, Brian; Niemi Aki (NMP/Helsinki);
> [email-masked]; Simple WG
> Subject: Re: [Simple] Tuple references and device coupling
> 
> 
> To deal with that situation I think you must depart from use 
> of the AOR 
> for all contacts. You must now provide a device specific 
> contact in the 
> relevant tuples. Once that is done, a compositor can merge 
> tuples from 
> different sources that have the same contact address.
> 

Do you mean merge into a single tuple? Is it possible to do that?

If I have a device that supports voice+video, voice, but not video alone. How do I represent that? And in how many tuples? If a device tuple contains information about supported mediums in that device, you are making the assumption that any combination of those is possible.

Also, we are also forgetting about the CLOSED tuples. If I want to publish that IM on any device of mine is CLOSED, then with the assumption that a tuple represents a device, I have to publish a tuple from every device indicating IM is closed. If a tuple can represent an IM service (from any device), then I only need to publish one tuple.

Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Apr 2003 07:49:02 -0500

> What meaningful distinction can you make between contact address and 
> device?
> 
> An email contact is no different than a voicemail contact.
> 
> If I publish that I am willing to accept communication at 
> some address, 
> that is all you need to know. How I actually receive that is 
> my business.
> 
> As far as I am concerned, "contact addres" == "device".
I publish an AoR with a "voice/video/im" characteristics, however
encoded.  I actually have 25 devices.  You call me.  I'll look
at what media you are trying to comminicate with me, and who you
are, and route your call to the appropriate device.

One contact address = multiple devices. 

While I think it's not the right way to go, you can have a one-to-one 
relationship, but you can't define it that way.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Apr 2003 08:18:00 -0500

> *IF* I choose to portray my presence through a single address 
> (my AOR), 
> then I would also use only a single tuple. I see no value in 
> partitioning the capabilities of the virtual device 
> represented by my AOR.
> 
> However this gives a distorted picture. It implies that I can 
> concurrently provide all the capabilities in a single call, which is 
> likely not true.
Why are you assuming that one AoR in a tuple represents what happens 
on one call?  If I publish an AoR representing a videophone, 
can you not call it with an audio-only phone and get it to work?

The AoR is an address.  All of the information that has ever been
proposed for a tuple could not possibly tell you what combination
of capabilities advertised for a tuple could be accommodated in
one call.  You have to look at SDP to figure that out.  

> 
> Splitting up the capabilities among separate tuples each 
> representing a 
> single medium also gives a distorted view that I can't do 
> more than one 
> of those things in a single call.
I even wonder about this, although my first assumption is that
it would be the case.

> 
> If I want to give an accurate picture, I provide a separate tuple for 
> each device, showing what capabilities it has.
I don't think presence can or should provide this level of information.
Even if, for example, you knew that a single device could do voice+video
unless you essentially reproduce SDP, you can't tell what the 
capabilities of the device is for simultaneous use.  

For example, I could have two devices, one a desktop video phone,
the other a PDA type device.  Without SDP, you can't tell 
which device you would prefer to use for a videoconference with
me unless you knew codecs, image size etc.

Of course, using my view, there is only one contact, you call me
with an offer SDP, and you will find that I answer it on the "best"
device given what you are trying to do, who you are, and what I'm
doing.

.....

> 
> With a precise enough set of callerprefs in the call you are 
> right that 
> the caller can pick what they want and the callee can route 
> to the best 
> device. But in practice I am unlikely to find a device that 
> will encode 
> arbitrary callerprefs, and if I could find one I wouldn't 
> want to use it.
Well, I'll agree that the current callerprefs isn't precise enough,
but then again, nothing short of SDP is precise enough.  In particular,
there is no reason the "richness" of callerprefs is not at least
as good as the "richness" of RPIDS.  To whatever extent RPIDS
provides a way to describe the capability of an AoR, caller prefs
should describe the "offer" (as it were) of the caller.

Actually, I'd like the semantics to be identical where they overlap
Actually, I'd really like the SYNTAX to be identical.

> 
> The closest I might come is a device that always encodes a preference 
> for every feature it is capable of exercising - e.g. voice+video+IM, 
> regardless of what I as the user of the device happen to want when 
> making a particular call. That in turn may make a suboptimal 
> choice if I 
> don't care about everything right now.
Can you help me parse this paragraph?  "encoding a preference" and
"user of the device" seem to be opposite sides of the coin.
If the device is represented in the presence document, then the
user is the presentity, not the caller.

> 
> But if I can look at my buddylist and see that you are available at a 
> voice device and at a voice+video+im device, then it is a 
> simple matter 
> of which I pick to get you in the manner that suits me right now.
Sure, but it's much easier if your buddylist shows that I'm available
for voice video and/or IM at one AoR, and my end figures out where
to send the call.

Really, the only reason for you to choose is when you feel that you
have to override my choice.  If you are a telemarketer, then
that may be your intention, but I doubt we want to make that the 
design center. 

The only other circumstance is when you have multiple service providers,
and you don't have a proxy that can make the kind of intelligent routing
choices I'm talking about.  That's the environment we actually have
in many cases now, which is really why I think we need to allow
lots of tuples.  

Brian