Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Tue Jul 25 17:24:23 2006

I would like to consider whether RRules are too complicated for GUI  
display in our most common calendar client applications.  If I send a  
complex RRule event to you and your client can't display the RRule in  
its GUI, you can only accept or reject the request, not modify it,  
and possibly not even understand it well.   Worse, if I'm using  
CalDAV and one client creates a complex RRule but then I switch to  
another client, I risk having a recurring event that I can't  
manage.   Shared calendars are particularly subject to this problem.

Although RRules may need to be powerful for certain situations  
(timezones), I believe they're too complex for use in events in GUIs  
designed for personal calendaring.  As an exercise, I took Apple's  
iCal, the most powerful recurrence-rule generating GUI available to  
me at this time on this computer, and tried to discover the full  
range of RRules I could create.  I also searched the Web for  
instances of certain kinds of RRules (e.g. looking at IETF meeting  
ICS files and similar shared files and googling for BYWEEKNO.) The  
kinds of RRules that I couldn't find "in the wild" or create, we  
should consider discouraging for interpersonal calendaring.

I don't care if we repeat the exercise for some other GUI client or  
make changes on what some other GUI client can do; this first attempt  
illustrates the approach rather than limits it.

My personal opinion is that some kind of simplification is required  
for two big reasons:
	- To improve interoperability between clients that attempt to do a  
decent job of RRules
	- To encourage clients that currently don't do RRules (many mobile  
devices) to implement.  Let's meet them half-way with  recurrence  
functionality that's simple enough for them to implement, and if they  
implement anything they're more likely to implement the whole set if  
it's that simple.

Besides GUI display concerns, I had a couple more minor reasons which  
you can find inside the proposal.

-------------- next part --------------
A Minimal Profile of RRULE for inter-personal scheduling

These RRULE simplifications are intended for VEVENTS (not necessarily timezones or tasks) in the context of:
 - Any calendar that is exported, with the intent to import it into a personal calendar application
 - Any interpersonal scheduling request
 - Any CalDAV calendar
 
WHY?  It's not because it's impossible to write iCalendar libraries.  Instead I have a couple other concerns:

a) This is really the core concern: display of recurrence rules.  We could just use recurrence dates, except that we'd lose the functionality of one person modifying the recurrence pattern for a recurring event, and the functionality of quickly grasping the recurrence pattern when I'm invited to something.  If I'm accepting an invitation or modifying an event, it's crucial to understand quickly that  "This event is scheduled every other week except for Christmas" rather than have to grovel through actual recurrence dates.  Thus, I conclude that the ability to display a recurrence rule is crucial to the usefulness of recurrence rules in VEVENTS involving real people.  RRule uses which can't be displayed by the client are harmful to usability and interoperability.

b) Many combinations are meaningless, ambiguous or nearly so, even if we limit ourselves to clauses that are actually in common use.  Some examples to try to remove:
    FREQ=YEARLY;BYDAY=FR -- is this every friday? The first friday each year?
    FREQ=DAILY;BYMONTH=3 
    FREQ=WEEKLY;BYDAY=FR;BYMONTHDAY=26
    
c) Some kinds of recurrences can be represented in more than one way.  It's an improvement in interoperability to *reduce* the number of options for representing a given recurrence.
    FREQ=DAILY;BYDAY=MO,WE,FR
    FREQ=WEEKLY;BYDAY=MO,WE,FR
    
d) We should have a model where we're clearly limiting or expanding recurrences with a BY* clause but not both.  The model is too complex when the evaluation is context-specific so we should fix this.  
    FREQ=DAILY;BYDAY=MO,WE,FR -- this limits/filters occurrences, to less than the default DAILY
    FREQ=WEEKLY;BYDAY=MO,WE,FR -- this multiplies occurrences beyond the default WEEKLY

How do I know which recurrence features can be displayed?  I tested Apple's iCal,  Chandler, Yahoo and Google Calendar GUIs (and would welcome additional cases).  iCal is the most flexible of these across all possible rules, with the possible exception that Google has an "Every weekday" rule option that Apple could probably duplicate by letting the user pick checkboxes for MoTuWeThFr.  If we were really to go with lowest common denominator we could be even more brutal but I don't think we want to.
 
FEATURES TO FORBID in VEVENT RRULES for display 

#1.  Only one recurrence rule per RRULE

#2. No EXRULE

#3.  No FREQ = SECONDLY, MINUTELY and HOURLY.

#4.  No BYSECOND, BYMINUTE, BYHOUR, BYYEARDAY, BYWEEKNO and BYSETPOS.

#5.  No WKST, because the rules that have a dependency on when the week starts are gone now.

COMBINATIONS TO REMOVE

#6.  Fewer combinations of BY* clauses together, fewer combinations of a given frequency and inappropriate BY* clauses:
  * MUST NOT combine BYDAY and BYMONTHDAY.
  * MUST NOT combine DAILY frequency and ( BYDAY or BYMONTHDAY or BYMONTH)
  * MUST NOT combine WEEKLY frequency and BYMONTH
  * MUST NOT combine MONTHLY frequency and BYMONTH
  * MUST NOT combine YEARLY frequency and BYDAY unless there's also a BYMONTH
      (because "every year on the 52nd Monday" is too useless)

#7.  MUST NOT have more than one of any kind of clause (INTERVAL, UNTIL, COUNT, BYDAY, BYMONTHDAY, BYMONTH)

#8.  When the old "ordwk" was used (to specify the 3rd Friday or 1st monday), it didn't make sense with WEEKLY frequency.  When the old weekday stuff was used (e.g. every Tuesday and Thursday) it didn't make sense with monthly freqency or yearly.  Thus, split these two concepts into two and limit usage. 

OTHER VARIATION TO REMOVE
  
#9. MUST use the canonical ordering of clauses. Frequency obviously comes first, then INTERVAL (required?) then UNTIL or COUNT (optional?) then BYDAY, BMONTHDAY and BYMONTH (with the combination restrictions above)

#10.  MUST include the INTERVAL

#11.  When specifying the "Nth weekday of a Month", only options are:
    1, 2, 3, 4, 5 and -1  
    (Thus remove option for "-4MO" or the fourth-to-last Monday of the month)
     Similarly, the only "ordmoday" that is negative is -1.
    
--------

RESULT:  An example of rewriting the ABNF completely with what you CAN have -- only the combinations that make sense.

recur     = "FREQ=DAILY" interval [ limit ] 
          =/ "FREQ=WEEKLY" interval [ limit ] [ chooseweekday ]
          =/ "FREQ=MONTHLY" interval [ limit ] [ choosemonthday ]
          =/ "FREQ=YEARLY" interval [ limit ] [ choosemonth [ choosemonthday ] ]
              
interval  = ";" "INTERVAL" "=" 1*DIGIT 

limit = ";" ( "UNTIL" "=" enddate ) / ( "COUNT" "=" 1*DIGIT ) 

chooseweekday = ";" ( "BYDAY" = weekdaylist )

choosemonthday = ";" ( "BYDAY" = nthweekdaylist )  
                 / ( "BYMONTHDAY" = monthdaylist)

choosemonth = ";" "BYMONTH" = bymolist

enddate    = date
enddate    =/ date-time            ;An UTC value

weekdaylist = weekday [ *("," weekday) ]

nthweekdaylist = nthweekday [ *("," nthweekday) ] 

nthweekday = ("1" / "2" / "3" / "4" / "5" / "-1" ) weekday 

weekday    = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
     ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
     ;FRIDAY, SATURDAY and SUNDAY days of the week.

monthdaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )

monthdaynum = ("+" ordmoday) / ( "-1" )

ordmoday   = 1DIGIT / 2DIGIT       ;1 to 31

bymolist   = monthnum / ( monthnum *("," monthnum) )
monthnum   = 1DIGIT / 2DIGIT       ;1 to 12

--------
     
NOTES ON REDUCED FUNCTIONALITY

What is this simplification *not* good for?  What are its effects?

REMOVING HOURLY: This makes simplified recurrence rules less useful for some kinds of repetitive tasks, particularly automated tasks.  Let's consider this a separate kind of application, as it doesn't affect VEVENTs in interpersonal scheduling.

REMOVING BYHOUR:

With the removal of BYHOUR, some timezone rules don't work.  We need to make RRULE BYHOUR understood for timezones, but NOT for interpersonal scheduling.

There are examples of BYHOUR at <http://tipi.sourceforge.net/doc/recur/indexs01.html> but I've never seen this in actual interpersonal scheduling.

An example at <http://www.orafaq.com/node/862> uses BYHOUR but could express the same rule with the reduced syntax.

REMOVING BYYEARDAY:

An example: RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU;BYYEARDAY=72
This is pretty stupid.  Only leap years affect whether the 72nd day of the year is 31+28+13 = March 13 or 31+29+12 = March 12.  It's just not useful enough to schedule a meeting on "March 13, except March 12 if it's a leap year" and that kind of use case can be worked around.  (One special case might be to state that a RRULE that occured yearly on Feb 29 might automatically recur on Feb 28 if not a leap year)  So without BYYEARDAY we'd see rules like "RRULE:FREQ=YEARLY; INTERVAL=1" and the date would be March 12 every year.

REMOVING BYWEEKNO:

An example: RRULE:FREQ=YEARLY;BYWEEKNO=1;BYDAY=5SU
This was crafted to show how combining BYWEEKNO with other BY* clauses generates non-sensical events.

Apple's iCal doesn't create BYWEEKNO.  It only uses BYMONTH with a possible modifier of BYDAY.  So instead of a rule of "RRULE:FREQ=YEARLY;BYWEEKNO=7;BYDAY=FR", an Apple iCal user would have to generate "RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=3FR"

REMOVING BYSETPOS:

An example supposed to be "Last weekday of March": RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR;BYMONTH=3;BYSETPOS=-1;WKST=SU

iCal just can't recreate this.  The closest iCal gets is "Every year on the last friday of March" which is RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=-1FR.  It's also true that iCal can't display this.

Is there an alternative?  Could we specify a special BYDAY code for "A weekday" in order to make this work?  E.g.
    RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=-1WK

For better backward compatibility, another alternative is to require all clients to understand this one application of BYSETPOS, if at least some minimum number clients are willing to do the display work.

REMOVING COMBINATION OF DAILY + BYMONTH:

What about "Every April, I need to have a series of meetings that is every work day all month"?  In the old rules this could be:
    RRULE:FREQ=DAILY;BYMONTH=4;BYDAY=MO,TU,WE,TH,FR

With this simplification you just can't do that. The best a client could do is to create a "FREQ=DAILY;UNTIL=20060430;BYDAY=MO,TU,WE,TH,FR" from the beginning to the end of April, each year.  

REMOVING ABILITY TO COMBINE RRULES

My quilting group actually meets every 4th saturday and every 4th tuesday evening, with the saturday offset from the tuesday meeting by being 2.5 weeks after the Tuesday meeting.  Our Yahoo group administrator actually put this on the Yahoo calendar by... creating *2* recurring events.  If Yahoo could express this in RRULE it would probably be two VEVENTS with something like
    DTSTART:20060523T193000
    RRULE:FREQ=WEEKLY;INTERVAL=4
    and
    DTSTART:20060610T193000
    RRULE:FREQ=WEEKLY;INTERVAL=4

-------------- next part --------------

Feedback?

thanks!
Lisa

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Tue Jul 25 17:52:50 2006

Lisa Dusseault wrote:
> its GUI, you can only accept or reject the request, not modify it, and
> possibly not even understand it well.   Worse, if I'm using CalDAV and
> one client creates a complex RRule but then I switch to another
> client, I risk having a recurring event that I can't manage.   Shared
> calendars are particularly subject to this problem.
I have carried out similar research in the context of discussions /
advise within the  Mozilla Sunbird / Lightning  project.  It will take a
little time to review your submission, and respond.  In general, I agree
some guidance on this issue (as it impact on GUI feature sets) it
definitely required.  I am unsure if your approach in necessarily the
best way to deal with this problem.

More detailed comment to follow (time permitting) ..

I also have a set of  iCalendar  files for NZ, US and Canada public
holidays, and other 'more complex' use of RRULE's that I have used as
the basis for my  GUI design  proposals.  They may also be of interest
in this discussion / thread.

-- 
_______________________________________________

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

---

From: tantek at technorati.com (Tantek Çelik)
Date: Tue Jul 25 18:01:31 2006

On Jul 25, 2006, at 5:24 PM, Lisa Dusseault wrote:

> The kinds of RRules that I couldn't find "in the wild" or create, we 

I *strongly* agree with this methodology.

Too much of RRULE in 2445 appears to have been designed to reach some 
sort of mathematical completeness goal in terms of recurrence, instead 
of based on the actual 80/20 usage of recurring meetings in the real 
world.

> <recur-simplification.txt>
> Feedback?

I cannot find anything in your analysis that I disagree with.

Lisa, thanks very much for doing this research and analysis.  It was 
very illuminating, and you have my support.

Thanks,

Tantek

--
Tantek ?elik
Chief Technologist, Technorati, Inc.

---

From: pregen at egenconsulting.com (Pat R Egen)
Date: Tue Jul 25 18:03:46 2006

Andrew, I'd be interested in your set of iCalendar files to use as part of 
our Calconnect Interoperability testing.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Andrew N Dowden <[email-masked]> 
Sent by: [email-masked]
07/25/2006 08:52 PM

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs

  SoftDesign Group

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060725/4d425558/attachment.htm

---

From: chuck at evdb.com (Chuck Norris)
Date: Tue Jul 25 18:50:51 2006

I like this approach, and can't find anything I would add or change  
about your conclusions.  It certainly meets all of our needs, and  
limiting to this set would make my life a lot easier.

Chuck

On Jul 25, 2006, at 5:24 PM, Lisa Dusseault wrote:

> display in our most common calendar client applications.  If I send  
> a complex RRule event to you and your client can't display the  
> RRule in its GUI, you can only accept or reject the request, not  
> modify it, and possibly not even understand it well.   Worse, if  
> I'm using CalDAV and one client creates a complex RRule but then I  
> switch to another client, I risk having a recurring event that I  
> can't manage.   Shared calendars are particularly subject to this  
> problem.
>
> (timezones), I believe they're too complex for use in events in  
> GUIs designed for personal calendaring.  As an exercise, I took  
> Apple's iCal, the most powerful recurrence-rule generating GUI  
> available to me at this time on this computer, and tried to  
> discover the full range of RRules I could create.  I also searched  
> the Web for instances of certain kinds of RRules (e.g. looking at  
> IETF meeting ICS files and similar shared files and googling for  
> BYWEEKNO.) The kinds of RRules that I couldn't find "in the wild"  
> or create, we should consider discouraging for interpersonal  
> calendaring.
>
> make changes on what some other GUI client can do; this first  
> attempt illustrates the approach rather than limits it.
>
> functionality that's simple enough for them to implement, and if  
> they implement anything they're more likely to implement the whole  
> set if it's that simple.
>
> Besides GUI display concerns, I had a couple more minor reasons  
> which you can find inside the proposal.
>
> Lisa_______________________________________________

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Tue Jul 25 20:42:45 2006

Lisa Dusseault wrote:
> iCal, the most powerful recurrence-rule generating GUI available to me 
> at this time on this computer, and tried to discover the full range of 
> RRules I could
ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, 
ha, ha, ha, ha, ha, ha, ha, ha, ha
, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, ha, 
ha, ha, ha, ha, ha, ha, ha, ha, ha, ha

That's the best laugh I've had today. Apple iCal is my greatest 
headache. My current battle is the presence of an RDATE entry will screw 
up the display of everything in the file, RDATE or not. I opened this as 
a defect at BugReport.apple.com two weeks ago, and haven't been blessed 
with any kind of response.

Try the web based UI on our application:

http://www.mhsoftware.com/caldemo/

It can create the following things that iCal doesn't support:

RDATE
BYSETPOS (at least a couple cases of it).

Additionally, I don't think they support.

Ala-Carte Month Selection for YEARLY recurrence

> #7.  MUST NOT have more than one of any kind of clause (INTERVAL, UNTIL, COUNT, BYDAY, BYMONTHDAY, BYMONTH)
I must mis-understand you. Let's see American thanksgiving:

RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=4TH

that seems to be two of those clauses.

COUNT is computationally difficult. If the problem with BYSETPOS is that 
calculating the set was difficult, then the same problem applies to 
COUNT. It requires the implementor to calculate the complete set of 
recurrences, and then check if the test date (the date we're drawing) is 
within that set.

I would really vote for ditching COUNT. If a UI wants to implement 
count, THEY can calculate the UNTIL clause and supply it.
> #10.  MUST include the INTERVAL
What if the interval is one? Seems kind of silly to me.
> #11.  When specifying the "Nth weekday of a Month", only options are:
This will kind of complicate people's parsers because we'll have to look 
at the actual data in the BYDAY and determine if it's a weekdaylist or 
nthweekdaylist. This is aggravated by the fact that digits are already 
allowed in BYDAY. I.E. 4TH.

While I'm not one to recommend junking things up, it seems to me it 
would be cleaner to add a BYWEEKDAY clause than to have BYDAY work in 
two different modes.

Alternatively, I would buy creation of a synthetic day of week WD to 
indicate WD so that the syntax would be

BYDAY=-1WD

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Wed Jul 26 06:23:42 2006

----- Original Message ----- 
From: "George Sexton" <[email-masked]>
> that seems to be two of those clauses.

I think you misinterpreted this statement.  You can have multiple different 
clauses, but not multiple same clauses.  So you can have BYMONTH and BYDAY, 
but not two BYDAYs.  The Thanksgiving example above would still be valid 
from what I can tell.

I think the overall idea of identifying what is acceptable in standard 
recurrence definitions is great.  I only have one thing that conflicts with 
the way we do things today, the elimination of BYSETPOS.  We use BYSETPOS to 
specify the last week day or weekend of a month.  Examples of how we use 
this are:

"Each year, last weekday of March": 
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3:BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

"Each month, first weekend day of the month": 
RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=SA,SU;BYSETPOS=1

When we built our UI for creating and viewing events, we wanted to support 
anything that would be sent to us from Outlook.  The ability to select the 
Nth weekday or weekend day is supported there and it seems to me it would be 
fairly common for people to use.  I liked the suggestion at the end of the 
proposal that maybe we could support this specific use of BYSETPOS.

Thanks for the proposal Lisa.

Chris

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Wed Jul 26 08:19:42 2006

Hi Chris,

--On July 26, 2006 9:23:33 AM -0400 Chris Bryant 
<[email-masked]> wrote:

> When we built our UI for creating and viewing events, we wanted to
> support anything that would be sent to us from Outlook.  The ability to
> select the Nth weekday or weekend day is supported there and it seems to
> me it would be fairly common for people to use.  I liked the suggestion
> at the end of the proposal that maybe we could support this specific use
> of BYSETPOS.

One concern with this - if we come up with a new set of properties, or new 
restrictions on existing properties we need to make sure that the new 
requirements are not more complex than what we already having. Having a 
requirement that BYSETPOS can only be used with certain uses of BYDAY would 
IMHO increase complexity not reduce it.

PS I too agree that BYSETPOS is useful particularly for the weekday 
inclusion/exclusion issue. Certainly we could have new element WDAY=YES/NO 
to handle the combination of BYDAY/BYSETPOS. But then you also run into the 
need to support 'weekend shifts' - i.e. if a regular meeting ends up on a 
weekend day, then move it to the nearest weekday, or the previous or next 
weekday. I have seen clients offer that capability. It can be implemented 
right now with RRULEs.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Jul 26 17:38:20 2006

Personally, I think we should avoid any new properties as part of the
Calsify effort. I think that restrictions on existing properties are
probably not horrible to do for implementations that support those
properties already, but brand new properties involve a lot more effort.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Wednesday, July 26, 2006 11:19 AM
To: Chris Bryant; George Sexton; Lisa Dusseault
Cc: IETF-iCalendar
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal
calendarGUIs

Hi Chris,

--On July 26, 2006 9:23:33 AM -0400 Chris Bryant <[email-masked]>
wrote:

> support anything that would be sent to us from Outlook.  The ability 
> to select the Nth weekday or weekend day is supported there and it 
> seems to me it would be fairly common for people to use.  I liked the 
> suggestion at the end of the proposal that maybe we could support this 
> specific use of BYSETPOS.

--
Cyrus Daboo

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Thu Jul 27 07:03:59 2006

Although there may be a cleaner solution to a problem by coming up with new 
properties, I agree that we should try to avoid adding new properties as 
part of the Calsify effort.  I think we should try to identify the set of 
recurrence rules that people really use when scheduling via common calendar 
UIs and recommend that people try to support those.  I wouldn't think that 
we would forbid systems from creating rrules outside the common set, but we 
should make it understood that if this is done, other systems may not be 
able to handle them.

Chris

----- Original Message ----- 
From: "Tim Hare" <[email-masked]>

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Thu Jul 27 08:26:27 2006

It would be better to have a new property, than to add an alternate 
behavior mode for an existing property.

One of my goals is to have a spec that most people can get right. My 
iCal implementation becomes more valuable with more correct 
implementations. The suggestion of nthweekdaylist for BYDAY would be a 
high defect area.

---

From: lear at cisco.com (Eliot Lear)
Date: Thu Jul 27 08:44:58 2006

> behavior mode for an existing property.

[Chair hat off]

I largely agree.  Doing otherwise could cause serious interop problems,
although sometimes circumscribing behavior is okay, such as what Lisa
has proposed.

Eliot

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Thu Jul 27 09:01:14 2006

I don't think anyone is proposing an alternate behavior for an existing 
property.  I am in favor of trying to support BYSETPOS in the way it is 
commonly used today to specify weekends or weekdays.  I am suggesting that 
we support this limited use of BYSETPOS and that people should avoid 
generating rrules using BYSETPOS except in the case that it is used to 
identify weekends or weekdays.

Chris

----- Original Message ----- 
From: "Eliot Lear" <[email-masked]>
To: "George Sexton" <[email-masked]>
Cc: "'IETF-iCalendar'" <[email-masked]>
Sent: Thursday, July 27, 2006 11:44 AM
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal 
calendarGUIs

---

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Thu Jul 27 10:00:49 2006

Two documents developed by CalConnect may have some relevance to this 
discussion.  Both were developed in consideration of the Calsify process.

The first is the Recurrence Problems and Recommendations document, 
developed by the Recurrence Technical Committee. This was more of an 
attempt to fix what is there now to give better interoperability, rather 
than do 'personal calendar simplification' as such.  However the two 
approaches share some elements in common.  Additionally this document 
addresses iTIP, which wasn't considered in the original post on this 
subject.  The Recurrence document may be found at:

http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf

Secondly is the Minimum-Interoperability Use Cases document, developed 
by the Usecase Technical Committee.  This was an attempt to defiine a 
minimum set of use cases which need to be supported to provide 
sufficient interoperability to make an implementation reasonably 
useful.  This document may be found at:

http://www.calconnect.org/publications/miniopusecasesv1.1.pdf

Hope these will be of some use.

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) ? +1 707 498 2238 (mobile)
http://www.calconnect.org ? [email-masked] 
<mailto:[email-masked]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060727/c0810f54/attachment.html

---

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Thu Jul 27 10:00:53 2006

Dave Thewlis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060727/6180a45b/attachment.htm

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Thu Jul 27 11:14:34 2006

You're right. I'm wrong.

My objection to her proposal for elimination of BYSETPOS is that it 
eliminates any ability to do last weekday, or 1st weekday.

Chris Bryant wrote:
> George,
>
> I think you may have misinterpreted item #11 below (or maybe I did).  
> I interpreted item 11 to say that only the numbers 1, 2, 3, 4, 5, and 
> -1 could be used in the BYDAY clause to, as stated in 2445,  "indicate 
> the nth occurrence of the specific day within the MONTHLY or YEARLY 
> RRULE".  With Lisa's proposal, you could still say the "last Friday of 
> the month" using "BYDAY=-1FR", but you could not say the second to the 
> last Friday of the month using "BYDAY=-2FR".
>
> I don't think item 11 implied a change to the way BYDAY works, just a 
> restriction on what values could be specified in it.
>
> Chris
>
> ----- Original Message ----- From: "George Sexton" 
> <[email-masked]>
>> This will kind of complicate people's parsers because we'll have to 
>> look at the actual data in the BYDAY and determine if it's a 
>> weekdaylist or nthweekdaylist. This is aggravated by the fact that 
>> digits are already allowed in BYDAY. I.E. 4TH.
>>

---

From: cbryant-ical at corp.usa.net (Chris Bryant)
Date: Thu Jul 27 11:14:56 2006

George,

I think you may have misinterpreted item #11 below (or maybe I did).  I 
interpreted item 11 to say that only the numbers 1, 2, 3, 4, 5, and -1 could 
be used in the BYDAY clause to, as stated in 2445,  "indicate the nth 
occurrence of the specific day within the MONTHLY or YEARLY RRULE".  With 
Lisa's proposal, you could still say the "last Friday of the month" using 
"BYDAY=-1FR", but you could not say the second to the last Friday of the 
month using "BYDAY=-2FR".

Chris

----- Original Message ----- 
From: "George Sexton" <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal 
calendarGUIs
> While I'm not one to recommend junking things up, it seems to me it would 
> be cleaner to add a BYWEEKDAY clause than to have BYDAY work in two 
> different modes.
>

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Thu Jul 27 11:25:36 2006

It may be a poor proposal; I didn't think very hard about the  
alternatives.  There's still the question of whether GUIs offer  
affordances to pick or display "[first|last] weekday of [month| 
year]".  iCal doesn't.

Lisa

On Jul 27, 2006, at 10:52 AM, George Sexton wrote:

>> I think you may have misinterpreted item #11 below (or maybe I  
>> did).  I interpreted item 11 to say that only the numbers 1, 2, 3,  
>> 4, 5, and -1 could be used in the BYDAY clause to, as stated in  
>> 2445,  "indicate the nth occurrence of the specific day within the  
>> MONTHLY or YEARLY RRULE".  With Lisa's proposal, you could still  
>> say the "last Friday of the month" using "BYDAY=-1FR", but you  
>> could not say the second to the last Friday of the month using  
>> "BYDAY=-2FR".
>>
>> I don't think item 11 implied a change to the way BYDAY works,  
>> just a restriction on what values could be specified in it.
>>
>> Chris
>>
>>> This will kind of complicate people's parsers because we'll have  
>>> to look at the actual data in the BYDAY and determine if it's a  
>>> weekdaylist or nthweekdaylist. This is aggravated by the fact  
>>> that digits are already allowed in BYDAY. I.E. 4TH.
>>>
>>> While I'm not one to recommend junking things up, it seems to me  
>>> it would be cleaner to add a BYWEEKDAY clause than to have BYDAY  
>>> work in two different modes.
>>>
>>> Alternatively, I would buy creation of a synthetic day of week WD  
>>> to indicate WD so that the syntax would be
>>>
>>> BYDAY=-1WD
>>
>>
>
> -- 
> George Sexton
> MH Software, Inc.
> Voice: +1 303 438 9585

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Thu Jul 27 13:18:14 2006

Lisa Dusseault wrote:
> affordances to pick or display "[first|last] weekday of 
> [month|year]".  iCal doesn't.

Ours does.

Outlook does. As a vendor, I really want to have interoperability with 
Outlook. If iCal doesn't support the recurrence patterns that Outlook 
does then it's going to be a real problem.

My reason for supporting Outlook is based on the practicality that 
virtually every computer sold in the US for business has it installed. 
While I personally find Apple iCal to be a very neat and elegant 
application, it's overall market-share is relatively small.

Don't get me wrong. I'm really OK with killing BYSETPOS its just that we 
need a replacement for the one really useful thing it does.

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Jul 27 13:40:27 2006

Hi George,

> does then it's going to be a real problem.

This is the real question: what does it mean for one client to 'support' 
the features in another? Right now I suspect you will find that a recurring 
event generated in one client will be correctly displayed in another, but 
you may not be able to edit it in the same way and preserve the original 
recurrence pattern. Does that make them non-interoperable? Certainly on the 
editing front one could argue that.

In my opinion no matter what we do, we will always have clients with 
different recurrence rule editing capability. What we need to do is provide 
sensible guidance for clients telling them how they should handle the case 
of a recurrence that is too complex for their editor (the guidance would 
pretty much say 'you MUST handle this case without data loss'). Also we 
should provide sensible 'profiles' of recurrence rules for say mobile, 
simple desktop/web and advanced desktop/web clients that suggest a sensible 
'minimum' editing capability for each.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net (Tim Hare)
Date: Thu Jul 27 21:26:57 2006

Well, we could hope that Outlook, when you choose the option to "use
iCalendar format", would comply with whatever ends up being the
interoperability standard.  I appreciate the market issues for a company,
but I don't think moving the standard as close as possible to Outlook's
implementation is going to particularly simplify things.

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of George Sexton
Sent: Thursday, July 27, 2006 4:18 PM
Cc: IETF-iCalendar
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal
calendarGUIs

Lisa Dusseault wrote:
> affordances to pick or display "[first|last] weekday of [month|year]".  
> iCal doesn't.

Ours does.

Outlook does. As a vendor, I really want to have interoperability with
Outlook. If iCal doesn't support the recurrence patterns that Outlook does
then it's going to be a real problem.

My reason for supporting Outlook is based on the practicality that virtually
every computer sold in the US for business has it installed. 
While I personally find Apple iCal to be a very neat and elegant
application, it's overall market-share is relatively small.

---

From: gsexton at mhsoftware.com (George Sexton)
Date: Fri Jul 28 08:19:49 2006

Nobody is suggesting moving the standard toward a particular implementation.

I am saying that removing existing functionality, that would be 
necessary for good inter-operation with the number 1 market share 
program would be a bad idea.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Jul 31 01:38:06 2006

Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault:
> - Any calendar that is exported, 
> with the intent to import it into a personal calendar application 

This requires that all information can be preserved. 

> #1. ?Only one recurrence rule per RRULE
>
> #2. No EXRULE

Okay. The definition of EXRULE is unclear anyway (e.g. is the dtstart always 
excluded by the exrule?) and multiple RRULEs are hardly ever needed.

> #3. ?No FREQ = SECONDLY, MINUTELY and HOURLY.

KAlarm is an alarm application that uses iCalendar to store the alarms (with 
lots of the recurrence parts available in rfc 2445) and also provides the 
alarms in iCalendar format for use in calendaring applications. This has the 
nice advantage, that your alarms also appear in your calendar without any 
extra work.

> #4. ?No BYSECOND, BYMINUTE, BYHOUR, BYYEARDAY, BYWEEKNO and BYSETPOS.

second, minute and hour are needed when you have FREQ=SECONDLY|MINUTELY|
HOURLY. Byyearday can be removed, BYWEEKNO are needed e.g. for tax deadlines, 
that have to be filed in week #something. 

> #7. ?MUST NOT have more than one of any kind of clause (INTERVAL, UNTIL,
> COUNT, BYDAY, BYMONTHDAY, BYMONTH)

But each of them can have multiple values? e.g. BYDAY=MO,WE,FR  for my math 
course or BYDAY=MO,WE for my choir rehearsals?

> #9. MUST use the canonical ordering of clauses. Frequency obviously comes
> first, then INTERVAL (required?) then UNTIL or COUNT (optional?) then
> BYDAY, BMONTHDAY and BYMONTH (with the combination restrictions above)

The order inside the vevent is irrelevant (you need to parse the whole 
icalendar file before you start evaluating anything anyway, as the VERSION 
property might come only in the very last line, and inside a VEVENT, the 
DTSTART might be last, too...), only the order in which they are evaluated 
matters. rfc 2445 tells you that order (but the description is confusing in 
some aspects).

> #10. ?MUST include the INTERVAL

Why? If no interval is given, INTERVAL=1 is the natural choice. I don't see a 
reason to include redundant information.

> nthweekday = ("1" / "2" / "3" / "4" / "5" / "-1" ) weekday

In our church, service is on every second to last saturday...

> REMOVING HOURLY: This makes simplified recurrence rules less useful for
> some kinds of repetitive tasks, particularly automated tasks. ?Let's
> consider this a separate kind of application, as it doesn't affect VEVENTs
> in interpersonal scheduling.

Okay, so you are talking about restricting icalendar usage for rfc 2446? RFC 
2445 is not only about interpersonal scheduling, but about general data 
exchange. E.g. between an alarm application and you calendar application.

> Apple's iCal doesn't create BYWEEKNO. ?It only uses BYMONTH with a possible
> modifier of BYDAY. ?So instead of a rule of
> "RRULE:FREQ=YEARLY;BYWEEKNO=7;BYDAY=FR", an Apple iCal user would have to
> generate "RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=3FR"

That's not the same date!
In 2004, friday of week #7 is February 13, but that is only the second friday 
in February.

> REMOVING BYSETPOS:
>
> An example supposed to be "Last weekday of March":
> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR;BYMONTH=3;BYSETPOS=-1;WKS
>T=SU
>
> iCal just can't recreate this. ?

But it does understand it? 

> Is there an alternative? ?Could we specify a special BYDAY code for "A
> weekday" in order to make this work? ?

No, because for this you have to define what a "weekday" is. In most western 
countries that's mon-fri, but in others it's not... 

Cheers,
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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Jul 31 17:17:30 2006

I really thought someone else had proposed what I'm about to post, but in an
attempt to search the archives I couldn't find it.  And, this contradicts my
earlier view about not adding components if it can be helped - but maybe in
this case it would help?

What about a recurrence component that had two parts - this might be an
actual component, perhaps REVENT (Recurring EVENT) - part A contains the
recurrence dates and times for all of the events in the set ; part B
contains the rules used to generate them.

Simple Example:
REVENT: BEGIN
UID: [email-masked]
RDATE; VALUE=DATE: 20060101, 20060201, 20060301, 20060401, 20060501,
20060601,
 20060701,20060801,20060901,20061001,20061101,20061201
DTSTART;VALUE=DATE: 20060101
RRULE; VALUE=DATE: DTSTART=20060101;FREQ=MONTHLY;COUNT=12;BYMONTHDAY=1
REVENT: END

I've put DTSTART as a separate property and as a parameter on RRULE - I
think the second is a little more "user-friendly" for people reading the
actual text file, but either will work for this purpose.

Clients which cannot handle the RRULEs sent merely store the REVENT and use
the RDATES to update the calendar; the UID identifies the unique REVENT, and
is stored with each instance to link it back to the REVENT if necessary. If
forwarding or delegating something, use the UID of an instance to retrieve
the REVENT and send it along.

I'm sure there are some holes in this - but it seems to me to allow us to
keep the RRULEs closer to what they are now, while requiring implementations
to "spell it out" for those other guys that don't understand the RRULES that
were sent.
This also means that the interpretation of the RRULEs is up to the sender:
The RDATEs sent must match the RRULEs expansion; if they don't then the
sender has committed an error. Clients that _can_ parse the RRULEs can
perform that check if they wish - and throw an exception or whatever if the
two aren't identical.

This does eliminate the use of an infinite recurrence; but I think we were
going to eliminate that anyway weren't we?

This also shouldn't be a huge code-change burden on current implementations,
since they're already creating most of this under a VEVENT, they may just
need to add the RDATE expansion to what they send/store and change
VEVENT:BEGIN/END to REVENT:BEGIN/END if something in the local store has
recurrence.

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Sunday, July 30, 2006 7:25 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal
calendarGUIs

second, minute and hour are needed when you have FREQ=SECONDLY|MINUTELY|
HOURLY. Byyearday can be removed, BYWEEKNO are needed e.g. for tax
deadlines, that have to be filed in week #something. 

> #10. ?MUST include the INTERVAL

Why? If no interval is given, INTERVAL=1 is the natural choice. I don't see
a 
reason to include redundant information.

That's not the same date!
In 2004, friday of week #7 is February 13, but that is only the second
friday 
in February.

Cheers,
Reinhold

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Mon Jul 31 17:41:51 2006

On Jul 27, 2006, at 22:40, Cyrus Daboo wrote:
> In my opinion no matter what we do, we will always have clients  
> with different recurrence rule editing capability. What we need to  
> do is provide sensible guidance for clients telling them how they  
> should handle the case of a recurrence that is too complex for  
> their editor (the guidance would pretty much say 'you MUST handle  
> this case without data loss'). Also we should provide sensible  
> 'profiles' of recurrence rules for say mobile, simple desktop/web  
> and advanced desktop/web clients that suggest a sensible 'minimum'  
> editing capability for each.
+1

And in the context of CalDAV remember that even the _server_ might  
restrict the available recurrence patterns (why do you restrict that  
to the client ;-). In fact a common thing might be that the server  
requires an UNTIL (because it flattenes cycles).
So some kind of status code for this situation would be quite  
nice ... (well, could be 501, but clients should be prepared).

Whats so hard about displaying a warning in the client that it  
doesn't support the rrule stored at the server? He would need to do  
the same thing for iCalendar imports etc anyway. I doubt that this  
gives practical issues.

I also very much like the idea of defining 'profiles' to outline the  
restrictions of clients.

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Tue, 1 Aug 2006 02:40:35 +0200
To: IETF-iCalendar <[email-masked]>

On Jul 27, 2006, at 22:40, Cyrus Daboo wrote:
> In my opinion no matter what we do, we will always have clients  
> with different recurrence rule editing capability. What we need to  
> do is provide sensible guidance for clients telling them how they  
> should handle the case of a recurrence that is too complex for  
> their editor (the guidance would pretty much say 'you MUST handle  
> this case without data loss'). Also we should provide sensible  
> 'profiles' of recurrence rules for say mobile, simple desktop/web  
> and advanced desktop/web clients that suggest a sensible 'minimum'  
> editing capability for each.
+1

And in the context of CalDAV remember that even the _server_ might  
restrict the available recurrence patterns (why do you restrict that  
to the client ;-). In fact a common thing might be that the server  
requires an UNTIL (because it flattenes cycles).
So some kind of status code for this situation would be quite  
nice ... (well, could be 501, but clients should be prepared).

Whats so hard about displaying a warning in the client that it  
doesn't support the rrule stored at the server? He would need to do  
the same thing for iCalendar imports etc anyway. I doubt that this  
gives practical issues.

I also very much like the idea of defining 'profiles' to outline the  
restrictions of clients.

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/

From: "Tim Hare" <[email-masked]>
To: <[email-masked]>
Date: Mon, 31 Jul 2006 20:17:20 -0400
Subject: [Ietf-calsify] RRULE proposal

I really thought someone else had proposed what I'm about to post, but =
in an
attempt to search the archives I couldn't find it.  And, this =
contradicts my
earlier view about not adding components if it can be helped - but maybe =
in
this case it would help?

Simple Example:
REVENT: BEGIN
UID: [email-masked]
RDATE; VALUE=3DDATE: 20060101, 20060201, 20060301, 20060401, 20060501,
20060601,
 20060701,20060801,20060901,20061001,20061101,20061201
DTSTART;VALUE=3DDATE: 20060101
RRULE; VALUE=3DDATE: =
DTSTART=3D20060101;FREQ=3DMONTHLY;COUNT=3D12;BYMONTHDAY=3D1
REVENT: END

Clients which cannot handle the RRULEs sent merely store the REVENT and =
use
the RDATES to update the calendar; the UID identifies the unique REVENT, =
and
is stored with each instance to link it back to the REVENT if necessary. =
If
forwarding or delegating something, use the UID of an instance to =
retrieve
the REVENT and send it along.

I'm sure there are some holes in this - but it seems to me to allow us =
to
keep the RRULEs closer to what they are now, while requiring =
implementations
to "spell it out" for those other guys that don't understand the RRULES =
that
were sent.
This also means that the interpretation of the RRULEs is up to the =
sender:
The RDATEs sent must match the RRULEs expansion; if they don't then the
sender has committed an error. Clients that _can_ parse the RRULEs can
perform that check if they wish - and throw an exception or whatever if =
the
two aren't identical.

This does eliminate the use of an infinite recurrence; but I think we =
were
going to eliminate that anyway weren't we?

This also shouldn't be a huge code-change burden on current =
implementations,
since they're already creating most of this under a VEVENT, they may =
just
need to add the RDATE expansion to what they send/store and change
VEVENT:BEGIN/END to REVENT:BEGIN/END if something in the local store has
recurrence.

Tim Hare

-----Original Message-----

Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault:
> These RRULE simplifications are intended for VEVENTS (not necessarily=20
> timezones or tasks) in the context of:

This requires that all information can be preserved.=20

> #1. =A0Only one recurrence rule per RRULE
>
> #2. No EXRULE

Okay. The definition of EXRULE is unclear anyway (e.g. is the dtstart =
always
excluded by the exrule?) and multiple RRULEs are hardly ever needed.

> #3. =A0No FREQ =3D SECONDLY, MINUTELY and HOURLY.

KAlarm is an alarm application that uses iCalendar to store the alarms =
(with
lots of the recurrence parts available in rfc 2445) and also provides =
the
alarms in iCalendar format for use in calendaring applications. This has =
the
nice advantage, that your alarms also appear in your calendar without =
any
extra work.

> #4. =A0No BYSECOND, BYMINUTE, BYHOUR, BYYEARDAY, BYWEEKNO and =
BYSETPOS.

second, minute and hour are needed when you have =
FREQ=3DSECONDLY|MINUTELY|
HOURLY. Byyearday can be removed, BYWEEKNO are needed e.g. for tax
deadlines, that have to be filed in week #something.=20

> #7. =A0MUST NOT have more than one of any kind of clause (INTERVAL, =
UNTIL,
> COUNT, BYDAY, BYMONTHDAY, BYMONTH)

But each of them can have multiple values? e.g. BYDAY=3DMO,WE,FR  for my =
math=20
course or BYDAY=3DMO,WE for my choir rehearsals?

> #9. MUST use the canonical ordering of clauses. Frequency obviously =
comes
> BYDAY, BMONTHDAY and BYMONTH (with the combination restrictions above)

The order inside the vevent is irrelevant (you need to parse the whole=20
icalendar file before you start evaluating anything anyway, as the =
VERSION=20
property might come only in the very last line, and inside a VEVENT, the =

DTSTART might be last, too...), only the order in which they are =
evaluated=20
matters. rfc 2445 tells you that order (but the description is confusing =
in=20
some aspects).

> #10. =A0MUST include the INTERVAL

Why? If no interval is given, INTERVAL=3D1 is the natural choice. I =
don't see
a=20
reason to include redundant information.

> nthweekday =3D ("1" / "2" / "3" / "4" / "5" / "-1" ) weekday

> REMOVING HOURLY: This makes simplified recurrence rules less useful =
for
> some kinds of repetitive tasks, particularly automated tasks. =A0Let's
> consider this a separate kind of application, as it doesn't affect =
VEVENTs
> in interpersonal scheduling.

Okay, so you are talking about restricting icalendar usage for rfc 2446? =
RFC

2445 is not only about interpersonal scheduling, but about general data=20
exchange. E.g. between an alarm application and you calendar =
application.

> REMOVING BYWEEKNO:
>
> An example: RRULE:FREQ=3DYEARLY;BYWEEKNO=3D1;BYDAY=3D5SU
> Apple's iCal doesn't create BYWEEKNO. =A0It only uses BYMONTH with a
possible
> modifier of BYDAY. =A0So instead of a rule of
> "RRULE:FREQ=3DYEARLY;BYWEEKNO=3D7;BYDAY=3DFR", an Apple iCal user =
would have to
> generate "RRULE:FREQ=3DYEARLY;BYMONTH=3D2;BYDAY=3D3FR"

friday=20
in February.

> An example supposed to be "Last weekday of March":
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3DMO,TU,WE,TH,FR;BYMONTH=3D3;BYSET=
POS=3D-1;WKS
>T=3DSU
>
> iCal just can't recreate this. =A0

But it does understand it?=20

> Is there an alternative? =A0Could we specify a special BYDAY code for =
"A
> weekday" in order to make this work? =A0

No, because for this you have to define what a "weekday" is. In most =
western

countries that's mon-fri, but in others it's not...=20

Cheers,
Reinhold

--=20
 * Financial and Actuarial Mathematics, TU Wien, =
http://www.fam.tuwien.ac.at

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs
Date: Sun, 30 Jul 2006 13:24:42 +0200

Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault:
> These RRULE simplifications are intended for VEVENTS (not necessarily
> timezones or tasks) in the context of:=20
> - Any calendar that is exported,=20
> with the intent to import it into a personal calendar application=20

This requires that all information can be preserved.=20

> #1. =C2=A0Only one recurrence rule per RRULE
>
> #2. No EXRULE

Okay. The definition of EXRULE is unclear anyway (e.g. is the dtstart alway=
s=20
excluded by the exrule?) and multiple RRULEs are hardly ever needed.

> #3. =C2=A0No FREQ =3D SECONDLY, MINUTELY and HOURLY.

KAlarm is an alarm application that uses iCalendar to store the alarms (wit=
h=20
lots of the recurrence parts available in rfc 2445) and also provides the=20
alarms in iCalendar format for use in calendaring applications. This has th=
e=20
nice advantage, that your alarms also appear in your calendar without any=20
extra work.

> #4. =C2=A0No BYSECOND, BYMINUTE, BYHOUR, BYYEARDAY, BYWEEKNO and BYSETPOS.

second, minute and hour are needed when you have FREQ=3DSECONDLY|MINUTELY|
HOURLY. Byyearday can be removed, BYWEEKNO are needed e.g. for tax deadline=
s,=20
that have to be filed in week #something.=20

> #7. =C2=A0MUST NOT have more than one of any kind of clause (INTERVAL, UN=
TIL,
> COUNT, BYDAY, BYMONTHDAY, BYMONTH)

But each of them can have multiple values? e.g. BYDAY=3DMO,WE,FR  for my ma=
th=20
course or BYDAY=3DMO,WE for my choir rehearsals?

> BYDAY, BMONTHDAY and BYMONTH (with the combination restrictions above)

The order inside the vevent is irrelevant (you need to parse the whole=20
icalendar file before you start evaluating anything anyway, as the VERSION=
=20
property might come only in the very last line, and inside a VEVENT, the=20
DTSTART might be last, too...), only the order in which they are evaluated=
=20
matters. rfc 2445 tells you that order (but the description is confusing in=
=20
some aspects).

> #10. =C2=A0MUST include the INTERVAL

Why? If no interval is given, INTERVAL=3D1 is the natural choice. I don't s=
ee a=20
reason to include redundant information.

> nthweekday =3D ("1" / "2" / "3" / "4" / "5" / "-1" ) weekday

> some kinds of repetitive tasks, particularly automated tasks. =C2=A0Let's

Okay, so you are talking about restricting icalendar usage for rfc 2446? RF=
C=20
2445 is not only about interpersonal scheduling, but about general data=20
exchange. E.g. between an alarm application and you calendar application.

> REMOVING BYWEEKNO:
>
> An example: RRULE:FREQ=3DYEARLY;BYWEEKNO=3D1;BYDAY=3D5SU
> Apple's iCal doesn't create BYWEEKNO. =C2=A0It only uses BYMONTH with a p=
ossible
> modifier of BYDAY. =C2=A0So instead of a rule of
> "RRULE:FREQ=3DYEARLY;BYWEEKNO=3D7;BYDAY=3DFR", an Apple iCal user would h=
ave to
> generate "RRULE:FREQ=3DYEARLY;BYMONTH=3D2;BYDAY=3D3FR"

That's not the same date!
In 2004, friday of week #7 is February 13, but that is only the second frid=
ay=20
in February.

> RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3DMO,TU,WE,TH,FR;BYMONTH=3D3;BYSET=
POS=3D-1;WKS
>T=3DSU
>
> iCal just can't recreate this. =C2=A0

But it does understand it?=20

> Is there an alternative? =C2=A0Could we specify a special BYDAY code for =
"A
> weekday" in order to make this work? =C2=A0

No, because for this you have to define what a "weekday" is. In most wester=
n=20
countries that's mon-fri, but in others it's not...=20

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------

Date: Fri, 28 Jul 2006 09:19:43 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: 'IETF-iCalendar' <[email-masked]>

From: "Tim Hare" <[email-masked]>
To: "'IETF-iCalendar'" <[email-masked]>
Subject: RE: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Fri, 28 Jul 2006 00:26:56 -0400

Tim Hare

-----Original Message-----

Ours does.

Date: Thu, 27 Jul 2006 16:40:06 -0400
From: Cyrus Daboo <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: IETF-iCalendar <[email-masked]>

Hi George,

-- 
Cyrus Daboo

Date: Thu, 27 Jul 2006 14:18:10 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: IETF-iCalendar <[email-masked]>

Ours does.

From: Aki Niemi <[email-masked]>
To: Calsify <[email-masked]>
Organization: Nokia-NRC/Helsinki
Date: Thu, 27 Jul 2006 22:43:58 +0300
Subject: [Ietf-calsify] Draft minutes from =?iso-8859-1?q?Montr=E9al?= posted

All,

Draft minutes of the IETF66 meeting have been posted:

http://www3.ietf.org/proceedings/06jul/minutes/calsify.txt

Please check them out, and in case you have something to add, send
email. Any comments are welcome.

As for individuals present at the meeting, please check the action items
as a reminder of the agreed actions.

-- 
Aki Niemi
Nokia Research Center

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Thu, 27 Jul 2006 11:25:23 -0700
To: George Sexton <[email-masked]>
Cc: IETF-iCalendar <[email-masked]>

Lisa

>>> to indicate WD so that the syntax would be

From: "Chris Bryant" <[email-masked]>
To: "George Sexton" <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Thu, 27 Jul 2006 13:36:45 -0400
Organization: USA.NET
Z-USANET-MsgId: XID866kgARKU0390X36
Cc: IETF-iCalendar <[email-masked]>

George,

Chris

----- Original Message ----- 
From: "George Sexton" <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal 
calendarGUIs
> indicate WD so that the syntax would be

Date: Thu, 27 Jul 2006 11:52:36 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Chris Bryant <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: IETF-iCalendar <[email-masked]>

You're right. I'm wrong.

Date: Thu, 27 Jul 2006 10:00:49 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: IETF-iCalendar <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar - Possibly relevant information
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------020005030904000206010302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------020005030904000206010302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Two documents developed by CalConnect may have some relevance to this
discussion.&nbsp; Both were developed in consideration of the Calsify
process.<br>
<br>
The first is the Recurrence Problems and Recommendations document,
developed by the Recurrence Technical Committee. This was more of an
attempt to fix what is there now to give better interoperability,
rather than do 'personal calendar simplification' as such.&nbsp; However the
two approaches share some elements in common.&nbsp; Additionally this
document addresses iTIP, which wasn't considered in the original post
on this subject.&nbsp; The Recurrence document may be found at:<br>
<br>
<a
 href="http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf">http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf</a><br>
<br>
Secondly is the Minimum-Interoperability Use Cases document, developed
by the Usecase Technical Committee.&nbsp; This was an attempt to defiine a
minimum set of use cases which need to be supported to provide
sufficient interoperability to make an implementation reasonably
useful.&nbsp; This document may be found at:<br>
<br>
<a href="http://www.calconnect.org/publications/miniopusecasesv1.1.pdf">http://www.calconnect.org/publications/miniopusecasesv1.1.pdf</a><br>
<br>
Hope these will be of some use.<br>
<br>
Dave Thewlis<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------020005030904000206010302--

Date: Thu, 27 Jul 2006 10:00:38 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: IETF-iCalendar <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar - Possibly relevant information
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------000609030301060502040108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------000609030301060502040108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Two documents developed by CalConnect may have some relevance to this
discussion.&nbsp; Both were developed in consideration of the Calsify
process.<br>
<br>
The first is the Recurrence Problems and Recommendations document,
developed by the Recurrence Technical Committee. This was more of an
attempt to fix what is there now to give better interoperability,
rather than do 'personal calendar simplification' as such.&nbsp; However the
two approaches share some elements in common.&nbsp; Additionally this
document addresses iTIP, which wasn't considered in the original post
on this subject.&nbsp; The Recurrence document may be found at:<br>
<br>
<a
 href="http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf">http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf</a><br>
<br>
Secondly is the Minimum-Interoperability Use Cases document, developed
by the Usecase Technical Committee.&nbsp; This was an attempt to defiine a
minimum set of use cases which need to be supported to provide
sufficient interoperability to make an implementation reasonably
useful.&nbsp; This document may be found at:<br>
<br>
<a href="http://www.calconnect.org/publications/miniopusecasesv1.1.pdf">http://www.calconnect.org/publications/miniopusecasesv1.1.pdf</a><br>
<br>
Hope these will be of some use.<br>
<br>
Dave Thewlis<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------000609030301060502040108--

From: "Chris Bryant" <[email-masked]>
To: "Eliot Lear" <[email-masked]>, "George Sexton" <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Thu, 27 Jul 2006 12:01:07 -0400
Organization: USA.NET
Z-USANET-MsgId: XID192kgAqBi0427X29
Cc: 'IETF-iCalendar' <[email-masked]>

Chris

----- Original Message ----- 
From: "Eliot Lear" <[email-masked]>
To: "George Sexton" <[email-masked]>
Cc: "'IETF-iCalendar'" <[email-masked]>
Sent: Thursday, July 27, 2006 11:44 AM
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal 
calendarGUIs

> although sometimes circumscribing behavior is okay, such as what Lisa

Date: Thu, 27 Jul 2006 17:44:49 +0200
From: Eliot Lear <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: 'IETF-iCalendar' <[email-masked]>

[Chair hat off]

Eliot

Date: Thu, 27 Jul 2006 09:26:20 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: 'IETF-iCalendar' <[email-masked]>

From: "Chris Bryant" <[email-masked]>
To: "'IETF-iCalendar'" <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Thu, 27 Jul 2006 10:03:55 -0400
Organization: USA.NET
Z-USANET-MsgId: XID125kgAoD50369X38

Chris

----- Original Message ----- 

From: "Tim Hare" <[email-masked]>
To: "'IETF-iCalendar'" <[email-masked]>
Subject: RE: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Wed, 26 Jul 2006 20:38:18 -0400

Tim Hare

-----Original Message-----

Hi Chris,

--
Cyrus Daboo

Date: Wed, 26 Jul 2006 11:19:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Chris Bryant <[email-masked]>, George Sexton <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Cc: IETF-iCalendar <[email-masked]>

Hi Chris,

-- 
Cyrus Daboo

From: "Chris Bryant" <[email-masked]>
To: "George Sexton" <[email-masked]>, "Lisa Dusseault" <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs
Date: Wed, 26 Jul 2006 09:23:33 -0400
Organization: USA.NET
Z-USANET-MsgId: XID399kgZNXj0419X37
Cc: IETF-iCalendar <[email-masked]>

----- Original Message ----- 

Chris

Date: Wed, 26 Jul 2006 16:56:17 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: [Ietf-calsify] Re: current test data: NZ, US/Canada (iCal scripts)

This is a multi-part message in MIME format.
--------------040001060008080208090908
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

file as discussed ..

This shows examples of real-world complex rules for holiday logic (NZ,
and US/Canada).  Context is in breaking down the rules into elements for
listing within GUI (design as proposed).

I will zip the GUI elements up and forward them shortly.

  SoftDesign Group

--------------040001060008080208090908
Content-Type: application/vnd.oasis.opendocument.text;
	name="Sunbird - iCal convert.odt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="Sunbird - iCal convert.odt"

--------------040001060008080208090908--

To: Andrew N Dowden <[email-masked]>
From: Pat R Egen <[email-masked]>
Date: Wed, 26 Jul 2006 00:48:33 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] Re: current test data: NZ, US/Canada (iCal scripts)

This is a multipart message in MIME format.
--=_alternative 001A6A83852571B7_=
Content-Type: text/plain; charset="US-ASCII"

That was quick.  Thanks for forwarding them.   As for the Openoffice 
document, why don't you post it to the discussion group so all can see it.

Andrew said:
============
These files represent what is possible within  Mozilla Sunbird , so some
compromises have been made.

I also have the same data as an  OpenOffice (19kb, .odt) document in its
optimum form, against some future GUI that allows / supports better
functionality.  I can send this to your direct in this (or alternate)
format, or post to this discussion.

This ties in with proposed 'full function' GUI design posted to Mozilla
Sunbird forum.  Currently, Sunbird direction is to first support entry
level, and semi-skilled user.  Design available to anyone with interest
in assisting / providing higher standard for GUI review / edit of
'complex recurrence' rules.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652
--=_alternative 001A6A83852571B7_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">That was quick. &nbsp;Thanks for forwarding
them. &nbsp; As for the Openoffice document, why don't you post it to the
discussion group so all can see it.</font>
<br>
<br><font size=2 face="sans-serif">Andrew said:</font>
<br><font size=2 face="sans-serif">============</font>
<br><font size=2><tt>These files represent what is possible within &nbsp;Mozilla
Sunbird , so some<br>
compromises have been made.<br>
<br>
I also have the same data as an &nbsp;OpenOffice (19kb, .odt) document
in its<br>
optimum form, against some future GUI that allows / supports better<br>
functionality. &nbsp;I can send this to your direct in this (or alternate)<br>
format, or post to this discussion.<br>
<br>
This ties in with proposed 'full function' GUI design posted to Mozilla<br>
Sunbird forum. &nbsp;Currently, Sunbird direction is to first support entry<br>
level, and semi-skilled user. &nbsp;Design available to anyone with interest<br>
in assisting / providing higher standard for GUI review / edit of<br>
'complex recurrence' rules.</tt></font>
<br><font size=2 face="sans-serif">___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
--=_alternative 001A6A83852571B7_=--

Date: Tue, 25 Jul 2006 21:42:38 -0600
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs
Cc: IETF-iCalendar <[email-masked]>

RDATE

BYDAY=-1WD

X-Http_host: webmail.rpi.edu
Date: Tue, 25 Jul 2006 23:21:49 -0400
Organization: Rensselaer Polytechnic Institute
Subject: Re: [Ietf-calsify] RRULE simplificatiion
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]

I don't believe the lack of use of rfc2445 in automation says anything
about the desirability. RFC2445 doesn't seem to be used in many areas
where it seems to be an obvious candidate - some room scheduling systems
for example.

I would much rather use a calendar to schedule events than cron.

The problem with creating a set of VEVENTS is that updates become a
problem. What if I want to change the description? In general how do I
determine which events to change?

However...

I do agree with the analysis as regards human interaction.

Rather than attempting to change RRULE and EXRULE would it not be better
to define new rules, perhaps with a different syntax, designed
specifically for human interaction - RECRULE and ???

It might even be possible to define a transformation from RECRULE to RRULE.

No mixing of RRULE and RECRULE would be allowed in VEVENTs.

Timezones still work - the new replacement for cron still might happen.

==============Original message text===============
On Tue, 25 Jul 2006 22:21:41 EDT "Tim Hare" wrote:

Not only do I agree with this analysis (remembering in this context I am not
a developer but a user of calendar software), but I could agree with further
simplifications. In particular I don't see a problem with clients creating a
set of VEVENTS with RRULEs to express some set of recurrences, rather than
adding to the complexity of syntax for one VEVENT/RRULE. 

Your Yahoo quilting group example reflects, also, what would  show up in a
usability study for most calendaring software: if a set of recurrences is
too hard to comprehend or express in one interaction, a user will use more
than one. Therefore I believe we can get by with simpler RRULEs because
people will use their client to create more than one VEVENT with rules that
they can understand.

I also believe that we could eliminate considerations for automation tools -
does anyone know of an automation implementation which uses RFC 2445 at all?
Most that I am aware of use something proprietary (as I believe Microsoft
Windows' Task Scheduler does and certainly the tools on our mainframe do),
or they use the Unix cron table formats. The amount of developed code using
these interfaces means that they're not going away any time soon and that
developers already have tools to use them for automation.

Tim Hare
Interested Bystander, Non-Inc.
===========End of original message text===========

From: "Tim Hare" <[email-masked]>
To: "'ietf-calsify'" <[email-masked]>
Date: Tue, 25 Jul 2006 22:21:41 -0400
Subject: [Ietf-calsify] RRULE simplificatiion

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C6B038.B4759620
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Not only do I agree with this analysis (remembering in this context I am not
a developer but a user of calendar software), but I could agree with further
simplifications. In particular I don't see a problem with clients creating a
set of VEVENTS with RRULEs to express some set of recurrences, rather than
adding to the complexity of syntax for one VEVENT/RRULE. 

Your Yahoo quilting group example reflects, also, what would  show up in a
usability study for most calendaring software: if a set of recurrences is
too hard to comprehend or express in one interaction, a user will use more
than one. Therefore I believe we can get by with simpler RRULEs because
people will use their client to create more than one VEVENT with rules that
they can understand.

I also believe that we could eliminate considerations for automation tools -
does anyone know of an automation implementation which uses RFC 2445 at all?
Most that I am aware of use something proprietary (as I believe Microsoft
Windows' Task Scheduler does and certainly the tools on our mainframe do),
or they use the Unix cron table formats. The amount of developed code using
these interfaces means that they're not going away any time soon and that
developers already have tools to use them for automation.

Tim Hare

------=_NextPart_000_0024_01C6B038.B4759620
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>RRULE simplificatiion</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Not only do I agree with this analysis =
(remembering in this context I am not a developer but a user of calendar =
software), but I could agree with further simplifications. In particular =
I don't see a problem with clients creating a set of VEVENTS with RRULEs =
to express some set of recurrences, rather than adding to the complexity =
of syntax for one VEVENT/RRULE. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Your Yahoo quilting group example =
reflects, also, what would&nbsp; show up in a usability study for most =
calendaring software: if a set of recurrences is too hard to comprehend =
or express in one interaction, a user will use more than one. Therefore =
I believe we can get by with simpler RRULEs because people will use =
their client to create more than one VEVENT with rules that they can =
understand.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I also believe that we could eliminate =
considerations for automation tools - does anyone know of an automation =
implementation which uses RFC 2445 at all? Most that I am aware of use =
something proprietary (as I believe Microsoft Windows' Task Scheduler =
does and certainly the tools on our mainframe do), or they use the Unix =
cron table formats. The amount of developed code using these interfaces =
means that they're not going away any time soon and that developers =
already have tools to use them for automation.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tim Hare</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Interested Bystander, Non-Inc.</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0024_01C6B038.B4759620--

Date: Wed, 26 Jul 2006 13:59:10 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: Patricia Egen <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] current test data: NZ, US/Canada (iCal scripts)

This is a multi-part message in MIME format.
--------------060401080206090305060903
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

These files represent what is possible within  Mozilla Sunbird , so some
compromises have been made.

I also have the same data as an  OpenOffice (19kb, .odt) document in its
optimum form, against some future GUI that allows / supports better
functionality.  I can send this to your direct in this (or alternate)
format, or post to this discussion.

This ties in with proposed 'full function' GUI design posted to Mozilla
Sunbird forum.  Currently, Sunbird direction is to first support entry
level, and semi-skilled user.  Design available to anyone with interest
in assisting / providing higher standard for GUI review / edit of
'complex recurrence' rules.

  SoftDesign Group

--------------060401080206090305060903
Content-Type: text/plain;
 name="NZ-Lunar2006.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NZ-Lunar2006.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
METHOD:PUBLISH
BEGIN:VEVENT
CREATED:20060324T104216Z
LAST-MODIFIED:20060324T104216Z
DTSTAMP:20060324T104216Z
UID:uuid:20060323T120000Z-30101-002
SUMMARY:Full Moon
DESCRIPTION:Lunar Cycle
CATEGORIES:Lunar
STATUS:CONFIRMED
CLASS:PUBLIC
RDATE;VALUE=DATE:20060114,20060213,20060315,20060414,20060513,20060612,20060711,20060809,20060908,20061007,20061106,20061205
DTSTART;VALUE=DATE:20060114
DTEND;VALUE=DATE:20060115
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T104216Z
LAST-MODIFIED:20060324T104216Z
DTSTAMP:20060324T104216Z
UID:uuid:20060323T120000Z-30102-002
SUMMARY:New Moon
DESCRIPTION:Lunar Cycle
CATEGORIES:Lunar
STATUS:CONFIRMED
CLASS:PUBLIC
RDATE;VALUE=DATE:20060130,20060228,20060329,20060428,20060527,20060626,20060725,20060824,20060922,20061022,20061121,20061221
DTSTART;VALUE=DATE:20060130
DTEND;VALUE=DATE:20060131
END:VEVENT
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="NZ-Holidays2005-2012.r008.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NZ-Holidays2005-2012.r008.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
METHOD:PUBLISH
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:New Year Holiday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed first 2 weekdays on after 1st January
RDATE;VALUE=DATE:20050103,20060102,20070101,20080101,20090101,20100101,20110103,20120102
DTSTART;VALUE=DATE:20050103
DTEND;VALUE=DATE:20050105
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:Waitangi Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 6th February, weekdays ONLY
RRULE:FREQ=YEARLY;BYMONTH=2;BYMONTHDAY=6;BYDAY=MO,TU,WE,TH,FR;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050206
DTEND;VALUE=DATE:20050207
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:Good Friday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Religious Calendar (Western)
RDATE;VALUE=DATE:20050325,20060414,20070406,20080321,20090410,20100402,20110422,20120406
DTSTART;VALUE=DATE:20050325
DTEND;VALUE=DATE:20050326
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:Easter Monday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Religious Calendar (Western)
RDATE;VALUE=DATE:20050328,20060417,20070409,20080324,20090413,20100405,20110425,20120409
DTSTART;VALUE=DATE:20050328
DTEND;VALUE=DATE:20050329
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:ANZAC Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 25th April
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050425
DTEND;VALUE=DATE:20050426
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:Queen's Birthday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 1st Monday in June
RRULE:FREQ=YEARLY;BYMONTH=6;BYDAY=1MO;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050606
DTEND;VALUE=DATE:20050607
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:Labour Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 4th Monday in October
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=4MO;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20051024
DTEND;VALUE=DATE:20051025
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231323Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231323Z
UID:[email-masked]
SUMMARY:Christmas Holiday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed first 2 weekdays on after 25 December
RDATE;VALUE=DATE:20051226,20061225,20071225,20081225,20091225,20101227,20111226,20121225
DTSTART;VALUE=DATE:20051226
DTEND;VALUE=DATE:20051228
END:VEVENT
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="NZ-Calendar2005-2012.r006.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NZ-Calendar2005-2012.r006.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
METHOD:PUBLISH
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:New Years Eve
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed midnight before 1st January
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20041231
DTEND;VALUE=DATE:20050101
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Waitangi Day
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 6th February
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050206
DTEND;VALUE=DATE:20050207
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Valentine's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 14th February
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050214
DTEND;VALUE=DATE:20050215
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:St. Patrick's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 17th March
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050317
DTEND;VALUE=DATE:20050318
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Autumnal Equinox
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around 21st March (astronomical)
RDATE;VALUE=DATE:20050320,20060320,20070321,20080320,20090320,20100320,20110320,20120320
DTSTART;VALUE=DATE:20050320
DTEND;VALUE=DATE:20050321
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Daylight Savings ends
DESCRIPTION:2:00am 3rd Sunday in March
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:2:00am 3rd Sunday in March
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=3SU;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050320
DTEND;VALUE=DATE:20050321
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:April Fool's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 1st April
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20050401
DTEND;VALUE=DATE:20050402
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Good Friday
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Religious Calendar (Western)
RDATE;VALUE=DATE:20050325,20060414,20070406,20080321,20090410,20100402,20110422,20120406
DTSTART;VALUE=DATE:20050325
DTEND;VALUE=DATE:20050326
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Easter Sunday
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Religious Calendar (Western)
RDATE;VALUE=DATE:20050327,20060416,20070408,20080323,20090412,20100404,20110424,20120408
DTSTART;VALUE=DATE:20050327
DTEND;VALUE=DATE:20050328
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Winter Solstice
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around 21st June (astronomical)
RDATE;VALUE=DATE:20050621,20060621,20070621,20080620,20090621,20100621,20110621,20120620
DTSTART;VALUE=DATE:20050621
DTEND;VALUE=DATE:20050622
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Vernal Equinox
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around 23rd September (astronomical)
RDATE;VALUE=DATE:20050922,20060923,20070923,20080922,20090922,20100923,20110923,20120922
DTSTART;VALUE=DATE:20050922
DTEND;VALUE=DATE:20050923
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Daylight Savings begins
DESCRIPTION:2:00am first Sunday in October
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:2:00am first Sunday in October
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20051002
DTEND;VALUE=DATE:20051003
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Summer Solstice
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around 21st December (astronomical)
RDATE;VALUE=DATE:20051221,20061222,20071222,20081221,20091221,20101221,20111222,20121221
DTSTART;VALUE=DATE:20051221
DTEND;VALUE=DATE:20051222
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Christmas Day
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 25th December
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20051225
DTEND;VALUE=DATE:20051226
END:VEVENT
BEGIN:VEVENT
CREATED:20060428T231932Z
LAST-MODIFIED:20060510T020743Z
DTSTAMP:20060428T231932Z
UID:[email-masked]
SUMMARY:Boxing Day
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 26th December
RRULE:FREQ=YEARLY;UNTIL=20130101T120000Z
DTSTART;VALUE=DATE:20051226
DTEND;VALUE=DATE:20051227
END:VEVENT
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="NZ-Regional2005+.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NZ-Regional2005+.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
METHOD:PUBLISH
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30501-004
SUMMARY:Anniversary Day
LOCATION:Southland
DESCRIPTION:Observed 3rd Monday in January
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3MO
DTSTART;VALUE=DATE:20050117
DTEND;VALUE=DATE:20050118
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30502-004
SUMMARY:Anniversary Day
LOCATION:Wellington
DESCRIPTION:Observed 4th Monday in January
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=4MO
DTSTART;VALUE=DATE:20050124
DTEND;VALUE=DATE:20050125
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30503-004
SUMMARY:Anniversary Day
LOCATION:Auckland & Nelson
DESCRIPTION:Observed last Monday in January
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1MO
DTSTART;VALUE=DATE:20050131
DTEND;VALUE=DATE:20050201
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30504-004
SUMMARY:Anniversary Day
LOCATION:Taranaki
DESCRIPTION:Observed 2nd Monday in March
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=2MO
DTSTART;VALUE=DATE:20050314
DTEND;VALUE=DATE:20050315
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30505-004
SUMMARY:Anniversary Day
LOCATION:Otago
DESCRIPTION:Observed 3rd Monday in March
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3MO
DTSTART;VALUE=DATE:20050321
DTEND;VALUE=DATE:20050322
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30506-004
SUMMARY:Anniversary Day
LOCATION:South Canterbury
DESCRIPTION:Observed last Monday in September
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1MO
DTSTART;VALUE=DATE:20050926
DTEND;VALUE=DATE:20050927
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30507-004
SUMMARY:Anniversary Day
LOCATION:Hawkes Bay
DESCRIPTION:Observed 3rd Friday in October
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3FR
DTSTART;VALUE=DATE:20051021
DTEND;VALUE=DATE:20051022
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30508-004
SUMMARY:Anniversary Day
LOCATION:Marlborough
DESCRIPTION:Observed last Monday in October
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1MO
DTSTART;VALUE=DATE:20051031
DTEND;VALUE=DATE:20051101
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30509-004
SUMMARY:Anniversary Day
LOCATION:North & Central Canterbury
DESCRIPTION:Observed 3rd Friday in November
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=3FR
DTSTART;VALUE=DATE:20051121
DTEND;VALUE=DATE:20051122
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30510-004
SUMMARY:Anniversary Day
LOCATION:Chatham Islands
DESCRIPTION:Observed last Monday in November
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1MO
DTSTART;VALUE=DATE:20051128
DTEND;VALUE=DATE:20051129
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T161232Z
LAST-MODIFIED:20060324T161232Z
DTSTAMP:20060324T161232Z
UID:uuid:20060324T161232Z-30511-004
SUMMARY:Anniversary Day
LOCATION:Westland
DESCRIPTION:Observed 1st Monday in December
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=1MO
DTSTART;VALUE=DATE:20051205
DTEND;VALUE=DATE:20051206
END:VEVENT
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="NZ-Timezone2005-2021.r001.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NZ-Timezone2005-2021.r001.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
BEGIN:VTIMEZONE
CREATED:20060408T002709Z
LAST-MODIFIED:20060408T002709Z
DTSTAMP:20060408T002709Z
UID:uuid:20060408T002709Z-30901-001
TZID:Pacific/Auckland
BEGIN:DAYLIGHT
TZNAME:NZDT
COMMENT:2:00am 3rd Sunday in March
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=3SU;UNTIL=20121231
DTSTART;VALUE=DATE:20050320T020000
TZOFFSETFROM:+1200
TZOFFSETTO:+1300
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:NZST
COMMENT:2:00am first Sunday in October
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU;UNTIL=20121231
DTSTART;VALUE=DATE:20051002T020000
TZOFFSETFROM:+1300
TZOFFSETTO:+1200
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="US-Calendar2005-2012.r003.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="US-Calendar2005-2012.r003.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
METHOD:PUBLISH
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:New Year's Eve
DESCRIPTION:observed
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed midnight before January 1
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20041231
DTEND;VALUE=DATE:20050101
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Martin Luther King's Birthday
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed January 15
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050115
DTEND;VALUE=DATE:20050116
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Inauguration Day
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed every 4 years on January 20
RRULE:FREQ=YEARLY;INTERVAL=4;UNTIL=20121231
DTSTART;VALUE=DATE:20050120
DTEND;VALUE=DATE:20050121
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Groundhog Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed February 2
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050202
DTEND;VALUE=DATE:20050203
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Abraham Lincoln's Birthday
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed February 12
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050212
DTEND;VALUE=DATE:20050213
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Valentine's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed February 14
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050214
DTEND;VALUE=DATE:20050215
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:George Washington's Birthday
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed February 22
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050222
DTEND;VALUE=DATE:20050223
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:St. Patrick's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed March 17
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050317
DTEND;VALUE=DATE:20050318
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Vernal Equinox
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around March 21 (astronomical)
RDATE;VALUE=DATE:20050320,20060320,20070321,20080320,20090320,20100320,20110320,20120320
DTSTART;VALUE=DATE:20050320
DTEND;VALUE=DATE:20050321
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Good Friday
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Religious Calendar (Western)
RDATE;VALUE=DATE:20050325,20060414,20070406,20080321,20090410,20100402,20110422,20120406
DTSTART;VALUE=DATE:20050325
DTEND;VALUE=DATE:20050326
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Easter Sunday
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Religious Calendar (Western)
RDATE;VALUE=DATE:20050327,20060416,20070408,20080323,20090412,20100404,20110424,20120408
DTSTART;VALUE=DATE:20050327
DTEND;VALUE=DATE:20050328
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:April Fool's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed April 1
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050401
DTEND;VALUE=DATE:20050402
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Daylight Savings begins
DESCRIPTION:2:00am first Sunday in April
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:2:00am first Sunday in April, until 2007
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20070101
DTSTART;VALUE=DATE:20050403
DTEND;VALUE=DATE:20050404
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Daylight Savings begins
DESCRIPTION:2:00am second Sunday in March
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:2:00am second Sunday in March, from 2007
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU;UNTIL=20121231
DTSTART;VALUE=DATE:20070311
DTEND;VALUE=DATE:20070312
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Tax Day
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed April 15
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050415
DTEND;VALUE=DATE:20050416
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Earth Day
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed April 22
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050422
DTEND;VALUE=DATE:20050423
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Mother's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 2nd Sunday in May
RRULE:FREQ=YEARLY;BYMONTH=5;BYDAY=2SU;UNTIL=20121231
DTSTART;VALUE=DATE:20050508
DTEND;VALUE=DATE:20050509
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Armed Forces Day
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 3rd Saturday in May
RRULE:FREQ=YEARLY;BYMONTH=5;BYDAY=3SA;UNTIL=20121231
DTSTART;VALUE=DATE:20050521
DTEND;VALUE=DATE:20050522
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Flag Day
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed June 14
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050614
DTEND;VALUE=DATE:20050615
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Summer Solstice
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around June 21 (astronomical)
RDATE;VALUE=DATE:20050621,20060621,20070621,20080620,20090621,20100621,20110621,20120620
DTSTART;VALUE=DATE:20050621
DTEND;VALUE=DATE:20050622
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Father's Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 3rd Sunday in June
RRULE:FREQ=YEARLY;BYMONTH=6;BYDAY=3SU;UNTIL=20121231
DTSTART;VALUE=DATE:20050619
DTEND;VALUE=DATE:20050620
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Independence Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed July 4
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20050704
DTEND;VALUE=DATE:20050705
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Parents' Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 4th Sunday in July
RRULE:FREQ=YEARLY;BYMONTH=7;BYDAY=4SU;UNTIL=20121231
DTSTART;VALUE=DATE:20050724
DTEND;VALUE=DATE:20050725
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Autumnal Equinox
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around September 23 (astronomical)
RDATE;VALUE=DATE:20050922,20060923,20070923,20080922,20090922,20100923,20110923,20120922
DTSTART;VALUE=DATE:20050922
DTEND;VALUE=DATE:20050923
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Columbus Birthday
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed October 12
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20051012
DTEND;VALUE=DATE:20051013
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Daylight Savings ends
DESCRIPTION:2:00am last Sunday in October
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:2:00am last Sunday in October, until 2007
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20070101
DTSTART;VALUE=DATE:20051030
DTEND;VALUE=DATE:20051031
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Daylight Savings ends
DESCRIPTION:2:00am first Sunday in November
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:2:00am first Sunday in November, from 2007
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU;UNTIL=20121231
DTSTART;VALUE=DATE:20071104
DTEND;VALUE=DATE:20071105
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Halloween
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed October 31
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20051031
DTEND;VALUE=DATE:20051101
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Election Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed Tuesday after first Monday in November
RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,5,6,7,8;UNTIL=20121231
DTSTART;VALUE=DATE:20051108
DTEND;VALUE=DATE:20051109
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Veteran's Day
DESCRIPTION:actual
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed November 11
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20051111
DTEND;VALUE=DATE:20051112
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Winter Solstice
DESCRIPTION:actual
CATEGORIES:Miscellaneous
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Occurs around December 21 (astronomical)
RDATE;VALUE=DATE:20051221,20061222,20071222,20081221,20091221,20101221,20111222,20121221
DTSTART;VALUE=DATE:20051221
DTEND;VALUE=DATE:20051222
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T041928Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Christmas Day
DESCRIPTION:traditional
CATEGORIES:Anniversary
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed December 25
RRULE:FREQ=YEARLY;UNTIL=20121231
DTSTART;VALUE=DATE:20051225
DTEND;VALUE=DATE:20051226
END:VEVENT
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="US-Holidays2005-2012.r003.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="US-Holidays2005-2012.r003.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
METHOD:PUBLISH
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:New Year Holiday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed closest weekday to January 1
RRULE:FREQ=YEARLY;BYMONTH=1;BYMONTHDAY=1;BYDAY=MO,TU,WE,TH,FR
RRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=31;BYDAY=FR
RRULE:FREQ=YEARLY;BYMONTH=1;BYMONTHDAY=2;BYDAY=MO
DTSTART;VALUE=DATE:20041231
DTEND;VALUE=DATE:20050101
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Martin Luther King Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 3rd Monday in January
RRULE:FREQ=YEARLY;BYMONTH=1;BYDAY=3MO
DTSTART;VALUE=DATE:20050117
DTEND;VALUE=DATE:20050118
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:President's Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 3rd Monday in February
RRULE:FREQ=YEARLY;BYMONTH=2;BYDAY=3MO
DTSTART;VALUE=DATE:20050221
DTEND;VALUE=DATE:20050222
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Memorial Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed last Monday in May
RRULE:FREQ=YEARLY;BYMONTH=5;BYDAY=-1MO
DTSTART;VALUE=DATE:20050523
DTEND;VALUE=DATE:20050524
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Independence Holiday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed closest weekday to July 4
RRULE:FREQ=YEARLY;BYMONTH=7;BYMONTHDAY=4;BYDAY=MO,TU,WE,TH,FR
RRULE:FREQ=YEARLY;BYMONTH=7;BYMONTHDAY=3;BYDAY=FR
RRULE:FREQ=YEARLY;BYMONTH=7;BYMONTHDAY=5;BYDAY=MO
DTSTART;VALUE=DATE:20050704
DTEND;VALUE=DATE:20050705
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Labor Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed first Monday in September
RRULE:FREQ=YEARLY;BYMONTH=9;BYDAY=1MO
DTSTART;VALUE=DATE:20050905
DTEND;VALUE=DATE:20050906
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Columbus Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 2nd Monday in October
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=2MO
DTSTART;VALUE=DATE:20051010
DTEND;VALUE=DATE:20051011
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Veteran's Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed closest weekday to November 11
RRULE:FREQ=YEARLY;BYMONTH=11;BYMONTHDAY=11;BYDAY=MO,TU,WE,TH,FR
RRULE:FREQ=YEARLY;BYMONTH=11;BYMONTHDAY=10;BYDAY=FR
RRULE:FREQ=YEARLY;BYMONTH=11;BYMONTHDAY=12;BYDAY=MO
DTSTART;VALUE=DATE:20051111
DTEND;VALUE=DATE:20051112
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Thanksgiving Day
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed 4th Thursday in November
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=4TH
DTSTART;VALUE=DATE:20051124
DTEND;VALUE=DATE:20051125
END:VEVENT
BEGIN:VEVENT
CREATED:20060324T002217Z
LAST-MODIFIED:20060403T034554Z
DTSTAMP:20060324T002217Z
UID:uuid:[email-masked]
SUMMARY:Christmas Holiday
DESCRIPTION:holiday
CATEGORIES:Public Holiday
STATUS:CONFIRMED
CLASS:PUBLIC
COMMENT:Observed closest weekday to December 25 (U.S. & Canada)
RRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=25;BYDAY=MO,TU,WE,TH,FR
RRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=24;BYDAY=FR
RRULE:FREQ=YEARLY;BYMONTH=12;BYMONTHDAY=26;BYDAY=MO
DTSTART;VALUE=DATE:20051226
DTEND;VALUE=DATE:20051227
END:VEVENT
END:VCALENDAR

--------------060401080206090305060903
Content-Type: text/plain;
 name="US-Timezone.r001.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="US-Timezone.r001.ics"

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30801-001
TZID:US/Pacific
BEGIN:DAYLIGHT
TZNAME:PDT
RRULE:FREQ=YEARLY;BYDAY=1SU;UNTIL=20070101
DTSTART:20000402T020000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
RRULE:FREQ=YEARLY;BYDAY=-1SU;UNTIL=20070101
DTSTART:20001029T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30801-002
TZID:US/Pacific
BEGIN:DAYLIGHT
TZNAME:PDT
RRULE:FREQ=YEARLY;BYDAY=2SU
DTSTART:20070311T020000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
RRULE:FREQ=YEARLY;BYDAY=1SU
DTSTART:20071104T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30802-001
TZID:US/Mountain
BEGIN:DAYLIGHT
TZNAME:MDT
RRULE:FREQ=YEARLY;BYDAY=1SU;UNTIL=20070101
DTSTART:20000402T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:MST
RRULE:FREQ=YEARLY;BYDAY=-1SU;UNTIL=20070101
DTSTART:20001029T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30802-002
TZID:US/Mountain
BEGIN:DAYLIGHT
TZNAME:MDT
RRULE:FREQ=YEARLY;BYDAY=2SU
DTSTART:20070311T020000
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:MST
RRULE:FREQ=YEARLY;BYDAY=1SU
DTSTART:20071104T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30803-001
TZID:US/Central
BEGIN:DAYLIGHT
TZNAME:CDT
RRULE:FREQ=YEARLY;BYDAY=1SU;UNTIL=20070101
DTSTART:20000402T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CST
RRULE:FREQ=YEARLY;BYDAY=-1SU;UNTIL=20070101
DTSTART:20001029T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30803-002
TZID:US/Central
BEGIN:DAYLIGHT
TZNAME:CDT
RRULE:FREQ=YEARLY;BYDAY=2SU
DTSTART:20070311T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CST
RRULE:FREQ=YEARLY;BYDAY=1SU
DTSTART:20071104T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30804-001
TZID:US/Eastern
BEGIN:DAYLIGHT
TZNAME:EDT
RRULE:FREQ=YEARLY;BYDAY=1SU;UNTIL=20070101
DTSTART:20000402T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
RRULE:FREQ=YEARLY;BYDAY=-1SU;UNTIL=20070101
DTSTART:20001029T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
CREATED:20060401T091403Z
LAST-MODIFIED:20060401T103819Z
DTSTAMP:20060401T103813Z
UID:uuid:20060401T091403Z-30804-002
TZID:US/Eastern
BEGIN:DAYLIGHT
TZNAME:EDT
RRULE:FREQ=YEARLY;BYDAY=2SU
DTSTART:20070311T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
RRULE:FREQ=YEARLY;BYDAY=1SU
DTSTART:20071104T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

--------------060401080206090305060903--

From: Chuck Norris <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs
Date: Tue, 25 Jul 2006 18:50:46 -0700
To: Lisa Dusseault <[email-masked]>
Cc: IETF-iCalendar <[email-masked]>

Chuck

> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar	GUIs
From: Pat R Egen <[email-masked]>
Date: Tue, 25 Jul 2006 21:03:38 -0400
Cc: [email-masked], [email-masked]

This is a multipart message in MIME format.
--=_alternative 0005D326852571B7_=
Content-Type: text/plain; charset="US-ASCII"

To

Subject

  SoftDesign Group

--=_alternative 0005D326852571B7_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Andrew, I'd be interested in your set
of iCalendar files to use as part of our Calconnect Interoperability testing.</font>
<br><font size=2 face="sans-serif">___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Andrew N Dowden &lt;[email-masked]&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">07/25/2006 08:52 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">[email-masked]</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ietf-calsify] RRule simplification
for interpersonal calendar &nbsp; &nbsp; &nbsp; &nbsp;GUIs</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Lisa Dusseault wrote:<br>
&gt; I would like to consider whether RRules are too complicated for GUI<br>
&gt; display in our most common calendar client applications. &nbsp;If
I send a<br>
&gt; complex RRule event to you and your client can't display the RRule
in<br>
&gt; its GUI, you can only accept or reject the request, not modify it,
and<br>
&gt; possibly not even understand it well. &nbsp; Worse, if I'm using CalDAV
and<br>
&gt; one client creates a complex RRule but then I switch to another<br>
&gt; client, I risk having a recurring event that I can't manage. &nbsp;
Shared<br>
&gt; calendars are particularly subject to this problem.<br>
I have carried out similar research in the context of discussions /<br>
advise within the &nbsp;Mozilla Sunbird / Lightning &nbsp;project. &nbsp;It
will take a<br>
little time to review your submission, and respond. &nbsp;In general, I
agree<br>
some guidance on this issue (as it impact on GUI feature sets) it<br>
definitely required. &nbsp;I am unsure if your approach in necessarily
the<br>
best way to deal with this problem.<br>
<br>
More detailed comment to follow (time permitting) ..<br>
<br>
I also have a set of &nbsp;iCalendar &nbsp;files for NZ, US and Canada
public<br>
holidays, and other 'more complex' use of RRULE's that I have used as<br>
the basis for my &nbsp;GUI design &nbsp;proposals. &nbsp;They may also
be of interest<br>
in this discussion / thread.<br>
<br>
-- <br>
_______________________________________________<br>
<br>
 &nbsp;SoftDesign Group<br>
 &nbsp;Dowden Software Associates<br>
 &nbsp;P O Box 31 132, Lower Hutt 5040, NEW ZEALAND<br>
<br>
<br>
_______________________________________________<br>
Ietf-calsify mailing list<br>
[email-masked]<br>
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br>
</tt></font>
<br>
--=_alternative 0005D326852571B7_=--

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs
Date: Tue, 25 Jul 2006 18:01:46 -0700
To: Lisa Dusseault <[email-masked]>
Cc: IETF-iCalendar <[email-masked]>

On Jul 25, 2006, at 5:24 PM, Lisa Dusseault wrote:

> The kinds of RRules that I couldn't find "in the wild" or create, we=20=

Too much of RRULE in 2445 appears to have been designed to reach some=20
sort of mathematical completeness goal in terms of recurrence, instead=20=

of based on the actual 80/20 usage of recurring meetings in the real=20
world.

> I don't care if we repeat the exercise for some other GUI client or=20
> make changes on what some other GUI client can do; this first attempt=20=

> My personal opinion is that some kind of simplification is required=20
> for two big reasons:
> 	- To improve interoperability between clients that attempt to do =
a=20
> decent job of RRules
> 	- To encourage clients that currently don't do RRules (many =
mobile=20
> devices) to implement.  Let's meet them half-way with  recurrence=20
> functionality that's simple enough for them to implement, and if they=20=

> implement anything they're more likely to implement the whole set if=20=

> it's that simple.
>
> Besides GUI display concerns, I had a couple more minor reasons which=20=

Lisa, thanks very much for doing this research and analysis.  It was=20
very illuminating, and you have my support.

Thanks,

Tantek

--
Tantek =C7elik

Date: Wed, 26 Jul 2006 12:52:43 +1200
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs

  SoftDesign Group

To: IETF-iCalendar <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Tue, 25 Jul 2006 17:24:05 -0700
Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs

--Apple-Mail-5--527413468
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

--Apple-Mail-5--527413468
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; x-mac-type=2A2A2A2A; x-unix-mode=0644;
	x-mac-creator=48647261; name=recur-simplification.txt
Content-Disposition: attachment;
	filename=recur-simplification.txt

These RRULE simplifications are intended for VEVENTS (not necessarily =
timezones or tasks) in the context of:
 - Any calendar that is exported, with the intent to import it into a =
personal calendar application
 - Any interpersonal scheduling request
 - Any CalDAV calendar
=20
WHY?  It's not because it's impossible to write iCalendar libraries.  =
Instead I have a couple other concerns:

a) This is really the core concern: display of recurrence rules.  We =
could just use recurrence dates, except that we'd lose the functionality =
of one person modifying the recurrence pattern for a recurring event, =
and the functionality of quickly grasping the recurrence pattern when =
I'm invited to something.  If I'm accepting an invitation or modifying =
an event, it's crucial to understand quickly that  "This event is =
scheduled every other week except for Christmas" rather than have to =
grovel through actual recurrence dates.  Thus, I conclude that the =
ability to display a recurrence rule is crucial to the usefulness of =
recurrence rules in VEVENTS involving real people.  RRule uses which =
can't be displayed by the client are harmful to usability and =
interoperability.

b) Many combinations are meaningless, ambiguous or nearly so, even if we =
limit ourselves to clauses that are actually in common use.  Some =
examples to try to remove:
    FREQ=3DYEARLY;BYDAY=3DFR -- is this every friday? The first friday =
each year?
    FREQ=3DDAILY;BYMONTH=3D3=20
    FREQ=3DWEEKLY;BYDAY=3DFR;BYMONTHDAY=3D26
   =20
c) Some kinds of recurrences can be represented in more than one way.  =
It's an improvement in interoperability to *reduce* the number of =
options for representing a given recurrence.
    FREQ=3DDAILY;BYDAY=3DMO,WE,FR
    FREQ=3DWEEKLY;BYDAY=3DMO,WE,FR
   =20
d) We should have a model where we're clearly limiting or expanding =
recurrences with a BY* clause but not both.  The model is too complex =
when the evaluation is context-specific so we should fix this. =20
    FREQ=3DDAILY;BYDAY=3DMO,WE,FR -- this limits/filters occurrences, to =
less than the default DAILY
    FREQ=3DWEEKLY;BYDAY=3DMO,WE,FR -- this multiplies occurrences beyond =
the default WEEKLY
   =20
   =20
How do I know which recurrence features can be displayed?  I tested =
Apple's iCal,  Chandler, Yahoo and Google Calendar GUIs (and would =
welcome additional cases).  iCal is the most flexible of these across =
all possible rules, with the possible exception that Google has an =
"Every weekday" rule option that Apple could probably duplicate by =
letting the user pick checkboxes for MoTuWeThFr.  If we were really to =
go with lowest common denominator we could be even more brutal but I =
don't think we want to.
=20
FEATURES TO FORBID in VEVENT RRULES for display=20

#2. No EXRULE

#3.  No FREQ =3D SECONDLY, MINUTELY and HOURLY.

#5.  No WKST, because the rules that have a dependency on when the week =
starts are gone now.

COMBINATIONS TO REMOVE
=0D#6.  Fewer combinations of BY* clauses together, fewer combinations =
of a given frequency and inappropriate BY* clauses:
  * MUST NOT combine BYDAY and BYMONTHDAY.
  * MUST NOT combine DAILY frequency and ( BYDAY or BYMONTHDAY or =
BYMONTH)
  * MUST NOT combine WEEKLY frequency and BYMONTH
  * MUST NOT combine MONTHLY frequency and BYMONTH
  * MUST NOT combine YEARLY frequency and BYDAY unless there's also a =
BYMONTH
      (because "every year on the 52nd Monday" is too useless)

#7.  MUST NOT have more than one of any kind of clause (INTERVAL, UNTIL, =
COUNT, BYDAY, BYMONTHDAY, BYMONTH)

#8.  When the old "ordwk" was used (to specify the 3rd Friday or 1st =
monday), it didn't make sense with WEEKLY frequency.  When the old =
weekday stuff was used (e.g. every Tuesday and Thursday) it didn't make =
sense with monthly freqency or yearly.  Thus, split these two concepts =
into two and limit usage.=20

OTHER VARIATION TO REMOVE
 =20
#9. MUST use the canonical ordering of clauses. Frequency obviously =
comes first, then INTERVAL (required?) then UNTIL or COUNT (optional?) =
then BYDAY, BMONTHDAY and BYMONTH (with the combination restrictions =
above)

#11.  When specifying the "Nth weekday of a Month", only options are:
    1, 2, 3, 4, 5 and -1 =20
    (Thus remove option for "-4MO" or the fourth-to-last Monday of the =
month)
     Similarly, the only "ordmoday" that is negative is -1.
   =20
--------

RESULT:  An example of rewriting the ABNF completely with what you CAN =
have -- only the combinations that make sense.

recur     =3D "FREQ=3DDAILY" interval [ limit ]=20
          =3D/ "FREQ=3DWEEKLY" interval [ limit ] [ chooseweekday ]
          =3D/ "FREQ=3DMONTHLY" interval [ limit ] [ choosemonthday ]
          =3D/ "FREQ=3DYEARLY" interval [ limit ] [ choosemonth [ =
choosemonthday ] ]
             =20
interval  =3D ";" "INTERVAL" "=3D" 1*DIGIT=20

limit =3D ";" ( "UNTIL" "=3D" enddate ) / ( "COUNT" "=3D" 1*DIGIT ) =0D=0D=
chooseweekday =3D ";" ( "BYDAY" =3D weekdaylist )

choosemonthday =3D ";" ( "BYDAY" =3D nthweekdaylist ) =20
                 / ( "BYMONTHDAY" =3D monthdaylist)

choosemonth =3D ";" "BYMONTH" =3D bymolist

enddate    =3D date=0Denddate    =3D/ date-time            ;An UTC value=0D=
=0Dweekdaylist =3D weekday [ *("," weekday) ]

nthweekdaylist =3D nthweekday [ *("," nthweekday) ]=20

nthweekday =3D ("1" / "2" / "3" / "4" / "5" / "-1" ) weekday =0D

weekday    =3D "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"=0D     =
;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,=0D     =
;FRIDAY, SATURDAY and SUNDAY days of the week.=0D=0Dmonthdaylist =3D =
monthdaynum / ( monthdaynum *("," monthdaynum) )=0D=0Dmonthdaynum =3D =
("+" ordmoday) / ( "-1" )=0D=0Dordmoday   =3D 1DIGIT / 2DIGIT       ;1 =
to 31=0D

bymolist   =3D monthnum / ( monthnum *("," monthnum) )=0D
monthnum   =3D 1DIGIT / 2DIGIT       ;1 to 12=0D=0D=0D
    =20
--------
    =20
NOTES ON REDUCED FUNCTIONALITY

REMOVING HOURLY: This makes simplified recurrence rules less useful for =
some kinds of repetitive tasks, particularly automated tasks.  Let's =
consider this a separate kind of application, as it doesn't affect =
VEVENTs in interpersonal scheduling.

REMOVING BYHOUR:

With the removal of BYHOUR, some timezone rules don't work.  We need to =
make RRULE BYHOUR understood for timezones, but NOT for interpersonal =
scheduling.

There are examples of BYHOUR at =
<http://tipi.sourceforge.net/doc/recur/indexs01.html> but I've never =
seen this in actual interpersonal scheduling.

An example at <http://www.orafaq.com/node/862> uses BYHOUR but could =
express the same rule with the reduced syntax.

REMOVING BYYEARDAY:

An example: RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU;BYYEARDAY=3D72
This is pretty stupid.  Only leap years affect whether the 72nd day of =
the year is 31+28+13 =3D March 13 or 31+29+12 =3D March 12.  It's just =
not useful enough to schedule a meeting on "March 13, except March 12 if =
it's a leap year" and that kind of use case can be worked around.  (One =
special case might be to state that a RRULE that occured yearly on Feb =
29 might automatically recur on Feb 28 if not a leap year)  So without =
BYYEARDAY we'd see rules like "RRULE:FREQ=3DYEARLY; INTERVAL=3D1" and =
the date would be March 12 every year.

REMOVING BYWEEKNO:

An example: RRULE:FREQ=3DYEARLY;BYWEEKNO=3D1;BYDAY=3D5SU
This was crafted to show how combining BYWEEKNO with other BY* clauses =
generates non-sensical events.

Apple's iCal doesn't create BYWEEKNO.  It only uses BYMONTH with a =
possible modifier of BYDAY.  So instead of a rule of =
"RRULE:FREQ=3DYEARLY;BYWEEKNO=3D7;BYDAY=3DFR", an Apple iCal user would =
have to generate "RRULE:FREQ=3DYEARLY;BYMONTH=3D2;BYDAY=3D3FR"

REMOVING BYSETPOS:

An example supposed to be "Last weekday of March": =
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3DMO,TU,WE,TH,FR;BYMONTH=3D3;BYSETP=
OS=3D-1;WKST=3DSU

iCal just can't recreate this.  The closest iCal gets is "Every year on =
the last friday of March" which is =
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYMONTH=3D3;BYDAY=3D-1FR.  It's also =
true that iCal can't display this.

Is there an alternative?  Could we specify a special BYDAY code for "A =
weekday" in order to make this work?  E.g.
    RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYMONTH=3D3;BYDAY=3D-1WK

For better backward compatibility, another alternative is to require all =
clients to understand this one application of BYSETPOS, if at least some =
minimum number clients are willing to do the display work.

What about "Every April, I need to have a series of meetings that is =
every work day all month"?  In the old rules this could be:
    RRULE:FREQ=3DDAILY;BYMONTH=3D4;BYDAY=3DMO,TU,WE,TH,FR

With this simplification you just can't do that. The best a client could =
do is to create a "FREQ=3DDAILY;UNTIL=3D20060430;BYDAY=3DMO,TU,WE,TH,FR" =
from the beginning to the end of April, each year. =20

My quilting group actually meets every 4th saturday and every 4th =
tuesday evening, with the saturday offset from the tuesday meeting by =
being 2.5 weeks after the Tuesday meeting.  Our Yahoo group =
administrator actually put this on the Yahoo calendar by... creating *2* =
recurring events.  If Yahoo could express this in RRULE it would =
probably be two VEVENTS with something like
    DTSTART:20060523T193000
    RRULE:FREQ=3DWEEKLY;INTERVAL=3D4
    and
    DTSTART:20060610T193000
    RRULE:FREQ=3DWEEKLY;INTERVAL=3D4

--Apple-Mail-5--527413468
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Feedback?

thanks!
Lisa
--Apple-Mail-5--527413468--

To: [email-masked]
From: IESG Secretary <[email-masked]>
Date: Tue, 25 Jul 2006 16:00:01 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] WG Action: RECHARTER: Calendaring and Scheduling Standards Simplification (calsify) 

The charter of the Calendaring and Scheduling Standards Simplification 
(calsify) working group in the Applications Area of the IETF has been 
updated. For additional information, please contact the Area Directors or the 
working group Chairs.

+++

Calendaring and Scheduling Standards Simplification (calsify)
==============================================================

Current Status: Active Working Group

Chair(s):
Eliot Lear <[email-masked]>
Aki Niemi <[email-masked]>

Applications Area Director(s):
Ted Hardie <[email-masked]>
Lisa Dusseault <[email-masked]>

Applications Area Advisor:
Lisa Dusseault <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

Description of Working Group:

The Calendaring and Scheduling standards, defined in RFC's 2445, 2446,
and 2447 were released in November 1998, and further described in RFC
3283. They were designed to progress the level of interoperability
between dissimilar calendaring and scheduling systems. The Calendaring
and Scheduling Core Object Specification, iCalendar, succeeded in
establishing itself as the common format for exchanging calendaring
information across the Internet. On the other hand, only basic
interoperability has been achieved between different scheduling systems.

The Calsify working group is chartered to:

(1) Revise the Calendaring and Scheduling Standards to advance the
state of interoperable calendaring and scheduling by addressing
the known interoperability issues, errata, and problems found based on
implementation experience.

(2) Clarify the registration process for iCalendar extensions (i.e.,
the current core object specification only provides a template
to register new properties).

(3) Provide a means to ease transition from, and to co-exist with,
the earlier iCalendar standards to the new ones.

Proposing an XML representation or transformation of iCalendar
objects is out of the scope of this working group.

Depending on the results of the update process on the standards 
documents the working group will consider whether advancing the 
documents to draft standard is appropriate. If we decide to move the 
documents to draft status, milestones may get changed and/or added to 
allow for any additional work necessary to advance the documents.

Goals and Milestones:

Done
Submit iMIP bis draft 00

Done
Submit iCalendar bis draft 00, with formatting changes from RFC2445.

Done
Submit iTIP bis draft 00

June 2006
Submit updated version of rfc2445bis draft

June 2006
Submit updated version of rfc2446bis draft

June 2006
Submit updated version of rfc2447bis draft

Sep 2006
Working Group Last Call on rfc2445bis draft

Oct 2006
Working Group Last Call on rfc2447bis draft

Oct 2006
Working Group Last Call on rfc2446bis draft

Nov 2006
Decide whether documents move to PS or DS

Jan 2007
Submit rfc2446bis draft to IESG

Jan 2007
Submit rfc2445bis to IESG

Jan 2007
Submit rfc2447bis to IESG

Date: Fri, 21 Jul 2006 12:00:48 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] 2445bis: clarify allowed value types of date-time property combinations

Hi Bernard,
I was just checking on the behavior for the VALUE type of DTSTART/DTEND and 
DTSTART/DUE in VEVENT and VTODO. Right now for VEVENT, the only restriction 
I see is that if DTSTART is a DATE then DTEND must also be a DATE. That 
means that having DTSTART be DATE-TIME and DTEND be DATE is allowed 
(provided DTEND is later than DTSTART). If that is allowed then I would 
like to see it explicitly stated - perhaps a table of the two properties 
with yes/no for combinations of value types?

The issue with VTODO is more complex as there is no restriction at all, so 
DTSTART as DATE and DUE as DATE-TIME, or DTSTART as DATE-TIME and DUE as 
DATE is allowed. I was just bitten by this so would like to see more 
clarification as per VEVENT.

PS This might tie in with the UNTIL value issue too. Perhaps a table of all 
date/time related properties for each component with an indication of what 
combinations of values each is allowed would be good.

-- 
Cyrus Daboo

From: "Tim Hare" <[email-masked]>
To: "'ietf-calsify'" <[email-masked]>
Subject: RE: [Ietf-calsify] Re: [issue21] do we need a new mime type for this update, in order for         backward compat?
Date: Sat, 15 Jul 2006 10:47:56 -0400

I don't know about the version number - in my experimentation with some
different implementations, some of them seem to ignore the VERSION:
component entirely; if the MIME type is text/calendar or the file extension
is ".ics" they read the file as though it were "VERSION: 2.0" even if the
VERSION: component is "1.0".

I agree with the statement "if we've preserved backward compat then we don't
need this".  I believe one of the original goals of Calsify was to reach a
sort of "least common denominator" that could be used without breaking
existing implementations badly enough to cause major redevelopment efforts.
I still think that's a good idea, and so would not like to see incompatible
or substantial changes. 

In my opinion, if you change things significantly enough to cause those
kinds of problems, you might as well go ahead and change over to an
XML-based syntax while you're at it: at least with XML you could fairly
easily invoke a parser and stylesheet in your input pipeline to transform it
into whatever your implementation understands.

Tim Hare

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Friday, July 14, 2006 11:39 PM
To: Alexey Melnikov
Cc: [email-masked]
Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this
update, in order for backward compat?

Alexey Melnikov wrote:
> Eliot Lear wrote:
>
>> New submission from Eliot Lear <[email-masked]>:
>>
>> if we've preserved backward compat then we don't need this. 
>> otherwise we might.
>>  
>>
> I thought rfc2445bis took care of this (it registers the MIME type, 
> used by iTIP and iMIP)?
>
I know it does currently, and perhaps I've misplaced the issue, but it
seemed more natural for iMIP.  This issue is a placeholder.  If we make
incompatible or substantial changes by the time we're done, we should think
about how this could be managed by calendar systems.  One approach is to use
mime multipart/alternative with a new version.  Another approach would be to
bump the iCal version number.  This is not something we can decide until
we're a little further down the road, but we should consider it.

Eliot

Date: Sat, 15 Jul 2006 05:39:09 +0200
From: Eliot Lear <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this update, in order for         backward compat?

Alexey Melnikov wrote:
> Eliot Lear wrote:
>
>> New submission from Eliot Lear <[email-masked]>:
>>
>> if we've preserved backward compat then we don't need this. 
>> otherwise we might.
>>  
>>
> I thought rfc2445bis took care of this (it registers the MIME type,
> used by iTIP and iMIP)?
>
I know it does currently, and perhaps I've misplaced the issue, but it
seemed more natural for iMIP.  This issue is a placeholder.  If we make
incompatible or substantial changes by the time we're done, we should
think about how this could be managed by calendar systems.  One approach
is to use mime multipart/alternative with a new version.  Another
approach would be to bump the iCal version number.  This is not
something we can decide until we're a little further down the road, but
we should consider it.

Eliot

To: [email-masked]
From: [email-masked]
Date: Mon, 03 Jul 2006 15:50:01 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-01.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-01.txt
	Pages		: 156
	Date		: 2006-6-23
	
There is a clear need to provide and deploy interoperable calendaring
and scheduling services for the Internet.  Current group scheduling
and Personal Information Management (PIM) products are being extended
for use across the Internet, today, in proprietary ways.  This memo
has been defined to provide the definition of a common format for
openly exchanging calendaring and scheduling information across the
Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-rfc2445bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-01.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--