Subject: [Simple] Timed presence

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 05 Jun 2005 09:17:32 -0400

Timed status allows to indicate that presence information is valid at a 
time either in the future or the past. The current draft

http://www.cs.columbia.edu/sip/draft/timed-status/draft-ietf-simple-future-03.html

defines a new "wrapper" that allows to include any other presence 
information with a validity time range. Unfortunately, this is somewhat 
less than elegant: For example, rich presence (RPID) also has timing 
information (since/until) for many elements. The mechanism predates the 
data model work and there hasn't been a whole lot of discussion on how 
to make the two play nice with each other.

Based on where PIDF can be extended, there appear to be three possible 
approaches:

(1) One simple mechanism is to avoid use of timed-status for all new 
presence elements that are defined in RPID and elsewhere and only define 
a very narrowly scoped timed basic status that addresses that problem 
that PIDF doesn't have this information. In other words,

<timed-status from="" until="">
   <basic>open</basic>
</timed-status>

All other elements, where applicable, would just use the since/until 
notation. This also works for PIDF-LO, since it currently extends 
<status> in PIDF.

(2) Another solution, bumping up one level, is to associate time with 
<person>, <device> and to create a <timed-tuple>.

(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>.

My current inclination is to do (3), but I can see merits in all three 
approaches.

I'd like to conclude this draft as soon as possible, so I'd appreciate 
feedback.

Henning

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Jun 2005 23:28:51 -0400

Henning Schulzrinne wrote:

> information (since/until) for many elements.

Right, but thats not a new problem, nor has the data model work changed 
that. I believe that our reconciliation of these two was that 
timed-status ONLY dealt with predictive presence information; that is, 
information that describes the future. The since and until stuff used 
within other attributes defines current status, such that the since and 
until range has to encapsulate the current time.

> My current inclination is to do (3), but I can see merits in all three 

There is a third, which is to extend the way timed-status currently 
works (whtin a tuple) to also work within a person or device:

<presence>
   <tuple>
     <timed-status>
       future-stuff
     </timed-status>
   </tuple>

   <person>
     <timed-status>
        future stuff
     </timed-status>
   </person>
</presence>

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2005 10:05:40 -0400

Jonathan Rosenberg wrote:
>> Timed status allows to indicate that presence information is valid at 
>> a time either in the future or the past. The current draft
>>
>> information with a validity time range. Unfortunately, this is 
>> somewhat less than elegant: For example, rich presence (RPID) also has 
>> timing information (since/until) for many elements.
> 
> 

The current status, and 'since' information are both (hopefully) 
describing known facts.

The timed-status when talking about the future, and 'until' are both 
predictions. Both suffer from the possibility of being incorrect.

While I think it has been said that you shouldn't publish a timed-status 
with a range encompassing the current time, after it is published the 
current time can catch up with it. That has always been of some concern 
to me. But I guess it could simply be viewed as status of questionable 
accuracy that can be used in absence of something better.

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

>> presence elements that are defined in RPID and elsewhere and only 
>> define a very narrowly scoped timed basic status that addresses that 
>> problem that PIDF doesn't have this information. In other words,
>>

Maybe.

>> <person>, <device> and to create a <timed-tuple>.

I think this would just confuse things.

>> 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.

> works (whtin a tuple) to also work within a person or device:

I generally agree with that. I also wonder if perhaps we ought to 
deprecate use of 'until' in regular status when the until value is a 
prediction rather than a certainty.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Jun 2005 10:57:26 -0400

>
> 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.

>>> 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?
>
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2005 11:41:48 -0400

Henning Schulzrinne wrote:
>>>> This avoids having multiple activities with different time  ranges, 
>>>> for example, within <person>.
>>>>
>>
>> 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?
>>
>> 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.
>>
> 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.

If its not a good fit, do you have a suggestion for something that is a 
better fit?

I think timed-status is a reasonable fit precisely because the future 
times are generally just estimates anyway and shouldn't be taken too 
literally.

An alternative I floated once (which didn't seem to get traction) was to 
permit prescaps both directly below <tuple> and <device> and also below 
<status>. The value in status would be the "current" value while the one 
higher up would be the "default" value.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 6 Jun 2005 12:28:29 -0400

>
> If its not a good fit, do you have a suggestion for something that  
> is a better fit?
>
> I think timed-status is a reasonable fit precisely because the  
> future times are generally just estimates anyway and shouldn't be  
> taken too literally.
>

I agree - while the fit isn't perfect, it's the closest we have and  
there doesn't seem to be much point in defining a separate,  
overlapping mechanism.

> An alternative I floated once (which didn't seem to get traction)  
> was to permit prescaps both directly below <tuple> and <device> and  
> also below <status>. The value in status would be the "current"  
> value while the one higher up would be the "default" value.
>

The hard part is defining what "default" means and what a user would  
do with this without any time indication. At least, with the timed- 
status, for some cases, such as scheduled calls, you can provide a  
pretty good estimate. Even for your phone call case, since the  
likelihood that calls exceed 10 minutes is small, providing a ten- 
minute estimate seems good enough. Presumably, after 10 minutes,  
you'd look again and check if the status has changed. Teenagers could  
presumably increase that interval.

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 7 Jun 2005 10:49:47 +0200

On Jun 6, 2005, at 4:05 PM, Paul Kyzivat wrote:

>>> Timed status allows to indicate that presence information is valid  
>>> at a time either in the future or the past. The current draft
>>>
>>> somewhat less than elegant: For example, rich presence (RPID) also  
>>> has timing information (since/until) for many elements.
>> Right, but thats not a new problem, nor has the data model work  
>> changed that. I believe that our reconciliation of these two was that  
>> timed-status ONLY dealt with predictive presence information; that  
>> is, information that describes the future. The since and until stuff  
>> used within other attributes defines current status, such that the  
>> since and until range has to encapsulate the current time.
>
> While I think it has been said that you shouldn't publish a  
> timed-status with a range encompassing the current time, after it is  
> published the current time can catch up with it. That has always been  
> of some concern to me. But I guess it could simply be viewed as status  
> of questionable accuracy that can be used in absence of something  
> better.
>
This is where composition policy would kick in. A compositor may simply  
throw this out if the time has arrived. or?

Hisham

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Jun 2005 05:55:06 -0400

> This is where composition policy would kick in. A compositor may  
> simply throw this out if the time has arrived. or?
>

Depends. If the NOTIFY arrives at 3.30 pm and the future time is 4  
pm, the compositor would have to realize at 4 pm that it needs to  
update the status even though nothing else might have changed (no  
additional PUBLISH have arrived). My mental model of a compositor was  
reactive, i.e., it would never create new event notifications, just  
create one when a new external (PUBLISH) event triggered this.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jun 2005 08:07:29 -0400

Henning Schulzrinne wrote:
> Depends. If the NOTIFY arrives at 3.30 pm and the future time is 4  pm, 
> the compositor would have to realize at 4 pm that it needs to  update 
> the status even though nothing else might have changed (no  additional 
> PUBLISH have arrived). My mental model of a compositor was  reactive, 
> i.e., it would never create new event notifications, just  create one 
> when a new external (PUBLISH) event triggered this.

My mental model is that composition can be done by either the presence 
server or the watcher, or both. When it is done by the presence server 
it can embody policy decisions specified by the presentity. It may be 
necessary for the presence server to do it to obscure detail that it 
doesn't want to disclose. Otherwise the choice of where it is done is 
merely a matter of convenience and optimization.

In this case, at 4pm it may be necessary to reconsider what status to 
display. This reconsideration can be done by the watcher if the raw 
status was made available to it. If the composer in the presence server 
had hidden this than it may need to do the reconsideration.

But, if the current status had been "on the phone" and closed, while the 
future status is available and open, then at 4pm I would be inclined to 
consider the status to remain the same.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Jun 2005 01:58:06 -0400

> My mental model is that composition can be done by either the  
> presence server or the watcher, or both. When it is done by the  
> presence server it can embody policy decisions specified by the  
> presentity. It may be necessary for the presence server to do it to  
> obscure detail that it doesn't want to disclose. Otherwise the  
> choice of where it is done is merely a matter of convenience and  
> optimization.

For me, composition implies the creation of a new presence document.  
Clearly, the watcher needs to decide what information to display and  
may decide to drop information it considers unreliable or outdated,  
but I'm not sure whether calling this composition helps. In any  
event, I don't think this makes much of a difference for the case at  
hand.

>
> In this case, at 4pm it may be necessary to reconsider what status  
> to display. This reconsideration can be done by the watcher if the  
> raw status was made available to it. If the composer in the  
> presence server had hidden this than it may need to do the  
> reconsideration.
>

I would rather not have the PA be expected to do this. This greatly  
complicates implementations. Since the watcher can already do this,  
there seems little gain by extending the expected PA behavior that  
way. Clearly, nothing we say prevents a PA from creating new presence  
documents any time it sees fit, but I wouldn't want to make this part  
of the common composition policy, for example.

> But, if the current status had been "on the phone" and closed,  
> while the future status is available and open, then at 4pm I would  
> be inclined to consider the status to remain the same.
>
>     Paul
>