From owner-ietf-calendar@mail.imc.org Mon Jun 4 14:42:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15515 for ; Mon, 4 Jun 2001 14:42:50 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA26580 for ietf-calendar-bks; Mon, 4 Jun 2001 11:25:02 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA26573 for ; Mon, 4 Jun 2001 11:24:57 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f54INKm15818 for ; Mon, 4 Jun 2001 11:23:20 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 4 Jun 2001 11:23:20 -0700 (PDT) From: Eric Busboom X-X-Sender: To: Subject: Update of iCalendar Draft online. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A new version of the iCalendar draft ( updates to RFC2445) is now online. This version fixes many of the typos on the issues list, includes the new BYSETPOS text, and is labeled as an internet draft instead of RFC2445. I've also updates the issues list. For details, see: http://softwarestudio.org/iCal/ eric. From owner-ietf-calendar@mail.imc.org Tue Jun 5 12:54:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25923 for ; Tue, 5 Jun 2001 12:54:40 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA23152 for ietf-calendar-bks; Tue, 5 Jun 2001 08:24:50 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA23143 for ; Tue, 5 Jun 2001 08:24:44 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA24937; Tue, 5 Jun 2001 11:24:41 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id LAA05135; Tue, 5 Jun 2001 11:24:37 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15132.63924.874984.869382@grandcentral.cs.columbia.edu> Date: Tue, 5 Jun 2001 11:24:36 -0400 (EDT) To: Eric Busboom Cc: Subject: Re: Update of iCalendar Draft online. In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, June 4 2001, "Eric Busboom" wrote to "" saying: > > A new version of the iCalendar draft ( updates to RFC2445) is now online. > > This version fixes many of the typos on the issues list, includes the new > BYSETPOS text, and is labeled as an internet draft instead of RFC2445. > > I've also updates the issues list. > > For details, see: > > http://softwarestudio.org/iCal/ Here are some suggestions for further clarifications. In section 4.3.5, DATE-TIME: add at the end of the FORM #3 subsection, before the leapsecond discussion: DATE-TIME values SHOULD NOT use the local timezone form if the resulting time would be ambiguous, due to clocks being set backward. For instance, TZID=US-Eastern;19971026T013000 can indicate both 19971026T053000Z (if interpreted as U.S. Eastern Daylight Time) and 19971026T063000Z (if interpreted as U.S. Eastern Standard Time). When a local timezone form is ambiguous, the UTC representation SHOULD be used instead. Applications which receive an ambiguous time MAY interpret them to mean any occurence of that time. DATE-TIME values MUST NOT indicate a nonexistent time in the local timezone. For example, the time TZID=US-Eastern;19970406T023000 does not exist -- the second after TZID=US-Eastern;19970406T015959 (U.S. Eastern Standard Time) is TZID=US-Eastern;19970406T030000 (U.S. Eastern Daylight Time). In section 4.3.10, Recurrence Rule: Change : If BYxxx rule part values are found which are beyond the available scope (ie, BYMONTHDAY=30 in February), they are simply ignored. To: If BYxxx rule part values are found which are outside the available scope for a given occurence of a rule (eg, BYMONTHDAY=30 for a rule which falls in February, or a time which falls in a leap-forward interval in the given timezone), that occurence is omitted. (I think this was the consensus as to what this sentence means.) After: Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time (DTSTART) entry attribute. For example, "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month or a time. This information would be the same as what is specified for DTSTART. Add: If the derived information is outside the appropriate scope for a given occurence of a rule (eg, the repetition of DTSTART=19970930;RRULE:FREQ=MONTHLY in February, or a time which falls in a leap-forward interval in the given timezone), that occurence is omitted. (Clarifying that the same rule applies for derived information as for BYxxx rules.) Add, somewhere: If a repetition of a rule occurs at an ambiguous time (as defined in section 4.3.5, DATE-TIME) due to the time zone rule in effect, it is undefined whether the event occurs only at the first occurence of the ambiguous time, only at the second occurence of the ambiguous time, or at both occurences. A rule author wishing to specify this explicitly SHOULD use explicit RDATE/EXDATE or yearly RRULE/EXRULE rules to clarify the intent. Also, section 4.3.6 should incorporate whatever the consensus was of the "Does 1 day == 24 hours?" thread, but I don't remember what that was. Does anyone have proposed text here? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Fri Jun 8 11:05:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13880 for ; Fri, 8 Jun 2001 11:05:47 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA00771 for ietf-calendar-bks; Fri, 8 Jun 2001 07:44:30 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00765 for ; Fri, 8 Jun 2001 07:44:24 -0700 (PDT) From: Bruce_Kahn@iris.com To: John Stracke Cc: hgs@cs.columbia.edu, ietf-calendar@imc.org, jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: Date: Fri, 8 Jun 2001 10:49:42 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/08/2001 10:47:40 AM, Serialize complete at 06/08/2001 10:47:40 AM Content-Type: multipart/alternative; boundary="=_alternative 0050DE7F85256A65_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0050DE7F85256A65_= Content-Type: text/plain; charset="us-ascii" First off, an appology for my brief disappearance. Real Work (TM) and Bronchitis conspired to keep me offline for a week and a half and Im just now getting dug out of the backlog... francis@ecal.com wrote on 05/14/2001 11:50:59 AM: > That is, in fact, the problem: how do you build a user interface > that expresses the full power? It can be done, I suppose, but > it's going to be *massively* complex, very hard for users to > learn. Lets not muddy the water w/different issues. How you design a UI for this is separate from the eventual on the wire encoding of the settings. If your concerns are really UI centric, start a new thread (that would be OOS for this WG anyway)... > From that > viewpoint, it's not a particularly complex grammar; but, from the > viewpoint of a user who has to be able to take a recurrence rule, > hold in their head, and maybe edit it, it's *far* too > complicated. Again, this is a UI issue and not an issue w/the grammar. > To repeat the example I posted in my > draft-stracke-calsch-rrule-subset-00.txt (unsubmitted, but posted > to the WG: > ), > iCalendar lets you specify an event which: > > * occurs every 79 seconds, > * also occurs at 3:15:25 PM on the 12th, 37th, and 159th days > of the year, > * but does not occur unless it's 13 or 23 seconds after the > minute, > * and does not occur on the second Tuesday of the month. > > This is absurd--and yet, any compliant implementation has to be > able to accept it, expand it (not too hard), show it to the user > (difficult), and let the user edit it (well-nigh impossible). If you do not like the fact that we did not put TONS of restrictions on the recurrence grammar, you should have said something sooner (ie: when we were going thru Last Call originally). We (the WG at large) had tons of chances then to say "Hmmm, ya know that I can make this event repeat every 79 seconds? Why would I want to? Isn't that overkill" but there was not a peep like that. If you are now trying to make up for that, great. However keep in mind that the grammar was (and still is) intended to be useful not only for what C&S applications/cases we can envision now (or then) but also be robust enough to be reused w/o change (or much change) in any future "calendar or scheduling like" application. The fact that iptel is reusing it is partly an endorsement of that design philosphy. All of your cited examples (except maybe the last one) may seem outlandish from the POV of a C&S app developer now but I strongly believe that if it is possible for someone to _want_ to be able to represent something that matches one of the above patterns that we should be able to represent it; IRREGARDLESS of the recipients ability to neatly present it in the UI/GUI. The last example in 2445 explains how to 'decode' a complex rule into a textual representation (ala Outlook 98 and laters ability to do so in their UI) so its not necessarily "bad" that your UI cannot graphically represent the grammar as buttons/sliders/widgets. Why not just 'textify' it and tell them "Hey, this event repeats at 3:15:25 PM on the 12th, 37th, and 159th days of the year" (or express the dates if you want, etc). Afterall, which is easier for a real human to understand: text like "This entry starts at 9:00AM Today and repeats every 79 seconds until January 1, 2002" or a GUI w/lots of buttons/pulldowns/sliders/etc?? (I assume the CUA can create a textual representation that is somewhat coherent and have ignored some issues like language conversions, etc just to make this a simple point.) Argh, I digressed into a UI vs use argument again. Sorry but I plead the effect of antibiotics and caffine... > (In fact, I've since realized I could've come up with something > even more complex, since RRULE and EXRULE can each appear > multiple times in a VEVENT.) Heck, add enough "simple" RRULE/EXRULEs and anything can become overly complex. Is that a 'fault' in the grammar or in the user/usage? > In fact, my objections are based largely on the prediction that > no two implementations will implement the same subset of RECUR. > To quote my draft again: > > In order to make the user interface comprehensible, > each CUA will probably expose only a subset of the > available recurrence features to the user. The risk, > then, is that different CUAs will expose different > subsets, and will not be properly tested for iCalendar > objects which stray outside those subsets. Even if > they expand those iCalendar objects correctly, they may > not display the full recurrence rule correctly, since > that would require complicating the UI. If that > happens, the user will wind up seeing that the > recurrence rule for their repeating event says it > occurs every Monday, but the calendar does not show the > event on every Monday; there are gaps. Confusing the > users like this effectively means that there will not > be interoperability: even if the underlying iCalendar > implementations understand each other, the users don't. Ok, this all still reads like a "I cant build something to represent it all in a GUI so I dont like it" kind of text. See my comment above about Outlook and textifying the rules for human representation. > It is not enough to be able to say "implementations A and B use > BYSETPOS, and implementations C and D use UNTIL, so they both can > stay in". For iCalendar to advance to Draft Standard, there must > be two implementations which implement the *entire* RECUR > grammar. In my opinion, "implement" in this case must cover the > user interface, not just the backend. (Patrik, am I right on > this procedural point? I'm relying in part on your ruling that 1 > day == 24 hours would confuse the users.) Sorry but I cant buy the tidbit about covering the UI as part of the implementation. iCalendar is an on the wire format, NOT a GUI spec. We are not in the business of specing UIs here, just standards so that different implementations can interoperate. Patrick: We could use some AD feedback on this point about "in or out". Pardon me if it was already given, I have a big backlog of postings to read thru and Im taking them linearly. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0050DE7F85256A65_= Content-Type: text/html; charset="us-ascii"
First off, an appology for my brief disappearance.  Real Work (TM) and Bronchitis conspired to keep me offline for a week and a half and Im just now getting dug out of the backlog...

francis@ecal.com wrote on 05/14/2001 11:50:59 AM:
> That is, in fact, the problem: how do you build a user interface
> that expresses the full power? It can be done, I suppose, but
> it's going to be *massively* complex, very hard for users to
> learn.
Lets not muddy the water w/different issues.  How you design a UI for this is separate from the eventual on the wire encoding of the settings.  If your concerns are really UI centric, start a new thread (that would be OOS for this WG anyway)...

>                                                     From that
> viewpoint, it's not a particularly complex grammar; but, from the
> viewpoint of a user who has to be able to take a recurrence rule,
> hold in their head, and maybe edit it, it's *far* too
> complicated.  

Again, this is a UI issue and not an issue w/the grammar.  

>                              To repeat the example I posted in my
> draft-stracke-calsch-rrule-subset-00.txt (unsubmitted, but posted
> to the WG:
> <http://www.imc.org/ietf-calendar/mail-archive/msg06770.html>),
> iCalendar lets you specify an event which:
>
>    * occurs every 79 seconds,
>    * also occurs at 3:15:25 PM on the 12th, 37th, and 159th days
>      of the year,
>    * but does not occur unless it's 13 or 23 seconds after the
>      minute,
>    * and does not occur on the second Tuesday of the month.
>
> This is absurd--and yet, any compliant implementation has to be
> able to accept it, expand it (not too hard), show it to the user
> (difficult), and let the user edit it (well-nigh impossible).
If you do not like the fact that we did not put TONS of restrictions on the recurrence grammar, you should have said something sooner (ie: when we were going thru Last Call originally).  We (the WG at large) had tons of chances then to say "Hmmm, ya know that I can make this event repeat every 79 seconds?  Why would I want to?  Isn't that overkill" but there was not a peep like that.  

If you are now trying to make up for that, great.  However keep in mind that the grammar was (and still is) intended to be useful not only for what C&S applications/cases we can envision now (or then) but also be robust enough to be reused w/o change (or much change) in any future "calendar or scheduling like" application.  The fact that iptel is reusing it is partly an endorsement of that design philosphy.

All of your cited examples (except maybe the last one) may seem outlandish from the POV of a C&S app developer now but I strongly believe that if it is possible for someone to _want_ to be able to represent something that matches one of the above patterns that we should be able to represent it; IRREGARDLESS of the recipients ability to neatly present it in the UI/GUI.

The last example in 2445 explains how to 'decode' a complex rule into a textual representation (ala Outlook 98 and laters ability to do so in their UI) so its not necessarily "bad" that your UI cannot graphically represent the grammar as buttons/sliders/widgets.  Why not just 'textify' it and tell them "Hey, this event repeats at 3:15:25 PM on the 12th, 37th, and 159th days of the year" (or express the dates if you want, etc).  Afterall, which is easier for a real human to understand: text like "This entry starts at 9:00AM Today and repeats every 79 seconds until January 1, 2002" or a GUI w/lots of buttons/pulldowns/sliders/etc??  (I assume the CUA can create a textual representation that is somewhat coherent and have ignored some issues like language conversions, etc just to make this a simple point.)

Argh, I digressed into a UI vs use argument again.  Sorry but I plead the effect of antibiotics and caffine...

> (In fact, I've since realized I could've come up with something
> even more complex, since RRULE and EXRULE can each appear
> multiple times in a VEVENT.)
Heck, add enough "simple" RRULE/EXRULEs and anything can become overly complex.  Is that a 'fault' in the grammar or in the user/usage?

> In fact, my objections are based largely on the prediction that
> no two implementations will implement the same subset of RECUR.
> To quote my draft again:
>
>      In order to make the user interface comprehensible,
>      each CUA will probably expose only a subset of the
>      available recurrence features to the user.  The risk,
>      then, is that different CUAs will expose different
>      subsets, and will not be properly tested for iCalendar
>      objects which stray outside those subsets.  Even if
>      they expand those iCalendar objects correctly, they may
>      not display the full recurrence rule correctly, since
>      that would require complicating the UI.  If that
>      happens, the user will wind up seeing that the
>      recurrence rule for their repeating event says it
>      occurs every Monday, but the calendar does not show the
>      event on every Monday; there are gaps.  Confusing the
>      users like this effectively means that there will not
>      be interoperability: even if the underlying iCalendar
>      implementations understand each other, the users don't.
Ok, this all still reads like a "I cant build something to represent it all in a GUI so I dont like it" kind of text.  See my comment above about Outlook and textifying the rules for human representation.

> It is not enough to be able to say "implementations A and B use
> BYSETPOS, and implementations C and D use UNTIL, so they both can
> stay in".  For iCalendar to advance to Draft Standard, there must
> be two implementations which implement the *entire* RECUR
> grammar.  In my opinion, "implement" in this case must cover the
> user interface, not just the backend.  (Patrik, am I right on
> this procedural point? I'm relying in part on your ruling that 1
> day == 24 hours would confuse the users.)
Sorry but I cant buy the tidbit about covering the UI as part of the implementation.  iCalendar is an on the wire format, NOT a GUI spec.  We are not in the business of specing UIs here, just standards so that different implementations can interoperate.

Patrick: We could use some AD feedback on this point about "in or out".  Pardon me if it was already given, I have a big backlog of postings to read thru and Im taking them linearly.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0050DE7F85256A65_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 12:56:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16697 for ; Fri, 8 Jun 2001 12:56:10 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA13306 for ietf-calendar-bks; Fri, 8 Jun 2001 09:44:50 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13299 for ; Fri, 8 Jun 2001 09:44:44 -0700 (PDT) From: Bruce_Kahn@iris.com To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: Date: Fri, 8 Jun 2001 12:43:47 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/08/2001 12:48:02 PM, Serialize complete at 06/08/2001 12:48:02 PM Content-Type: multipart/alternative; boundary="=_alternative 005BE3B485256A65_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005BE3B485256A65_= Content-Type: text/plain; charset="us-ascii" Shannon replied: >Restrict BYSETPOS to events of value DATE - that is restrict it to events >enumerated by DAY? Sounds tempting at first blush but it would prevent the use of BYSETPOS in models like the SKiCAL where they do have stuff that can repeat sub day (ie: A city tour that repeats 3 times a day during the week). >Just a thought - if it was intended for use when DAYS are enumerated, why >not clearly define and specify that that is the case? A scan of the archives will reveal a terse response from Frank to the original notice of the oversight saying it was a mistake. He can also confirm this if he is still lurking around... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005BE3B485256A65_= Content-Type: text/html; charset="us-ascii"
Shannon replied:
>Restrict BYSETPOS to events of value DATE - that is restrict it to events
>enumerated by DAY?

Sounds tempting at first blush but it would prevent the use of BYSETPOS in models like the SKiCAL where they do have stuff that can repeat sub day (ie: A city tour that repeats 3 times a day during the week).

>Just a thought - if it was intended for use when DAYS are enumerated, why
>not clearly define and specify that that is the case?
A scan of the archives will reveal a terse response from Frank to the original notice of the oversight saying it was a mistake.  He can also confirm this if he is still lurking around...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005BE3B485256A65_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 12:56:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16715 for ; Fri, 8 Jun 2001 12:56:18 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA12931 for ietf-calendar-bks; Fri, 8 Jun 2001 09:39:18 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA12917 for ; Fri, 8 Jun 2001 09:39:11 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org, Jonathan Lennox Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: Date: Fri, 8 Jun 2001 12:38:14 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/08/2001 12:42:28 PM, Serialize complete at 06/08/2001 12:42:28 PM Content-Type: multipart/alternative; boundary="=_alternative 005B61A885256A65_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005B61A885256A65_= Content-Type: text/plain; charset="us-ascii" Eric wrote: >BYSETPOS is problematic for a number of reasons, but there may be a way to >fix it so that CPL can use it. While this is a good idea I think the larger goal should be to 'fix' it so that it is useful for all implementors of the recurrence grammar, not just iptel/CPL. Doing this has the side effect of making it work for everyone instead of just another WG that is reusing it. >The way BYSETPOS is currently specified is that it can take values from 1 >to 366 and -1 to -366. Clearly is was intended to enumerate days, but >there is no restriction to keep it from being used on a rule that can >generate intra-day events, potentially millions of values in the >occurrence set, such as by specifying every second of a year. >It is silly for BYSETPOS to only let you access the first 366 and the last >366 of a set of 31 million events. We noted this a long time ago (earlier than last 1-Jun-00 "Max # of occurences in a recur rule?" thread on the topic and Frank concurred in a reply that indeed it was an oversight that needed to be fixed. > There are a few possible fixes for >this: > > (1) Let BYSETPOS take a full range of vlaues from -31 million to > +31 million. > > (2) Declare that BYSETPOS cannot be used on a rule that gnenerates > more than 366 events before BYSETPOS is applied. ( Throw an error) > > (3) Declare that when BYSETPOS appears, the implementation must > only consider the first 366 occurrences it generates to be part of > the set that BYSETPOS is applied to. > >(1) is the concept that makes BYSETPOS it unusuable for CPL. However, (2) >and (3) imply that an implementation only has to expand 366 events -- they >are restrictions that bound the execution time for BYSETPOS. I think we all agree that +/-366 is inadequate and needs to be corrected. Sure, +/-31 million is overly large for us to visualize now but Im not sure that its a reason to NOT go that route w/some caveats. I think that the proper behavior of ANY CUA that does not like either BYSETPOS, its size or its values (ie: there are 68K values on it) should be to reject the rule as "too complex". This said, I think that CPL or other implementors will find taking that approach a more robust one going forward. As systems get faster or feature sets get more robust, they can extend the size of the grammar (ie: BYSETPOS values) that they support; all w/o requiring ANY RFC changes! WRT the individual cases above, I think that (1) is probably the best course to logically take for reuse and growth reasons. (2) is not good since it prevents something like SKiCAL from doing a "The City Tour begins at 9AM and again at 12PM every day of the year except New Years Day" kinds of stuff. (Or actually any recurrence set that can generate > 366 instances; not too good.) (3) is equally unlikable as (2) for many of the same reasons or worse yet, it could result in a recurrance instance that is actually desired but 'unreachable'. (Consider the set that has 733 instances in it, there is 1 instances that is 'unreachable'.) Just as we have a way to indicate "I do not grok the recurrence subcomponent BYSETPOS (or BLECH, etc)" and rejecting the rule as "unsupportable" or "too complex" I think that the proper course of action is to adopt (1). This coupled w/the fact that it is possible to actually specify a VERY big set using BYxxx modifiers (31,622,400 by my count w/o leap seconds) I think we really must have a way to filter out only the desired instances from the full pattern (the purpose of BYSETPOS) . Otherwise BYSETPOS really is only partly functioning compared to its intended use. Now, do I actually expect someone to generate a recurrence rule that evenly remotely comes close to this; not in the forseeable future. Does it go against my KISS mantra; to some degree, yes. However from a technical perspective I think that having a 'complete' solution is better than one that has "holes" in it. After all, just where should we draw the line at the limit of BYSETPOS between 366 and 31,622,400?? 1K? 10K? 1M? 10M? For our (CalSched) uses I do not see any real cases of "An event that repeats every second, of every day, all year long". However we are trying to make our design reusable to other areas where it may be necessary to have a value above our self-prescribed limit and below the theoretical max of 31,622,400. Im not trying to sound like a broken record here but I do think we need to not restrict ourselves by fixing something for a smaller subset of potential users when we should be fixing it for any adopter of the grammar. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005B61A885256A65_= Content-Type: text/html; charset="us-ascii"
Eric wrote:
>BYSETPOS is problematic for a number of reasons, but there may be a way to
>fix it so that CPL can use it.
While this is a good idea I think the larger goal should be to 'fix' it so that it is useful for all implementors of the recurrence grammar, not just iptel/CPL.  Doing this has the side effect of making it work for everyone instead of just another WG that is reusing it.

>The way BYSETPOS is currently specified is that it can take values from 1
>to 366 and -1 to -366. Clearly is was intended to enumerate days, but
>there is no restriction to keep it from being used on a rule that can
>generate intra-day events, potentially millions of values in the
>occurrence set, such as by specifying every second of a year.
>It is silly for BYSETPOS to only let you access the first 366 and the last
>366 of a set of 31 million events.

We noted this a long time ago (earlier than last 1-Jun-00 "Max # of occurences in a recur rule?" thread on the topic and Frank concurred in a reply that indeed it was an oversight that needed to be fixed.

>                                There are a few possible fixes for
>this:
>
>                 (1) Let BYSETPOS take a full range of vlaues from -31 million to
>                 +31 million.
>
>                 (2) Declare that BYSETPOS cannot be used on a rule that gnenerates
>                 more than 366 events before BYSETPOS is applied. ( Throw an error)
>
>                 (3) Declare that when BYSETPOS appears, the implementation must
>                 only consider the first 366 occurrences it generates to be part of
>                 the set that BYSETPOS is applied to.
>
>(1) is the concept that makes BYSETPOS it unusuable for CPL.  However, (2)
>and (3) imply that an implementation only has to expand 366 events -- they
>are restrictions that bound the execution time for BYSETPOS.
I think we all agree that +/-366 is inadequate and needs to be corrected.  Sure, +/-31 million is overly large for us to visualize now but Im not sure that its a reason to NOT go that route w/some caveats.

I think that the proper behavior of ANY CUA that does not like either BYSETPOS, its size or its values (ie: there are 68K values on it) should be to reject the rule as "too complex".  This said, I think that CPL or other implementors will find taking that approach a more robust one going forward.  As systems get faster or feature sets get more robust, they can extend the size of the grammar (ie: BYSETPOS values) that they support; all w/o requiring ANY RFC changes!

WRT the individual cases above, I think that (1) is probably the best course to logically take for reuse and growth reasons.  (2) is not good since it prevents something like SKiCAL from doing a "The City Tour begins at 9AM and again at 12PM every day of the year except New Years Day" kinds of stuff.  (Or actually any recurrence set that can generate > 366 instances; not too good.) (3) is equally unlikable as (2) for many of the same reasons or worse yet, it could result in a recurrance instance that is actually desired but 'unreachable'.  (Consider the set that has 733 instances in it, there is 1 instances that is 'unreachable'.)

Just as we have a way to indicate "I do not grok the recurrence subcomponent BYSETPOS (or BLECH, etc)" and rejecting the rule as "unsupportable" or "too complex" I think that the proper course of action is to adopt (1).  This coupled w/the fact that it is possible to actually specify a VERY big set using BYxxx modifiers (31,622,400 by my count w/o leap seconds) I think we really must have a way to filter out only the desired instances from the full pattern (the purpose of BYSETPOS) .  Otherwise BYSETPOS really is only partly functioning compared to its intended use.

Now, do I actually expect someone to generate a recurrence rule that evenly remotely comes close to this; not in the forseeable future.  Does it go against my KISS mantra; to some degree, yes.  However from a technical perspective I think that having a 'complete' solution is better than one that has "holes" in it.  After all, just where should we draw the line at the limit of BYSETPOS between 366 and 31,622,400??  1K? 10K? 1M? 10M?  For our (CalSched) uses I do not see any real cases of "An event that repeats every second, of every day, all year long".  However we are trying to make our design reusable to other areas where it may be necessary to have a value above our self-prescribed limit and below the theoretical max of 31,622,400.

Im not trying to sound like a broken record here but I do think we need to not restrict ourselves by fixing something for a smaller subset of potential users when we should be fixing it for any adopter of the grammar.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005B61A885256A65_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 12:59:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16909 for ; Fri, 8 Jun 2001 12:59:09 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA13630 for ietf-calendar-bks; Fri, 8 Jun 2001 09:49:23 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13622 for ; Fri, 8 Jun 2001 09:49:18 -0700 (PDT) From: Bruce_Kahn@iris.com To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: Date: Fri, 8 Jun 2001 12:48:20 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/08/2001 12:52:35 PM, Serialize complete at 06/08/2001 12:52:35 PM Content-Type: multipart/alternative; boundary="=_alternative 005C4E8F85256A65_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005C4E8F85256A65_= Content-Type: text/plain; charset="us-ascii" Jonathan replied: >One further comment on why BYSETPOS is horribly broken. > >RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13, > 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36, > 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59; > BYSETPOS=-1 > >is a legal RFC 2445 recurrence. It expands to approximately three >quadrillion events before BYSETPOS is applied. Good luck... Thanks but by my calculations the set is 60 instances long (one per second) and the set repeats every 100000000 years. The BYSETPOS simply selects the instance at second 59 making the rest obsolete really. Hmm, does Jonathan has a pet Dino? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C4E8F85256A65_= Content-Type: text/html; charset="us-ascii"
Jonathan replied:
>One further comment on why BYSETPOS is horribly broken.
>
>RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13,
>        14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,
>        37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59;
>        BYSETPOS=-1
>
>is a legal RFC 2445 recurrence.  It expands to approximately three
>quadrillion events before BYSETPOS is applied.  Good luck...
Thanks but by my calculations the set is 60 instances long (one per second) and the set repeats every 100000000 years.  The BYSETPOS simply selects the instance at second 59 making the rest obsolete really.  Hmm, does Jonathan has a pet Dino?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005C4E8F85256A65_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 13:00:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17002 for ; Fri, 8 Jun 2001 13:00:38 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA13560 for ietf-calendar-bks; Fri, 8 Jun 2001 09:48:09 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA13550 for ; Fri, 8 Jun 2001 09:48:03 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA32640 for ; Fri, 8 Jun 2001 11:46:18 -0500 From: "Shannon J. Clark" To: Subject: RE: RECUR Subset and IPTel's CPL: Need Resolution Date: Fri, 8 Jun 2001 11:47:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C0F010.C8BDD180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C0F010.C8BDD180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit While there is a difference between writing a User Interface standard and writing a data/wire standard the two ARE connected whether we like it or not. Look at it this way - if the standard is NOT representable in a manner that allows for interoperability the standard is dead on arrival. Some standards are designed for highly technical users (think language specifications, SQL standards etc) - in these cases complex grammars and a low level usage may make sense and be a solution to how to handle areas of high complexity. However, Calendaring and Scheduling is an area intended for WIDE usage by users of all sorts (including non-human "users" like CPL) - this means that we very much have to consider whether or not our standard will serve as a foundation for tools that can be developed for wide usage - if it cannot be, or if doing so requires making compromises that lead to interoperability issues - such as not fully supporting "required" sections of the standards or more subtly supporting them in ways that lead to varying behavior from the perspective of the end user - such as displaying or interpreting Reoccurrence rules in a different manner - we are unlikely to had widespread and useful adoption of iCalendar and related standards. So - while I understand that we are not fundamentally in the business of designing user interfaces, I think that a blanket statement "that is it Off-Topic for the working group" is not true. A wire/data standard that defeats itself when User Interfaces are attempted to be built will not be a successful standard. Successful standards have managed to accommodate a wide range of user interfaces by in general avoiding areas that highly complex to represent - I think that as they are currently defined, even with the proposed changes in the latest Draft of a new version of the iCalendar standard - the Reoccurrence Rules section IS still very complex - with good reason perhaps - but well worth time and attention and thought about how to represent to END USERS the rules - if the rules cannot be entered INTO an object - they will not be in objects to be read back. The intent of the RRULES is to allow for highly flexible ways of encapsulating multiple occurrences over time of something - to provide for flexibility many ways of defining WHEN each occurrence should occur are built into the standard. Most of the complexity comes from COMBINING these systems together - each approach by itself is self-contained and generally reasonable - it is when the pieces of each approach are combined that we get hard to represent or define rules. Furthermore - we have to strike a balance between imposing "reality" into how the rules function - and allowing for flexibility. This leads to questions involving hours of the year that exist in some timezones - but not in others (for Daylight Savings changes) - which leads to the counterintuitive situation of rules that in the present standard may have undefined results depending on where and how timezones are applied to a given object. (What I mean by this is the following - generally from a USER's perspective the USER lives in a given timezone - thus the USER's calendar should be represented in that timezone. If a given event is sent out to a group of users, if the event is set for 2:30AM every Day (to use easy RRULES) and is set for a timezone with Daylight Savings rules - there will one day a year when the event encounters an issue - it is set for a time that does not "happen" - how is the system supposed to deal with this? Further, take the following example - remove the TIMEZONE from the event in question - that is place it into the LOCAL time of the user - now the "event" will have highly varying behavior as users around the globe go through daylight savings changes on different days (and some do not). Should the standard address this issue? Or similar ones like events set for Feb 29 of a non-leap year? Is the correct behavior to IGNORE that occurrence (which is NOT the intuitive behavior from an end-user's perspective - to understand this, think of the BIRTHDAY set for FEB 29 - it shouldn't NOT happen 3 out of 4 years... rather it should do something - but that something is NOT standardized.) Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Bruce_Kahn@iris.com Sent: Friday, June 08, 2001 9:50 AM To: John Stracke Cc: hgs@cs.columbia.edu; ietf-calendar@imc.org; jdrosen@dynamicsoft.com Subject: Re: RECUR Subset and IPTel's CPL: Need Resolution First off, an appology for my brief disappearance. Real Work (TM) and Bronchitis conspired to keep me offline for a week and a half and Im just now getting dug out of the backlog... francis@ecal.com wrote on 05/14/2001 11:50:59 AM: > That is, in fact, the problem: how do you build a user interface > that expresses the full power? It can be done, I suppose, but > it's going to be *massively* complex, very hard for users to > learn. Lets not muddy the water w/different issues. How you design a UI for this is separate from the eventual on the wire encoding of the settings. If your concerns are really UI centric, start a new thread (that would be OOS for this WG anyway)... > From that > viewpoint, it's not a particularly complex grammar; but, from the > viewpoint of a user who has to be able to take a recurrence rule, > hold in their head, and maybe edit it, it's *far* too > complicated. Again, this is a UI issue and not an issue w/the grammar. > To repeat the example I posted in my > draft-stracke-calsch-rrule-subset-00.txt (unsubmitted, but posted > to the WG: > ), > iCalendar lets you specify an event which: > > * occurs every 79 seconds, > * also occurs at 3:15:25 PM on the 12th, 37th, and 159th days > of the year, > * but does not occur unless it's 13 or 23 seconds after the > minute, > * and does not occur on the second Tuesday of the month. > > This is absurd--and yet, any compliant implementation has to be > able to accept it, expand it (not too hard), show it to the user > (difficult), and let the user edit it (well-nigh impossible). If you do not like the fact that we did not put TONS of restrictions on the recurrence grammar, you should have said something sooner (ie: when we were going thru Last Call originally). We (the WG at large) had tons of chances then to say "Hmmm, ya know that I can make this event repeat every 79 seconds? Why would I want to? Isn't that overkill" but there was not a peep like that. If you are now trying to make up for that, great. However keep in mind that the grammar was (and still is) intended to be useful not only for what C&S applications/cases we can envision now (or then) but also be robust enough to be reused w/o change (or much change) in any future "calendar or scheduling like" application. The fact that iptel is reusing it is partly an endorsement of that design philosphy. All of your cited examples (except maybe the last one) may seem outlandish from the POV of a C&S app developer now but I strongly believe that if it is possible for someone to _want_ to be able to represent something that matches one of the above patterns that we should be able to represent it; IRREGARDLESS of the recipients ability to neatly present it in the UI/GUI. The last example in 2445 explains how to 'decode' a complex rule into a textual representation (ala Outlook 98 and laters ability to do so in their UI) so its not necessarily "bad" that your UI cannot graphically represent the grammar as buttons/sliders/widgets. Why not just 'textify' it and tell them "Hey, this event repeats at 3:15:25 PM on the 12th, 37th, and 159th days of the year" (or express the dates if you want, etc). Afterall, which is easier for a real human to understand: text like "This entry starts at 9:00AM Today and repeats every 79 seconds until January 1, 2002" or a GUI w/lots of buttons/pulldowns/sliders/etc?? (I assume the CUA can create a textual representation that is somewhat coherent and have ignored some issues like language conversions, etc just to make this a simple point.) Argh, I digressed into a UI vs use argument again. Sorry but I plead the effect of antibiotics and caffine... > (In fact, I've since realized I could've come up with something > even more complex, since RRULE and EXRULE can each appear > multiple times in a VEVENT.) Heck, add enough "simple" RRULE/EXRULEs and anything can become overly complex. Is that a 'fault' in the grammar or in the user/usage? > In fact, my objections are based largely on the prediction that > no two implementations will implement the same subset of RECUR. > To quote my draft again: > > In order to make the user interface comprehensible, > each CUA will probably expose only a subset of the > available recurrence features to the user. The risk, > then, is that different CUAs will expose different > subsets, and will not be properly tested for iCalendar > objects which stray outside those subsets. Even if > they expand those iCalendar objects correctly, they may > not display the full recurrence rule correctly, since > that would require complicating the UI. If that > happens, the user will wind up seeing that the > recurrence rule for their repeating event says it > occurs every Monday, but the calendar does not show the > event on every Monday; there are gaps. Confusing the > users like this effectively means that there will not > be interoperability: even if the underlying iCalendar > implementations understand each other, the users don't. Ok, this all still reads like a "I cant build something to represent it all in a GUI so I dont like it" kind of text. See my comment above about Outlook and textifying the rules for human representation. > It is not enough to be able to say "implementations A and B use > BYSETPOS, and implementations C and D use UNTIL, so they both can > stay in". For iCalendar to advance to Draft Standard, there must > be two implementations which implement the *entire* RECUR > grammar. In my opinion, "implement" in this case must cover the > user interface, not just the backend. (Patrik, am I right on > this procedural point? I'm relying in part on your ruling that 1 > day == 24 hours would confuse the users.) Sorry but I cant buy the tidbit about covering the UI as part of the implementation. iCalendar is an on the wire format, NOT a GUI spec. We are not in the business of specing UIs here, just standards so that different implementations can interoperate. Patrick: We could use some AD feedback on this point about "in or out". Pardon me if it was already given, I have a big backlog of postings to read thru and Im taking them linearly. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... ------=_NextPart_000_000C_01C0F010.C8BDD180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
While = there is a=20 difference between writing a User Interface standard and writing a = data/wire=20 standard the two ARE connected whether we like it or = not.
 
Look = at it this way=20 - if the standard is NOT representable in a manner that allows for=20 interoperability the standard is dead on arrival.
 
Some = standards are=20 designed for highly technical users (think language specifications, SQL=20 standards etc) - in these cases complex grammars and a low level usage = may make=20 sense and be a solution to how to handle areas of high complexity. = However,=20 Calendaring and Scheduling is an area intended for WIDE usage by users = of all=20 sorts (including non-human "users" like CPL) - this means that we very = much have=20 to consider whether or not our standard will serve as a foundation for = tools=20 that can be developed for wide usage - if it cannot be, or if doing so = requires=20 making compromises that lead to interoperability issues - such as not = fully=20 supporting "required" sections of the standards or more subtly = supporting them=20 in ways that lead to varying behavior from the perspective of the end = user -=20 such as displaying or interpreting Reoccurrence rules in a different = manner - we=20 are unlikely to had widespread and useful adoption of iCalendar and = related=20 standards.
 
So - = while I=20 understand that we are not fundamentally in the business of designing = user=20 interfaces, I think that a blanket statement "that is it Off-Topic for = the=20 working group" is not true. A wire/data standard that defeats itself = when User=20 Interfaces are attempted to be built will not be a successful=20 standard.
 
Successful standards=20 have managed to accommodate a wide range of user interfaces by in = general=20 avoiding areas that highly complex to represent - I think that as they = are=20 currently defined, even with the proposed changes in the latest Draft of = a new=20 version of the iCalendar standard - the Reoccurrence Rules section IS = still very=20 complex - with good reason perhaps - but well worth time and attention = and=20 thought about how to represent to END USERS the rules - if the rules = cannot be=20 entered INTO an object - they will not be in objects to be read back. = The intent=20 of the RRULES is to allow for highly flexible ways of encapsulating = multiple=20 occurrences over time of something - to provide for flexibility many = ways of=20 defining WHEN each occurrence should occur are built into the standard. = Most of=20 the complexity comes from COMBINING these systems together - each = approach by=20 itself is self-contained and generally reasonable - it is when the = pieces of=20 each approach are combined that we get hard to represent or define=20 rules.
 
Furthermore - we=20 have to strike a balance between imposing "reality" into how the rules = function=20 - and allowing for flexibility. This leads to questions involving hours = of the=20 year that exist in some timezones - but not in others (for Daylight = Savings=20 changes) - which leads to the counterintuitive situation of rules that = in the=20 present standard may have undefined results depending on where and how = timezones=20 are applied to a given object.
 
   =20 (What I mean by this is the following - generally from a USER's = perspective the=20 USER lives in a given timezone - thus the USER's calendar should be = represented=20 in that timezone. If a given event is sent out to a group of users, if = the event=20 is set for 2:30AM every Day (to use easy RRULES) and is set for a = timezone with=20 Daylight Savings rules - there will one day a year when the event = encounters an=20 issue - it is set for a time that does not "happen" - how is the system = supposed=20 to deal with this?
 
Further, take the=20 following example - remove the TIMEZONE from the event in question - = that is=20 place it into the LOCAL time of the user - now the "event" will have = highly=20 varying behavior as users around the globe go through daylight savings = changes=20 on different days (and some do not).
 
Should = the standard=20 address this issue? Or similar ones like events set for Feb 29 of a = non-leap=20 year? Is the correct behavior to IGNORE that occurrence (which is NOT = the=20 intuitive behavior from an end-user's perspective - to understand this, = think of=20 the BIRTHDAY set for FEB 29 - it shouldn't NOT happen 3 out of 4 = years... rather=20 it should do something - but that something is NOT=20 standardized.)
 
Shannon
-----Original Message-----
From:=20 owner-ietf-calendar@mail.imc.org=20 [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of=20 Bruce_Kahn@iris.com
Sent: Friday, June 08, 2001 9:50=20 AM
To: John Stracke
Cc: hgs@cs.columbia.edu;=20 ietf-calendar@imc.org; jdrosen@dynamicsoft.com
Subject: Re: = RECUR=20 Subset and IPTel's CPL: Need Resolution


First off, an appology for my brief = disappearance.=20  Real Work (TM) and Bronchitis conspired to keep me offline for a = week=20 and a half and Im just now getting dug out of the backlog...=20

francis@ecal.com wrote on = 05/14/2001=20 11:50:59 AM:
> That is, in fact, the problem: how do you build a = user=20 interface
> that expresses the full power? It can be done, I = suppose,=20 but
> it's going to be *massively* complex, very hard for users=20 to
> learn.

Lets = not muddy=20 the water w/different issues.  How you design a UI for this is = separate=20 from the eventual on the wire encoding of the settings.  If your = concerns=20 are really UI centric, start a new thread (that would be OOS for this = WG=20 anyway)...

> =    =20                     =  =20                     =  =20     From that
> viewpoint, it's not a particularly = complex=20 grammar; but, from the
> viewpoint of a user who has to be able = to take=20 a recurrence rule,
> hold in their head, and maybe edit it, it's = *far*=20 too
> complicated.  

Again, this is a UI issue and not an issue w/the grammar. =  =20

>       =  =20                     =  To=20 repeat the example I posted in my
>=20 draft-stracke-calsch-rrule-subset-00.txt (unsubmitted, but = posted
> to=20 the WG:
>=20 = <http://www.imc.org/ietf-calendar/mail-archive/msg06770.html>),
= >=20 iCalendar lets you specify an event which:
>
>   =  *=20 occurs every 79 seconds,
>    * also occurs at 3:15:25 = PM on=20 the 12th, 37th, and 159th days
>      of the=20 year,
>    * but does not occur unless it's 13 or 23 = seconds=20 after the
>      minute,
>    * = and does=20 not occur on the second Tuesday of the month.
>
> This is = absurd--and yet, any compliant implementation has to be
> able = to accept=20 it, expand it (not too hard), show it to the user
> (difficult), = and let=20 the user edit it (well-nigh impossible).

If you do not like the fact that we did not put TONS of = restrictions on=20 the recurrence grammar, you should have said something sooner (ie: = when we=20 were going thru Last Call originally).  We (the WG at large) had = tons of=20 chances then to say "Hmmm, ya know that I can make this event repeat = every 79=20 seconds?  Why would I want to?  Isn't that overkill" but = there was=20 not a peep like that.  

If=20 you are now trying to make up for that, great.  However keep in = mind that=20 the grammar was (and still is) intended to be useful not only for what = C&S=20 applications/cases we can envision now (or then) but also be robust = enough to=20 be reused w/o change (or much change) in any future "calendar or = scheduling=20 like" application.  The fact that iptel is reusing it is partly = an=20 endorsement of that design philosphy.

All of your cited examples (except maybe the last one) may = seem=20 outlandish from the POV of a C&S app developer now but I strongly = believe=20 that if it is possible for someone to _want_ to be able to represent = something=20 that matches one of the above patterns that we should be able to = represent it;=20 IRREGARDLESS of the recipients ability to neatly present it in the = UI/GUI.=20

The last example in = 2445 explains=20 how to 'decode' a complex rule into a textual representation (ala = Outlook 98=20 and laters ability to do so in their UI) so its not necessarily "bad" = that=20 your UI cannot graphically represent the grammar as = buttons/sliders/widgets.=20  Why not just 'textify' it and tell them "Hey, this event repeats = at=20 3:15:25 PM on the 12th, 37th, and 159th days of the year" (or express = the=20 dates if you want, etc).  Afterall, which is easier for a real = human to=20 understand: text like "This entry starts at 9:00AM Today and repeats = every 79=20 seconds until January 1, 2002" or a GUI w/lots of=20 buttons/pulldowns/sliders/etc??  (I assume the CUA can create a = textual=20 representation that is somewhat coherent and have ignored some issues = like=20 language conversions, etc just to make this a simple point.)=20

Argh, I digressed into a UI = vs use=20 argument again.  Sorry but I plead the effect of antibiotics and=20 caffine...

> (In = fact, I've=20 since realized I could've come up with something
> even more = complex,=20 since RRULE and EXRULE can each appear
> multiple times in a=20 VEVENT.)

Heck, add = enough "simple"=20 RRULE/EXRULEs and anything can become overly complex.  Is that a = 'fault'=20 in the grammar or in the user/usage?

> In fact, my objections are based largely on the = prediction=20 that
> no two implementations will implement the same subset of=20 RECUR.
> To quote my draft again:
>
>     =  In order to make the user interface comprehensible,
> =  =20    each CUA will probably expose only a subset of = the
>  =20    available recurrence features to the user.  The=20 risk,
>      then, is that different CUAs will = expose=20 different
>      subsets, and will not be = properly tested=20 for iCalendar
>      objects which stray outside = those=20 subsets.  Even if
>      they expand those = iCalendar=20 objects correctly, they may
>      not display = the full=20 recurrence rule correctly, since
>      that = would=20 require complicating the UI.  If that
>    =20  happens, the user will wind up seeing that the
>   =  =20  recurrence rule for their repeating event says it
>   =  =20  occurs every Monday, but the calendar does not show the
> =  =20    event on every Monday; there are gaps.  Confusing=20 the
>      users like this effectively means that = there=20 will not
>      be interoperability: even if the=20 underlying iCalendar
>      implementations = understand=20 each other, the users don't.

Ok,=20 this all still reads like a "I cant build something to represent it = all in a=20 GUI so I dont like it" kind of text.  See my comment above about = Outlook=20 and textifying the rules for human representation. =

> It is not enough to be able to say=20 "implementations A and B use
> BYSETPOS, and implementations C = and D use=20 UNTIL, so they both can
> stay in".  For iCalendar to = advance to=20 Draft Standard, there must
> be two implementations which = implement the=20 *entire* RECUR
> grammar.  In my opinion, "implement" in = this case=20 must cover the
> user interface, not just the backend. =  (Patrik, am=20 I right on
> this procedural point? I'm relying in part on your = ruling=20 that 1
> day =3D=3D 24 hours would confuse the = users.)

Sorry but I cant buy the tidbit about = covering the UI=20 as part of the implementation.  iCalendar is an on the wire = format, NOT a=20 GUI spec.  We are not in the business of specing UIs here, just = standards=20 so that different implementations can interoperate. =

Patrick: We could use some AD feedback on = this point=20 about "in or out".  Pardon me if it was already given, I have a = big=20 backlog of postings to read thru and Im taking them linearly.=20

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Bruce=20 Kahn                   =  =20            INet: = Bruce_Kahn@iris.com
Iris=20 Associates                 =  =20        Phone: 978.392.5335
Westford, MA, USA = 01886=20                   =  FAX: and=20 nothing but the FAX...
Standard disclaimers apply, even where = prohibited by=20 law...
------=_NextPart_000_000C_01C0F010.C8BDD180-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 13:22:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17433 for ; Fri, 8 Jun 2001 13:22:56 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA15271 for ietf-calendar-bks; Fri, 8 Jun 2001 10:12:40 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15256 for ; Fri, 8 Jun 2001 10:12:29 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA18810; Fri, 8 Jun 2001 13:12:29 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id NAA28510; Fri, 8 Jun 2001 13:12:28 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15137.1915.720530.303537@grandcentral.cs.columbia.edu> Date: Fri, 8 Jun 2001 13:12:27 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, June 8 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > Jonathan replied: > >One further comment on why BYSETPOS is horribly broken. > > > >RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13, > > 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36, > > 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59; > > BYSETPOS=-1 > > > >is a legal RFC 2445 recurrence. It expands to approximately three > >quadrillion events before BYSETPOS is applied. Good luck... > > Thanks but by my calculations the set is 60 instances long (one per > second) and the set repeats every 100000000 years. The BYSETPOS simply selects the instance at second 59 > making the rest obsolete really. Hmm, does Jonathan has a pet Dino? See, this is what I mean about BYSETPOS being confusing. In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 instances long, not 2. So in my example above, the set is three quadrillion instances long, not sixty. How are these not analogous? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Fri Jun 8 13:27:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17540 for ; Fri, 8 Jun 2001 13:27:18 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA15703 for ietf-calendar-bks; Fri, 8 Jun 2001 10:18:54 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15694 for ; Fri, 8 Jun 2001 10:18:47 -0700 (PDT) From: Bruce_Kahn@iris.com To: Eric Busboom Cc: ietf-calendar@imc.org, Jonathan Lennox Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: Date: Fri, 8 Jun 2001 13:17:32 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/08/2001 01:22:05 PM, Serialize complete at 06/08/2001 01:22:05 PM Content-Type: multipart/alternative; boundary="=_alternative 005EFAE385256A65_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005EFAE385256A65_= Content-Type: text/plain; charset="us-ascii" Eric replied in part with: > BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY > rules. If any of BYSECOND, BYMINUTE or BYHOUR rule parts appear in a > rule, BYSETPOS MUST NOT appear. I mildly dislike the last line but I definitely dislike the first one. It precludes simple kinds of cases where it is simpler to express a 'bigger' set and then pare it down using BYSETPOS. For example, I want to represent "Every 20 minutes from 9:00AM to 4:40PM every day except for 12:00PM, 12:20PM (when Im eating lunch) and 4:40PM (since I leave at 4:30PM)" I can simply use: RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 EXRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40;BYSETPOS=10,11,-1 (You could 'invert' this example for my 'replacmenet' who will cover the instances for when Im unavailable and their example would be: RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40;BYSETPOS=10,11,-1 ) There may be other usage models (ie: SKiCAL or some future ones) that may need it to have sub-day repeats and need BYSETPOS to achieve the same results that day (or larger) repeat intervals enjoy. I think we should make BYSETPOS work for all levels recurrence with the understanding that some cases are just insanely prohibitive to fully role (ie: Every second of every day year long). If an implementation does not wish to support BYSETPOS on some FREQ values (or with some BYxxx subcomponents) then they are free to reject 'em like they would for any other combination of unsupported BYxxx subcomponents or combinations... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005EFAE385256A65_= Content-Type: text/html; charset="us-ascii"
Eric replied in part with:
>  BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY
>  rules. If any of  BYSECOND, BYMINUTE or BYHOUR rule parts appear in a
>  rule, BYSETPOS MUST NOT appear.
I mildly dislike the last line but I definitely dislike the first one.  It precludes simple kinds of cases where it is simpler to express a 'bigger' set and then pare it down using BYSETPOS.  For example, I want to represent "Every 20 minutes from 9:00AM to 4:40PM every day except for 12:00PM, 12:20PM (when Im eating lunch) and 4:40PM (since I leave at 4:30PM)" I can simply use:

RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
EXRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40;BYSETPOS=10,11,-1

(You could 'invert' this example for my 'replacmenet' who will cover the instances for when Im unavailable and their example would be:
RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40;BYSETPOS=10,11,-1 )
There may be other usage models (ie: SKiCAL or some future ones) that may need it to have sub-day repeats and need BYSETPOS to achieve the same results that day (or larger) repeat intervals enjoy.  
I think we should make BYSETPOS work for all levels recurrence with the understanding that some cases are just insanely prohibitive to fully role (ie: Every second of every day year long).  If an implementation does not wish to support BYSETPOS on some FREQ values (or with some BYxxx subcomponents) then they are free to reject 'em like they would for any other combination of unsupported BYxxx subcomponents or combinations...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005EFAE385256A65_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 13:43:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18012 for ; Fri, 8 Jun 2001 13:43:05 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA16666 for ietf-calendar-bks; Fri, 8 Jun 2001 10:34:06 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16657 for ; Fri, 8 Jun 2001 10:33:59 -0700 (PDT) From: Bruce_Kahn@iris.com To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: Date: Fri, 8 Jun 2001 13:39:13 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/08/2001 01:37:17 PM, Serialize complete at 06/08/2001 01:37:17 PM Content-Type: multipart/alternative; boundary="=_alternative 0060640585256A65_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0060640585256A65_= Content-Type: text/plain; charset="us-ascii" Jonathan replied in part: > Using contracting rules in >conjunction with BYSETPOS, given the above definition, is nonsensical: > RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 >since a RECUR with only contracting rules will always have only >single-element sets. W/o the BYSETPOS=1, this rule says that the entry repeats every week in April. If I had a DTSTART;TZID=US-Eastern:20010406T090000 w/this rule then the repeat set would be: (09:00:00 EDT) 06-Apr-2001, 13-Apr-2001, 20-Apr-2001, 27-Apr-2001 (09:00:00 EDT) 05-Apr-2002, 12-Apr-2002, 19-Apr-2002, 26-Apr-2002 ... However w/the BYSETPOS=1 the resulting repeat set becomes: (09:00:00 EDT) 06-Apr-2001 (09:00:00 EDT) 05-Apr-2002 ... Essentially its the "1st Friday in April, forever" given my DTSTART, a very logical set. However if you wanted to just have that set then a rule like: RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=FR;BYMONTHDAY=1,2,3,4,5,6,7 or even simpler: RRULE:FREQ=MONTHLY;BYDAY=1FR;BYMONTH=4 w/o any BYSETPOS subcomponents. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0060640585256A65_= Content-Type: text/html; charset="us-ascii"
Jonathan replied in part:
>                                       Using contracting rules in
>conjunction with BYSETPOS, given the above definition, is nonsensical:
>        RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1
>since a RECUR with only contracting rules will always have only
>single-element sets.

W/o the BYSETPOS=1, this rule says that the entry repeats every week in April.  If I had a DTSTART;TZID=US-Eastern:20010406T090000 w/this rule then the repeat set would be:

(09:00:00 EDT) 06-Apr-2001, 13-Apr-2001, 20-Apr-2001, 27-Apr-2001
(09:00:00 EDT) 05-Apr-2002, 12-Apr-2002, 19-Apr-2002, 26-Apr-2002
...

However w/the BYSETPOS=1 the resulting repeat set becomes:

(09:00:00 EDT) 06-Apr-2001
(09:00:00 EDT) 05-Apr-2002
...

Essentially its the "1st Friday in April, forever" given my DTSTART, a very logical set.  However if you wanted to just have that set then a rule like:

RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=FR;BYMONTHDAY=1,2,3,4,5,6,7

or even simpler:

RRULE:FREQ=MONTHLY;BYDAY=1FR;BYMONTH=4

w/o any BYSETPOS subcomponents.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0060640585256A65_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 8 14:10:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18359 for ; Fri, 8 Jun 2001 14:10:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id LAA18328 for ietf-calendar-bks; Fri, 8 Jun 2001 11:00:10 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA18319 for ; Fri, 8 Jun 2001 11:00:04 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA21408; Fri, 8 Jun 2001 14:00:04 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id OAA28600; Fri, 8 Jun 2001 14:00:04 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15137.4771.828520.378485@grandcentral.cs.columbia.edu> Date: Fri, 8 Jun 2001 14:00:03 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, June 8 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > Jonathan replied in part: > > Using contracting rules in > >conjunction with BYSETPOS, given the above definition, is nonsensical: > > RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 > >since a RECUR with only contracting rules will always have only > >single-element sets. > > W/o the BYSETPOS=1, this rule says that the entry repeats every week in > April. If I had a DTSTART;TZID=US-Eastern:20010406T090000 w/this rule then the repeat set would be: > > (09:00:00 EDT) 06-Apr-2001, 13-Apr-2001, 20-Apr-2001, 27-Apr-2001 > (09:00:00 EDT) 05-Apr-2002, 12-Apr-2002, 19-Apr-2002, 26-Apr-2002 > ... > > However w/the BYSETPOS=1 the resulting repeat set becomes: > > (09:00:00 EDT) 06-Apr-2001 > (09:00:00 EDT) 05-Apr-2002 > ... Why? Why is the "set," for this rule, "all the events within a year" (or is it "within a month"), rather than, say, "within a week" (FREQ) or "within twenty-eight years" (least-common-multiple of BYMONTH and WEEKLY)? Can you write a pseudo-code algorithm which, for any combination of FREQ, INTERVAL, and any BY* rules except BYSETPOS, tells me which event recurrences should be marked as beginning a "set"? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Fri Jun 8 16:59:34 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20552 for ; Fri, 8 Jun 2001 16:59:33 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA25983 for ietf-calendar-bks; Fri, 8 Jun 2001 13:48:17 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25964 for ; Fri, 8 Jun 2001 13:48:11 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id QAA10346; Fri, 8 Jun 2001 16:47:44 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f58Klhv02422; Fri, 8 Jun 2001 16:47:43 -0400 (EDT) Message-Id: <5.0.0.25.0.20010608145543.0830ca68@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 08 Jun 2001 16:49:16 -0400 To: Jonathan Lennox From: Alan Davies Subject: Re: Can we fix BYSETPOS? Cc: ietf-calendar@imc.org In-Reply-To: <15109.44677.303897.569435@ind.cs.columbia.edu> References: <15107.61820.912612.674288@conrail.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:21 PM 18/05/2001 -0400, you wrote: >One further comment on why BYSETPOS is horribly broken. > >RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13, > 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36, > 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59; > BYSETPOS=-1 > >is a legal RFC 2445 recurrence. It expands to approximately three >quadrillion events before BYSETPOS is applied. Good luck... [...] >Yes, this is clearly pathological. But how well can it be prevented? And >what should a calendaring program do upon receiving it? Why should we prevent this from happening? Many useful languages and data formats can express absurdities/contradictions. Unless arbitrary restrictions are placed all over iCalendar, it'll always be possible to create an 'absurd' object. Without arbitrary restrictions, each implementor has to decide what they consider to be absurd. If you send me an object containing the "BYSECOND=0,1,2,3,4,..." recurrence rule, you'd get the same response that you would if you sent me three quadrillion RDATEs. Something along the lines of: REQUEST-STATUS:3.1;Ridiculous property value;RECUR:[...] or maybe REQUEST-STATUS:3.2;This system is not yet fully Y100M compliant;RECUR:[...] Also, removing the BYSETPOS=-1 from the rule doesn't make it any less absurd, I don't think many CUAs can handle events in the year 100M. The rule is only absurd in our problem domain though; with the universe estimated to be 12 billion years old, so an Astronomer might want to express information about events far in the future. How else could you see the opening times of the "Restaurant at the End of the Universe" in a SKiCAL object? Of course, an iCalendar 'date-fullyear' can have only 4 digits (a restriction that I don't like- and I'm sure Astronomers and Historians wouldn't be too pleased about this either). Perhaps your RRULE could have been considered invalid because it would be impossible to express the recurrence as an RDATE. (perhaps this should be noted in the iCalendar spec, if the restriction remains) --Alan From owner-ietf-calendar@mail.imc.org Fri Jun 8 22:53:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25129 for ; Fri, 8 Jun 2001 22:53:28 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id TAA16020 for ietf-calendar-bks; Fri, 8 Jun 2001 19:45:46 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA16014 for ; Fri, 8 Jun 2001 19:45:40 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id WAA25323; Fri, 8 Jun 2001 22:45:30 -0400 Message-ID: <3B218D8E.721F9789@ximian.com> Date: Fri, 08 Jun 2001 22:44:30 -0400 From: Damon Chaplin X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" CC: "libical@softwarestudio.org" Subject: Olson -> VTIMEZONE converter update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's my latest attempt at converting the Olson timezone data to VTIMEZONE format for use in iCalendar apps: http://primates.ximian.com/~damon/icalendar/ I'm quite confident that the VTIMEZONEs are correct now. I've done some testing at each stage of the conversion process, and also checked through several of the VTIMEZONEs manually. If anyone can spot any errors in the VTIMEZONEs, please let me know. (We'll be adding them to libical, and hence to our Evolution client, fairly soon.) Damon From owner-ietf-calendar@mail.imc.org Mon Jun 11 10:35:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11796 for ; Mon, 11 Jun 2001 10:35:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BE72029336 for ietf-calendar-bks; Mon, 11 Jun 2001 07:07:02 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BE70J29331 for ; Mon, 11 Jun 2001 07:07:00 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA02336; Mon, 11 Jun 2001 10:07:00 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id KAA18213; Mon, 11 Jun 2001 10:07:00 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15140.53379.536069.736469@grandcentral.cs.columbia.edu> Date: Mon, 11 Jun 2001 10:06:59 -0400 (EDT) To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: <5.0.0.25.0.20010608145543.0830ca68@imap1.in.steltor.com> References: <15107.61820.912612.674288@conrail.cs.columbia.edu> <5.0.0.25.0.20010608145543.0830ca68@imap1.in.steltor.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, June 8 2001, "Alan Davies" wrote to "Jonathan Lennox, ietf-calendar@imc.org" saying: > Why should we prevent this from happening? Many useful languages and data > formats can express absurdities/contradictions. Unless arbitrary restrictions > are placed all over iCalendar, it'll always be possible to create an > 'absurd' object. > > Without arbitrary restrictions, each implementor has to decide what they > consider to be absurd. If you send me an object containing the > "BYSECOND=0,1,2,3,4,..." recurrence rule, you'd get the same response > that you would if you sent me three quadrillion RDATEs. Something along > the lines of: > > REQUEST-STATUS:3.1;Ridiculous property value;RECUR:[...] > or maybe > REQUEST-STATUS:3.2;This system is not yet fully Y100M compliant;RECUR:[...] As we've discussed before on these lists, we have two choices when it comes to dealing with absurd statuses: 1. Let each implementation decide what it isn't going to handle. 2. Let the standard limit what implementations have to support. The problem with choice 1 is that it effectively abandons interoperability. If I generate a calendar object, I have *no idea* whether any given server is going to be able to deal with it correctly, or is going to reject it. Remember, RFC 2445 is a data format. You're not always running in an environment where you're going to get back a REQUEST-STATUS to try to negotiate a sensible representation. Consider an "Export as iCalendar" option, for instance. Thus, the track I've been advocating -- and I think a lot of the other people here have agreed with me -- is that we instead have to limit the things the specification allows. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jun 11 11:44:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12987 for ; Mon, 11 Jun 2001 11:44:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BFNZU02924 for ietf-calendar-bks; Mon, 11 Jun 2001 08:23:35 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BFNXJ02918 for ; Mon, 11 Jun 2001 08:23:33 -0700 (PDT) To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Mon, 11 Jun 2001 11:22:34 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/11/2001 11:25:46 AM, Serialize complete at 06/11/2001 11:25:46 AM Content-Type: multipart/alternative; boundary="=_alternative 005463DA85256A68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005463DA85256A68_= Content-Type: text/plain; charset="us-ascii" lennox@cs.columbia.edu wrote on 06/08/2001 01:12:27 PM: > See, this is what I mean about BYSETPOS being confusing. Yep, the text about "set of events specified by the rule" (p. 44) is overly vague. However it is possible to divine the intent from the examples (and hopefully we can get some common understanding about how to clarify this in the next update we make). (Before folks start shooting me for this, Im just pseudo-Frank (TM) and psuedo-Derik (TM) in this and arguments about this concept should have happened when recurrence rules were first introduced; dont keep shooting the messenger w/the long memory and FT indexed archive!) Each 'pass' thru the rule will generate a date or set of dates (and times) is the 'set' that is being referred to. The original perception/intention of a rule was that it would become a 'template' for rolling out 'sets' of dates. As such, it was desireable to be able to have a rule that could be 'trimmed back' a bit or that could be made more accurate in what dates were generated by filtering the set and so BYSETPOS was created (much to the bane of my WG existance of late). > So in my example above, the set is three quadrillion instances long, not > sixty. I can best explain how to this meaning by pointing to an example in 2445, the last one on p. 124: The 2nd to last weekday of the month: DTSTART;TZID=US-Eastern:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 ==> (1997 9:00 AM EDT)September 29 (1997 9:00 AM EST)October 30;November 27;December 30 (1998 9:00 AM EST)January 29;February 26;March 30 ... Ill try to take this step by step: A: The FREQ is monthly (ie: Add 1 to the month value of the DTSTART for the next instance so it would be 29-Oct-1997, 29-Nov-1997, etc). W/o any BYxxx modifiers the 'set' is effectively 1 recurrence per 'rollout' of the rule. Next add in the BYxxx modifiers in order prescribed by the text at the bottom of p44. So we get... B: The BYDAY modifier to make makes the 'set' effectively become "All Mondays, Tuesdays, Wednesdays, Thursdays and Fridays in the Month". That makes the sets of dates become: 1: [01-Sep-1997, 02-Sep-1997,..., 29-Sep-1997, 30-Sep-1997] in 1 pass since we only evaluate the rule for the month of September given the DTSTART value (and the rules decodes as ALL weekdays in the month that contains DTSTART, since this is the 1st pass). C: The BYSETPOS modfier is used to take the next to last value in the set ("BYSETPOS=-2") so this set shrinks down to: 1: [29-Sep-1997] which also happens to be the DTSTART value so this value is a duplicate value and is ignored (per the text in Section 4.8.5.1 Exception Date/Times, last line of the 1st paragraph of the Description.) There are no other modifiers to apply so the 1st pass thru evaluating this rule yields a value of 29-Sep-1997 @ 9:00 AM EDT A2: The next pass thru the rule starts by moving the evaulation point from the DTSTART by the FREQ and INTERVAL amount and become 29-Oct-1997. B2: Applying the BYDAY modifier again yields the set of dates of: 2: [01-Oct-1997, 02-Oct-1997, 03-Oct-1997, 06-Oct-1997,..., 30-Oct-1997, 31-Oct-1997] C2: Applying the BYSETPOS again yields a final output of: 2: [30-Oct-1997] Again, there are no further modifiers to apply so the value from this pass is 30-Oct-1997 @ 9:00 AM EDT. Does this help clarify things a bit?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005463DA85256A68_= Content-Type: text/html; charset="us-ascii"
lennox@cs.columbia.edu wrote on 06/08/2001 01:12:27 PM:
> See, this is what I mean about BYSETPOS being confusing.
Yep, the text about "set of events specified by the rule" (p. 44) is overly vague.  However it is possible to divine the intent from the examples (and hopefully we can get some common understanding about how to clarify this in the next update we make).  (Before folks start shooting me for this, Im just pseudo-Frank (TM) and psuedo-Derik (TM) in this and arguments about this concept should have happened when recurrence rules were first introduced; dont keep shooting the messenger w/the long memory and FT indexed archive!)

Each 'pass' thru the rule will generate a date or set of dates (and times) is the 'set' that is being referred to.  The original perception/intention of a rule was that it would become a 'template' for rolling out 'sets' of dates.  As such, it was desireable to be able to have a rule that could be 'trimmed back' a bit or that could be made more accurate in what dates were generated by filtering the set and so BYSETPOS was created (much to the bane of my WG existance of late).

> So in my example above, the set is three quadrillion instances long, not
> sixty.
I can best explain how to this meaning by pointing to an example in 2445, the last one on p. 124:

   The 2nd to last weekday of the month:

    DTSTART;TZID=US-Eastern:19970929T090000
    RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2

    ==> (1997 9:00 AM EDT)September 29
        (1997 9:00 AM EST)October 30;November 27;December 30
        (1998 9:00 AM EST)January 29;February 26;March 30
    ...

Ill try to take this step by step:

A: The FREQ is monthly (ie: Add 1 to the month value of the DTSTART for the next instance so it would be 29-Oct-1997, 29-Nov-1997, etc).  W/o any BYxxx modifiers the 'set' is effectively 1 recurrence per 'rollout' of the rule.

Next add in the BYxxx modifiers in order prescribed by the text at the bottom of p44. So we get...

B: The BYDAY modifier to make makes the 'set' effectively become "All Mondays, Tuesdays, Wednesdays, Thursdays and Fridays in the Month".  That makes the sets of dates become:
        1: [01-Sep-1997, 02-Sep-1997,..., 29-Sep-1997, 30-Sep-1997] in 1 pass since we only evaluate the rule for the month of September given the DTSTART value (and the rules decodes as ALL weekdays in the month that contains DTSTART, since this is the 1st pass).

C: The BYSETPOS modfier is used to take the next to last value in the set ("BYSETPOS=-2") so this set shrinks down to:
        1: [29-Sep-1997] which also happens to be the DTSTART value so this value is a duplicate value and is ignored (per the text in Section 4.8.5.1 Exception Date/Times, last line of the 1st paragraph of the Description.)

There are no other modifiers to apply so the 1st pass thru evaluating this rule yields a value of 29-Sep-1997 @ 9:00 AM EDT

A2: The next pass thru the rule starts by moving the evaulation point from the DTSTART by the FREQ and INTERVAL amount and become 29-Oct-1997.  

B2: Applying the BYDAY modifier again yields the set of dates of:
            2: [01-Oct-1997, 02-Oct-1997, 03-Oct-1997, 06-Oct-1997,..., 30-Oct-1997, 31-Oct-1997]

C2: Applying the BYSETPOS again yields a final output of:
            2: [30-Oct-1997]

Again, there are no further modifiers to apply so the value from this pass is 30-Oct-1997 @ 9:00 AM EDT.

Does this help clarify things a bit??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005463DA85256A68_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 11 11:51:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13149 for ; Mon, 11 Jun 2001 11:51:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BFXd204839 for ietf-calendar-bks; Mon, 11 Jun 2001 08:33:39 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BFXcJ04832 for ; Mon, 11 Jun 2001 08:33:38 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f5BFWjt10469; Mon, 11 Jun 2001 08:32:55 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 11 Jun 2001 08:32:45 -0700 (PDT) From: Eric Busboom X-X-Sender: To: cc: Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Fri, 8 Jun 2001 Bruce_Kahn@iris.com wrote: > It precludes simple kinds of cases where it is simpler to express a > 'bigger' set and then pare it down using BYSETPOS. For example, I > want to represent "Every 20 minutes from 9:00AM to 4:40PM every day > except for 12:00PM, 12:20PM (when Im eating lunch) and 4:40PM (since I > leave at 4:30PM)" I can simply use: > > RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 > EXRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40; > BYSETPOS=10,11,-1 Or, you could just add another exrule: RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 EXRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=0,20; EXRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=40; Certainly there are many rules that can be expressed with BYSETPOS -- for any restriction you can always invent a counter example. But we only need to implement each significant case once; we don't need to support every fringe case in a wide variety of ways. Can you identify some rule of general significance that absolutely requires BYSETPOS? If not, then we can keep the proposed BYSETPOS restrictions without impairing the utility of the recurrence rules. > There may be other usage models (ie: SKiCAL or some future ones) that > may need it to have sub-day repeats and need BYSETPOS to achieve the > same results that day (or larger) repeat intervals enjoy. Why do we care if there are other situations where an implementation COULD use BYSETPOS? We should only care if they MUST use it. Given the problems we have already identified it, we should not keep unnecessary flexibility. > role (ie: Every second of every day year long). If an implementation > does not wish to support BYSETPOS on some FREQ values (or with some > BYxxx subcomponents) then they are free to reject 'em like they would > for any other combination of unsupported BYxxx subcomponents or > combinations... And that restricts interoperability. If every rule that uses BYSETPOS can also be implemented without it, and some implementation reject some BYSETPOS rules, then we have an unnecessary interoperability problem -- those that use BYSETPOS unnecessarily will not be understood by those that do not accept BYSETPOS. We already have strong evidence that this will be the case -- CPL will not be able to accept every BYSETPOS rule under the current spec for RECUR. It is much better that we restrict BYSETPOS now and avoid these problems. So, Bruce, can you demonstrate that there exist common rules that cannot be constructed with the proposed restrictions to BYSETPOS? If not, then let's keep the restrictions. eric. From owner-ietf-calendar@mail.imc.org Mon Jun 11 12:14:01 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13800 for ; Mon, 11 Jun 2001 12:14:00 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5BFrOr07669 for ietf-calendar-bks; Mon, 11 Jun 2001 08:53:24 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BFrNJ07665 for ; Mon, 11 Jun 2001 08:53:23 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA29581; Mon, 11 Jun 2001 11:53:19 -0400 Received: from c-2856.steltor.com ([101.1.46.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5BFrIv25759; Mon, 11 Jun 2001 11:53:18 -0400 (EDT) Message-Id: <5.0.0.25.0.20010611101901.02ac3c38@imap1.in.steltor.com> X-Sender: aland@imap1.in.steltor.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 11 Jun 2001 11:54:47 -0400 To: Jonathan Lennox From: Alan Davies Subject: Re: Can we fix BYSETPOS? Cc: ietf-calendar@imc.org In-Reply-To: <15140.53379.536069.736469@grandcentral.cs.columbia.edu> References: <5.0.0.25.0.20010608145543.0830ca68@imap1.in.steltor.com> <15107.61820.912612.674288@conrail.cs.columbia.edu> <5.0.0.25.0.20010608145543.0830ca68@imap1.in.steltor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:06 AM 11/06/2001 -0400, Jonathan Lennox wrote: >As we've discussed before on these lists, we have two choices when it comes >to dealing with absurd statuses: > >1. Let each implementation decide what it isn't going to handle. >2. Let the standard limit what implementations have to support. > >The problem with choice 1 is that it effectively abandons interoperability. >If I generate a calendar object, I have *no idea* whether any given server >is going to be able to deal with it correctly, or is going to reject it. > >Remember, RFC 2445 is a data format. You're not always running in an >environment where you're going to get back a REQUEST-STATUS to try to >negotiate a sensible representation. Consider an "Export as iCalendar" >option, for instance. > >Thus, the track I've been advocating -- and I think a lot of the other >people here have agreed with me -- is that we instead have to limit the >things the specification allows. If this were true then there would be absolute limits to everything within iCalendar- maximum number of RDATES, ATTENDEES, max components in an object, maximum size of an object, etc. If a (valid) iCalender object was created that contained, say, several years worth of all employees' agendas for a large corporation, it could feasably be 100's of Gigabytes in size. You'd still have *no idea* whether or not anyone would be able to import this object, or without pared down RRULEs. (I don't think there's anything wrong with simplifying RRULEs, I just don't think that preventing absurdity is a valid or applicable reason) --Alan From owner-ietf-calendar@mail.imc.org Mon Jun 11 12:43:11 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14451 for ; Mon, 11 Jun 2001 12:43:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BGJkw08370 for ietf-calendar-bks; Mon, 11 Jun 2001 09:19:46 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BGJiJ08362 for ; Mon, 11 Jun 2001 09:19:44 -0700 (PDT) To: "Shannon J. Clark" Cc: ietf-calendar@imc.org Subject: RE: RECUR Subset and IPTel's CPL: Need Resolution MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Mon, 11 Jun 2001 12:18:44 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/11/2001 12:21:57 PM, Serialize complete at 06/11/2001 12:21:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0059885F85256A68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0059885F85256A68_= Content-Type: text/plain; charset="us-ascii" shannon@jigzaw.com wrote on 06/08/2001 12:47:24 PM: > While there is a difference between writing a User Interface > standard and writing a data/wire standard the two ARE connected > whether we like it or not. Sure, they are connected in that the UI needs to represent in some fashion the content recieved over the wire. However just because we do not have a UI yet that can handle the full extensibility of the format is no reason to say "Lets cut this back now". As we progress in our ability to devise better UIs we would then have to readd it all back in and go thru this process again. Since we have already provided a means for a UI to convey back "Hey, I cannot grok this complex (or long or ...) recurrence rule so I will not accept it" I do not think that a UI argument justifys cutting stuff out that we will probably add back in at some point. Had that argument used for, say, web searching or other kinds of data models/formats then fuzzy logic searches or matches would not be doable now. Nor would natural language processing (aka "Knowledge Management" to some folks). These new technlogies greatly extend the very simple "Enter search text" input boxes that can only do literal search matching. Who is to say that someone does not write a tool that takes in literal text like "Every four years, the first Tuesday after a Monday in November, forever" and geneates the proper RRULE as an output?? Given the text at the end of 4.3.10 (top of p. 45) that it should not be nuclear science to at least 'textify' the incoming RRULE (assuming it was not malformed and adheres to the currently accepted recurrence rule updates/restrictions) so I do not buy that it cannot be done at all. > Look at it this way - if the standard is NOT representable in a > manner that allows for interoperability the standard is dead on arrival. The UI abilities will eventually catch up. So should we hamstring the standard now to make the UI coders life simpler now or should we leave it as robust as it is now and let them catch up (and then add back in all that we took out)?? Id hope that the former case is not the concensus... If our only problems in the standard are that the UI cannot easily represent something that no existing UI will generate yet then I dont think this is really a problem. Sure, if someone wanted to hand craft a nasty RRULE they could but is that a viable justification? I dont believe it is. That would fall under the 99/1 rule at best I think. > However, Calendaring and > Scheduling is an area intended for WIDE usage by users of all sorts > (including non-human "users" like CPL) - this means that we very > much have to consider whether or not our standard will serve as a > foundation for tools that can be developed for wide usage - if it > cannot be, or if doing so requires making compromises that lead to > interoperability issues - such as not fully supporting "required" > sections of the standards or more subtly supporting them in ways > that lead to varying behavior from the perspective of the end user - > such as displaying or interpreting Reoccurrence rules in a different > manner - we are unlikely to had widespread and useful adoption of > iCalendar and related standards. Sounds like you are expecting lots of cross over between different kinds of C&S systems and non-C&S systems that both utilize our recurrence model/grammar. I suspect that its more likely that they will not intermix and have problems. If any implementor of the grammar also implements a mechanism for dealing with rejection or negotiation (ie: Like we did with REQUEST-STATUS and CPL did with reply codes) then these problems you fear so much should be manageable. This also smells like the "smallest common footprint" argument that was going around for a while a long time ago. Some folks claimed that the full set of features in iCalendar (besides the recurrence model) were too big for small footprint devices like Palms or Cell Phones and that stuff needed to be cut. If that were the case then it would not be possible to make an "Enterprise scalable" iCalendar based system since it would only have a tiny set of features that could fit into a small device. The feature set would be too minimal to make it unpalatable to the user base that would expect LOTS of features on their desktop calendar system. > Successful standards have managed to accommodate a wide range of > user interfaces by in general avoiding areas that highly complex to > represent - I think that as they are currently defined, even with > the proposed changes in the latest Draft of a new version of the > iCalendar standard - the Reoccurrence Rules section IS still very > complex - with good reason perhaps - but well worth time and > attention and thought about how to represent to END USERS the rules Feel free to start some UI discussion if you like. However I think we all agree that C&S is definitely a VERY complex beast to do well in either a standards or a proprietary way. As such I think that we (the WG) need to roll up our collective sleeves, make sure we all understand the issues and then work together to come up with viable solutions that can be implemented going forward. > - if the rules cannot be entered INTO an object - they will not be > in objects to be read back. Im not sure if you are saying that becuase a UI cannot now represent the very very complex (and still rarer) kinds of examples that have been tossed around of late that they cannot be put into the iCalendar object that is sent out or something else. As you noted before and I have suggested above, the ability to generate a very complex recurrence rule is orthogonal to being able to render one that is received. Since a UI may not be able to render a rule (even a moderatly simple one) that it does not generate is not a good justification for some arguments. (After all Outlook uses RRULEs with BYSETPOS in them but they choke on RDATEs, a much much simpler construct to deal with than a grammar!!) > (What I mean by this is the following - generally from a USER's > perspective the USER lives in a given timezone - thus the USER's > calendar should be represented in that timezone. If a given event is > sent out to a group of users, if the event is set for 2:30AM every > Day (to use easy RRULES) and is set for a timezone with Daylight > Savings rules - there will one day a year when the event encounters > an issue - it is set for a time that does not "happen" - how is the > system supposed to deal with this? I think you've been drinking w/Damon a bit... ;^) What I would posit is that just because officially my clock is supposed to automagically shift forward/backward at a predetermined date/time for my time zone; this does not actually mean that all of them really do. (Who here does not have to manually readjust your VCR, DVD, Alarm Clock, Wristwatch, or even computer clock in some cases??) As such, it is somewhat logical for a CUA to consider the entry as 'missed' or 'past' when the clocks magically move forward. For the back case, I would not suggest that they 'reoccur' unless you have the funky case of a multiple repeating alarm w/a sub-shift repeat interval in which case Im open to suggestions. Sure the TZ shift 'hits' need to be dealt with in a reasonable manner but as I noted before this shift occurs at a rather unusual time for most business to be transacting and it these shifts happen in less than .55% of the the possible days in the year. The boundary cases should be addressed but I would not fixate on it given its relative occurance (Typically on a weekend, very early in the AM even). I think we have some bigger and more important stuff to resolve (like recurrence rule handling, TZ naming, etc). > Further, take the following example - remove the TIMEZONE from the > event in question - that is place it into the LOCAL time of the user > - now the "event" will have highly varying behavior as users around > the globe go through daylight savings changes on different days (and > some do not). Just dont forget that if a CU is mobile then you will have to 'readjust' yet again and that may mean reshifting an entry yet again so you would probably want to know the original TZ and its rules since that can be simpler when rerolling sets than shifting back to UTC and then to another local TZ. But Ill leave it as an exercise to the UI coders... ;^o Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0059885F85256A68_= Content-Type: text/html; charset="us-ascii"
shannon@jigzaw.com wrote on 06/08/2001 12:47:24 PM:
> While there is a difference between writing a User Interface
> standard and writing a data/wire standard the two ARE connected
> whether we like it or not.
Sure, they are connected in that the UI needs to represent in some fashion the content recieved over the wire.  However just because we do not have a UI yet that can handle the full extensibility of the format is no reason to say "Lets cut this back now".  As we progress in our ability to devise better UIs we would then have to readd it all back in and go thru this process again.  Since we have already provided a means for a UI to convey back "Hey, I cannot grok this complex (or long or ...) recurrence rule so I will not accept it" I do not think that a UI argument justifys cutting stuff out that we will probably add back in at some point.

Had that argument used for, say, web searching or other kinds of data models/formats then fuzzy logic searches or matches would not be doable now.  Nor would natural language processing (aka "Knowledge Management" to some folks).  These new technlogies greatly extend the very simple "Enter search text" input boxes that can only do literal search matching.

Who is to say that someone does not write a tool that takes in literal text like "Every four years, the first Tuesday after a Monday in November, forever" and geneates the proper RRULE as an output??  Given the text at the end of 4.3.10 (top of p. 45) that it should not be nuclear science to at least 'textify' the incoming RRULE (assuming it was not malformed and adheres to the currently accepted recurrence rule updates/restrictions) so I do not buy that it cannot be done at all.  

> Look at it this way - if the standard is NOT representable in a
> manner that allows for interoperability the standard is dead on arrival.

The UI abilities will eventually catch up.  So should we hamstring the standard now to make the UI coders life simpler now or should we leave it as robust as it is now and let them catch up (and then add back in all that we took out)??  Id hope that the former case is not the concensus...

If our only problems in the standard are that the UI cannot easily represent something that no existing UI will generate yet then I dont think this is really a problem.  Sure, if someone wanted to hand craft a nasty RRULE they could but is that a viable justification?  I dont believe it is.  That would fall under the 99/1 rule at best I think.

>                                           However, Calendaring and
> Scheduling is an area intended for WIDE usage by users of all sorts
> (including non-human "users" like CPL) - this means that we very
> much have to consider whether or not our standard will serve as a
> foundation for tools that can be developed for wide usage - if it
> cannot be, or if doing so requires making compromises that lead to
> interoperability issues - such as not fully supporting "required"
> sections of the standards or more subtly supporting them in ways
> that lead to varying behavior from the perspective of the end user -
> such as displaying or interpreting Reoccurrence rules in a different
> manner - we are unlikely to had widespread and useful adoption of
> iCalendar and related standards.
Sounds like you are expecting lots of cross over between different kinds of C&S systems and non-C&S systems that both utilize our recurrence model/grammar.  I suspect that its more likely that they will not intermix and have problems.  If any implementor of the grammar also implements a mechanism for dealing with rejection or negotiation (ie: Like we did with REQUEST-STATUS and CPL did with reply codes) then these problems you fear so much should be manageable.

This also smells like the "smallest common footprint" argument that was going around for a while a long time ago.  Some folks claimed that the full set of features in iCalendar (besides the recurrence model) were too big for small footprint devices like Palms or Cell Phones and that stuff needed to be cut.  If that were the case then it would not be possible to make an "Enterprise scalable" iCalendar based system since it would only have a tiny set of features that could fit into a small device.  The feature set would be too minimal to make it unpalatable to the user base that would expect LOTS of features on their desktop calendar system.

> Successful standards have managed to accommodate a wide range of
> user interfaces by in general avoiding areas that highly complex to
> represent - I think that as they are currently defined, even with
> the proposed changes in the latest Draft of a new version of the
> iCalendar standard - the Reoccurrence Rules section IS still very
> complex - with good reason perhaps - but well worth time and
> attention and thought about how to represent to END USERS the rules

Feel free to start some UI discussion if you like.  However I think we all agree that C&S is definitely a VERY complex beast to do well in either a standards or a proprietary way.  As such I think that we (the WG) need to roll up our collective sleeves, make sure we all understand the issues and then work together to come up with viable solutions that can be implemented going forward.

> - if the rules cannot be entered INTO an object - they will not be
> in objects to be read back.

Im not sure if you are saying that becuase a UI cannot now represent the very very complex (and still rarer) kinds of examples that have been tossed around of late that they cannot be put into the iCalendar object that is sent out or something else.  As you noted before and I have suggested above, the ability to generate a very complex recurrence rule is orthogonal to being able to render one that is received.  Since a UI may not be able to render a rule (even a moderatly simple one) that it does not generate is not a good justification for some arguments.  (After all Outlook uses RRULEs with BYSETPOS in them but they choke on RDATEs, a much much simpler construct to deal with than a grammar!!)

>     (What I mean by this is the following - generally from a USER's
> perspective the USER lives in a given timezone - thus the USER's
> calendar should be represented in that timezone. If a given event is
> sent out to a group of users, if the event is set for 2:30AM every
> Day (to use easy RRULES) and is set for a timezone with Daylight
> Savings rules - there will one day a year when the event encounters
> an issue - it is set for a time that does not "happen" - how is the
> system supposed to deal with this?
I think you've been drinking w/Damon a bit... ;^)

What I would posit is that just because officially my clock is supposed to automagically shift forward/backward at a predetermined date/time for my time zone; this does not actually mean that all of them really do.  (Who here does not have to manually readjust your VCR, DVD, Alarm Clock, Wristwatch, or even computer clock in some cases??)  As such, it is somewhat logical for a CUA to consider the entry as 'missed' or 'past' when the clocks magically move forward.  For the back case, I would not suggest that they 'reoccur' unless you have the funky case of a multiple repeating alarm w/a sub-shift repeat interval in which case Im open to suggestions.

Sure the TZ shift 'hits' need to be dealt with in a reasonable manner but as I noted before this shift occurs at a rather unusual time for most business to be transacting and it these shifts happen in less than .55% of the the possible days in the year.  The boundary cases should be addressed but I would not fixate on it given its relative occurance (Typically on a weekend, very early in the AM even).  I think we have some bigger and more important stuff to resolve (like recurrence rule handling, TZ naming, etc).

> Further, take the following example - remove the TIMEZONE from the
> event in question - that is place it into the LOCAL time of the user
> - now the "event" will have highly varying behavior as users around
> the globe go through daylight savings changes on different days (and
> some do not).
Just dont forget that if a CU is mobile then you will have to 'readjust' yet again and that may mean reshifting an entry yet again so you would probably want to know the original TZ and its rules since that can be simpler when rerolling sets than shifting back to UTC and then to another local TZ.  But Ill leave it as an exercise to the UI coders... ;^o

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0059885F85256A68_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 11 13:14:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15127 for ; Mon, 11 Jun 2001 13:14:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BGs3E10965 for ietf-calendar-bks; Mon, 11 Jun 2001 09:54:03 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BGs1J10961 for ; Mon, 11 Jun 2001 09:54:01 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id LAA03490 for ; Mon, 11 Jun 2001 11:51:19 -0500 From: "Shannon J. Clark" To: Subject: RE: Can we fix BYSETPOS? Date: Mon, 11 Jun 2001 11:53:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <15140.53379.536069.736469@grandcentral.cs.columbia.edu> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To follow up on this thought. The current standard is highly vague in many areas - which leads us to see at present, and to predict in the future, issues around interoperability and varying interpretations of certain types of complex (and perhaps even not-so-complex) structures - especially around RRULES. Indeed it is the case that in use cases that involve direct interaction between C&S systems these cases could be negotiated by way of messages like "too complex for me to deal with" or "non-sensical rule detected" - however iCalendar is intended as a DATA standard - which means that it should be usable as an interchange structure ABSENT messages and communications. It should be usable as a format to STORE calendaring data for interchange BETWEEN tools. This should be doable in a NON-INTERACTIVE manner - i.e. store to fixed media and move to another machine absent communications between the two Calendaring and Scheduling systems. Perhaps this is not a primary case that many application developers have been considering - certainly the issues that common tools like MS Outlook have with multi-event iCalendar files shows that the primary use case has been perceived as a message encapsulating ONE object - but it seems like a highly valuable and useful use case is an ability to STORE an entire calendar structure to a persistent media in a format that other tools can read and interpret in a useful and consistent manner. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Jonathan Lennox Sent: Monday, June 11, 2001 9:07 AM To: Alan Davies Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? On Friday, June 8 2001, "Alan Davies" wrote to "Jonathan Lennox, ietf-calendar@imc.org" saying: > Why should we prevent this from happening? Many useful languages and data > formats can express absurdities/contradictions. Unless arbitrary restrictions > are placed all over iCalendar, it'll always be possible to create an > 'absurd' object. > > Without arbitrary restrictions, each implementor has to decide what they > consider to be absurd. If you send me an object containing the > "BYSECOND=0,1,2,3,4,..." recurrence rule, you'd get the same response > that you would if you sent me three quadrillion RDATEs. Something along > the lines of: > > REQUEST-STATUS:3.1;Ridiculous property value;RECUR:[...] > or maybe > REQUEST-STATUS:3.2;This system is not yet fully Y100M compliant;RECUR:[...] As we've discussed before on these lists, we have two choices when it comes to dealing with absurd statuses: 1. Let each implementation decide what it isn't going to handle. 2. Let the standard limit what implementations have to support. The problem with choice 1 is that it effectively abandons interoperability. If I generate a calendar object, I have *no idea* whether any given server is going to be able to deal with it correctly, or is going to reject it. Remember, RFC 2445 is a data format. You're not always running in an environment where you're going to get back a REQUEST-STATUS to try to negotiate a sensible representation. Consider an "Export as iCalendar" option, for instance. Thus, the track I've been advocating -- and I think a lot of the other people here have agreed with me -- is that we instead have to limit the things the specification allows. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jun 11 13:56:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15968 for ; Mon, 11 Jun 2001 13:56:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BHdf912124 for ietf-calendar-bks; Mon, 11 Jun 2001 10:39:41 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BHdcJ12119 for ; Mon, 11 Jun 2001 10:39:39 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id MAA03604 for ; Mon, 11 Jun 2001 12:36:57 -0500 From: "Shannon J. Clark" To: Subject: RE: Can we fix BYSETPOS? - Limits of various types Date: Mon, 11 Jun 2001 12:39:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <5.0.0.25.0.20010611101901.02ac3c38@imap1.in.steltor.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To build on this thought... There is a distinction that we should keep in mind when thinking about and suggesting limitations and/or restrictions built into the standard. Certainly the standard should be able to stretch from handling a representation of ONE event taking a few K of space to store to handling millions of user's information for many years (your multi-gigabyte example). IF the large scale is built by adding individual entries this should be feasible - there are significent programming and database issues from the implementer's perspective - some of which do suggest certain modifications to the standard to help accommodate this situation - but the standard should be able to handle high use situations as well as low-use cases. (for example, in a large scale implementation with many calendars in the calendar store extracting vTimezone information into a baseline set and avoiding excess storage and search requirements in the various vCalendars may make a lot of sense, this is fine as long as the interfaces to the calendar store correctly generate full iCalendar operations in interoperability cases - i.e. when exporting a given vCalendar the vTimezones required by that particular vCalendar are added back) That said, this is a case of scaling up, not a case of avoiding absurdity. Avoiding absurdity is looking at a couple of main questions. One - Does the structure suggested represent something even potentially useful? Especially important is does it somehow define or encapsulate information NOT captured in alternative representations (see the difference between storing a START and END time vs. storing a START time and a duration - they result initially in displaying the same event, but they encapsulate different information - by storing (and thus fixing a duration) behavior MIGHT differ should the start-time be changed. This is probably a case that should be clarified in the standard.) Two - Is it possible for User Interfaces to BOTH enter this case AND display this case in a consistent manner. Translation - is interpreting this case possible or is it ALWAYS vague? Three - If there are MULTIPLE possible interpretations - which suggests that different vendor's tools will make differing interpretations - we break interoperability. This means the standard should IDENTIFY these cases and DEFINE correct behavior (see issues such as whether ONE DAY == 24 HOURS, or RRULES defining a reoccurring event on a non-existent day or time) Basically the standard should define what minimum set of features and functions are required by a calendaring information storage system - optional features should truly be optional and required features truly required. The major issues come up where there is a great deal of room for interpretation - a standard should avoid interpretation issues as much as possible. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Alan Davies Sent: Monday, June 11, 2001 10:55 AM To: Jonathan Lennox Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? At 10:06 AM 11/06/2001 -0400, Jonathan Lennox wrote: >As we've discussed before on these lists, we have two choices when it comes >to dealing with absurd statuses: > >1. Let each implementation decide what it isn't going to handle. >2. Let the standard limit what implementations have to support. > >The problem with choice 1 is that it effectively abandons interoperability. >If I generate a calendar object, I have *no idea* whether any given server >is going to be able to deal with it correctly, or is going to reject it. > >Remember, RFC 2445 is a data format. You're not always running in an >environment where you're going to get back a REQUEST-STATUS to try to >negotiate a sensible representation. Consider an "Export as iCalendar" >option, for instance. > >Thus, the track I've been advocating -- and I think a lot of the other >people here have agreed with me -- is that we instead have to limit the >things the specification allows. If this were true then there would be absolute limits to everything within iCalendar- maximum number of RDATES, ATTENDEES, max components in an object, maximum size of an object, etc. If a (valid) iCalender object was created that contained, say, several years worth of all employees' agendas for a large corporation, it could feasably be 100's of Gigabytes in size. You'd still have *no idea* whether or not anyone would be able to import this object, or without pared down RRULEs. (I don't think there's anything wrong with simplifying RRULEs, I just don't think that preventing absurdity is a valid or applicable reason) --Alan From owner-ietf-calendar@mail.imc.org Mon Jun 11 14:14:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16239 for ; Mon, 11 Jun 2001 14:14:41 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BHsoG12477 for ietf-calendar-bks; Mon, 11 Jun 2001 10:54:50 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BHsnJ12473 for ; Mon, 11 Jun 2001 10:54:49 -0700 (PDT) To: Eric Busboom Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Mon, 11 Jun 2001 13:53:47 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/11/2001 01:57:02 PM, Serialize complete at 06/11/2001 01:57:02 PM Content-Type: multipart/alternative; boundary="=_alternative 00623C0985256A68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00623C0985256A68_= Content-Type: text/plain; charset="us-ascii" Eric Busboom wrote on 06/11/2001 11:32:45 AM: > Or, you could just add another exrule: > > RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 > EXRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=0,20; > EXRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=40; Or I could have used several RRULEs: RRULE:FREQ=DAILY;BYHOUR=9,10,11,13,14,15;BYMINUTE=0,20,40 RRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=40 RRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=0,20 or other several mixes. The point is that BYSETPOS is useful for the combination I put together for a sub-day BYxxx subcomponent. > Certainly there are many rules that can be expressed with BYSETPOS -- for > any restriction you can always invent a counter example. Which means that it is useful for those restriction cases you proposed. > But we only need > to implement each significant case once; we don't need to support every > fringe case in a wide variety of ways. Fringe cases are like needing to resolve how a CUA should behave if a repeat instance occurs during a TZ shift given its frequency of occurance. If you mean that any sub-day BYxxx subcomponent is fringe then why not just argue to remove them entirely?? I see no logical explaination for removing BYSETPOS for recurrences that are sub-day (apart from the value range is +/-31M). If the grammar can express a set that large (or at a sub-day recurrence at all) then it is logical to think that someone may want (or even NEED) the ability to filter on particular instances just like in the super-day recurrence cases. > Can you identify some rule of general significance that absolutely > requires BYSETPOS? If not, then we can keep the proposed BYSETPOS > restrictions without impairing the utility of the recurrence rules. Sure, for the same reason that any super-day recurrence set needs to have BYSETPOS; the sub-day recurrence set has the _exact_ same needs. > > There may be other usage models (ie: SKiCAL or some future ones) that > > may need it to have sub-day repeats and need BYSETPOS to achieve the > > same results that day (or larger) repeat intervals enjoy. > > Why do we care if there are other situations where an implementation > COULD use BYSETPOS? We should only care if they MUST use it. Given the > problems we have already identified it, we should not keep unnecessary > flexibility. Whoa Hoss! Thats a big step between COULD and MUST and I havent seen any justification for your distinctions. BYSETPOS can occur in _ANY_ recurrence rule that has at least 1 BYxxx subcomponent in it (otherwise its non-sensical since the 'set' is just 1 instance). If you need to see why it is necessary to have, revisit any of the examples in the RFC 2445 (starting on p118) and just change them to be sub-day instead of super-day recurrence intervals. Im not sure exactly what "problems" we have already identified apart from "What is the 'set' referred to by BYSETPOS?" and the fact that it was published assuming super-day recurrence intervals (hence the limit of +/-366). The former is simply a case of the authors not being clear in their text (and the WG not catching this during Last Call). The latter is an acknowledged oversight that needs to be corrected. What is the likelyhood that the will be some C&S system that uses sub-day recurrence? Well given the model for SKiCAL Id say that it is not far fetched to assume it will happen. What is the likelyhood that I make a CUA that generates something as abusive as the "Repeat every second, every day of the year" and that uses a BYSETPOS to select them all (making it useless in this case really)? Very very very very very (did I say very yet?) unlikely. Am I likely to support an overly large BYSETPOS (or for that matter 'abusive' recurrence rule)? Probably not. I have throttles in my code to prevent this kind of abuse (can any one say C&S Spam??) So I ask you again then that if there there is a model that may need it (ie: SKiCAL or something else that will come down the pipeline) then why NOT keep it in for completeness? If your (the royal you) implementation does not support sub-day recurrence anyway you wont need to be worried about "BYSETPOS=31000005,3100006" either now will you? Since we CAN generate a set of repeat instances with > 366 value, we NEED to have BYSETPOS be able to select them all. Otherwise we could wind up with some instances that are not selectable or filterable. I do not think we should 'revise' the grammar to be such that we need to 'rerevise' it later when someone new shows up with the need to have what we took out now. > And that restricts interoperability. If every rule that uses BYSETPOS can > also be implemented without it, and some implementation reject some > BYSETPOS rules, then we have an unnecessary interoperability problem -- > those that use BYSETPOS unnecessarily will not be understood by those that > do not accept BYSETPOS. I am nearly tempted to agree w/your claim about alternate ways to code up recurrence rules w/o BYSETPOS but then I tried to do the "real world" one from the RFC 2445 that matches my pay schedule: "the last work day of the month". This is currently a very simple rule: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 but in 5 min of chewing on it I could not figure a different way to do it in RRULEs unless I multiple RRULEs per year that 'know' what months have workdays as 'last days' and which do not, and then repeated that set out for as many years as the sample which was infinite!. Perhaps you can give me an alternate w/o a BYSETPOS that resolves to the same set of dates w/o it being several pages long... There will always be some interop issues but I suspect they are more related to implementation architectures rather than to 'flaws' in the standards. If a C&S system has absolutely no concept of seconds (ie: "We only allow scheduling on minute boundaries") then does this mean we should remove BYSECOND from our recurrence grammar? No. What we need is a way for them to interop as best that we can hope for and have some logical behaviour for dealing with these cases (and that does belong in our specs!) > We already have strong evidence that this will be the case -- CPL will not > be able to accept every BYSETPOS rule under the current spec for RECUR. And Outlook wont accept RDATEs. Should we drop them from the spec? Of course not! The spec needs to have a clear and concise means for dealing with interop issues like this (ie: REQUEST-STATUS in our case). > It is much better that we restrict BYSETPOS now and avoid these problems. Not QED yet... If the grammar can generate a set of instances that cannot be filtered or accessed by BYSETPOS then we have a problem, not a solution. > So, Bruce, can you demonstrate that there exist common rules that cannot > be constructed with the proposed restrictions to BYSETPOS? Sure, see above for the "Last workday of the month" example. > If not, then > let's keep the restrictions. Guess then that the new restrictions are not yet in... As an implementor I like to see some restrictions in place to make my coding task easier. They allow me to better tune my engine to be faster or allow me to cut some corners in some areas. As the Method Reviewer I do not like to see changes that are overly heavy handed and not forward looking. The proposed restrictions for sub-day recurrence just set off alarms to me when I look forward to future reuse of the grammar. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00623C0985256A68_= Content-Type: text/html; charset="us-ascii"
Eric Busboom <eric@softwarestudio.org> wrote on 06/11/2001 11:32:45 AM:
> Or, you could just add another exrule:
>
>  RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
>  EXRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=0,20;
>  EXRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=40;
Or I could have used several RRULEs:

    RRULE:FREQ=DAILY;BYHOUR=9,10,11,13,14,15;BYMINUTE=0,20,40
   RRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=40
   RRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=0,20
or other several mixes.  The point is that BYSETPOS is useful for the combination I put together for a sub-day BYxxx subcomponent.  

> Certainly there are many rules that can be expressed with BYSETPOS -- for
> any restriction you can always invent a counter example.

Which means that it is useful for those restriction cases you proposed.

>                                                      But we only need
> to implement each significant case once; we don't need to support every
> fringe case in a wide variety of ways.
Fringe cases are like needing to resolve how a CUA should behave if a repeat instance occurs during a TZ shift given its frequency of occurance.  If you mean that any sub-day BYxxx subcomponent is fringe then why not just argue to remove them entirely??  I see no logical explaination for removing BYSETPOS for recurrences that are sub-day (apart from the value range is +/-31M).  

If the grammar can express a set that large (or at a sub-day recurrence at all) then it is logical to think that someone may want (or even NEED) the ability to filter on particular instances just like in the super-day recurrence cases.

> Can you identify some rule of general significance that absolutely
> requires BYSETPOS?  If not, then we can keep the proposed BYSETPOS
> restrictions without impairing the utility of the recurrence rules.
Sure, for the same reason that any super-day recurrence set needs to have BYSETPOS; the sub-day recurrence set has the _exact_ same needs.  

> > There may be other usage models (ie: SKiCAL or some future ones) that
> > may need it to have sub-day repeats and need BYSETPOS to achieve the
> > same results that day (or larger) repeat intervals enjoy.
>
> Why do we care if there are other situations where an implementation
> COULD use BYSETPOS? We should only care if they MUST use it. Given the
> problems we have already identified it, we should not keep unnecessary
> flexibility.
Whoa Hoss!  Thats a big step between COULD and MUST and I havent seen any justification for your distinctions.  BYSETPOS can occur in _ANY_ recurrence rule that has at least 1 BYxxx subcomponent in it (otherwise its non-sensical since the 'set' is just 1 instance).  If you need to see why it is necessary to have, revisit any of the examples in the RFC 2445 (starting on p118) and just change them to be sub-day instead of super-day recurrence intervals.  

Im not sure exactly what "problems" we have already identified apart from "What is the 'set' referred to by BYSETPOS?" and the fact that it was published assuming super-day recurrence intervals (hence the limit of +/-366).  The former is simply a case of the authors not being clear in their text (and the WG not catching this during Last Call).  The latter is an acknowledged oversight that needs to be corrected.

<HAT IMPLEMENTOR=ON METHOD_REVIEWER=OFF>
What is the likelyhood that the will be some C&S system that uses sub-day recurrence?  Well given the model for SKiCAL Id say that it is not far fetched to assume it will happen.
What is the likelyhood that I make a CUA that generates something as abusive as the "Repeat every second, every day of the year" and that uses a BYSETPOS to select them all (making it useless in this case really)?  Very very very very very (did I say very yet?) unlikely.
Am I likely to support an overly large BYSETPOS (or for that matter 'abusive' recurrence rule)?  Probably not.  I have throttles in my code to prevent this kind of abuse (can any one say C&S Spam??)
</HAT>

So I ask you again then that if there there is a model that may need it (ie: SKiCAL or something else that will come down the pipeline) then why NOT keep it in for completeness?  If your (the royal you) implementation does not support sub-day recurrence anyway you wont need to be worried about "BYSETPOS=31000005,3100006" either now will you?  

Since we CAN generate a set of repeat instances with > 366 value, we NEED to have BYSETPOS be able to select them all.  Otherwise we could wind up with some instances that are not selectable or filterable.  I do not think we should 'revise' the grammar to be such that we need to 'rerevise' it later when someone new shows up with the need to have what we took out now.

> And that restricts interoperability. If every rule that uses BYSETPOS can
> also be implemented without it, and some implementation reject some
> BYSETPOS rules, then we have an unnecessary interoperability problem --
> those that use BYSETPOS unnecessarily will not be understood by those that
> do not accept BYSETPOS.
I am nearly tempted to agree w/your claim about alternate ways to code up recurrence rules w/o BYSETPOS but then I tried to do the "real world" one from the RFC 2445 that matches my pay schedule: "the last work day of the month".  This is currently a very simple rule:

     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1

but in 5 min of chewing on it I could not figure a different way to do it in RRULEs unless I multiple RRULEs per year that 'know' what months have workdays as 'last days' and which do not, and then repeated that set out for as many years as the sample which was infinite!.  Perhaps you can give me an alternate w/o a BYSETPOS that resolves to the same set of dates w/o it being several pages long...

There will always be some interop issues but I suspect they are more related to implementation architectures rather than to 'flaws' in the standards.  If a C&S system has absolutely no concept of seconds (ie: "We only allow scheduling on minute boundaries") then does this mean we should remove BYSECOND from our recurrence grammar? No.  What we need is a way for them to interop as best that we can hope for and have some logical behaviour for dealing with these cases (and that does belong in our specs!)

> We already have strong evidence that this will be the case -- CPL will not
> be able to accept every BYSETPOS rule under the current spec for RECUR.
And Outlook wont accept RDATEs.  Should we drop them from the spec?  Of course not!  The spec needs to have a clear and concise means for dealing with interop issues like this (ie: REQUEST-STATUS in our case).

> It is much better that we restrict BYSETPOS now and avoid these problems.
Not QED yet...  If the grammar can generate a set of instances that cannot be filtered or accessed by BYSETPOS then we have a problem, not a solution.

> So, Bruce, can you demonstrate that there exist common rules that cannot
> be constructed with the proposed restrictions to BYSETPOS?

Sure, see above for the "Last workday of the month" example.

>                                                             If not, then
> let's keep the restrictions.
Guess then that the new restrictions are not yet in...  

As an implementor I like to see some restrictions in place to make my coding task easier.  They allow me to better tune my engine to be faster or allow me to cut some corners in some areas.

As the Method Reviewer I do not like to see changes that are overly heavy handed and not forward looking.  The proposed restrictions for sub-day recurrence just set off alarms to me when I look forward to future reuse of the grammar.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00623C0985256A68_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 11 16:09:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18006 for ; Mon, 11 Jun 2001 16:09:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BJe9i14814 for ietf-calendar-bks; Mon, 11 Jun 2001 12:40:09 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BJe7J14810 for ; Mon, 11 Jun 2001 12:40:07 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f5BJcQ711349; Mon, 11 Jun 2001 12:38:27 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 11 Jun 2001 12:38:26 -0700 (PDT) From: Eric Busboom X-X-Sender: To: cc: Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 11 Jun 2001 Bruce_Kahn@iris.com wrote: > Or I could have used several RRULEs: > > RRULE:FREQ=DAILY;BYHOUR=9,10,11,13,14,15;BYMINUTE=0,20,40 > RRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=40 > RRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=0,20 > > or other several mixes. The point is that BYSETPOS is useful for the > combination I put together for a sub-day BYxxx subcomponent. > It is the useful features that have resulted in recurrence rules being absurdly complex. We should be focusing on the mandatory features. The problem we have is that if we allow BYSETPOS to operate over the entire range of seconds in a year, it is possible for CUAs to generate rules that CPU-bound servers will reject because they are too complex to evaluate in a small amount of time. I believe that we can restrict recurrence rules to only using BYSETPOS for day-scale events, thus eliminating the complexity problem for all but the most feeble servers. I also think that any plausible rule that would use BYSETPOS for sub-day intervals can be re-written without BYSETPOS, so the restriction does not reduce the functionality of recurrence rules. You are arguing that BYSETPOS for sub-day intervals is useful and that there may be cases where some CUA will want to use them. That same argument could support embedding TCL code in recurrence rules. Neither case is necessary, and both of them cause interoperability problems related to computational complexity. The proposed restrictions are a compromise between a complexity problem that we know exists and a set of future possibilities that we suppose exist. We can't design for a vague an unknown future; if you've got some plausible use cases that cannot be implemented without BYSETPOS on a sub-day scale, then we can do some analysis. Otherwise, we are just guessing. So, can you show some rules for a plausible scenario that cannot be implemented without BYSETPOS on a sub-day interval? eric. From owner-ietf-calendar@mail.imc.org Mon Jun 11 17:15:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19203 for ; Mon, 11 Jun 2001 17:15:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BKpqO16717 for ietf-calendar-bks; Mon, 11 Jun 2001 13:51:52 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BKpoJ16713 for ; Mon, 11 Jun 2001 13:51:51 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA28498; Mon, 11 Jun 2001 16:51:50 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id QAA20083; Mon, 11 Jun 2001 16:51:50 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15141.12133.617001.34123@grandcentral.cs.columbia.edu> Date: Mon, 11 Jun 2001 16:51:49 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, June 11 2001, "Bruce_Kahn@iris.com" wrote to "Eric Busboom, ietf-calendar@imc.org" saying: > As an implementor I like to see some restrictions in place to make my > coding task easier. They allow me to better tune my engine to be faster > or allow me to cut some corners in some areas. > > As the Method Reviewer I do not like to see changes that are overly heavy > handed and not forward looking. The proposed restrictions for sub-day > recurrence just set off alarms to me when I look forward to future reuse > of the grammar. I'm not (overly) concerned about keeping coding tasks easy -- it's a *good idea*, of course, but it's not an overriding concern. I am, however, concerned about whether it's possible to implement a specification efficiently. (Where "efficiently" means using a predictable, bounded amount of CPU time and memory to perform standard operations in the specification.) In iCalendar COS, we have a fairly classic "pick-two" situation. We can have at most two of: 1. Efficient implementation 2. Predictable interoperability 3. Full generality RFC 2445, in theory, decided to drop point #1, though I doubt this was realized at the time. Implementors, in practice, usually dropped #3 and thus #2. What I'm proposing, instead, is to drop #3 formally, and thus keep #1 and #2. Here's some proposed wording as to how I'd accomplish this, while still leaving room for future generality in appropriate environments. I hope this would be generally acceptable. Applications which interpret iCalendar COS objects MUST support any COS object which conforms to the following restrictions: [... list of restrictions, to be determined by the group. This includes the restricted BYSETPOS rules. It should be easy and efficient to check whether a COS object complies with the restrictions.] Applications which interpret iCalendar COS objects MAY also support COS objects which violate or exceed one or more of the above limitations. Applications which generate iCalendar COS objects SHOULD NOT generate a COS object which violates or exceeds any of the above limitations, unless they know, through means not defined in this specification, that every application which will attempt to interpret the COS object can do so sucessfully. This solves the "what SkiCal needs" problem -- if SkiCal needs (e.g.) sub-day BYSETPOS rules, it can define a looser set of restrictions for SkiCal. Will this proposal let us come to some consensus? Are there thoughts about what an appropriate list of these restrictions would be? (I could contribute some for the RRULE family, but not for the rest of the COS, which I don't know very well). -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jun 11 17:32:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19416 for ; Mon, 11 Jun 2001 17:32:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BL6MR17117 for ietf-calendar-bks; Mon, 11 Jun 2001 14:06:22 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BL6KJ17113 for ; Mon, 11 Jun 2001 14:06:20 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA29391; Mon, 11 Jun 2001 17:06:20 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id RAA20141; Mon, 11 Jun 2001 17:06:20 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15141.13003.50097.603696@grandcentral.cs.columbia.edu> Date: Mon, 11 Jun 2001 17:06:19 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, June 11 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > lennox@cs.columbia.edu wrote on 06/08/2001 01:12:27 PM: > > See, this is what I mean about BYSETPOS being confusing. > > Yep, the text about "set of events specified by the rule" (p. 44) is overly vague. However it is possible to divine the intent > from the examples (and hopefully we can get some common understanding > about how to clarify this in the next update we make). [Description elided] Actually, the reason I was confused is that the definition of the set *isn't* clear from the examples, because the examples only show the use of BYSETPOS with expanding BY* rules. The confusion comes from the use of BYSETPOS with contracting BY* rules, which no examples show. (I suppose the use of INTERVAL with BYSETPOS isn't technically ambiguous, but *I* certainly mis-interpreted it. No examples show this either.) Consider, e.g.: DTSTART;TZID=US-Eastern:19970929T090000 RRULE:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=TU,TH;BYSETPOS=-1 Does this mean "The last Tuesday or Thursday of the week, every April and June"? Or "The last Tuesday or Thursday of April, and the last Tuesday or Thursday of June, every year"? Or "The last Tuesday or Thursday of (April or June), every year"? The conclusion we came to on the list, which got folded into Eric Busboom's latest draft, is: BYSETPOS operates on a set of events in one interval of the recurrence rule. For a WEEKLY rule, the interval is one week, for a MONTHLY rule, one month, and for a YEARLY rule, one year. I like this interpretation -- it's clean, simple, easy to explain, and easy to compute. If we re-allow the use of BYSETPOS with sub-day recurrences, as you wanted (hopefully, with conditional restrictions forbidding it, using the language that I had in my previous mail), this would apply to MINUTELY, HOURLY, and DAILY rules as well, but the first sentence would still apply. (BYSETPOS with a SECONDLY rule would never make sense.) I'd extend this further, by changing the current sentence in RFC 2445 It [BYSETPOS] MUST only be used in conjunction with another BYxxx rule part. to It MUST only be used in conjunction with other BYxxx rule parts. At least one of these BYxxx rule parts must be an "expanding" rule part, that is, a BYxxx rule part representing an interval of time smaller than FREQ. Do you object to this? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jun 11 17:52:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19701 for ; Mon, 11 Jun 2001 17:52:23 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5BLSJn17678 for ietf-calendar-bks; Mon, 11 Jun 2001 14:28:19 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BLSIJ17670 for ; Mon, 11 Jun 2001 14:28:18 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id RAA07245 for ; Mon, 11 Jun 2001 17:28:15 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f5BLSFv28652 for ; Mon, 11 Jun 2001 17:28:15 -0400 (EDT) Message-ID: <036d01c0f2bd$2a081f50$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) Date: Mon, 11 Jun 2001 17:26:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric Busboom" To: Cc: Sent: 11 June, 2001 15:38 Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) > > So, can you show some rules for a plausible scenario that cannot be > implemented without BYSETPOS on a sub-day interval? > The obvious example would be to take Bruce's BYSETPOS poster case and throw in a sub-day part: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=12,13;BYSETPOS=-1,-2 This isn't a terribly unlikely scenario, either. It seems that BYSETPOS is useful primarily when dealing with cases where one time component doesn't "divide" evenly into another, for example, not all months have the same # of days; the number of days & weeks in a year varies from year to year; days with a timezone shift don't have 24 hours (the infamous 1:30 am event could be specified thusly to specify the first instance of 1:30 on appropriate days: RRULE:FREQ=DAILY;BYHOUR=1;BYMINUTE=30;BYSETPOS=1). Graham From owner-ietf-calendar@mail.imc.org Mon Jun 11 18:21:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20086 for ; Mon, 11 Jun 2001 18:21:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BLwCV18443 for ietf-calendar-bks; Mon, 11 Jun 2001 14:58:12 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BLwAJ18439 for ; Mon, 11 Jun 2001 14:58:10 -0700 (PDT) To: Jonathan Lennox Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Mon, 11 Jun 2001 17:59:54 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/11/2001 06:01:37 PM, Serialize complete at 06/11/2001 06:01:37 PM Content-Type: multipart/alternative; boundary="=_alternative 0078845385256A68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078845385256A68_= Content-Type: text/plain; charset="us-ascii" Jonathan Lennox replied with: >> >RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13, >> > 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36, >> > 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59; >> > BYSETPOS=-1 >> > >> >is a legal RFC 2445 recurrence. It expands to approximately three >> >quadrillion events before BYSETPOS is applied. Good luck... >> >> Thanks but by my calculations the set is 60 instances long (one per >> second) and the set repeats every 100000000 years. The BYSETPOS simply selects the instance at second 59 >> making the rest obsolete really. Hmm, does Jonathan has a pet Dino? > >See, this is what I mean about BYSETPOS being confusing. Clearly thats the root of much confusion. I hope my previous posting on decoding helps shed some light on it. If not, Ill defer to that thread to cover any further confusion. >In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 instances >long, not 2. Yes, depending on the the month. >So in my example above, the set is three quadrillion instances long, not >sixty. The FREQ is yearly so that alone would make the entry repeat on a basis of 1 year. You do not factor in the INTERVAL value when trying to calculate the set; it is used when moving the starting point for the next 'rollout'. As such, the only modifier you have to worry about is the BYSECOND. So since your DTSTART date/time value is only being 'expanded' using BYSECOND, the only part of it that will be changed (and added to the 'set') is the seconds value of the time. For example, had you provided a DTSTART;TZID=US-Eastern:20010611T090000 then the 'set' would evaluate out to: 11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST and since the DTSTAMP already used 09:00:00 that is a duplicate that gets ignored in the counting. In any case, the BYSETPOS=-1 then selects the 11-Jun-2001 @ 09:00:59 EDT instance. The next pass around the INTERVAL value is added to the DTSTART to get a (non-compliant) new starting point for evaulation of 11-Jun-100002001 @ 09:00:00 EDT. >How are these not analogous? I think the confusion you have is that you are factoring in the INTERVAL value for the set rollout when you should not. Clearer now?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... From: owner-ietf-calendar@mail.imc.org Date: 06/08/2001 01:12:27 PM AST Subject: Re: Can we fix BYSETPOS? -- Jonathan Lennox lennox@cs.columbia.edu --=_alternative 0078845385256A68_= Content-Type: text/html; charset="us-ascii"
Jonathan Lennox replied with:
>> >RECUR:FREQ=YEARLY;INTERVAL=100000000;BYSECOND=0,1,2,3,4,5,6,7,8,9,10,11,12,13,
>> > 14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,
>> > 37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59;
>> >        BYSETPOS=-1
>> >
>> >is a legal RFC 2445 recurrence.  It expands to approximately three
>> >quadrillion events before BYSETPOS is applied.  Good luck...
>>
>> Thanks but by my calculations the set is 60 instances long (one per
>> second) and the set repeats every 100000000 years.  The BYSETPOS simply selects the instance at second 59
>> making the rest obsolete really.  Hmm, does Jonathan has a pet Dino?
>
>See, this is what I mean about BYSETPOS being confusing.
Clearly thats the root of much confusion.  I hope my previous posting on decoding helps shed some light on it.  If not, Ill defer to that thread to cover any further confusion.

>In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 instances
>long, not 2.
Yes, depending on the the month.

>So in my example above, the set is three quadrillion instances long, not
>sixty.
The FREQ is yearly so that alone would make the entry repeat on a basis of 1 year.  You do not factor in the INTERVAL value when trying to calculate the set; it is used when moving the starting point for the next 'rollout'.  As such, the only modifier you have to worry about is the BYSECOND.  

So since your DTSTART date/time value is only being 'expanded' using BYSECOND, the only part of it that will be changed (and added to the 'set') is the seconds value of the time.  For example, had you provided a DTSTART;TZID=US-Eastern:20010611T090000 then the 'set' would evaluate out to:

11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST

and since the DTSTAMP already used 09:00:00 that is a duplicate that gets ignored in the counting.  In any case, the BYSETPOS=-1 then selects the 11-Jun-2001 @ 09:00:59 EDT instance.  The next pass around the INTERVAL value is added to the DTSTART to get a (non-compliant) new starting point for evaulation of 11-Jun-100002001 @ 09:00:00 EDT.

>How are these not analogous?

I think the confusion you have is that you are factoring in the INTERVAL value for the set rollout when you should not.

Clearer now??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...



From:        owner-ietf-calendar@mail.imc.org
Date:        06/08/2001 01:12:27 PM AST
Subject:        Re: Can we fix BYSETPOS?



--
Jonathan Lennox
lennox@cs.columbia.edu

--=_alternative 0078845385256A68_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 11 18:43:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20293 for ; Mon, 11 Jun 2001 18:43:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BMRUt19119 for ietf-calendar-bks; Mon, 11 Jun 2001 15:27:30 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BMRNJ19114 for ; Mon, 11 Jun 2001 15:27:28 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id SAA08079 for ; Mon, 11 Jun 2001 18:27:20 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f5BMRKv02726 for ; Mon, 11 Jun 2001 18:27:20 -0400 (EDT) Message-ID: <038001c0f2c5$6b1c26a0$092e0165@in.steltor.com> From: "Graham Gilmore" To: References: Subject: Re: BYSETPOS sets and INTERVAL Date: Mon, 11 Jun 2001 18:25:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: "Jonathan Lennox" Cc: "Eric Busboom" ; Sent: 11 June, 2001 17:59 Subject: Re: Can we fix BYSETPOS? > > I think the confusion you have is that you are factoring in the INTERVAL > value for the set rollout when you should not. > If INTERVAL isn't used in calculating the set, then how would one specify a set that was, for example, 2 months or 2 years long? One might want to modify the "last working day of the month" example to be "last working day every 2nd month". INTERVAL would seem the natural choice for this. Sure, I suppose you could specify every 2nd month explicitly with a BYMONTH part, but then the content (not just the expansion) of the RRULE becomes dependent on the DTSTART (i.e. which months are 'every second month'?), which seems wrong somehow. Graham From owner-ietf-calendar@mail.imc.org Mon Jun 11 18:46:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20305 for ; Mon, 11 Jun 2001 18:46:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BMVGu19222 for ietf-calendar-bks; Mon, 11 Jun 2001 15:31:16 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BMVEJ19216 for ; Mon, 11 Jun 2001 15:31:14 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA04205; Mon, 11 Jun 2001 18:31:15 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id SAA20453; Mon, 11 Jun 2001 18:31:15 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15141.18098.373155.181813@grandcentral.cs.columbia.edu> Date: Mon, 11 Jun 2001 18:31:14 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, June 11 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > >So in my example above, the set is three quadrillion instances long, not > >sixty. > > The FREQ is yearly so that alone would make the entry repeat on a basis of > 1 year. You do not factor in the INTERVAL value when trying to calculate > the set; it is used when moving the starting point for the next 'rollout'. > As such, the only modifier you have to worry about is the BYSECOND. > > So since your DTSTART date/time value is only being 'expanded' using > BYSECOND, the only part of it that will be changed (and added to the > 'set') is the seconds value of the time. For example, had you provided a > DTSTART;TZID=US-Eastern:20010611T090000 then the 'set' would evaluate out > to: > > 11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST Ah! This is the thing I missed. Again, a serious omission in the RFC 2445 examples. I understood, from RFC 2445, the concept "information smaller than your smallest BY* parameter, and smaller than your FREQ, should be obtained from DTSTART". The question is, what do you do for fields *larger* than your smallest BY* parameter, but smaller than FREQ? This is only relevant if there's a "gap" in the information. For instance: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=YEARLY;BYMONTHDAY=1 I had interpreted this as meaning ==> (1997 9:00 AM EDT) September 2, October 1 (1997 9:00 AM EST) November 1, December 1 (1998 9:00 AM EST) January 1, February 1, March 1 ... (I.e. treat the "gap" information as "wild" -- as if we had BYMONTH=1,2,3,4,5,6,7,8,9,10,11,12.) Instead, you're saying it's ==> (1997 9:00 AM EDT) September 2 (1998 9:00 AM EDT) September 1 (1999 9:00 AM EDT) September 1 ... (I.e. treat it the same as if we had BYMONTH=9.) Note that the only RFC 2445 examples that address anything like this question are the ones of the form DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU ==> (1997 9:00 AM EDT)September 2,9,16,23,30 (1997 9:00 AM EST)November 4,11,18,25 (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 In this example, we must treat the week of the month as "wild" -- i.e. BYDAY=TU is equivalent to BYDAY=1TU,2TU,3TU,4TU,5TU in a MONTHLY rule. (And to BYDAY=1TU,2TU,...,53TU in a YEARLY rule.) Is BYDAY "special" when it comes to filling in gaps, and in all other cases the gap should be filled in from the DTSTART? Or are gaps different than times smaller than the smallest time unit mentioned in a BY*/FREQ? A very close reading of the RECUR definition seems to show that your interpretation -- the "BYDAY is special, gaps aren't" reading -- is *probably* right, and I guess it allows slightly more generality. However, it certainly wasn't clear, or illustrated. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jun 11 18:46:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20322 for ; Mon, 11 Jun 2001 18:46:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BMVSc19227 for ietf-calendar-bks; Mon, 11 Jun 2001 15:31:28 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BMVGJ19223 for ; Mon, 11 Jun 2001 15:31:16 -0700 (PDT) To: Jonathan Lennox Cc: Alan Davies , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: From: Bruce_Kahn@iris.com Date: Mon, 11 Jun 2001 18:32:58 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/11/2001 06:34:44 PM, Serialize complete at 06/11/2001 06:34:44 PM Content-Type: multipart/alternative; boundary="=_alternative 007B8B7485256A68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007B8B7485256A68_= Content-Type: text/plain; charset="us-ascii" Jonathan responded with: >As we've discussed before on these lists, we have two choices when it comes >to dealing with absurd statuses: > >1. Let each implementation decide what it isn't going to handle. >2. Let the standard limit what implementations have to support. > >The problem with choice 1 is that it effectively abandons interoperability. Well unless you expect _every_ implementation to implement every feature/option the exact same way then this is not really a problem. We would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP (or... ) since every implementation implements only a fixed set of features and we would never have a migration case since the set never grows w/o _every_ implemenation concurrently rolling it out... Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg today for no reason so Im a bit punchy. But the logic that "If my engine does not like Feature X of a protocol for some reason so it wont be able to interop with others that do" is simply a myth if the protocol plans ahead and provides ways for conveying this back (hence some of the REQUEST-STATUS values in iTIP). By having a negotiation mechanism in the protocol you increase your interop chances/abilities, not decrease them. Otherwise LDAP, TLS, SASL, or RFC 1869 and other protocols that have put in such mechanisms would be as interoperable as they are now. >If I generate a calendar object, I have *no idea* whether any given server >is going to be able to deal with it correctly, or is going to reject it. Before we accept that most CUAs are going to actually generate and use some of these "absurd" entries I'd contest the fact that they would to begin with. The existing C&S CUAs from CalConnect do a decent job of not actually generating some of the overly complex, nasty or "absurd" entries so is it realistic to think that the current or immediately pending crop of CUAs are going to generate them? Probably not. Even if someone redid an OpenSource C&S app to generate them; its not likely to be the SOP we will find in day to day usage. For the CPL case the CUA / CS has some restrictions on what it will be able to accept (ie: no sub-day recurrences) but is that an "absurd" case like "repeating every second of every day of the year" or a more realistic case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM EST". The CPL worlds requirements are such that it cannot accept (currently) some kinds of real world examples (not absurdities) and that is fine; its part of their model of things. In the future there will be other models that do not have those restrictions (ie: SKiCAL). Does this mean that a SKiCAL 'valid' (or 'correct' or pick your own term) object is not valid in the CPL context?? Perhaps for now but that may change as Moores law takes over or the requirements / restrictions of CPL evolve. So some may ask why not just remove the "absurd" stuff now but keep in mind that our recurrence grammar is intended to be reusable by anyone else (ie: SKiCAL, CPL, etc) and to be flexible enough that any future needs are not going to force us to make wholesale changes. To this end, removing stuff that could be abusive or absurd given our current expectations but that could be valid later on is just an excercise in frustration for the future updaters. >Remember, RFC 2445 is a data format. You're not always running in an >environment where you're going to get back a REQUEST-STATUS to try to >negotiate a sensible representation. Consider an "Export as iCalendar" >option, for instance. Again this last bit assums that some to-be-written CUA will actually generate internally (and use??) an absurd case and I challenge that assumption. Sure, it is possible to build a CUA that is purposely nasty but is that a realistic norm or a "what about" kind of exception to the rule?? I am also considering the case that the recurrence model is the only part of iCalendar that is adopted (ie: the data actually sent is NOT in iCalendar format entirely). This too relies on the actual underlying transport/protocol to plan for a negotiation or request/response kind of mechanism when dealing with these abusive critters. Is that an issue for iCalendar to deal with or an issue for each reusing implementation/protocol?? >Thus, the track I've been advocating -- and I think a lot of the other >people here have agreed with me -- is that we instead have to limit the >things the specification allows. Its one thing to put the restrictions in the 'base' definition in iCalendar. Its another to put them in any derivative works. I see no issue w/CPL putting restrictions on what they can accept (and I'd hope they do it with some planning for future growth or system improvements). I do see an issue in putting in restrictions that make the grammar incomplete in the base work. Putting logical restrictions on value sets like BYSETPOS is between -366 and 366 for a FREQ=DAILY but -31M and +31M for SECONDLY, etc. is something I think should be done. There are some logical limits to the values given some conditions; I just dont agree w/the proposals to remove some of the actual conditions. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007B8B7485256A68_= Content-Type: text/html; charset="us-ascii"
Jonathan responded with:
>As we've discussed before on these lists, we have two choices when it comes
>to dealing with absurd statuses:
>
>1. Let each implementation decide what it isn't going to handle.
>2. Let the standard limit what implementations have to support.
>
>The problem with choice 1 is that it effectively abandons interoperability.
Well unless you expect _every_ implementation to implement every feature/option the exact same way then this is not really a problem.  We would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP (or... ) since every implementation implements only a fixed set of features and we would never have a migration case since the set never grows w/o _every_ implemenation concurrently rolling it out...  

Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg today for no reason so Im a bit punchy.  But the logic that "If my engine does not like Feature X of a protocol for some reason so it wont be able to interop with others that do" is simply a myth if the protocol plans ahead and provides ways for conveying this back (hence some of the REQUEST-STATUS values in iTIP).  By having a negotiation mechanism in the protocol you increase your interop chances/abilities, not decrease them.  Otherwise LDAP, TLS, SASL, or RFC 1869 and other protocols that have put in such mechanisms would be as interoperable as they are now.

>If I generate a calendar object, I have *no idea* whether any given server
>is going to be able to deal with it correctly, or is going to reject it.
Before we accept that most CUAs are going to actually generate and use some of these "absurd" entries I'd contest the fact that they would to begin with.  The existing C&S CUAs from CalConnect do a decent job of not actually generating some of the overly complex, nasty or "absurd" entries so is it realistic to think that the current or immediately pending crop of CUAs are going to generate them?  Probably not.  Even if someone redid an OpenSource C&S app to generate them; its not likely to be the SOP we will find in day to day usage.

For the CPL case the CUA / CS has some restrictions on what it will be able to accept (ie: no sub-day recurrences) but is that an "absurd" case like "repeating every second of every day of the year" or a more realistic case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM EST".  The CPL worlds requirements are such that it cannot accept (currently) some kinds of real world examples (not absurdities) and that is fine; its part of their model of things.  In the future there will be other models that do not have those restrictions (ie: SKiCAL).

Does this mean that a SKiCAL 'valid' (or 'correct' or pick your own term) object is not valid in the CPL context??  Perhaps for now but that may change as Moores law takes over or the requirements / restrictions of CPL evolve.
So some may ask why not just remove the "absurd" stuff now but keep in mind that our recurrence grammar is intended to be reusable by anyone else (ie: SKiCAL, CPL, etc) and to be flexible enough that any future needs are not going to force us to make wholesale changes.  To this end, removing stuff that could be abusive or absurd given our current expectations but that could be valid later on is just an excercise in frustration for the future updaters.  

>Remember, RFC 2445 is a data format.  You're not always running in an
>environment where you're going to get back a REQUEST-STATUS to try to
>negotiate a sensible representation.  Consider an "Export as iCalendar"
>option, for instance.
Again this last bit assums that some to-be-written CUA will actually generate internally (and use??) an absurd case and I challenge that assumption.  Sure, it is possible to build a CUA that is purposely nasty but is that a realistic norm or a "what about" kind of exception to the rule??

I am also considering the case that the recurrence model is the only part of iCalendar that is adopted (ie: the data actually sent is NOT in iCalendar format entirely).  This too relies on the actual underlying transport/protocol to plan for a negotiation or request/response kind of mechanism when dealing with these abusive critters.  Is that an issue for iCalendar to deal with or an issue for each reusing implementation/protocol??

>Thus, the track I've been advocating -- and I think a lot of the other
>people here have agreed with me -- is that we instead have to limit the
>things the specification allows.
Its one thing to put the restrictions in the 'base' definition in iCalendar.  Its another to put them in any derivative works.  I see no issue w/CPL putting restrictions on what they can accept (and I'd hope they do it with some planning for future growth or system improvements).  I do see an issue in putting in restrictions that make the grammar incomplete in the base work.  

Putting logical restrictions on value sets like BYSETPOS is between -366 and 366 for a FREQ=DAILY but -31M and +31M for SECONDLY, etc. is something I think should be done.  There are some logical limits to the values given some conditions; I just dont agree w/the proposals to remove some of the actual conditions.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 007B8B7485256A68_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 11 19:28:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20629 for ; Mon, 11 Jun 2001 19:28:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BNAYJ20104 for ietf-calendar-bks; Mon, 11 Jun 2001 16:10:34 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BNAVJ20099 for ; Mon, 11 Jun 2001 16:10:32 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA05907; Mon, 11 Jun 2001 19:10:34 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id TAA20554; Mon, 11 Jun 2001 19:10:33 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15141.20457.210774.688358@grandcentral.cs.columbia.edu> Date: Mon, 11 Jun 2001 19:10:33 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Alan Davies , ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, June 11 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Alan Davies, ietf-calendar@imc.org" saying: > Jonathan responded with: > >As we've discussed before on these lists, we have two choices when it > >comes to dealing with absurd statuses: > > > >1. Let each implementation decide what it isn't going to handle. > >2. Let the standard limit what implementations have to support. > > > >The problem with choice 1 is that it effectively abandons > >interoperability. > > Well unless you expect _every_ implementation to implement every > feature/option the exact same way then this is not really a problem. We > would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP > (or... ) since every implementation implements only a fixed set of > features and we would never have a migration case since the set never > grows w/o _every_ implemenation concurrently rolling it out... iCalendar COS isn't like IMAP4 or SMTP. iCalendar COS is like RFC822 or HTML. It's a data format. iTIP is like IMAP4 or SMTP. It's a transaction protocol. When RFC822 was extended with MIME you got "If you can see this, your mail reader doesn't understand MIME" blocks, and large unreadable blobs of base64-encoded text. When HTML was extended with frames, you got sections that were supposed to contain equivalent content, but actually contained "Netscape Now!" buttons. Or, in other words, extensibility in data formats is almost always painful. Now, mind you, sometimes you need to have your data formats be extensible. However, when you do this, experience seems to have shown that the right thing to do is to have the thing say, up front, "I'm an extended-X. I may look like an original-X, but I'm not, so if you don't know what an extended-X is, give up now." This also means that you need a clear distinction between "original-X" and "extended-X." Having them shade vaguely into each other is a bad idea. > Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg > today for no reason so Im a bit punchy. But the logic that "If my engine > does not like Feature X of a protocol for some reason so it wont be able > to interop with others that do" is simply a myth if the protocol plans > ahead and provides ways for conveying this back (hence some of the > REQUEST-STATUS values in iTIP). If there's a protocol which is specific to your application, yes. Are you saying I shouldn't be able to e-mail you an iCalendar object, or to put it on my web page? > Before we accept that most CUAs are going to actually generate and use > some of these "absurd" entries I'd contest the fact that they would to > begin with. The existing C&S CUAs from CalConnect do a decent job of not > actually generating some of the overly complex, nasty or "absurd" entries > so is it realistic to think that the current or immediately pending crop > of CUAs are going to generate them? Probably not. Even if someone redid > an OpenSource C&S app to generate them; its not likely to be the SOP we > will find in day to day usage. Oh, absolutely. I reached this point of view by worring about entries generated by actively hostile adversaries, who want to launch a denial-of-service attack on my server by feeding me input that makes me fall over. If you're not worried about this case, things are not nearly so much of a problem. (Though I would say that current experience in the Internet seems to indicate that you *do* have to worry about this.) > For the CPL case the CUA / CS has some restrictions on what it will be > able to accept (ie: no sub-day recurrences) but is that an "absurd" case > like "repeating every second of every day of the year" or a more realistic > case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM > EST". The CPL worlds requirements are such that it cannot accept > (currently) some kinds of real world examples (not absurdities) and that > is fine; its part of their model of things. In the future there will be > other models that do not have those restrictions (ie: SKiCAL). My original model of CPL was to define a number of restrictions on what a CPL script had to accept. This was where the IESG got all up in arms -- "you're breaking interoperability with iCalendar!" Okay, I figured, interoperability with iCalendar on (moderately) complex or pathological cases is important, so we need a good definition of what's allowed and what's too complex or pathological. But now I'm hearing that CalSch *doesn't* want to define this, that each implementation is allowed to pick its own definition of complex and pathological events. So I find myself in the situation that I'm told I have to be fully interoperable with a number of implementations which aren't fully interoperable with each other. This is ... challenging. Is this group willing to say, definitively: Every iCalendar CS or CUA implementation is allowed to pick its own definition, aribitrarily, of what event descriptions are too complex for it to handle, and refuse to handle such event descriptions. Such implementations are still fully compliant implementations of RFC 2445 and its successors. If so, I'll just resurrect the last CPL draft with some minor editorial changes, tell the IESG about the CalSch working group consensus, and be on my way to Proposed Standard. However, I suspect the IESG would have *serious* concerns with this statement. (And I don't think the group would be willing to say it, anyway.) As I mentioned in my earlier mail, I think the following statement would be much more generally acceptable: Every compliant iCalendar CS or CUA must be able to correctly understand a certain basic subset of event descriptions, defined by the specification. They may also understand more general event descriptions. Compliant iCalendar CS or CUAs should not generate event descriptions beyond the basic subset unless they know that all receivers of the event can understand them correctly. Profiles of iCalendar can declare that a larger subset of iCalendar is required for that profile. > Again this last bit assums that some to-be-written CUA will actually > generate internally (and use??) an absurd case and I challenge that > assumption. Sure, it is possible to build a CUA that is purposely nasty > but is that a realistic norm or a "what about" kind of exception to the > rule?? Some of both. If I'm writing a powerful CUA, I want to know what sorts of things I should *avoid* generating to prevent a CS from choking. (For instance, I know of calendaring applications that refuse to deal with events with more than 500 or so repetitions. I don't think these applications currently make any claim to iCalendar support -- they're just vCalendar, or something proprietary, I think -- but it's the sort of thing you have to worry about.) -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Mon Jun 11 19:37:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20708 for <calsch-archive@odin.ietf.org>; Mon, 11 Jun 2001 19:37:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5BNMuJ20374 for ietf-calendar-bks; Mon, 11 Jun 2001 16:22:56 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BNMsJ20370 for <ietf-calendar@imc.org>; Mon, 11 Jun 2001 16:22:55 -0700 (PDT) To: Eric Busboom <eric@softwarestudio.org> Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: <OF353DE398.F9146B7C-ON85256A68.007C7A08@iris.com> From: Bruce_Kahn@iris.com Date: Mon, 11 Jun 2001 19:24:38 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/11/2001 07:26:22 PM, Serialize complete at 06/11/2001 07:26:22 PM Content-Type: multipart/alternative; boundary="=_alternative 0080461985256A68_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0080461985256A68_= Content-Type: text/plain; charset="us-ascii" Eric wrote: >It is the useful features that have resulted in recurrence rules being >absurdly complex. We should be focusing on the mandatory features. Are you suggesting we codify what subcomponents of a recurrence rule are MUST, SHOULD, MAY, etc? Thats a different argument that the discussion so far so I want to try and stay relevant here... >The problem we have is that if we allow BYSETPOS to operate over the >entire range of seconds in a year, it is possible for CUAs to >generate rules that CPU-bound servers will reject because they are too >complex to evaluate in a small amount of time. Thats a justification from CPL for removing BYSETPOS entirely (at least initially). But not every system that implements iCalendar is going to have an O(1) time requirement for expanding sets of recurrence instances. We (Lotus Notes) certainly do not have one. I do not recall finding one in Outlook/Exchange. Besides CPL, are there any other implemenations that have this requirement?? Since not every implemenation has such a requirement I do not think it an absolute necessity to impose said restriction on the rest. (Thats akin to the smallest footprint argument for cutting features argument again...) >I believe that we can restrict recurrence rules to only using BYSETPOS for >day-scale events, thus eliminating the complexity problem for all but the >most feeble servers. That may be fine for CPL but it may not be fine for, say, SKiCAL. I would stipulate that the base definition (ie: iCalendar) is NOT the place to put restrictions motivated by this kind of argument since they do not apply to all uses of the grammar. It is applicable to put them into non-base definitions or other derivative works though that may have such a restriction. (That is to say, the restriction is in the Cell Phone Sync program/protocol, NOT in iCalendar itself!) > I also think that any plausible rule that would use >BYSETPOS for sub-day intervals can be re-written without BYSETPOS, so the >restriction does not reduce the functionality of recurrence rules. Nothing argued so far seems to justify why losing functionality that exists now for sub-day sets is a good thing (apart from it is not something that some derivative works want to deal with). At least not that Ive been able to digest so far... >You are arguing that BYSETPOS for sub-day intervals is useful and that >there may be cases where some CUA will want to use them. It is the same argument for both sub-day and super-day recurrences that I trying to present here. BYSETPOS is used to select specific instances of the set for use. That is irregardless of the FREQ scale. > Neither >case is necessary, and both of them cause interoperability problems >related to computational complexity. This gets back to the O(1) requirement of CPL. It is NOT a requirement of iCalendar. >The proposed restrictions are a compromise between a complexity problem >that we know exists and a set of future possibilities that we suppose >exist. We can't design for a vague an unknown future; if you've got some >plausible use cases that cannot be implemented without BYSETPOS on a >sub-day scale, then we can do some analysis. Otherwise, we are just >guessing. The proposed restrictions are _NOT_ a compromise that needs to made in iCalendar; those are current restrictions of CPLs model. The addition of clarifying text about BYSETPOS is a good thing though. In providing clear text about how to evaluate any recurrence rule subcomponent and any theoretical limitations that apply to them we are doing the right thing and allowing future implementors to benefit from our open mindedness. If we take the approach of "I cant think of a use for this mix although it could be useful sometime later" then we are not providing a springboard for future extension and reuse; we are providing a plank for them to walk along and fall off. >So, can you show some rules for a plausible scenario that cannot be >implemented without BYSETPOS on a sub-day interval? Argue for it at all on super-day intervals. The same usage applys to both cases (its just that some folks do not want to deal w/sub-day cases). In case some folks haven't seen that line in 2445 (p. 44) the use for BYSETPOS is to "indicates the nth occurrence of the specific occurrence within the set of events specified by the rule". So whatever size your rule can geneate, BYSETPOS needs to be able to indicate ANY instance in that set. You cannot justify it one way w/o also justfying the other way at the same time... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0080461985256A68_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Eric wrote:<br> &gt;It is the useful features that have resulted in recurrence rules being<br> &gt;absurdly complex. We should be focusing on the mandatory features.<br> </font> <br><font size=2 face="sans-serif">Are you suggesting we codify what subcomponents of a recurrence rule are MUST, SHOULD, MAY, etc? &nbsp;Thats a different argument that the discussion so far so I want to try and stay relevant here...</font> <br><font size=2 face="Courier New"><br> &gt;The problem we have is that if we allow BYSETPOS to operate over the<br> &gt;entire range of seconds in a year, it is possible for CUAs to<br> &gt;generate rules that CPU-bound servers will reject because they are too<br> &gt;complex to evaluate in a small amount of time.<br> </font> <br><font size=2 face="sans-serif">Thats a justification from CPL for removing BYSETPOS entirely (at least initially). &nbsp;But not every system that implements iCalendar is going to have an O(1) time requirement for expanding sets of recurrence instances. &nbsp;We (Lotus Notes) certainly do not have one. &nbsp;I do not recall finding one in Outlook/Exchange. &nbsp;Besides CPL, are there any other implemenations that have this requirement?? &nbsp;</font> <br> <br><font size=2 face="sans-serif">Since not every implemenation has such a requirement I do not think it an absolute necessity to impose said restriction on the rest. &nbsp;(Thats akin to the smallest footprint argument for cutting features argument again...)</font> <br><font size=2 face="sans-serif"><br> &gt;</font><font size=2 face="Courier New">I believe that we can restrict recurrence rules to only using BYSETPOS for<br> &gt;day-scale events, thus eliminating the complexity problem for all but the<br> &gt;most feeble servers. </font> <br> <br><font size=2 face="sans-serif">That may be fine for CPL but it may not be fine for, say, SKiCAL. &nbsp;I would stipulate that the base definition (ie: iCalendar) is NOT the place to put restrictions motivated by this kind of argument since they do not apply to all uses of the grammar. &nbsp;It is applicable to put them into non-base definitions or other derivative works though that may have such a restriction. &nbsp;(That is to say, the restriction is in the Cell Phone Sync program/protocol, NOT in iCalendar itself!)</font> <br> <br><font size=2 face="Courier New">&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;I also think that any plausible rule that would use<br> &gt;BYSETPOS for sub-day intervals can be re-written without BYSETPOS, so the<br> &gt;restriction does not reduce the functionality of recurrence rules.<br> </font> <br><font size=2 face="sans-serif">Nothing argued so far seems to justify why losing functionality that exists now for sub-day sets is a good thing (apart from it is not something that some derivative works want to deal with). &nbsp;At least not that Ive been able to digest so far...</font> <br><font size=2 face="sans-serif"><br> </font><font size=2 face="Courier New">&gt;You are arguing that BYSETPOS for sub-day intervals is useful and that<br> &gt;there may be cases where some CUA will want to use them. </font> <br> <br><font size=2 face="sans-serif">It is the same argument for both sub-day and super-day recurrences that I trying to present here. &nbsp;BYSETPOS is used to select specific instances of the set for use. &nbsp;That is irregardless of the FREQ scale.</font> <br><font size=2 face="sans-serif"><br> </font><font size=2 face="Courier New">&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Neither<br> &gt;case is necessary, and both of them cause interoperability problems<br> &gt;related to computational complexity.<br> </font> <br><font size=2 face="sans-serif">This gets back to the O(1) requirement of CPL. &nbsp;It is NOT a requirement of iCalendar.</font> <br><font size=2 face="sans-serif"><br> </font><font size=2 face="Courier New">&gt;The proposed restrictions are a compromise between a complexity problem<br> &gt;that we know exists and a set of future possibilities that we suppose<br> &gt;exist. We can't design for a vague an unknown future; if you've got some<br> &gt;plausible use cases that cannot be implemented without BYSETPOS on a<br> &gt;sub-day scale, then we can do some analysis. Otherwise, we are just<br> &gt;guessing.<br> </font> <br><font size=2 face="sans-serif">The proposed restrictions are _<u>NOT</u>_ a compromise that needs to made in iCalendar; those are current restrictions of CPLs model. &nbsp;</font> <br> <br><font size=2 face="sans-serif">The addition of clarifying text about BYSETPOS is a good thing though. &nbsp;In providing clear text about how to evaluate any recurrence rule subcomponent and any theoretical limitations that apply to them we are doing the right thing and allowing future implementors to benefit from our open mindedness. &nbsp;If we take the approach of &quot;I cant think of a use for this mix although it could be useful sometime later&quot; then we are not providing a springboard for future extension and reuse; we are providing a plank for them to walk along and fall off.</font> <br><font size=2 face="Courier New"><br> &gt;So, can you show some rules for a plausible scenario that cannot be<br> &gt;implemented without BYSETPOS on a sub-day interval?</font> <br> <br><font size=2 face="sans-serif">Argue for it at all on super-day intervals. &nbsp;The same usage applys to both cases (its just that some folks do not want to deal w/sub-day cases). &nbsp;In case some folks haven't seen that line in 2445 (p. 44) the use for BYSETPOS is to &quot;</font><font size=2><tt>indicates the nth occurrence of the specific occurrence within the set of events specified by the rule</tt></font><font size=2 face="sans-serif">&quot;. &nbsp;So whatever size your rule can geneate, BYSETPOS needs to be able to indicate ANY instance in that set. &nbsp;You cannot justify it one way w/o also justfying the other way at the same time...</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 0080461985256A68_=-- From owner-ietf-calendar@mail.imc.org Mon Jun 11 20:01:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20939 for <calsch-archive@odin.ietf.org>; Mon, 11 Jun 2001 20:01:39 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5BNkuq20989 for ietf-calendar-bks; Mon, 11 Jun 2001 16:46:56 -0700 (PDT) Received: from agony.busboom.org (24-25-198-84.san.rr.com [24.25.198.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5BNktJ20985 for <ietf-calendar@imc.org>; Mon, 11 Jun 2001 16:46:55 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f5BNkm312035; Mon, 11 Jun 2001 16:46:49 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 11 Jun 2001 16:46:48 -0700 (PDT) From: Eric Busboom <eric@softwarestudio.org> X-X-Sender: <eric@agony.busboom.org> To: Graham Gilmore <grahamg@steltor.com> cc: <ietf-calendar@imc.org> Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: <036d01c0f2bd$2a081f50$092e0165@in.steltor.com> Message-ID: <Pine.LNX.4.33.0106111628260.2137-100000@agony.busboom.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> On Mon, 11 Jun 2001, Graham Gilmore wrote: > > So, can you show some rules for a plausible scenario that cannot be > > implemented without BYSETPOS on a sub-day interval? > > The obvious example would be to take Bruce's BYSETPOS poster case > and throw in a sub-day part: > > RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=12,13;BYSETPOS=-1,-2 Without BYSETPOS: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYMONTHDAY=-1;BYHOUR=12,13; eric. From owner-ietf-calendar@mail.imc.org Mon Jun 11 21:00:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21493 for <calsch-archive@odin.ietf.org>; Mon, 11 Jun 2001 21:00:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5C0i3R22602 for ietf-calendar-bks; Mon, 11 Jun 2001 17:44:03 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5C0i1J22598 for <ietf-calendar@imc.org>; Mon, 11 Jun 2001 17:44:02 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id UAA08906 for <ietf-calendar@imc.org>; Mon, 11 Jun 2001 20:44:00 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f5C0hxv10426 for <ietf-calendar@imc.org>; Mon, 11 Jun 2001 20:43:59 -0400 (EDT) Message-ID: <039c01c0f2d8$82216be0$092e0165@in.steltor.com> From: "Graham Gilmore" <grahamg@steltor.com> To: <ietf-calendar@imc.org> References: <Pine.LNX.4.33.0106111628260.2137-100000@agony.busboom.org> Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) Date: Mon, 11 Jun 2001 20:42:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Eric Busboom" <eric@softwarestudio.org> To: "Graham Gilmore" <grahamg@steltor.com> Cc: <ietf-calendar@imc.org> Sent: 11 June, 2001 19:46 Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) > On Mon, 11 Jun 2001, Graham Gilmore wrote: > > > > So, can you show some rules for a plausible scenario that cannot be > > > implemented without BYSETPOS on a sub-day interval? > > > > The obvious example would be to take Bruce's BYSETPOS poster case > > and throw in a sub-day part: > > > > > > RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=12,13;BYSETPOS=-1,-2 > > Without BYSETPOS: > > RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYMONTHDAY=-1;BYHOUR=12,13; In this case, if the last day of the month is not one of MO,TU,WE,TH,FR, that month would be skipped (since the intersection of BYMONTHDAY and BYDAY is empty for that month). Like Bruce, I tried for several minutes to come up with an alternative representation, and I couldn't. Graham From owner-ietf-calendar@mail.imc.org Tue Jun 12 13:16:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19948 for <calsch-archive@odin.ietf.org>; Tue, 12 Jun 2001 13:16:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CGlvN07354 for ietf-calendar-bks; Tue, 12 Jun 2001 09:47:57 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CGlsJ07349 for <ietf-calendar@imc.org>; Tue, 12 Jun 2001 09:47:55 -0700 (PDT) To: "Graham Gilmore" <grahamg@steltor.com> Cc: ietf-calendar@imc.org Subject: Re: BYSETPOS sets and INTERVAL MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: <OF65C40EE6.7E8103A9-ON85256A69.005B6775@iris.com> From: Bruce_Kahn@iris.com Date: Tue, 12 Jun 2001 12:49:34 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/12/2001 12:49:44 PM, Serialize complete at 06/12/2001 12:49:44 PM Content-Type: multipart/alternative; boundary="=_alternative 005C15A885256A69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 005C15A885256A69_= Content-Type: text/plain; charset="us-ascii" Graham wrote on 06/11/2001 06:25:28 PM: > If INTERVAL isn't used in calculating the set, then how would one > specify a set that was, for example, 2 months or 2 years long? I think you should read the RFC text on the use of INTERVAL a bit closer. From Section 4.3.10 Recurrence Rule, p42: The INTERVAL rule part contains a positive integer representing how often the recurrence rule repeats. To see it in use, read several of the examples. > One > might want to modify the "last working day of the month" example to be > "last working day every 2nd month". INTERVAL would seem the natural > choice for this. Correct. For the former case, it is not that useful (INTERVAL=1). For the second case it is INTERVAL=2. You are now using the INTERVAL value to properly move the starting point for where the next starting point will be (ie: Move the effective seed date/time out by 2 months instead of 1). Now are you are using it the way it should be; it is not intended to be used to say "a set is 2 months long" but rather "how far do I move the starting point of the 'set'". This is different from your 1st line at the top though... > the RRULE becomes dependent on the DTSTART (i.e. which > months are 'every second month'?), which seems wrong somehow. Initially the rule IS dependent on DTSTART but after the first set is rolled out, a new 'effective' DTSTART is used to generate the next set of values. This new 'effective' DTSTART is the 'currently effective' DTSTART value adjusted by the FREQ and INTERVAL amounts. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005C15A885256A69_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Graham &nbsp;wrote on 06/11/2001 06:25:28 PM:<br> &gt; &nbsp; &nbsp; If INTERVAL isn't used in calculating the set, then how would one<br> &gt; specify a set that was, for example, 2 months or 2 years long?</font> <br> <br><font size=2 face="sans-serif">I think you should read the RFC text on the use of INTERVAL a bit closer. &nbsp;From Section 4.3.10 Recurrence Rule, p42:</font> <br> <br><font size=2 face="sans-serif">&nbsp; &nbsp;The INTERVAL rule part contains a positive integer representing how<br> &nbsp; often the recurrence rule repeats.</font> <br> <br><font size=2 face="sans-serif">To see it in use, read several of the examples.</font> <br><font size=2 face="Courier New"><br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;One</font> <br><font size=2 face="Courier New">&gt; might want to modify the &quot;last working day of the month&quot; example to be<br> &gt; &quot;last working day every 2nd month&quot;. &nbsp;INTERVAL would seem the natural<br> &gt; choice for this. &nbsp;</font> <br> <br><font size=2 face="sans-serif">Correct. &nbsp;For the former case, it is not that useful (INTERVAL=1). &nbsp;For the second case it is INTERVAL=2. &nbsp;You are now using the INTERVAL value to properly move the starting point for where the next starting point will be (ie: Move the effective seed date/time out by 2 months instead of 1). &nbsp;Now are you are using it the way it should be; it is not intended to be used to say &quot;a set is 2 months long&quot; but rather &quot;how far do I move the starting point of the 'set'&quot;. &nbsp;This is different from your 1st line at the top though...</font> <br> <br><font size=2 face="Courier New">&gt; &nbsp; &nbsp; &nbsp; &nbsp; the RRULE becomes dependent on the DTSTART (i.e. which<br> &gt; months are 'every second month'?), which seems wrong somehow.<br> </font> <br><font size=2 face="sans-serif">Initially the rule IS dependent on DTSTART but after the first set is rolled out, a new 'effective' DTSTART is used to generate the next set of values. &nbsp;This new 'effective' DTSTART is the 'currently effective' DTSTART value adjusted by the FREQ and INTERVAL amounts.</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> <br> --=_alternative 005C15A885256A69_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 12 16:18:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23880 for <calsch-archive@odin.ietf.org>; Tue, 12 Jun 2001 16:18:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CJuRC14197 for ietf-calendar-bks; Tue, 12 Jun 2001 12:56:27 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CJuQJ14193 for <ietf-calendar@imc.org>; Tue, 12 Jun 2001 12:56:26 -0700 (PDT) To: Eric Busboom <eric@softwarestudio.org> Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: <OF047414CE.4CABDCDF-ON85256A69.006C63D9@iris.com> From: Bruce_Kahn@iris.com Date: Tue, 12 Jun 2001 15:58:10 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/12/2001 03:58:16 PM, Serialize complete at 06/12/2001 03:58:16 PM Content-Type: multipart/alternative; boundary="=_alternative 006D597185256A69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 006D597185256A69_= Content-Type: text/plain; charset="us-ascii" I think I had an ephiany last night one the drive home that makes some of what Eric and Jonathan are saying clear. Let me see if I can reexplain their rationale for trying to restrict BYSETPOS and you guys can tell me if the lights are finally on... <NUTSHELL> Since BYSETPOS is only useful for selecting particular instances in a set generated by each pass of the rule. As such, for sub-day recurrences (ie: FREQ less than DAILY really) the same effect can be achieved by simply splitting the rule into 'smaller' rules which do not include the instances that would be punched out (or conversely selected). As such, we do not need to have BYSETPOS if the FREQ is less than DAILY since we can simply subdivide the recurrence rule into smaller bounding recurrences. </NUTSHELL> I think the key factor for me was part of a response from Jonathan that said: >In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 instances >long, not 2. Since the set is variable in this case the BYSETPOS is useful (or necessary). For a case where the set is NOT variable (ie: FREQ=HOURLY;BYHOUR=9,10,11,12;BYMINUTE=0,20,40 will ALWAYS generate 12 instances) then BYSETPOS is not of any real value since we can easily 'subdivide' the recurrence rule into separate but proper subsets of the original rule. This can I live with as long as we expressly say to do this in the text for BYSETPOS where we preclude it for FREQ values DAILY or smaller. I think the key rationale (that the set for FREQ=DAILY and below is not variable in size when instanciated) was what was not clear to me in the previous threads (was it to others??). Now I can accept the rationale for restricting BYSETPOS for 'fixed size instanciations' is a viable change (even if it does cause some data size expansion). Eric/Jonathan: Does this jive w/what you had in mind all along?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006D597185256A69_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">I think I had an ephiany last night one the drive home that makes some of what Eric and Jonathan are saying clear. &nbsp;Let me see if I can reexplain their rationale for trying to restrict BYSETPOS and you guys can tell me if the lights are finally on...</font> <br> <br><font size=2 face="sans-serif">&lt;NUTSHELL&gt;</font> <br><font size=2 face="sans-serif">Since BYSETPOS is only useful for selecting particular instances in a set generated by each pass of the rule. &nbsp;As such, for sub-day recurrences (ie: FREQ less than DAILY really) the same effect can be achieved by simply splitting the rule into 'smaller' rules which do not include the instances that would be punched out (or conversely selected). &nbsp;As such, we do not need to have BYSETPOS if the FREQ is less than DAILY since we can simply subdivide the recurrence rule into smaller bounding recurrences.</font> <br><font size=2 face="sans-serif">&lt;/NUTSHELL&gt;</font> <br> <br><font size=2 face="sans-serif">I think the key factor for me was part of a response from Jonathan that said:</font> <br><font size=2 face="Courier New">&gt;In RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYSETPOS=-1, the set is 8 - 10 instances<br> &gt;long, not 2.</font> <br> <br><font size=2 face="sans-serif">Since the set is variable in this case the BYSETPOS is useful (or necessary). &nbsp;For a case where the set is NOT variable (ie: FREQ=HOURLY;BYHOUR=9,10,11,12;BYMINUTE=0,20,40 will ALWAYS generate 12 instances) then BYSETPOS is not of any real value since we can easily 'subdivide' the recurrence rule into separate but proper subsets of the original rule. &nbsp;This can I live with as long as we expressly say to do this in the text for BYSETPOS where we preclude it for FREQ values DAILY or smaller.</font> <br> <br><font size=2 face="sans-serif">I think the key rationale (that the set for FREQ=DAILY and below is not variable in size when instanciated) was what was not clear to me in the previous threads (was it to others??). &nbsp;Now I can accept the rationale for restricting BYSETPOS for 'fixed size instanciations' is a viable change (even if it does cause some data size expansion). &nbsp;</font> <br> <br><font size=2 face="sans-serif">Eric/Jonathan: Does this jive w/what you had in mind all along??</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 006D597185256A69_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 12 16:37:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24254 for <calsch-archive@odin.ietf.org>; Tue, 12 Jun 2001 16:37:05 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CKOkH15096 for ietf-calendar-bks; Tue, 12 Jun 2001 13:24:46 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CKOjJ15092 for <ietf-calendar@imc.org>; Tue, 12 Jun 2001 13:24:45 -0700 (PDT) To: Eric Busboom <eric@softwarestudio.org> Cc: ietf-calendar@imc.org, Jonathan Lennox <lennox@cs.columbia.edu> Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions Clarification!) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: <OFDA566513.C35862BF-ON85256A69.006F3AE9@iris.com> From: Bruce_Kahn@iris.com Date: Tue, 12 Jun 2001 16:26:29 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/12/2001 04:26:35 PM, Serialize complete at 06/12/2001 04:26:35 PM Content-Type: multipart/alternative; boundary="=_alternative 006FF10985256A69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 006FF10985256A69_= Content-Type: text/plain; charset="us-ascii" I would like to take a second to clarify my current view of the changes for BYSETPOS before what I just sent is taken as a blanket acceptance of the proposed changes. I just said: >This can I live with as long as we expressly say to do this in the text for BYSETPOS >where we preclude it for FREQ values DAILY or smaller. This relates to the proposed change of Erics: > BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY > rules. As long as what I just sent jives w/the intent of Eric and Jonathan I can live w/this line (for the previously stated reasons and providing we add prose saying why its prohibited and what the alternative to BYSETPOS is for these FREQ cases (exploding into sub-rules). I still do not agree w/the other bit from the proposed change: > If any of BYSECOND, BYMINUTE or BYHOUR rule parts appear in a > rule, BYSETPOS MUST NOT appear. Since it is still possible to generate a variable sized set of instances when they are present (to paraphrase Jonathans example): RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYHOUR=9,12;BYSETPOS=-1,-4 which will generate between 16 and 20 instances. The key to wheter or not BYSETPOS is actually allowed should be whether or not the instance set is variable in size; not whether or not a time BYxxx subcomponent is present. Why not allow BYSETPOS if the time related BYxxx subcomponents? Doesnt it make sense to allow BYSETPOS no matter which BYxxx subcomponents are there (as long as at least 1 non-time related one is)? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006FF10985256A69_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">I would like to take a second to clarify my current view of the changes for BYSETPOS before what I just sent is taken as a blanket acceptance of the proposed changes.</font> <br> <br><font size=2 face="sans-serif">I just said:</font> <br><font size=2 face="sans-serif">&gt;This can I live with as long as we expressly say to do this in the text for BYSETPOS </font> <br><font size=2 face="sans-serif">&gt;where we preclude it for FREQ values DAILY or smaller.</font><font size=3> </font> <br> <br><font size=2 face="sans-serif">This relates to the proposed change of Erics:</font> <br> <br><font size=2 face="sans-serif">&gt;</font><font size=2 face="Courier New"> &nbsp;BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY<br> &gt; &nbsp;rules.</font> <br> <br><font size=2 face="sans-serif">As long as what I just sent jives w/the intent of Eric and Jonathan I can live w/this line (for the previously stated reasons and providing we add prose saying why its prohibited and what the alternative to BYSETPOS is for these FREQ cases (exploding into sub-rules).</font> <br> <br><font size=2 face="sans-serif">I still do not agree w/the other bit from the proposed change:</font> <br> <br><font size=2 face="Courier New">&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;If any of &nbsp;BYSECOND, BYMINUTE or BYHOUR rule parts appear in a<br> &gt; &nbsp;rule, BYSETPOS MUST NOT appear.</font> <br> <br><font size=2 face="sans-serif">Since it is still possible to generate a variable sized set of instances when they are present (to paraphrase Jonathans example):</font> <br> <br><font size=2 face="Courier New">RECUR:FREQ=MONTHLY;BYDAY=TU,TH;BYHOUR=9,12;BYSETPOS=-1,-4</font> <br> <br><font size=2 face="sans-serif">which will generate between 16 and 20 instances. &nbsp;The key to wheter or not BYSETPOS is actually allowed should be whether or not the instance set is variable in size; not whether or not a time BYxxx subcomponent is present.</font> <br> <br><font size=2 face="sans-serif">Why not allow BYSETPOS if the time related BYxxx subcomponents? &nbsp;Doesnt it make sense to allow BYSETPOS no matter which BYxxx subcomponents are there (as long as at least 1 non-time related one is)?</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 006FF10985256A69_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 12 17:22:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24872 for <calsch-archive@odin.ietf.org>; Tue, 12 Jun 2001 17:22:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CL4S516359 for ietf-calendar-bks; Tue, 12 Jun 2001 14:04:28 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CL4QJ16355 for <ietf-calendar@imc.org>; Tue, 12 Jun 2001 14:04:27 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06042001 June 04, 2001 Message-ID: <OF574E5C31.2E3E950B-ON85256A69.00718035@iris.com> From: Bruce_Kahn@iris.com Date: Tue, 12 Jun 2001 17:06:09 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/12/2001 05:06:17 PM, Serialize complete at 06/12/2001 05:06:17 PM Content-Type: multipart/alternative; boundary="=_alternative 007392C585256A69_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 007392C585256A69_= Content-Type: text/plain; charset="us-ascii" Jonathan Lennox <lennox@cs.columbia.edu> wrote on 06/11/2001 06:31:14 PM: > > The FREQ is yearly so that alone would make the entry repeat on a basis of > > 1 year. You do not factor in the INTERVAL value when trying to calculate > > the set; it is used when moving the starting point for the next 'rollout'. > > As such, the only modifier you have to worry about is the BYSECOND. > > > > So since your DTSTART date/time value is only being 'expanded' using > > BYSECOND, the only part of it that will be changed (and added to the > > 'set') is the seconds value of the time. For example, had you provided a > > DTSTART;TZID=US-Eastern:20010611T090000 then the 'set' would evaluate out > > to: > > > > 11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST > > Ah! This is the thing I missed. Again, a serious omission in the RFC 2445 > examples. May I suggest that when we rev the RFC we make an effort to include some examples like this for the future benefit of others?? I think thats something that Eric would have to take on (but at least he can copy my example for starters). Id be willing to help out on some other examples (in a few weeks) too. > The question is, what do you do for fields *larger* than your smallest > BY* parameter, but smaller than FREQ? > > This is only relevant if there's a "gap" in the information. > > For instance: > DTSTART;TZID=US-Eastern:19970902T090000 > RRULE:FREQ=YEARLY;BYMONTHDAY=1 > > I had interpreted this as meaning > ==> (1997 9:00 AM EDT) September 2, October 1 > (1997 9:00 AM EST) November 1, December 1 > (1998 9:00 AM EST) January 1, February 1, March 1 > ... > > (I.e. treat the "gap" information as "wild" -- as if we had > BYMONTH=1,2,3,4,5,6,7,8,9,10,11,12.) > > Instead, you're saying it's > ==> (1997 9:00 AM EDT) September 2 > (1998 9:00 AM EDT) September 1 > (1999 9:00 AM EDT) September 1 > ... Correct (it is akin to the "Every Friday the 13th, forever:" example). > (I.e. treat it the same as if we had BYMONTH=9.) Hmm, I had not viewed it that way so I don't know if that is accurate to do that. I simply used the FREQ/INTERVAL values to pick my next effective DTSTART and then applied the BYxxx subcomponent in the prescribed order. > Note that the only RFC 2445 examples that address anything like this > question are the ones of the form > DTSTART;TZID=US-Eastern:19970902T090000 > RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU > ==> (1997 9:00 AM EDT)September 2,9,16,23,30 > (1997 9:00 AM EST)November 4,11,18,25 > (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 > > In this example, we must treat the week of the month as "wild" -- > i.e. BYDAY=TU is equivalent to BYDAY=1TU,2TU,3TU,4TU,5TU in a MONTHLY rule. > (And to BYDAY=1TU,2TU,...,53TU in a YEARLY rule.) Not sure Id say that I wildcarded anything again. It is simply a matter of generating the proper 'filter' for expanding/contracting the set (in the prescribed order). Since 2445 says that BYDAY=MO is equivalent to BYDAY=1MO,2MO,3MO,4MO,5MO (or the corresponding negatives for that matter) I can do an expansion internally in my grammar evaluator (which you consider making the weeks in the month "wild" but I just do not factor them in since that is the purpose of BYWEEKNO really). I then seed my engine w/the DTSTART value and have it find "all Tuesdays in the month". When it is done I move the DTSTART value (internally) by the prescribed FREQ/INTERVAL and begin again. I find that it is possible to make the 'filter' up front since it never changes, just the seed that gets DTSTART that gets fed in changes. > Is BYDAY "special" when it comes to filling in gaps, and in all other cases > the gap should be filled in from the DTSTART? Or are gaps different than > times smaller than the smallest time unit mentioned in a BY*/FREQ? BYDAY is special in that it can be 'shorthanded' for FREQ=MONTHLY or YEARLY. It also allowed us to reuse the subcomponent w/o having to define different allowable values based on the FREQ (than say the expected '1 off' of a FREQ=WEEKLY). For a better explaination Id defer to Frank since he massaged all our original thoughts/comments into the prose that you have confounding you now... > A very close reading of the RECUR definition seems to show that your > interpretation -- the "BYDAY is special, gaps aren't" reading -- is > *probably* right, and I guess it allows slightly more generality. However, > it certainly wasn't clear, or illustrated. I think that in our push to get iCalendar out we (the WG at the time) did not necessarily focus very strongly on the recurrence grammar (or the delegation related stuff) and it shows up now as we all try to implement it in a consistant manner. The recurrence grammar addtions/changes were the last ones in and after such a long labor I think we just wanted it out and were not concerned about "a few warts". Then again thats just my retrospective opinion... I certainly hope we take the time now to correct our oversights/missteps and I think Eric has done a good job doing this so far. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007392C585256A69_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Jonathan Lennox &lt;lennox@cs.columbia.edu&gt; wrote on 06/11/2001 06:31:14 PM:<br> &gt; &gt; The FREQ is yearly so that alone would make the entry repeat on a basis of <br> &gt; &gt; 1 year. &nbsp;You do not factor in the INTERVAL value when trying to calculate <br> &gt; &gt; the set; it is used when moving the starting point for the next 'rollout'. <br> &gt; &gt; As such, the only modifier you have to worry about is the BYSECOND. <br> &gt; &gt;<br> &gt; &gt; So since your DTSTART date/time value is only being 'expanded' using <br> &gt; &gt; BYSECOND, the only part of it that will be changed (and added to the <br> &gt; &gt; 'set') is the seconds value of the time. &nbsp;For example, had you provided a <br> &gt; &gt; DTSTART;TZID=US-Eastern:20010611T090000 then the 'set' would evaluate out <br> &gt; &gt; to:<br> &gt; &gt; <br> &gt; &gt; 11-Jun-2001 09:00:[00, 01, 02, 03, 04,..., 58, 59] EST<br> &gt; <br> &gt; Ah! &nbsp;This is the thing I missed. &nbsp;Again, a serious omission in the RFC 2445<br> &gt; examples.<br> </font> <br><font size=2 face="sans-serif">May I suggest that when we rev the RFC we make an effort to include some examples like this for the future benefit of others?? &nbsp;I think thats something that Eric would have to take on (but at least he can copy my example for starters). &nbsp;Id be willing to help out on some other examples (in a few weeks) too.</font> <br> <br><font size=2 face="Courier New">&gt; The question is, what do you do for fields *larger* than your smallest<br> &gt; BY* parameter, but smaller than FREQ?<br> &gt; <br> &gt; This is only relevant if there's a &quot;gap&quot; in the information.<br> &gt; <br> &gt; For instance:<br> &gt; &nbsp; &nbsp; DTSTART;TZID=US-Eastern:19970902T090000<br> &gt; &nbsp; &nbsp; RRULE:FREQ=YEARLY;BYMONTHDAY=1<br> &gt; <br> &gt; I had interpreted this as meaning<br> &gt; &nbsp; &nbsp; ==&gt; (1997 9:00 AM EDT) September 2, October 1<br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; (1997 9:00 AM EST) November 1, December 1<br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; (1998 9:00 AM EST) January 1, February 1, March 1<br> &gt; &nbsp; ...<br> &gt; <br> &gt; (I.e. treat the &quot;gap&quot; information as &quot;wild&quot; -- as if we had<br> &gt; BYMONTH=1,2,3,4,5,6,7,8,9,10,11,12.)<br> &gt; <br> &gt; Instead, you're saying it's<br> &gt; &nbsp; &nbsp; ==&gt; (1997 9:00 AM EDT) September 2<br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; (1998 9:00 AM EDT) September 1<br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; (1999 9:00 AM EDT) September 1<br> &gt; &nbsp; ...<br> </font> <br><font size=2 face="sans-serif">Correct (it is akin to the &quot;Every Friday the 13th, forever:&quot; example).</font> <br> <br><font size=2 face="Courier New">&gt; (I.e. treat it the same as if we had BYMONTH=9.)<br> </font> <br><font size=2 face="sans-serif">Hmm, I had not viewed it that way so I don't know if that is accurate to do that. &nbsp;I simply used the FREQ/INTERVAL values to pick my next effective DTSTART and then applied the BYxxx subcomponent in the prescribed order.</font> <br> <br><font size=2 face="Courier New">&gt; Note that the only RFC 2445 examples that address anything like this<br> &gt; question are the ones of the form<br> &gt; &nbsp; &nbsp; &nbsp;DTSTART;TZID=US-Eastern:19970902T090000<br> &gt; &nbsp; &nbsp; &nbsp;RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU<br> &gt; &nbsp; &nbsp; &nbsp;==&gt; (1997 9:00 AM EDT)September 2,9,16,23,30<br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(1997 9:00 AM EST)November 4,11,18,25<br> &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;(1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31<br> &gt; <br> &gt; In this example, we must treat the week of the month as &quot;wild&quot; --<br> &gt; i.e. BYDAY=TU is equivalent to BYDAY=1TU,2TU,3TU,4TU,5TU in a MONTHLY rule.<br> &gt; (And to BYDAY=1TU,2TU,...,53TU in a YEARLY rule.)<br> </font> <br><font size=2 face="sans-serif">Not sure Id say that I wildcarded anything again. &nbsp;It is simply a matter of generating the proper 'filter' for expanding/contracting the set (in the prescribed order). &nbsp;Since 2445 says that BYDAY=MO is equivalent to BYDAY=1MO,2MO,3MO,4MO,5MO (or the corresponding negatives for that matter) I can do an expansion internally in my grammar evaluator (which you consider making the weeks in the month &quot;wild&quot; but I just do not factor them in since that is the purpose of BYWEEKNO really).</font> <br> <br><font size=2 face="sans-serif">I then seed my engine w/the DTSTART value and have it find &quot;all Tuesdays in the month&quot;. &nbsp;When it is done I move the DTSTART value (internally) by the prescribed FREQ/INTERVAL and begin again. &nbsp;I find that it is possible to make the 'filter' up front since it never changes, just the seed that gets DTSTART that gets fed in changes.</font> <br> <br><font size=2 face="Courier New">&gt; Is BYDAY &quot;special&quot; when it comes to filling in gaps, and in all other cases<br> &gt; the gap should be filled in from the DTSTART? &nbsp;Or are gaps different than<br> &gt; times smaller than the smallest time unit mentioned in a BY*/FREQ?<br> </font> <br><font size=2 face="sans-serif">BYDAY is special in that it can be 'shorthanded' for FREQ=MONTHLY or YEARLY. &nbsp;It also allowed us to reuse the subcomponent w/o having to define different allowable values based on the FREQ (than say the expected '1 off' of a FREQ=WEEKLY). &nbsp;For a better explaination Id defer to Frank since he massaged all our original thoughts/comments into the prose that you have confounding you now...</font> <br> <br><font size=2 face="Courier New">&gt; A very close reading of the RECUR definition seems to show that your<br> &gt; interpretation -- the &quot;BYDAY is special, gaps aren't&quot; reading -- is<br> &gt; *probably* right, and I guess it allows slightly more generality. &nbsp;However,<br> &gt; it certainly wasn't clear, or illustrated.<br> </font> <br><font size=2 face="sans-serif">I think that in our push to get iCalendar out we (the WG at the time) did not necessarily focus very strongly on the recurrence grammar (or the delegation related stuff) and it shows up now as we all try to implement it in a consistant manner. &nbsp;The recurrence grammar addtions/changes were the last ones in and after such a long labor I think we just wanted it out and were not concerned about &quot;a few warts&quot;. &nbsp;Then again thats just my retrospective opinion... &nbsp;I certainly hope we take the time now to correct our oversights/missteps and I think Eric has done a good job doing this so far.</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> <br> --=_alternative 007392C585256A69_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 12 21:55:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28819 for <calsch-archive@odin.ietf.org>; Tue, 12 Jun 2001 21:55:09 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5D1cbH22372 for ietf-calendar-bks; Tue, 12 Jun 2001 18:38:37 -0700 (PDT) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5D1cJJ22354 for <ietf-calendar@imc.org>; Tue, 12 Jun 2001 18:38:19 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: Alan Davies <aland@steltor.com>, Bruce_Kahn@iris.com, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Can we fix BYSETPOS? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF22A85820.39E55A1C-ON85256A6A.0008A904@egenconsulting.com> From: pregen@egenconsulting.com Date: Tue, 12 Jun 2001 21:37:27 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 06/12/2001 09:37:37 PM, Serialize complete at 06/12/2001 09:37:37 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 000954C585256A6A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 000954C585256A6A_= Content-Type: text/plain; charset="us-ascii" Jonathan, I do not believe we are hearing a "concensus" on your statement "Every iCalendar CS or CUA implementation is allowed to pick its own definition, aribitrarily, of what event descriptions are too complex for it to handle, and refuse to handle such event descriptions. Such implementations are still fully compliant implementations of RFC 2445 and its successors." I think we are hearing a few voices saying it's possible that maybe is this is right. However, there are over 300 people who "lurk" on this list - I believe I need to hear a few more than 5-6 to say it's a concensus. List, let's hear from some other listeners - do you agree with what Jonathan says above. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Jonathan Lennox <lennox@cs.columbia.edu> Sent by: owner-ietf-calendar@mail.imc.org 06/11/01 07:10 PM To: Bruce_Kahn@iris.com cc: Alan Davies <aland@steltor.com>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? On Monday, June 11 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Alan Davies, ietf-calendar@imc.org" saying: > Jonathan responded with: > >As we've discussed before on these lists, we have two choices when it > >comes to dealing with absurd statuses: > > > >1. Let each implementation decide what it isn't going to handle. > >2. Let the standard limit what implementations have to support. > > > >The problem with choice 1 is that it effectively abandons > >interoperability. > > Well unless you expect _every_ implementation to implement every > feature/option the exact same way then this is not really a problem. We > would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP > (or... ) since every implementation implements only a fixed set of > features and we would never have a migration case since the set never > grows w/o _every_ implemenation concurrently rolling it out... iCalendar COS isn't like IMAP4 or SMTP. iCalendar COS is like RFC822 or HTML. It's a data format. iTIP is like IMAP4 or SMTP. It's a transaction protocol. When RFC822 was extended with MIME you got "If you can see this, your mail reader doesn't understand MIME" blocks, and large unreadable blobs of base64-encoded text. When HTML was extended with frames, you got <noframes> sections that were supposed to contain equivalent content, but actually contained "Netscape Now!" buttons. Or, in other words, extensibility in data formats is almost always painful. Now, mind you, sometimes you need to have your data formats be extensible. However, when you do this, experience seems to have shown that the right thing to do is to have the thing say, up front, "I'm an extended-X. I may look like an original-X, but I'm not, so if you don't know what an extended-X is, give up now." This also means that you need a clear distinction between "original-X" and "extended-X." Having them shade vaguely into each other is a bad idea. > Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg > today for no reason so Im a bit punchy. But the logic that "If my engine > does not like Feature X of a protocol for some reason so it wont be able > to interop with others that do" is simply a myth if the protocol plans > ahead and provides ways for conveying this back (hence some of the > REQUEST-STATUS values in iTIP). If there's a protocol which is specific to your application, yes. Are you saying I shouldn't be able to e-mail you an iCalendar object, or to put it on my web page? > Before we accept that most CUAs are going to actually generate and use > some of these "absurd" entries I'd contest the fact that they would to > begin with. The existing C&S CUAs from CalConnect do a decent job of not > actually generating some of the overly complex, nasty or "absurd" entries > so is it realistic to think that the current or immediately pending crop > of CUAs are going to generate them? Probably not. Even if someone redid > an OpenSource C&S app to generate them; its not likely to be the SOP we > will find in day to day usage. Oh, absolutely. I reached this point of view by worring about entries generated by actively hostile adversaries, who want to launch a denial-of-service attack on my server by feeding me input that makes me fall over. If you're not worried about this case, things are not nearly so much of a problem. (Though I would say that current experience in the Internet seems to indicate that you *do* have to worry about this.) > For the CPL case the CUA / CS has some restrictions on what it will be > able to accept (ie: no sub-day recurrences) but is that an "absurd" case > like "repeating every second of every day of the year" or a more realistic > case like "The walking tour of Boston begins at 9:00AM and again at 1:00PM > EST". The CPL worlds requirements are such that it cannot accept > (currently) some kinds of real world examples (not absurdities) and that > is fine; its part of their model of things. In the future there will be > other models that do not have those restrictions (ie: SKiCAL). My original model of CPL was to define a number of restrictions on what a CPL script had to accept. This was where the IESG got all up in arms -- "you're breaking interoperability with iCalendar!" Okay, I figured, interoperability with iCalendar on (moderately) complex or pathological cases is important, so we need a good definition of what's allowed and what's too complex or pathological. But now I'm hearing that CalSch *doesn't* want to define this, that each implementation is allowed to pick its own definition of complex and pathological events. So I find myself in the situation that I'm told I have to be fully interoperable with a number of implementations which aren't fully interoperable with each other. This is ... challenging. Is this group willing to say, definitively: Every iCalendar CS or CUA implementation is allowed to pick its own definition, aribitrarily, of what event descriptions are too complex for it to handle, and refuse to handle such event descriptions. Such implementations are still fully compliant implementations of RFC 2445 and its successors. If so, I'll just resurrect the last CPL draft with some minor editorial changes, tell the IESG about the CalSch working group consensus, and be on my way to Proposed Standard. However, I suspect the IESG would have *serious* concerns with this statement. (And I don't think the group would be willing to say it, anyway.) As I mentioned in my earlier mail, I think the following statement would be much more generally acceptable: Every compliant iCalendar CS or CUA must be able to correctly understand a certain basic subset of event descriptions, defined by the specification. They may also understand more general event descriptions. Compliant iCalendar CS or CUAs should not generate event descriptions beyond the basic subset unless they know that all receivers of the event can understand them correctly. Profiles of iCalendar can declare that a larger subset of iCalendar is required for that profile. > Again this last bit assums that some to-be-written CUA will actually > generate internally (and use??) an absurd case and I challenge that > assumption. Sure, it is possible to build a CUA that is purposely nasty > but is that a realistic norm or a "what about" kind of exception to the > rule?? Some of both. If I'm writing a powerful CUA, I want to know what sorts of things I should *avoid* generating to prevent a CS from choking. (For instance, I know of calendaring applications that refuse to deal with events with more than 500 or so repetitions. I don't think these applications currently make any claim to iCalendar support -- they're just vCalendar, or something proprietary, I think -- but it's the sort of thing you have to worry about.) -- Jonathan Lennox lennox@cs.columbia.edu --=_alternative 000954C585256A6A_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">Jonathan, I do not believe we are hearing a &quot;concensus&quot; on your statement </font> <br> <br><font size=2 face="sans-serif">&quot;</font><font size=2><tt>Every iCalendar CS or CUA implementation is allowed to pick its own<br> &nbsp; definition, aribitrarily, of what event descriptions are too complex for<br> &nbsp; it to handle, and refuse to handle such event descriptions. &nbsp;Such<br> &nbsp; implementations are still fully compliant implementations of RFC 2445 and<br> &nbsp; its successors.&quot;</tt></font> <br> <br><font size=2 face="sans-serif">I think we are hearing a few voices saying it's possible that maybe is this is right. However, there are over 300 people who &quot;lurk&quot; on this list - I believe I need to hear a few more than 5-6 to say it's a concensus.</font> <br> <br><font size=2 face="sans-serif">List, let's hear from some other listeners - do you agree with what Jonathan says above.<br> ___________________<br> Patricia Egen Consulting<br> www.egenconsulting.com<br> 423-875-2652</font> <br> <br> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>Jonathan Lennox &lt;lennox@cs.columbia.edu&gt;</b></font> <br><font size=1 face="sans-serif">Sent by: owner-ietf-calendar@mail.imc.org</font> <p><font size=1 face="sans-serif">06/11/01 07:10 PM</font> <br> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Bruce_Kahn@iris.com</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;Alan Davies &lt;aland@steltor.com&gt;, ietf-calendar@imc.org</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Can we fix BYSETPOS?</font></table> <br> <br> <br><font size=2><tt><br> On Monday, June 11 2001, &quot;Bruce_Kahn@iris.com&quot; wrote to &quot;Jonathan Lennox, Alan Davies, ietf-calendar@imc.org&quot; saying:<br> <br> &gt; Jonathan responded with:<br> &gt; &gt;As we've discussed before on these lists, we have two choices when it <br> &gt; &gt;comes to dealing with absurd statuses:<br> &gt; &gt;<br> &gt; &gt;1. Let each implementation decide what it isn't going to handle.<br> &gt; &gt;2. Let the standard limit what implementations have to support.<br> &gt; &gt;<br> &gt; &gt;The problem with choice 1 is that it effectively abandons <br> &gt; &gt;interoperability.<br> &gt; <br> &gt; Well unless you expect _every_ implementation to implement every<br> &gt; feature/option the exact same way then this is not really a problem. &nbsp;We<br> &gt; would then have no need for the COMPATIBILITY in IMAP4 or the EHLO in SMTP<br> &gt; (or... ) since every implementation implements only a fixed set of<br> &gt; features and we would never have a migration case since the set never<br> &gt; grows w/o _every_ implemenation concurrently rolling it out...<br> <br> iCalendar COS isn't like IMAP4 or SMTP. &nbsp;iCalendar COS is like RFC822 or<br> HTML. &nbsp;It's a data format.<br> <br> iTIP is like IMAP4 or SMTP. &nbsp;It's a transaction protocol.<br> <br> When RFC822 was extended with MIME you got &quot;If you can see this, your mail<br> reader doesn't understand MIME&quot; blocks, and large unreadable blobs of<br> base64-encoded text. &nbsp;When HTML was extended with frames, you got &lt;noframes&gt;<br> sections that were supposed to contain equivalent content, but actually<br> contained &quot;Netscape Now!&quot; buttons.<br> <br> Or, in other words, extensibility in data formats is almost always painful.<br> <br> Now, mind you, sometimes you need to have your data formats be extensible.<br> However, when you do this, experience seems to have shown that the right<br> thing to do is to have the thing say, up front, &quot;I'm an extended-X. &nbsp;I may<br> look like an original-X, but I'm not, so if you don't know what an<br> extended-X is, give up now.&quot;<br> <br> This also means that you need a clear distinction between &quot;original-X&quot; and<br> &quot;extended-X.&quot; &nbsp;Having them shade vaguely into each other is a bad idea.<br> <br> &gt; Ok, the sarcasm was a bit heavy there but I got stuck in a 2.5 hour mtg <br> &gt; today for no reason so Im a bit punchy. &nbsp;But the logic that &quot;If my engine <br> &gt; does not like Feature X of a protocol for some reason so it wont be able <br> &gt; to interop with others that do&quot; is simply a myth if the protocol plans <br> &gt; ahead and provides ways for conveying this back (hence some of the <br> &gt; REQUEST-STATUS values in iTIP).<br> <br> If there's a protocol which is specific to your application, yes.<br> <br> Are you saying I shouldn't be able to e-mail you an iCalendar object, or to<br> put it on my web page?<br> <br> &gt; Before we accept that most CUAs are going to actually generate and use <br> &gt; some of these &quot;absurd&quot; entries I'd contest the fact that they would to <br> &gt; begin with. &nbsp;The existing C&amp;S CUAs from CalConnect do a decent job of not <br> &gt; actually generating some of the overly complex, nasty or &quot;absurd&quot; entries <br> &gt; so is it realistic to think that the current or immediately pending crop <br> &gt; of CUAs are going to generate them? &nbsp;Probably not. &nbsp;Even if someone redid <br> &gt; an OpenSource C&amp;S app to generate them; its not likely to be the SOP we <br> &gt; will find in day to day usage.<br> <br> Oh, absolutely. &nbsp;I reached this point of view by worring about entries<br> generated by actively hostile adversaries, who want to launch a<br> denial-of-service attack on my server by feeding me input that makes me fall<br> over. &nbsp;If you're not worried about this case, things are not nearly so much<br> of a problem. &nbsp;(Though I would say that current experience in the Internet<br> seems to indicate that you *do* have to worry about this.)<br> <br> &gt; For the CPL case the CUA / CS has some restrictions on what it will be <br> &gt; able to accept (ie: no sub-day recurrences) but is that an &quot;absurd&quot; case <br> &gt; like &quot;repeating every second of every day of the year&quot; or a more realistic <br> &gt; case like &quot;The walking tour of Boston begins at 9:00AM and again at 1:00PM <br> &gt; EST&quot;. &nbsp;The CPL worlds requirements are such that it cannot accept <br> &gt; (currently) some kinds of real world examples (not absurdities) and that <br> &gt; is fine; its part of their model of things. &nbsp;In the future there will be <br> &gt; other models that do not have those restrictions (ie: SKiCAL). <br> <br> My original model of CPL was to define a number of restrictions on what a<br> CPL script had to accept. &nbsp;This was where the IESG got all up in arms --<br> &quot;you're breaking interoperability with iCalendar!&quot; &nbsp;Okay, I figured,<br> interoperability with iCalendar on (moderately) complex or pathological<br> cases is important, so we need a good definition of what's allowed and<br> what's too complex or pathological. &nbsp;But now I'm hearing that CalSch<br> *doesn't* want to define this, that each implementation is allowed to pick<br> its own definition of complex and pathological events.<br> <br> So I find myself in the situation that I'm told I have to be fully<br> interoperable with a number of implementations which aren't fully<br> interoperable with each other. &nbsp;This is ... challenging.<br> <br> <br> Is this group willing to say, definitively:<br> <br> &nbsp; Every iCalendar CS or CUA implementation is allowed to pick its own<br> &nbsp; definition, aribitrarily, of what event descriptions are too complex for<br> &nbsp; it to handle, and refuse to handle such event descriptions. &nbsp;Such<br> &nbsp; implementations are still fully compliant implementations of RFC 2445 and<br> &nbsp; its successors.<br> <br> If so, I'll just resurrect the last CPL draft with some minor editorial<br> changes, tell the IESG about the CalSch working group consensus, and be on<br> my way to Proposed Standard. &nbsp;However, I suspect the IESG would have<br> *serious* concerns with this statement. &nbsp;(And I don't think the group would<br> be willing to say it, anyway.)<br> <br> As I mentioned in my earlier mail, I think the following statement would be<br> much more generally acceptable:<br> <br> &nbsp; Every compliant iCalendar CS or CUA must be able to correctly understand<br> &nbsp; a certain basic subset of event descriptions, defined by the<br> &nbsp; specification. &nbsp;They may also understand more general event<br> &nbsp; descriptions.<br> &nbsp; Compliant iCalendar CS or CUAs should not generate event descriptions<br> &nbsp; beyond the basic subset unless they know that all receivers of the event<br> &nbsp; can understand them correctly.<br> &nbsp; Profiles of iCalendar can declare that a larger subset of iCalendar is<br> &nbsp; required for that profile.<br> <br> &gt; Again this last bit assums that some to-be-written CUA will actually <br> &gt; generate internally (and use??) an absurd case and I challenge that <br> &gt; assumption. &nbsp;Sure, it is possible to build a CUA that is purposely nasty <br> &gt; but is that a realistic norm or a &quot;what about&quot; kind of exception to the <br> &gt; rule??<br> <br> Some of both. &nbsp;If I'm writing a powerful CUA, I want to know what sorts of<br> things I should *avoid* generating to prevent a CS from choking. &nbsp;(For</tt></font> <br><font size=2><tt>instance, I know of calendaring applications that refuse to deal with events<br> with more than 500 or so repetitions. &nbsp;I don't think these applications<br> currently make any claim to iCalendar support -- they're just vCalendar, or<br> something proprietary, I think -- but it's the sort of thing you have to<br> worry about.) <br> <br> -- <br> Jonathan Lennox<br> lennox@cs.columbia.edu<br> </tt></font> <br> <br> --=_alternative 000954C585256A6A_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 13 09:51:19 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23147 for <calsch-archive@odin.ietf.org>; Wed, 13 Jun 2001 09:51:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DDTqD18520 for ietf-calendar-bks; Wed, 13 Jun 2001 06:29:52 -0700 (PDT) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DDTmJ18516 for <ietf-calendar@imc.org>; Wed, 13 Jun 2001 06:29:48 -0700 (PDT) To: ietf-calendar@imc.org Subject: Internet-Draft Cutoff Dates for London (England) IETF X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OF7895976C.1FF9EE98-ON85256A6A.0049FF08@egenconsulting.com> From: pregen@egenconsulting.com Date: Wed, 13 Jun 2001 09:29:00 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 06/13/2001 09:29:03 AM, Serialize complete at 06/13/2001 09:29:03 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004A7B8F85256A6A_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 004A7B8F85256A6A_= Content-Type: text/plain; charset="us-ascii" FYI - the dates below are for those of you submitting drafts to be discussed in London ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 ----- Forwarded by Pat R Egen/Egen Consulting/01 on 06/13/01 09:32 AM ----- Natalie Syracuse <nsyracus@cnri.reston.va.us> 06/13/01 08:32 AM To: IETF-Announce: ; cc: Subject: Internet-Draft Cutoff Dates for London (England) IETF NOTE: There are two (2) Internet-Draft Cutoff dates July 13: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Friday, July 13, 17:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, July 16. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of July 13 will NOT be accepted. July 20: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Friday, July 20, 2001 at 17:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_51.html --=_alternative 004A7B8F85256A6A_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">FYI - the dates below are for those of you submitting drafts to be discussed in London<br> ___________________<br> Patricia Egen Consulting<br> www.egenconsulting.com<br> 423-875-2652</font> <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Pat R Egen/Egen Consulting/01 on 06/13/01 09:32 AM -----</font> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>Natalie Syracuse &lt;nsyracus@cnri.reston.va.us&gt;</b></font> <p><font size=1 face="sans-serif">06/13/01 08:32 AM</font> <br> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;IETF-Announce: ;</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Internet-Draft Cutoff Dates for London (England) IETF</font></table> <br> <br> <br><font size=2><tt><br> NOTE: There are two (2) Internet-Draft Cutoff dates<br> <br> July 13: Cutoff for Initial Submissions (new documents)<br> <br> All initial submissions(-00) must be submitted by Friday,<br> July 13, 17:00 US-EST. Initial submissions received after this time<br> will NOT be made available in the Internet-Drafts directory, and will have<br> to be resubmitted.<br> <br> As before, all initial submissions (-00.txt) with a filename beginning<br> with a draft-ietf MUST be approved by the appropriate WG Chair prior to<br> processing and announcing. WG Chair approval must be received by<br> Monday, July 16.<br> <br> Please do NOT wait until the last minute to submit.<br> <br> Be advised: NO placeholders. Updates to initial submissions received<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the week of July 13 will NOT be accepted.<br> <br> July 20: FINAL Internet-Draft Cutoff<br> <br> All revised Internet-Draft submissions must be submitted by Friday,<br> July 20, 2001 at 17:00 US-EST. Internet-Drafts received after this time<br> will NOT be announced NOR made available in the Internet-Drafts<br> Directories.<br> <br> We will begin accepting Internet-Draft submissions the week of the<br> meeting, though announcements will NOT be sent until the IETF meeting<br> is over.<br> <br> Thank you for your understanding and cooperation. Please do not hesitate<br> to contact us if you have any questions or concenrs.<br> <br> FYI: These and other significant dates can be found at<br> &nbsp; &nbsp; &nbsp;http://www.ietf.org/meetings/cutoff_dates_51.html<br> <br> </tt></font> <br> --=_alternative 004A7B8F85256A6A_=-- From owner-ietf-calendar@mail.imc.org Fri Jun 15 11:39:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12159 for <calsch-archive@odin.ietf.org>; Fri, 15 Jun 2001 11:39:53 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5FFDs023069 for ietf-calendar-bks; Fri, 15 Jun 2001 08:13:54 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5FFDqJ23063 for <ietf-calendar@imc.org>; Fri, 15 Jun 2001 08:13:52 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id LAA04929 for <ietf-calendar@imc.org>; Fri, 15 Jun 2001 11:13:48 -0400 Received: from pc152 ([101.1.46.9]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f5FFDlv10474 for <ietf-calendar@imc.org>; Fri, 15 Jun 2001 11:13:48 -0400 (EDT) Message-ID: <05a201c0f5ad$802c5430$092e0165@in.steltor.com> From: "Graham Gilmore" <grahamg@steltor.com> To: <ietf-calendar@imc.org> References: <OF22A85820.39E55A1C-ON85256A6A.0008A904@egenconsulting.com> Subject: Re: Can we fix BYSETPOS? Date: Fri, 15 Jun 2001 11:11:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit ----- Original Message ----- From: <pregen@egenconsulting.com> To: "Jonathan Lennox" <lennox@cs.columbia.edu> Cc: "Alan Davies" <aland@steltor.com>; <Bruce_Kahn@iris.com>; <ietf-calendar@imc.org>; <owner-ietf-calendar@mail.imc.org> Sent: 12 June, 2001 21:37 Subject: Re: Can we fix BYSETPOS? > Jonathan, I do not believe we are hearing a "concensus" on your statement > > "Every iCalendar CS or CUA implementation is allowed to pick its own > definition, aribitrarily, of what event descriptions are too complex > for > it to handle, and refuse to handle such event descriptions. Such > implementations are still fully compliant implementations of RFC 2445 > and > its successors." > > I think we are hearing a few voices saying it's possible that maybe is > this is right. However, there are over 300 people who "lurk" on this list > - I believe I need to hear a few more than 5-6 to say it's a concensus. > > List, let's hear from some other listeners - do you agree with what > Jonathan says above. After some thought on the topic, I'd have to agree with . iCalendar is simply a data format, and only tells the implementor what the information means, not how it must be dealt with. I don't think anyone's having issues parsing the data; the IPTel people are having difficulties dealing with the full scope of the information once it's parsed, but that would seem to be outside the scope of the RFC. As long as an implementation can recognize an iCalendar object, I don't see any problem with that implementation then deciding that it doesn't want to deal with that object ("Filter out any iCalendar whose Organizer uses a Hotmail account," for example). Graham From owner-ietf-calendar@mail.imc.org Mon Jun 18 16:27:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20161 for <calsch-archive@odin.ietf.org>; Mon, 18 Jun 2001 16:27:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5IK5mW06437 for ietf-calendar-bks; Mon, 18 Jun 2001 13:05:48 -0700 (PDT) Received: from agony.busboom.org (dt010n57.san.rr.com [204.210.12.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5IK5lJ06433 for <ietf-calendar@imc.org>; Mon, 18 Jun 2001 13:05:47 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f5IK5QS01409; Mon, 18 Jun 2001 13:05:26 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Mon, 18 Jun 2001 13:05:26 -0700 (PDT) From: Eric Busboom <eric@softwarestudio.org> X-X-Sender: <eric@agony.busboom.org> To: Graham Gilmore <grahamg@steltor.com> cc: <ietf-calendar@imc.org> Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: <039c01c0f2d8$82216be0$092e0165@in.steltor.com> Message-ID: <Pine.LNX.4.33.0106140744480.2137-100000@agony.busboom.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> On Mon, 11 Jun 2001, Graham Gilmore wrote: > RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=12,13;BYSETPOS=-1,-2 > > > > Without BYSETPOS: > > > > RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYMONTHDAY=-1;BYHOUR=12,13; > > In this case, if the last day of the month is not one of > MO,TU,WE,TH,FR, that month would be skipped (since the intersection of > BYMONTHDAY and BYDAY is empty for that month). Like Bruce, I tried for > several minutes to come up with an alternative representation, and I > couldn't. Ah -- you are right. I can't think of a way to solve it either, and it is a very practical case. Looks like I'll have to abandon my proposal for restrictions. eric. From owner-ietf-calendar@mail.imc.org Wed Jun 20 10:24:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08760 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 10:24:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KDuCA20087 for ietf-calendar-bks; Wed, 20 Jun 2001 06:56:12 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KDuBk20083 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 06:56:11 -0700 (PDT) To: Eric Busboom <eric@softwarestudio.org> Cc: Graham Gilmore <grahamg@steltor.com>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06132001 June 13, 2001 Message-ID: <OFC00F7BFF.3A6B0BC4-ON85256A71.004C047E@iris.com> From: Bruce_Kahn@iris.com Date: Wed, 20 Jun 2001 09:58:26 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/20/2001 10:00:01 AM, Serialize complete at 06/20/2001 10:00:01 AM Content-Type: multipart/alternative; boundary="=_alternative 004C6E4A85256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 004C6E4A85256A71_= Content-Type: text/plain; charset="us-ascii" eric@softwarestudio.org wrote on 06/18/2001 04:05:26 PM: > Ah -- you are right. I can't think of a way to solve it either, and it is > a very practical case. Looks like I'll have to abandon my proposal for > restrictions. I think that not allowing BYSETPOS for recurrence sets that have fixed instance counts (ie: Ones that have only BYHOUR, BYMINUTE or BYSECOND subcomponents) can still be included for the reasons I sent last week. It is not unfeasible for this and would probably make describing BYSETPOS easier (ie: It is only useful for sets that have variable instance counts hence the original requirement that at least 1 BYxxx subcomponent must be there too). However if you want to abandon the restrictions I would suggest that we still add some clarifying text about BYSETPOS to the revision and include some examples like Jonathan & I hashed over in a different thread on this topic. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 004C6E4A85256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">eric@softwarestudio.org wrote on 06/18/2001 04:05:26 PM:<br> &gt; Ah -- you are right. I can't think of a way to solve it either, and it is<br> &gt; a very practical case. Looks like I'll have to abandon my proposal for<br> &gt; restrictions.<br> </font> <br><font size=2 face="sans-serif">I think that not allowing BYSETPOS for recurrence sets that have fixed instance counts (ie: Ones that have only BYHOUR, BYMINUTE or BYSECOND subcomponents) can still be included for the reasons I sent last week. &nbsp;It is not unfeasible for this and would probably make describing BYSETPOS easier (ie: It is only useful for sets that have variable instance counts hence the original requirement that at least 1 BYxxx subcomponent must be there too). &nbsp;</font> <br> <br><font size=2 face="sans-serif">However if you want to abandon the restrictions I would suggest that we still add some clarifying text about BYSETPOS to the revision and include some examples like Jonathan &amp; I hashed over in a different thread on this topic.</font> <br><font size=2 face="sans-serif"><br> Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 004C6E4A85256A71_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 20 10:30:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08968 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 10:30:26 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5KEGZx20613 for ietf-calendar-bks; Wed, 20 Jun 2001 07:16:35 -0700 (PDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KEGXk20609 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 07:16:33 -0700 (PDT) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Wed, 20 Jun 2001 15:16:26 +0100 Received: from ecemm (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 15Cilp-0005lf-00 for ietf-calendar@imc.org; Wed, 20 Jun 2001 15:15:49 +0100 Date: Wed, 20 Jun 2001 15:15:49 +0100 (BST) From: Libby Miller <Libby.Miller@bristol.ac.uk> To: ietf-calendar@imc.org Subject: Re: More Work on iCalendar RDF Schema (fwd) Message-ID: <Pine.GSO.4.21.0106201509240.15903-100000@mail.ilrt.bris.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Hi all, I'm organizing the RDF-calendar taskforce (see http://ilrt.org/discovery/2001/04/calendar/), and Michael Arick and I have separately been working on RDF schemas for iCalendar. Michael has very kindly created a single schema from the two (see below). It's still a draft, but we feel that it's coming along well, and the general approach is good. I'd be very interested in any comments about this. Please send them to me or preferably www-rdf-calendar@w3.org (you would need to subscribe; see the list announcement http://lists.w3.org/Archives/Public/www-rdf-calendar/2001Apr/0001.html) thanks Libby Miller ---------- Forwarded message ---------- Date: Tue, 19 Jun 2001 03:08:46 -0700 From: Michael Arick <marick@cse.ucsc.edu> To: RDF Calendar <www-rdf-calendar@w3.org> Subject: Re: More Work on iCalendar RDF Schema Resent-Date: Tue, 19 Jun 2001 07:05:01 -0400 (EDT) Resent-From: www-rdf-calendar@w3.org Hi Everybody: I now have, on my home page (http://www.cse.ucsc.edu/~marick/HybridCal/index.html) a new RDF schema for iCalendar data. This one is based on Libby's and my old one. I believe this one is pretty good, but it still has some issues. Please read it over, and make your concerns known as soon as possible. For your edification, I have also generated a couple of drawings of the schema from the SirPAC parser. They are at: http://www.cse.ucsc.edu/~marick/HybridCal/SirpacGenerated.pdf http://www.cse.ucsc.edu/~marick/HybridCal/SirpacGenerated.svg Enjoy! -Michael From owner-ietf-calendar@mail.imc.org Wed Jun 20 11:46:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11665 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 11:46:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KFLSH22928 for ietf-calendar-bks; Wed, 20 Jun 2001 08:21:28 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KFLQk22923 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 08:21:26 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06132001 June 13, 2001 Message-ID: <OFD5276F4A.5B8E2563-ON85256A71.00504DBF@iris.com> From: Bruce_Kahn@iris.com Date: Wed, 20 Jun 2001 11:23:41 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/20/2001 11:25:16 AM, Serialize complete at 06/20/2001 11:25:16 AM Content-Type: multipart/alternative; boundary="=_alternative 00543C7685256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 00543C7685256A71_= Content-Type: text/plain; charset="us-ascii" Jonathan pondered: >Actually, the reason I was confused is that the definition of the set >*isn't* clear from the examples, because the examples only show the use of >BYSETPOS with expanding BY* rules. The confusion comes from the use of >BYSETPOS with contracting BY* rules, which no examples show. (I suppose the >use of INTERVAL with BYSETPOS isn't technically ambiguous, but *I* certainly >mis-interpreted it. No examples show this either.) Sounds like we need to add a bigger variety of new examples to clarify things a bit. Im eyeball deep in work and some outside projects but if need be I can try to come up with an example of BYSETPOS in a contracting set. The only real requirement for BYSETPOS though is that the instance set the rule generates is not always constant. Beyond that, its just a matter of finding a a contracting (yet variable) set of instances... >Consider, e.g.: > > DTSTART;TZID=US-Eastern:19970929T090000 > RRULE:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=TU,TH;BYSETPOS=-1 > >Does this mean "The last Tuesday or Thursday of the week, every April and >June"? Or "The last Tuesday or Thursday of April, and the last Tuesday or >Thursday of June, every year"? Or "The last Tuesday or Thursday of (April >or June), every year"? Following the evaluation order from 2445 (p. 44, last paragraph) I would say that the rule decodes as follows: 1: The implied INTERVAL=1 means this rule is "Every week" (or "Every week in the entire year" if you prefer). 2: "BYMONTH=4,6" makes it "Every week in April & June" (or "In April & June, every week" if you strictly follow the RFCs phrasing style). 3: "BYDAY=TU,TH" makes it "Every Tuesday & Thursday [in the weeks] in April & June" if I clean the phrase up a bit (or "Every Tuesday & Thursday in April & June, every week" again). 4: "BYSETPOS=-1" means "The last instance in the set of ("Every Tuesday & Thursday in April & June")" which translates essentially down into "The last Tuesday or Thursday in June" since there are several June instances and we are only interested in the 'last one' of the combined set of April & June. As such, there are no actual used/referenced instances in April so the rule could have been simplified to: RRULE:FREQ=WEEKLY;BYMONTH=6;BYDAY=TU,TH;BYSETPOS=-1 and the result would be the same. If the intent was to get "The last Tuesday or Thursday in April AND June" then you would need to use 2 RRULEs (1 per month) since the desired instance can vary w/in each month really (ie: TU 29-Apr-1997 then TH 30-Apr-1998, TH 29-Apr-1999, TH 27-Apr-2000, TH 26-Apr-2001, TU 30-Apr-2002, etc. and the same kind of flipping occurs in June but not necessarily in the same order). >I'd extend this further, by changing the current sentence in RFC 2445 > It [BYSETPOS] MUST only be used in conjunction with another BYxxx rule > part. >to > It MUST only be used in conjunction with other BYxxx rule parts. At > least one of these BYxxx rule parts must be an "expanding" rule part, > that is, a BYxxx rule part representing an interval of time smaller than > FREQ. > >Do you object to this? I dont have a thought either way on expanding vs contracting w/o trying to do a couple examples of contracting (yet variable) cases. Let me mull it over a bit. Is my assumption that BYSETPOS is only a concern when the instance sets are variable correct? Im assuming it is but so far I haven't heard Yes or No from either you or Eric... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00543C7685256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Jonathan pondered:<br> &gt;Actually, the reason I was confused is that the definition of the set<br> &gt;*isn't* clear from the examples, because the examples only show the use of<br> &gt;BYSETPOS with expanding BY* rules. &nbsp;The confusion comes from the use of<br> &gt;BYSETPOS with contracting BY* rules, which no examples show. &nbsp;(I suppose the<br> &gt;use of INTERVAL with BYSETPOS isn't technically ambiguous, but *I* certainly<br> &gt;mis-interpreted it. &nbsp;No examples show this either.)<br> </font> <br><font size=2 face="sans-serif">Sounds like we need to add a bigger variety of new examples to clarify things a bit. &nbsp;Im eyeball deep in work and some outside projects but if need be I can try to come up with an example of BYSETPOS in a contracting set. &nbsp;The only real requirement for BYSETPOS though is that the instance set the rule generates is not always constant. &nbsp;Beyond that, its just a matter of finding a a contracting (yet variable) set of instances...</font> <br><font size=2 face="Courier New"><br> &gt;Consider, e.g.:<br> &gt;<br> &gt; &nbsp; &nbsp; &nbsp;DTSTART;TZID=US-Eastern:19970929T090000<br> &gt; &nbsp; &nbsp; &nbsp;RRULE:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=TU,TH;BYSETPOS=-1<br> &gt;<br> &gt;Does this mean &quot;The last Tuesday or Thursday of the week, every April and<br> &gt;June&quot;? &nbsp;Or &quot;The last Tuesday or Thursday of April, and the last Tuesday or<br> &gt;Thursday of June, every year&quot;? &nbsp;Or &quot;The last Tuesday or Thursday of (April<br> &gt;or June), every year&quot;?<br> </font> <br><font size=2 face="sans-serif">Following the evaluation order from 2445 (p. 44, last paragraph) I would say that the rule decodes as follows:</font> <br> <br><font size=2 face="sans-serif">1: The implied INTERVAL=1 means this rule is &quot;Every week&quot; (or &quot;Every week in the entire year&quot; if you prefer).</font> <br><font size=2 face="sans-serif">2: &quot;BYMONTH=4,6&quot; makes it &quot;Every week in April &amp; June&quot; (or &quot;In April &amp; June, every week&quot; if you strictly follow the RFCs phrasing style).</font> <br><font size=2 face="sans-serif">3: &quot;BYDAY=TU,TH&quot; makes it &quot;Every Tuesday &amp; Thursday [in the weeks] in April &amp; June&quot; if I clean the phrase up a bit (or &quot;Every Tuesday &amp; Thursday in April &amp; June, every week&quot; again).</font> <br><font size=2 face="sans-serif">4: &quot;BYSETPOS=-1&quot; means &quot;The last instance in the set of (&quot;Every Tuesday &amp; Thursday in April &amp; June&quot;)&quot; which translates essentially down into &quot;The last Tuesday or Thursday in June&quot; since there are several June instances and we are only interested in the 'last one' of the combined set of April &amp; June. &nbsp;</font> <br> <br><font size=2 face="sans-serif">As such, there are no actual used/referenced instances in April so the rule could have been simplified to:</font> <br> <br><font size=2 face="sans-serif">RRULE:FREQ=WEEKLY;BYMONTH=6;BYDAY=TU,TH;BYSETPOS=-1</font> <br> <br><font size=2 face="sans-serif">and the result would be the same. &nbsp;</font> <br> <br><font size=2 face="sans-serif">If the intent was to get &quot;The last Tuesday or Thursday in April AND June&quot; then you would need to use 2 RRULEs (1 per month) since the desired instance can vary w/in each month really (ie: TU 29-Apr-1997 then TH 30-Apr-1998, TH 29-Apr-1999, TH 27-Apr-2000, TH 26-Apr-2001, TU 30-Apr-2002, etc. and the same kind of flipping occurs in June but not necessarily in the same order). </font> <br><font size=2 face="Courier New"><br> &gt;I'd extend this further, by changing the current sentence in RFC 2445<br> &gt; &nbsp; &nbsp;It [BYSETPOS] MUST only be used in conjunction with another BYxxx rule<br> &gt; &nbsp; &nbsp;part.<br> &gt;to<br> &gt; &nbsp; &nbsp;It MUST only be used in conjunction with other BYxxx rule parts. &nbsp;At<br> &gt; &nbsp; &nbsp;least one of these BYxxx rule parts must be an &quot;expanding&quot; rule part,<br> &gt; &nbsp; &nbsp;that is, a BYxxx rule part representing an interval of time smaller than<br> &gt; &nbsp; &nbsp;FREQ.<br> &gt;<br> &gt;Do you object to this?<br> </font> <br><font size=2 face="sans-serif">I dont have a thought either way on expanding vs contracting w/o trying to do a couple examples of contracting (yet variable) cases. &nbsp;Let me mull it over a bit.</font> <br> <br><font size=2 face="sans-serif">Is my assumption that BYSETPOS is only a concern when the instance sets are variable correct? &nbsp;Im assuming it is but so far I haven't heard Yes or No from either you or Eric...</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> --=_alternative 00543C7685256A71_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 20 12:34:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13077 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 12:34:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KFsCi27717 for ietf-calendar-bks; Wed, 20 Jun 2001 08:54:12 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KFsAk27710 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 08:54:11 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06132001 June 13, 2001 Message-ID: <OF001D4ED2.26F01808-ON85256A71.0054AAA5@iris.com> From: Bruce_Kahn@iris.com Date: Wed, 20 Jun 2001 11:56:11 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/20/2001 11:58:01 AM, Serialize complete at 06/20/2001 11:58:01 AM Content-Type: multipart/alternative; boundary="=_alternative 0057363785256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0057363785256A71_= Content-Type: text/plain; charset="us-ascii" Jonathan replied with: >> > RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 [Snip, snip] >> W/o the BYSETPOS=1, this rule says that the entry repeats every week in >> April. If I had a DTSTART;TZID=US-Eastern:20010406T090000 w/this rule then the repeat set would be: >> >> (09:00:00 EDT) 06-Apr-2001, 13-Apr-2001, 20-Apr-2001, 27-Apr-2001 >> (09:00:00 EDT) 05-Apr-2002, 12-Apr-2002, 19-Apr-2002, 26-Apr-2002 >> ... >> >> However w/the BYSETPOS=1 the resulting repeat set becomes: >> >> (09:00:00 EDT) 06-Apr-2001 >> (09:00:00 EDT) 05-Apr-2002 >> ... > >Why? > >Why is the "set," for this rule, "all the events within a year" (or is it >"within a month"), rather than, say, "within a week" (FREQ) or "within >twenty-eight years" (least-common-multiple of BYMONTH and WEEKLY)? If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) then you decode the RRULE in the following way: 1: There is an implicit "INTERVAL=1" defined so this rule starts as "Every week" (or "Every week in the year forever" if you want a more verbose description") 2: "BYMONTH=4" refines it down to "Every week in April (forever)" 3: "BYSETPOS=1" refines it to "The first instance of the set of dates("Every week in April (forever)")" So if you inherit the time value from the DTSTART (since we have no time only BYxxx subcomponents in this case) and then you start rolling out the set based on the initial DTSTART date/time value. So if we had stopped @ step #2 (ie: no "BYSETPOS") then you get the first set of dates/times I listed. If we apply step #3 (ie: a "BYSETPOS") then we get the second set of dates/time I listed. >Can you write a pseudo-code algorithm which, for any combination of FREQ, >INTERVAL, and any BY* rules except BYSETPOS, tells me which event >recurrences should be marked as beginning a "set"? The text on the bottom of p. 44 of 2445 lays it out fairly well in plain english: If multiple BYxxx rule parts are specified, then after evaluating the specified FREQ and INTERVAL rule parts, the BYxxx rule parts are applied to the current set of evaluated occurrences in the following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. but it includes BYSETPOS near the end of the ordering for obvious reasons. COUNT / UNTIL are used as the 'until()' clause of your repeat/until loop (or your favorite do/while or other looping style of control). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0057363785256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Jonathan replied with:<br> &gt;&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1<br> [Snip, snip]</font> <br><font size=2 face="Courier New">&gt;&gt; W/o the BYSETPOS=1, this rule says that the entry repeats every week in <br> &gt;&gt; April. &nbsp;If I had a DTSTART;TZID=US-Eastern:20010406T090000 w/this rule then the repeat set would be:<br> &gt;&gt; <br> &gt;&gt; (09:00:00 EDT) 06-Apr-2001, 13-Apr-2001, 20-Apr-2001, 27-Apr-2001<br> &gt;&gt; (09:00:00 EDT) 05-Apr-2002, 12-Apr-2002, 19-Apr-2002, 26-Apr-2002<br> &gt;&gt; ...<br> &gt;&gt; <br> &gt;&gt; However w/the BYSETPOS=1 the resulting repeat set becomes:<br> &gt;&gt; <br> &gt;&gt; (09:00:00 EDT) 06-Apr-2001<br> &gt;&gt; (09:00:00 EDT) 05-Apr-2002<br> &gt;&gt; ...<br> &gt;<br> &gt;Why?<br> &gt;<br> &gt;Why is the &quot;set,&quot; for this rule, &quot;all the events within a year&quot; (or is it<br> &gt;&quot;within a month&quot;), rather than, say, &quot;within a week&quot; (FREQ) or &quot;within<br> &gt;twenty-eight years&quot; (least-common-multiple of BYMONTH and WEEKLY)?<br> </font> <br><font size=2 face="sans-serif">If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) then you decode the RRULE in the following way:</font> <br> <br><font size=2 face="sans-serif">1: There is an implicit &quot;INTERVAL=1&quot; defined so this rule starts as &quot;Every week&quot; (or &quot;Every week in the year forever&quot; if you want a more verbose description&quot;)</font> <br><font size=2 face="sans-serif">2: &quot;BYMONTH=4&quot; refines it down to &quot;Every week in April (forever)&quot;</font> <br><font size=2 face="sans-serif">3: &quot;BYSETPOS=1&quot; refines it to &quot;The first instance of the set of dates(&quot;Every week in April (forever)&quot;)&quot;</font> <br> <br><font size=2 face="sans-serif">So if you inherit the time value from the DTSTART (since we have no time only BYxxx subcomponents in this case) and then you start rolling out the set based on the initial DTSTART date/time value.</font> <br> <br><font size=2 face="sans-serif">So if we had stopped @ step #2 (ie: no &quot;BYSETPOS&quot;) then you get the first set of dates/times I listed. &nbsp;If we apply step #3 (ie: a &quot;BYSETPOS&quot;) then we get the second set of dates/time I listed.</font> <br> <br><font size=2 face="Courier New">&gt;Can you write a pseudo-code algorithm which, for any combination of FREQ,<br> &gt;INTERVAL, and any BY* rules except BYSETPOS, tells me which event<br> &gt;recurrences should be marked as beginning a &quot;set&quot;?</font> <br> <br><font size=2 face="sans-serif">The text on the bottom of p. 44 of 2445 lays it out fairly well in plain english:</font> <br> <br><font size=2><tt>&nbsp; &nbsp;If multiple BYxxx rule parts are specified, then after evaluating the<br> &nbsp; specified FREQ and INTERVAL rule parts, the BYxxx rule parts are<br> &nbsp; applied to the current set of evaluated occurrences in the following<br> &nbsp; order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,<br> &nbsp; BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.<br> </tt></font> <br><font size=2 face="sans-serif">but it includes BYSETPOS near the end of the ordering for obvious reasons. &nbsp;COUNT / UNTIL are used as the 'until()' clause of your repeat/until loop (or your favorite do/while or other looping style of control). &nbsp;</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> --=_alternative 0057363785256A71_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 20 14:14:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16714 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 14:14:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KHZdV00797 for ietf-calendar-bks; Wed, 20 Jun 2001 10:35:39 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KHZbk00793 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 10:35:38 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA29396; Wed, 20 Jun 2001 13:35:37 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id NAA05848; Wed, 20 Jun 2001 13:35:35 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.57062.296852.185660@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 13:35:34 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom <eric@softwarestudio.org>, Graham Gilmore <grahamg@steltor.com>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: <OFC00F7BFF.3A6B0BC4-ON85256A71.004C047E@iris.com> References: <OFC00F7BFF.3A6B0BC4-ON85256A71.004C047E@iris.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "Bruce_Kahn@iris.com" wrote to "Eric Busboom, Graham Gilmore, ietf-calendar@imc.org" saying: > eric@softwarestudio.org wrote on 06/18/2001 04:05:26 PM: > > Ah -- you are right. I can't think of a way to solve it either, and it > is > > a very practical case. Looks like I'll have to abandon my proposal for > > restrictions. > > I think that not allowing BYSETPOS for recurrence sets that have fixed > instance counts (ie: Ones that have only BYHOUR, BYMINUTE or BYSECOND > subcomponents) can still be included for the reasons I sent last week. It > is not unfeasible for this and would probably make describing BYSETPOS > easier (ie: It is only useful for sets that have variable instance counts > hence the original requirement that at least 1 BYxxx subcomponent must be > there too). This restriction doesn't do anything to accomplish my goal of setting restrictions, i.e. to ensure that processing of recurrence rules is computationally bounded (other than "bounded by 31 million recurrences", which isn't sufficient). -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 14:40:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17643 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 14:40:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KI2pu01410 for ietf-calendar-bks; Wed, 20 Jun 2001 11:02:51 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KI2ok01404 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 11:02:50 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA00856; Wed, 20 Jun 2001 14:02:50 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id OAA05887; Wed, 20 Jun 2001 14:02:50 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.58697.940955.434428@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 14:02:49 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: <OF001D4ED2.26F01808-ON85256A71.0054AAA5@iris.com> References: <OF001D4ED2.26F01808-ON85256A71.0054AAA5@iris.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: [We're discussing RRULE:DTSTART;TZID=US-Eastern:20010406T090000 RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 ] > >Why is the "set," for this rule, "all the events within a year" (or is it > >"within a month"), rather than, say, "within a week" (FREQ) or "within > >twenty-eight years" (least-common-multiple of BYMONTH and WEEKLY)? > > If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) > then you decode the RRULE in the following way: > > 1: There is an implicit "INTERVAL=1" defined so this rule starts as "Every > week" (or "Every week in the year forever" if you want a more verbose > description") > 2: "BYMONTH=4" refines it down to "Every week in April (forever)" > 3: "BYSETPOS=1" refines it to "The first instance of the set of > dates("Every week in April (forever)")" Step 3 is the step I don't get, and it's where the definition of "set" is crucial. Clearly, "the set of dates consisting of the first instance of the set of dates 'Every week in April, forever'" has exactly one member - one day in April. Similarly, "the set of dates consisting of the last instance of the set of dates 'Every week in April, forever'" is ill-defined, as there is no such last instance -- the set continues (as it says) forever. So you're implicitly assuming some other algorithm for determining the meaning of BYSETPOS, presumably derived from whatever algorithm you're using to enumerate infinite sets. If I decided to use an algorithm of "expand the set so that all events are a constant-time offset from n * constant-period + DTSTART", my sets for the above rule would be twenty-eight years in length (ignoring the Gregorian correction and any year-dependent changes in time zone rules). If I decided to use an algorithm of "for any given instance of n * FREQ + DTSTART, check to make sure it complies with all the contracting rules and INTERVAL, then apply the expanding rules", my set would be one week in length (and would have only a single member). Other than for BYSETPOS, both of these are reasonable implementation strategies for recurrence rules, I think. I have to admit, though, I don't see any implementation strategy for which "one year" is a natural resulting set for this rule. The standardized meaning Eric and I came up with was that the enclosing set was the unit of time indicated by FREQ. This is a natural fit with the second algorithm I said above, and is easy to explain and to understand. However, this clearly isn't what you're doing. So I don't understand what you *are* doing. Can you explain it? I.e., do you agree with the following general statements, and can you answer the question, in the model of recurrence rules you're using? Given a recurrence rule with a BYSETPOS rule, we have a period of time P (possibly with an irregular length, such as a month) such that BYSETPOS=1 indicates the first event following n * P + DTSTART for integer n >= 0, and BYSETPOS=-1 indicates the last event preceding n * P + DTSTART for integer n >= 1. P is independent of INTERVAL, COUNT, UNTIL, and expanding BY* rules. It depends only on FREQ and contracting BY* rules. Given a recurrence rule with a specified FREQ and some number of specified contracting BY* rules, how can you determine P? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 15:48:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20085 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:48:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KJ5iF02895 for ietf-calendar-bks; Wed, 20 Jun 2001 12:05:44 -0700 (PDT) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KJ5Zk02881 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 12:05:35 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: Bruce_Kahn@iris.com, Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org Subject: Re: Can we fix BYSETPOS? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFDC2B3C2C.4DB96E13-ON85256A71.0068B6D9@egenconsulting.com> From: pregen@egenconsulting.com Date: Wed, 20 Jun 2001 15:05:21 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 06/20/2001 03:05:24 PM, Serialize complete at 06/20/2001 03:05:24 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00693A2585256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 00693A2585256A71_= Content-Type: text/plain; charset="us-ascii" Can anyone on the list help Bruce come up with a good example so we can get this BYSETPOS item resolved. It sounds like we are very close. However, I know there must be someone else out there besides Eric, Jonathan and Bruce who have an idea of an example. Jonathan Lennox <lennox@cs.columbia.edu> Sent by: owner-ietf-calendar@mail.imc.org 06/20/01 02:02 PM To: Bruce_Kahn@iris.com cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? On Wednesday, June 20 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: [We're discussing RRULE:DTSTART;TZID=US-Eastern:20010406T090000 RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 ] > >Why is the "set," for this rule, "all the events within a year" (or is it > >"within a month"), rather than, say, "within a week" (FREQ) or "within > >twenty-eight years" (least-common-multiple of BYMONTH and WEEKLY)? > > If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) > then you decode the RRULE in the following way: > > 1: There is an implicit "INTERVAL=1" defined so this rule starts as "Every > week" (or "Every week in the year forever" if you want a more verbose > description") > 2: "BYMONTH=4" refines it down to "Every week in April (forever)" > 3: "BYSETPOS=1" refines it to "The first instance of the set of > dates("Every week in April (forever)")" Step 3 is the step I don't get, and it's where the definition of "set" is crucial. Clearly, "the set of dates consisting of the first instance of the set of dates 'Every week in April, forever'" has exactly one member - one day in April. Similarly, "the set of dates consisting of the last instance of the set of dates 'Every week in April, forever'" is ill-defined, as there is no such last instance -- the set continues (as it says) forever. So you're implicitly assuming some other algorithm for determining the meaning of BYSETPOS, presumably derived from whatever algorithm you're using to enumerate infinite sets. If I decided to use an algorithm of "expand the set so that all events are a constant-time offset from n * constant-period + DTSTART", my sets for the above rule would be twenty-eight years in length (ignoring the Gregorian correction and any year-dependent changes in time zone rules). If I decided to use an algorithm of "for any given instance of n * FREQ + DTSTART, check to make sure it complies with all the contracting rules and INTERVAL, then apply the expanding rules", my set would be one week in length (and would have only a single member). Other than for BYSETPOS, both of these are reasonable implementation strategies for recurrence rules, I think. I have to admit, though, I don't see any implementation strategy for which "one year" is a natural resulting set for this rule. The standardized meaning Eric and I came up with was that the enclosing set was the unit of time indicated by FREQ. This is a natural fit with the second algorithm I said above, and is easy to explain and to understand. However, this clearly isn't what you're doing. So I don't understand what you *are* doing. Can you explain it? I.e., do you agree with the following general statements, and can you answer the question, in the model of recurrence rules you're using? Given a recurrence rule with a BYSETPOS rule, we have a period of time P (possibly with an irregular length, such as a month) such that BYSETPOS=1 indicates the first event following n * P + DTSTART for integer n >= 0, and BYSETPOS=-1 indicates the last event preceding n * P + DTSTART for integer n >= 1. P is independent of INTERVAL, COUNT, UNTIL, and expanding BY* rules. It depends only on FREQ and contracting BY* rules. Given a recurrence rule with a specified FREQ and some number of specified contracting BY* rules, how can you determine P? -- Jonathan Lennox lennox@cs.columbia.edu --=_alternative 00693A2585256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">Can anyone on the list help Bruce come up with a good example so we can get this BYSETPOS item resolved. &nbsp;It sounds like we are very close. &nbsp;However, I know there must be someone else out there besides Eric, Jonathan and Bruce who have an idea of an example. &nbsp;</font> <br> <br> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>Jonathan Lennox &lt;lennox@cs.columbia.edu&gt;</b></font> <br><font size=1 face="sans-serif">Sent by: owner-ietf-calendar@mail.imc.org</font> <p><font size=1 face="sans-serif">06/20/01 02:02 PM</font> <br> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Bruce_Kahn@iris.com</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;Eric Busboom &lt;eric@softwarestudio.org&gt;, ietf-calendar@imc.org</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Can we fix BYSETPOS?</font></table> <br> <br> <br><font size=2><tt><br> On Wednesday, June 20 2001, &quot;Bruce_Kahn@iris.com&quot; wrote to &quot;Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org&quot; saying:<br> <br> [We're discussing<br> &nbsp; &nbsp; &nbsp; RRULE:DTSTART;TZID=US-Eastern:20010406T090000<br> &nbsp; &nbsp; &nbsp; RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1<br> ]<br> <br> &gt; &gt;Why is the &quot;set,&quot; for this rule, &quot;all the events within a year&quot; (or is it<br> &gt; &gt;&quot;within a month&quot;), rather than, say, &quot;within a week&quot; (FREQ) or &quot;within<br> &gt; &gt;twenty-eight years&quot; (least-common-multiple of BYMONTH and WEEKLY)?<br> &gt; <br> &gt; If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) <br> &gt; then you decode the RRULE in the following way:<br> &gt; <br> &gt; 1: There is an implicit &quot;INTERVAL=1&quot; defined so this rule starts as &quot;Every <br> &gt; week&quot; (or &quot;Every week in the year forever&quot; if you want a more verbose <br> &gt; description&quot;)<br> &gt; 2: &quot;BYMONTH=4&quot; refines it down to &quot;Every week in April (forever)&quot;<br> <br> &gt; 3: &quot;BYSETPOS=1&quot; refines it to &quot;The first instance of the set of <br> &gt; dates(&quot;Every week in April (forever)&quot;)&quot;<br> <br> Step 3 is the step I don't get, and it's where the definition of &quot;set&quot; is<br> crucial.<br> <br> Clearly, &quot;the set of dates consisting of the first instance of the set of<br> dates 'Every week in April, forever'&quot; has exactly one member - one day in<br> April.<br> <br> Similarly, &quot;the set of dates consisting of the last instance of the set of<br> dates 'Every week in April, forever'&quot; is ill-defined, as there is no such<br> last instance -- the set continues (as it says) forever.<br> <br> So you're implicitly assuming some other algorithm for determining the<br> meaning of BYSETPOS, presumably derived from whatever algorithm you're using<br> to enumerate infinite sets.<br> <br> If I decided to use an algorithm of &quot;expand the set so that all events are a<br> constant-time offset from n * constant-period + DTSTART&quot;, my sets for the<br> above rule would be twenty-eight years in length (ignoring the Gregorian<br> correction and any year-dependent changes in time zone rules).<br> <br> If I decided to use an algorithm of &quot;for any given instance of n * FREQ +<br> DTSTART, check to make sure it complies with all the contracting rules and<br> INTERVAL, then apply the expanding rules&quot;, my set would be one week in<br> length (and would have only a single member).<br> <br> Other than for BYSETPOS, both of these are reasonable implementation<br> strategies for recurrence rules, I think. &nbsp;I have to admit, though, I don't<br> see any implementation strategy for which &quot;one year&quot; is a natural resulting<br> set for this rule.<br> <br> The standardized meaning Eric and I came up with was that the enclosing set<br> was the unit of time indicated by FREQ. &nbsp;This is a natural fit with the<br> second algorithm I said above, and is easy to explain and to understand.<br> However, this clearly isn't what you're doing. &nbsp;So I don't understand what<br> you *are* doing.<br> <br> Can you explain it? &nbsp;I.e., do you agree with the following general<br> statements, and can you answer the question, in the model of recurrence rules<br> you're using?<br> <br> &nbsp; &nbsp; &nbsp; Given a recurrence rule with a BYSETPOS rule, we have a period of<br> &nbsp; &nbsp; &nbsp; time P (possibly with an irregular length, such as a month) such that<br> &nbsp; &nbsp; &nbsp; BYSETPOS=1 indicates the first event following n * P + DTSTART for<br> &nbsp; &nbsp; &nbsp; integer n &gt;= 0, and BYSETPOS=-1 indicates the last event preceding n *<br> &nbsp; &nbsp; &nbsp; P + DTSTART for integer n &gt;= 1.<br> <br> &nbsp; &nbsp; &nbsp; P is independent of INTERVAL, COUNT, UNTIL, and expanding BY* rules.<br> &nbsp; &nbsp; &nbsp; It depends only on FREQ and contracting BY* rules.<br> <br> &nbsp; &nbsp; &nbsp; Given a recurrence rule with a specified FREQ and some number of<br> &nbsp; &nbsp; &nbsp; specified contracting BY* rules, how can you determine P?<br> <br> -- <br> Jonathan Lennox<br> lennox@cs.columbia.edu<br> </tt></font> <br> <br> --=_alternative 00693A2585256A71_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 20 15:50:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20171 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:50:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KJE1n03128 for ietf-calendar-bks; Wed, 20 Jun 2001 12:14:01 -0700 (PDT) Received: from office.jigzaw.com ([63.144.102.109]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KJDxk03124 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 12:13:59 -0700 (PDT) Received: from colatz ([10.0.0.14]) by office.jigzaw.com (8.9.3/8.9.3) with ESMTP id OAA25692 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 14:13:30 -0500 From: "Shannon J. Clark" <shannon@jigzaw.com> To: <ietf-calendar@imc.org> Subject: RE: Can we fix BYSETPOS? (Proposed Restrictions) Date: Wed, 20 Jun 2001 14:13:48 -0500 Message-ID: <NEBBKFJICLIPPJJJBCFCGEFFCOAA.shannon@jigzaw.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15152.57062.296852.185660@grandcentral.cs.columbia.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit It sounds like we have discovered at least TWO issues with BYSETPOS One - even amongst working group members, who presumably have read the specs and thought about it a great deal there is much confusion about how to interpert BYSETPOS and how to write RRULES to express certain conditions (Such as repeat on "the last Tuesday of every April and June for every year" ) Two - we have a computational bounds issue with RRULES that create large and/or highly computationally complex sets of potential reoccurrences - which then need to be evaluated to fit a COUNT, BYSETPOS, or UNTIL conditional. As Jonathon has pointed out in his email - this is highly dependant on a common understanding of the SET that rules like BYSETPOS works on - clearly this is an area that needs clarification and explanation. I suggest that we look at arriving at a common understanding of issue One above, and then based on the common understanding describe the cases which generate computationally unbound (i.e. are exponential in computational requirements) and look for solutions to limit those cases. My personal thought is that there may be mathematical tricks that can be used to place bounds on many cases to reduce computational issues from unbound to manageable (i.e. many times you can limit the expansion of an RRULE to a set that captures the period for which you are concerned - by doing so you place additional bounds that may help limit and resolve an otherwise difficult calculation. Additionally, there may be structural tricks that can work on an RRULE expression to transform it to an equivalent form for computation - while preserving the original form for encapsulation of intent and meaning (i.e. the difference between COUNT and UNTIL - in many cases they can be transformed at runtime but you may want to preserve in storage). Furthermore there are at least THREE use cases to consider when looking at RRULES: A. Evaluating the question "Does this specific event occur NOW? (or within another FIXED interval of time)? - note this COULD be a Boolean query - unconcerned with the specific occurrence TIME or NUMBER of occurrences, just with whether or not the event occurs during the interval in question - you have to also look at how you define the interval - i.e. do you include the boundaries within or outside of the interval. B. Evaluating a SET of events to answer the question - WHICH EVENTS occur during a given interval? - and returning an order set of those events - this requires that in some way ALL events in the calendar are checked for whether or not they could occur during the interval in question, and for those that could that all occurrences are evaluated and then ordered. The one advantage we have from a computational point of view is that this is a bound case - with limits on the start and end of the interval in question - these in turn can be used to eliminate a large number of potential events, and hopefully reduce the computational time required to expand RRULES of the remaining. C. Populating a "FULL" calendar - this is a strawman case since events are allowed to reoccur "FOREVER" all use cases MUST have a bounds place on an initial query AND/OR must continue to reevaluate RRULES that are "FOREVER" as the use requires information further and further out - in point of fact the time systems currently defined and used by iCalendar have a year 9999 issue :-) An additional question might be of the following form - GIVEN a "new" event - does it overlap with any existing events in the calendar? This however may in most cases by a use for FREEBUSY information - which is in turn generated by evaluating the events on the calendar, looking at TRANSP settings, expanding RRULES for the required events, and building up this information. Hope this is helpful in focusing the discussions. Shannon -----Original Message----- From: owner-ietf-calendar@mail.imc.org [mailto:owner-ietf-calendar@mail.imc.org]On Behalf Of Jonathan Lennox Sent: Wednesday, June 20, 2001 12:36 PM To: Bruce_Kahn@iris.com Cc: Eric Busboom; Graham Gilmore; ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? (Proposed Restrictions) On Wednesday, June 20 2001, "Bruce_Kahn@iris.com" wrote to "Eric Busboom, Graham Gilmore, ietf-calendar@imc.org" saying: > eric@softwarestudio.org wrote on 06/18/2001 04:05:26 PM: > > Ah -- you are right. I can't think of a way to solve it either, and it > is > > a very practical case. Looks like I'll have to abandon my proposal for > > restrictions. > > I think that not allowing BYSETPOS for recurrence sets that have fixed > instance counts (ie: Ones that have only BYHOUR, BYMINUTE or BYSECOND > subcomponents) can still be included for the reasons I sent last week. It > is not unfeasible for this and would probably make describing BYSETPOS > easier (ie: It is only useful for sets that have variable instance counts > hence the original requirement that at least 1 BYxxx subcomponent must be > there too). This restriction doesn't do anything to accomplish my goal of setting restrictions, i.e. to ensure that processing of recurrence rules is computationally bounded (other than "bounded by 31 million recurrences", which isn't sufficient). -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 15:55:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20417 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 15:55:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KJI3V03227 for ietf-calendar-bks; Wed, 20 Jun 2001 12:18:03 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KJI1k03223 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 12:18:01 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA05655; Wed, 20 Jun 2001 15:18:03 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id PAA07104; Wed, 20 Jun 2001 15:18:02 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.63210.60207.590980@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 15:18:02 -0400 (EDT) To: "Robert Ransdell/Iris" <Robert_Ransdell@iris.com> Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: <OFBAFCB0CC.43222DFF-ON85256A71.00671890@lotus.com> References: <OFBAFCB0CC.43222DFF-ON85256A71.00671890@lotus.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "Robert Ransdell/Iris" wrote to ""Jonathan Lennox, ietf-calendar@imc.org" saying: > The BYSETPOS is evaluated over one instance of the set. > In this case one instance of the set is defined by FREQ=WEEKLY;INTERVAL=1 > For every year, months January, February, March, May, June, July, August, > September, October, November and December becomes empty sets because of the BYMONTH=4 rule. > For April of every year the weekly expansion is evaluated and than the > BYSETPOS item is picked. So are you proposing (or claiming) "the size of the set is the largest unit of time mentioned in the rule"? How would you resolve RRULE:DTSTART;TZID=US-Eastern:20010406T090000 RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYSETPOS=-1 ? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 16:47:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22151 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 16:47:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KKBEp04713 for ietf-calendar-bks; Wed, 20 Jun 2001 13:11:14 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KKBDk04708 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 13:11:13 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA09297; Wed, 20 Jun 2001 16:11:15 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id QAA07787; Wed, 20 Jun 2001 16:11:15 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15153.865.999897.937092@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 16:11:13 -0400 (EDT) To: Robert_Ransdell@iris.com Cc: ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: <OFED1C4455.2CB94B94-ON85256A71.006ABE58@iris.com> References: <OFED1C4455.2CB94B94-ON85256A71.006ABE58@iris.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "Robert_Ransdell@iris.com" wrote to "Jonathan Lennox, ietf-calendar@imc.org" saying: > The FREQ = WEEKLY > The INTERVAL =1 > The BYMONTH is a reduction restriction. > > DTSTART is 4/6/2001 so starting there > for WEEKLY in April I have dates 4/6/2001 (set of one) BYSETPOS=-1 GET > 4/6 > 4/13/2001 (set of one) > BYSETPOS=-1 get 4/13 > 4/20/2001 (set of one) > BYSETPOS=-1 get 4/20 > 4/27/2001 (set of one) BYSETPOS=-1 > get 4/27 ... and so on ... Okay. So in other words, you agree with Eric and me, and disagree with Bruce -- this rule means "the last Friday of the week, in April and June", and the enclosing unit of a BYSETPOS set is the FREQ. Thus, BYSETPOS is mostly meaningless if only reduction restrictions (contracting rules) are present, since only single-element sets are generated. (This is the cause of the rather bizarre qualifier "the last Friday of the week," above.) Bruce was saying (I think) that this rule should instead be interpreted as generating 6/29/2001 6/28/2002 6/27/2003 ... I.e. "the last Friday of (April or June) in the year", which is equivalent to "the last Friday of June in the year" since DTSTART is in April. I don't understand his logic for this, though. > RRULE:DTSTART;TZID=US-Eastern:20010406T090000 > RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYSETPOS=-1 -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 17:08:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22861 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 17:08:13 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KKVNf05272 for ietf-calendar-bks; Wed, 20 Jun 2001 13:31:23 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KKVMk05268 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 13:31:22 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA19274; Wed, 20 Jun 2001 16:31:24 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id QAA07869; Wed, 20 Jun 2001 16:31:23 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15153.2075.336929.95820@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 16:31:23 -0400 (EDT) To: "Shannon J. Clark" <shannon@jigzaw.com> Cc: <ietf-calendar@imc.org> Subject: RE: Can we fix BYSETPOS? (Proposed Restrictions) In-Reply-To: <NEBBKFJICLIPPJJJBCFCGEFFCOAA.shannon@jigzaw.com> References: <15152.57062.296852.185660@grandcentral.cs.columbia.edu> <NEBBKFJICLIPPJJJBCFCGEFFCOAA.shannon@jigzaw.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "Shannon J. Clark" wrote to "<ietf-calendar@imc.org>" saying: > > It sounds like we have discovered at least TWO issues with BYSETPOS I agree with your general statement. It's a very good summary. I have a few comments on specific points, though. > One - even amongst working group members, who presumably have read the specs > and thought about it a great deal there is much confusion about how to > interpert BYSETPOS and how to write RRULES to express certain conditions > (Such as repeat on "the last Tuesday of every April and June for every > year" ) I think there probably isn't too much disagreement about the "natural" way to represent most common rules. The disagreements we're having (I think) are about how to interpret rules which are perhaps "un-natural" ways of representing certain recurrences. > Two - we have a computational bounds issue with RRULES that create large > and/or highly computationally complex sets of potential reoccurrences - > which then need to be evaluated to fit a COUNT, BYSETPOS, or UNTIL > conditional. As Jonathon has pointed out in his email - this is highly > dependant on a common understanding of the SET that rules like BYSETPOS > works on - clearly this is an area that needs clarification and explanation. Yes. The smaller the set, clearly, the less computation needed. > I suggest that we look at arriving at a common understanding of issue One > above, and then based on the common understanding describe the cases which > generate computationally unbound (i.e. are exponential in computational > requirements) and look for solutions to limit those cases. Just to clarify this a bit -- "exponential" is a bit strong here. No algorithms I've found are worse than linear, in the *values* of the parameters. The problem, though, is that these values can be arbitrarily large. Especially, DTSTART can be located in the absurdly distant past, DURATION can be arbitrarily long, and BYSETPOS values are (apparently) limited only by "seconds per year". > My personal thought is that there may be mathematical tricks that can be > used to place bounds on many cases to reduce computational issues from > unbound to manageable (i.e. many times you can limit the expansion of an > RRULE to a set that captures the period for which you are concerned - by > doing so you place additional bounds that may help limit and resolve an > otherwise difficult calculation. Additionally, there may be structural > tricks that can work on an RRULE expression to transform it to an equivalent > form for computation - while preserving the original form for encapsulation > of intent and meaning (i.e. the difference between COUNT and UNTIL - in many > cases they can be transformed at runtime but you may want to preserve in > storage). Yes. The problem is that "many cases" aren't "all cases", at least I think they aren't. The limited-expansions and the structural tricks work nicely for resolving the problems with DTSTART and COUNT. However, I haven't yet found any similar tricks for DURATION and BYSETPOS, and I'm not sure any such tricks are possible. > Furthermore there are at least THREE use cases to consider when looking at > RRULES: > > A. Evaluating the question "Does this specific event occur NOW? (or within > another FIXED interval of time)? - note this COULD be a Boolean query - > unconcerned with the specific occurrence TIME or NUMBER of occurrences, just > with whether or not the event occurs during the interval in question - you > have to also look at how you define the interval - i.e. do you include the > boundaries within or outside of the interval. Note also that DURATION is very relevant for this. Usually, the question you want to ask is "Is this specific event occuring now" or "is this event occuring within this interval of time", not "does this event start now / within this interval". A number of existing calendaring systems get this wrong -- if you ask them to show "events on Tuesday", they won't show a four-hour event which begins at 10PM Monday. This is why I restricted the acceptable values for DURATION in my initial RECUR subset for CPL. CPL only cares about your "is this event occuring now" case, but this is equivalent to "does this event start between DURATION ago, and now." > Hope this is helpful in focusing the discussions. I hope so too... -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 17:11:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23018 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 17:11:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KJTeM03485 for ietf-calendar-bks; Wed, 20 Jun 2001 12:29:40 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KJTck03481 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 12:29:38 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA06250; Wed, 20 Jun 2001 15:26:54 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id PAA07113; Wed, 20 Jun 2001 15:26:53 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.63741.310107.517957@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 15:26:53 -0400 (EDT) To: pregen@egenconsulting.com Cc: Bruce_Kahn@iris.com, Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: <OFDC2B3C2C.4DB96E13-ON85256A71.0068B6D9@egenconsulting.com> References: <OFDC2B3C2C.4DB96E13-ON85256A71.0068B6D9@egenconsulting.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "pregen@egenconsulting.com" wrote to "Jonathan Lennox, Bruce_Kahn@iris.com, Eric Busboom, ietf-calendar@imc.org, owner-ietf-calendar@mail.imc.org" saying: > Can anyone on the list help Bruce come up with a good example so we can > get this BYSETPOS item resolved. It sounds like we are very close. > However, I know there must be someone else out there besides Eric, > Jonathan and Bruce who have an idea of an example. Examples are all well and good, but not sufficient. As things stand now, the normative text for RRULE is so ambiguous and unclear (especially for the weird corner cases) that people end up deriving RRULE's semantics by reverse-engineering the examples. In the cases which the examples don't cover, people guess differently. We really need clear, formal semantics defined for all of the RRULE cases. Ideally, a pseudo-code algorithm should be given for it. -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 17:15:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23131 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 17:15:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KKe1205453 for ietf-calendar-bks; Wed, 20 Jun 2001 13:40:01 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KKe0k05445 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 13:40:00 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06132001 June 13, 2001 Message-ID: <OF5D5CD426.AEFC7C27-ON85256A71.006BF954@iris.com> From: Bruce_Kahn@iris.com Date: Wed, 20 Jun 2001 16:38:43 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/20/2001 04:42:31 PM, Serialize complete at 06/20/2001 04:42:31 PM Content-Type: multipart/alternative; boundary="=_alternative 0071137485256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0071137485256A71_= Content-Type: text/plain; charset="us-ascii" Jonathan Lennox <lennox@cs.columbia.edu> wrote on 06/20/2001 02:02:49 PM: >[We're discussing > RRULE:DTSTART;TZID=US-Eastern:20010406T090000 > RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 >] [Snip, snip] > > If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) > > then you decode the RRULE in the following way: > > > > 1: There is an implicit "INTERVAL=1" defined so this rule starts as "Every > > week" (or "Every week in the year forever" if you want a more verbose > > description") > > 2: "BYMONTH=4" refines it down to "Every week in April (forever)" > > > 3: "BYSETPOS=1" refines it to "The first instance of the set of > > dates("Every week in April (forever)")" > > Step 3 is the step I don't get, and it's where the definition of "set" is > crucial. I sure wish that Frank or Vinod would pipe up for a change so that they can help Jonathan understand this. I don't seem to be doing a bang up job of it. I cannot give a purely mathematical defintion so Ive tried to define by example (something I think I picked up from Frank along the way). I think that before now there was some believe that the 'set' was all possible instances ever (which makes BYSETPOS=-1 impossible for infinitely repeating sets like our current example). Ill try another description to see if I can clarify it while I poke the others OOB to provide an answer that may help you further. In Step #2 we have a set or 'template' (new term to try and get around any mental baggage) for the rule that contains "Every week in April (forever)". That is, it contains: 1: The (effective) DTSTART date/time (call it DTS0). In reality it is 20010406T090000. 2: DTS0 + "1 week" (DTS1). In reality it is 20010413T090000. 3: DTS1 + "1 week" (DTS2). In reality it is 20010420T090000. 4: DTS2 + "1 week" (DTS3). In reality it is 20010427T090000. There is no #5 since DTS3 + "1 week" would put it outside the BYMONTH value for 2001 but it MAY exist eventually in some years. The template does NOT contain 20020405T090000, 20020412T090000, etc. since that would be another Aprils worth of values and that would require evaluating the subcomponents again (ie: another pass down the evaluation order). We do not do this since that is basically reevaluating the rule at its next starting point using a the BYMONTH over again. This is probably going to be confusing or disputable to some at this point but Ill press on to try and complete my description. So when we get to Step #3 we want to take just the 1st instance of the template (ie: Just item #1) and that is how I got to my dates I originally posted. > Clearly, "the set of dates consisting of the first instance of the set of > dates 'Every week in April, forever'" has exactly one member - one day in > April. If you describe it that way then it does have only 1 value (the DTSTART really). However I think that the 'forever' tidbit is confusing the matter. I only put it in to be complete since we never had an UNTIL or COUNT. However I do not read Step #3 as "the set of dates consisting of the first instance of the set of dates 'Every week in April, forever'" I read it as "the set of dates consisting of the first instance of the set of dates 'Every week in April' that repeats forever". Perhaps I should have written my original text better but I did not mean to say that the BYSETPOS evaluation applied to an infinite set but it repeated infinitely on the set of "Every week in April". If you take the view that the BYSETPOS applies to all possible instances of a rule then you are not limited by 31M but rather by infinity and that is just not even remotely viable no matter how long you apply Moores law. Perhaps it would help me understand your confusion if you could decypher the following example: DTSTART;TZID=US-Eastern:20010621T090000 RRULE:FREQ=MONTHLY;BYDAY=TH;BYSETPOS=4 for me. Do you view it as "The 4th Thursday in the month, forever"? Or "The set of dates consisting of the 4th instance of the set of dates 'Every Thursday in the month, forever'"? Or "The set of dates consisting of the 4th instance of the set of dates "Every Thursday in the month", forever"? The differences are subtle but significant. > Similarly, "the set of dates consisting of the last instance of the set of > dates 'Every week in April, forever'" is ill-defined, as there is no such > last instance -- the set continues (as it says) forever. Poor grammar on my part attempting to mimic the style of 2445. I think it is better written as "the set of dates consisting of the last instance of the set of dates 'Every week in April', forever" (the single quote was moved to not include the last word). > So you're implicitly assuming some other algorithm for determining the > meaning of BYSETPOS, presumably derived from whatever algorithm you're using > to enumerate infinite sets. Will not go down that path as it was NEVER my contention that the set / template was infinite in size. I was pointing out that if you applied BYSETPOS incorrectly you could mistakenly create a single, infinite set rather than a set of instances (or a single instance) that is repeatedly reused forever. > If I decided to use an algorithm of "expand the set so that all events are a > constant-time offset from n * constant-period + DTSTART", my sets for the > above rule would be twenty-eight years in length (ignoring the Gregorian > correction and any year-dependent changes in time zone rules). I think you shorted something in your calculation. You could never have the full set since you did not include a COUNT or UNTIL so the set of matching dates becomes infinite (assuming we dont split hairs about the value becoming Y10K, etc). > The standardized meaning Eric and I came up with was that the enclosing set > was the unit of time indicated by FREQ. This is a natural fit with the > second algorithm I said above, and is easy to explain and to understand. > However, this clearly isn't what you're doing. So I don't understand what > you *are* doing. > > Can you explain it? Ill get the person who owns it now to describe it in an attempt to get another voice involved. That may help clarify things. Bruce PS: I know the cited example @ the top is off but its readers can understand it all the same... Do not send me nudges OOB about it. =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0071137485256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Jonathan Lennox &lt;lennox@cs.columbia.edu&gt; wrote on 06/20/2001 02:02:49 PM:<br> &gt;[We're discussing<br> &gt; &nbsp; &nbsp; &nbsp; RRULE:DTSTART;TZID=US-Eastern:20010406T090000<br> &gt; &nbsp; &nbsp; &nbsp; RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1<br> &gt;]<br> [Snip, snip]</font> <br><font size=2 face="Courier New">&gt; &gt; If you follow the decoding guidelines in Section 4.3.10 (p. 44 generally) <br> &gt; &gt; then you decode the RRULE in the following way:<br> &gt; &gt; <br> &gt; &gt; 1: There is an implicit &quot;INTERVAL=1&quot; defined so this rule starts as &quot;Every <br> &gt; &gt; week&quot; (or &quot;Every week in the year forever&quot; if you want a more verbose <br> &gt; &gt; description&quot;)<br> &gt; &gt; 2: &quot;BYMONTH=4&quot; refines it down to &quot;Every week in April (forever)&quot;<br> &gt; <br> &gt; &gt; 3: &quot;BYSETPOS=1&quot; refines it to &quot;The first instance of the set of <br> &gt; &gt; dates(&quot;Every week in April (forever)&quot;)&quot;<br> &gt; <br> &gt; Step 3 is the step I don't get, and it's where the definition of &quot;set&quot; is<br> &gt; crucial.<br> </font> <br><font size=2 face="sans-serif">I sure wish that Frank or Vinod would pipe up for a change so that they can help Jonathan understand this. &nbsp;I don't seem to be doing a bang up job of it. &nbsp;I cannot give a purely mathematical defintion so Ive tried to define by example (something I think I picked up from Frank along the way).</font> <br> <br><font size=2 face="sans-serif">I think that before now there was some believe that the 'set' was all possible instances ever (which makes BYSETPOS=-1 impossible for infinitely repeating sets like our current example).</font> <br> <br><font size=2 face="sans-serif">Ill try another description to see if I can clarify it while I poke the others OOB to provide an answer that may help you further. &nbsp;In Step #2 we have a set or 'template' (new term to try and get around any mental baggage) for the rule that contains &quot;Every week in April (forever)&quot;. &nbsp;That is, it contains:</font> <br> <br><font size=2 face="sans-serif">1: The (effective) DTSTART date/time (call it DTS0). &nbsp;In reality it is 20010406T090000.</font> <br><font size=2 face="sans-serif">2: DTS0 + &quot;1 week&quot; (DTS1). &nbsp;In reality it is 20010413T090000.</font> <br><font size=2 face="sans-serif">3: DTS1 + &quot;1 week&quot; (DTS2). &nbsp;In reality it is 20010420T090000.</font> <br><font size=2 face="sans-serif">4: DTS2 + &quot;1 week&quot; (DTS3). &nbsp;In reality it is 20010427T090000.</font> <br> <br><font size=2 face="sans-serif">There is no #5 since DTS3 + &quot;1 week&quot; would put it outside the BYMONTH value for 2001 but it MAY exist eventually in some years. &nbsp;</font> <br> <br><font size=2 face="sans-serif">The template does NOT contain 20020405T090000, 20020412T090000, etc. since that would be another Aprils worth of values and that would require evaluating the subcomponents again (ie: another pass down the evaluation order). &nbsp;We do not do this since that is basically reevaluating the rule at its next starting point using a the BYMONTH over again. &nbsp;</font> <br> <br><font size=2 face="sans-serif">This is probably going to be confusing or disputable to some at this point but Ill press on to try and complete my description.</font> <br> <br><font size=2 face="sans-serif">So when we get to Step #3 we want to take just the 1st instance of the template (ie: Just item #1) and that is how I got to my dates I originally posted.</font> <br> <br><font size=2 face="Courier New">&gt; Clearly, &quot;the set of dates consisting of the first instance of the set of<br> &gt; dates 'Every week in April, forever'&quot; has exactly one member - one day in<br> &gt; April.<br> </font> <br><font size=2 face="sans-serif">If you describe it that way then it does have only 1 value (the DTSTART really). &nbsp;However I think that the 'forever' tidbit is confusing the matter. &nbsp;I only put it in to be complete since we never had an UNTIL or COUNT.</font> <br> <br><font size=2 face="sans-serif">However I do not read Step #3 as &quot;the set of dates consisting of the first instance of the set of dates 'Every week in April, forever'&quot; &nbsp;I read it as &quot;the set of dates consisting of the first instance of the set of dates 'Every week in April' that repeats forever&quot;. &nbsp;Perhaps I should have written my original text better but I did not mean to say that the BYSETPOS evaluation applied to an infinite set but it repeated infinitely on the set of &quot;Every week in April&quot;. </font> <br> <br><font size=2 face="sans-serif">If you take the view that the BYSETPOS applies to all possible instances of a rule then you are not limited by 31M but rather by infinity and that is just not even remotely viable no matter how long you apply Moores law.</font> <br> <br><font size=2 face="sans-serif">Perhaps it would help me understand your confusion if you could decypher the following example:</font> <br> <br><font size=2 face="sans-serif">DTSTART;TZID=US-Eastern:20010621T090000</font> <br><font size=2 face="sans-serif">RRULE:FREQ=MONTHLY;BYDAY=TH;BYSETPOS=4</font> <br> <br><font size=2 face="sans-serif">for me. &nbsp;Do you view it as &quot;The 4th Thursday in the month, forever&quot;? &nbsp;Or &quot;The set of dates consisting of the 4th instance of the set of dates 'Every Thursday in the month, forever'&quot;? Or &quot;The set of dates consisting of the 4th instance of the set of dates &quot;Every Thursday in the month&quot;, forever&quot;? &nbsp;The differences are subtle but significant.</font> <br> <br><font size=2 face="Courier New">&gt; Similarly, &quot;the set of dates consisting of the last instance of the set of<br> &gt; dates 'Every week in April, forever'&quot; is ill-defined, as there is no such<br> &gt; last instance -- the set continues (as it says) forever.<br> </font> <br><font size=2 face="sans-serif">Poor grammar on my part attempting to mimic the style of 2445. &nbsp;I think it is better written as &quot;the set of dates consisting of the last instance of the set of dates 'Every week in April', forever&quot; (the single quote was moved to not include the last word).</font> <br> <br><font size=2 face="Courier New">&gt; So you're implicitly assuming some other algorithm for determining the<br> &gt; meaning of BYSETPOS, presumably derived from whatever algorithm you're using<br> &gt; to enumerate infinite sets.<br> </font> <br><font size=2 face="sans-serif">Will not go down that path as it was NEVER my contention that the set / template was infinite in size. &nbsp;I was pointing out that if you applied BYSETPOS incorrectly you could mistakenly create a single, infinite set rather than a set of instances (or a single instance) that is repeatedly reused forever.</font> <br> <br><font size=2 face="Courier New">&gt; If I decided to use an algorithm of &quot;expand the set so that all events are a<br> &gt; constant-time offset from n * constant-period + DTSTART&quot;, my sets for the<br> &gt; above rule would be twenty-eight years in length (ignoring the Gregorian<br> &gt; correction and any year-dependent changes in time zone rules).<br> </font> <br><font size=2 face="sans-serif">I think you shorted something in your calculation. &nbsp;You could never have the full set since you did not include a COUNT or UNTIL so the set of matching dates becomes infinite (assuming we dont split hairs about the value becoming Y10K, etc).</font> <br> <br><font size=2 face="Courier New">&gt; The standardized meaning Eric and I came up with was that the enclosing set<br> &gt; was the unit of time indicated by FREQ. &nbsp;This is a natural fit with the<br> &gt; second algorithm I said above, and is easy to explain and to understand.<br> &gt; However, this clearly isn't what you're doing. &nbsp;So I don't understand what<br> &gt; you *are* doing.<br> &gt; <br> &gt; Can you explain it? &nbsp;</font> <br> <br><font size=2 face="sans-serif">Ill get the person who owns it now to describe it in an attempt to get another voice involved. &nbsp;That may help clarify things.</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">PS: I know the cited example @ the top is off but its readers can understand it all the same... Do not send me nudges OOB about it.</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 0071137485256A71_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 20 17:30:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23576 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 17:30:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KKuSL05851 for ietf-calendar-bks; Wed, 20 Jun 2001 13:56:28 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KKuRk05847 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 13:56:27 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: ietf-calendar@imc.org, Robert_Ransdell@iris.com Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06132001 June 13, 2001 Message-ID: <OF703FF0F8.97DE9124-ON85256A71.0072BE5B@iris.com> From: Bruce_Kahn@iris.com Date: Wed, 20 Jun 2001 16:58:46 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/20/2001 04:58:58 PM, Serialize complete at 06/20/2001 04:58:58 PM Content-Type: multipart/alternative; boundary="=_alternative 0072E96C85256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0072E96C85256A71_= Content-Type: text/plain; charset="us-ascii" Jonathan wrote on 06/20/2001 04:11:13 PM: > Okay. So in other words, you agree with Eric and me, and disagree with > Bruce -- this rule means "the last Friday of the week, in April and June", > and the enclosing unit of a BYSETPOS set is the FREQ. Thus, BYSETPOS is > mostly meaningless if only reduction restrictions (contracting rules) are > present, since only single-element sets are generated. (This is the cause > of the rather bizarre qualifier "the last Friday of the week," above.) This is all starting to rehash an unresolved issue I raised wwaaaaayyyy back on 30-Jun-2000 (Subject: Seeking RRULE evaluation guidance) about handling disjoint BYxxx values in the same subcomponent. Only 3 folks even replied at first but we got no further traction on it. This is a digression but perhaps it is relevant to resolve now... I think we need to get some other vendors invovlved and I know that Netscape/iPlanet has done some work here and so has Steltor so Id love to hear their ideas on this unresolved issue. Steve? Mario? Graham? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072E96C85256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Jonathan wrote on 06/20/2001 04:11:13 PM:<br> &gt; Okay. &nbsp;So in other words, you agree with Eric and me, and disagree with<br> &gt; Bruce -- this rule means &quot;the last Friday of the week, in April and June&quot;,<br> &gt; and the enclosing unit of a BYSETPOS set is the FREQ. &nbsp;Thus, BYSETPOS is<br> &gt; mostly meaningless if only reduction restrictions (contracting rules) are<br> &gt; present, since only single-element sets are generated. &nbsp;(This is the cause<br> &gt; of the rather bizarre qualifier &quot;the last Friday of the week,&quot; above.)<br> </font> <br><font size=2 face="sans-serif">This is all starting to rehash an unresolved issue I raised wwaaaaayyyy back on 30-Jun-2000 (Subject: Seeking RRULE evaluation guidance) about handling disjoint BYxxx values in the same subcomponent. &nbsp;Only 3 folks even replied at first but we got no further traction on it. &nbsp;This is a digression but perhaps it is relevant to resolve now...</font> <br> <br><font size=2 face="sans-serif">I think we need to get some other vendors invovlved and I know that Netscape/iPlanet has done some work here and so has Steltor so Id love to hear their ideas on this unresolved issue. &nbsp;Steve? Mario? Graham?</font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> <br> --=_alternative 0072E96C85256A71_=-- From owner-ietf-calendar@mail.imc.org Wed Jun 20 17:41:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23969 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 17:41:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KL8hT06104 for ietf-calendar-bks; Wed, 20 Jun 2001 14:08:43 -0700 (PDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KL8gk06100 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 14:08:42 -0700 (PDT) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA27479; Wed, 20 Jun 2001 17:08:43 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3+Sun/8.9.3) id RAA09069; Wed, 20 Jun 2001 17:08:42 -0400 (EDT) X-Authentication-Warning: grandcentral.cs.columbia.edu: lennox set sender to lennox@grandcentral.cs.columbia.edu using -f From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15153.4313.940504.69556@grandcentral.cs.columbia.edu> Date: Wed, 20 Jun 2001 17:08:41 -0400 (EDT) To: Bruce_Kahn@iris.com Cc: Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? In-Reply-To: <OF5D5CD426.AEFC7C27-ON85256A71.006BF954@iris.com> References: <OF5D5CD426.AEFC7C27-ON85256A71.006BF954@iris.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit On Wednesday, June 20 2001, "Bruce_Kahn@iris.com" wrote to "Jonathan Lennox, Eric Busboom, ietf-calendar@imc.org" saying: > Jonathan Lennox <lennox@cs.columbia.edu> wrote on 06/20/2001 02:02:49 PM: > >[We're discussing > > RRULE:DTSTART;TZID=US-Eastern:20010406T090000 > > RECUR:FREQ=WEEKLY;BYMONTH=4;BYSETPOS=1 > >] > I sure wish that Frank or Vinod would pipe up for a change so that they > can help Jonathan understand this. I don't seem to be doing a bang up job > of it. I cannot give a purely mathematical defintion so Ive tried to > define by example (something I think I picked up from Frank along the > way). > I think that before now there was some believe that the 'set' was all > possible instances ever (which makes BYSETPOS=-1 impossible for infinitely > repeating sets like our current example). Yes, clearly that's wrong. That was mostly just a complaint about the terminology being unclear. I didn't mean to harp on that point. I think it's also clear that even for bounded sets, COUNT and UNTIL apply *after* BYSETPOS. > Ill try another description to see if I can clarify it while I poke the > others OOB to provide an answer that may help you further. In Step #2 we > have a set or 'template' (new term to try and get around any mental > baggage) for the rule that contains "Every week in April (forever)". That > is, it contains: > > 1: The (effective) DTSTART date/time (call it DTS0). In reality it is 20010406T090000. > 2: DTS0 + "1 week" (DTS1). In reality it is 20010413T090000. > 3: DTS1 + "1 week" (DTS2). In reality it is 20010420T090000. > 4: DTS2 + "1 week" (DTS3). In reality it is 20010427T090000. > > There is no #5 since DTS3 + "1 week" would put it outside the BYMONTH > value for 2001 but it MAY exist eventually in some years. > > The template does NOT contain 20020405T090000, 20020412T090000, etc. since > that would be another Aprils worth of values and that would require > evaluating the subcomponents again (ie: another pass down the evaluation > order). We do not do this since that is basically reevaluating the rule > at its next starting point using a the BYMONTH over again. So you're saying that the duration of the 'template' depends on the largest BY* rule (or FREQ, if that's larger) mentioned in the rule. I really don't like that -- I think the interpretation which I, Eric, and Robert advocate is both much more useful and much easier to explain. Here's why. Consider the following three rules: RRULE:DTSTART;TZID=US-Eastern:20010401T090000 RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1 RRULE:DTSTART;TZID=US-Eastern:20010401T090000 RECUR:FREQ=MONTHLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1 RRULE:DTSTART;TZID=US-Eastern:20010401T090000 RECUR:FREQ=YEARLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1 As far as I can generalize from your example, these three examples under your interpretation would be *identical* -- the FREQ is completely irrelevant. They all generate "The last Friday of (April or June)". Under my interpretation, these would be, respectively, "the last Friday of the week, in April and June" (i.e. "Fridays in April and June"); "the last Friday of April, and the last Friday of June"; and "the last Friday of (April or June)" (i.e., given DTSTART, "The last Friday of June"). Regardless of what RFC 2445 seems to say (and I think it's apparent by now that this is terribly unclear), do people agree that the above interpretation is what RRULE *should* mean? -- Jonathan Lennox lennox@cs.columbia.edu From owner-ietf-calendar@mail.imc.org Wed Jun 20 17:54:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24308 for <calsch-archive@odin.ietf.org>; Wed, 20 Jun 2001 17:54:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5KLINf06405 for ietf-calendar-bks; Wed, 20 Jun 2001 14:18:23 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KLIMk06401 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 14:18:22 -0700 (PDT) To: Jonathan Lennox <lennox@cs.columbia.edu> Cc: ietf-calendar@imc.org, Robert_Ransdell@iris.com Subject: Re: Can we fix BYSETPOS? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06132001 June 13, 2001 Message-ID: <OF324B577B.352084C5-ON85256A71.0074A90A@iris.com> From: Bruce_Kahn@iris.com Date: Wed, 20 Jun 2001 17:20:45 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/20/2001 05:20:54 PM, Serialize complete at 06/20/2001 05:20:54 PM Content-Type: multipart/alternative; boundary="=_alternative 0074EC8285256A71_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0074EC8285256A71_= Content-Type: text/plain; charset="us-ascii" Jonathan wrote on 06/20/2001 04:11:13 PM: > > The FREQ = WEEKLY > > The INTERVAL =1 > > The BYMONTH is a reduction restriction. [Snip, snip] > Bruce was saying (I think) that this rule should instead be interpreted as > generating > > 6/29/2001 > 6/28/2002 > 6/27/2003 > ... At some point I was using FREQ=MONTHLY instead of FREQ=WEEKLY. Im not sure where the disjoint happened so I went back to _my_ original example and it was: DTSTART;TZID=US-Eastern:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 so I think the thread for the past day or so has been a BIG miscommunication somehow. I checked the archive and found that I did start w/MONTHLY (http://www.imc.org/ietf-calendar/mail-archive/msg04829.html) so lets try to reset here before we all blow some gray cells for nothing. I need to leave now to run some family errands but Ill pick this up again tomorrow. Bruce PS: Has anyone gotten the actual WG postings from Robert_Ransdell@iris.com?? I havent and they do not appear to be in the archives so Im curious if Im alone or not... =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0074EC8285256A71_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="Courier New">Jonathan wrote on 06/20/2001 04:11:13 PM:<br> &gt; &gt; The FREQ = WEEKLY<br> &gt; &gt; The INTERVAL =1<br> &gt; &gt; The BYMONTH is a reduction restriction.<br> [Snip, snip]</font> <br><font size=2 face="Courier New">&gt; Bruce was saying (I think) that this rule should instead be interpreted as<br> &gt; generating<br> &gt; <br> &gt; 6/29/2001<br> &gt; 6/28/2002<br> &gt; 6/27/2003<br> &gt; ...<br> </font> <br><font size=2 face="sans-serif">At some point I was using FREQ=MONTHLY instead of FREQ=WEEKLY. &nbsp;Im not sure where the disjoint happened so I went back to _my_ original example and it was:</font> <br> <br><font size=2 face="sans-serif">&nbsp; &nbsp; DTSTART;TZID=US-Eastern:19970929T090000<br> &nbsp; &nbsp;RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2<br> </font> <br><font size=2 face="sans-serif">so I think the thread for the past day or so has been a BIG miscommunication somehow. &nbsp;I checked the archive and found that I did start w/MONTHLY (http://www.imc.org/ietf-calendar/mail-archive/msg04829.html) so lets try to reset here before we all blow some gray cells for nothing.</font> <br> <br><font size=2 face="sans-serif">I need to leave now to run some family errands but Ill pick this up again tomorrow. </font> <br> <br><font size=2 face="sans-serif">Bruce</font> <br><font size=2 face="sans-serif">PS: Has anyone gotten the actual WG postings from Robert_Ransdell@iris.com?? &nbsp;I havent and they do not appear to be in the archives so Im curious if Im alone or not...</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> <br> <br> --=_alternative 0074EC8285256A71_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 21 01:24:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05779 for <calsch-archive@odin.ietf.org>; Thu, 21 Jun 2001 01:24:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5L55Bp16862 for ietf-calendar-bks; Wed, 20 Jun 2001 22:05:11 -0700 (PDT) Received: from server1.egenconsulting.com (www.egenconsulting.com [207.244.42.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5L555k16851 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 22:05:05 -0700 (PDT) To: Bruce_Kahn@iris.com Cc: ietf-calendar@imc.org, Jonathan Lennox <lennox@cs.columbia.edu>, owner-ietf-calendar@mail.imc.org, Robert_Ransdell@iris.com Subject: Re: Can we fix BYSETPOS? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: <OFFF36CC58.B61C1224-ON85256A72.001BE280@egenconsulting.com> From: pregen@egenconsulting.com Date: Thu, 21 Jun 2001 01:04:53 -0400 X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0.5 |September 22, 2000) at 06/21/2001 01:04:56 AM, Serialize complete at 06/21/2001 01:04:56 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 001C496C85256A72_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 001C496C85256A72_= Content-Type: text/plain; charset="us-ascii" Bruce, I have not seen posting from Robert Ransdell. ___________________ Patricia Egen Consulting www.egenconsulting.com 423-875-2652 Bruce_Kahn@iris.com Sent by: owner-ietf-calendar@mail.imc.org 06/20/01 05:20 PM To: Jonathan Lennox <lennox@cs.columbia.edu> cc: ietf-calendar@imc.org, Robert_Ransdell@iris.com Subject: Re: Can we fix BYSETPOS? Jonathan wrote on 06/20/2001 04:11:13 PM: > > The FREQ = WEEKLY > > The INTERVAL =1 > > The BYMONTH is a reduction restriction. [Snip, snip] > Bruce was saying (I think) that this rule should instead be interpreted as > generating > > 6/29/2001 > 6/28/2002 > 6/27/2003 > ... At some point I was using FREQ=MONTHLY instead of FREQ=WEEKLY. Im not sure where the disjoint happened so I went back to _my_ original example and it was: DTSTART;TZID=US-Eastern:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 so I think the thread for the past day or so has been a BIG miscommunication somehow. I checked the archive and found that I did start w/MONTHLY (http://www.imc.org/ietf-calendar/mail-archive/msg04829.html) so lets try to reset here before we all blow some gray cells for nothing. I need to leave now to run some family errands but Ill pick this up again tomorrow. Bruce PS: Has anyone gotten the actual WG postings from Robert_Ransdell@iris.com?? I havent and they do not appear to be in the archives so Im curious if Im alone or not... =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 001C496C85256A72_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">Bruce, I have not seen posting from Robert Ransdell.<br> ___________________<br> Patricia Egen Consulting<br> www.egenconsulting.com<br> 423-875-2652</font> <br> <br> <br> <table width=100%> <tr valign=top> <td> <td><font size=1 face="sans-serif"><b>Bruce_Kahn@iris.com</b></font> <br><font size=1 face="sans-serif">Sent by: owner-ietf-calendar@mail.imc.org</font> <p><font size=1 face="sans-serif">06/20/01 05:20 PM</font> <br> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;Jonathan Lennox &lt;lennox@cs.columbia.edu&gt;</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;ietf-calendar@imc.org, Robert_Ransdell@iris.com</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Can we fix BYSETPOS?</font></table> <br> <br> <br><font size=2 face="Courier New"><br> Jonathan wrote on 06/20/2001 04:11:13 PM:<br> &gt; &gt; The FREQ = WEEKLY<br> &gt; &gt; The INTERVAL =1<br> &gt; &gt; The BYMONTH is a reduction restriction.<br> [Snip, snip]</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br> &gt; Bruce was saying (I think) that this rule should instead be interpreted as<br> &gt; generating<br> &gt; <br> &gt; 6/29/2001<br> &gt; 6/28/2002<br> &gt; 6/27/2003<br> &gt; ...</font><font size=3 face="Times New Roman"><br> </font><font size=2 face="sans-serif"><br> At some point I was using FREQ=MONTHLY instead of FREQ=WEEKLY. &nbsp;Im not sure where the disjoint happened so I went back to _my_ original example and it was:</font><font size=3 face="Times New Roman"> <br> </font><font size=2 face="sans-serif"><br> &nbsp; &nbsp;DTSTART;TZID=US-Eastern:19970929T090000<br> &nbsp; RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2</font><font size=3 face="Times New Roman"><br> </font><font size=2 face="sans-serif"><br> so I think the thread for the past day or so has been a BIG miscommunication somehow. &nbsp;I checked the archive and found that I did start w/MONTHLY (http://www.imc.org/ietf-calendar/mail-archive/msg04829.html) so lets try to reset here before we all blow some gray cells for nothing.</font><font size=3 face="Times New Roman"> <br> </font><font size=2 face="sans-serif"><br> I need to leave now to run some family errands but Ill pick this up again tomorrow. </font><font size=3 face="Times New Roman"><br> </font><font size=2 face="sans-serif"><br> Bruce</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br> PS: Has anyone gotten the actual WG postings from Robert_Ransdell@iris.com?? &nbsp;I havent and they do not appear to be in the archives so Im curious if Im alone or not...</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br> ===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font><font size=3 face="Times New Roman"> <br> </font> <br> <br> --=_alternative 001C496C85256A72_=-- From owner-ietf-calendar@mail.imc.org Thu Jun 21 01:50:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07505 for <calsch-archive@odin.ietf.org>; Thu, 21 Jun 2001 01:50:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5L5VJF17309 for ietf-calendar-bks; Wed, 20 Jun 2001 22:31:19 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5L5VHk17305 for <ietf-calendar@imc.org>; Wed, 20 Jun 2001 22:31:18 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id BAA01336; Thu, 21 Jun 2001 01:30:39 -0400 Message-ID: <3B31793B.AC2ED60E@ximian.com> Date: Thu, 21 Jun 2001 00:34:03 -0400 From: Damon Chaplin <damon@ximian.com> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox <lennox@cs.columbia.edu> CC: Bruce_Kahn@iris.com, Eric Busboom <eric@softwarestudio.org>, ietf-calendar@imc.org Subject: Re: Can we fix BYSETPOS? References: <OF5D5CD426.AEFC7C27-ON85256A71.006BF954@iris.com> <15153.4313.940504.69556@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > Here's why. Consider the following three rules: > > RRULE:DTSTART;TZID=US-Eastern:20010401T090000 > RECUR:FREQ=WEEKLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1 > > RRULE:DTSTART;TZID=US-Eastern:20010401T090000 > RECUR:FREQ=MONTHLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1 > > RRULE:DTSTART;TZID=US-Eastern:20010401T090000 > RECUR:FREQ=YEARLY;BYMONTH=4,6;BYDAY=FR;BYSETPOS=-1 > > As far as I can generalize from your example, these three examples under > your interpretation would be *identical* -- the FREQ is completely > irrelevant. They all generate "The last Friday of (April or June)". > > Under my interpretation, these would be, respectively, "the last Friday of > the week, in April and June" (i.e. "Fridays in April and June"); "the last > Friday of April, and the last Friday of June"; and "the last Friday of > (April or June)" (i.e., given DTSTART, "The last Friday of June"). > > Regardless of what RFC 2445 seems to say (and I think it's apparent by now > that this is terribly unclear), do people agree that the above > interpretation is what RRULE *should* mean? I think (hope/pray!) you are correct on this. I think the set covers a period equal to the RRULE frequency. e.g. for "FREQ=WEEKLY" a set of occurrences is generated for each week. for "FREQ=YEARLY;INTERVAL=2" a set of occurrences is generated for every other year. Damon From owner-ietf-calendar@mail.imc.org Mon Jun 25 11:44:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18782 for <calsch-archive@odin.ietf.org>; Mon, 25 Jun 2001 11:44:55 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5PFN6n09637 for ietf-calendar-bks; Mon, 25 Jun 2001 08:23:06 -0700 (PDT) Received: from lnsmtp.on.com (lnsmtp.on.com [207.18.216.12]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5PFN2k09619 for <ietf-calendar@imc.org>; Mon, 25 Jun 2001 08:23:02 -0700 (PDT) Received: by lnsmtp.on.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 85256A76.005491DE ; Mon, 25 Jun 2001 11:23:43 -0400 X-Lotus-FromDomain: ON TECHNOLOGY From: svangasse@meetingmaker.com To: ietf-calendar@imc.org Message-ID: <85256A76.005490AE.00@lnsmtp.on.com> Date: Mon, 25 Jun 2001 11:21:36 -0400 Subject: global tzid? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> I've been looking through the calsch threads on the possibility of using some kind of globally defined TZID in a VTIMEZONE. Where does the group currently stand on this issue? Are we waiting for the tz registry to be set up? Steve Vangasse Software Engineer meetingmaker http://www.meetingmaker.com From owner-ietf-calendar@mail.imc.org Mon Jun 25 11:49:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18989 for <calsch-archive@odin.ietf.org>; Mon, 25 Jun 2001 11:49:46 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5PFaMr12633 for ietf-calendar-bks; Mon, 25 Jun 2001 08:36:22 -0700 (PDT) Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PFaIk12620 for <ietf-calendar@imc.org>; Mon, 25 Jun 2001 08:36:18 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f5PFaCr07991 for <ietf-calendar@imc.org>; Mon, 25 Jun 2001 08:36:13 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GFHSOC00.J17; Mon, 25 Jun 2001 08:36:12 -0700 Message-ID: <3B375A88.FA7A87C4@netscape.com> Date: Mon, 25 Jun 2001 08:36:40 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: svangasse@meetingmaker.com CC: ietf-calendar@imc.org Subject: Re: global tzid? References: <85256A76.005490AE.00@lnsmtp.on.com> Content-Type: multipart/mixed; boundary="------------732455A6EB67698DA4487C22" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --------------732455A6EB67698DA4487C22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit we'd love to have one. I keep hearing rumors that it's an easy thing to do. It would be great if someone would step up and do it. -Steve svangasse@meetingmaker.com wrote: > I've been looking through the calsch threads on the possibility of using some > kind of globally defined TZID in a VTIMEZONE. Where does the group currently > stand on this issue? Are we waiting for the tz registry to be set up? > > Steve Vangasse > Software Engineer > meetingmaker > http://www.meetingmaker.com --------------732455A6EB67698DA4487C22 Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------732455A6EB67698DA4487C22-- From owner-ietf-calendar@mail.imc.org Mon Jun 25 22:16:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03471 for <calsch-archive@odin.ietf.org>; Mon, 25 Jun 2001 22:16:27 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5Q1r3H10953 for ietf-calendar-bks; Mon, 25 Jun 2001 18:53:03 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5Q1r0m10949 for <ietf-calendar@imc.org>; Mon, 25 Jun 2001 18:53:00 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id VAA04401 for <ietf-calendar@imc.org>; Mon, 25 Jun 2001 21:52:58 -0400 Message-ID: <3B37EB83.14FC077A@ximian.com> Date: Mon, 25 Jun 2001 21:55:15 -0400 From: Damon Chaplin <damon@ximian.com> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-calendar@imc.org" <ietf-calendar@imc.org> Subject: are blank lines allowed? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Quick question: are blank lines allowed in iCalendar? I was separating VTIMEZONE components with a blank line like this for clarity: BEGIN:STANDARD TZOFFSETFROM:+0000 TZOFFSETTO:-000052 TZNAME:LMT DTSTART:00010101T000000 RDATE:00010101T000000 END:STANDARD BEGIN:STANDARD TZOFFSETFROM:-000052 TZOFFSETTO:+0000 TZNAME:GMT DTSTART:19180101T000000 RDATE:19180101T000000 END:STANDARD But I've been told that this isn't actually correct. Damon From owner-ietf-calendar@mail.imc.org Tue Jun 26 10:42:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14497 for <calsch-archive@odin.ietf.org>; Tue, 26 Jun 2001 10:42:43 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5QEQjr23979 for ietf-calendar-bks; Tue, 26 Jun 2001 07:26:45 -0700 (PDT) Received: from localhost.localdomain ([216.52.68.3]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QEQim23975 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 07:26:44 -0700 (PDT) Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f5QESMC02470 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 10:28:22 -0400 Message-ID: <3B389C06.2257196@ecal.com> Date: Tue, 26 Jun 2001 10:28:22 -0400 From: John Stracke <francis@ecal.com> X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586) X-Accept-Language: en, de, es MIME-Version: 1.0 To: "ietf-calendar@imc.org" <ietf-calendar@imc.org> Subject: Re: are blank lines allowed? References: <3B37EB83.14FC077A@ximian.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit Damon Chaplin wrote: > Quick question: are blank lines allowed in iCalendar? [...] > But I've been told that this isn't actually correct. I was the one who pointed it out to Damon, when pulling in his Olson-in-iCalendar work (for which I was very grateful, of course, and which I was able to use just by grepping out the blank lines--no big deal). Although RFC-2445 doesn't actually give an overall syntax definition, I don't see any places where two consecutive CRLFs could occur. Each component is defined in terms of a series of properties, and each property is defined with ABNF that includes a ":", ends in CRLF, and does not contain any interior CRLF. (Line folding is another issue, but it doesn't permit blank lines either, though it would mean that a line containing a single linear-whitespace character would be ignored.) While I kind of like the idea of being able to insert blank lines for readability, I think it's too late; we don't want to start sending iCalendar that existing implementations can't accept. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"HTTP is what happens in the absence of good | |francis@ecal.com|design." -- Keith Moore | \==============================================================/ From owner-ietf-calendar@mail.imc.org Tue Jun 26 11:18:40 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19908 for <calsch-archive@odin.ietf.org>; Tue, 26 Jun 2001 11:18:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5QF3Cd25972 for ietf-calendar-bks; Tue, 26 Jun 2001 08:03:12 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QF3Bm25968 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 08:03:11 -0700 (PDT) To: "ietf-calendar@imc.org" <ietf-calendar@imc.org> Subject: Re: are blank lines allowed? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06202001 June 20, 2001 Message-ID: <OF1CAFBC65.D9567082-ON85256A77.0052FCE8@iris.com> From: Robert_Ransdell@iris.com Date: Tue, 26 Jun 2001 11:07:07 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/26/2001 11:05:19 AM, Serialize complete at 06/26/2001 11:05:19 AM Content-Type: multipart/alternative; boundary="=_alternative 0052830285256A77_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0052830285256A77_= Content-Type: text/plain; charset="us-ascii" Just for the record; the Notes code will ignore blank lines. John Stracke <francis@ecal.com> Sent by: owner-ietf-calendar@mail.imc.org 06/26/2001 10:28 AM To: "ietf-calendar@imc.org" <ietf-calendar@imc.org> cc: (bcc: Robert Ransdell/Iris) Subject: Re: are blank lines allowed? Damon Chaplin wrote: > Quick question: are blank lines allowed in iCalendar? [...] > But I've been told that this isn't actually correct. I was the one who pointed it out to Damon, when pulling in his Olson-in-iCalendar work (for which I was very grateful, of course, and which I was able to use just by grepping out the blank lines--no big deal). Although RFC-2445 doesn't actually give an overall syntax definition, I don't see any places where two consecutive CRLFs could occur. Each component is defined in terms of a series of properties, and each property is defined with ABNF that includes a ":", ends in CRLF, and does not contain any interior CRLF. (Line folding is another issue, but it doesn't permit blank lines either, though it would mean that a line containing a single linear-whitespace character would be ignored.) While I kind of like the idea of being able to insert blank lines for readability, I think it's too late; we don't want to start sending iCalendar that existing implementations can't accept. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"HTTP is what happens in the absence of good | |francis@ecal.com|design." -- Keith Moore | \==============================================================/ --=_alternative 0052830285256A77_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">Just for the record; the Notes code will ignore blank lines.</font> <br> <br> <br> <table width=100%> <tr valign=top> <td bgcolor=#b0c8e0> <td bgcolor=#b0c8e0><font size=1 face="sans-serif"><b>John Stracke &lt;francis@ecal.com&gt;</b></font> <br><font size=1 face="sans-serif">Sent by: owner-ietf-calendar@mail.imc.org</font> <p><font size=1 face="sans-serif">06/26/2001 10:28 AM</font> <br> <td bgcolor=#b0c8e0><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;ietf-calendar@imc.org&quot; &lt;ietf-calendar@imc.org&gt;</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;(bcc: Robert Ransdell/Iris)</font> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: are blank lines allowed?</font></table> <br> <br> <br><font size=2 face="Courier New"><br> Damon Chaplin wrote:<br> <br> &gt; Quick question: are blank lines allowed in iCalendar?<br> <br> [...]<br> <br> &gt; But I've been told that this isn't actually correct.<br> <br> I was the one who pointed it out to Damon, when pulling in his Olson-in-iCalendar<br> work (for which I was very grateful, of course, and which I was able to use just<br> by grepping out the blank lines--no big deal). &nbsp;Although RFC-2445 doesn't<br> actually give an overall syntax definition, I don't see any places where two<br> consecutive CRLFs could occur. &nbsp;Each component is defined in terms of a series of<br> properties, and each property is defined with ABNF that includes a &quot;:&quot;, ends in<br> CRLF, and does not contain any interior CRLF.<br> <br> (Line folding is another issue, but it doesn't permit blank lines either, though<br> it would mean that a line containing a single linear-whitespace character would<br> be ignored.)<br> <br> While I kind of like the idea of being able to insert blank lines for<br> readability, I think it's too late; we don't want to start sending iCalendar that<br> existing implementations can't accept.<br> <br> --<br> /==============================================================\<br> |John Stracke &nbsp; &nbsp;| http://www.ecal.com |My opinions are my own.|<br> |Chief Scientist |=============================================|<br> |eCal Corp. &nbsp; &nbsp; &nbsp;|&quot;HTTP is what happens in the absence of good |<br> |francis@ecal.com|design.&quot; -- Keith Moore &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|<br> \==============================================================/<br> <br> <br> <br> </font> <br> <br> --=_alternative 0052830285256A77_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 26 14:41:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02514 for <calsch-archive@odin.ietf.org>; Tue, 26 Jun 2001 14:41:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5QIOQC06908 for ietf-calendar-bks; Tue, 26 Jun 2001 11:24:26 -0700 (PDT) Received: from Arista.iris.com (arista.iris.com [198.112.211.42]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5QIOPm06904 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 11:24:25 -0700 (PDT) To: Damon Chaplin <damon@ximian.com> Cc: ietf-calendar@imc.org Subject: Re: are blank lines allowed? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_06242001 June 24, 2001 Message-ID: <OFF1B67038.853FE7E3-ON85256A77.0062BEF2@iris.com> From: Bruce_Kahn@iris.com Date: Tue, 26 Jun 2001 14:28:16 -0400 X-MIMETrack: Serialize by Router on Arista/Iris(Build V508_05242001 |May 24, 2001) at 06/26/2001 02:28:33 PM, Serialize complete at 06/26/2001 02:28:33 PM Content-Type: multipart/alternative; boundary="=_alternative 0064DAFA85256A77_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multipart message in MIME format. --=_alternative 0064DAFA85256A77_= Content-Type: text/plain; charset="us-ascii" Damon asked: > Quick question: are blank lines allowed in iCalendar? Well a strict intepretation of 2445s ABNF: The following notation defines the lines of content in an iCalendar object: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string or more precisely: icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF) icalbody = calprops component component = 1*(eventc / todoc / journalc / freebusyc / / timezonec / iana-comp / x-comp) iana-comp = "BEGIN" ":" iana-token CRLF 1*contentline "END" ":" iana-token CRLF timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2*( [Snip, snip] ) "END" ":" "VTIMEZONE" CRLF would lead me to say that extra CRLF are not allowed if you take a strict interpreation. In any case, I would hope that engines would be somewhat lenient in dealing with extra stuff like that. I know we are. Im a bit overloaded now so perhaps someone else can do a quick test of pasting some 'pretty' iCalendar into Outlook or their engines and see what comes out. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@iris.com Iris Associates Phone: 978.392.5335 Westford, MA, USA 01886 FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0064DAFA85256A77_= Content-Type: text/html; charset="us-ascii" <br><font size=2 face="sans-serif">Damon asked:</font> <br><font size=2 face="Courier New">&gt; Quick question: are blank lines allowed in iCalendar?<br> </font> <br><font size=2 face="sans-serif">Well a strict intepretation of 2445s ABNF:</font> <br> <br><font size=2><tt>&nbsp; &nbsp;The following notation defines the lines of content in an iCalendar<br> &nbsp; object:<br> <br> &nbsp; &nbsp; contentline &nbsp; &nbsp; &nbsp; &nbsp;= name *(&quot;;&quot; param ) &quot;:&quot; value CRLF<br> &nbsp; &nbsp; &nbsp; &nbsp;; This ABNF is just a general definition for an initial parsing<br> &nbsp; &nbsp; &nbsp; &nbsp;; of the content line into its property name, parameter list,<br> &nbsp; &nbsp; &nbsp; &nbsp;; and value string<br> </tt></font> <br><font size=2 face="sans-serif">or more precisely:</font> <br> <br><font size=2><tt>&nbsp; &nbsp; &nbsp;icalobject = 1*(&quot;BEGIN&quot; &quot;:&quot; &quot;VCALENDAR&quot; CRLF<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;icalbody<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;END&quot; &quot;:&quot; &quot;VCALENDAR&quot; CRLF)<br> </tt></font> <br><font size=2><tt>&nbsp; &nbsp; &nbsp;icalbody &nbsp; = calprops component<br> <br> &nbsp; &nbsp; component &nbsp;= 1*(eventc / todoc / journalc / freebusyc /<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/ timezonec / iana-comp / x-comp)<br> <br> &nbsp; &nbsp; iana-comp &nbsp;= &quot;BEGIN&quot; &quot;:&quot; iana-token CRLF<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1*contentline<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;END&quot; &quot;:&quot; iana-token CRLF<br> <br> &nbsp; &nbsp; timezonec &nbsp;= &quot;BEGIN&quot; &quot;:&quot; &quot;VTIMEZONE&quot; CRLF<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;2*(<br> [Snip, snip]</tt></font> <br><font size=2><tt>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; )<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;END&quot; &quot;:&quot; &quot;VTIMEZONE&quot; CRLF</tt></font> <br> <br><font size=2 face="sans-serif">would lead me to say that extra CRLF are not allowed if you take a strict interpreation. &nbsp;In any case, I would hope that engines would be somewhat lenient in dealing with extra stuff like that. &nbsp;I know we are. &nbsp;Im a bit overloaded now so perhaps someone else can do a quick test of pasting some 'pretty' iCalendar into Outlook or their engines and see what comes out.</font> <br><font size=2 face="sans-serif"><br> Bruce</font> <br><font size=2 face="sans-serif">===========================================================================<br> Bruce Kahn &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;INet: Bruce_Kahn@iris.com<br> Iris Associates &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Phone: 978.392.5335<br> Westford, MA, USA 01886 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;FAX: and nothing but the FAX...<br> Standard disclaimers apply, even where prohibited by law...</font> --=_alternative 0064DAFA85256A77_=-- From owner-ietf-calendar@mail.imc.org Tue Jun 26 23:34:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAB25756 for <calsch-archive@odin.ietf.org>; Tue, 26 Jun 2001 23:34:05 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5R3GIT04908 for ietf-calendar-bks; Tue, 26 Jun 2001 20:16:18 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5R3GGm04904 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 20:16:17 -0700 (PDT) Received: from ximian.com (IDENT:damon@[141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id XAA22321; Tue, 26 Jun 2001 23:16:13 -0400 Message-ID: <3B395081.ADE3E36@ximian.com> Date: Tue, 26 Jun 2001 23:18:25 -0400 From: Damon Chaplin <damon@ximian.com> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour <sman@netscape.com> CC: svangasse@meetingmaker.com, ietf-calendar@imc.org Subject: Re: global tzid? References: <85256A76.005490AE.00@lnsmtp.on.com> <3B375A88.FA7A87C4@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit I thought we'd agreed on using a vendor ID to guarantee uniqueness of the TZIDs. In libical (and hence Evolution) we use TZIDs like this: TZID:/softwarestudio.org/Olson_20010601_1/Africa/Dakar The "/softwarestudio.org/" is supposed to be a unique vendor ID, and the rest of the TZID is up the the vendor. Then that TZID uniquely identifies a specific VTIMEZONE component, and any uses of that TZID must refer to that *exact* VTIMEZONE component. Damon Steve Mansour wrote: > > we'd love to have one. I keep hearing rumors that it's an easy thing to do. It > would be great if someone would step up and do it. > -Steve > > svangasse@meetingmaker.com wrote: > > > I've been looking through the calsch threads on the possibility of using some > > kind of globally defined TZID in a VTIMEZONE. Where does the group currently > > stand on this issue? Are we waiting for the tz registry to be set up? > > > > Steve Vangasse > > Software Engineer > > meetingmaker > > http://www.meetingmaker.com From owner-ietf-calendar@mail.imc.org Wed Jun 27 00:01:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06701 for <calsch-archive@odin.ietf.org>; Wed, 27 Jun 2001 00:01:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5R3lQj05432 for ietf-calendar-bks; Tue, 26 Jun 2001 20:47:26 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5R3lPm05428 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 20:47:25 -0700 (PDT) Received: from ximian.com (IDENT:damon@[141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id XAA24395; Tue, 26 Jun 2001 23:47:23 -0400 Message-ID: <3B3957D0.24D28A74@ximian.com> Date: Tue, 26 Jun 2001 23:49:36 -0400 From: Damon Chaplin <damon@ximian.com> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Stracke <francis@ecal.com> CC: "ietf-calendar@imc.org" <ietf-calendar@imc.org> Subject: Re: are blank lines allowed? References: <3B37EB83.14FC077A@ximian.com> <3B389C06.2257196@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit John Stracke wrote: > While I kind of like the idea of being able to insert blank lines for > readability, I think it's too late; we don't want to start sending iCalendar that > existing implementations can't accept. OK. I've updated the vzic converter and VTIMEZONE files. They're at: http://primates.ximian.com/~damon/icalendar/ In case anyone is interested, I ran some tests against mktime. It stepped though the years 1995-2010, every 15 minutes, converting from UTC to local time and back again. Once using mktime/localtime, and once using the functions I have written for libical, which use the above VTIMEZONE data. In roughly 320 out of 350 timezones the output matched. From checking a few of the differences I think that in a further 15-20 timezones the differences are due to changes to the Olson database (i.e. the timezone data in my glibc is a bit out-of-date). But I think there are probably 1 or 2 bugs still to find, which are causing problems in the final 15-20 zones. These bugs may be in the VTIMEZONE files, or they may be in my timezone code for libical. Let me know if you spot any errors. Damon From owner-ietf-calendar@mail.imc.org Wed Jun 27 00:43:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24931 for <calsch-archive@odin.ietf.org>; Wed, 27 Jun 2001 00:43:20 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5R4RGI05984 for ietf-calendar-bks; Tue, 26 Jun 2001 21:27:16 -0700 (PDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5R4RFm05980 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 21:27:15 -0700 (PDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f5R4RBY01170 for <ietf-calendar@imc.org>; Tue, 26 Jun 2001 21:27:11 -0700 (PDT) Received: from netscape.com ([198.93.95.109]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GFKN1C00.18Y; Tue, 26 Jun 2001 21:27:13 -0700 Message-ID: <3B3960B7.CFE05D51@netscape.com> Date: Tue, 26 Jun 2001 21:27:35 -0700 From: sman@netscape.com (Steve Mansour) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Damon Chaplin <damon@ximian.com> CC: svangasse@meetingmaker.com, ietf-calendar@imc.org Subject: Re: global tzid? References: <85256A76.005490AE.00@lnsmtp.on.com> <3B375A88.FA7A87C4@netscape.com> <3B395081.ADE3E36@ximian.com> Content-Type: multipart/mixed; boundary="------------F6CC07D4DDFDE4D0D019405A" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. --------------F6CC07D4DDFDE4D0D019405A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit will softwarestudio.org also be the timezone authority, publish the "standard" timezones, and keep them up-to-date? -Steve Damon Chaplin wrote: > I thought we'd agreed on using a vendor ID to guarantee uniqueness > of the TZIDs. In libical (and hence Evolution) we use TZIDs like this: > > TZID:/softwarestudio.org/Olson_20010601_1/Africa/Dakar > > The "/softwarestudio.org/" is supposed to be a unique vendor ID, and the > rest of the TZID is up the the vendor. > > Then that TZID uniquely identifies a specific VTIMEZONE component, and > any uses of that TZID must refer to that *exact* VTIMEZONE component. > > Damon > > Steve Mansour wrote: > > > > we'd love to have one. I keep hearing rumors that it's an easy thing to do. It > > would be great if someone would step up and do it. > > -Steve > > > > svangasse@meetingmaker.com wrote: > > > > > I've been looking through the calsch threads on the possibility of using some > > > kind of globally defined TZID in a VTIMEZONE. Where does the group currently > > > stand on this issue? Are we waiting for the tz registry to be set up? > > > > > > Steve Vangasse > > > Software Engineer > > > meetingmaker > > > http://www.meetingmaker.com --------------F6CC07D4DDFDE4D0D019405A Content-Type: text/x-vcard; charset=us-ascii; name="sman.vcf" Content-Description: Card for Steve Mansour Content-Disposition: attachment; filename="sman.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Mansour;Steve tel;fax:408-276-4930 tel;work:408-276-4268 x-mozilla-html:FALSE org:Netscape version:2.1 email;internet:sman@netscape.com title:Judge, Jury, and Executioner adr;quoted-printable:;;501 East Middlefield Road=0D=0AMS: MV-054;Mountain View;CA;94043; x-mozilla-cpt:;-10552 fn:Steve Mansour end:vcard --------------F6CC07D4DDFDE4D0D019405A-- From owner-ietf-calendar@mail.imc.org Thu Jun 28 16:59:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16707 for <calsch-archive@odin.ietf.org>; Thu, 28 Jun 2001 16:59:50 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5SKdx225652 for ietf-calendar-bks; Thu, 28 Jun 2001 13:39:59 -0700 (PDT) Received: from trna.ximian.com (trna.ximian.com [141.154.95.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SKdwm25648 for <ietf-calendar@imc.org>; Thu, 28 Jun 2001 13:39:58 -0700 (PDT) Received: from ximian.com (IDENT:damon@karuna.ximian.com [141.154.95.114]) by trna.ximian.com (8.9.3/8.9.3) with ESMTP id QAA28078; Thu, 28 Jun 2001 16:39:48 -0400 Message-ID: <3B3B9692.DA8090D5@ximian.com> Date: Thu, 28 Jun 2001 16:41:54 -0400 From: Damon Chaplin <damon@ximian.com> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Mansour <sman@netscape.com> CC: svangasse@meetingmaker.com, ietf-calendar@imc.org Subject: Re: global tzid? References: <85256A76.005490AE.00@lnsmtp.on.com> <3B375A88.FA7A87C4@netscape.com> <3B395081.ADE3E36@ximian.com> <3B3960B7.CFE05D51@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> Content-Transfer-Encoding: 7bit You want to have a standard set of VTIMEZONE data? (Based on the Olson timezone data, I assume.) I'd be happy if my VTIMEZONE convertor (at http://primates.ximian.com/~damon/icalendar/) became the basis of this. In which case we could change the Vendor ID to /ietf.org/ Damon Steve Mansour wrote: > > will softwarestudio.org also be the timezone authority, publish the "standard" > timezones, and keep them up-to-date? > -Steve > > Damon Chaplin wrote: > > > I thought we'd agreed on using a vendor ID to guarantee uniqueness > > of the TZIDs. In libical (and hence Evolution) we use TZIDs like this: > > > > TZID:/softwarestudio.org/Olson_20010601_1/Africa/Dakar > > > > The "/softwarestudio.org/" is supposed to be a unique vendor ID, and the > > rest of the TZID is up the the vendor. > > > > Then that TZID uniquely identifies a specific VTIMEZONE component, and > > any uses of that TZID must refer to that *exact* VTIMEZONE component. > > > > Damon > > > > Steve Mansour wrote: > > > > > > we'd love to have one. I keep hearing rumors that it's an easy thing to do. It > > > would be great if someone would step up and do it. > > > -Steve > > > > > > svangasse@meetingmaker.com wrote: > > > > > > > I've been looking through the calsch threads on the possibility of using some > > > > kind of globally defined TZID in a VTIMEZONE. Where does the group currently > > > > stand on this issue? Are we waiting for the tz registry to be set up? > > > > > > > > Steve Vangasse > > > > Software Engineer > > > > meetingmaker > > > > http://www.meetingmaker.com From owner-ietf-calendar@mail.imc.org Thu Jun 28 21:02:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21238 for <calsch-archive@odin.ietf.org>; Thu, 28 Jun 2001 21:02:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5T0kdx01910 for ietf-calendar-bks; Thu, 28 Jun 2001 17:46:39 -0700 (PDT) Received: from agony.busboom.org (dt010n57.san.rr.com [204.210.12.87]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5T0kcm01906 for <ietf-calendar@imc.org>; Thu, 28 Jun 2001 17:46:38 -0700 (PDT) Received: from localhost (eric@localhost) by agony.busboom.org (8.11.2/8.11.2) with ESMTP id f5T0kHA13395; Thu, 28 Jun 2001 17:46:17 -0700 X-Authentication-Warning: agony.busboom.org: eric owned process doing -bs Date: Thu, 28 Jun 2001 17:46:17 -0700 (PDT) From: Eric Busboom <eric@softwarestudio.org> X-X-Sender: <eric@agony.busboom.org> To: Steve Mansour <sman@netscape.com> cc: Damon Chaplin <damon@ximian.com>, <svangasse@meetingmaker.com>, <ietf-calendar@imc.org> Subject: Re: global tzid? In-Reply-To: <3B3960B7.CFE05D51@netscape.com> Message-ID: <Pine.LNX.4.33.0106281742020.3645-100000@agony.busboom.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/> List-ID: <ietf-calendar.imc.org> List-Unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe> On Tue, 26 Jun 2001, Steve Mansour wrote: > will softwarestudio.org also be the timezone authority, publish the "standard" > timezones, and keep them up-to-date? The proposal that Damon is refering to is that the SOLIDUS indicates that the sender of the component guarantees that the TZID refers on only one VTIMEZONE data. The proposal is in the message: http://www.imc.org/ietf-calendar/mail-archive/msg01655.html If the sender uses TZIDs that come from a database that includes the vendor's name in the TZID, then the vendor is the authority for its own TZIDS. That is, in Damon's example, softwarestudio.org is the authority only for TZIDs that begin with /softwarestudio.org/. Other implementations should play nice and not create Timezone databases with TZIDs that begin with /softwarestudio.org/ eric.