Subject: CALSCH Agenda for IETF 50

From: Bob Mahoney <[email-masked]>
Date: Sat, 10 Mar 2001 07:15:38 -0500

1. Agenda Tweaks		-Bob Mahoney
	The usual bashing

2. IPTEL/CALSCH issues	-John Stracke
	Overview of major issues
	(Will also be covered in WG dinners and such)

3. CAP status	                   -Steve Mansour/George Babics

4. CALSCH.ORG web site	-Bob Mahoney

5. Have we bit off more than we can chew? -Steve Mansour
	Are the sheer size of the documents & scope of effort 
impeding adoption?

6. "Guide to Internet Calendaring" Last Call   -Bob/George

7. RFC updates and status  -TBA

7. Plans for further informal meetings during the week.

8. Adjourn.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 12 Mar 2001 00:15:44 -0600

I probably won't be able to attend the meeting, but wanted to weigh in on
agenda item 5.

My company, JigZaw Inc, is in the process of writing applications that will
make extensive use of the various calendaring standards that this group is
responsible for, in the course of doing this we have had to spend a great
deal of time with the various standards documents. Below are some of my
general observations and conclusions, hopefully these will be useful for the
general discussion in the meeting.

One - the documents were already too long, and every new version of them has
only gotten longer - see the CAP proposed standard for a great example of
this.

Two - while the documents as written serve a useful purpose of having both
human readable and machine parseable sections (the ABNF stuff) - this also
serves to greatly lengthen the documents, and has frequently been a source
of errors cropping up the documentation - where the text and the ABNF
examples differ.

Three - the documents are very erratic about language usage which serves to
confuse the reader - especially around deciding which sections represent
components that are MANDATORY to implement and which are truly OPTIONAL.

Four - the various interlocking documents and standards do not have a clear
sense of the PURPOSE and PLAN behind the various standards and proposed
standards - why do we have multiple proposed standards for realtime/live
interactions with a calendar server (CAP and iRip etc) More fundamentally
there is lacking a clear sense of HOW the various standards will in fact be
deployed.

Five - Most glaringly some of the MAJOR software products on the market seem
to define the use of the iCalendar standard very differently than the
standards documents imply - the case of MS Outlook is what I am citing here.

Six - There is preponderance of sections to the various documents which
address the problem set of Scheduling meetings between individuals - whether
using the same basic calendaring service or whether using multiple vendor's
systems. This is fine - but it is NOT the same problem set as the general
question of the storage and communication of time-related information. My
company's products have nearly nothing at all to do with scheduling of
meetings - all of the sections of the various standards that involve
FREE/BUSY time, attendees, delegates, invitations, organizers, etc are
mostly meaningless in the context of what our applications do. We are
interested in the standards for a standard means of storing and
interchanging complex time-related information - our software harvests this
information from a large variety of sources, stores it, sorts it, and
otherwise manipulates it for our end users - in a fully standards compliant
world I would like to be able to interchange information from my systems to
the systems employed by the various firms for whom we provide services.

So, for my purposes the large sections of the various standards that deal
with scheduling are an impediment for my development purposes.

Seven - there are some sections of various standards that might be best
pulled OUT of the current standards and made into their own standards. This
would simplify the documents considerably, and would also refine reusability
of these elements.

I propose the following - one, the reoccurrence sections - both the simple
and the "full" be pulled OUT and turned into a generalized system for
reoccurrence rules. This would greatly simplify the standards, and would
allow the reoccurrence rules to be applied in a greater variety of means
than currently considered.

Two - The working group strongly consider whether CALENDARING - that is the
STORAGE of time-related information (Events or ToDo's in particular) be
separated in the standards from SCHEDULING - which is the subset of events
that have the characteristics of a business meeting (Organizer, attendees, a
need for Free/Busy checking, locations, delegates, etc.)

Three - The group consider strongly HOW the various standards will in fact
be employed in the "real world" - will they be used to exchange information
about ONE event at a time (ala vCalendar), to exchange complex calendars
(how I thought iCalendar was intended to be used), to allow for
interoperability between scheduling systems?, or to provide a generalized
framework for applications that have to deal with TIME RELATED issues to
handle the storage, electronic definition, and communication of those issues
to other applications? Will we ever in fact address such a server by way of
a cal://URL or will these systems primarily be addressed in a secondary
manner - i.e. hidden by a more common addressing scheme such as HTTP?

Hope this was not too long for people to read through and pick our my
questions, I will be very curious to hear what is decided at the meeting.

thanks,

Shannon Clark
CEO and Founder, JigZaw Inc.
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bob Mahoney
Sent: Saturday, March 10, 2001 6:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: CALSCH Agenda for IETF 50

8. Adjourn.

---

From: John Stracke <[email-masked]>
Date: Mon, 12 Mar 2001 11:10:49 -0500

> of errors cropping up the documentation - where the text and the ABNF

I think part of the problem here is that the ABNF is incomplete; it can't
specify things like "these appear in any order, but no more than one of each",
so such statements get relegated to comments and the text.  Short of definining
a new formal grammar (<cringe>), we don't really have a solution for this.

> why do we have multiple proposed standards for realtime/live
> interactions with a calendar server (CAP and iRip etc)

Um...because we're not done yet? iRIP went by the wayside a couple of years
ago, and then it was realized that CAP could serve the same purpose.  This has
been the case for some time (I remember Steve Mansour pointed it out to me in
Oslo, so that's 20 months ago), and the iRIP drafts have long since expired.

> standards documents imply - the case of MS Outlook is what I am citing here.

Does this surprise you? Everybody has trouble implementing a standard correctly
when it's new (that's why we have Proposed Standard, Draft Standard, and
Standard); if any vendor is going to be an exception, it won't be MS (see the
Halloween Memos for why not).

> address the problem set of Scheduling meetings between individuals

That's because scheduling is where people have the deepest experience; it's the
problem people set out to solve.  If you want a data model that matches what
you're doing, please write up a Draft describing your needs.

> reoccurrence rules.

Very bad idea.  Recurrence rule syntaxes are nasty, twisted little beasties;
the last thing we want to do is grant them more freedom to proliferate.  It is
my opinion that we need to rein in the RRULE syntax, and adopt a subset; but,
even if we wind up supporting both the subset and the current full syntax, I
would not want to use a generic mechanism that would let people add more in the
future.

> questions, I will be very curious to hear what is decided at the meeting.

Nothing is ever decided at IETF meetings.  Decisions get made on the  list, so
as not to exclude anybody; meetings are just for talking things through faster,
so that the people at the meeting can move closer to consensus (or, at least, a
better understanding of their disagreements ;-) and then try to spread that
consensus to the rest of the WG.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I'm on a Mission From God to Save The World from|
[email-masked]|megalomania!                                    |
\=================================================================/

---

From: [email-masked] (Steve Mansour)
Date: Mon, 12 Mar 2001 10:03:18 -0800

Shannon,

Thanks for the feedback.  Comments below

> only gotten longer - see the CAP proposed standard for a great example of

I feel the same. The latest version of CAP (04) has actually gotten shorter than
the previous version. It's still long. What would *really* be helpful is to
suggest how we might further shorten the draft.

> serves to greatly lengthen the documents,

yep.

> and has frequently been a source

yes. Still, I think those examples are really important. However, the ABNF and
the examples should always be consistent. Careful as the editors might be,
errors show up. We can use help in making them consistent.

> components that are MANDATORY to implement and which are truly OPTIONAL.

I agree that having too many "optional" or "should" features lengthens the
document. More important, whether a feature is "must" or "should", if it appears
in the RFC, then we have to spend as much as necessary to get it right. This
takes a lot of time --especially on the should features because there is usually
a long debate about whether it is "should" or "must". If nobody is going to
implement a "should" feature, or if only one or two vendors *might* implement
it, then I would push for removing it altogether from first version of CAP. We
can address the "should" issues in a seperate or follow-on draft.

Let me be clear on this point. I'm not trying to say that many of the "should"
features are not worth pursuing. But we don't need to get to *everything* in the
first version of CAP. The "crawl, walk run" approach is probably a good one for
CAP. The "must" features alone add up to a pretty complicated draft. I'd rather
see us focus on those, and maybe even lose some of the "must" features, in order
to make it easier for vendors to do an implementation. Then follow-up with the
should features in future drafts.

> there is lacking a clear sense of HOW the various standards will in fact be

I think we've done a reasonable job.  Here's the way I see it:

   * iCalendar - data and schema definition
   * iTIP / iMIP - interoperability protocol
   * CAP - calendar client-server protocol

There is no IRIP.   We use iTIP to interact with disjoint systems.  Use CAP to
connect clients to a server within an organization.

Could you articulate where your concern or confusion lies?

> standards documents imply - the case of MS Outlook is what I am citing here.

iPlanet's calendar server does interoperate with Microsoft's Exchange server
through iMIP and to some extent with Lotus. I know that Lotus' calendar product
can interoperate with iPlanet's and Microsoft's products.  It's not perfect,
yet.

Will JigZaw be at the CalConnect?  That's another place to really drive the
point home. The product developers will be there. Test your interactions with
other companies. Point out the problems.

> with scheduling are an impediment for my development purposes.

We just have to be careful here. Of course we want the standards to cover
everything. But this is part of the reason we have the bloat in the documents
that you're concerned with. It's also part of the reason we've been on CAP for a
couple of years, and why it took a few years to get iCalendar to RFC status. If
there's a whole new area we need to cover, CAP and potentially iCalendar will
become bigger. If we come out with the perfect specification, that addresses
every calendaring need, but people don't implement it because it's too much or
too complicated, then we've all lost. It would be great if you could make it to
the Minneapolis meeting to discuss where the shortcomings are and what it would
take to make the standards more relevant for your product. Perhaps there's
another way to go about getting what you need (something other than tying it to
CAP).

 But I do believe we are addressing the needs of many vendors.

> need for Free/Busy checking, locations, delegates, etc.)

much of the CAP document that may have led people to believe that we were
proposing how data should be stored has been pulled from the doc. The intent was
not to tell people how to store the data, it was to provide schema information
for the new components so that we could develop a query capability for the
protocol.  The schema definitions will be moved into iCalendar, which is more
appropriate. But CAP will not specify how implementors store their data.

> to other applications?

this last framework question is a slippery slope. We have our hands full with
just the calendaring and scheduling we're dealing with today. If, as you say,
what we're producing is not relevant to your needs, wouldn't a standard that
addressed them become even bigger and more complicated?  I don't know, I'm just
asking.  I do have some ideas on what we might do to simplify CAP. But even if
those are accepted by the group, we will still have a pretty complex draft.

> Will we ever in fact address such a server by way of

It is certainly my goal to see that cap://bla becomes a common way to access
calendar information. I think everyone in this working group would want this.

> questions, I will be very curious to hear what is decided at the meeting.

Great feedback!   Please don't let everyone else decide. You obviously have some
energy on this. We need more energy in this working group.  Help us.

-Steve

---

From: John Stracke <[email-masked]>
Date: Mon, 12 Mar 2001 13:49:42 -0500

Steve Mansour wrote:

> I feel the same. The latest version of CAP (04) has actually
> gotten shorter than the previous version. It's still long. What
> would *really* be helpful is to suggest how we might further
> shorten the draft.

One approach that might help would be to split it up into
transport and messages: define, say, tiCAP (transport-independent
CAP) as the set of iCalendar messages exchanged and CATP
(Calendar Access Transport Protocol) as the transport protocol
they run over.  Then both documents would be shorter and easier
to read; and we could run tiCAP over other transports.  (For
example, tiCAP over SMS could be useful for CUAs running on
cellphones.)

It'd be a nice bit of orthogonality.  tiCAP would not explicitly
contain any iTIP functionality.  Instead, iTIP running over CATP
would be CRISP; (iTIP+tiCAP) over CATP would be CAP; (iTIP+tiCAP)
over email would be a superset of iMIP; tiCAP over CATP would be
SOGGY.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |This space intentionally not left blank.     |
[email-masked]|                                             |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Mar 2001 15:12:43 -0500

>         (Will also be covered in WG dinners and such)

Attached is the outline of what I'll be covering.  Please let me
know if there's anything unclear, or if you think it's too long,
or something.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"You gotta learn to dance before you learn to|
[email-masked]|crawl!" -- Meatloaf, "Everything Louder than |
|                |Everything Else"                             |
\==============================================================/

IPTEL's use of iCalendar

Why IPTEL uses iCalendar

CPL (Call Processing Language) needs to know which rules apply
when.

In essence, that's a recurring event: this rule applies at
these times.

Rather than invent recurrence rules from scratch, CPL uses a
subset of iCalendar's.

Hope is that a user's CPL rules can be populated from their
calendar: "Don't call me while I'm in meetings".

What the problem is

The full iCalendar RECUR semantics are too much for CPL

CPL has to run in a telephony switch. CPU and memory are
expensive.

CPL has to run in bounded time. BYSETPOS and COUNT cannot be
evaluated in bounded time.

Also, iCalendar can specify a recurring event whose instances
overlap. Nightmare.

So CPL defines a subset of the recurrence rules

Eliminates all sub-day parameters (SECONDLY, MINUTELY,
HOURLY, BYSECOND, BYMINUTE, BYHOUR).

Eliminates BYSETPOS, COUNT.

Restricts DURATION to be less than 24 hours.

Meets CPL's needs, but cannot interoperate

A calendar user can specify recurrences which their IPTEL
switch cannot implement.

If the switch and the CS are connecting behind the scenes,
it will be difficult to give the user a good explanation.

User will wind up believing the switch just doesn't work.

Some users may not encounter the problem. This is worse,
because, sooner or later, they will; and then it'll be a
surprise.

The subset solution

iCalendar's recurrence rules are too much for calendars, too.

Possible to define extremely complex rules. Example:

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.

How can UI express this clearly?

Worse, how can the user edit it?

CUA's RRULE editor will work only on a subset; no other
option.

Different CUAs will use different subsets. Might not test
features outside their subset properly. Interop nightmare.

Suggestion: define a subset.

Pare down the semantics to something manageable.

draft-stracke-calsch-rrule-subset-XX.txt defines subset from
CPL

Might conceivably need to be simplified still more, but this
is a start.

My preference: this subset should become the only set.

When we rev 2445, we should throw out the parts that don't
fit.

Otherwise, we still have interop problems, when a 2445bis CUA
gets an iCalendar from a 2445 CUA.

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Mar 2001 10:16:41 -0500

John Stracke wrote:

* Bob Mahoney wrote:
> Attached is the outline of what I'll be covering.

And here's the (unsubmitted) Draft it mentions.

|eCal Corp.      |I'm not imaginary. I'm ontologically challenged.|

Internet Engineering Task Force                     J. Stracke
INTERNET DRAFT                                            eCal
draft-stracke-calsch-rrule-subset-XX.txt             J. Lennox
                                                Columbia Univ.

                                                 February 2001
                                          Expires: August 2001

                A Simplified Subset of iCalendar RRULEs

1.  Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.  Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other docu-
   ments at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this document is unlimited. Please send comments to
   [email-masked] or to the [email-masked] discussion list
   (subscription address [email-masked]; "SUBSCRIBE" or
   "UNSUBSCRIBE" in the body).

2.  Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

3.  Abstract

   This document sets forth a subset of the RRULE syntax for [iCalen-
   dar].  The problem which motivated this subset is that iCalendar's
   recurring-event rules are extremely complex; it is difficult to eval-
   uate them, and well-nigh impossible to build a usable user interface

Stracke, Lennox                                                 [Page 1]

RRULE Subset                                               December 2000

   to edit them.

4.  Introduction

   [iCalendar]'s recurrence rules are extremely complex.  For example,
   it is possible to 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.

   While it is certainly feasible (though difficult) to write computer
   code which interprets such rules, it is extremely hard to be sure one
   has written this code correctly.  Furthermore, it is probably impos-
   sible to create a user interface which can display (let alone edit)
   these rules in a comprehensible fashion.  (For one thing, note that
   the "not unless it's 13 or 23 seconds after the minute" part con-
   flicts with the "3:15:25 PM" part.  It is, of course, possible to
   write code which examines the rule for such conflicts; but then one
   has to figure out how to explain them to the user.  A proper UI pre-
   vents the user from making mistakes in the first place; and that
   becomes nearly impossible when the mistakes are so hard to explain.)

   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 differ-
   ent subsets, and will not be properly tested for iCalendar objects
   which stray outside those subsets.  Even if they expand those iCalen-
   dar 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 interop-
   erability: even if the underlying iCalendar implementations under-
   stand each other, the users don't.

   Finally, evaluating these rules is highly CPU-intensive.  If one uses
   the COUNT parameter, for example, to state that the event occurs no
   more than 25 times, then, every time the user wishes to see their
   calendar, the CUA (Calendar User Agent) must evaluate that rule up to
   25 times.  This is sort of acceptable when it's just the CUA getting
   involved; but, if the CUA is making a query against a CS (Calendar
   Store) for all the user's events within a given range, that's an

Stracke, Lennox                                                 [Page 2]

RRULE Subset                                               December 2000

   extremely expensive request, computationally, to impose on a server.
   Servers which support such queries will not scale, unless they pre-
   expand their recurring events.  This approach can work, but it has
   its own problems; it is expensive in disk space, and may create so
   many database entries that the database slows down.  (Or, of course,
   it may not; the point is simply that, as things stand, this approach
   is the only viable one; with cheaper evaluation, we have more
   options, more opportunities to find the Right Thing.)

   The iptel working group, in defining their Call Processing Language
   ([CPL]), needed a way of specifying which processing rules apply
   when.  They wanted to reuse the iCalendar specification, but they
   found the cost of evaluating the recurrence rules to be too high to
   perform in a telephony switch.  So, instead, they used a subset of
   iCalendar recurrence rules, in which the switch can answer the ques-
   tion "which rule applies right now?" in O(1) time.  This document
   lays out that subset in iCalendar terms.

5.  Subset Definition

   In this subset, not all of the parameters defined in [iCalendar]'s
   section 4.3.10 (which defines the value type RECUR) are allowed.  The
   allowed parameters are:

      * FREQ
      * INTERVAL
      * UNTIL
      * BYDAY
      * BYMONTHDAY
      * BYYEARDAY
      * BYWEEKNO
      * BYMONTH
      * WKST

      In addition, the FREQ parameter is more restricted than in [iCal-
      endar]; the only legal values are DAILY, WEEKLY, MONTHLY, and
      YEARLY (SECONDLY, MINUTELY, and HOURLY were removed).

      Finally, the event's DURATION must be less than 24 hours.

6.  Subset Motivation

   (This section is non-normative.)

   The COUNT and BYSETPOS parameters have been removed in order to make
   sure that it is possible to evaluate a rule in O(1) time; since COUNT

Stracke, Lennox                                                 [Page 3]

RRULE Subset                                               December 2000

   and BYSETPOS rely on the concept of "Nth instance of the event", they
   require the implementation to loop through and evaluate at least the
   first N instances.  If necessary, similar functionality can be
   obtained via UNTIL and EXDATE or RDATE.

   In addition, limiting FREQ's values and removing BYSECOND, BYMINUTE,
   and BYHOUR makes it impossible to specify an event which recurs more
   often than once per day.  Combined with the restriction that the
   event's duration must be less than 24 hours, this makes sure that no
   two instances of a recurring event can overlap.  Overlapping
   instances would complicate the evaluation algorithm and prevent it
   from being O(1); and, in any case, a user interface would be hard-
   pressed to display an event with overlapping instances in a coherent
   fashion.  It might be possible to come up with some other way of pre-
   venting overlapping instances, but this one is simple to understand
   (both for implementors and for users).

   It is worth pointing out that the O(1) algorithm is not quite con-
   stant time; for example, if the VEVENT contains both an RRULE and an
   EXRULE, evaluation will take twice as long.  If it contains N
   EXDATEs, evaluation will go up by an O(N) factor (the same applies
   for RDATEs, of course).

7.  Conclusions

   The subset specified here is much simpler to work with than the full
   RECUR syntax of [iCalendar], without greatly limiting functionality;
   if we modify iCalendar to be limited to this subset, it ought to be
   easier to achieve full interoperability.  It will also be simpler for
   users to understand, and for implementations to evaluate.

8.  Security Considerations

   This document specifies a subset of [iCalendar], and accordingly
   inherits all of iCalendar's security analysis.  It seems intuitively
   obvious (warning: handwaving ahead) that adopting this subset cannot
   introduce new security risks; that any risk present in this subset is
   also present in the original iCalendar specification.

9.  An Algorithm for Resolving Time Switches

   (This section is non-normative.  It is taken from Appendix A of
   [CPL].)

Stracke, Lennox                                                 [Page 4]

RRULE Subset                                               December 2000

   The following algorithm resolves, in constant time, whether a given
   instant falls within a repetition of a time-switch recurrence. Open-
   source Java code implementing this algorithm is available on the
   world wide web at <http://www.cs.columbia.edu/~lennox/Cal-Code/>.

     1.   Compute the time of the call, in the timezone of the time
          switch.  (No step after this needs to consider time zones --
          all calculations are done using continuously-running standard
          Gregorian time.)

     2.   If the call time is earlier than dtstart, fail NOMATCH.

     3.   If the call time is less than duration after dtstart, succeed
          MATCH.

     4.   Determine the smallest unit specified in a byxxx rule or by
          the freq. Call this the Minimum Unit.  Determine the previous
          instant (before the call time) when all the time units smaller
          than the minimum unit are the same as those of dtstart. (For
          all minimum units, the time-of-day must be the same as
          dtstart. If the minimum unit is a week, the day-of-the-week
          must be the same as dtstart. If the minimum unit is a month,
          the day-of-the-month must be the same as dtstart. If the mini-
          mum unit is a year, the month and day-of-month must both be
          the same as dtstart. (Note that this means it may be necessary
          to roll back more than one minimum unit -- if the minimum unit
          is a month, then some months do not have a 31st (or 30th or
          29th) day; if the minimum unit is a year, then some years do
          not have a February 29th. In the Gregorian calendar, it is
          never necessary to roll back more than two months, or eight
          years (four years between 1904 and 2096).)

          Call this instant the Candidate Start Time.

     5.   If the time between the candidate start time and the call time
          is more than the duration, fail NOMATCH.

     6.   If the candidate start time is later than the until parameter
          of the recurrence, fail NOMATCH.

     7.   Call the unit of the freq parameter of the recurrence the Fre-
          quency Unit.  Determine the frequency unit enclosing the Can-
          didate Start Time, and that enclosing dtstart. Calculate the
          number of frequency units that have passed between these two
          times. If this is not a multiple of the interval parameter,
          fail NOMATCH.

Stracke, Lennox                                                 [Page 5]

RRULE Subset                                               December 2000

     8.   For every byxxx rule, confirm that the candidate start time
          matches one of the options specified by that byxxx rule. If
          not, fail NOMATCH.

     9.   Succeed MATCH.

10.  Authors' Addresses:

   John Stracke
   Chief Scientist
   eCal Corp.
   Email: [email-masked]

   Jonathan Lennox
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   Email: [email-masked]

11.  References

[iCAL] Dawson, Stenerson, "Internet Calendaring and Scheduling Core
Object Specification (iCalendar)", RFC 2445, November 1998.

[CPL] Lennox, Schulzrinne, "CPL: A Language for User Control of Internet
Telephony Services", draft-ietf-iptel-cpl-04.txt, November 2000.  Work
in progress.

Stracke, Lennox                                                 [Page 6]