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.