Subject: [Ietf-calsify] Recommendations for stripping down iCal to a manageable 'standard'

From: danw at novell.com (Dan Winship)
Date: Tue Aug 17 15:34:26 2004

On Mon, 2004-08-16 at 20:35 -0400, Cameron Stillion wrote:
> 1.3) eCal Scale
> 
> It has also been recommended that the standard be limited to
> "Gregorian" calendar support.  I suggest that other types of calendars
> will require different schemas and should therefore be handled in
> different standards... IF they are desirable in the future.  This
> standard should deal exclusively in Gregorian dates, in my opinion.

But really, the standard already does deal exclusively in Gregorian
dates. YYYYMMDD won't cut it in a calendar system where some days aren't
part of any month, or there are mid-year leap months that change the
month numbering. So dropping CALSCALE isn't going to let us simplify
anything anywhere else in the spec.

What it would mean, would be that if someone did later come up with an
Islamic calendar standard, that they'd have to have the calendars start
with "BEGIN:VISLAMICCALENDAR" or something, rather than "BEGIN:VCALENDAR
CALSCALE:ISLAMIC". Which means that clients would only be able to say "I
have no idea at all what this data is" rather than "I can't import this
calendar data because it uses dates from a non-Gregorian calendar
system."

So I vote for keeping CALSCALE, but clarifying that we have no idea what
non-GREGORIAN calendar data would look like, and that clients shouldn't
even try to parse a VCALENDAR object if they don't recognize its
CALSCALE.

> 2) Simplify recurrences
> 
> Nathaniel suggested in San Diego a rather severe approach which
> included doing away completely with recurrence rules.

Boo! But I agree they should be simplified.

> I also recommend that we disallow multiple BY*'s in one FREQ.

Hm... I think that needs to be considered at the same time as:

> 2.1) Better examples

In particular, "the last work day of the month" requires both BYDAY and
BYSETPOS, and that should probably be expressible.

Lots of holidays require multiple BY*s as well (eg, the "U.S.
Presidential Election Day" example uses 3). But then, does anyone really
use those? I can't imagine what a UI would look like that would let you
create an event like that...

The RRULE semantics are just awful. (See how long it takes you to
actually generate the aforementioned election day rule.) It would be
nice to come up with a comprehensive list of examples, covering all the
sorts of recurrences we think the spec should cover, and then come up
with a new, simpler recurrence rule grammar that covers that.

> 3) Simplify exceptions
> 
> I propose that exceptions be exclusively one-off events, never
> recurrences themselves.

Seems reasonable.

-- Dan

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Wed Aug 18 08:36:17 2004

> with a new, simpler recurrence rule grammar that covers that.

This is exactly why a list of time/dates sounds to me like a better option
- we avoid having to think of and provide every possible rule situation
where the reciever needs to infer what you meant when you sent the invite.
-CS