Subject: dnd (was RE: [Simple] Extending <status> for presence)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 21 Jan 2003 16:52:41 -0500

I think in Mr. Gurbani's argument below I see some requirements for our
forthcoming presence extensions, and some unrelated requirements for
UA/proxy behavior that is integrated with the setting of particular presence
states. 

It is clear that inspecting a PIDF document is not the only way to learn
someone's contact information, and that not everyone who has your contact
information will subscribe to your presence. People may attempt to initiate
telephone sessions with my SIP AoR regardless of whether or not I am
publishing a 'DND' presence, or even if my state is just 'CLOSED'. In that
sense, publishing 'DND' alone is not enough, and integrating this
publication with appropriate proxy server and UA behavior (rejecting calls
as needed, etc) seems like a logical next step. However, I don't see how
this requirement affects the work at hand - the question of how we structure
PIDF documents for SIMPLE.

Personally, I have a hard time seeing why I would want to publish 'DND' as a
presence instead of 'CLOSED'. I agree with Mr. Khartabil that presence
should be customizable for various watchers - the requirements of RFC2779
are very friendly to selectively revealing your 'true' presence. If I want
some set of preferred watchers to be able to contact me, I should show them
a state of 'OPEN', and show everyone else a state of 'CLOSED'. 'DND' seems
to be a form of impolite blocking - I'm here but I don't want to talk to
you. Why would I ever want to send that instead of 'CLOSED', which
communicates that I am unreachable? I think it is very limiting to assume
that a presentity has one and only one true presence state that it reveals
to all watchers.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 8: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: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Jan 2003 17:08:26 -0500

The reason you want a rich sense of presence is because the
watcher needs the same vocabulary as the presentity to determine
whether to initiate communication.  If you set yourself to
DND, and I am your supervisor, I may act differently than if you
set your state to "Vacation".

It is not necessary for either end to have any automated behavior,
but they could.  What is necessary is that there is no loss of
information when coupling my presentity system to your watcher.

Check the prior exchange between Paul and I on why CLOSED is not
appropriate.  I am not CLOSED if I am in DND.  I may defer or
forward communications you send to me.  It is up to you to decide
if you will initiate communications if I am in DND.  It is up to
me to decide if I will accept a communication from you if I am in
DND.  It is necessary for me to communicate to you that I am in DND,
and not CLOSED.  That is why we need agreement on a range of
states other than Open/Closed.

Brian 

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 4:53 PM
> To: 'Vijay K. Gurbani'; [email-masked]
> Subject: dnd (was RE: [Simple] Extending <status> for presence)
> 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Jan 2003 21:29:11 -0600

Henning Schulzrinne [mailto:[email-masked]] writes:
> 
> Peterson, Jon wrote:
> >
> > So, I don't disagree that we need a more sophisticated range of
> > communications states than OPEN/CLOSED - I think we've 
> already made a lot of
> > progress towards that here. But if you merely want further 
> descriptive
> > powers ("Vacation"), that sounds like a job for <note>. I 
> am very wary of
> > proliferating standardized states like "On the phone" as 
> distinguished from
> > "Busy" in any way other than through the <note> element, as 
> qualifiers for a
> > broader presence state.
> 
> However, the use within calendaring systems (including large 
> commercial 
> ones like Yahoo calendar and the iCal spec) argue that this is indeed 
> useful for reasons which were mentioned before:
> 
> - allows some automated processing, including I18N 
> (translation) and icons

The ability to display translated statuses is admittedly
valuable in certain contexts. In fact, I think we need to
take this to its logical conclusion: when we're coming
up with these enumerated types, we should do a survey of
various cultures, to make sure that we don't miss the
English "At Tea" and Spanish "Siesta" and whatever variety
of other specific varients of "away" might exist in other
cultures around the world.

Or, we could just attempt to parameterize the sort of things
that characterize typical "away" statuses, and allow
applications and/or users to set them as appropriate. Then,
even if I don't understand what's in the freeform text field
(or don't have a good intuitive feel for when siesta starts
and ends), at least I can figure out what the nature of the
break is even if I don't know what it would be called in
English (assuming, that is, that there is even a cultural
equivalent).

> - allows easier translation into call handling logic; it's 
> much easier 
> to have a 'case foo' list than trying to pick this out of a 'note' 
> statement that will, by necessity, have other information, such as 
> "Lunch with clients (Mexican place around the corner)".

This is precisely why I proposed trying to come up with parameters
that make these situations unique. Instead of having a "case out_to_lunch",
you can have "if (time_to_return < 7200)" or similar. Otherwise,
your call processing logic might need to specifically bundle
"case out_to_lunch" with "case on_the_phone" and "case in_a_meeting"
and "case in_the_shower" and "case working_out" and "case at_the_doctor"
and "case picking_up_the_kids_from_school" and....

> - simplifies the UI - much easier to have a pull-down menu 
> than typing 
> this each time.

Certainly everyone here realizes that the decision about whether
this is an enumerated, machine-interpretable value versus whether
it is a plain-text string has *no* bearing on the interface, right?
Even if we choose not to enumerate a standard set of presences,
applications can still include "On the phone" in a dropdown box,
the selection of which would publish presence with appropriate
parameters (OPEN, interruptability=0.1, etc) and with a freeform
text field of "On the phone".

/a

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Jan 2003 08:15:30 -0500

I agree that we don't want DND to be equivalent to CLOSED.
I clearly agree we need more states besides OPEN and CLOSED

Let me motivate a need for "On the Phone" as opposed to "Busy"
Don't get too hung up on the tags, or whether there is a simple
list of states, or a multidimensioned state.  The fundamental
difference I want to point out is "On the Phone" is a state 
that my SIP UA can detect and report, while Busy is a state
a human decides.  

One of the experiences we have, over the past several months 
living with a multistate presence system, is that humans don't
remember to change their state.  We have running code with
states like "Available", "Busy", "Do Not Disturb", "Out of Office"
and "Back in 5 minutes".  We have presentity clients to pick a state
from a menu.  It's prominently displayed on the UI, and we
have watchers that display the state on contacts/speed dials.

Our experience is that Presence state is almost always wrong.  
We're just not used to keeping fine grained state current.
It's interesting because having the information is, in fact
very useful before you make a call.  What's even more interesting
is that even when you recognize that as a watcher, it's great,
it doesn't motivate you as a presentity to keep your presence
state accurate enough.

As a result, we are moving to automated state changes.  We'll
clearly have the manual state mechanism retained, but we need
to have the system automatically change state for you.  Activity
detectors are an obvious source of information.  "On the Phone" is
something we can detect.  "Busy" could imply a lot more than
"On the phone". 

It seems obvious to me that we do manage to keep our calendars
reasonably up to date.  Thus we can, in fact, determine the
difference between "Out of Office" and "On Vacation".  I would
like to be able to represent that.  While putting the difference
in a Note works for a human watcher, it doesn't work for 
providing automated forwarding based on presence; forwarding
behavior is much different for those two cases.

Brian

> Sent: Tuesday, January 21, 2003 7:33 PM
> To: 'Rosen, Brian'; 'Vijay K. Gurbani'; [email-masked]
> Subject: RE: dnd (was RE: [Simple] Extending <status> for presence)
> 
> 
> 
> I was trying to make a slightly subtler point - I'm not really arguing
> against the DND state, but against a particular semantic of 
> DND, one that
> seems essentially equivalent to CLOSED. If we necessarily 
> couple DND with
> rejection of unauthenticated communication attempts via IM or 
> voice or what
> have you, then we violate, I think, Mr. Kyzviat's 'fireman 
> principle' - that
> is, when we put a DND sign on a hotel door, we assume that we 
> would welcome
> an interruption when the building is burning down; but if it 
> is impossible
> to be disturbed when we're DND, then actually our state is really just
> CLOSED. This makes it really hard for me to see how I would 
> use DND. The
> fireman principle also could be accommodated, however, if 
> hotel emergency
> staff were simply given a different presence than the people 
> that come to
> turn down the bed, as it were.
> 
> From this thread, I have gotten the impression that many of 
> the arguments
> for DND are founded in the understanding that I have only one 
> presence that
> I show to every watcher in the world - so therefore I often 
> want a state
> that meanas "CLOSED with some exceptions". I was merely 
> reinforcing Mr.
> Khartabil's assertion that IMPP has other ways to attack this 
> problem, and
> probably better ones.  Referring to your previous example, if 
> you don't mind
> being disturbed by your wife, then don't send her DND - that is a much
> simpler approach than trying to figure out a semantic for DND that
> accomodates sending DND to watcher for whom you want to 
> appear reachable.
> You are in fact OPEN/available/whatever to those select 
> watchers, and the
> protocol should support a capability to show different 
> presence to different
> people.
> 
> progress towards that here. But if you merely want further descriptive
> powers ("Vacation"), that sounds like a job for <note>. I am 
> very wary of
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Tuesday, January 21, 2003 2:08 PM
> > To: 'Peterson, Jon'; 'Vijay K. Gurbani'; [email-masked]
> > Subject: RE: dnd (was RE: [Simple] Extending <status> for presence)
> > 
> > 
> > > > Vijay K. Gurbani  
> vkg@{lucent.com,research.bell-labs.com,acm.org}

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Jan 2003 15:24:03 -0000

To a large extent I concur with Jon.

I think it is extremely dangerous to identify something called "DND" and then try and fix semantics to it. This is because the term already carries the users expectations which are all substantiallt different.

My understanding, which may not be anyone elses, but derives from my enterprise network (PABX) background would be as follows:

1)	DND applies to the device. Putting DND on my phone does not stop people barging in the door. Putting a DND label on the office door does not stop the phone ringing.

2)	DND is no different to "The device is busy, please try later". The original implementation of the feature on enterprise networks returned exactly the same tone as "busy". The calling user saw no difference between the user actually using the device and the device being in a state of DND.

3)	DND is interruptable to anybody with the appropriate privileges. The managing director can be given a Class of Service that enables him to sucessfully ring anybody with a phone in DND.

It is likely to be unsafe to say these are the only version of the semantics that people think of with DND, and therefore whatever is defined, I would urge people not to use the term DND.

It may well be applicable to try and define something, at either the user or the device level, that indicates that it is worth trying later.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 22 January 2003 00:33

---

From: Michael Hammer <[email-masked]>
Date: Wed, 22 Jan 2003 10:48:20 -0500

Keith,

I agree with your comments and conclusion, with the following 
exception.  (My view comes more from a Centrex/Class environment, but I 
think it is consistent to PBX.)  The DND feature by itself would block all 
calls from ringing.  The barge-in that you describe is effectively a "DND 
Override" feature that cancels out the DND for that caller.  That is not 
the same as saying that DND lets some users through.  That is more of a 
call screening feature.

Anyway, I agree that not overloading the term DND with too many meanings is 
of value.

Mike

At 03:24 PM 1/22/2003 +0000, Drage, Keith (Keith) wrote:
>I think it is extremely dangerous to identify something called "DND" and 
>then try and fix semantics to it. This is because the term already carries 
>the users expectations which are all substantiallt different.
>
>My understanding, which may not be anyone elses, but derives from my 
>enterprise network (PABX) background would be as follows:
>
>1)      DND applies to the device. Putting DND on my phone does not stop 
>people barging in the door. Putting a DND label on the office door does 
>not stop the phone ringing.
>
>2)      DND is no different to "The device is busy, please try later". The 
>original implementation of the feature on enterprise networks returned 
>exactly the same tone as "busy". The calling user saw no difference 
>between the user actually using the device and the device being in a state 
>of DND.
>
>3)      DND is interruptable to anybody with the appropriate privileges. 
>The managing director can be given a Class of Service that enables him to 
>sucessfully ring anybody with a phone in DND.
>
>It is likely to be unsafe to say these are the only version of the 
>semantics that people think of with DND, and therefore whatever is 
>defined, I would urge people not to use the term DND.
>
>It may well be applicable to try and define something, at either the user 
>or the device level, that indicates that it is worth trying later.
>
>Keith
>
>Keith Drage
>Lucent Technologies
>Tel: +44 1793 776249
>Email: [email-masked]
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Jan 2003 10:55:46 -0500

I think we need to agree on a set of presence states that
are reasonably unambiguous with respect to their definitions of the
presentity's state as communicated from presentity to watcher.  
It is up to a given UA or proxy server that implements forwarding
based on information it obtains as a watcher to decide how to 
control calls when the presence state is, for example DND.
That is not subject to standardization.

Our system, for example, allows the user to create exactly the
definition of DND that you espouse, but does not limit her
to that definition.

Brian

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, January 22, 2003 10:24 AM
> To: Peterson, Jon; 'Rosen, Brian'; 'Vijay K. Gurbani';
> [email-masked]
> I think it is extremely dangerous to identify something 
> called "DND" and then try and fix semantics to it. This is 
> because the term already carries the users expectations which 
> are all substantiallt different.
> 
> My understanding, which may not be anyone elses, but derives 
> from my enterprise network (PABX) background would be as follows:
> 
> 1)	DND applies to the device. Putting DND on my phone does 
> not stop people barging in the door. Putting a DND label on 
> the office door does not stop the phone ringing.
> 
> 2)	DND is no different to "The device is busy, please try 
> later". The original implementation of the feature on 
> enterprise networks returned exactly the same tone as "busy". 
> The calling user saw no difference between the user actually 
> using the device and the device being in a state of DND.
> 
> 3)	DND is interruptable to anybody with the appropriate 
> privileges. The managing director can be given a Class of 
> Service that enables him to sucessfully ring anybody with a 
> phone in DND.
> 
> It is likely to be unsafe to say these are the only version 
> of the semantics that people think of with DND, and therefore 
> whatever is defined, I would urge people not to use the term DND.
> 
> It may well be applicable to try and define something, at 
> either the user or the device level, that indicates that it 
> is worth trying later.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: [email-masked] 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Jan 2003 17:22:18 -0500

> 
> Maybe you are already implying this, I am not sure.  But just to be
> concrete, I would think that there is some value to having [filter] be
> more than simple 1-to-1 state substitutions.  The PA can selectively
> advertise me as "Busy" to all watchers except my spouse who sees
> "Interruptible", for example.
> 
Yes, the filter can be dependent on watcher.
That behavior is only dependent on the implementation of the PA,
and thus is not a standardization issue.

For that matter, saying that [filter] is state for state substitution
is really also a single entity implementation issue.  The only thing
that we standardize is the states expressed across the boundaries.
In this case, I'm advocating that the states across the
Presentity to PA boundary be the same as the states across the
PA to Watcher boundary.

Brian

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 22 Jan 2003 19:46:23 -0500

inline.

Jon Peterson
NeuStar, Inc.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 11:37 PM
> To: Peterson, Jon
> Cc: 'Rosen, Brian'; 'Vijay K. Gurbani'; [email-masked];
> [email-masked]
> Subject: Re: dnd (was RE: [Simple] Extending <status> for presence)
> 
[snip]
> 
> Well, you aren't really OPEN to those select watchers, either. You are 
> telling them that you are really busy, and would prefer not to be 
> contacted, but communciations attempts from those people will succeed if 
> tried.
> 
> Again, I argue that this is really just a basic status of OPEN, combined 
> with a "what am i doing" status of "do not disturb", which is one of an 
> enumerated set of such things.
> 
> FOr those folks for whom I am DND and won't accept communications, the 
> combination of CLOSED and "do not disturb" would make sense.
> 

We're on the same page on all of the above. The key thing for me is that the
flavor text ("what I am doing") and the basic status are separable. It is a
slightly thornier issue how much flavor text needs to be standardized - it
is nice to be able to set away messages arbitrarily, and also nice for
automata to make decisions based on something other than basic status. I
basically agree with your statement below that finding a dozen or so
enumerated standardized statuses is probably the best approach.

> Later on, Adam Roach writes:
> > 
> I would be willing to consider such a thing, if you could propose a 
> concrete mechanism which is actually useful and usable. A duration 
> parameter hardly seems to cut it, given the issues raised multiple times 
> surrounding i8n, icons, and other things that people want to do.
> 

I think Adam's core concept here is sound, though I agree that it might be
difficult to agre on the set of operands we'd want to use.

> The essence of your argument is that, because we can't enumerate 
> EVERYTHING, we should enumerate NOTHING. I disagree. I think that, if we 
> scope it to a dozen or so statuses seen in existing systems today with a 
> few more for fun, we can have a very useful and interoperable list. 
> Indeed, we might decide to establish an IANA registry for said statuses, 
> to make it easier to add "in a siesta" down the road, if that is what we 
> need to have.
>
> -Jonathan R.
> -- 
> 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
>