Subject: [Ietf-calsify] possible VALARM solution?

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Sun Sep 5 20:47:25 2004

I think having a sender-defined suggested reminder is a reasonable
feature, though I do not find it all that compelling.  Assuming we agree
that the standard should address this particular feature, I just want to
point out that the UI could also decide not to bother the poor user who
might easily be importing ALL 27 of his team's recurring events for the
lifetime of the product cycle (since he is just joining the team, for
instance).  We must think about these features in terms of scale.

But then, this very reasonable ask has gotten us right back where we
were - all VALARMS that occur in the past *should* be suppressed
(right?) - or else we have the less-than-desirable Netscape
experience... and then again, if I'm in a different building (or a
different time zone), I will likely want to adjust my reminders to be
earlier anyway.  The context of the reminder is very client-centric.
And once again, I find the feature dubious.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, September 05, 2004 7:28 PM
To: [email-masked]
Subject: [Ietf-calsify] possible VALARM solution?

Here's an idea for simplification of the "VALARM problem".

The originator of a calendar object (meeting, to-do item, appointment)
may desire that someone be reminded of such an event, which I feel is a
valid option to have - if I schedule a staff meeting on a regular
schedule, far in advance, I might like to indicate that all employees be
reminded of it on that day. However, as many have pointed out, the
methods of notification should be part of the UI.  My proposal for
simplification, then, is that each component have a simple, binary
property, or a parameter of the component, which is a YES/NO value for
'remind the attendee/originator of this object'.  If that property is
set to YES, then the UI is responsible for asking the UI owner how they
want to be reminded about that object.

Comments?

Tim Hare
Interested Bystander, Non-Inc. 

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 6 11:46:36 2004

>And once again, I find the feature dubious.
I think that is a user preference. I may want to see what I forgot to go to
when I get back late from a meeting.

I would rather show up 5 minutes late to a meeting with a customer
than not at all just because I was not running the CUA at the exact
alarm trigger time.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040906/87abf4a6/smime.bin

---

From: TimHare at comcast.net ([email-masked])
Date: Mon Sep 6 19:09:48 2004

In response to both Cameron and Doug....

I don't see a case for PDAs to use CAP that much - they either seem to be 
their own Calendar Service (i.e. the user uses _only_ the PDA for 
calendaring), or they are an adjunct to the desktop CUA and the 
communication between PDA and desktop is more in the realm of SyncML. I 
could be wrong on this point, but that's how I see it.

Even if we _do_ want to use CAP, transporting VALARMS  is fraught with 
other problems - since a PDA and sometimes other CUAs can be implemented on 
different platforms from the CS, we have to add complexity so that one end 
of the conversation can indicate what it can/cannot do in relation to 
VALARMS ( "don't send me executables", "I can't make sounds", and the like).

So, while I don't necessarily think that transporting alarms is a good 
idea,   I think that transporting the need for an alarm is probably the 
best simplification we could come up with.

Tim Hare

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 7 10:27:05 2004

[email-masked] wrote:

> I don't see a case for PDAs to use CAP that much - 

That was one of the CAP requirements.

And even if PDA's do not use CAP, many still use VCALENDAR objects.
And transporting the alarms is done at this time.

> other problems - since a PDA and sometimes other CUAs can be 
> implemented on different platforms from the CS, we have to add 
> complexity so that one end of the conversation can indicate what it 
> can/cannot do in relation to VALARMS ( "don't send me executables", "I 
> can't make sounds", and the like). 

In the client/server model - you have to transport VALARMS with CAP, 
else you have no alarms.
CAP only transports VALARMS to be used by one or more CUAs. So if CAP did
not transport them, you could not have any in your own calendar.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040907/2666d067/smime.bin