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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 3 Apr 2003 10:51:26 -0500

>> 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).
My service would use a single URI and would prefer to see Caller
Preferences used to handle the multiple media, but would in any case
choose the "best" device based on caller preferences and/or SDP.
Now, to be sure, I'm talking about a contact address that starts out
with sip:.  If it starts out with im: then we don't need to work so hard.
If I had both a sip: and an im: in one presence document, they have to
be separate tuples.  This is not what I consider a good idea, but I can live
with it. My view is that the state of a user is pretty uniform,
and the kinds of services I will accept communication on is one aspect
of the presentity (that is, essentially all of the RPIDS attributes
refer to the user, and not to the many devices he may have).  The fact
that we humans have multiple devices each of which has a separate
address that we hand out to our correspondents is an accident of
the incremental nature of the advance in technology.  If we could start
over, I doubt we would do it that way.  Wait a minute, we ARE starting
over, we CAN do it differently.  Gee, that's my point - have ONE
address ([email-masked]), one presence
(pres:[email-masked]),
and have a list of "services" (voice, video, IM, email) you can use to
contact pres:[email-masked].

The present organization turns this around.  It has multiple addresses,
each of which repeats presence data on the same user.

Now, that's just redundant data, so I can ignore it, and those that want
to stick with having device addresses can be happy.
 
>>  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). 
Right, this is Jonathan's example, and he would have more than one
tuple, and more than one URI to reach the devices.

>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. 
Well, caller preferences could be used to specify which client if you
have multiple clients in the one uri, multiple client case.
I would of course say that the fact that I have multiple clients
is not important to you - I tell you my presence (in a car, but
available for IM).  If you send me IM, I'll get it on my mobile.
You don't really care about the fact that my office client is
not available; you know I'm traveling, I'm willing to take IM.  If you
send me IM, I'll get it.  Working hard to find out that if you send
IM to my office no one will pay attention is not very interesting.

> 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. 
The only point of having multiple tuples is to present a set of options
to the user so that he can decide what to do.  If the only interesting
result was an automatic "pick the best one" then it's the called party
that is in the best position to make that determination.  Those that
want multiple tuples want to present all that information to the
watcher user.  I don't know why, but that's the reason for multiple
tuples.  "Local Policy" doesn't make a lot of sense to me, please cite
an example.
> 
> 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. 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 03 Apr 2003 12:27:57 -0600

On Thu, 2003-04-03 at 09:51, Rosen, Brian wrote:
[...]
> tuples.  "Local Policy" doesn't make a lot of sense to me, please cite

Sure--I could have a local policy that says to only use voice as a last
resort. So if any tuple exists for IM, I will use it, even if a voice
tuple has a higher priority in the presence doc. And of course, the most
trivial local policy is the one you mention--let my user decide.

Sure, you can say that I can do the same thing with caller prefs. I
agree completely. My point was not to defend one architectural decision
over the other in the current one-true-tuple vs many-tuple controversy.
My point was to say that, _if_ we can define the way a watcher
interprets tuples so that the two architetures can interoperate, there
is no need for SIMPLE to choose one over the other.

And I think we _can_ do that, if we follow something like the tuple
definition I mentioned earlier, as quoted below.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2003 22:43:55 -0500

> contact pres:[email-masked].

I agree with part of this as *one* way I *might* choose to portray my 
presence.

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

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.

If I want to give an accurate picture, I provide a separate tuple for 
each device, showing what capabilities it has.

> tuples.  "Local Policy" doesn't make a lot of sense to me, please cite

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.

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.

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.

	Paul