[Ietf-calsify] (no subject)

[Reinhold Kainhofer]

On Wednesday 13 October 2004 14:45, Helge Hess wrote:
> On Oct 13, 2004, at 14:33, <Veikko.Punkka at nokia.com> wrote:
> > I agree, it would be _really_ useful to have a (maintained) chart
> > which outlines what RRULE features are supported by what
> > 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
> > choice of which RRULE features belong to the core specification and
> > which ones not.
>
> 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.

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