Subject: RE: [Simple] RPIDS: Capabilities in tuples and Caller Prefs

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Feb 2003 11:44:17 -0500

I'm glad we got back to this, as I really want to get closure.
.... snip....
> I think the actual problem, if any, is with the client. It is 
> the server 
> that gets to decide which of these models it wishes to use. 
> The client 
> must accomodate.
> 
> For us it is not a problem - you only publish one tuple, so 
> to us it is 
> just a single virtual device.
Well, your client has to use caller preferences to influence
what happens to the call, if he wants to do that.  If we don't
make that work well, and clients won't implement it,
we won't have good interoperability.

> 
> I don't know if this is a problem to you or not. Clients need to be 
> prepared to present information about multiple tuples to their users, 
> and preferably provide the user with suitable courses of action on a 
> per-tuple basis. This is more work than if there is but a 
> single tuple. 
> But I can think of some concise and convenient GUI interfaces 
> for this
It would be interesting to do some useability studies on this.

> 
> > I'm not objecting to having a way to provide a device
> > address if the principal wishes to.  I'm trying to
> > figure out a way so that if the principal does NOT
> > wish to provide device addresses, or even enumerate
> > the devices he has, all watcher/UA implementations will 
> > work pretty well. 
> 
> Where is the problem?
Making the syntax of the (RPIDS) presence document and
the syntax of caller preferences match enough to make
influencing outcome obvious.  

Making the representation of data in one tuple rich enough
to express the state of a presentity instead of the state
of a device.

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Feb 2003 11:59:55 -0600

Rosen, Brian wrote:
[...]
> It would be interesting to do some useability studies on this.

We did something along these lines in early 2001.  There was an
internal Bell Labs project called TeamPortal [1] that did use-ability
studies and deployment on such a presence-based system.  The model
in TeamPortal was presentity-based with each presentity being
represented by a myriad of devices that a watcher could use to
initiate communication.  In the TeamPortal GUI, a set of icons to the
right of a presentity's icon represented each such device at the
presentity's disposal.  Each such device included information such as
the last used time and current status.

The presence status of the presentities was also tied into calendaring
systems and such.  The intent was to keep a globally disperesed team in
a cohesive collaboratory by providing presence and communication means
to other watchers in the collaboration.

[1] "Advanced Services: Changing how we communicate", R. Colbert,
D. Compton, R. Hackbarth, J. Herbsleb, L. Hoadley, and G. Willis,
Bell Labs Technical Journal, Volume 6, No 1, January-June 2001, pp
211-228.  (Email me if you cannot find the article online some-
where.  The authors of TeamPortal also generated some usage
statistics which are relevant for a collaboration-type of setup.)

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Feb 2003 18:09:52 -0500

> we won't have good interoperability.

The use of callerprefs is more optional in this case, because there is 
only one visible contact. If that happens to be an AOR for multiple 
devices, then presumably a call will be forked, and something will 
happen that is consistent with the expectations promised by the presence 
document.

Problems occur when there are multiple tuples in the document that 
repeat the same contact but describe different features. This is when 
callerprefs (or something else) are required to ensure that a call 
directed to the contact with expectation of the features promised in 
that tuple.

In your case there are some ambiguities that could be resolved via 
callerprefs. For instance suppose you have one phone for business calls 
and another for personal calls, both registered to your AOR. Using your 
approach, the compositor would have to decide how to represent the 
combined status of the AOR. Publishing this as a single tuple is a bit 
deceiving, because you presumably report the equivalent of 
class="business,personal". A client might read this and think it can 
call without specifying any preferences and reach something suitable for 
either or both. But in fact that isn't what calling without specifying a 
preference means in this case. You have broken the appearance that this 
is one device.

I suppose we could try to add some guidelines indicating that a caller 
should explicitly request all the offered preferences that are actually 
desired. But you *know* it won't happen, because it is too hard. 
Instead, people are simply going to click on an icon corresponding to 
the contact, and a call will be made. There won't be any easy way to 
cause the preferences to be added in this case.

> to express the state of a presentity instead of the state

I think by the time you have achieved that, you will have simply ened up 
exposing the existence of the individual devices in a more obscure way.

It is a caller feature to be able to pick among the tuples and get a 
device with the corresponding features, without having to explicitly 
request each feature.

	Paul