RE: Can we fix BYSETPOS?

["Shannon J. Clark" <shannon@xxxxxxxxxx>]

Along a similar line, what about the following:

Restrict BYSETPOS to events of value DATE - that is restrict it to events
enumerated by DAY?

Now this does raise the point that it is not exactly clear how to define
this - events currently could have a DTSTART of type DATE (i.e. no TIME
portions) but have a DURATION which include Hours (i.e. an event declared to
start on Monday, May 21st, 2001 - and last for 36 hours.  On the face of it
a not unreasonable type of event - but could also be defined as an event
that STARTS Monday May 20th, 2001 at just after midnight with a duration of
36 hours.

If defined in the first manner a restriction rule using BYSETPOS could be
potentially be ugly (but not impossible to interpret), if defined in my
second manner my suggestion would make the use of BYSETPOS invalid (which I
am not certain it should be).

Just a thought - if it was intended for use when DAYS are enumerated, why
not clearly define and specify that that is the case?

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
shannon@xxxxxxxxxx
www.jigzaw.com

-----Original Message-----
From: owner-ietf-calendar@xxxxxxxxxxxx
[mailto:owner-ietf-calendar@xxxxxxxxxxxx]On Behalf Of Eric Busboom
Sent: Friday, May 18, 2001 12:48 PM
To: Jonathan Lennox; Bruce_Kahn@xxxxxxxx
Cc: ietf-calendar@xxxxxxx
Subject: Can we fix BYSETPOS?


On Thu, 17 May 2001, Jonathan Lennox wrote:

> I thought I'd clarify further my current thoughts on RECUR in CPL.
>
> After my phone conversation with Eric Busboom, we agreed that we could do
> everything CPL needed with only one change to RECUR:
>
> * Drop BYSETPOS.
>

BYSETPOS is problematic for a number of reasons, but there may be a way to
fix it so that CPL can use 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. 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.

So, could CPL use BYSETPOS if we instituted (2) or (3)? Bruce, would you
be happy with (2) or (3)?

eric.