RE: [Ietf-calsify] VALARM

I see your point.

I am a little surprised that UAs would choose to use iCal as a native
storage format, but I understand the desire not to disallow it by
design.  Also, now that you mention it, I can imagine a thin client
wanting to use caldav to access a user's data where the alarm
information would need to be there too.

Perhaps iMip can lend some weight here and if not disallow, then highly
discourage the transport of VALARMs for any purposes other than
backup/restore/etc. I would say that MIME transport is rarely used for
the purposes we've identified for actually using VALARMS.


cameron


-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Monday, August 23, 2004 4:52 AM
To: Cameron Stillion; [email protected]
Subject: Re: [Ietf-calsify] VALARM

Your idea makes the assumption that iCalendar is _only_ used for
exchange between two calendaring endpoints. Some UAs use iCalendar as
their "native" 
storage, I believe. That aside, the spec was certainly developed to
support that use and that is why VALARMs are in the spec.  If the
simplification work results in multiple "levels" of the spec being
supported, then perhaps VALARMs could be moved to an option-including
level, but not eliminated entirely.


At 12:30 PM 8/21/04, you wrote:
>Content-Type: multipart/alternative;
>         boundary="----------=_1093105859-28996-122"
>Content-Transfer-Encoding: binary
>MIME-Version: 1.0
>X-Mailer: MIME-tools 5.411 (Entity 5.404)
>
>I would like to suggest the removal of VALARM from the iCal spec.
>
>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.
>
>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.
>
>While the alarm information is useful to store and to use for a client 
>application, it seems pointless to transport.
>
>Can anyone express a scenario where sending a valarm from one client to

>another makes sense?
>
>cameron
>
>_______________________________________________
>Ietf-calsify mailing list
>[email protected]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.