Subject: RE: [Ietf-calsify] VALARM

From: "Cameron Stillion" <[email-masked]>
Date: Mon, 23 Aug 2004 13:34:46 -0700

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-masked] [mailto:[email-masked]] 
Sent: Monday, August 23, 2004 4:52 AM
To: Cameron Stillion; [email-masked]
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-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sat, 28 Aug 2004 12:46:03 -0400

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

---

From: Doug Royer <[email-masked]>
Date: Sun, 29 Aug 2004 16:23:34 -0600

(On the CALSIFY mailing list we are talking about the next rev of 244[567].)

Nathaniel Borenstein wrote:

> ....

It is needed so CUA from vendor A can set an alarm in CS vendor B product.
MANY implementations discard objects they do not know. Without
a standardized VALARM, you can't set one. Your talking about access control
on the VALARM objects. And it is needed so that CUA from vendor A can see an
alarm in the CS.

> want anyone else to set an alarm for *me*.)  -- Nathaniel

Without VALARM - how would you set a VALARM in a CS were both
the CUA and CS were not the same vendor, unless there was a standard
way to set the alarm?

Your talking about access control on the VALARM objects.

I do not care if VALARM is a separate draft from the others or not.
I do think many implementations will break if there is not a 
standardized alarm.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards