Subject: Re: Alarms - was RE: Question on calstore current time.

From: [email-masked]
Date: Thu, 20 Dec 2001 12:23:45 -0500

Shannon asked on 12/19/2001 04:51:22 PM:
> First - how do vendors CURRENTLY handle alarms - i.e. can the vendors 
here
> each speak up and explain how they handle it today... 

For every vendor here Im sure you'll get a slightly different answer. 
Basically it falls into 2 categories: some use 'server push' models and 
some use 'client pull' models.  Notes uses the latter scheme so that it 
can present "missed alarms" to the user the next time they log in 
("Mobile" or "Disconnected" users access an 'internal' server in the 
client).

No matter what route you take, every method has its strengths and 
weaknesses (otherwise there would be just "the" accepted way to implement 
it).  I suspect that in order to get a "client pull" CS to work with a 
"server push" CUA that some negotiation between the two is going to be 
necessary and the same for the converse rolls.

> Second - fundamentally what are the REQUIREMENTS around alarms? 
[Snip, snip]
>       do they belong in CAP at all?

I think CAP MUST address it.  As an access protocol for C&S, it must 
provide some way for a user to access their alarms as well as the actual 
entries. 

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 20 Dec 2001 12:31:35 -0600

Bruce,

Thanks - I guess what I am getting at when I ask whether CAP must address
alarms is asking whether alarms are fundamental (i.e. a requirement) for
interoperating calendar systems - or whether they are a characteristic of
Calendar USER agents - i.e. since so far the examples appear to be specific
to ONE user - are they something that must be a part of the core calendaring
specs? Or could they be considered a very optional component and something
that is specific to the vendor(s) involved in a given application?

Perhaps though there should be a standard way to separate off and store this
vendor specific information - so I could see an argument for some data
structure - just wondering how much or how little is really required.

I am struggling a bit to see a clear reason alarms are a standardized
element - i.e. they seem to be very specific in nature to a given vendor's
application - unless we are suggesting that there be two elements to an
alarm - one "when it should happen" - and a second, specific to a given
application, of "what" should then happen????

Shannon
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]
  Sent: Thursday, December 20, 2001 11:24 AM
  To: Shannon J. Clark
  Cc: [email-masked]
  Subject: Re: Alarms - was RE: Question on calstore current time.

here

  For every vendor here Im sure you'll get a slightly different answer.
Basically it falls into 2 categories: some use 'server push' models and some
use 'client pull' models.  Notes uses the latter scheme so that it can
present "missed alarms" to the user the next time they log in ("Mobile" or
"Disconnected" users access an 'internal' server in the client).

  [Snip, snip]

  Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Dec 2001 12:06:42 -0700

> "Shannon J. Clark" wrote:
> 
> Bruce,
> 
> Thanks - I guess what I am getting at when I ask whether CAP must
> address alarms is asking whether alarms are fundamental (i.e. a
> requirement) for interoperating calendar systems - or whether they are
> a characteristic of Calendar USER agents - i.e. since so far the
> examples appear to be specific to ONE user - are they something that
> must be a part of the core calendaring specs? Or could they be
> considered a very optional component and something that is specific to
> the vendor(s) involved in a given application?

They already are - see rfc2445

> Perhaps though there should be a standard way to separate off and
> store this vendor specific information - so I could see an argument
> for some data structure - just wondering how much or how little is
> really required.

This debate took place over years - lets not deprecate rfc2445.

> element - i.e. they seem to be very specific in nature to a given
> vendor's application - unless we are suggesting that there be two
> elements to an alarm - one "when it should happen" - and a second,
> specific to a given application, of "what" should then happen????

I just posted what I think will resolve the user preferences
to VALARM issues.

The reality is that they exists. We need to debate how to
deal with them. 

-Doug