Subject: [Ietf-calsify] (no subject)

From: Veikko.Punkka at nokia.com ([email-masked])
Date: Wed Oct 13 05:33:52 2004

I agree, it would be _really_ useful to have a (maintained) chart 
which outlines what RRULE features are supported by what 
implementation. Based on that chart it would be possible to make a rational 
choice of which RRULE features belong to the core specification and 
which ones not.

Any ideas of how we could practically start creating this kind of a chart?

Best Regards, 
Veikko

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Helge
> Hess
> Sent: 13 October, 2004 14:15
> To: <[email-masked]> <[email-masked]>
> Subject: Re: [Ietf-calsify] (no subject)
> 
> 
> On Oct 13, 2004, at 8:12, <[email-masked]> wrote:
> > 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?
> 
> 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
> 
> _______________________________________________
> 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 05:45:45 2004

> choice of which RRULE features belong to the core specification and

I think its already more or less clear that RRULE needs to be removed 
completely from the core spec so that we can move to UTC for the base 
spec.

An interesting question is whether the RRULE extension needs to have 
additional "levels" for basic / complex RRULE support.

Greets,
   Helge

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 13 06:57:05 2004

On Wednesday 13 October 2004 14:45, Helge Hess wrote:
> > implementation. 

Yes, I'd like to have such a table too. Here's the current support of KDE 
(libkcal as the base library, which supports more than KOrganizer as the 
corresponding GUI. libkcal is also used by other applications like KPilot's 
calendar conduits, the time tracking application KArm, and KNotes). I'll have 
to distinguish betwen KOrganizer (which provides less gui options) and 
libkcal (which supports almost all BY* rule, although you cannot create them 
in korganizer):

libkcal does understand and can handle the following BY* rules (not all 
combinations are understood, though. The ones neede by korganizer below are 
of course best supported):
BYSECOND: somewhat
BYMINUTE: YES
BYHOUR: YES
BYDAY: YES
BYMONTHDAY: YES
BYYEARDAY: YES
BYWEEKNO: NO
BYMONTH: YES
BYSETPOS: No (but is planned, needed for first/last weekday of a month)

In KOrganizer's GUI we support the following recurrence options:
Daily: FREQ=DAILY
Weekly: FREQ=WEEKLY;BYDAY=...
Monthly: FREQ=MONTHLY
  -) on the n-th (mon|tues|..)day: BYDAY=... 
  -) on the n-th day: BYMONTHDAY=...
Yearly: FREQ=YEARLY
  -) On the n-th day of month Y: BYMONTHDAY=11;BYMONTH=10
  -) On the n-th (mon|tues|..)day of Month Y:BYDAY=2MO;BYMONTH=10
  -) On the n-th day of the year: BYYEARDAY=285

All other recurrence rules understood by libkcal are shown in KOrganizer (if 
the FREQ>=DAILY), but cannot be edited.

> > Based on that chart it would be possible to make a 
> > rational

Why is it so clear that RRULE needs to be removed? Sure, moving to UTC would 
be great, but recurrence rules are such a core feature to (almost) all 
calendar GUIs, that I don't think sacrificing rrules for UTC is really 
warranted. 
For pure invitation handling, RRULEs might not be absolutely necessary, but 
remember that many applications use iCalendar as their native storage format 
(for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.). 

I think it really depends on whether iCalendar is supposed to be a format 
purely intended for invitation handling, or also as a storage format. 
Currently, I think it's the latter, and there removing all recurrence rules 
in the core spec is like removing all paragraph format settings in a word 
processing format spec.

Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041013/eab276e5/attachment.bin

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 07:21:39 2004

> Any ideas of how we could practically start creating this kind of a chart?

ScheduleWorld supports the entire RRULE definition.

ScheduleWorld also uses UTC for everything internally. This has greatly eased 
interoperability with limited devices and simplified the J2ME client.

RRULEs already work fine when you strictly use UTC. TimeZone support is purely 
a presentation issue and does not belong in RFC 2445.

Cheers.

-- 
Free SyncML-capable J2ME & J2SE replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

---

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

On Oct 13, 2004, at 15:56, Reinhold Kainhofer wrote:
> Why is it so clear that RRULE needs to be removed?

There was a long discussion on that (UTC+RRULE) issue some weeks back 
and I had the impression that everyone agreed.

> Sure, moving to UTC would be great, but recurrence rules are such a 
> core feature to (almost) all calendar GUIs, that I don't think 
> sacrificing rrules for UTC is really
> warranted.

Recurring appointments can be done in various ways and there are 
several servers (actually almost all OpenSource servers are in that 
category!) which store recurring events as a finite set of individual 
(but connected) events for good reasons.

So, removing RRULE's improves interoperability because it matches 
non-iCal-like-RRULE servers and clients, avoids differences in RRULE 
support, and it removes a huge complexity because timezones can be 
dropped.

> (for example, KOrganizer, Evolution, KPilot's calendar conduits, etc.).

As mentioned before I definitely agree that RRULE's should not be 
dropped, just moved out of the core specification.
So you can still use iCalendar+RRULE-ext as the native storage format 
(nothing will change for you!).

Greets,
   Helge

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Oct 13 07:45:47 2004

> a presentation issue and does not belong in RFC 2445.

How do you store a recurrence rule for "every monday 11:00 PST" in UTC? 
Due to DST shifts, 11:00 PST translates to different UTC values 
depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC 
(UTC-6) in summer).

Greets,
   Helge

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 09:01:23 2004

> depending on the week (18:00 UTC (UTC-7?) in winter and 19:00 UTC

The key is in DTSTART. Since you have a UTC value at an instance of time you 
can compensate for the changing timezone offsets at any set instance in the 
future. 
The key is the fact that the presentation layer can convert 11:00am April 22, 
2004 Canadian/Eastern into a UTC value and back again.

Cheers.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 13 09:01:24 2004

On Wednesday 13 October 2004 16:21, Mark Swanson wrote:
> RRULEs already work fine when you strictly use UTC. TimeZone support is
> purely a presentation issue and does not belong in RFC 2445.

Ahm, it's not that easy. Assume you want a recurring event each monday at 
01:30. During summer time this is (I'm in Austria, so central European Summer 
time, UTC+02:00) 23:30 on the previous sunday, in winter time this is 00:30 
on the monday. The recurrence rule will have to state that it's 01:30 local 
time each monday. You just cannot express this as a RRULE in UTC...

Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041013/96171c49/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 13 09:14:44 2004

On Wednesday 13 October 2004 18:01, Mark Swanson wrote:
> The key is in DTSTART. Since you have a UTC value at an instance of time
> you can compensate for the changing timezone offsets at any set instance in
> the future.
> The key is the fact that the presentation layer can convert 11:00am April
> 22, 2004 Canadian/Eastern into a UTC value and back again.

Ahm, for two persons in two different time zones this will not work.

Again use the example of my last mail: every monday at 01:30 in Timezone 
Europe/Vienna. If the start date is in summer time, the event is on sunday 
23:30 UTC. No imagine somebody in the US views this event. The event start 
day will be on a sunday, so for the US person the event will only be 
displayed on the following monday, which is one day after it was actually 
supposed to happen... 
I don't think RRULES can work without some information about the time zone.

Reinhold

PS: Yes, his is a borderline-case, but a spec, which doesn't get the 
borderline cases correct, is next to useless.
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041013/d87acd2c/attachment.bin

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Oct 13 09:23:13 2004

> can compensate for the changing timezone offsets at any set instance 

Yes, if you know the timezone the event was created in. Or in other 
words, you can save the time values in any timezone, including UTC, but 
you need to specify the timezone required for DST and historic 
calculations.

> 2004 Canadian/Eastern into a UTC value and back again.

Of course, but the presentation layer needs to know that the event was 
created in (and is intended for) "Candian/Eastern" time.
An "each Monday at 11:00 MST" is different to "each Monday at 23:00 
CET" even though the UTC starttime might match (DST rules are 
different, so a German flying to Arizona for a meeting at 11:00 MST 
will arrive at the incorrect time).

Greets,
   Helge

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 13 09:48:21 2004

> I don't think RRULES can work without some information about the time zone.

... which gives me an idea: How about moving the TZID parameter from the 
DTSTART to the RRULE (and RDATEs)?

I'm not aware of any other places in rfc2445, that depend on the timezone 
information, so this might put the timezone problem with recurrence rules to 
the place it actually belongs to: To the recurrence rules.

It will be nasty to implement in GUIs, but that nastiness is already there... 
Basically, the user would have to specify the rrule in some timezone, and if 
somebody else uses a different timezone, he'll have to change the rrule in 
the original timezone, so although the event might appear at 11:30 on Sunday 
in his calendar, the recurrence rule might still be set to recur on 01:30 on 
Monday (but in CEST)...

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Wed Oct 13 09:57:56 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: attxokfw.dat
Type: application/octet-stream
Size: 196 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041013/75f1e8f8/attxokfw.obj

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 11:24:26 2004

On October 13, 2004 12:14 pm, Reinhold Kainhofer wrote:
> > you can compensate for the changing timezone offsets at any set instance
> > in the future.

It does. We'll get to it in a couple of emails I'm sure.

> displayed on the following monday, which is one day after it was actually

I'd like to pick a different example because I read this as: you say the event 
is on Monday, then you say the US person viewing the event on a Monday is the 
wrong day? (or did you mean in 8 days as the following Monday?)

Next emai...

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 11:47:51 2004

> you need to specify the timezone required for DST and historic

It involves some work, but there is a way to do it without having to know what 
timezone the event is created in.

> created in (and is intended for) "Candian/Eastern" time.

Perhaps "(and is intended for)" is also a key factor. F.E. I assume that 
someone flying to Vancouver for a meeting would ask his presentation layer to 
display his events for that day in the Pacific timezone. I believe this to be 
logical.

> will arrive at the incorrect time).

Still a presentation issue. Perhaps this will help:

1. TZ=PST, recurring monday meeting: 11:00AM created by Joe
2. TZ=EST, Bob's calendar shows a 2:00PM recurring monday meeting.
3. Bob flies to the PST timezone, and sets his presentation timezone to PST, 
which shows his meeting at 11:00AM.

If that isn't the issue Helge/Reinhold, perhaps it's a deeper issue of how 
some folks are creating instances of the recurrence set from the 
DTSTART/RRULE definition.

Cheers.

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 11:57:13 2004

> day will be on a sunday, so for the US person the event will only be

If your RRULE specifies weekly every Monday, the US person will see the Monday 
1 second after his DTSTART, so he will see the correct Monday.

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Wed Oct 13 12:07:32 2004

Hi Mark,

--On Wednesday, October 13, 2004 2:47 PM -0400 Mark Swanson 
<[email-masked]> wrote:

> someone flying to Vancouver for a meeting would ask his presentation
> layer to  display his events for that day in the Pacific timezone. I
> believe this to be  logical.

The timezone needed for 'presentation' may well be different than the 
timezone needed when editing an event. Consider: I am in EST timezone but 
want to schedule an event for a meeting next week on the west coast in PST 
- so I create the event and set the start to 12:00 pm PST - note that I 
edit it in PST not my current 'presentation' timezone of EST. If at some 
later point I want to edit it, the edit dialog should show the time in PST 
- not the current 'presentation' timezone, whatever that may be.

Thus timezone information does need to be included with event data - 
however that info only needs to be a 'hint' - the actual time can be stored 
in UTC.

Hence my earlier suggestion of having a 'TZHINT' parameter on times 
specified in UTC. That 'hint' is only needed is special circumstances, e.g. 
editing, rrule expansion - all other operations can be done with the UTC 
time without reference to it.

-- 
Cyrus Daboo

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Oct 13 12:37:08 2004

> DTSTART to the RRULE (and RDATEs)?

This is something I suggested before. The only, but significant, 
problem is that this will break compatibility with existing solutions.
I fear the latter might be a very valid reason to keep it like it is.

Greets,
   Helge

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Oct 13 13:43:16 2004

> It does. We'll get to it in a couple of emails I'm sure.

To be honest, I'd really love to see this work. Because then all our problems 
would have vanished... But so far, I haven't seen 

> If your RRULE specifies weekly every Monday, the US person will see the
> Monday  1 second after his DTSTART, so he will see the correct Monday.

Yes, that's what he'll see, which is wrong. See below.

> I'd like to pick a different example because I read this as: you say the
> event is on Monday, then you say the US person viewing the event on a 
> Monday is the wrong day?

Yes, he'll see the event on monday. However, the event really occurs on Monday 
01:30 CEST, which is about *Sunday afternoon* in the US. Oops. 
I really said the event is on monday - for a person in CEST. But monday in 
CEST (UTC+0200) is not necessarily monday for a person in the US!

RRULEs are highly dependent on the local time zone. If you specify a 
recurrence on monday, this will no longer be true in general for a different 
time zone.

And translating RRULES from local time to UTC is not possible either. E.g. 
00:30 localtime on the first monday each month will be either 23:30 UTC of 
the first sunday, or of the last sunday of the previous month. I don't see 
any way to represent this as a RRULE in UTC.

So, to be correct, all recurrence calculation need to be done in the original 
time zone of the event, and only then can the results be translated to the 
time zone of the presentation layer.

Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041013/a5eb37bd/attachment.bin

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 16:44:28 2004

On October 13, 2004 4:43 pm, Reinhold Kainhofer wrote:
>
> Yes, he'll see the event on monday. However, the event really occurs on
> Monday 01:30 CEST, which is about *Sunday afternoon* in the US. Oops.

Well... duh. :-) My head was stuck where the <recurring> timezone/event would 
not conflict across the 12 midnight boundary. When it does you're hosed. 
Thanks to Reinhold, Helge, and Cyrus for taking the time to set me straight.

I also agree localtime is not possible either.
There is no way to calculate when the midnight boundary condition will happen 
- without a timezone...

We must not remove timezones.

Cheers.

---

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

> Thanks to Reinhold, Helge, and Cyrus for taking the time to set me 

Well, this is just another example why avoiding a requirement for 
timezones in the base spec will pay off.
(Political) Timezones are an incredibly complex issue (and I attribute 
my first grey hair to it ;-) If we can remove that issue from the base 
spec, its a huge gain for implementors. If its only in the base spec 
because of another - questionable! - feature, rrule's, its even more 
viable.

> We must not remove timezones.

Me says, remove rrule's and timezones from the base spec, but ensure 
that they are still available in an extension spec from the beginning 
on.
There are proper implementations and it would be a real waste to render 
them useless due to incompatible changes in the standard.

Greets,
   Helge

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Wed Oct 13 18:49:16 2004

> because of another - questionable! - feature, rrule's, its even more

10 recurring swimming lessons in a row, x skating lessons in a row, and a 
number of other recurring events. Let's not forget birthdays, anniversaries, 
10:00 am weekly meetings during a crunch.
Perhaps you meant RRULEs are questionable in their current form?

> that they are still available in an extension spec from the beginning

I'm a little surprised to hear this. Based on the seemingly infinite amount of 
time wasted waffling over 2445 (all good smart folks involved) I couldn't 
fathom trying to make _two_ specifications work.

Cheers.

---

From: TimHare at comcast.net ([email-masked])
Date: Wed Oct 13 21:41:18 2004

There's a good point here, we can't afford to work on this forever...

Has anyone from previous Interops or other sources got a listing of RRULE 
issues that exist between implementations? If we can list all of the places 
where RRULE interoperabiltiy is broken, will vendors / implementors commit 
on this list to work out the differences and solve the problems? If they 
will, and not get into finger-pointing sessions, then RRULEs should be in a 
base spec. If not, then RRULEs need to be in an extension spec and 
implementations that don't support RRULEs or don't support them in an 
interoperable way will have to calculate the individual VEVENTs (obviously 
within a finite timeframe) and exchange those.

As for timezones:  it's the political timezone system that is broken on 
this issue, not necessarily our RFCs.  If we have to have them (for the use 
cases others have cited?), then can we simplify how we exchange them? How 
about the spec referencing some repository for political timezone 
definitions, and the spec only referencing TZs by a standard name? There 
are standards for names of political entities (like states in the US which 
have two-letter postal codes, and also federal state ID numbers), standards 
for names of languages (EN, FR, etc.), so why couldn't one of these 
standards bodies "hold" the timezones also?

>fathom trying to make _two_ specifications work.

Tim Hare
Interested Bystander, Non-Inc.