Subject: [Ietf-calsify] (no subject)

From: Veikko.Punkka at nokia.com ([email-masked])
Date: Tue Oct 12 23:37:40 2004

It sounds like you would be sacrificing a lot of other things at the
same time. Let me explain my own situation. I have my calendar data
on multiple devices (a PC, a bigger mobile phone I carry around at work, 
a smaller mobile phone I carry around at leisure). I synchronise the
devices periodically so that they keep in sync to each other and I use
all the devices to enter and view events in the calendar. In my calendar I
have several things that repeat: anniversaries, weekly meetings, etc.
Sometimes they do not have a specific end date, while other times they do
(say for example the projected duration of a project). Occasionally I need 
to modify these repeating things. The time of the weekly meeting may change,
or it may be changed to a biweekly meeting or the end date of the project has 
slipped and so the end date of the repeat changes. I want to do these changes from 
any one of my devices without having to go through every occurence of that 
repeating thing. For that I need a reliable synchronisation method that keeps
those repeating things related. Most of current implementations I use do
this by sending the repeating things as a single VEVENT with a RRULE
that is used to calculate the occurences of the thing in each of the
devices. If you now start sending each occurence as a single VEVENT
with some other thing to keep them related (not necessarily supported
by current clients), how do you think that will make you reach interoperability
sooner?

Veikko Punkka

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 13 October, 2004 04:28
> To: [email-masked]
> Subject: Re: [Ietf-calsify] (no subject)
> 
> 
> Sorry - I was unclear. What I meant to say was, for 
> iCal-Basic or whatever 
> we're calling it, that a set of VEVENTs instead of using 
> RRULEs would work 
> for me, if it means that interoperability comes sooner.  It 
> sacrifices the 
> "every week forever" kind of event, but if my client and/or 
> server can 
> compute and send "every week until my projected retirement 
> date" that's 
> sufficient :-)
> 
> At 09:21 AM 10/12/04, Doug Royer wrote:
> 
> 
> >What do you mean by "single VEVENT"?
> >Do you mean that we need to start with VEVENTs?
> >
> >--
> >
> >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
> >
> >
> >
> >
> >
> >_______________________________________________
> >Ietf-calsify mailing list
> >[email-masked]
> >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> Tim Hare
> Interested Bystander, Non-Inc. 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Oct 13 04:15:31 2004

On Oct 13, 2004, at 8:12, <[email-masked]> wrote:
> If you now start sending each occurence as a single VEVENT

The huge majority of available systems are not interoperable at all. 
Reducing complexity will make it much easier for those systems to 
implement iCal and to ensure interoperability at a certain level. This 
level might not be sufficient for you, but it will improve the 
situation for a lot of other users of scheduling software.

On the other side we should not break existing applications (you are 
certainly correct that some implementations probably support 100% of 
RRULE's). IMHO if we remove RRULE's from the core spec, we should _at 
the same time_ have an extension spec available which implements 
'traditional' RRULE's.

Besides that it would be _really_ useful to have a (maintained) chart 
which outlines what RRULE features are supported by what 
implementation. So far I have only seen pretty broad statements like "4 
of 5 implements X".

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org