Subject: Re: RECAP & Questions of CPL RECUR Issues.

From: [email-masked]
Date: Wed, 16 May 2001 15:06:34 -0400

Eric wrote:
>                (2) Because the RRULEs are so complex, and because there 
are many
>                different ways to specify a single set of occurrences, it 
will be very
>                difficult for a CUA to create a GUI that can manipulate 
any arbitrary
>                incoming RRULEs.

So far, none of the proposed ipTel changes I've seen simplify or resolve 
this.  I also do not think that there is any real 'fix' for this as it may 
not really be a problem.  Since RRULEs are 'compounded' to generate the 
the final recurrence set (ignoring other relevant stuff to keep this 
simple) then is it really a problem if I specify:

     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH

(from p119 of 2445) or

     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TH

Not really.  The UI/GUI will have to decompose both into "Weekly on Tuesday and Thursday for 5 weeks" when it presents it to me (or at least present it as "Weekly on Tuesday for 5 weeks" and "And 
also weekly on Thursday for 5 weeks" if it cannot 'merge' them textually).  The changes proposed by iptel do not address this need really.  They may 
reduce the available set of subcomponents that may be split (ie: no more 
BYHOUR, BYMINUTE, BYSECOND) but this does not really address (2).

>The proposed solutions are:
>
>                (1) Remove COUNT

This is a feature that at least 3 CUAs implemented and actively use in 
their UIs. Its a typical C&S feature that CUs use and have come to expect 
so its hard to justify why it should go away in my mind.  iptel justified 
this with:

        iCal also defines a count parameter, which allows an
        alternate method of specifying a bound to a recurrence.
        This bound has been removed from CPL. Translating from full
        iCal recurrences to CPL recurrences requires that the count
        parameter be converted to an until parameter, which can be
        done by enumerating the recurrence and determining its
        final date.

The bit about translating works for when the set is presented in a UI or 
when mapiuplations on the set are necessary (ie: rescheduling ranges, etc) 
but this wont work for storage.  There is a very fundamental difference 
between rolling it out at creating time into an UNTIL date-time and 
keeping it as a COUNT.  The former case 'fixes' the end and there is 
absolutely no way that a CUA can distinguish it from an UNTIL that was 
actually specified at creation or a COUNT that was munged. 

As such, when the set gets moved (ie: John's "change all my Monday entrys 
to Tuesday" elsewhere in the thread) then the CUA has no way to know if 
the set should shrink or if it should stay the same size.  That is to say, 
if I move my 1st DTSTART from 01-Jan-01 to 05-Feb-01 then how can the CUA 
know if the set should still end at 31-Dec-01 or 04-Feb-02 unless it knows 
if the UNTIL was 'hard' or if it was generated based on a COUNT value that 
is no longer known??  Its not possible.

COUNT is a feature that nearly all CUAs Ive used have and implement so it 
cannot simply be removed from the spec.  This sounds like something the 
iptel engines could do as part of their preprocessing work on each rule 
though though.  I assume some preprocessing is done to check for 
'non-supported' subcomponent values in recurrence rules, etc since this 
filtering is not described in Appendix A of the iptel draft.

Also, feature removal of already demonstrated interop features is not good 
is it??

>                 (2) Remove BYSETPOS

This feature is actively used by at least 1 shipping CUA (Outlook) and 
supported by 2 others (Organizer and Notes).  Again, feature removal is 
not good if folks rely on it.  While all of vendors besides Microsoft may 
dream of making killer CUAs (or killer C&S based apps), we all realize 
that we need (if not want) to interoperate with Outlook.  This is a good 
step _away_ from that in a very big way. 

>                (3) Remove byrules and frequencies for hour, minute and 
second.

This has a very negative impact on schemas that may want (or really need) 
to have 'subday' recurrence.  Real world examples include: Admin case (ie 
"Change the backup tape in the system every 90 minutes or 2 times a day"), 
Tourism (ie: "The Boston Harbor tour boats leave at 9AM and again at 1PM 
every day, no matter the weather"), Entertainment (ie: "The movie Star 
Wars: Episode II shows every 30 minutes 24 hours a day during opening 
week", "David Copperfield has a matinee and an evening show on Sunday", "Life in the ER is on at 7PM EST and again at 11PM on The Discovery 
Channel on Sunday").   The list of actual uses is not that short.

For iptels needs though these components may not be that useful (or at 
least the BYMINUTE and BYSECOND easily).  This does not make them 
unnecessary for other applications where scheduling is involved.  So is 
their need reason to remove these useful (even necessary?) subcomponents?? 

Perhaps the approach needs to be taken is one of identifying subcomponents 
that are logical to the usage and ruling out those that are not. 
iCalendar/iTIP defined a mechanism for the recieving CUA to communicate 
back to the sender "I did not grok your BYSETPOS of the RRULE:... but I 
accept the rest" or "Your RRULE:... is illogical so I did not use it", 
etc.  Check out section 3.6 Status Replies of iTIP for a more concrete listing.  I did not see this kind of 
mechanism in ipTel; perhaps adding one is in order to facilitate future 
expansion of ipTel as systems get faster and O(n) becomes larger so more 
values are allowable...

>                 (4) Limit the duration of an event to less than 24 hours.

It may be logical to think that a phone call may not go > 24 hours but I 
can see lots of other events/tasks that are longer than that in duration. 
Lets see, Lotusphere 2001, DevCon, E3, Quake 3 "Frag Fests" kinds of 
events come to mind.  Hey, so does IETF.  Guess we cant use iCalendar to 
publish "IETF" this summer...

For the iptel world it may be logical but I profess some confusion as to 
the practical uses of iptel from just reading the draft.  If this is an 
attempt to avoid overlapping entries if the repeat interval is DAILY then 
why not allow > 1 day durations if the interval is, say, WEEKLY??  Since 
it seems everyone agrees with Erics:

>                                                       (3)
>and (4) are proposed to disallow a RRULE from generating any two
>occurrences that overlap.

so this then this would argue again for a mechanism in iptel to communcate 
back (to the user or to some system somewhere?) that "Hey, entries cannot 
overlap" instead of trying to hide the problem by making recurrence never 
be able to be subday and having the duration max of 1 day. 

As systems get faster then the amount of processing that can be done in 
the fixed time O(n) increases.  This means that future iptel 
implementations could conceivably be able to implement the full recurrence 
grammar at some point in the not too distant future.

I am very rusty in my set theory and other relevant math topics but it 
appears to me that as the repeat instance dates get farther from DTSTART 
that the time required to evaluate becomes longer since there are more 
intervening instances to iterate over.  I did not notice this increasing 
time impact being factored into the O(n) discussion.  Was it and I just 
missed it??

I am VERY skittish of making changes like removing subcomponents just because the 
current processing ability of some implementations may not be able to 
handle very complex constructs w/a given time constraint.  If this were a 
good motivation then software would never have progressed to its current 
state from, say, 10 years ago.  I can empathize with those trying to solve 
the problem but simply cutting stuff out that is not convenient is not the 
way to go.

Have the iptel folks looked at the REQUEST-STATUS mechanism that we put in 
to partially solve this problem?  We build the REQUEST-STATUS property to 
allow 'weaker' or "less robust" CUAs to easily communicate with "more 
robust" CUAs that can do more.  As time rolls on, the less robust folks 
will be able to improve their abilities and the problem will go away 
(hopefully).  At least we put in place a mechanism to convey this kind of 
communication so that as implementations got more robust and faster they 
were still able to function with older ones w/o causing serious 
incompatabilities or growth restrictions.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
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: Alan Davies <[email-masked]>
Date: Wed, 16 May 2001 18:27:15 -0400

>is no longer known??  Its not possible.

I'm not sure that storage, or the way that a CUA adjusts one property
when another changes, are concerns we need to worry about. But you're
right that there is a subtle semantic difference between COUNT and UNTIL
that may be useful. All we're trying to lay out is a data format,
and if it is useful to differentiate between these two concepts then
they should stay in.

>week", "David Copperfield has a matinee and an evening show on Sunday", 
>"Life in the ER is on at 7PM EST and again at 11PM on The Discovery 

Many of these could be expressed in other ways, such as multiple recurrence 
rules,
e.g. one for "Life in the ER is at 7pm EST", and one for "11PM on The 
Discovery Channel
on Sunday". I agree that the sub-day recurrences might be useful in some 
situations
though.

>be able to be subday and having the duration max of 1 day.

Testing for overlapping entries might not always be that easy,
for example when there are multiple infinitely repeating
rules.

>time impact being factored into the O(n) discussion.  Was it and I just 

The algorithm proposed didn't need to expand the set of occurrences,
it just tested whether the date-time intersected the rule, but it
was only O(n) if there was only one candidate occurrence, hence the
non-overlapping restriction.

>incompatabilities or growth restrictions.

Something like that seems pretty sensible solution- CPL could just
'refuse' overly-complex events, as could any CUA.

--Alan

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 16 May 2001 18:08:40 -0500

A few quick observations.

If CPL is proposing an algorithm that tests "whether the date-time
intersected the rule" this implies that given a large set of RRULES - ALL
rules must be tested at ALL points in time... this seems potentially very
complex vs. evaluating out the RRULES and testing against a set that
contains all occurrences for ALL objects (for the given calendar) - which
should be a very manageable test.

I.E. - are they really proposing that for every point in time that their
software needs to "do" something, it checks (and evaluates) ALL RRULES on
ALL objects in the calendar(s) present for the software and then do
something based on those events?

In developing my company's software we are evaluating RRULES when the enter
our server to get to a set of occurrences - subsequently we check against
this set for occurrences that overlap the period of time that we need to
evaluate for. For some types of RRULES (i.e. rules with no end boundary) we
will periodically re-evaluate the rules (but will evaluate them past the
boundaries of most of our client's interest ranges i.e. few clients are
looking 10+ years forward) so this is less critical. To handle changes to an
RRULE we grab the previous set of occurrence, reevaluate the RRULE, and
adjust the occurrence set accordingly - so if Monday becomes Tuesday the
Monday occurrences are removed, and the Tuesday occurrences are added. (note
we are not implementing scheduling functions fully so we only have a few
workflow issues with this - in a full scheduling environment this would
potentially trigger some additional workflow related exchanges of data)

This means that I can evaluate complex RRULES since I occur the cost of
evaluation rarely - i.e. just upon the calendar object containing the RRULE
being added to a calendar in my system - subsequently I will be using a set
of occurrences vs. checking all objects for RRULES and then evaluating all
RRULES every time I need to get the events for a given period of time (for
example events for TODAY or "now").

Hope this helps - it seems that the standards and supporting documentation
are very vague and unclear about many underlying assumptions - for instance
in this case - when RRULES will be expanded and how systems will deal with
real world issues of large sets of calendar objects.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Alan Davies
Sent: Wednesday, May 16, 2001 5:27 PM
To: [email-masked]
Subject: Re: RECAP & Questions of CPL RECUR Issues.

--Alan

---

From: John Stracke <[email-masked]>
Date: Thu, 17 May 2001 10:19:07 -0400

[email-masked] wrote:

> Also, feature removal of already demonstrated interop features
> is not good is it??

Again, it is not forbidden.  If we can't get two interoperating
CUAs that support the entire RECUR syntax, we'll have to cut
something.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |A successful tool is one that was used to do |
[email-masked]|something undreamed of by its author.        |
\==============================================================/

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 17 May 2001 11:42:52 -0400 (EDT)

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.

I also suggested two clarifications/recommendations:

* A server (CPL server, calendaring server, whatever) MAY reject any RECUR
  rule on the grounds that it's too "expensive" (complex, whatever).  The
  definition of expense/complexity is implementation-dependent.

* We ought to add text to the recur definition which says that a server
  SHOULD support any RECUR which meets certain constraints.  This allows us
  to guarantee that unconditionally compliant implementations will be
  interoperable.  (The exact nature and values of these constraints can be
  hashed out later.)

Note that this means:
* COUNT is back (but may be subject to the server's complexity rules).
* Sub-day frequencies and BY* rules are back.
* Durations can be any length (subject to the server's complexity rules).

I have (mostly) completed an implementation -- a modification to the Java
code I released late last year -- which implements this RECUR-minus-
BYSETPOS.  It correctly generates all the RECUR examples from 2445 except
the two which use BYSETPOS.

The two complexity constraints I impose in my code are that if a rule has a
COUNT value, it must be fully satisifed before a caller-specified time and a
caller-specified recurrence of the smallest time unit mentioned in the rule;
and the duration of a recurrence must be less than a caller-specified
multiple of the smallest time unit mentioned in the rule.

The running time of my code is linear in the caller-specified bounds.  (The
COUNT bounds are linear once; the duration bound is linear every time the
rule is evaluated.)  In all other respects it's linear in the textual size
of the rule.  It's possible to determine whether a rule exceeds the bounds
at the time a script is submitted to a server.

In the phone conversation, Eric seemed to indicate that he thought that
BYSETPOS was too complex for iCalendar as well.  And of course iCalendar
(2446, yes?) already has the concept of rejecting a calendering object for
being too complex.

What's the feeling of the working group on this proposal?

-- 
Jonathan Lennox
[email-masked]

---

From: John Stracke <[email-masked]>
Date: Thu, 17 May 2001 14:53:43 -0400

Jonathan Lennox wrote:

>   interoperable.

This will be equivalent to cutting some parts of RECUR and allowing for
extensions.  But, really, extensions in the data model are poison; if I
schedule a meeting using extensions, and I can't send that meeting to everyone
I want to be there, then I just can't use the extensions.  Worse, it's going to
be really hard to explain to the user which part of their invitation caused the
problem.

> (2446, yes?) already has the concept of rejecting a calendering object for

Does it? I haven't been able to find such a thing in 2445 or 2446.

CAP might have it, but CAP is special; it's got a real-time channel over which
it can send errors.  That gets harder in iTIP.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"Music is not a noun, it's a verb." --John Perry|
[email-masked]|Barlow                                          |
\=================================================================/

---

From: Eric Busboom <[email-masked]>
Date: Fri, 18 May 2001 10:47:37 -0700 (PDT)

> everything CPL needed with only one change to RECUR:

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.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 18 May 2001 13:31:55 -0500

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Eric Busboom
Sent: Friday, May 18, 2001 12:48 PM
To: Jonathan Lennox; [email-masked]
Cc: [email-masked]
Subject: Can we fix BYSETPOS?

eric.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 18 May 2001 15:18:37 -0500

Eric,

My intention - which was unclear on rereading - was indeed to explicitly
restrict BYSETPOS to Sets of events that were of the type DATEs - I think
that a set of RRULES that do not imply "BYHOUR, BYMINUTE, or BYSECOND" could
be that.

That said, it does raise a related point - why the restriction to +/- 366
days - which implies a formal assumption that the SET of events will not
stretch beyond one year from now. Or is it intended to be combined in some
manner to extend past that?

All in all it does seem unclearly defined and restricted in its current
form.

Shannon

-----Original Message-----
From: Eric Busboom [mailto:[email-masked]]
Sent: Friday, May 18, 2001 3:14 PM
To: Shannon J. Clark
Cc: [email-masked]
Subject: RE: Can we fix BYSETPOS?

> Restrict BYSETPOS to events of value DATE - that is restrict it to events

Do you mean that DTSTART has VALUE=DATE? That would mean that you could
not use BYSETPOS on an event that, for instance, ran from 10:00 to 11:00
every day of the year. Probably not what you intended to exclude.

Or, do you mean that BYSETPOS could not be used in an RRULE that had
BYHOUR, BYMINUTE or BYSECOND? That would work, and it is much easier to
check in constant time. This case might be acceptable if current
implementations are only using BYSETPOS to select days. If so, I like it
more than my (2) and (3), since it makes the use of BYSETPOS for dates
explicit.

eric.

---

From: Eric Busboom <[email-masked]>
Date: Fri, 18 May 2001 13:14:07 -0700 (PDT)

eric.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 18 May 2001 19:21:41 -0400 (EDT)

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?

(This is also an example of where the "expand the set to resolve it"
strategy falls over.  The above rule without BYSETPOS needs to be expanded
to three quadrillion events.  The point-evaluation method, by contrast,
handles it in O(duration) time just like anything else...)

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 18 May 2001 19:09:38 -0400 (EDT)

> fix it so that CPL can use it.

I appreciate trying to fix BYSETPOS.  In doing so, I think the first thing
to do is to actually *understand* BYSETPOS.  I think it's terribly confusing
as it is.

RFC 2445 says about BYSETPOS only:
   The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
   44) separated list of values which corresponds to the nth occurrence
   within the set of events specified by the rule.

However, the concept "set of events specified by the rule" is terribly
vague.

At least one person on this list thought that this meant that you expand the
recurrence rule completely, and then if you have, say, BYSETPOS=3 you take
only the third event from the list, once.  But from the examples that's
clearly not what's intended.

So we have to have some understanding of what the "set repitition interval"
is.  Let's take some examples....

RRULE:FREQ=DAILY;BYMONTH=8;BYSETPOS=6
        (Contracting rules with BYSETPOS)

RRULE:FREQ=YEARLY;INTERVAL=10;BYDAY=TH;BYSETPOS=25
        (Interaction of BYSETPOS and INTERVAL.  Also note that the "least
        common multiple" of YEARLY and BYDAY is 28 years, even disregarding
        the Gregorian adjustment.  Does this make this a 280-year set?)

RRULE:FREQ=WEEKLY;INTERVAL=4;BYMONTH=8;BYSETPOS=2 
        ("Semi-expanding" rules.  I seem to recall something that said these
         were forbidden, but now I can't find it.)

RRULE:FREQ=YEARLY;INTERVAL=10000;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
        (Sets can be arbitrarily large.)

Is there a good algorithm for "given a time, give me the beginning of the
set enclosing this time"?  I don't necessarily mind having to roll through
366 instances to evaluate a rule (though I'm not thrilled about it), but I
*must not* be forced to fully evaluate a rule starting at DTSTART.

Or was the intention that BYSETPOS only makes sense with expanding rules,
and the set interval is always FREQ?  This is a lot more tractable, but
definitely not what the spec currently says.

I think that once we agree on what BYSETPOS means, we can agree on what
should be done with it.  (I'm still in favor of throwing it out.  It's too
confusing.)

-- 
Jonathan Lennox
[email-masked]

---

From: Eric Busboom <[email-masked]>
Date: Sun, 20 May 2001 21:56:52 -0700 (PDT)

> However, the concept "set of events specified by the rule" is terribly

Right. How about this as proposed text, as an addition to 4.3.10,
Recurrence Rule:

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

  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. After the recurrence rule is
  expanded for one week, month or year, occurrences are selected from this
  set according to the positions in the set specified by the elements of
  BYSETPOS. BYSETPOS is applied to each successive week, month or yearly
  interval of the rule to generate the final occurrence set.

  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.

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

The first paragraph clarifies how to use BYSETPOS, and the second limits
it's use to rules that generate no more than one occurrence per day, so an
implementation will never have to expand more than 366 occurrences per
interval.

Jonathan, will this work for CPL? Bruce, is this acceptable for iCalendar?

eric.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 21 May 2001 11:11:51 -0400 (EDT)

> Right. How about this as proposed text, as an addition to 4.3.10,

Hmm.  From a specification point of view, there's one thing I'd add: the
current text that BYSETPOS "MUST only be used in conjunction with another
BYxxx rule part" should be clarified that it MUST only be used in
conjunction with an *expanding* rule 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.

From a CPL point of view, this is inherently bounded in time, so I think
it's okay.  I'm a little nervous about the fact that we're adding more and
more things that push the bound upward, but it's probably okay.

Other than that, I like this re-definition.  I think it clears up all the
pathological BYSETPOS cases.

-- 
Jonathan Lennox
[email-masked]