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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Jan 2003 15:19:51 -0500

I have a problem with attaching too much significance to DND.
DND is one point on a spectrum from Available to On Vacation.
(Hmmm, maybe we could have "deceased" or "No longer employed here")
The difference between DND and Out to Lunch is pretty small -
if you try communicating with me, you are not likely to get me.
All of these states are how unavailable I am.  

We've struggled a bit here with that, because we find people
often don't manually change their presence state to maintain
validity.  We had particular problems with "Back in 5 minutes"
or variations on that.

Once you are past "Available", the differences reduce to:
	how your system will respond, which for us depends on
		who you are.  This is not a standardization issue.
	what time expectation callers (IM'ers?) have for when
		you will be available.  This is also not
		a standardization issue, except that we are
		going to agree on a reasonable set of tags

I worry about making everything past "Available" some version of
"Closed".  It's that step that gets us into the dilemma of 
"closed for voice, open for IM".  It also precludes my local
system from saving an IM sent for later review, or forwarding
a call to voicemail.

To me, presence is guidance to the caller, and state for my
local devices to use when requests for calls arrive.  I don't
want it to be state for remote devices, or at least, I want
to encourage a lot of user interaction at the caller.
If my spouse sees I'm in DND, and calls anyway, I want that
call to go through.  My stock broker may not get that behavior.
I don't want my wife's IM client to prevent her from sending me
a message if I'm in DND.  

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 11:34 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Extending <status> for presence
> 
> 
> [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
> > 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.
> 
> 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
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jan 2003 15:49:13 -0500

Brian,

You haven't spoken for awhile. Good to hear from somebody else again.

I think there may still be some different expectations implied in your 
response than what my expectations are. Lets try to clarify.

inline...

	Paul

> All of these states are how unavailable I am.  

I agree with you on this. At least as far as *presence status* is 
concerned these are pretty similar to me. I think the difference is 
expectations about the behavior of the receiving device when DND status 
has been set. I think many people believe the act of setting state to 
DND not only affects the presence state, but also changes the device 
behavior so it responds with an error rather than alerting.

I am inclined to agree that UAs might do this, but consider it out of 
scope when defining PIDF extensions.

> validity.  We had particular problems with "Back in 5 minutes"

Yeah. "Back in 5 minutes" is really bad. "Back at <now+5minutes>" is 
better, because at least clients know when the status is bogus.

A smart UA would manage this. When the expected return time passes, it 
would change the status to "Expected back momentarily" or simply 
"unavailable".

> system from saving an IM sent for later review, or forwarding

Yes, we need more than CLOSED for "not Available".

That is why I have explicitly tried to find ways to encode things like: 
available for IM now, available for voice & IM eventually.

This is also why I have tried to provide for operational status like 
active/inactive vs declarative status like available/unavailable/...

> local devices to use when requests for calls arrive. 

Here we differ. I don't see presence as a guide for my devices. Rather I 
see my local devices as responsible for setting my presence status.

 > I don't

I want user interaction if that is what the user wants. But I also think 
automated decisions about when to call, or what device to call, are an 
important feature of presence. It should be possible to build a proxy 
that directs calls to devices based on presence, rather than based on a 
registry and location service.

> I don't want my wife's IM client to prevent her from sending me

I think I agree with you on this. I don't think your wife's IM client 
should prohibit her from sending, but it might try to discourage it, and 
make her go through some override action. Obviously the details are 
application issues.

	Paul