Subject: [Ietf-calsify] VALARM

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Sat Aug 21 09:31:01 2004

Skipped content of type multipart/alternative

---

From: Doug at royer.com (Doug Royer)
Date: Sat Aug 21 13:19:49 2004

Cameron Stillion wrote:

>I would like to suggest the removal of ALARM from the iCal spec.
> 
>
I disagree.

>I have yet to hear or come up with a good scenario that includes sending
>alarm information from one client to another.  Applications that have
>implemented this end up with features that are annoying and useless.
>Case in point : Mozilla imports a calendar and all of the valarms inside
>of it.  Many of them (all that are in the past) immediately go off after
>import.  The rest of the events are set to cause an alarm.  The user has
>not implied that they want to attend any of these events, but is already
>being bothered about it.
> 
>
Many do implement VALARMS correctly. In addition VALARMs are the
only way for one vendors CUA to set an alarm in another venders CS. I can't
think of how it could be done without VALARMs.

>Sending REQUEST calendars that include valarms makes little sense as
>well.  you may accept my meeting, but it's up to you when you want to be
>notified about its pending approach.  You might need to travel further
>than anyone else I send it to, so the valarm information is inherently
>specific to the client.
>

I would agree that we should specify when you should and should not 
include them.

> 
>While the alarm information is useful to store and to use for a client
>application, it seems pointless to transport.
>
It needs to be transported from the CS to and from the CUA.

> 
>Can anyone express a scenario where sending a valarm from one client to
>another makes sense?
>  
>
Client to client  - no.
Client to and from server - yes.
The ability to mix vendor A CUA with vendor B CS  and use/test/get 
alarms - yes.

-- 

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/20040821/6bb0250f/smime.bin

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Sun Aug 29 19:47:13 2004

Cameron Stillion wrote:

> I would like to suggest the removal of VALARM from the iCal spec.
>  
> alarm information from one client to another.

Cameron,

Here's a good scenario:

1- I'm invited to a meeting.

2- I synchronize my SyncML device.

3- Since the calendar server knows that I want reminders
    with a 10 minutes lead time, the VEVENT uploaded to
    my SyncML device will contain a VALARM specifying an
    alarm 10 minutes prior the VEVENT start time.

Don't ask me for a good scenario in the context of iTIP.
In my opinion, VALARM should not be used in the context
of iTIP. If you receive an iTIP message with a VALARM
just ignore it.

Cheers,
Bernard

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Mon Aug 30 08:26:49 2004

It's starting to sound to me like the transport format should be a 
*subset* of the interactive access format.  Is that a useful thing to 
consider in simplifying the documents?  -- Nathaniel

On Aug 29, 2004, at 10:47 PM, Bernard Desruisseaux wrote:

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