Subject: RE: [Simple] Extending <status> for presence

From: [email-masked]
Date: Tue, 21 Jan 2003 09:43:10 +0200

I would like to throw in one more:

A lot of discussion in this thread was about tying the device behaviour with the presence state. If device is CLOSED, then it will not ring. So, I wanted to bring in authorisation policies and polite blocking into the formula.

If a watcher gets false information due to a policy indicating so. Does the device need to know NOT to ring for that person or group that the presentity is lying to?

I might show out-to-lunch for someone who I don't want to talk to right now, my show available to my good friends. How is the device controlled in this case?

I guess the real question is: Can the device be controlled by presence state? or it like just like Paul's example; you hang a do-not-disturb sign on the door and hope for the best?

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, January 20, 2003 11:22 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Simple] Extending <status> for presence
> 
> 
> This seems like a good capture of much of what is being 
> discussed. It is
> definitely hard to follow these threads since we are covering a lot of
> really different topics all interspersed.
> 
> In addition to what you have below, there has also been a bunch of
> discussion on DND, and how that relates. Also, much discussion on the
> need for hierarchies of tuples and what they represent.
> 
> Really, our first task in SIMPLE here is to scope this work. 
> Hopefully,
> some of that will result from distilling concepts into uses of a small
> set of status types. Others we will simply need to declare 
> out of scope
> for now.
> 
> A few comments on selected points:
> 
> ON AVAILABILITY
> 
> I'd like to first comment on this available status you 
> discuss. I don't
> see how it is different from the basic OPEN/CLOSED status. I 
> also don't
> see how the probability helps. Paul had given an example use case:
> 
>  > I want to use presence for routing calls to agents in a 
> call center.
>  > In the case of voice calls, availability in this case is 
> binary - an
>  > agent on the phone isn't available for another call. But it isn't
>  > necesarily so when the 'calls' are for IM sessions. A call center
>  > agent can usually handle more than one IM session at a time. But I
>  > would like to be able to distinguish between two otherwise equal
>  > agents when one is already in an IM session and another is not. In
>  > some sense the one that is already in an IM session may be 
> viewed as
>  > less available for another session.
> 
> To me, this is not really a probability, so much as an expression that
> availability is conditional on some other characteristics of the call.
> It is this kind of need which motivated my proposal to 
> support "virtual
> devices". The primary purpose of those virtual devices would be to
> represent (using the callerprefs attributes) the conditions 
> to which the
> OPEN/CLOSED status would apply.
> 
> ON ACTIVITY
> 
> I'd next like to comment on what you call "activity". I think 
> there is a
> need for some type of standardization to support this 
> concept. There are
> several different ways in which the concept can be quantified:
> 
>    * the amount of TIME since the presentity last interacted 
> with the device
>    * the physical DISTANCE of the presentity from the device
>    * the PROBABILITY that a communications request to the 
> device will be
> answered by the presentity
> 
> I think existing IM systems very much rely on the TIME definition.
> However, in my experience that definition is heavily tied to 
> the concept
> of a PC application. On a cell phone, where the user normally does not
> interact with the device continously, this tends to a poor definition.
> For cell phones, the DISTANCE is a better measure, but even 
> that is not
> neccesarily a good one. The phone may be near me, but its tucked away
> into a laptop bag and so I really am idle with respect to it, since I
> can't hear it or reach it.
> 
> Arguably, one approach is to separate the means for measuring 
> "activity"
> or "idleness" from its representation. Using something like a
> probability, for example, would allow the metric to work 
> across devices,
> and for it to be measured differently for different devices.
> 
> Another issue to be factored into the decision about how to represent
> idleness is how frequently it needs to be reported to the watcher in
> order to be useful. A time-based measure has the nice benefit that the
> watcher can continously know how long the presentity has been idle,
> simply by conveying the time of last activity in the presence 
> notifications.
> 
> One final point on activity. Some have stated that the defining
> characteristic of this status is that it is implicitly computed by the
> system. I disagree. I think it may be perfectly valid to set 
> it explicitly.
> 
> ON DND
> 
> DND has received a bit of discussion on this thread. To be 
> honest, I am
> at a loss as to why it is not really a combination of two things: (1)
> basic status of CLOSED for each device, and (2) a "task" of "do not
> disturb". Paul has defined these tasks as things that 
> describe what the
> presentity is doing, such as "out-to-lunch". "do not disturb" 
> seems like
> another example.
> 
> It is the usage of the basic status of CLOSED that really captures the
> essence of DND - that attempts to contact with that user across their
> devices will fail.
> 
> ON STORE_AND_FORWARD
> 
> Paul has proposed that store-and-forward (what he calls autoresposne)
> become a special status type for a device. An alternative is 
> to use the
> caller prefs attribute for this (formerly voicemail, now called
> msg-server). THis is not quite the same thing. The 
> voicemail/msg-server
> attribute says "this device IS a voicemail server", and not "if you
> contact this device, and no one answers, the call will go to 
> voicemail".
> The latter is an expression of application logic running in a proyx
> which cannot be concretely known by the device itself. Thus, its not
> appropriate IMHO as something to represent in caller prefs. 
> It may very
> well be useful to represent in PIDF, since it is the type of 
> thing that
> a PA might know, as it has a broader view of the presentity across all
> devices.
> 
> Indeed, "auto-response" is just an expression of an 
> application that is
> running on calls to that device. THere are other applications running
> that might be of interest. Lets say I have a cell phone and a home
> phone. I am running CFNA on my home phone, to my cell phone. 
> Perhaps we
> might like to express in PIDF that this will happen. Supporting such
> things would argue for representing "voicemail" as another device, and
> then defining extensions that indicate that call forwarding 
> logic occurs
> from one device to another. Such a capability in PIDF would 
> capture both
> the autoresponder semantic and inter-device forwarding rules.
> 
> What about other applications, such as voice recorders or 
> call blocking
> applicatoins? DO we need to signal those too? As a matter of 
> scope, I am
> inclined to treat this whole set (including auto-responder) as out of
> scope for this first cut.
> 
> ON HIERARCHIES
> 
> I have proposed that another axis of extension for PIDF is to allow
> hierarchies of tuples. This is a superst of the concept Vijay 
> G has been
> advocating, of defining a special type of tuple to represent a person.
> 
> On this point, Paul K wrote:
>  > I also looked at 2778 to clarify my thinking. A presentity need not
>  > represent a person. A single presentity could represent a 
> group. So I
>  >  would be inclined to say that an address like
>  > sip:[email-masked] (or
>  > pres:[email-masked]) should be viewed that 
> way. Such a
>  > presentity may have many devices, and each may have independent
>  > status - some OPEN, some CLOSED, some AWAY, some DND.
> 
> Ultimately the group presentity is represented through 
> multiple devices,
> but those devices each "belong" to other, different presentities. The
> value in the hierarchy is being able to express the relationships
> between these things. I think its valuable to be able to subscribe to
> pres:[email-masked], and for notifications to be capable
> of indicating any of the following:
> 
>     * customer support is available now for calls and IM, here is the
> cotnact address.
>     * customer support is available, and is made up of bob, judy and
> bill. Here are the contact addresses for bob, judy and bill 
> as presentities
>     * customer support is available, is made of up of bob, 
> judy and bill.
> Bob has a cell phone and IM device. He is available on the IM device,
> but not the cell phone.
> 
> A "group" presentity differs from a "user" presentity in that it can
> have "user" presentity sub-tuples, and that certain status types apply
> to it alone. For example, I would like to have a "percentage OPEN"
> status, which indicates the percentage of the members of the 
> group which
> are available right now. That definition makes sense for a group, but
> not a single user presentity.
> 
>  > I'm not sure if you are suggesting an extension that literally
>  > permits tuples to be nested within tuples, or some sort of tagging
>  > and referencing notation that defines graphs between the tuples. I
>  > guess either is technically possible within the scope of 
> the existing
>  > PIDF definition.
> 
> I had in mind literal nesting, as this is natural for XML. Of course 
> either would work. Its a detail. It is far more important to 
> determine 
> if hierarchical tuples are a useful concept, and if we wish to pursue 
> them now or later.
> 
> -Jonathan R.
> 
> 
> Paul Kyzivat wrote:
>  > OK, after thinking about this I have a proposal that covers many of
>  > the issues that have emerged. It is influenced by many things, most
>  > recently Henning's comments in his "Stepping Back" note. (And Vijay
>  > *has* succeeded in convincing me that there are *some* status
>  > attributes that aren't associated with any device.)
>  >
>  > I see the following categories of status attributes:
>  >
>  > * Device specific status - belongs only in a <tuple> that also
>  > contains a <contact> element:
>  >
>  > - a <prescaps> element as defined in
>  > draft-lonnfors-simple-prescaps-ext-00, or equivalent. This 
> includes,
>  > among other things, an indication of what media are 
> available at the
>  > device to be used right now.
>  >
>  > - an element (<activity>?) indicating activity of the presentity in
>  > proximity with the device. (active/inactive). This is 
> intended as an
>  > automated hint of likelihood that presentity is attending to the
>  > device.
>  >
>  > - an element (<availability>?) indicating explict availability and
>  > willingness of the presentity to communicate using this device
>  > (available/unavailable). (Perhaps this should be a probability -
>  > number between 0-1.)
>  >
>  > - an element (<autoresponse>) indicating ability of device 
> to handle
>  > communication requests in the absence of the presentity.
>  > (available/unavailable). (This is voicemail for voice.)
>  >
>  > * Status that can go in any tuple:
>  >
>  > - elements indicating current tasks the presentity is 
> involved with,
>  > and/or general willingness to communicate. Chosen from an 
> enumeration
>  >  (TBD). (This covers "out to lunch", "on vacation",  "Do Not
>  > Disturb", "On the Phone", etc. These do not imply any particular
>  > behavior - that is indicated via device specific status.
>  >
>  > - geoloc information (TBD)
>  >
>  > - an element (<future-status>?) specifying expected future status.
>  > This contains an optional timestamp indicating when it will take
>  > effect. It also contains other status elements. (If it contains
>  > device specific status it must go into a device specific tuple.)
>  >
>  > The <future-status> element handles a number of things. If you are
>  > Out to Lunch and unavailable right now, it can specify that at 1:00
>  > you will be available. If you are "On the Phone" now, and 
> so are not
>  > indicating support for voice, it can indicate that you will be
>  > available for voice later, though you can't say when. And 
> if you are
>  > going to be leaving the office at 7:00, it can indicate 
> that then you
>  >  will be unavailable.
>  >
>  > There is some overlap between the <autoresponse> element and the
>  > voicemail callerpref. But callerprefs currently can't 
> specify that a
>  > single device may handle calls directly or via voicemail. It may be
>  > better to fix this in callerprefs and then import that via
>  > <prescaps>.
>  >
>  > Paul
>  >
>  > _______________________________________________ Simple mailing list
>  > [email-masked] https://www1.ietf.org/mailman/listinfo/simple
>  >
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 21 Jan 2003 10:33:34 -0600

[email-masked] wrote:
> I guess the real question is: Can the device be controlled by presence 
> state? or it like just like Paul's example; you hang a do-not-disturb 
> sign on the door and hope for the best?

I believe that a person should have the option of controlling *their*
own device through *their* presence state.  That is, if I actively set
my presence/availability state to DND, I would like the following
sequence of events to happen:

    1) My status is set to DND and all watchers are informed.  The
       presentities associated with the watchers see a big "DND"
       status next to my icon on their UA.
    2) My presence document is updated so that all my interactive devices
       are CLOSED.
    3) Either a message is sent to all my interactive devices to stop
       accepting sessions (currently not possible), or a script is
       uploaded to my proxy server redirecting all communication sessions
       to a recorder (definitely possible).

Arguably, the reason we cannot do (3) currently is that we cannot
control each device we own -- we cannot stop the PSTN phone from
ringing (short of plugging it out of the wall), nor can we stop the
cell phone from paging me (again, short of powering it down).  I
believe it is this behavior that is leading us down the path of
equating DND with "hanging DND on the door and hoping for the best".

In a network where all the devices we own are far more controllable, we
can do better.  I think the power of the simple WG is the use of SIP
as a unifying protocol -- SIP drives all communication aspects.  Other
IM/P systems like Yahoo! or Jabber do not aim to tie all communication
aspects under one protocol.  Thus IM is done using native protocols,
while phone calls are completed using (probably non-SIP) gateways to the
PSTN.  This leads to cases where the status of the presentity itself
is at odds with the status of its devices (i.e. status of presentity is
DND but it still answers the PSTN phone).

DND has received a lot of air-time, and Jonathan wrote:
> ON DND
> 
> DND has received a bit of discussion on this thread. To be honest, I am
> disturb". Paul has defined these tasks as things that describe what the
> presentity is doing, such as "out-to-lunch". "do not disturb" seems like
> another example.
> 

I don't think the representation of DND is what we are arguing; it is
the semantics.  DND implies to me that all *my* devices should honor
my will and not even alert me.  But of course, there maybe cases where
the department secretary or the CEO should be able to get to me.  Given
today's disparate networks, I cannot impose my will on my devices.  But
should we preclude us from doing so for tomorrow's networks where it
maybe more possible to control the device in a far more discrete manner?

Thanks,

- 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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 16:18:23 -0500

Vijay K. Gurbani wrote:

> my will and not even alert me. 

Here is our fundamental disconnect.

I view this as one application's interpretation of DND. DND merely means 
  "I dont want to be disturbed". If you have a proxy app that subscribes 
to your presence, and it creates a CPL that blocks all calls when your 
presence is DND, thats great. It can do that. That is how that 
presence-based application works. Others might do different things. I do 
not want to mandate the way that applications have to operate under 
certain presence states. That path is full of perils, not the least of 
which is that networks differ frome each other in many ways, so that 
applications will need to be built in different ways. You have already 
stumbled on this above, in the case of uncontrollable PSTN devices.

  But of course, there maybe cases where
> maybe more possible to control the device in a far more discrete manner?

We should ENABLE such applications to be built. We should not mandate 
HOW they are built.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Jan 2003 10:11:19 -0500

Fundamentally, this is a discussion about the role of events and 
presence. In my view, presence and events indicate what is ("status"), 
not what should be ("control").

As has been discussed here, some other presentity-controlled entity may 
close the feedback loop and translate "is" into "does". (No, I don't 
want to discuss the meaning of the word "is".)

Trying to implement such restrictions on the watcher side is also 
fundamentally pointless since it relies on the cooperation of the 
watcher software.