Subject: [Ietf-calsify] possible VALARM solution?

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Sep 7 06:37:15 2004

Let's walk through the rest of your scenario...

If you mean, importing an entire list of shared events (a published
calendar of customer meetings) into your own calendar, or accepting a
meeting request for that customer meeting.  

The meeting request is more personal, and arguably SHOULD turn on an
alarm, but using the client's defaults - not the senders.  

The published calendar is more to the point.  Firing lots of past event
alarms will not help you make the meeting, it will only cause noise that
you will likely dismiss inadvertently to avoid the potentially many
other pointless alarms.  Even so, this is a very small edge case of
importing these events *just* as the event is starting.  Your CUA could
realistically be smart enough to fire alarms for events that are also in
process.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, September 06, 2004 11:46 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] possible VALARM solution?

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

---

From: TimHare at comcast.net ([email-masked])
Date: Tue Sep 7 07:38:40 2004

It would be desirable for the UI of a CUA to ask you, at import/open time, 
whether you want to:

         1. Ignore alarms entirely - don't set them.
         2. Import the alarms using client defaults
         3. Ask the user what kind of alarm to set, for each one imported

UIs of course, are outside of the scope of the simplification work - but 
the above 3 choices would work whether we retain the transmission of 
VALARMs, or we simplify by having a REMINDER=YES/NO parameter/property.

I've left out option 4,  Import the alarms exacly as the server sent them. 
That can only work if there is enough other complexity to determine if the 
client is a compatible platform, so it doesn't work with our goal of 
simplification.

At 09:37 AM 9/7/04, you wrote:
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 7 10:43:16 2004

>realistically be smart enough to fire alarms for events that are also in
That is an implementation detail - not a protocol issue or an object issue.

The purpose of iCAL is to define how to transport calendar objects.
Clearly VALARM is one of the successful objects being transported
at this time.

I can see a usage document for interpersonal calendaring describing
how/when/if a VALARM should be transported. However VALARM
is clearly compatible with many implementations at this time. So I do
not think that it is in scope to consider eliminating them entirely. And
if you can not transport them, that is the same effect.

I could PUBLISH a project calendar, with the alarms sending email
to the team members with the VEVENTS and VTODO and any VALARMs
being updated by the team leader. So again I can see a document
listing the pro's and con's of when to send VALARMs.

-- 

-------------- 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/bd8b1901/smime-0001.bin