Subject: RE: [Simple] Timed presence

From: "Tim Rang" <[email-masked]>
Date: Mon, 6 Jun 2005 12:32:20 -0700

I disagree.  I see very few practical applications of future presence,
and calendar info is one of them.  As Paul stated, it's difficult to
provide a reasonable estimate of when a presence transition will occur
in general.  The most reliable way to do so is to predict based on
previously scheduled activities, meetings, out of office time, etc, all
of which are generally captured in a person's calendar.

I'd stop short of calling for calendar synchronization, but it seems to
me to be one of the primary sources of future presence.

Tim Rang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Monday, June 06, 2005 7:57 AM
To: Paul Kyzivat
Cc: Simple WG
Subject: Re: [Simple] Timed presence

>
> There is also the slippery slope here to including full calendaring  
> info in presence, which IMO is more than we want.
>

I agree we don't want to use this draft as a calendar synchronization  
protocol.

>
>>> (3) The highest-level solution is to have a timed-presence, as in
>>>
>>> <presence>
>>>   <tuple>
>>>     existing tuple information
>>>   </tuple>
>>>
>>>   <timed-presence from=... until=...>
>>>     <tuple> </tuple>
>>>     <person> </person>
>>>     <device> </device>
>>>   </timed-presence>
>>>
>>> </presence>
>>>
>>> This avoids having multiple activities with different time  
>>> ranges, for example, within <person>.
>>>
>
> While I can see some merit in this from the perspective of the  
> watcher, I don't see how one would ever get the information to  
> create this. How would the publishers of bits and pieces of  
> presence info use this?
>
> My original reason for being interested in this was to cover the  
> following scenario:
>
> - I have a multimedia device. (Say voice, video, IM.)
> - When I am not on a call, I am normally open with capabilities for
>   all three media. (one tuple)
> - when I am on a call, that may diminish my availability for
>   another call. Details are policy, but lets assume I can only
>   take one voice and/or video call at a time, but can take up to
>   5 IM calls at a time.
> - I express my diminished availability by changing by current
>   presence status. So when on a voice call I say I am still open,
>   but only for IM. (Also indicating "on the phone".)
> - My expectation is that when the call is over I will go back to
>   being available for all media.
> - a watcher that sees my status when I am on the phone can see
>   that I am available for IM, but has no way to know that I
>   also have voice and video capability, just not right now.
>
> So I wanted to use the old future-status to indicate that in the  
> future I would be available for voice,video, and IM.
>
> The problem with this, of course, is that my phone, which is  
> probably the one publishing presence, can't generally estimate when  
> I wll be off the phone. So for this to work I would need a future- 
> status/timed-status that doesn't say *when* in the future it will  
> be true.
>
> Perhaps this is a problem that should be solved in some other way,  
> but I had hoped that timed-status could be the solution. Its just a  
> little more extreme case of the times in timed-status being  
> predictions rather than truths. It could in fact be handled by  
> setting the start time to the current time, on the assumption that  
> the current call could end at any time.
>

I'm not sure this is a good fit. The model you're describing is more  
of a "idle" presence, i.e., you'll never have more media than a set,  
but may have less if you are using one or more of those resources.

I suspect that in practice, you'll get something akin to the "5  
minute" convention, i.e., "I'm on another call right now, talk to me  
in 5 minutes" or the "minute convention" ("I'll be with you in a  
minute"). There is no assumption that this is actually going to be  
precisely 300 seconds or 60 seconds.

See also http://www.worldwidewords.org/qa/qa-new1.htm

_______________________________________________
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: Mon, 6 Jun 2005 15:43:01 -0400

I don't think we're disagreeing :-)

I think we both agree that calendars are the primary source of this  
type of information.

When I said calendar synchronization protocol, I meant a protocol  
that would allow two iCal instances to stay in sync, e.g., to sync a  
PDA and Outlook. I don't think timed presence can (or should) do that  
job.