[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ietf-calsify] VALARM


As the officially-designated wild-eyed radical, I think Cameron has given up this argument too quickly.

There is certainly no law against using iCal as your internal storage format. However I would conjecture that nearly anyone who does that will end up, more or less inevitably, adding non-standard private extensions to iCal, to take account of *some* kind of concept that isn't found in iCal. i haven't yet heard anyone claim that iCal is, or can be, a representation for all calendar-related information that you might possibly want to keep. Thus I would conjecture that any software using iCal for storage is likely to end up either A) mapping its representation to a more standard subset for transport, or B) sending non-standard data in transport. The former is clearly fine from a standards perspective, while the latter can probably be designed to be fine, through judicious use of X- fields, etc.

Given this view, I find myself to reluctant to keep *any* feature in the iCal format for the reasons that Tim cites for keeping VALARM in the core spec. If there is a feature -- perhaps VALARM, perhaps something else -- that is not needed for transport, I would like to see it moved out of the base iCal standard and into another document, so that we can **simplify** the core standard that everyone needs to understand and implement.

I have nothing against VALARM per se, but I am skeptical of including anything in the base standard that isn't needed for data interchange between heterogeneous systems, because such transport is the most important problem we are trying to solve. In the case of VALARM, the thin client CalDav example is fairly compelling, but even there I see it as belonging in a separate spec that describes user-side concepts. (Personally, I want to be able to set an alarm for myself, but I don't want anyone else to set an alarm for *me*.) -- Nathaniel


On Aug 23, 2004, at 4:34 PM, Cameron Stillion wrote:

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: 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
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
Ietf-calsify@xxxxxxxxxxxxxxxxx
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Tim Hare
Interested Bystander, Non-Inc.