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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Jan 2003 13:54:51 -0500

> > I actually don't think this particular example is great, but I do
> > think that there is a use for "On Vacation" vs. "Out of Office".
> > Here, I would forward (at least some) calls to a cellphone for
> > the latter, but not the former.  Fine grained presence state is
> > very useful.
> 
> I think this is a case where you don't really want "on vacation" or 
> "out-of-office" per se, but some kind of more general purpose status 
> with semantics that imply preferences for one type of communications 
> device over another.
I don't think so.  The presentity sets his state by what he is actually
doing.  The systems around him react to that appropriately.
I don't want to have a caller know what is happening (although he
might care, the note would work to tell him what to expect when he
places a call), but I want my system to decide if it should ring
my desk, my cell or my home phone depending on who is calling and
what my presence state is.

It's up to me (the presentity) to decide if I will in fact forward
a call from you to my cellphone if I am "out of office", and in
fact, if it's my wife calling, I will forward the call to my mobile
even if I'm "On Vacation".  So, presence state of "On Vacation" is
what my local incoming proxy needs.  I make it a watcher, and 

> 
> That leads to an interesting issue. Right now, statuses are always 
> associated with a tuple. Here, I think we are talking about a status 
> element that is truly applicable to the presentity, and not 
> any one of 
> their devices. You can't have presentity-level statuses in PIDF. We 
> could designate a tuple as a "presentity tuple", I suppose, but you'd 
> need some way to convay this fact (perhaps a pres contact address).
Yeah, but I think this gets complicated fast, and I'm okay with having
to set presence for both IM and voice/video independently; I can
automate that at the presentity UI.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jan 2003 15:56:57 -0500

> doing.  The systems around him react to that appropriately.

This is one approach. But not the only one.

When I publish that I am "on vacation", I leave it up to the presence 
client to decide if it is ok to call or not. I might prefer not to share 
that kind of info with the public, but instead simply say whether I am 
answering the phone or not.

> what my presence state is.

The behavior you describe here doesn't require presence at all. This is 
what callerprefs plus CPL are for.

Presence permits the caller to take over some of this. It is exactly why 
we are trying to get all the callerprefs info into presence.

It is interesting to consider a proxy that makes routing decisions based 
on presence rather than a location service and callerprefs. I firmly 
believe that this is what would happen if we were starting over with sip 
- we would use this instead of registration. But given where we are 
today, I don't think that presence will replace registration any time soon.

> what my local incoming proxy needs.  I make it a watcher, and 

Surely you can do as you wish. But it is probably unwise to act in ways 
inconsistent with the presence information you publish. It will simply 
confuse things. And if you do it enough, your buddies will cease to 
trust your presence.

	Paul