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: [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.
>
>
>
>
>