From Internet-Drafts at ietf.org Mon Jul 3 12:50:01 2006 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Jul 3 12:50:07 2006 Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-01.txt Message-ID: 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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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. -------------- next part -------------- Skipped content of type multipart/alternative From lear at cisco.com Fri Jul 14 20:39:09 2006 From: lear at cisco.com (Eliot Lear) Date: Fri Jul 14 20:39:17 2006 Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this update, in order for backward compat? In-Reply-To: <44B81CF7.2050106@isode.com> References: <1152889487.72.0.329408898494.issue21@ofcourseimright.com> <44B81CF7.2050106@isode.com> Message-ID: <44B8635D.3070301@cisco.com> Alexey Melnikov wrote: > Eliot Lear wrote: > >> New submission from Eliot Lear : >> >> 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 From TimHare at comcast.net Sat Jul 15 07:47:56 2006 From: TimHare at comcast.net (Tim Hare) Date: Sat Jul 15 07:48:03 2006 Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this update, in order for backward compat? In-Reply-To: <44B8635D.3070301@cisco.com> Message-ID: <20060715144800.0420B142277@laweleka.osafoundation.org> 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 Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Eliot Lear Sent: Friday, July 14, 2006 11:39 PM To: Alexey Melnikov Cc: ietf-calsify@osafoundation.org 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 : >> >> 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cyrus at daboo.name Fri Jul 21 09:00:48 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Fri Jul 21 09:01:09 2006 Subject: [Ietf-calsify] 2445bis: clarify allowed value types of date-time property combinations Message-ID: <44C02FD6CF4A426162CC3BFC@Cyrus-Daboo.local> 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 iesg-secretary at ietf.org Tue Jul 25 13:00:01 2006 From: iesg-secretary at ietf.org (IESG Secretary) Date: Tue Jul 25 13:00:10 2006 Subject: [Ietf-calsify] WG Action: RECHARTER: Calendaring and Scheduling Standards Simplification (calsify) Message-ID: 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 Aki Niemi Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-calsify@osafoundation.org 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 From lisa at osafoundation.org Tue Jul 25 17:24:05 2006 From: lisa at osafoundation.org (Lisa Dusseault) Date: Tue Jul 25 17:24:23 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs Message-ID: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> 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 but I've never seen this in actual interpersonal scheduling. An example at 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 Tue Jul 25 17:52:43 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Tue Jul 25 17:52:50 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: <44C6BCDB.8080805@softdesign.net.nz> Lisa Dusseault wrote: > 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. 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 Tue Jul 25 18:01:46 2006 From: tantek at technorati.com (=?ISO-8859-1?Q?Tantek_=C7elik?=) Date: Tue Jul 25 18:01:31 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: 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 > should consider discouraging for interpersonal calendaring. 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. > 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. > > > 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 Tue Jul 25 18:03:38 2006 From: pregen at egenconsulting.com (Pat R Egen) Date: Tue Jul 25 18:03:46 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs In-Reply-To: <44C6BCDB.8080805@softdesign.net.nz> Message-ID: 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 Sent by: ietf-calsify-bounces@osafoundation.org 07/25/2006 08:52 PM To ietf-calsify@osafoundation.org cc Subject Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs Lisa Dusseault wrote: > 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. 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org 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 Tue Jul 25 18:50:46 2006 From: chuck at evdb.com (Chuck Norris) Date: Tue Jul 25 18:50:51 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: <167C8B30-AB6E-48B3-8A69-EFCADD014A31@evdb.com> 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: > > 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. > > > > Feedback? > > thanks! > Lisa_______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From andrew_dowden at softdesign.net.nz Tue Jul 25 18:59:10 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Tue Jul 25 18:59:29 2006 Subject: [Ietf-calsify] current test data: NZ, US/Canada (iCal scripts) Message-ID: <44C6CC6E.4080704@softdesign.net.nz> 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 Dowden Software Associates P O Box 31 132, Lower Hutt 5040, NEW ZEALAND -------------- next part -------------- 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 -------------- next part -------------- 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:20060428T231323Z-30302-008@softdesign.net.nz 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:20060428T231323Z-30303-008@softdesign.net.nz 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:20060428T231323Z-30304-008@softdesign.net.nz 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:20060428T231323Z-30305-008@softdesign.net.nz 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:20060428T231323Z-30306-008@softdesign.net.nz 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:20060428T231323Z-30307-008@softdesign.net.nz 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:20060428T231323Z-30308-008@softdesign.net.nz 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:20060428T231323Z-30309-008@softdesign.net.nz 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 -------------- next part -------------- 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:20060428T231932Z-30402-006@softdesign.net.nz 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:20060428T231932Z-30403-006@softdesign.net.nz 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:20060428T231932Z-30404-006@softdesign.net.nz 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:20060428T231932Z-30405-006@softdesign.net.nz 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:20060428T231932Z-30406-006@softdesign.net.nz 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:20060428T231932Z-30407-006@softdesign.net.nz 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:20060428T231932Z-30408-006@softdesign.net.nz 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:20060428T231932Z-30409-006@softdesign.net.nz 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:20060428T231932Z-30410-006@softdesign.net.nz 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:20060428T231932Z-30411-006@softdesign.net.nz 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:20060428T231932Z-30412-006@softdesign.net.nz 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:20060428T231932Z-30413-006@softdesign.net.nz 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:20060428T231932Z-30414-006@softdesign.net.nz 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:20060428T231932Z-30415-006@softdesign.net.nz 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:20060428T231932Z-30416-006@softdesign.net.nz 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 -------------- next part -------------- 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 -------------- next part -------------- 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 -------------- next part -------------- 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:20060324T002217Z-30601-003@softdesign.net.nz 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:20060324T002217Z-30602-003@softdesign.net.nz 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:20060324T002217Z-30603-003@softdesign.net.nz 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:20060324T002217Z-30604-003@softdesign.net.nz 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:20060324T002217Z-30605-003@softdesign.net.nz 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:20060324T002217Z-30606-003@softdesign.net.nz 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:20060324T002217Z-30607-003@softdesign.net.nz 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:20060324T002217Z-30608-003@softdesign.net.nz 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:20060324T002217Z-30609-003@softdesign.net.nz 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:20060324T002217Z-30610-003@softdesign.net.nz 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:20060324T002217Z-30611-003@softdesign.net.nz 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:20060324T002217Z-30612-003@softdesign.net.nz 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:20060324T002217Z-30613-003@softdesign.net.nz 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:20060324T002217Z-30614-003@softdesign.net.nz 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:20060324T002217Z-30615-003@softdesign.net.nz 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:20060324T002217Z-30616-003@softdesign.net.nz 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:20060324T002217Z-30617-003@softdesign.net.nz 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:20060324T002217Z-30618-003@softdesign.net.nz 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:20060324T002217Z-30619-003@softdesign.net.nz 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:20060324T002217Z-30620-003@softdesign.net.nz 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:20060324T002217Z-30621-003@softdesign.net.nz 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:20060324T002217Z-30622-003@softdesign.net.nz 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:20060324T002217Z-30623-003@softdesign.net.nz 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:20060324T002217Z-30624-003@softdesign.net.nz 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:20060324T002217Z-30625-003@softdesign.net.nz 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:20060324T002217Z-30626-003@softdesign.net.nz 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:20060324T002217Z-30627-003@softdesign.net.nz 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:20060324T002217Z-30628-003@softdesign.net.nz 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:20060324T002217Z-30629-003@softdesign.net.nz 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:20060324T002217Z-30630-003@softdesign.net.nz 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:20060324T002217Z-30631-003@softdesign.net.nz 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:20060324T002217Z-30632-003@softdesign.net.nz 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 -------------- next part -------------- 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:20060324T002217Z-30501-003@softdesign.net.nz 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:20060324T002217Z-30502-003@softdesign.net.nz 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:20060324T002217Z-30503-003@softdesign.net.nz 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:20060324T002217Z-30504-003@softdesign.net.nz 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:20060324T002217Z-30505-003@softdesign.net.nz 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:20060324T002217Z-30506-003@softdesign.net.nz 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:20060324T002217Z-30507-003@softdesign.net.nz 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:20060324T002217Z-30508-003@softdesign.net.nz 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:20060324T002217Z-30509-003@softdesign.net.nz 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:20060324T002217Z-30510-003@softdesign.net.nz 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 -------------- next part -------------- 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 From TimHare at comcast.net Tue Jul 25 19:21:41 2006 From: TimHare at comcast.net (Tim Hare) Date: Tue Jul 25 19:21:49 2006 Subject: [Ietf-calsify] RRULE simplificatiion Message-ID: <20060726022143.DA850142260@laweleka.osafoundation.org> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060725/edf99a74/attachment.htm From douglm at rpi.edu Tue Jul 25 20:21:49 2006 From: douglm at rpi.edu (douglm@rpi.edu) Date: Tue Jul 25 20:21:54 2006 Subject: [Ietf-calsify] RRULE simplificatiion Message-ID: <200607260321.k6Q3LnwW006524@smtp6.server.rpi.edu> 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 gsexton at mhsoftware.com Tue Jul 25 20:42:38 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Tue Jul 25 20:42:45 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: <44C6E4AE.5090106@mhsoftware.com> Lisa Dusseault wrote: > > 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 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: > 1, 2, 3, 4, 5 and -1 > 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 pregen at egenconsulting.com Tue Jul 25 21:48:33 2006 From: pregen at egenconsulting.com (Pat R Egen) Date: Tue Jul 25 21:48:40 2006 Subject: [Ietf-calsify] Re: current test data: NZ, US/Canada (iCal scripts) In-Reply-To: <44C6CC6E.4080704@softdesign.net.nz> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060726/d7667927/attachment.html From andrew_dowden at softdesign.net.nz Tue Jul 25 21:56:17 2006 From: andrew_dowden at softdesign.net.nz (Andrew N Dowden) Date: Tue Jul 25 21:56:35 2006 Subject: [Ietf-calsify] Re: current test data: NZ, US/Canada (iCal scripts) Message-ID: <44C6F5F1.8040501@softdesign.net.nz> 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 Dowden Software Associates P O Box 31 132, Lower Hutt 5040, NEW ZEALAND -------------- next part -------------- A non-text attachment was scrubbed... Name: Sunbird - iCal convert.odt Type: application/vnd.oasis.opendocument.text Size: 15655 bytes Desc: not available Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060726/a5d56d33/Sunbird-iCalconvert-0001.bin From cbryant-ical at corp.usa.net Wed Jul 26 06:23:33 2006 From: cbryant-ical at corp.usa.net (Chris Bryant) Date: Wed Jul 26 06:23:42 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> Message-ID: <000c01c6b0b6$b27cfd30$6401a8c0@corp.usa.net> ----- Original Message ----- From: "George Sexton" > >> #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. 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 Wed Jul 26 08:19:22 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Wed Jul 26 08:19:42 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <000c01c6b0b6$b27cfd30$6401a8c0@corp.usa.net> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <000c01c6b0b6$b27cfd30$6401a8c0@corp.usa.net> Message-ID: Hi Chris, --On July 26, 2006 9:23:33 AM -0400 Chris Bryant 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 Wed Jul 26 17:38:18 2006 From: TimHare at comcast.net (Tim Hare) Date: Wed Jul 26 17:38:20 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: Message-ID: <20060727003816.47A2B142256@laweleka.osafoundation.org> 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] 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 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From cbryant-ical at corp.usa.net Thu Jul 27 07:03:55 2006 From: cbryant-ical at corp.usa.net (Chris Bryant) Date: Thu Jul 27 07:03:59 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <20060727003816.47A2B142256@laweleka.osafoundation.org> Message-ID: <001501c6b185$80198280$6401a8c0@corp.usa.net> 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" > > 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: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] 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 > > 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 gsexton at mhsoftware.com Thu Jul 27 08:26:20 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu Jul 27 08:26:27 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <20060727003816.47A2B142256@laweleka.osafoundation.org> References: <20060727003816.47A2B142256@laweleka.osafoundation.org> Message-ID: <44C8DB1C.40700@mhsoftware.com> 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. Tim Hare wrote: > > 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: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] 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 > 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 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From lear at cisco.com Thu Jul 27 08:44:49 2006 From: lear at cisco.com (Eliot Lear) Date: Thu Jul 27 08:44:58 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <44C8DB1C.40700@mhsoftware.com> References: <20060727003816.47A2B142256@laweleka.osafoundation.org> <44C8DB1C.40700@mhsoftware.com> Message-ID: <44C8DF71.7070107@cisco.com> George Sexton wrote: > It would be better to have a new property, than to add an alternate > 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 Thu Jul 27 09:01:07 2006 From: cbryant-ical at corp.usa.net (Chris Bryant) Date: Thu Jul 27 09:01:14 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <20060727003816.47A2B142256@laweleka.osafoundation.org><44C8DB1C.40700@mhsoftware.com> <44C8DF71.7070107@cisco.com> Message-ID: <002001c6b195$df96c000$6401a8c0@corp.usa.net> 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" To: "George Sexton" Cc: "'IETF-iCalendar'" Sent: Thursday, July 27, 2006 11:44 AM Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs > George Sexton wrote: >> It would be better to have a new property, than to add an alternate >> 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > From Dave.Thewlis at calconnect.org Thu Jul 27 10:00:38 2006 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Thu Jul 27 10:00:49 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar - Possibly relevant information In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: <44C8F136.10403@calconnect.org> 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 ? Dave.Thewlis@calconnect.org -------------- 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 Thu Jul 27 10:00:49 2006 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Thu Jul 27 10:00:53 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar - Possibly relevant information In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: <44C8F141.3040702@calconnect.org> 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 ? Dave.Thewlis@calconnect.org -------------- 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 Thu Jul 27 10:52:36 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu Jul 27 11:14:34 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> Message-ID: <44C8FD64.6050101@mhsoftware.com> 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" > > Subject: Re: [Ietf-calsify] RRule simplification for interpersonal > calendarGUIs >> >> >> Lisa Dusseault wrote: >>> >>> #11. When specifying the "Nth weekday of a Month", only options are: >>> 1, 2, 3, 4, 5 and -1 >> 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 Thu Jul 27 10:36:45 2006 From: cbryant-ical at corp.usa.net (Chris Bryant) Date: Thu Jul 27 11:14:56 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> Message-ID: <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> 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" Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs > > > Lisa Dusseault wrote: >> >> #11. When specifying the "Nth weekday of a Month", only options are: >> 1, 2, 3, 4, 5 and -1 > 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 From lisa at osafoundation.org Thu Jul 27 11:25:23 2006 From: lisa at osafoundation.org (Lisa Dusseault) Date: Thu Jul 27 11:25:36 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <44C8FD64.6050101@mhsoftware.com> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> Message-ID: <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> 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: > 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" >> >> Subject: Re: [Ietf-calsify] RRule simplification for interpersonal >> calendarGUIs >>> >>> >>> Lisa Dusseault wrote: >>>> >>>> #11. When specifying the "Nth weekday of a Month", only options >>>> are: >>>> 1, 2, 3, 4, 5 and -1 >>> 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/ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From aki.niemi at nokia.com Thu Jul 27 12:43:58 2006 From: aki.niemi at nokia.com (Aki Niemi) Date: Thu Jul 27 12:44:29 2006 Subject: [Ietf-calsify] Draft minutes from =?iso-8859-1?q?Montr=E9al?= posted Message-ID: <1154029438.32124.7.camel@macbuster.research.nokia.com> 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 gsexton at mhsoftware.com Thu Jul 27 13:18:10 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Thu Jul 27 13:18:14 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> Message-ID: <44C91F82.1060409@mhsoftware.com> Lisa Dusseault wrote: > 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. 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. > > Lisa > > On Jul 27, 2006, at 10:52 AM, George Sexton wrote: > >> 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. >> -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From cyrus at daboo.name Thu Jul 27 13:40:06 2006 From: cyrus at daboo.name (Cyrus Daboo) Date: Thu Jul 27 13:40:27 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <44C91F82.1060409@mhsoftware.com> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> <44C91F82.1060409@mhsoftware.com> Message-ID: Hi George, --On July 27, 2006 2:18:10 PM -0600 George Sexton wrote: > 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. 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 Thu Jul 27 21:26:56 2006 From: TimHare at comcast.net (Tim Hare) Date: Thu Jul 27 21:26:57 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <44C91F82.1060409@mhsoftware.com> Message-ID: <20060728042654.E1221142267@laweleka.osafoundation.org> 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 Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] 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: > 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. 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. > > Lisa > > On Jul 27, 2006, at 10:52 AM, George Sexton wrote: > >> 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. >> -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From gsexton at mhsoftware.com Fri Jul 28 08:19:43 2006 From: gsexton at mhsoftware.com (George Sexton) Date: Fri Jul 28 08:19:49 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: <20060728042654.E1221142267@laweleka.osafoundation.org> References: <20060728042654.E1221142267@laweleka.osafoundation.org> Message-ID: <44CA2B0F.9010505@mhsoftware.com> 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. Tim Hare wrote: > > 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 > Interested Bystander, Non-Inc. > > -----Original Message----- > From: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] 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: > >> 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. >> > > 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. > > >> Lisa >> >> On Jul 27, 2006, at 10:52 AM, George Sexton wrote: >> >> >>> 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. >>> >>> > > -- > George Sexton > MH Software, Inc. > Voice: +1 303 438 9585 > URL: http://www.mhsoftware.com/ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ From reinhold at kainhofer.com Sun Jul 30 04:24:42 2006 From: reinhold at kainhofer.com (Reinhold Kainhofer) Date: Mon Jul 31 01:38:06 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Message-ID: <200607301324.43280.reinhold@kainhofer.com> Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault: > 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 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. > 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" 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: reinhold@kainhofer.com, 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 Mon Jul 31 17:17:20 2006 From: TimHare at comcast.net (Tim Hare) Date: Mon Jul 31 17:17:30 2006 Subject: [Ietf-calsify] RRULE proposal In-Reply-To: <200607301324.43280.reinhold@kainhofer.com> Message-ID: <20060801001727.2D5E914226F@laweleka.osafoundation.org> 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: Monthly@Tims.House.disorg 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 Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Reinhold Kainhofer Sent: Sunday, July 30, 2006 7:25 AM To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault: > 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 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. > 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" 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: reinhold@kainhofer.com, 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/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From helge.hess at opengroupware.org Mon Jul 31 17:40:35 2006 From: helge.hess at opengroupware.org (Helge Hess) Date: Mon Jul 31 17:41:51 2006 Subject: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs In-Reply-To: References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> <44C91F82.1060409@mhsoftware.com> Message-ID: 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/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6AC517F94D for ; Mon, 31 Jul 2006 17:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5CF3C142285 for ; Mon, 31 Jul 2006 17:41:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23208-06 for ; Mon, 31 Jul 2006 17:41:46 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id AFD53142284 for ; Mon, 31 Jul 2006 17:41:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 35FC3436AB6 for ; Tue, 1 Aug 2006 02:41:59 +0200 (CEST) Received: from [192.168.0.111] (port-ip-213-211-243-166.reverse.mdcc-fun.de [213.211.243.166]) by mail.mdlink.net (Postfix) with ESMTP id C81FC436A7F for ; Tue, 1 Aug 2006 02:41:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> <44C91F82.1060409@mhsoftware.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Tue, 1 Aug 2006 02:40:35 +0200 To: IETF-iCalendar X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 00:41:49 -0000 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/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 295687F906 for ; Mon, 31 Jul 2006 17:17:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A42F142284 for ; Mon, 31 Jul 2006 17:17:29 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23641-04 for ; Mon, 31 Jul 2006 17:17:27 -0700 (PDT) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D5E914226F for ; Mon, 31 Jul 2006 17:17:27 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc15) with SMTP id <2006080100172601500lli2je>; Tue, 1 Aug 2006 00:17:26 +0000 From: "Tim Hare" To: Date: Mon, 31 Jul 2006 20:17:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200607301324.43280.reinhold@kainhofer.com> Thread-Index: Aca0fKTFrs5ZO6ZySkGuKigLIJEd4wAfvHrA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <20060801001727.2D5E914226F@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.2 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID X-Spam-Level: ** Subject: [Ietf-calsify] RRULE proposal X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 00:17:29 -0000 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: Monthly@Tims.House.disorg 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 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 Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Reinhold Kainhofer Sent: Sunday, July 30, 2006 7:25 AM To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault: > A Minimal Profile of RRULE for inter-personal scheduling > > These RRULE simplifications are intended for VEVENTS (not necessarily=20 > timezones or tasks) in the context of: > - Any calendar that is exported, > with the intent to import it into a personal calendar application 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 > 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=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 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. =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 > This was crafted to show how combining BYWEEKNO with other BY* clauses > generates non-sensical events. > > 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" That's not the same date! In 2004, friday of week #7 is February 13, but that is only the second friday=20 in February. > REMOVING BYSETPOS: > > 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 ------------------------------------------------------------------ Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, 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/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CEE177F611 for ; Mon, 31 Jul 2006 01:38:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C0B08142255 for ; Mon, 31 Jul 2006 01:38:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05416-04 for ; Mon, 31 Jul 2006 01:38:01 -0700 (PDT) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C0CE142253 for ; Mon, 31 Jul 2006 01:38:01 -0700 (PDT) Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6V8bsAZ021287 for ; Mon, 31 Jul 2006 10:37:57 +0200 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs Date: Sun, 30 Jul 2006 13:24:42 +0200 User-Agent: KMail/1.9.3 References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607301324.43280.reinhold@kainhofer.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, DATE_IN_PAST_12_24 X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 08:38:04 -0000 Am Mittwoch, 26. Juli 2006 02:24 schrieb Lisa Dusseault: > 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:=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? > #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=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 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. =C2=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? 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 > This was crafted to show how combining BYWEEKNO with other BY* clauses > generates non-sensical events. > > 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. > REMOVING BYSETPOS: > > 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. =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----------------------------------------------------------------- Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, 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/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 304D67F7F8 for ; Fri, 28 Jul 2006 08:19:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 200EE1422A6 for ; Fri, 28 Jul 2006 08:19:48 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29807-02 for ; Fri, 28 Jul 2006 08:19:45 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4D4CA1422A7 for ; Fri, 28 Jul 2006 08:19:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 497C52927836; Fri, 28 Jul 2006 09:19:45 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28883-05; Fri, 28 Jul 2006 09:19:44 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 79E4329279C0; Fri, 28 Jul 2006 09:19:44 -0600 (MDT) Message-ID: <44CA2B0F.9010505@mhsoftware.com> Date: Fri, 28 Jul 2006 09:19:43 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <20060728042654.E1221142267@laweleka.osafoundation.org> In-Reply-To: <20060728042654.E1221142267@laweleka.osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 15:19:48 -0000 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. Tim Hare wrote: > > 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 > Interested Bystander, Non-Inc. > > -----Original Message----- > From: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] 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: > >> 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. >> > > 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. > > >> Lisa >> >> On Jul 27, 2006, at 10:52 AM, George Sexton wrote: >> >> >>> 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. >>> >>> > > -- > George Sexton > MH Software, Inc. > Voice: +1 303 438 9585 > URL: http://www.mhsoftware.com/ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 66FA97F8A3 for ; Thu, 27 Jul 2006 21:26:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 57784142281 for ; Thu, 27 Jul 2006 21:26:56 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02868-02 for ; Thu, 27 Jul 2006 21:26:55 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc13.comcast.net [206.18.177.53]) by laweleka.osafoundation.org (Postfix) with ESMTP id E1221142267 for ; Thu, 27 Jul 2006 21:26:54 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (alnrmhc13) with SMTP id <20060728042654b1300if2qle>; Fri, 28 Jul 2006 04:26:54 +0000 From: "Tim Hare" To: "'IETF-iCalendar'" Subject: RE: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Fri, 28 Jul 2006 00:26:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44C91F82.1060409@mhsoftware.com> Thread-Index: AcaxucpvGV4MNzKnRYOE0yDFFPL+ZwAQ0sxw Message-Id: <20060728042654.E1221142267@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.2 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID X-Spam-Level: ** X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2006 04:26:56 -0000 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 Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] 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: > 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. 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. > > Lisa > > On Jul 27, 2006, at 10:52 AM, George Sexton wrote: > >> 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. >> -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 32A097F8A1 for ; Thu, 27 Jul 2006 13:40:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 240E214227D for ; Thu, 27 Jul 2006 13:40:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11692-10 for ; Thu, 27 Jul 2006 13:40:22 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 40CA2142274 for ; Thu, 27 Jul 2006 13:40:22 -0700 (PDT) Received: from [17.101.35.49] ([17.101.35.49]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k6RKeC8q002215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jul 2006 16:40:15 -0400 Date: Thu, 27 Jul 2006 16:40:06 -0400 From: Cyrus Daboo To: George Sexton Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Message-ID: In-Reply-To: <44C91F82.1060409@mhsoftware.com> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> <44C91F82.1060409@mhsoftware.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.2 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 20:40:25 -0000 Hi George, --On July 27, 2006 2:18:10 PM -0600 George Sexton wrote: > 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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1DE9A7F8B3 for ; Thu, 27 Jul 2006 13:18:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E0D2142273 for ; Thu, 27 Jul 2006 13:18:13 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05346-03 for ; Thu, 27 Jul 2006 13:18:12 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 905F6142272 for ; Thu, 27 Jul 2006 13:18:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 9D9AC29275D8; Thu, 27 Jul 2006 14:18:12 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32309-02; Thu, 27 Jul 2006 14:18:12 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id E62AB29275C2; Thu, 27 Jul 2006 14:18:11 -0600 (MDT) Message-ID: <44C91F82.1060409@mhsoftware.com> Date: Thu, 27 Jul 2006 14:18:10 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> In-Reply-To: <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_HEADERS X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 20:18:13 -0000 Lisa Dusseault wrote: > 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. 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. > > Lisa > > On Jul 27, 2006, at 10:52 AM, George Sexton wrote: > >> 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. >> -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C7E987F8F6 for ; Thu, 27 Jul 2006 12:44:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B9A6614227D for ; Thu, 27 Jul 2006 12:44:27 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03925-07 for ; Thu, 27 Jul 2006 12:44:25 -0700 (PDT) Received: from mgw-ext12.nokia.com (mgw-ext12.nokia.com [131.228.20.171]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0428C142272 for ; Thu, 27 Jul 2006 12:44:24 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6RJiJFK019983 for ; Thu, 27 Jul 2006 22:44:21 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 22:44:03 +0300 Received: from essapo-nirac253186.europe.nokia.com ([10.162.253.186]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jul 2006 22:44:03 +0300 From: Aki Niemi To: Calsify Content-Type: text/plain Organization: Nokia-NRC/Helsinki Date: Thu, 27 Jul 2006 22:43:58 +0300 Message-Id: <1154029438.32124.7.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 19:44:03.0950 (UTC) FILETIME=[03E9F8E0:01C6B1B5] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-calsify] Draft minutes from =?iso-8859-1?q?Montr=E9al?= posted X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 19:44:27 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AF49C7F91F for ; Thu, 27 Jul 2006 11:25:30 -0700 (PDT) Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8AF74142267; Thu, 27 Jul 2006 11:25:30 -0700 (PDT) In-Reply-To: <44C8FD64.6050101@mhsoftware.com> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> <44C8FD64.6050101@mhsoftware.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <006F0746-1023-42DC-9699-8CAD5AE8FDB2@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Thu, 27 Jul 2006 11:25:23 -0700 To: George Sexton X-Mailer: Apple Mail (2.752.2) Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:25:34 -0000 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: > 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" >> >> Subject: Re: [Ietf-calsify] RRule simplification for interpersonal >> calendarGUIs >>> >>> >>> Lisa Dusseault wrote: >>>> >>>> #11. When specifying the "Nth weekday of a Month", only options >>>> are: >>>> 1, 2, 3, 4, 5 and -1 >>> 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/ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9E5E97F5DD for ; Thu, 27 Jul 2006 11:14:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 90023142267 for ; Thu, 27 Jul 2006 11:14:55 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22841-05 for ; Thu, 27 Jul 2006 11:14:53 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by laweleka.osafoundation.org (Postfix) with ESMTP id C8AEB142260 for ; Thu, 27 Jul 2006 11:14:53 -0700 (PDT) Received: from cmsout01.mbox.net (cmsout01.mbox.net [165.212.64.31]) by cmsout01.mbox.net (Postfix) with ESMTP id E930D78132; Thu, 27 Jul 2006 17:36:48 +0000 (GMT) Received: from cmsapps01.cms.usa.net [165.212.11.136] by cmsout01.mbox.net via smtad (C8.MAIN.3.27X); Thu, 27 Jul 2006 17:36:48 GMT X-USANET-Source: 165.212.11.136 IN cbryant-ical@corp.usa.net cmsapps01.cms.usa.net X-USANET-MsgId: XID069kgARKx6573X01 Received: from cbryantlt2 [165.212.225.3] by cmsapps01.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.27X) with ESMTP id 866kgARKU0390M36; Thu, 27 Jul 2006 17:36:46 GMT X-USANET-Auth: 165.212.225.3 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> From: "Chris Bryant" To: "George Sexton" References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Thu, 27 Jul 2006 13:36:45 -0400 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Z-USANET-MsgId: XID866kgARKU0390X36 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:14:55 -0000 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" Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs > > > Lisa Dusseault wrote: >> >> #11. When specifying the "Nth weekday of a Month", only options are: >> 1, 2, 3, 4, 5 and -1 > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 01C0C7F585 for ; Thu, 27 Jul 2006 11:14:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E6B6C142267 for ; Thu, 27 Jul 2006 11:14:32 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24048-04 for ; Thu, 27 Jul 2006 11:14:30 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E27A142260 for ; Thu, 27 Jul 2006 11:14:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 096ED2927563; Thu, 27 Jul 2006 11:53:02 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27808-08; Thu, 27 Jul 2006 11:53:01 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 5426C29274A4; Thu, 27 Jul 2006 11:52:37 -0600 (MDT) Message-ID: <44C8FD64.6050101@mhsoftware.com> Date: Thu, 27 Jul 2006 11:52:36 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Chris Bryant Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> In-Reply-To: <004d01c6b1a3$3c139620$6401a8c0@corp.usa.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 18:14:33 -0000 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" > > Subject: Re: [Ietf-calsify] RRule simplification for interpersonal > calendarGUIs >> >> >> Lisa Dusseault wrote: >>> >>> #11. When specifying the "Nth weekday of a Month", only options are: >>> 1, 2, 3, 4, 5 and -1 >> 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/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 36CDB7F8DD for ; Thu, 27 Jul 2006 10:00:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2831414227D for ; Thu, 27 Jul 2006 10:00:52 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10044-03 for ; Thu, 27 Jul 2006 10:00:51 -0700 (PDT) Received: from fed1rmmtao10.cox.net (fed1rmmtao10.cox.net [68.230.241.29]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E71C142277 for ; Thu, 27 Jul 2006 10:00:51 -0700 (PDT) Received: from [192.168.0.103] (really [70.191.49.25]) by fed1rmmtao10.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060727170050.HYQE18458.fed1rmmtao10.cox.net@[192.168.0.103]>; Thu, 27 Jul 2006 13:00:50 -0400 Message-ID: <44C8F141.3040702@calconnect.org> Date: Thu, 27 Jul 2006 10:00:49 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: IETF-iCalendar Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar - Possibly relevant information References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Content-Type: multipart/alternative; boundary="------------020005030904000206010302" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 17:00:52 -0000 This is a multi-part message in MIME format. --------------020005030904000206010302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 · Dave.Thewlis@calconnect.org --------------020005030904000206010302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 · Dave.Thewlis@calconnect.org
--------------020005030904000206010302-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4FCD87F707 for ; Thu, 27 Jul 2006 10:00:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 41210142277 for ; Thu, 27 Jul 2006 10:00:47 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07693-05 for ; Thu, 27 Jul 2006 10:00:45 -0700 (PDT) Received: from fed1rmmtao02.cox.net (fed1rmmtao02.cox.net [68.230.241.37]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B7A914226B for ; Thu, 27 Jul 2006 10:00:45 -0700 (PDT) Received: from [192.168.0.103] (really [70.191.49.25]) by fed1rmmtao02.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060727170041.SLUB12581.fed1rmmtao02.cox.net@[192.168.0.103]>; Thu, 27 Jul 2006 13:00:41 -0400 Message-ID: <44C8F136.10403@calconnect.org> Date: Thu, 27 Jul 2006 10:00:38 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: IETF-iCalendar Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar - Possibly relevant information References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Content-Type: multipart/alternative; boundary="------------000609030301060502040108" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 17:00:47 -0000 This is a multi-part message in MIME format. --------------000609030301060502040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 · Dave.Thewlis@calconnect.org --------------000609030301060502040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 · Dave.Thewlis@calconnect.org
--------------000609030301060502040108-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8D9127F88A for ; Thu, 27 Jul 2006 09:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7FC8514227D for ; Thu, 27 Jul 2006 09:01:13 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18906-07 for ; Thu, 27 Jul 2006 09:01:10 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by laweleka.osafoundation.org (Postfix) with ESMTP id B6FF2142273 for ; Thu, 27 Jul 2006 09:01:10 -0700 (PDT) Received: from cmsout02.mbox.net (cmsout02.mbox.net [165.212.64.32]) by cmsout02.mbox.net (Postfix) with ESMTP id 8449E4C8F1; Thu, 27 Jul 2006 16:01:09 +0000 (GMT) Received: from uadvg129.cms.usa.net [165.212.11.129] by cmsout02.mbox.net via smtad (C8.MAIN.3.27X); Thu, 27 Jul 2006 16:01:09 GMT X-USANET-Source: 165.212.11.129 IN cbryant-ical@corp.usa.net uadvg129.cms.usa.net X-USANET-MsgId: XID985kgAqBJ0375X02 Received: from cbryantlt2 [165.212.225.3] by uadvg129.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.27X) with ESMTP id 192kgAqBH0427M29; Thu, 27 Jul 2006 16:01:07 GMT X-USANET-Auth: 165.212.225.3 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <002001c6b195$df96c000$6401a8c0@corp.usa.net> From: "Chris Bryant" To: "Eliot Lear" , "George Sexton" References: <20060727003816.47A2B142256@laweleka.osafoundation.org><44C8DB1C.40700@mhsoftware.com> <44C8DF71.7070107@cisco.com> Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Thu, 27 Jul 2006 12:01:07 -0400 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Z-USANET-MsgId: XID192kgAqBi0427X29 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 16:01:13 -0000 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" To: "George Sexton" Cc: "'IETF-iCalendar'" Sent: Thursday, July 27, 2006 11:44 AM Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs > George Sexton wrote: >> It would be better to have a new property, than to add an alternate >> 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 > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BCEB37F7C2 for ; Thu, 27 Jul 2006 08:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AE82B14226D for ; Thu, 27 Jul 2006 08:44:56 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03798-06 for ; Thu, 27 Jul 2006 08:44:55 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2399214226C for ; Thu, 27 Jul 2006 08:44:55 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2006 08:44:55 -0700 X-IronPort-AV: i="4.07,189,1151910000"; d="scan'208"; a="308500092:sNHT24489736" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6RFispo018532; Thu, 27 Jul 2006 08:44:54 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6RFisJi026769; Thu, 27 Jul 2006 08:44:54 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp177.cisco.com [10.61.64.177]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6RFc0u6005402; Thu, 27 Jul 2006 08:38:01 -0700 Message-ID: <44C8DF71.7070107@cisco.com> Date: Thu, 27 Jul 2006 17:44:49 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: George Sexton Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <20060727003816.47A2B142256@laweleka.osafoundation.org> <44C8DB1C.40700@mhsoftware.com> In-Reply-To: <44C8DB1C.40700@mhsoftware.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=325; t=1154015094; x=1154879094; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-calsify]=20RRule=20simplification=20for=20interpersonal=20 calendarGUIs; X=v=3Dcisco.com=3B=20h=3DQjQTKLW7zDDKJ5RXW4bCxhMFon0=3D; b=qFcwFMvG7RMI5aR/tViypKYOoKDqri4ijPc+Tg9L0nDisVq/m8MBERftgZhPy2hjFyPwcq6M fs3mvQ1zUKbNAUOvWZ74Q09Ich5tH78TogNmmJ/SMMDKSkDF2CFN+WJf; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:44:56 -0000 George Sexton wrote: > It would be better to have a new property, than to add an alternate > 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BF7F57F71D for ; Thu, 27 Jul 2006 08:26:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B072E14226C for ; Thu, 27 Jul 2006 08:26:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23357-06 for ; Thu, 27 Jul 2006 08:26:23 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 02C5514226B for ; Thu, 27 Jul 2006 08:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id BDDFA2926C2F; Thu, 27 Jul 2006 09:26:22 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24344-05; Thu, 27 Jul 2006 09:26:22 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id E189F29272C2; Thu, 27 Jul 2006 09:26:21 -0600 (MDT) Message-ID: <44C8DB1C.40700@mhsoftware.com> Date: Thu, 27 Jul 2006 09:26:20 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Tim Hare Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs References: <20060727003816.47A2B142256@laweleka.osafoundation.org> In-Reply-To: <20060727003816.47A2B142256@laweleka.osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: 'IETF-iCalendar' X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 15:26:25 -0000 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. Tim Hare wrote: > > 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: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] 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 > 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 > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > -- George Sexton MH Software, Inc. Voice: +1 303 438 9585 URL: http://www.mhsoftware.com/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EB1D27F7BE for ; Thu, 27 Jul 2006 07:03:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DBF6F1422A0 for ; Thu, 27 Jul 2006 07:03:58 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00492-09 for ; Thu, 27 Jul 2006 07:03:58 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0299014229B for ; Thu, 27 Jul 2006 07:03:58 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by cmsout03.mbox.net (Postfix) with ESMTP id DF17D22E for ; Thu, 27 Jul 2006 14:03:56 +0000 (GMT) Received: from cmsapps02.cms.usa.net [165.212.11.138] by cmsout03.mbox.net via smtad (C8.MAIN.3.27X); Thu, 27 Jul 2006 14:03:56 GMT X-USANET-Source: 165.212.11.138 IN cbryant-ical@corp.usa.net cmsapps02.cms.usa.net X-USANET-MsgId: XID549kgAoD52801X03 Received: from cbryantlt2 [165.212.225.3] by cmsapps02.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.27X) with ESMTP id 125kgAoD40369M38; Thu, 27 Jul 2006 14:03:55 GMT X-USANET-Auth: 165.212.225.3 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <001501c6b185$80198280$6401a8c0@corp.usa.net> From: "Chris Bryant" To: "'IETF-iCalendar'" References: <20060727003816.47A2B142256@laweleka.osafoundation.org> Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Thu, 27 Jul 2006 10:03:55 -0400 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Z-USANET-MsgId: XID125kgAoD50369X38 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 14:03:59 -0000 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" > > 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: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] 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 > > 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 > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DB46B7F6C9 for ; Wed, 26 Jul 2006 17:38:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B1011142292 for ; Wed, 26 Jul 2006 17:38:18 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10017-01 for ; Wed, 26 Jul 2006 17:38:16 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by laweleka.osafoundation.org (Postfix) with ESMTP id 47A2B142256 for ; Wed, 26 Jul 2006 17:38:16 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc11) with SMTP id <20060727003815m1100l50t1e>; Thu, 27 Jul 2006 00:38:15 +0000 From: "Tim Hare" To: "'IETF-iCalendar'" Subject: RE: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Wed, 26 Jul 2006 20:38:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawxusKi7DQH5Y4QP6tniGwHZhgkgATVKNw Message-Id: <20060727003816.47A2B142256@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.1 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID X-Spam-Level: ** X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2006 00:38:19 -0000 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: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] 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 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4FD7E7F80A; Wed, 26 Jul 2006 08:19:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 408FE142292; Wed, 26 Jul 2006 08:19:41 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30282-06; Wed, 26 Jul 2006 08:19:38 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C31F14228D; Wed, 26 Jul 2006 08:19:38 -0700 (PDT) Received: from [17.101.35.49] ([17.101.35.49]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k6QFJRCL020495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 11:19:31 -0400 Date: Wed, 26 Jul 2006 11:19:22 -0400 From: Cyrus Daboo To: Chris Bryant , George Sexton , Lisa Dusseault Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Message-ID: In-Reply-To: <000c01c6b0b6$b27cfd30$6401a8c0@corp.usa.net> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> <000c01c6b0b6$b27cfd30$6401a8c0@corp.usa.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 15:19:41 -0000 Hi Chris, --On July 26, 2006 9:23:33 AM -0400 Chris Bryant 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D4AB07F7A3; Wed, 26 Jul 2006 06:23:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C5AFC142287; Wed, 26 Jul 2006 06:23:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02173-07; Wed, 26 Jul 2006 06:23:38 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by laweleka.osafoundation.org (Postfix) with ESMTP id 01E51142281; Wed, 26 Jul 2006 06:23:38 -0700 (PDT) Received: from cmsout03.mbox.net (cmsout03.mbox.net [165.212.64.33]) by cmsout03.mbox.net (Postfix) with ESMTP id C3B3223C; Wed, 26 Jul 2006 13:23:36 +0000 (GMT) Received: from uadvg137.cms.usa.net [165.212.11.137] by cmsout03.mbox.net via smtad (C8.MAIN.3.27X); Wed, 26 Jul 2006 13:23:36 GMT X-USANET-Source: 165.212.11.137 IN cbryant-ical@corp.usa.net uadvg137.cms.usa.net X-USANET-MsgId: XID348kgZNXK9913X03 Received: from cbryantlt2 [165.212.225.3] by uadvg137.cms.usa.net (ASMTP/) via mtad (C8.MAIN.3.27X) with ESMTP id 399kgZNXI0419M37; Wed, 26 Jul 2006 13:23:34 GMT X-USANET-Auth: 165.212.225.3 AUTO cbryant-ical@corp.usa.net cbryantlt2 Message-ID: <000c01c6b0b6$b27cfd30$6401a8c0@corp.usa.net> From: "Chris Bryant" To: "George Sexton" , "Lisa Dusseault" References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> <44C6E4AE.5090106@mhsoftware.com> Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendarGUIs Date: Wed, 26 Jul 2006 09:23:33 -0400 Organization: USA.NET MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Z-USANET-MsgId: XID399kgZNXj0419X37 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 13:23:41 -0000 ----- Original Message ----- From: "George Sexton" > >> #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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F36077F8A1 for ; Tue, 25 Jul 2006 21:56:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E4EC814228E for ; Tue, 25 Jul 2006 21:56:33 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04417-03 for ; Tue, 25 Jul 2006 21:56:32 -0700 (PDT) Received: from grunt8.ihug.co.nz (grunt8.ihug.co.nz [203.109.254.48]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5C0AD142262 for ; Tue, 25 Jul 2006 21:56:30 -0700 (PDT) Received: from 203-109-186-229.dialup.ihug.co.nz ([127.0.0.1]) [203.109.186.229] by grunt8.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1G5bRS-0000kZ-00; Wed, 26 Jul 2006 16:56:18 +1200 Message-ID: <44C6F5F1.8040501@softdesign.net.nz> Date: Wed, 26 Jul 2006 16:56:17 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ietf-calsify Content-Type: multipart/mixed; boundary="------------040001060008080208090908" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-calsify] Re: current test data: NZ, US/Canada (iCal scripts) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 04:56:34 -0000 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 Dowden Software Associates P O Box 31 132, Lower Hutt 5040, NEW ZEALAND --------------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" UEsDBBQAAAAAAFgP+jRexjIMJwAAACcAAAAIAAAAbWltZXR5cGVhcHBsaWNhdGlvbi92bmQu b2FzaXMub3BlbmRvY3VtZW50LnRleHRQSwMEFAAAAAAAWA/6NAAAAAAAAAAAAAAAABoAAABD b25maWd1cmF0aW9uczIvc3RhdHVzYmFyL1BLAwQUAAgACABYD/o0AAAAAAAAAAAAAAAAJwAA AENvbmZpZ3VyYXRpb25zMi9hY2NlbGVyYXRvci9jdXJyZW50LnhtbAMAUEsHCAAAAAACAAAA AAAAAFBLAwQUAAAAAABYD/o0AAAAAAAAAAAAAAAAGAAAAENvbmZpZ3VyYXRpb25zMi9mbG9h dGVyL1BLAwQUAAAAAABYD/o0AAAAAAAAAAAAAAAAGgAAAENvbmZpZ3VyYXRpb25zMi9wb3B1 cG1lbnUvUEsDBBQAAAAAAFgP+jQAAAAAAAAAAAAAAAAcAAAAQ29uZmlndXJhdGlvbnMyL3By b2dyZXNzYmFyL1BLAwQUAAAAAABYD/o0AAAAAAAAAAAAAAAAGAAAAENvbmZpZ3VyYXRpb25z Mi9tZW51YmFyL1BLAwQUAAAAAABYD/o0AAAAAAAAAAAAAAAAGAAAAENvbmZpZ3VyYXRpb25z Mi90b29sYmFyL1BLAwQUAAAAAABYD/o0AAAAAAAAAAAAAAAAHwAAAENvbmZpZ3VyYXRpb25z Mi9pbWFnZXMvQml0bWFwcy9QSwMEFAAIAAgAWA/6NAAAAAAAAAAAAAAAAAwAAABsYXlvdXQt Y2FjaGVjZGBkKLBjYGAI4WVg4GACMtiQOTxAHMDJwMDyCcZwZIRKOzFCpAFQSwcIJhf0iCcA AABCAAAAUEsDBBQACAAIAFgP+jQAAAAAAAAAAAAAAAALAAAAY29udGVudC54bWztneuWm0iS gP/vU3A0Z/tU74gSJKCbu2pO2S6vPe2ye11y93r+zEmhVIk1Ai2guuyveYB9in20fYB9hs3k JhBIAikxSIruPtVVQAZJZETkl0Fm8stfnuem8Egc17Ctq5Z8KbUEYun2xLAerlpfR+/Efusv 1//0iz2dGjoZTmx9OSeWJ+q25dH/C7S05Q6Ds1etpWMNbewa7tDCc+IOPX1oL4gVlRomrx76 9wqOuN6LWbi4f3GytEeevaKF2bWpsnhc/M7+xcnSEwc/FS3MrqVKTRaf2kULP7umOLWp1ucL 7BlrtXg2Dev7VWvmeYthp/P09HT5pFzazkNHHgwGHf9sXGE9vm6xdEz/qoneISZhN3M78qXc ia6dEw8XrR+7NlklazkfE6ewarCHM63qPj4UtojHhw2q0WfYKWwb/sXp5lUmxZtXmSTLzrE3 29Am/c4dPen/uPu4sgVnXvRe7NqUqnTHWBR+zODqZHnbtuOqsgKBg/rVRZKkdoK/E1c/bb38 yTE84iQu17dermNTjzVuz/OURq+TO/QKkTwyM40NnynC3VAAdYLT8cXuZKPof7/7eK/PyByv LjZ2Xywaluthi2kmDGmpOHodBc1A4W4nPjClwVOcYp2IE6Kb7vUvgfHHh4Xgb9aIV617Dzv3 L/OxbbYEaujRVXPDfFk7uRLCLNkl1CKeRTc429l+kxvHwHnyg+M7Co/wzJ5jOad4cKbQzfOK R7VKlmVnxAdiEcegZuU+Ga67S/4bPxiZ2Jrk3CN1cvON5vaEOFbqkoXh6dTFp8Yzmex8RGuC TSLcY8sVvn7IqcZPeGG7r9KXBcfy7vmIqWZoqCt32zwVb75vWwjPsUYQvloGhQIi3N0fXqvQ KjaayyEP7Ff2E3Yc+2nz0yYuynmafBs7oFJ3hu7Yrj31AgXfU7HTjZXLu/hHVPJ34kywldcq qzMH3r6zKfyFx/HSo83vGbroy4njov9zzYKoSDm+X1hRH89aUSn/L3Hh0C7H8Qzihhc/GRPW Mcu9S9r36POWMLVpX+08GJZokikNmVL6oGM8zOhRUYquDyAQm8YDjfPBRa5f4DshC/HJ8Gai 5QMpe5yoiqxLpPAnsjBy1TId0Rv7Gkk84K6nvbzJfV4KPuZybq09dnAw+/Th8VAJg0tN7rJn Ck46xBTTFyjdbk/9l9I1fc29pr1Ltd/fVlPU73fl8jW9yTciUSemuV5ReihZTdriY6x/f3Ds pTVhtbEp7/6JdNm/vj0s8CQYRVHTGfRCqxrbDu1IIlOjNoX0ueDapjER/iT5/yQvC43Psi2S POzZiwKFx7bnMZzKvzB6uMQzGHP8QFYazH3sspZQj37rfegbdMhDV2w26we3W0lpz2/Io++8 rnJdKGfVOylH0zspR9M7KdA7VRqolXPsnZTz7Z0U6J1iXeQr4lR7J1RN78RaYWvvJA/KxnxU Se+0o6aoP5C75WsKvVOVgRqdY++Ezrd3QtA7MV38ljH6BXbwg4MXs+gEPcDeQPt/iPE7EmuC nTiFP8euR+u0oOa5fkWsSNrPrKnQz0u6xn/Ry2V54bXiY08k0MzYNtNvCdjFInYNbEVFEieD UtHp/LLsraVJnjeXji/wyxdXY8aWiqjRN8S/I+nv7wlmxhQrKy68prGwnw9iarrvj+0hPOzr O+z5XQ878dP+x9L1jOkL1Yf1QGvyRM3pqjXFpptIWa83VkJPeXn/dFsO1jSbbLTcc7HO2dni Ks+M+KtUeeTSsirnMhdzw176TFWtFJczrAl9vFBYUIxxnJg6eYwtqx7Usm+CqTIuL286Lt1p P1R3VbpFCfNO9Nb0ueyFu34genTbpWMbNmFAulS0btC4nUzZzuZn39KdRdjXl9i/rax55L+X zDGT9X7Qsp352ov5beaT7gg3FU7Z17aeMBRQ3AS752iCxaPEuZhBj48ZhNeahpu+8qN8ZBaS CVKdvSLN2dpTH+ypYZ3e2Zri4Bx7uKbY29Kl4yFaNftJDCZfBtzlOUtyxtAlSxWHR3Ts5grd bTmD2iszeMIGBYSfMZHDsp6n0g/uF1ggY5AwpMNyuedtSEBFWwyLUyp5YyemnLPNnaNBccqv n4xBARVlTKSm/DfSwA4aZQdVJ8BVMJFjNxFOOe3jsgMYQPE3JE4Z6Y2xRgMsOXITQZwSxCdi BxA9EqZRdaq3eypWc74mwinVey4mAum4XCvaK8+7cy55Rp/xFhppFebPMt+hwx3zzHcqcedM 8/Ja3CupmdHiJj8bOwR/F8dkajuEiX4oEw9Laf6Y5vdXnffrlY1/q1UnTYx/5xjcOOX9zsVE oIvMtSJOWcMTMRUYpiVMo6ZsodysN5awtqNOG6xp6mu9Ngg92R6molQ9I7UPKYMDrGiat2eB 51BhQascj51Vnb08MTs7x1AEE1VhgdAPNThOE1o3xqTBkdkixKSMifzYXQ6Oww6ApHNNperk syydlhntYyMJeRSIiWMaFgm0lNh86aitCPZl+GEB5/SNqfLdHY5tOT4QTsZGKt+xAZaQHr2N VD1xVYYFNcduI2rViWS5/EqKRtsIZJL3NLSqM8mnZmjnGIyqnggrw1KLo7eRqrO/MsyWhg6L GVrV2xucmqGdYzCqPHlcel5qs20EgtGehlb1/OdTM7RzDEaVp41hss7R20jlaWOYPHH0NlJ1 2hid2BtxgJr9DE2rfFvdEzO0MwxGWuU75cK78KO3karTxqdmIzATMNeMznKj3HpXh54Oy1Sd LUYwH+foA0zV2eJTsxHop3LNCOYa124qp9JvjbLf5abq3bEZ1Jap18VvnP1AdMEbr1bUuUt6 WtD6/5y9LbsyESBTt/Y/Rra6wCSPxAxdZbw0TeIJwUl2/KpFFeT/mfSl1/5lzJnuX+Zj24xD srWci+5yOjVoU1yGBQOZoj7D1ET+7x//HT9j4u6JJ/XLzJnf4TE9E37WXrpUBwO9zPdS7z3s BLXztbPteUtoA3HVxv/+43+KaIP6lE7iTbOkS03yI1GzNaXUr6kj0JLaAC0dhz1p9WsKNV9L 3QZo6TjsqVe/phRKjkegqX4TNKVJR+B9g/o1pR6HTbEvStavqjqNKnG6CLMjYHZgdmD2JmgJ mB2YHZgdmL3JmgJmB2YHZq+Z2RVgdmB2YPYmaAmYHZgdmB2YvcmaAmYHZgdmr5nZVWB2YHZg 9iZoCZgdmB2YHZi9yZoCZgdmB2avmdk1YHZgdmD2JmgJmB2YHZgdmL3JmgJmB2YHZq+Z2bvA 7MDswOxN0BIwOzA7MDswe5M1BcwOzA7MXjOz94DZgdmB2ZugJWB2YHZgdmD2JmsKmB2YHZi9 ZmbvA7MDswOzN0FLwOzA7MDswOxN1hQwOzA7MHvNzD4AZgdmB2ZvgpaA2YHZgdmB2ZusKWB2 YHZg9pqZXZYA2gHaAdqboCWAdoB2gHaA9iZrCqAdoB2gvW5ohy+hArQDtDdCSwDtAO0A7QDt TdYUQDtAO0B73dAOn0IFaAdob4SWANoB2gHaAdqbrCmAdoB2gPa6oR2+hQrQDtDeCC0BtAO0 A7QDtDdZUwDtAO0A7XVDO3wMFaAdoL0RWgJoB2gHaAdob7KmANoB2gHa64Z2+BoqQDtAeyO0 BNAO0A7QDtDeZE0BtAO0A7TXDe3wOVSAdoD2RmgJoB2gHaAdoL3JmgJoB2gHaK8b2uF7qADt AO2N0BJAO0A7QDtAe5M1BdAO0A7QXje0wwdRAdoB2huhJYB2gHaAdoD2JmsKoB2gHaC9bmiH L6ICtAO0N0JLAO0A7QDtAO1N1hRAO0A7QHvN0I7gi6gA7QDtjdASQDtAO0A7QHuTNQXQDtAO 0F43tMMXUQHaAdoboSWAdoB2gHaA9iZrCqAdoB2gvW5ohy+iArQDtDdCSwDtAO0A7QDtTdYU QDtAO0B79dDesekT6mSIl549x56hByfc61/CE2N78hL/wYrHf9AHmrsC+5koPbX1pXvVmmLT Ja3w5GJhvogT4hoPlji3JyQ63QnbziX/uSQWVdKE6KabdzDQ1sRwFyZ+Ee2lZxoWEcNmjVo1 0McH01y6nkMrY1v5dyghbITH5oZ6lpFCfz1YyFsHPxnWw6qRc7W2yBr4b3Lr+vYZzxe0VYdC WInO9cXXy/tL4Sd6/JXwBlt4gn8OBS+oLPbcQ/+nEPye0AcbnPnHkncJz6SKirptLufWxqsv b3ytlCjwer3AjOAJcUTHfnLTJ+iRNdHENLfUhD5UaNaP2FwS0XtZ0LPUkJjOtyiXDmuNN9gU pgYb8b5YHn5eqbGzXoEyVXq9b5WU1vVnS3B1hxBLeDTI09YKdTJa61SiYLTn06it605nZbaf yJPwjWBHuJjZpjHBL0mrLSjj89glziOZCLppu8T1hCdCvlNRgmcLf8XWEjsvglxM7JcvXz/e Dt99uf23q2+3N18+fnv1+tvd50+j91dy9Nvbm2/0j2Li4iq+/saK3X1uj762/7htj9633305 uEYoWSWFVZD9wkFwUi56FdW9mNi3o/vRzZfRq99vPn69vXp7M7odIklSZaTIvBxpX9PTWtes d/WEt9gjQ0FGHUXusMoJF++corbXpZpb0thwIf88FALFrZVi3XG24Mf0W27DI/Mtd+m1rkPL TSotr3QRaX3aLNQdDEu4o6Axo48uXEwNx/V+5iSdiqXq4yRstCQuP2l/kInFU95otnQ4igsM b4uw1YHtlv2FLAj2hsI7iqWPxClgyYPIklFJS0ZlLJlC+vVbopP5OFmp/XUmy+vGnA4sh8jl 0xgy2qc1ZCVqDqVkcyilmkPlGlnYl5/SrYGEC5foNB5wiS1M/s7gcnirFOKoBtDSHe29qKo/ Lr0ZcYRfaWGBaZ8HOynORAg0PWStGXGTP6woKHc7UfiQchhFaJIs9xpGEZLckXuMIjThItBf EW3Je2OEWsrb+XIEExc8Y1tQhAtvZjhb3byYY/ZPwDF/c4hrTIjl/YQXtvvKrcAtmVe+I2OH o1siXm6JUNPgXkIdJNfqltFFtE6i/yjsNfgO54raF5y10l6UzG3HwCY3JzUxtYmVl95hXg6q hQ4qyod6qIaUpnmo1kHK0XnoHZ+RX9I5RToaZxYEzsmc6oM1oY9Af1g64eageYnBpfkiqIc6 aC+ZKlObkBVM1UjhlhNMidW45AQ1qSepTQtKvY6klg5KHHOCZWMSA3xqyZVkCVXhYmovHW8G aUJIE/JIE5bucCV+1p2TNywAxaXEn0r6sHQzqRybKZNQ1CCPyB2yPuKx7XCjK/9VUmL8c08W 3lq+fz/oGISccfDoZyBpWxupBtAYdNgA6MhGPzkty2cMVOSF5PmMgd6waTPjJb8sIrKSWcTP umdz8E5ZCt0THeiesiRLDXNPWerQ/47NPTMNy8c5C73SOx/v/J14xMEW70x/To7ik/3oR1tB Pnz6Unr+UjMmMKXrJPGbwJQWzGcKkybLctPecshyR47ectQyhWmPdEVk1JWkLGQuc0EgVXGA uPNNVfC07Gy6Is1Ih8g95zwF1zbK5CpkBMkK7rw1mmHru/tgPPKc7qR6MyEKfKwBs3ZxAHr4 L4NG7w+kDdS0lyMMNaKXI5HujmFYxNXne6sOs13sDcn5jIzezBz6lHNc2aBoyEZF0WxiAWnC 9lVP+3lwalkF0hoxUkrXSeU3UkoL7nIaKSHUbVrsQh3UPbIXuzynzWdGSojLexUYKR0g7nxH StUuCEmD0yFyz3mkxLWNsstEurzkwkhphR72M88xkkUPrMgLTz3KXGnEs6NLL6qBr+5+8FUd efXaqH8AEFJZ97ej3z7fXxVM6G8GrKatg2GAFa2DCXvxSglLK7UOZsA5ng0qimcDrgjExHFl IL9+HCGIyePTx7Iv/5TvY7v7YlC3jPWxDc55Wh/KEk+vIrl9XnL5jRKYNI4+wjay/GBRNLJ0 Umxh/OH2WHrbjm03UuKtaPY5reZvJsO25fgbwSZOvfRP1Ci7jYyycRsZpdQ2MkrZbWSUqraR UZq3jYxyUtvIKPy3kXkfYO8e/JvGXhSBryvYVsi+Mu0K4nXRn/4m0AYmNKo5XJZHr6YrtFFb aXNZS5LAzTYqJm/jwmtJKSrg9tPbnOJ8JmAq/CZgKiJtS5HHFC+GD8WwoVcKGzSui7dR9m0l z11gsuL57gSRlc91/n5WPN/VL6hIpqKUNJ4MpHEeJ/j14zhOYPJ2jhOKS+uWRb49RfObOIl6 taWn+HXS/2rbEyFoxkPyU1+IaTwY9tKNO2Dh4g/i0h7aKtoTs44p00cpSGvTX7qSKqvsl56k Sl32S5+ektsl+2NabkAlSVSALFFJiP0iSyryf0FM9mE9soJq71JRP92nIk28w45Ydj4iGjCn 0c3lhMpgkpKC9iovq+LNwi9fRMnZ8lI3Kt/br/5yVP/+fvWXovsP9qs/CssnJ42VqX9cvkie cov+0hOijiNMrVLc+w8mNiTT80YVSFvNaKhuVMFiGw1mB+avKxhZpOcKbBeQM7Kgxft1h8G1 kQXqirRBax9ZlH3n5xMwzyxldkDAZcpBjlwuufccuXyyqlm5fLKqMKKAEUWdI4paE9RTx54L X969QaqqFc1Qo40ZalQqQ43KZqhRVRlq1LwMNTqpDDXiRpW31MFeBNvfuJNBYJt9TIF5XXRJ IEJnH73qJKnuj9vbXynVffg0uv1C4ecKvfrj1/vR1f3XUtg1lAeDHh2RohH9Qf/h1dYcl8Oj Dqsj/XUoSfS//acRBBorxk39MhlZRWKxmEI7fVY/FhO/UQOqd7mEe0VmHSf5LvraGQr3Sx6z mw5/G9kAD2JqMV/YwCk0DAFbk9UiDupOgha0ROmRU+hjbz5//TRiC1FDD3sVTycquZjjxL1N QVl3Kz5UGZRyOaWkP5SSzJF4fXG7AbWQuyrqyl1lKXSABbayl45ouGDvKWLTj9qAXX59fD7u j5DMlzbz8gB02YqPxP6afrcpdIU5u7C8o/v5kNjTo+UOYtkdLM7Kv0OdFXNuNru7hNNoiW0w 47GNwGU3TKW7cqJu4COR2fx83I7hv/VkfkFhMvANf4KuPfUP+I8Y0+XeHpLIHYqFX/2Dc2x3 jlLfgFF664kj2hA7+4LAOJIelOkKzpYgk07EtkRi/Chr3izrOrTbFWxdXzoO24f20H7G39pk lYpvy0Xeap23QxXHSbnU52iU7EI4rtNUsvLlbVnvPXBQ2BUDQhxMd3UnwIPBNoM45APW5/1Y v5XbYrlVG+C3W/221HeLlMyKC65Z9qx4bruy7zeYOwnvDXKeoUm1BZJIgXKi1ERWNMrVgIvu dFH1z0V9tNTXhtRN6dGcUde+jqoWWv1xPkjLJr2bftz669Iifu/of9lg374wKfti6RI3iIci C47+O7fQcfaenbLes15120XmWJ2py5adBiKXWhapIrZxt0W4OCbauQl46e5yV2dJDTzsLl+o G5xGbxl0j+x5GPOG8//b8Ze/2r6L32FHn73iAbyhVyb60YyD+gtSwEV3uahS1EVLrR1VlQ19 asriD/Ncvp8EZeJ4fseMyfPt/QcPoxNzTaibKX8+oRjDPioYRRg2fpZdr01VInkzP7og/zfq DJVEGCUZYdjJYGxNb8/m2kOc4RZnSi02U7VknFGiOKPwjDPdeIzNqJXzCD4rXeKyYWpGLtoq t7KUwEkFIMQCTPhBgjCHxx5u/3xAPPXdT7BL8Dp3VxwpGENKTY9Sk98MONhJTmJ4Hph7uObN 72q3v8KjLeXNkh7O40VusFVkKpUNPJ8Q193/hW6puUxq9t2QwqWL4raX4Gn4nEl0z6Bo6++D 9vVeiD/Ozb75G53dYy1X4MxsUXjQFbdXExH9lVzr38GK9h0+uFuL2VlN7jNdTFpc+yg/nn4V rbTVttbutnvtIisV0yGhK8uS1syQIMvs81qsjhxCQkTectG0OSo1CUodJNFbjdBb5YjeGuev EzB5Vb5Fz8rnutlDVjzfzR6y8rmsfMuK5bLwLSuWy7q3rFguy96YWHgBtOqUUGKKbPTpKN4z Abet/xXLLf8FlNzUZ5SaG6hx3VJP47ulniZzXvzp14/j4k+tyNbOxaWldhDkPY1ZU04gSLGE sxGqiHUIiQlb2PLjVTxJJDacoUDPxp/aKEvrwXn9qoVanWt2H3//BYXPugHlVXqf4VU0hHE1 n2BYak6npvINXyrv8KVyDl9aMuAUIeNikSaxYIIK3ZWW9pPSaX/yM1ZlF1fwXEbeCc2enV/9 NbYnL6u/Jra+nBPLE2mM9uj/r/8fUEsHCFIvCIwoGAAAwzYCAFBLAwQUAAgACABYD/o0AAAA AAAAAAAAAAAACgAAAHN0eWxlcy54bWztHGuT27bxe38FR5122ml5IiX5fHf1KeM6cZqOnXrm zs3HDERCEhuK4ADg6eRf38WLBEmQoh4+O+NLZmIL+8BiX9gFgbz67nGTeg+YsoRkt6PwIhh5 OItInGSr29HH+7f+1ei7+R9ekeUyifBNTKJigzPuM75LMfOAOGM3Cng7Kmh2QxBL2E2GNpjd 8OiG5DgzRDc29o2cSo1IZkPJJbJNzfEjH0oscGu0aDF8ZolsU8cUbYcSC1zQqU2+JEOJH1nq L4kfkU2OeNKQ4jFNst9uR2vO85vxeLvdXmynF4SuxuH19fVYQkuBoxIvL2gqseJojFMsJmPj 8CIcG9wN5miofALXFikrNgtMB6sGcdSyKntYDfaIh1WHaqI1ooN9QyLXzTuNh5t3Gtu0G8TX HTa5Gr8HoPzP+3eVL9DN0LkEbk1VEU3ywctU2DY9IaQUVRCoAJXiToJgNla/LextL/qWJhxT Cz3qRY9QGpUaJxuX0gAvHAOGjx+Em448nUJqaWtuctSSQH5aogj7MY5SNn+lfKsc9tRvoaPb 0R1H9G63WZB05IEfGaxNku4awIqJcBSGQeGPPlPQcf8kr2mCXPzV+B7ie7QmGxQ6yBVk0OQu ciOVTSsg/gpnmCZgNbZNGNvH/42M9RRlsWOOGrB7og2JMc1qKHnCI4igZfKI471LzGKUYu8O Zcz7+JNDjD+jnLB/1NHUmGvOBwSagUxy2LQuFXfP+3dPw4QRvI9ZAlsu9t7fnS6V9opOdzll wVLYnxGlZNu9WgvJsRq3j50g1PskooSRJVcKvgO2y07hXMhPIeR/MY1R5rJKBTlx+nFX+tPj qmIzYsZ4iYpU13GGsxZpRVG+TqKRwdW//ZxC/qY8gbpPVDM3bI1isvWBP2RD//F2FFxMo83I Bdw1gJBYuQ+VCfZZjiKoi/w1ocknEB2lAnVy1Yv8IMSI2qiw2Q3l2kJ18NRqSWEd24SvfVVp clpY9s4RRVJBtnoUSKD7qOBETAFOkMSYKFSU5uvS5FKKBcUIijjGweDcQMROKkQT6fF2lFKf L2pekGQxFhu8KMjttUDaRCnDpQGhcAVDk5wJN+kWu0QXcrdWUzAMWsiEUdUuSFJCtTa8JVES seQTSBpOci7HIPGvCrSCIZzJgYgUGafgDR/vaisRdD6ULigz1Fo3moGB4XKT0JwMwMVP1IQp fuzgWELbPEsQcK1UVguZIXFU6njU6yyglvUuX+MM6leS+SmKYTP0pSy3o4yAZTdJKf5An8qL LOKFYrgFMFRVsG5wjf1OZ5zFjxOIvExMEl5MXoRVQNTdMgdlVuFwhO9YZquVS6f6lGBm3KNV IXw+15PTlh7k2HTP55u262AT9E1/oniDkkwWrcapJi2kvGDrBsoJji8bZTv7pNj2CdVHLwgV fi6cCHIuwyI2hFudPLEvqpP65DDSiLjfMM59TlaYr0WjitIt2rF9U9tTlu0DeBatqttW6Bvz pYgxEBDCY282UDGeJqtMxCZsfobJ/wrGk+UOPChbwaq2oEHb6oRCBshglkD+3CYQb+Wv4SnG tes83U7izgbhEeng9ceB6SD8qvJB8NXngz0xcQ9G/3US/Log8c5IC3tJnqKdX2F4NrgzbGCg PG303SF3SGRtEIVNEOIeNsRAbGjV2IJwLk4foPgLJwA6arniz0TWY3sW7tWxDlm/S71H6CDF Sy5WO7u+riuCJqs1r9QjQ1hJqwcVe1GD+DWgcrfBensH5cWZ158Klv25x5FY9sRqOHxJ/8Io FidfZ3NqWAJF/RaVJ9rqvFX2AKyMewmRdZ45jg3aebw5YEQkLOHyaO0KPOSqMjvf5SBuBPLD Qsd7qcPLi2vlYDa5dDFLrZY0vZvKMCu8JYQ/W+FLW+FeFF4iTt9AYKlTW2dGFGheE+dM+eDs hhu+KZjVi5RgtV2uxTdQDlp7l5KHK6BRb2qfGlBwHqw5d1ouyzoBhX6WgyBRVe1tsdqOFiSt HyErNeiSy1BZcEVoEDrIy1TfzaBEkSwGO8AblIvYe9os1KxwdCnTU+Wcy4ruzbVVtAe6aHdZ vKsEt+rhQYZ37+HDCu4e1xhs+Z+gHHo8o90Tye+8SewwI56vQPpAsfh4iTjHsUhbIne7U6ON 6dloZ9Domm/Ss7QKqk0YqEz7U5grLJpa1h7e8QWtN0TqVurjUI+CwXb85Rf/HAnud5XM2kcQ 30I2A0ufntC+XPI6a3tXeX347Pbfhtt/RkP/Lv3+2fG/Fcd/9vyG5z+7/jfj+s++r49RM8Ll 8VL9EmS9UzN4XuOmpPkkK3q3cfc0P8vFJtmqmqfjqLDE9BpoQ6f6Z5GmmO+dR6H1TjLYLPYN 0npIXff0fB33Tu3ocpKXxu5jUCJdH9Lx/ZDFQ5xBox3pCxCBrxcM8U++CSYWrWmytL+Bn4NX K75PYnZmbgeze0vhjybRgDt8MuGgLFoT6qsvAnaae1jdPJoPfvD3Xe3jn7pSJNAhVEoz67Qm gDmO/ZIbc90xQDl4YsZJQcsMqEDmHp6fE/FJk+QtABUXRqrsGqmzb4NWXflTHOon2ha0g83g kPhRqbSVIZ5C9RnJjlbYiYoarqD/vPvhm9eNXA0puLqe6RhL8QNO9WUmVQKIAahurKjy1VHo 7UjwH0Q9OYl6ehL17CTqFydRX55E/fIk6quTqK9Pog6DLvJxpweKjZqJtLdMVgWV9368EuDr s/Klru50fRpBUS0vCNmVb3elaAsTahbqOvcDSgss76bJQTMN86uv1vJiqU2TmQLQF/zMvdPh a8GqOOlbiqPMkcgbxCD+fTFnHfOAlRpZhSGqpbhk7mwP1G1669pO9+SaSaVOceFHw5IsovLF nwg36+mA5Fa9GBBXfIAnpGcD6Mr0H47qmPR1mb5+6fCbEmFwEQTTr+SqxMAuoXwD0ui6w2aD a7fXTmDVHIeHVPcfJsfYT1+0+RzXWYc3vl9cd/fugr3nvkP/ldW9Nx/23Gw47d7CfcsTTlrN 8Hmnh877JZU0O0pYCRX1KWTqRmMuo0oL2wkvpdUYHfLKTQpactjza1Lnm3DkwGlIKiHbJBbP lych5NJQn0RKwFrre3J98bJz/9FTwPbGfaiUIW0gvaMTyilK+Kh54hlehM1rqObE0wFSV1cn zmurk65nKrXXU3rlK5rE5vb5H6NA/OvC0BvxzAlcIFapRezLs0oCG48Wi52FF85CN56S1u5h WlwWOBVPsGtds40kNd8D10c2DQxTgvkb9FgJCkJWLxs1AsNm39R+AltuaN1ONA+HQFDwCokv lxyEDhy0FIWVCwXFYoNQZYoqXtQ4tFylg774kxk1ZgzkP1ZsuF3dLGota5D6Mw89tpTbW/Oc HlytsuL11aXLNQOna3ZeOJ9dWbEU7yBaRcllnvKZ54bjboG1pMcu4uXs6EXo7xWzl7PhK6hL 27bS/jw2+VrzWMdXm8m589cxsfrk4TR2uaeT0fyV6lbE/wkE1x526ZP/MLgcWUg7T/9V76gp Uc/G9KjYf+f+q7H908A2sJ2uPQtSiBe/xkMHMNhhRDumH7dWUbVW7V5KA3RnaUbVsq12s6aI 5oU22xjtTV4ZQ3eduelJq/r9g0BVoznK2nCobOfvyackTZE+RhB4/SQQmt5dkS0SGts0XnAx ReHfvL8EU38a/FWxgC5qPE/eoNSDJlgcyFnDvZNMR/MgDGr8Nb4hhJhJQL2qwRf2MLkJcVTr YZRrTS79fxepPwmCS821xcCcpOSNTFx38h5lT/YoGxZ1R5b8e8ygU6qt7UdKitzzvV7y2Wj+ PdnGOPMEly10a95rxkiUgOysbT6p5A/Cv7TE8mRD+m/fiQZOccSlX0JPXVDREo7mRmcWj7lH ljZn2RM4GdepJV5b1Ua541Z47IuYxjGNK2Am9hFIIxzH7v/v1fz/UEsHCMRAYZB0CwAAN0sA AFBLAwQUAAAAAABYD/o0exBbpvYEAAD2BAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0i MS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG9mZmljZTpkb2N1bWVudC1tZXRhIHhtbG5zOm9m ZmljZT0idXJuOm9hc2lzOm5hbWVzOnRjOm9wZW5kb2N1bWVudDp4bWxuczpvZmZpY2U6MS4w IiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM6ZGM9 Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIiB4bWxuczptZXRhPSJ1cm46b2Fz aXM6bmFtZXM6dGM6b3BlbmRvY3VtZW50OnhtbG5zOm1ldGE6MS4wIiB4bWxuczpvb289Imh0 dHA6Ly9vcGVub2ZmaWNlLm9yZy8yMDA0L29mZmljZSIgb2ZmaWNlOnZlcnNpb249IjEuMCI+ PG9mZmljZTptZXRhPjxtZXRhOmdlbmVyYXRvcj5PcGVuT2ZmaWNlLm9yZy8yLjAkV2luMzIg T3Blbk9mZmljZS5vcmdfcHJvamVjdC82ODBtNyRCdWlsZC05MDQ0PC9tZXRhOmdlbmVyYXRv cj48bWV0YTppbml0aWFsLWNyZWF0b3I+QW5kcmV3IE4gRG93ZGVuPC9tZXRhOmluaXRpYWwt Y3JlYXRvcj48bWV0YTpjcmVhdGlvbi1kYXRlPjIwMDYtMDMtMjdUMTQ6MDY6Mzk8L21ldGE6 Y3JlYXRpb24tZGF0ZT48ZGM6Y3JlYXRvcj5BbmRyZXcgTiBEb3dkZW48L2RjOmNyZWF0b3I+ PGRjOmRhdGU+MjAwNi0wNy0yNlQxMzo1ODo0NzwvZGM6ZGF0ZT48bWV0YTpwcmludGVkLWJ5 PkFuZHJldyBOIERvd2RlbjwvbWV0YTpwcmludGVkLWJ5PjxtZXRhOnByaW50LWRhdGU+MjAw Ni0wNC0wNFQxNTo0NzozNTwvbWV0YTpwcmludC1kYXRlPjxkYzpsYW5ndWFnZT5lbi1VUzwv ZGM6bGFuZ3VhZ2U+PG1ldGE6ZWRpdGluZy1jeWNsZXM+MTcxPC9tZXRhOmVkaXRpbmctY3lj bGVzPjxtZXRhOmVkaXRpbmctZHVyYXRpb24+UDFEVDE2SDQ1TTEwUzwvbWV0YTplZGl0aW5n LWR1cmF0aW9uPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMSIvPjxtZXRh OnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8gMiIvPjxtZXRhOnVzZXItZGVmaW5lZCBt ZXRhOm5hbWU9IkluZm8gMyIvPjxtZXRhOnVzZXItZGVmaW5lZCBtZXRhOm5hbWU9IkluZm8g NCIvPjxtZXRhOmRvY3VtZW50LXN0YXRpc3RpYyBtZXRhOnRhYmxlLWNvdW50PSIzIiBtZXRh OmltYWdlLWNvdW50PSIwIiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50 PSI2IiBtZXRhOnBhcmFncmFwaC1jb3VudD0iMzkyIiBtZXRhOndvcmQtY291bnQ9IjE1NDgi IG1ldGE6Y2hhcmFjdGVyLWNvdW50PSI5MjI0Ii8+PC9vZmZpY2U6bWV0YT48L29mZmljZTpk b2N1bWVudC1tZXRhPlBLAwQUAAgACABYD/o0AAAAAAAAAAAAAAAAGAAAAFRodW1ibmFpbHMv dGh1bWJuYWlsLnBuZwGGBXn6iVBORw0KGgoAAAANSUhEUgAAAHEAAACgCAYAAAA7HINaAAAF TUlEQVR4nO2da26kMBCEM9KeIpdNctlcIxtWi4Qsv7ptQ7uqvj/zwPhBTYMpG8+fn5+fN7E3 f56ugBhHIgIgEQGQiABIRAAkIgDDIr5er3/3KL+3Kq/x6pTLmJ3/ijw9Zc+oh0nEU7CDo+Dr 57My19dc2lya63fXcnrSWut/zStX19ll5NpUO3ae8k0ippnmCjm/q6XNpWm9L2331N/SjlVl tMq0lK9rIgASEQCJCIBLxJ4OiSWvGfkw4+6dXj+XvrfmO5oPGkt6pyff39//Xt/f36vbI1Oq e44n2mOpn1nEa4N2EKvG7vU/MYto+YVEB6UtQ73TnMtQSjdSzgqOun5+fha3f3x8vL6+voau yUce3n0t/QGziD1OzC60DvKICHdiFrHkN3oo5XPXj6Hl7+b2ifhDdUfirMY8eVBQziquSDxe SyMWJXp+6bU0pdEGa/3TtqQGQ6nuI+WsZuiaaI3Knl96Lc3sg7lr5KW4IzFHLTpHxuhEneHe aWn7zDG6VeRG2Fun8Nq2p9oX6prYs6+V2oHtuTT07v8k4a6JPfvOgrZjE6l32lNm7/boQtUI F4l39k7pI/HKDAfniQOlSOz8PjK9kXglYjup59jQRqKIB7WIltNp5EilFlGnUwBakbiLsNQi KhIB8MyhiThlg1rEiIJ4oBaRdo4NErRzbJBoDQqnRBWWWsSREZlIUIs4Mj3j3H5HPVtQizg6 PSMK1CLKsQFg195oCrWIcmwAiCiIB2oR5dgAIMcGANopi0jsGnkp1CKiQC3i7Kei0u3za5yH WkTap6KQUMcGAHVsAJDtBkBEQTxMXXhhN1Da4orEu5/oXcEda7ud+Xj2u2Vttzuf6F2F1nZz RFvrhjp9b62bFdpRjJFZYT031HcepCj1GCXs6hm1fKx1LkF7s3/n6hmr2TXyUkKsnvHUAbQ+ KRx1Rhz16hnWSIzaRmrHxnofGPWWg1rEqKJYke0GgPuaaF1gL93/aahtt5OeDk4UwUrIdptk u+XSnO+tdbMi222i7ZZLcwey3WS7hUG22wPlziaE7XbmMbI/M9S2G613ioS8UwBovVMUq+qg 5tgU0ods+/S/GdqF6/UwIkttt/TesNfpOLdby1tJ7XT6tHdqYfqUxWhC1ZB36uySt/ax1mcE eacbd8lP5J2Ce6fQIso7jQe1d2qx3UpEEJ/aO6WNRCRobTckoopihdo7RWnLkki8+1bBA/WU Rc/tRFRku004FaX5yHbzceuUxVp+TyDbbbHtlovS2daYbLc3e1RabbdapMxg18hLmXqLUYvO 6zZPRVeQRmJP9PduW1PjPNN7p7XojCTgQc9ZpVbnKO3Z+prYKqt1kDWN/y32NdE6aB1dqBqQ kXjdx5J+V2AjsQfa0+nMQeE08qz7j0J7Op09KPzkwfOM7EcUm3o8kTYSkbBEYmSRqUVUJALQ isRdhKUWUZEowkAtov7cBIDrRKne6Rm/It5TOQPUItJOzxDxoBaRdo4NEruePlOoRVwxx+aJ HwO1iLRzbJCQ7QaArokAyLEBIKIgHqhFpH0qCgnZbgDIsQFg18hLoRZx1LG5q54tqEUcdWyi QC0iCtQi0j6LgYQ6NgDQ2m4oS2kdWP9S4f8+4dpvEnHnUw4y1KdTFCQiABIRAIkIgEQEQCIC IBEBkIgASEQAJCIAEhEAt4ilpSitC9N6FrKNtvjtTDxtM4mYzkMpjWhc05Vej3TH+9J8z9r7 tOzSio89ny3tH6W0QmVuno+lbq5RDOuqiqXXNJ3nfatukebMtOb0WI/via6JAEhEACQiABIR AIkIgEQE4C9Wm1yDGJJAygAAAABJRU5ErkJgglBLBwhPbpo1iwUAAIYFAABQSwMEFAAIAAgA WA/6NAAAAAAAAAAAAAAAAAwAAABzZXR0aW5ncy54bWztWklz4jgUvs+voHztSrMkk06ohC5h IE1CwhqS5ibsh/EgSx5JDjC/fp4MZBKCp2mDp+bQPuBNepu+t+iZq6+LgOVeQCpf8Gur+Llg 5YA7wvW5d209DhonF9bXym9XYjLxHSi7wokC4PpEgdY4ROVwOlfl1etrK5K8LKjyVZnTAFRZ O2URAt9MK78dXY6ZrZ4smM9n19ZU67Ccz8/n88/z089Cevni5eVlPn67GeoIPvG9fVmtRr9l JYR4ZWQmrISJmZUKhbP86t7KrYV8Z5rKxg4b9StXawar04mvITC2ya0fG9GuLWRZfvFh/mo1 a9e893OGOJ5IoAMRWps3ehniG59rq1L8UiieF6/yH8nsT7oFE72Ldql0XjiM8pPv6ulOsS9O Ly4Po/0NfG+6U+5i6exLKR3x/lTMe+AizsCeUu6B2mIwFoIB5VZFywjS8WjyqhRzBffChSTq E8rU3uRPAhqe+NyFBbgfbbUbZPEcdA+53M/iTXdLVKUlItiqGDynNLahm4S902LhAFQnOUuh eHmaGtLKHzPIwldiwpn4d0y5l+QnpcL52flBpKtCaxHsdvDS+WlKuUdCBAMktY24qZCGcnqi DepoIRPIfrlI6c6qDwwcDW5D4oMUHr3j4Vv3THq99vjdAzDD7J+TVg8iSTVmuJ9JTsR1O1TS AUUs9EPqmIhwjIj2nksHI43ugcnAsB2GjkG/HWkT8FvIgX33gbnqIQrGILPRpoU1zGPoUr0r ARyG8dhQ9SDUyw7NJnV5XEho+FJpVAOaiECum/yH5krPEbOwRK8FaYsglKBMDZYcG1KG4Nhu fZSfwa0YJ9rtgEVfLXhDYmCDIGR4fXxTxVp0aAjS8OmDjrYzyjE0QZeP41x7MsFAkQHGYjVM ms0Iw+vyriOFxqiNcLqD5TYXquD8rOpzKpdWfk+R4yCYgbzGAzSJtFhhKCOD2wKTjWBZrSfI nXh8a+fKzOt8yhem3WZ9MXVKw2U/GBaatd49+Z8e/QbxBjeNv0bPt3ej5673UJ8nDX0ipE5K pLm5r5LG6BHPs3GXkPtirz2c14lNqs1Hu3r//fmBObOQuTYpDBK51+tI1iG1rt399IlUuzi/ W/vTDi6aI0OfXJAWqVcNXzzXzHlwMyy4N8NlOm3r/1x2zU9zpQceeXPsVL1a7z/+Pmx6eIly 4s9oNHrek7/Yur9/5Ue8nxD71/Hr+O+O60PKKkwginC3yiifqYaQpsKyKXMiFtflWRXWhHOh Yw7J9WjKuqolqNsD6grOPqTY45QiZvex3ngMRJyBbWDJWewwZvUF5jFOWQtVymZvQMKQLR8V yBrV9PipuGE2N1mWEn36AsNVo7TNbSbUcRpcH5ncMDGmrLbu8ZotVRZr3lR3uOBE+ZR3Iu7o KCtHJMz3OMK3r0XYEcr/NzYHVJLMD4l63VER7qB3g/skcahssGVc12dhRzuSEpfJgNqUfObc F5F0PkSbVU9xj4q7Jh6EtmmoIwk1Seft8R+qzc2OIQPx47jSE/M7gCx2VOsC+eFj82jTY/3W ybXQbvIWdO6sdQCXBl0ks9nD7LhLUL4LcgAL/SRp2OZoeARsZk0f07rMqpehWnQMrzEki02/ AkzjAcSZ/AftsfR67OjBEd3XuGk8Pq9XjTYACDNRKfbuHijQRjOitTT10EMUNETyQh3aOJFC heBkgYOY/g1aa+o7GQCZMCbmMY9bMbYpd4BlkDveh3BbBAHl7o5OXNz9T1kvxut+GyntT5bG Z9STr6f3lEeUVSXQWYaAxjiGi7/JvZmgeh3nTdPUfJ82dQtdimgbcZugj4t6IkEJFhmJUqvX Zm6W3ex109GDKnVmnhQRT+zQHxt8qbNYLLOpGuKvHNmsM+7inJkJV2lyY+IHnfyHvx3kk/6Q UfkbUEsHCIrh+C+VBQAA0iEAAFBLAwQUAAgACABYD/o0AAAAAAAAAAAAAAAAFQAAAE1FVEEt SU5GL21hbmlmZXN0LnhtbLWVTW7DIBBG9zmFxd6m7aqy4kRqpZ4gPcAEjx0kDIgZovj2xZHy 0zaqmtbsQIL3hsH+WK4Pgyn2GEg724jH6kEUaJVrte0b8b55K5/FerVYDmB1h8T1aVCkfZbO 00bEYGsHpKm2MCDVrGrn0bZOxQEt15/X15NptSgu4E4bLNPCMBYXGbYaSh49NgK8N1oBpzrl 3rbV0VVdKyrGA4vL7i4aU3rgXSOkkHfJblNene10H8OxCHqSxMCRthDy4EEpNJimLkgVQ5iO mLqY3ZVF0BkHjJng3vno0ycQM+GD6wNSvpueSs8GZ+dMNrgeoEeSL5oH8JTVcSf7a15QtNPf U0VdqWvB72r4h3yrLYTxtsbA6CKXCtQO71RMYSenOLgJTkfkv+XFz1zi0SDNjh2QYbZs2+zi sLWgDUk+DStv+7nh8zYWmdObe27tUn57clcfUEsHCIP3gpxPAQAArQcAAFBLAQIUABQAAAAA AFgP+jRexjIMJwAAACcAAAAIAAAAAAAAAAAAAAAAAAAAAABtaW1ldHlwZVBLAQIUABQAAAAA AFgP+jQAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAAE0AAABDb25maWd1cmF0aW9uczIvc3Rh dHVzYmFyL1BLAQIUABQACAAIAFgP+jQAAAAAAgAAAAAAAAAnAAAAAAAAAAAAAAAAAIUAAABD b25maWd1cmF0aW9uczIvYWNjZWxlcmF0b3IvY3VycmVudC54bWxQSwECFAAUAAAAAABYD/o0 AAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAADcAAAAQ29uZmlndXJhdGlvbnMyL2Zsb2F0ZXIv UEsBAhQAFAAAAAAAWA/6NAAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAAEgEAAENvbmZpZ3Vy YXRpb25zMi9wb3B1cG1lbnUvUEsBAhQAFAAAAAAAWA/6NAAAAAAAAAAAAAAAABwAAAAAAAAA AAAAAAAASgEAAENvbmZpZ3VyYXRpb25zMi9wcm9ncmVzc2Jhci9QSwECFAAUAAAAAABYD/o0 AAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAACEAQAAQ29uZmlndXJhdGlvbnMyL21lbnViYXIv UEsBAhQAFAAAAAAAWA/6NAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAAugEAAENvbmZpZ3Vy YXRpb25zMi90b29sYmFyL1BLAQIUABQAAAAAAFgP+jQAAAAAAAAAAAAAAAAfAAAAAAAAAAAA AAAAAPABAABDb25maWd1cmF0aW9uczIvaW1hZ2VzL0JpdG1hcHMvUEsBAhQAFAAIAAgAWA/6 NCYX9IgnAAAAQgAAAAwAAAAAAAAAAAAAAAAALQIAAGxheW91dC1jYWNoZVBLAQIUABQACAAI AFgP+jRSLwiMKBgAAMM2AgALAAAAAAAAAAAAAAAAAI4CAABjb250ZW50LnhtbFBLAQIUABQA CAAIAFgP+jTEQGGQdAsAADdLAAAKAAAAAAAAAAAAAAAAAO8aAABzdHlsZXMueG1sUEsBAhQA FAAAAAAAWA/6NHsQW6b2BAAA9gQAAAgAAAAAAAAAAAAAAAAAmyYAAG1ldGEueG1sUEsBAhQA FAAIAAgAWA/6NE9umjWLBQAAhgUAABgAAAAAAAAAAAAAAAAAtysAAFRodW1ibmFpbHMvdGh1 bWJuYWlsLnBuZ1BLAQIUABQACAAIAFgP+jSK4fgvlQUAANIhAAAMAAAAAAAAAAAAAAAAAIgx AABzZXR0aW5ncy54bWxQSwECFAAUAAgACABYD/o0g/eCnE8BAACtBwAAFQAAAAAAAAAAAAAA AABXNwAATUVUQS1JTkYvbWFuaWZlc3QueG1sUEsFBgAAAAAQABAAKAQAAOk4AAAAAA== --------------040001060008080208090908-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3EEC67F74A for ; Tue, 25 Jul 2006 21:48:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F17C14228E for ; Tue, 25 Jul 2006 21:48:38 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02933-07 for ; Tue, 25 Jul 2006 21:48:36 -0700 (PDT) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D1E5142262 for ; Tue, 25 Jul 2006 21:48:36 -0700 (PDT) In-Reply-To: <44C6CC6E.4080704@softdesign.net.nz> To: Andrew N Dowden MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Pat R Egen Date: Wed, 26 Jul 2006 00:48:33 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 07/26/2006 12:48:36 AM, Serialize complete at 07/26/2006 12:48:36 AM Content-Type: multipart/alternative; boundary="=_alternative 001A6A83852571B7_=" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.0 tagged_above=-50.0 required=4.0 tests=AWL, HTML_20_30, HTML_MESSAGE X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Re: current test data: NZ, US/Canada (iCal scripts) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 04:48:38 -0000 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"
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_=-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BC0D87F8A2; Tue, 25 Jul 2006 20:42:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id ACD4F14228E; Tue, 25 Jul 2006 20:42:43 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23336-03; Tue, 25 Jul 2006 20:42:40 -0700 (PDT) Received: from mail.mhsoftware.com (ip-216-17-130-186.rev.frii.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B268114228D; Tue, 25 Jul 2006 20:42:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id 59E042926F0D; Tue, 25 Jul 2006 21:42:40 -0600 (MDT) Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01663-02; Tue, 25 Jul 2006 21:42:39 -0600 (MDT) Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 9464B2926D87; Tue, 25 Jul 2006 21:42:39 -0600 (MDT) Message-ID: <44C6E4AE.5090106@mhsoftware.com> Date: Tue, 25 Jul 2006 21:42:38 -0600 From: George Sexton Organization: MH Software, Inc. User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mhsoftware.com X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 03:42:43 -0000 Lisa Dusseault wrote: > > 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 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: > 1, 2, 3, 4, 5 and -1 > 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/ Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AFECE7F8A8 for ; Tue, 25 Jul 2006 20:21:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A0A5D142295 for ; Tue, 25 Jul 2006 20:21:52 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24954-03 for ; Tue, 25 Jul 2006 20:21:52 -0700 (PDT) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 22D5F142293 for ; Tue, 25 Jul 2006 20:21:52 -0700 (PDT) Received: from localhost.localdomain (webmail1.server.rpi.edu [128.113.2.131]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6Q3LnwW006524 for ; Tue, 25 Jul 2006 23:21:50 -0400 Message-Id: <200607260321.k6Q3LnwW006524@smtp6.server.rpi.edu> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Originating-Ip: 72.224.123.130 X-Http_host: webmail.rpi.edu Date: Tue, 25 Jul 2006 23:21:49 -0400 MIME-Version: 1.0 Organization: Rensselaer Polytechnic Institute Subject: Re: [Ietf-calsify] RRULE simplificatiion X-Mailer: EMUmail 6.0.1.27 From: douglm@rpi.edu X-Browser: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 X-Webmail-User: douglm@imap.server.rpi.edu To: ietf-calsify@osafoundation.org X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, NO_REAL_NAME X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: douglm@rpi.edu List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 03:21:52 -0000 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=========== Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7557E7F5E9 for ; Tue, 25 Jul 2006 19:21:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6006A142264 for ; Tue, 25 Jul 2006 19:21:47 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12775-05 for ; Tue, 25 Jul 2006 19:21:43 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by laweleka.osafoundation.org (Postfix) with ESMTP id DA850142260 for ; Tue, 25 Jul 2006 19:21:43 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc13) with SMTP id <20060726022142m1300mfogke>; Wed, 26 Jul 2006 02:21:42 +0000 From: "Tim Hare" To: "'ietf-calsify'" Date: Tue, 25 Jul 2006 22:21:41 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C6B038.B4759620" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcawWjrb6zuUCXTDSoyuTNxjuk4Sgg== Message-Id: <20060726022143.DA850142260@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.2 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, HTML_20_30, HTML_MESSAGE, MSGID_FROM_MTA_ID X-Spam-Level: ** Subject: [Ietf-calsify] RRULE simplificatiion X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 02:21:47 -0000 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 Interested Bystander, Non-Inc. ------=_NextPart_000_0024_01C6B038.B4759620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RRULE simplificatiion

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.

------=_NextPart_000_0024_01C6B038.B4759620-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CD3ED7F8A3 for ; Tue, 25 Jul 2006 18:59:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BC38014228D for ; Tue, 25 Jul 2006 18:59:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10298-06 for ; Tue, 25 Jul 2006 18:59:23 -0700 (PDT) Received: from grunt14.ihug.co.nz (grunt14.ihug.co.nz [203.109.254.61]) by laweleka.osafoundation.org (Postfix) with ESMTP id 933F6142281 for ; Tue, 25 Jul 2006 18:59:22 -0700 (PDT) Received: from 203-109-180-137.dialup.ihug.co.nz ([127.0.0.1]) [203.109.180.137] by grunt14.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1G5Yg3-0006EF-00; Wed, 26 Jul 2006 13:59:11 +1200 Message-ID: <44C6CC6E.4080704@softdesign.net.nz> Date: Wed, 26 Jul 2006 13:59:10 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Patricia Egen Content-Type: multipart/mixed; boundary="------------060401080206090305060903" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=UPPERCASE_50_75 X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] current test data: NZ, US/Canada (iCal scripts) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 01:59:25 -0000 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 Dowden Software Associates P O Box 31 132, Lower Hutt 5040, NEW ZEALAND --------------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:20060428T231323Z-30302-008@softdesign.net.nz 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:20060428T231323Z-30303-008@softdesign.net.nz 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:20060428T231323Z-30304-008@softdesign.net.nz 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:20060428T231323Z-30305-008@softdesign.net.nz 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:20060428T231323Z-30306-008@softdesign.net.nz 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:20060428T231323Z-30307-008@softdesign.net.nz 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:20060428T231323Z-30308-008@softdesign.net.nz 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:20060428T231323Z-30309-008@softdesign.net.nz 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:20060428T231932Z-30402-006@softdesign.net.nz 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:20060428T231932Z-30403-006@softdesign.net.nz 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:20060428T231932Z-30404-006@softdesign.net.nz 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:20060428T231932Z-30405-006@softdesign.net.nz 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:20060428T231932Z-30406-006@softdesign.net.nz 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:20060428T231932Z-30407-006@softdesign.net.nz 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:20060428T231932Z-30408-006@softdesign.net.nz 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:20060428T231932Z-30409-006@softdesign.net.nz 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:20060428T231932Z-30410-006@softdesign.net.nz 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:20060428T231932Z-30411-006@softdesign.net.nz 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:20060428T231932Z-30412-006@softdesign.net.nz 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:20060428T231932Z-30413-006@softdesign.net.nz 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:20060428T231932Z-30414-006@softdesign.net.nz 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:20060428T231932Z-30415-006@softdesign.net.nz 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:20060428T231932Z-30416-006@softdesign.net.nz 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:20060324T002217Z-30601-003@softdesign.net.nz 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:20060324T002217Z-30602-003@softdesign.net.nz 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:20060324T002217Z-30603-003@softdesign.net.nz 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:20060324T002217Z-30604-003@softdesign.net.nz 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:20060324T002217Z-30605-003@softdesign.net.nz 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:20060324T002217Z-30606-003@softdesign.net.nz 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:20060324T002217Z-30607-003@softdesign.net.nz 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:20060324T002217Z-30608-003@softdesign.net.nz 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:20060324T002217Z-30609-003@softdesign.net.nz 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:20060324T002217Z-30610-003@softdesign.net.nz 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:20060324T002217Z-30611-003@softdesign.net.nz 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:20060324T002217Z-30612-003@softdesign.net.nz 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:20060324T002217Z-30613-003@softdesign.net.nz 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:20060324T002217Z-30614-003@softdesign.net.nz 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:20060324T002217Z-30615-003@softdesign.net.nz 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:20060324T002217Z-30616-003@softdesign.net.nz 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:20060324T002217Z-30617-003@softdesign.net.nz 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:20060324T002217Z-30618-003@softdesign.net.nz 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:20060324T002217Z-30619-003@softdesign.net.nz 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:20060324T002217Z-30620-003@softdesign.net.nz 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:20060324T002217Z-30621-003@softdesign.net.nz 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:20060324T002217Z-30622-003@softdesign.net.nz 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:20060324T002217Z-30623-003@softdesign.net.nz 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:20060324T002217Z-30624-003@softdesign.net.nz 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:20060324T002217Z-30625-003@softdesign.net.nz 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:20060324T002217Z-30626-003@softdesign.net.nz 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:20060324T002217Z-30627-003@softdesign.net.nz 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:20060324T002217Z-30628-003@softdesign.net.nz 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:20060324T002217Z-30629-003@softdesign.net.nz 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:20060324T002217Z-30630-003@softdesign.net.nz 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:20060324T002217Z-30631-003@softdesign.net.nz 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:20060324T002217Z-30632-003@softdesign.net.nz 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:20060324T002217Z-30501-003@softdesign.net.nz 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:20060324T002217Z-30502-003@softdesign.net.nz 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:20060324T002217Z-30503-003@softdesign.net.nz 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:20060324T002217Z-30504-003@softdesign.net.nz 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:20060324T002217Z-30505-003@softdesign.net.nz 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:20060324T002217Z-30506-003@softdesign.net.nz 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:20060324T002217Z-30507-003@softdesign.net.nz 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:20060324T002217Z-30508-003@softdesign.net.nz 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:20060324T002217Z-30509-003@softdesign.net.nz 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:20060324T002217Z-30510-003@softdesign.net.nz 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-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0FE117F74A for ; Tue, 25 Jul 2006 18:50:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00F35142281 for ; Tue, 25 Jul 2006 18:50:50 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13777-01 for ; Tue, 25 Jul 2006 18:50:47 -0700 (PDT) Received: from mail.evdb.com (mail.evdb.com [209.126.252.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 89C18142287 for ; Tue, 25 Jul 2006 18:50:47 -0700 (PDT) Received: (qmail 31326 invoked by uid 513); 25 Jul 2006 18:50:46 -0700 Received: from chuck@evdb.com by mail.evdb.com by uid 511 with qmail-scanner-1.22-st-qms (spamassassin: 2.63. Clear:RC:1(67.52.157.90):. Processed in 0.01504 secs); 26 Jul 2006 01:50:46 -0000 X-Antivirus-MYDOMAIN-Mail-From: chuck@evdb.com via mail.evdb.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.52.157.90):. Processed in 0.01504 secs Process 31322) Received: from rrcs-67-52-157-90.west.biz.rr.com (HELO ?192.168.1.111?) (chuck@evdb.com@67.52.157.90) by mail.evdb.com with RC4-SHA encrypted SMTP; 25 Jul 2006 18:50:46 -0700 In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <167C8B30-AB6E-48B3-8A69-EFCADD014A31@evdb.com> Content-Transfer-Encoding: 7bit From: Chuck Norris Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs Date: Tue, 25 Jul 2006 18:50:46 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 01:50:50 -0000 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: > > 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. > > > > Feedback? > > thanks! > Lisa_______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3D5A97F8D7; Tue, 25 Jul 2006 18:03:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2EDAB142271; Tue, 25 Jul 2006 18:03:44 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26944-06; Tue, 25 Jul 2006 18:03:42 -0700 (PDT) Received: from www.egenconsulting.com (www.egenconsulting.com [208.31.106.82]) by laweleka.osafoundation.org (Postfix) with ESMTP id CD13614223D; Tue, 25 Jul 2006 18:03:41 -0700 (PDT) In-Reply-To: <44C6BCDB.8080805@softdesign.net.nz> To: Andrew N Dowden Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Pat R Egen Date: Tue, 25 Jul 2006 21:03:38 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 6.5.2|June 01, 2004) at 07/25/2006 09:03:42 PM, Serialize complete at 07/25/2006 09:03:42 PM Content-Type: multipart/alternative; boundary="=_alternative 0005D326852571B7_=" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE X-Spam-Level: Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 01:03:44 -0000 This is a multipart message in MIME format. --=_alternative 0005D326852571B7_= Content-Type: text/plain; charset="US-ASCII" 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 Sent by: ietf-calsify-bounces@osafoundation.org 07/25/2006 08:52 PM To ietf-calsify@osafoundation.org cc Subject Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs Lisa Dusseault wrote: > 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. 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=_alternative 0005D326852571B7_= Content-Type: text/html; charset="US-ASCII"
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 <andrew_dowden@softdesign.net.nz>
Sent by: ietf-calsify-bounces@osafoundation.org

07/25/2006 08:52 PM

To
ietf-calsify@osafoundation.org
cc
Subject
Re: [Ietf-calsify] RRule simplification for interpersonal calendar        GUIs





Lisa Dusseault wrote:
> 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.
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


_______________________________________________
Ietf-calsify mailing list
Ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
--=_alternative 0005D326852571B7_=-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5239F7F74B; Tue, 25 Jul 2006 18:01:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 42CF2142271; Tue, 25 Jul 2006 18:01:30 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28594-10; Tue, 25 Jul 2006 18:01:27 -0700 (PDT) Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BA4A714223D; Tue, 25 Jul 2006 18:01:27 -0700 (PDT) Received: from [192.168.1.178] (dsl092-180-250.sfo1.dsl.speakeasy.net [66.92.180.250]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id 49733212877; Tue, 25 Jul 2006 18:01:27 -0700 (PDT) In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Tantek_=C7elik?= Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs Date: Tue, 25 Jul 2006 18:01:46 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: IETF-iCalendar X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 01:01:30 -0000 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= > should consider discouraging for interpersonal calendaring. I *strongly* agree with this methodology. 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= > illustrates the approach rather than limits it. > > 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= > you can find inside the proposal. > > > Feedback? I cannot find anything in your analysis that I disagree with. Lisa, thanks very much for doing this research and analysis. It was=20 very illuminating, and you have my support. Thanks, Tantek -- Tantek =C7elik Chief Technologist, Technorati, Inc. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B929D7F8D8 for ; Tue, 25 Jul 2006 17:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AA1641422A3 for ; Tue, 25 Jul 2006 17:52:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03249-05 for ; Tue, 25 Jul 2006 17:52:48 -0700 (PDT) Received: from grunt3.ihug.co.nz (grunt3.ihug.co.nz [203.109.254.43]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09B9014225A for ; Tue, 25 Jul 2006 17:52:48 -0700 (PDT) Received: from 203-109-180-137.dialup.ihug.co.nz ([127.0.0.1]) [203.109.180.137] by grunt3.ihug.co.nz with asmtp (Exim 3.35 #1 (Debian)) id 1G5Xdl-00065o-00; Wed, 26 Jul 2006 12:52:46 +1200 Message-ID: <44C6BCDB.8080805@softdesign.net.nz> Date: Wed, 26 Jul 2006 12:52:43 +1200 From: Andrew N Dowden Organization: Dowden Software Associates User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs References: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> In-Reply-To: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 00:52:49 -0000 Lisa Dusseault wrote: > 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. 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3E4E77F8A3 for ; Tue, 25 Jul 2006 17:24:22 -0700 (PDT) Received: from [192.168.103.59] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4AD1A142295 for ; Tue, 25 Jul 2006 17:24:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: IETF-iCalendar Message-Id: <774F9B5D-8557-4133-83D0-D6C6EED7FE80@osafoundation.org> Content-Type: multipart/mixed; boundary=Apple-Mail-5--527413468 From: Lisa Dusseault Date: Tue, 25 Jul 2006 17:24:05 -0700 X-Mailer: Apple Mail (2.752.2) Subject: [Ietf-calsify] RRule simplification for interpersonal calendar GUIs X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 00:24:22 -0000 --Apple-Mail-5--527413468 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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. --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 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 =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 #1. Only one recurrence rule per RRULE #2. No EXRULE #3. No FREQ =3D 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 =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) #10. MUST include the INTERVAL #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 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 = but I've never = seen this in actual interpersonal scheduling. An example at 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. 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=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 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=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-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 17F267F6BA for ; Tue, 25 Jul 2006 13:00:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 09B6314228D for ; Tue, 25 Jul 2006 13:00:09 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29813-04 for ; Tue, 25 Jul 2006 13:00:08 -0700 (PDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1386A14224D for ; Tue, 25 Jul 2006 13:00:07 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PK01p0006020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 20:00:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5T4T-0003q1-Of; Tue, 25 Jul 2006 16:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 25 Jul 2006 16:00:01 -0400 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] WG Action: RECHARTER: Calendaring and Scheduling Standards Simplification (calsify) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 20:00:09 -0000 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 Aki Niemi Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-calsify@osafoundation.org 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 08C8B7F656 for ; Fri, 21 Jul 2006 09:01:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C230C1422A2 for ; Fri, 21 Jul 2006 09:01:07 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17767-07 for ; Fri, 21 Jul 2006 09:01:05 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F1C2114229E for ; Fri, 21 Jul 2006 09:01:04 -0700 (PDT) Received: from [17.101.35.49] ([17.101.35.49]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k6LG0r4f022725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 12:00:56 -0400 Date: Fri, 21 Jul 2006 12:00:48 -0400 From: Cyrus Daboo To: Bernard Desruisseaux Message-ID: <44C02FD6CF4A426162CC3BFC@Cyrus-Daboo.local> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] 2445bis: clarify allowed value types of date-time property combinations X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 16:01:08 -0000 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 832017FA3A for ; Sat, 15 Jul 2006 07:48:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 73F24142278 for ; Sat, 15 Jul 2006 07:48:02 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04445-02 for ; Sat, 15 Jul 2006 07:48:01 -0700 (PDT) Received: from alnrmhc11.comcast.net (alnrmhc11.comcast.net [204.127.225.91]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0420B142277 for ; Sat, 15 Jul 2006 07:48:00 -0700 (PDT) Received: from thare (c-68-84-31-33.hsd1.fl.comcast.net[68.84.31.33]) by comcast.net (alnrmhc11) with SMTP id <20060715144800b1100o7tdie>; Sat, 15 Jul 2006 14:48:00 +0000 From: "Tim Hare" To: "'ietf-calsify'" 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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcanwEA9itBPz5DtTOC5tpL1dnvpugAWzNwQ In-Reply-To: <44B8635D.3070301@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <20060715144800.0420B142277@laweleka.osafoundation.org> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=2.5 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS, MSGID_FROM_MTA_ID, SUBJ_HAS_SPACES X-Spam-Level: ** X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 14:48:02 -0000 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 Interested Bystander, Non-Inc. -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Eliot Lear Sent: Friday, July 14, 2006 11:39 PM To: Alexey Melnikov Cc: ietf-calsify@osafoundation.org 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 : >> >> 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 _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F07C7FA5A for ; Fri, 14 Jul 2006 20:39:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7F809142297 for ; Fri, 14 Jul 2006 20:39:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07883-04 for ; Fri, 14 Jul 2006 20:39:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id 337BF14227C for ; Fri, 14 Jul 2006 20:39:15 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 14 Jul 2006 20:39:14 -0700 X-IronPort-AV: i="4.06,245,1149490800"; d="scan'208"; a="1838827559:sNHT1979026490" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6F3dDLj022971; Fri, 14 Jul 2006 20:39:13 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6F3dDiB009717; Fri, 14 Jul 2006 20:39:13 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4321.cisco.com [10.61.80.224]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6F3X4L1024303; Fri, 14 Jul 2006 20:33:06 -0700 Message-ID: <44B8635D.3070301@cisco.com> Date: Sat, 15 Jul 2006 05:39:09 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Alexey Melnikov References: <1152889487.72.0.329408898494.issue21@ofcourseimright.com> <44B81CF7.2050106@isode.com> In-Reply-To: <44B81CF7.2050106@isode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=843; t=1152934754; x=1153798754; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[issue21]=20do=20we=20need=20a=20new=20mime=20type=20for=20this= 20update, =20in=20order=0A=20for=20=20=20=20=20=20=20=20=20backward=20compat ?; X=v=3Dcisco.com=3B=20h=3DGRzRogpTW9dlzvSlt1FYlAhEadc=3D; b=Ofe8iQhNedU4FLYa1PEJ+QdO+tl+t1binuMWcuB3nplQWlTnv5OYRpL/yNr8mi6D6jwgDihW 4zqA0pOGIov9XfTPuQPiwk/EaLT8N3P37TkorfuEtvxa3aUQba+qlFOl; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=AWL, SUBJ_HAS_SPACES X-Spam-Level: Cc: "ietf-calsify@osafoundation.org" Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this update, in order for backward compat? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 03:39:16 -0000 Alexey Melnikov wrote: > Eliot Lear wrote: > >> New submission from Eliot Lear : >> >> 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 Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C44E37F73A for ; Mon, 3 Jul 2006 12:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B58E61422A8 for ; Mon, 3 Jul 2006 12:50:06 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21449-01 for ; Mon, 3 Jul 2006 12:50:04 -0700 (PDT) Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 137AB142297 for ; Mon, 3 Jul 2006 12:50:03 -0700 (PDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k63Jo19F025670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FxUQj-0006OL-Dh; Mon, 03 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 03 Jul 2006 15:50:01 -0400 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, MIME_BOUND_NEXTPART, NO_REAL_NAME X-Spam-Level: Cc: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-01.txt X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 19:50:06 -0000 --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 i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-3115117.I-D@ietf.org> 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: <2006-7-3115117.I-D@ietf.org> --OtherAccess-- --NextPart--