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.
From: TimHare@xxxxxxxxxxx [mailto:TimHare@xxxxxxxxxxx]
Sent: Monday, August 23, 2004 4:52 AM
To: Cameron Stillion; ietf-calendar@xxxxxxx
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
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:
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
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
another makes sense?
Ietf-calsify mailing list
Interested Bystander, Non-Inc.