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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 21 Jan 2003 19:32:48 -0500

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.

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.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 2:08 PM
> To: 'Peterson, Jon'; 'Vijay K. Gurbani'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: dnd (was RE: [Simple] Extending <status> for presence)
> 
> 
> 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 
> 
> > -----Original Message-----
> > From: Peterson, Jon [mailto:[email-masked]]
> > Sent: Tuesday, January 21, 2003 4:53 PM
> > To: 'Vijay K. Gurbani'; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: dnd (was RE: [Simple] Extending <status> for presence)
> > 
> > 
> > 
> > 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
> > 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Jan 2003 21:16:37 -0500

> turn down the bed, as it were.

In the draft that I'm finishing up, I use the same principle as in 
caller preferences: provide a hint what kind of communication is 
currently welcome (routine, urgent, emergency). I suspect that this 
works reasonably well in practice with people you know, as most people 
would be embarrassed to call you with a trivial problem if you have 
indicated "emergency only". DND is always a hint; it requires judgement 
since the disturbing party needs to gauge how important the interruption 
is. Except for truly life-threatening cases, this is not easily encoded 
in software. (For example, most people would ignore the DND sign on your 
door even if it was just a fire drill.)

> protocol should support a capability to show different presence to different

To amplify: There are at least three uses for presence information:
- for publishing, which then turns into all kinds of notifications (the 
example you gave);
- for direct notifications (the common assumption);
- and for generating call policy, e.g., a CPL script.

> "Busy" in any way other than through the <note> element, as qualifiers for a

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
- 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)".
- simplifies the UI - much easier to have a pull-down menu than typing 
this each time.

This does *not* mean that we have to enumerate all facets of human 
activity. iCal doesn't, either.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Jan 2003 02:37:16 -0500

inline.

> protocol should support a capability to show different presence to different

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.

Later on, Adam Roach writes:
> 
> 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).
> 

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.

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

---

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

Jonathan,

What do you expect tech support (customer service) to say to the individual 
that calls in and complains that he set DND on his phone and it still rang 
and rang during his power lunch with the CEO?

I think there are already well defined semantics associated with phones 
that work today and don't need to be messed with.  That is not to say that 
you can't define other similar type language to describe what you are 
trying to do.

My main question is this:  Should the semantics of DND in presence 
applications be consistent with the DND of the phone application?  I really 
think the semantics of DND should be one, and not mean something different 
depending on who you talk to.  This is supposed to be convergence, not 
divergence.

If you mean that calls will be "screened for emergencies" then say 
that.  If you use CLOSED with DND versus OPEN with DND, then the DND 
indication is really superfluous and can be omitted.

Mike

At 02:37 AM 1/22/2003 -0500, Jonathan Rosenberg wrote:
>contacted, but communciations attempts from those people will succeed if tried.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Jan 2003 16:57:56 -0500

Michael Hammer wrote:
 > Jonathan,
 >
 > What do you expect tech support (customer service) to say to the
 > individual that calls in and complains that he set DND on his phone
 > and it still rang and rang during his power lunch with the CEO?

Its not our job at IETF to tell operators how to build useful and
intuitive network services. It is our job to develop the protocol
mechanisms that make it possible to do so. It is certainly possible for 
someone to build a call filtering application that looks at DND. It is 
NOT ietfs job to mandate that an operator do so.

 >
 > I think there are already well defined semantics associated with
 > phones that work today and don't need to be messed with.  That is not
 > to say that you can't define other similar type language to describe
 > what you are trying to do.
 >
 > applications be consistent with the DND of the phone application?  I
 >  really think the semantics of DND should be one, and not mean
 > something different depending on who you talk to.  This is supposed
 > to be convergence, not divergence.

The semantics need to be clear, in terms of the user intent. I do not
think we can, or should, standardize the application behaviors that
ought to occur when they see that a user is DND or busy or on vacation.
There are MANY applications that can be built which look at presence.
Shall we specify the full set of applications and how all of them must
operate? I should hope not.

 >  indication is really superfluous and can be omitted.

My point was CLOSED with DND has different semantics from OPEN with DND.
Since the two are orthogonal, it seems like a good thing to have both.

Henning writes:
 > Again, 'dnd' and 'on vacation' are used only in two ways by
 > automatons:
 >
 > (1) If your CPL-generator subscribes to your presence, it may
 > translate "on vacation" to a set of filters and rules that implement
 > the behavior you describe.
 >
 > (2) There may be some rule-based mechanism in your presence agent
 > that translates your PUBLISHed 'dnd' to a set of OPEN and CLOSED
 > indications for particular subscribers.

Only two ways? I can think of lots of ways that automatons use these 
things in addition to the two above:

  1. rendering of icons in a buddy list application
  2. speaking of the presence state in a voice app
  3. creation of an appropriate voicemail greeting for callers
  4. automated conferencing applications which call everyone when their 
status is something that indicates now is a good time

-Jonathan R.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 23 Jan 2003 11:12:44 -0500

Jonathan,

At 04:57 PM 1/22/2003 -0500, Jonathan Rosenberg wrote:
>The semantics need to be clear, in terms of the user intent.

That is what I am attempting to do.  When you add a new meaning to a 
well-known term you create ambiguity.  That does not help clarity.

I am not trying to specify implementation, just as you are not by choosing 
to use such a name.  I am only trying to avoid confusing the developers 
that eventually will have to use this stuff.

Mike