Subject: RE: Question on calstore current time.

From: "John Stracke" <[email-masked]>
Date: Wed, 12 Dec 2001 13:57:59 -0500

>Are VALARMS required to specify time in a TIMEZONE or UTC format?

Uh...<dig, dig>...no; they're relative to an event, and an event can be in 
floating time.

But wait a minute--VALARMs don't go off on the server, do they? A VALARM 
going off is a UI thing; it should be the CUA's responsibility.  <dig, 
dig>...the CAP draft says nothing about server-side VALARMs.

(You might want a server to send email at a particular time--say, to send 
a reminder to your cellphone--but that would have to be a separate server, 
using CAP to get its data.)

And, if there were such a thing as server-side VALARMs, it would still be 
inappropriate to use the server's default timezone for floating events; 
you'd use the CU's TZID property.

/============================================================\
|John Stracke                   |Principal Engineer          |
[email-masked]  |Incentive Systems, Inc.     |
|http://www.incentivesystems.com|My opinions are my own.     |
|============================================================|
|If all the world's a stage, I want to operate the trap door.|
\============================================================/

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 12 Dec 2001 15:25:29 -0500

Hi,

>...But wait a minute--VALARMs don't go off on the server, do they? A VALARM

The behavior that results from a VALARM is not part of the protocol. I hope
that implementors will develop servers that can generate events based on
VALARMS. I may not always have my CUA running, but I can probably be reached
in a variety of other ways, for example by pager, phone, or an instant
messaging service.

Paul

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Dec 2001 15:53:24 -0700

> dig>...the CAP draft says nothing about server-side VALARMs.

This is another point I wanted to raise.
Why not? Perhaps we need a way to say what the CUA expects?

 	(a) CS Always processes VALARMs.

	(b) CS Only processes VALARMs when the CUA is not connected.

	(c) CS Never processes VALARMs.

	(d) CS Only process the tagged VALARMs.

	(e) CS Only process the tagged VALARMs when the CUA is not
	    connected.

	(f) CS Only processes specific types of VALARMs (email only
	    for example).

	(g) CS Only processes specific types of VALARMs when the
	    CUA is not connected.
	...

BIG BIG interoperability issues!!!

	What if the CS Can't process any VALARMs:

		As in - you don't own the server and it does not
		do those things for you. (Unless we make it 
		a MUST and that won't fly).

	What if the CUA can't process some kinds of VALARMs:

		My Non-Net Palm Pilot can't send an email when it
	 	is in my bag at 30,000 feet - what if that email
	 	goes to my co-workers - that's why I put the
	 	information in a VALARM). 

	What if multiple CUA are connected and we agree
	that the CUA send the VALARMs?

	Do they all send the same email, process the procedure,
	... (assume they are all the calendar owner). 

> using CAP to get its data.)

Did we specify that - nope? Do we need to - yep.
MUST it be the CUA - not sure.

> you'd use the CU's TZID property.

Or Calendars TZID property - only if no TZ attached to the object
			     and it is not in UTC.

Or the objects TZID property - yep - if it has one - else the calendars.

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Dec 2001 15:55:32 -0700

"Paul B. Hill" wrote:

> The behavior that results from a VALARM is not part of the protocol.
> I hope that implementors will develop servers that can generate
> events based on VALARMS. I may not always have my CUA running,
> but I can probably be reached in a variety of other ways,
> for example by pager, phone, or an instant messaging service.

I agree.

We need to write down the rules or you are going to get
two or more VALARMs or none depending on the implementations.