Recurrence rule clarification

RFC 2446 Quickie

Re: Recurrence rule clarification

On Thu, 1 Jun 2000 Bruce_Kahn <at> iris.com wrote:

> In banging my head against the monitor trying to totally absorb the 
> nuances of a full recurrence rule engine and parsing I think I ran across 
> a slight discrepancy in the description of the recurrence rule data type. 

Ah... it is good to know that I am not suffering alone...

>   The first line says that multiple recurrence rules on a single property 
> that takes this data type can be separated by commas.  However this would 
> be totally unparsable hence we put in that last line.  Just how 

Well, it isn't unparsable, but it is not pretty. My code that splits
values based on commas has a special case for recur: it is a value
separating comma only if it is followed by "FREQ." Since "FREQ" must be
the first thing in a rrule ( contrary to some RFC2446 examples ) this
should always work. 

But, this is a is horribly ugly hack. I'd like to second Bruce's request
to make RECUR values take only one value.

eric. 

Max # of occurences in a recur rule?

RFC2445 says that BYSETPOS can select from only 366 occurences in an
interval. This seems sensible, since any recurrence rule that had more
than 366 occurences per interval could be re-written to have less. Can an
implementation assume that there will be no more 366 occurences per
interval and reject any rule that has more?

Implementing recurrence rules gets difficult when you have to handle the
most general case, since some of these cases get excessive. For instance: 

	RRULE:FREQ=YEARLY; BYYEARDAY=1,2,3,4,...,364,365,366;
	 BYHOUR=0,...,23;BYMINUTE=0,...59;BYSECOND=0,...,59;
	 BYSETPOS=1,100,-100,-1

This rule selects 4 out of 31 million occurences, and the use of SETPOS is
an abuse of the original intent.  Handling it without resource exhaustion
or excessive run times requires an extraordinary programmer or an ugly
special case.

Can an implementation reject a strictly conforming but logically
insensible rrule? Or can we make un-normalized RRULEs non-conforming? I
think we need to reduce some of the unlimited possibilites of the
recurrence grammar to be able to write conforming, efficient and
bug-free code.

eric. 

Re: Poll: How should this "recur" value be handled

On Thu, 1 Jun 2000 Bruce_Kahn <at> iris.com wrote:

> The case in particular I am thinking of is what is the prescribed
> behaviour of a CUA to a recurrence value that is 'discontiguous' when
> evaluated.  For example:
> 
> DTSTART:20000601T040000Z
> DTEND:20000601T043000Z
> RRULE:FREQ=DAILY,INTERVAL=1,BYMONTH=1,BYYEARDAY=10,200;COUNT=10
> 
> The BYMONTH sets the selection range to "all days in January" and then the 
> BYYEARDAY part specifies the  10th and 200th day of the year.  The former 
> is in January but the latter is not.

There is a similar ambigulty between some interval frequencies and BYxxx
parts. 

RFC2445 indicates that based on the frequency (FREQ) the BYxxx parts can
expand or contract the occurence set. Many of these relationships are
clear, but some are not. RFC 4.3.10 gives some good examples of the clear
cases. 

But, how do the BYxxx parts expand or contract the followig recurrence
intervals?

FREQ=WEEKLY: BYMONTHDAY, BYYEARDAY
FREQ=MONTHLY: BYYEARDAY, BYWEEKNO

I am guessing that for the WEEKLY case, both are contracting, and for the
MONTHLY case, both are expanding. But, we need to make sure other
developers make the same guess.

eric. 

Re: Recurrence rule clarification

Re: Max # of occurences in a recur rule?

CALSCH Action Items

This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar <at> imc.org or to myself
mailto:Doug.Royer <at> Software.COM .

There are three parts to this action list:

	(W) Working group action items.
	(C) CAP editor action items.
	(I) iCalendar action items (Frank Dawson)

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

			Working Group Action Items   

Where Resolution is one of:

	U - undecided.
	Y - Chair determined consensus is in favor of the proposal.
	N - Chair determined consensus is NOT in favor of the proposal.
	D - Dropped. Chair has decided that it may never reach consensus.

 The following are a list of proposals and their status in the WG:

 WG Action Item					Resolution
 --------------					----------

 W-1 CAP Use HTTP as transport			N

 W-2 CAP If all booked and scheduled		Y
     appointments are in same table

 W-3 CAP Use SASL as authentication method	Y

 W-4 Add UID and COUNTER to VFREEBUSY		N 

 W-5 CAP Should CAPABILITY reply be sent	N
     as result of successful AUTHENTICATE
     and IDENTITY 

 W-6 Do we need to handle 'unscheduled
     event' as described by the SKI project?	N
     (In CAP - 'N', SKI to be a seperate
      project/draft as it will effect
      RFC2445,6,7)

 W-7 CAP Auto-logout Timer issues		
      Do we need one?				Y
      How long?					<variable>
      Can the server decide not to do this?	Y

 W-8 CAP Bounded Latency Issues			D
     <there were issues - I can't remember
     them>

 W-9 CAP MOVE method. Issues with VCARs.	Y
     [see note in CAP 7.2.1.5]

 W-10 CAP Text mandatory in all response	N
      codes

 W-11 CAP Text optional in response codes	Y
      (some response codes may have 
       mandatory data that follows)

 W-12 CAP Should parts of response code be	Y
      separated by ';'

 W-13 CAP Store Schema				Y

 W-14 CAP VEVENT Schema				Y

 W-15 CAP VTODO Schema				Y

 W-16 CAP VJOURNAL Schema			Y

 W-17 CAP VCAR Schema				Y

 W-18 CAP UPN definition, including anonymous	Y
      user and how UPN's are used in LDAP and
      certificates.

 W-19 CAP Group definitions, dynamic and	Y
      static and how groups are used in VCARs.
      Policy definitions, in a VCAR format.

 W-20 Associating UPN values with CREATED	N
      and LAST-MODIFIED properties.

 W-21 CAP Get/Set calendar user properties	N

 W-22 VTIMEZONE and IANA			Y in process

 W-23 CAP Calendar property to allow/disallow	N
      overlapped booking OPAQUE entries?

 W-24 CAP Calendar CHARSET property issues	Y

 W-25 Remove MUST from UID in 4.8.4.7		Y

 W-26 Write/Submit information draft/rfc	Y

 W-27 How a query can specify if the recurrence	Y
      rules are to be expanded by the CS.

 W-28 Cal-Props - PATH				N
      (CAP-00 - 12.2)
      Will there need to be one?		N
      Optional?					N

 W-29 Import/Export				Y - sync only

 W-30 Transport protocol name (transport vs	Y
      application layer)

 W-31 NOOP command?				Y

 W-32 NOOP advisory only?			Y

 W-33 Should DISCONNECT be called QUIT?		U

 W-34 Format following error codes. Are		Y
      they well defined? If not they
      need to be machine determinable. 

 W-35 Move DNS and SLP to seperate draft?	Y

------------------------------------------------------------------------------

 The following are a list of action items for the CAP draft editors:

 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------
	
 C-1 Remove unused definitions				N

 C-2 Fix up changes in authentication		Alex	N
     text as commented on the list		Paul

 C-3 Text for 2.7 [Finding CAP Servers]		Doug	N

 C-4 VCAR examples				Doug?	N

 C-5 PUBLISH text

 C-6 REQUEST text

 C-7 REPLY text

 C-8 ADD text

 C-9 CANCEL text 

 C-10 REFRESH text

 C-11 COUNTER text

 C-12 DECLINECOUNTER Text

 C-13 Post CAP-00.txt					Y

 C-14 Redo state diagram to include STARTTLS
      and IDENTIFY command.

 C-15 Document the 'CALMASTER' calendar property

 C-16 (2.11)  Query Schema

	I'll send this out next week.

 C-17 (7.2.1.5) MOVE Method

	More text needed - Who?

 C-18 (12.1) Calendar Store Properties

	Editors note. (Per W-27)

 C-19 (12.2) SCHEDULABLE-HOURS

	Format? Text needs to be written.

 C-20 (13.) Security Considerations

	See editors note - more text.

 
------------------------------------------------------------------------------

 The following are a list of action items for the iCalendar-2 draft:

 
 Draft Action Item				Who	Done (Y/N)
 -----------------				---	----------

 I-1 MIME alternate/related			Frank	?
     MUST be supported.

 I-2 Remove ordering of properties and		Frank	?
     parameters in draft.

 I-3 S/MIME and RFC1847.			U
     [CAP] 2.2.3

 I-4 Add ALARMID to VALARM ?			Y

------------------------------------------------------------------------------

Updates should be sent to mailto:ietf-calendar <at> imc.org or to myself
mailto:Doug.Royer <at> Software.COM

--------------------------------------------------------------------------
Work: Doug.Royer <at> Software.com              Home    801 Woodside Rd #14-244
      530 E. Montecito St.                 Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541                    Personal Email: Doug <at> Royer.com

Proposed change to RECUR, RFC2445, 4.3.10

To address some of the comments that Bruce Kahn and I have made about
recurrence rules over the last week, I propose the following text changes
to RFC2445. 

Since I was not privy to the original recurrence rule discussions, I don't
have a complete understanding of the complete purpose for the grammar as
it exists today. This proposal is based entirely on implementation
experiences. 

Though the grammar can represent almost any conceivable recurrence
pattern, it can also represent inconceivable patterns. These insensible
patterns are entirely due to the overlaps in ways to specify a specific
day, and the proposed text would make these ambiguous overlaps illegal. 

For instance, BYYEARDAY specifies a day of the year, a day of the week, a
month, and a week number, so it conflicts with many of the other BYxxx
rule parts. We could define a way to merge these rule parts to eliminate
conflicts, but how useful is a rule like "Every year on the 100th day of
the year, when the 100th day is also a Saturday in March"? Weird stuff
like this can be handled with multiple RRULE or EXRULEs. 

eric. 

This proposed text is an addition to RFC2445, section 4.3.10
--------------------------------------------------------------------------

There are two types of BYxxx rules; date BYxxx rule parts that specify
time periods equal to or longer than a day, and time BYxxx rule parts that
specify the time within a day. The day BYxxx rule parts are : BYMONTH,
BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY. The time BYxxx rule parts are
BYHOUR, BYMINUTE, and BYSECOND. BYSETPOS is neither a date rule part nor
a time rule part. 

Not all date BYxxx rule parts can appear simultaneously in a single
recurrence rule. Date BYxxx rule part restrictions are:

  If the BYYEARDAY appears, no other date rule part may appear. 

  BYWEEKNO and BYMONTH rule parts may not both appear. 

Furthermore, not all date rule parts may be used with all recurrence
intervals. 

  For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor BYWEEKNO
  may appear.

  For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor BYYEARDAY
  may appear.

There are no restrictions regarding use of date rule parts and time rule
parts. There are no restrictions with using any combination of time rule
parts

Just a quick update