Subject: iptel and iCalendar

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Feb 2001 03:48:27 -0500

Folks,

Let me introduce myself - my name is Jonathan Rosenberg and I'm the chair of
the iptel group. We're the group which has generated the CPL specification:

http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-04.txt

which makes use of iCalendar. 

As Patrik has mentioned, the draft is currently blocked within IESG until
this group gives its OK that the usage of iCalendar is reasonable. I saw
from the list notes a bunch of comments on this subject. I'll address some
of them now. I've asked the CPL author, Jonathan Lennox, to also join the
list to make additional comments, as he defined the subset and also built a
running implementation.

So:

1. The issue was raised as to why iptel didn't talk to calsch at the time
they decided to use the specification. Well, there is no good reason for it;
it was an error on my part, and I apologize. Groups often use rfc's from
other groups in their own work without consulting that group, especially for
mature documents. I should have contacted calsch as soon as the group began
to consider the implementation of a subset. In our own defense, we did elect
to use rfc2445 as opposed to something completely different. In fact, the
original cpl draft used a crontab style time definition. There were several
implementations built around it. We decided to move to rfc2445, breaking
backwards compatibility, in order to be consistent with other IETF efforts -
namely yours. Therefore, please do not interpret our usage of a subset as an
attempt to be purposefully incompatible. Rather, we wanted to be compatible
but had certain constraints that needed to be addressed.

2. Another issue was raised regarding syntax. I saw two proposals; one of
which was to use more deeply nested XML tags to contain things like the
byday value, rather than use attributes, and another was to use the actual
syntax defined in rfc2445 (please correct me if I misrepresent the
statements made). The first proposal doesn't work at all for us. The CPL
syntax has a very specific structure, and the use of nested tags has a CPL
specific meaning that prevents us from using them to do other things. Usage
of the existing syntax within an attribute would work, but requires
additional code for both the XML and recurrence parsing. We didn't see
syntax compatibility as a real issue, so we opted to represent the exact
same data, but in a format which was easiest for us.

3. The reason we selected a subset was based on the really important
property of an O(1) computation to determine if the current time is within a
recurrence. Since these computations happen in real time for call setups, we
have both processing and latency constraints. There was also the concern
about implementation complexity. The algorithm in the document was the
maximal subset we could discover which was still computable in O(1) time.
The pieces we needed to eliminate didn't seem like they would be commonly
used at all, and so we were happy that we achieved our goal with something
with would cover most, if not all, real usage cases. What I'd love to hear
more about from this group is how we could meet our constraint of O(1) time
and not have to implement a subset.

More to come,

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: John Stracke <[email-masked]>
Date: Mon, 12 Feb 2001 11:39:50 -0500

Jonathan Rosenberg wrote:

> mature documents.

Sure.  Meanwhile, on our part, we didn't realize that we should be watching out
for Drafts that referenced iCalendar, until Patrik mentioned it.

> Therefore, please do not interpret our usage of a subset as an
> attempt to be purposefully incompatible.

Sure.  Your approach makes sense for your needs; the only serious concern is
where you say, "This allows CPLs to be generated automatically from calendar
books."

> property of an O(1) computation to determine if the current time is within a

Yeah, that makes sense.  However, it seems to me that there may be calendaring
applications which want a simpler recurrence system, too.  I have *never* used
a calendar whose recurrence rules were as complex as iCalendar's--and, in fact,
I hope I never do; the UI would be horrendous.  Most iCalendar implementations
are going to have UIs that support only subsets of the iCalendar recurrence
rules, which is a good way to run into interop problems, since they'll support
different subsets.  So, if you send me an event that uses recurrence syntax my
UI doesn't handle, my CUA may *understand* the full syntax, and expand the
recurrence set correctly; but I won't be able to see and understand the rule,
or modify it (if I want to COUNTER).

I, for one, would be interested in working up a simplified subset for
general-purpose use, which would be easier for users to work with.  If it
turned out to be implementable in O(1) time, that would solve both our
problems.

As for the XML representation--maybe we can resurrect the old iCalendar-in-XML
draft.  I opposed it at the time, because having two syntaxes for the same data
model gets messy; but it's becoming clear that we need to be able to embed
iCalendar data in other people's XML.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |When rats leave a sinking ship, where exactly do|
[email-masked]|they think they're going?                       |
\=================================================================/

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 12 Feb 2001 16:31:54 -0500 (EST)

On Monday, February 12 2001, "John Stracke" wrote to "[email-masked],
[email-masked]":

> > they decided to use the specification. Well, there is no good reason for
> > it; it was an error on my part, and I apologize. Groups often use rfc's
> > from other groups in their own work without consulting that group,
> > especially for mature documents.
> 
> Sure.  Meanwhile, on our part, we didn't realize that we should be watching
> out for Drafts that referenced iCalendar, until Patrik mentioned it.

As the primary person behind the use of iCalendar in CPL, I'll take
responsibility for this too.  I've asked some questions about iCalendar use
here, but never explicitly expliained to the group what I was doing.

> Yeah, that makes sense.  However, it seems to me that there may be
> calendaring applications which want a simpler recurrence system, too.  I
> have *never* used a calendar whose recurrence rules were as complex as
> iCalendar's--and, in fact, I hope I never do; the UI would be horrendous.
> Most iCalendar implementations are going to have UIs that support only
> subsets of the iCalendar recurrence rules, which is a good way to run into
> interop problems, since they'll support different subsets.  So, if you
> send me an event that uses recurrence syntax my UI doesn't handle, my CUA
> may *understand* the full syntax, and expand the recurrence set correctly;
> but I won't be able to see and understand the rule, or modify it (if I
> want to COUNTER).

The phrase "can be generated automatically from calendar books" is indeed
somewhat glib -- no, you can't generate a general CPL script from a general
iCalendar template without an O(n) (I believe) space blow-up in the number
of rules.  I'm pretty sure, though, that the the iCalendar subset we use in
CPL does indeed contain the rules that would be generated by any of the
actual calendaring UIs you describe.  (I explored a number of them in the
process of working out a subset; I can send these results to this list if it
would be helpeful.)  The one exception is 'count', but 'count' and 'until'
are pretty trivially transformable to one another if you're willing to
enumerate.

In particular, I find it somewhat hard to imagine a UI that could
sucessfully describe the general case of 'bysetpos'.  Maybe this is a
failure of imagination on my part, though.

> turned out to be implementable in O(1) time, that would solve both our

Yes, I agree,  Indeed, I suspect that CPL's iCalendar superset may indeed
still be too *big* for reasonable UI representation, though this could still
be a matter of debate.

> As for the XML representation--maybe we can resurrect the old
> iCalendar-in-XML draft.  I opposed it at the time, because having two
> syntaxes for the same data model gets messy; but it's becoming clear that
> we need to be able to embed iCalendar data in other people's XML.

As Jonathan Rosenberg mentioned in his initial mail, CPL maps a fairly
strong semantic structure onto XML's nesting model, so the way you'd want to
do iCalendar-in-XML in the general case probably doesn't match very well
with how you'd want to do iCalendar-RRULEs-in-CPL.  On the question of
whether a generic iCalendar-in-XML would be useful, I'm agnostic.

When I designed the iCalendar-RRULEs-in-CPL syntax, though, I tried to keep
the syntax transformations as simple as possible.  Thus, a rule with a rule
part like:
        RRULE;BYMONTHDAY=5,17,23
is transformed into a CPL node with a parameter expressed as an XML
attribute:
        <time bymonthday="5,17,23">

This transformation doesn't easily generalize to allow a representation of
all of iCalendar, mostly because it doesn't allow for nesting.  However, for
what it's trying to do, I think it accomplishes it pretty
straightforwardly.

I'll comment on the motivations and justifications for CPL's RRULE subset in
a follow-up message (I think this message is getting too long as-is).

Thanks for you help with this!

-- 
Jonathan Lennox
[email-masked]

---

From: John Stracke <[email-masked]>
Date: Mon, 12 Feb 2001 16:51:31 -0500

Jonathan Lennox wrote:

> The one exception is 'count', but 'count' and 'until'

Right--and a UI that has the user specify "until" is probably easier to work with
than one that has the user specify "count".

> with how you'd want to do iCalendar-RRULEs-in-CPL.

Yeah...yeah, iCalendar in XML would probably be nicer if it didn't have to
conform to those restrictions.  But, really, that's a side issue; syntax is easy
to translate.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |For an engineer, paranoia is not an affliction;|
[email-masked]|it's a tool.                                   |
\================================================================/

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 12 Feb 2001 18:39:56 -0500 (EST)

> a follow-up message (I think this message is getting too long as-is).

As promised.

CPL's subset of RRULE is motivated by a single requirement: we need to be
able to tell, in O(1) time, whether a given instant falls within some
repetition of an RRULE.

At first, I thought I was going to have to give up a whole lot of RRULE to
satisfy this requirement, but I managed to come up with an algorithm
(Appendix A of the CPL spec draft-ietf-iptel-cpl-04) which satisfies it
while including *almost* all of RRULE.  There were only four restrictions: 

* We don't use COUNT 
* We don't use BYSETPOS
* Durations are limited to less than 24 hours
* We eliminated the FREQ rule parts and the BY* rule parts less than a day.

The first two of these are rules that (as near as I can tell) can't be
resolved without a full enumeration of the recurrence set.  I'd certainly
welcome any comments which correct me on this, though!

Of these two, the elimination of COUNT is significantly less of a semantic
loss.  It's largely interchangeable with UNTIL in semantics, and it's a lot
easier to write both code and user interfaces for UNTIL.

Basically, converting a recurrence which uses COUNT to a recurrence which
uses UNTIL is an off-line one-time cost of O(count). I was going to impose
this cost on the iCalendar-to-CPL conversion tool, but if interoperability
meant that the cost was imposed on a CPL server instead, I don't think it'd
be a huge problem.  (It'd mean that conversions back from CPL to iCalendar
wouldn't lose information.)

BYSETPOS is a lot more of a semantic loss, since there's no way (as far as I
can tell) to encode its semantics into other RRULE rule parts.  For at least
some BYSETPOS rules, you can transform them into a set of non-BYSETPOS-using
RRULE and EXRULE rules, but I'm not sure if this is possible in the general
case.  (CPL doesn't actually use EXRULE, but its first-match semantics for
time switches are effectively equivalent.  I'm using the iCalendar
terminology for this discussion to try to keep things clear for this mailing
list.)

I haven't studied this transformation very thoroughly, though -- I'm not
sure it's always possible, and at any rate a single BYSETPOS-using
recurrence will I believe have to be transformed into O(setsize)
non-BYSETPOS-using recurrences.  I feel this is probably the weakest point
of the subset right now; reactions are welcome.  I'd be a lot more concerned
about this fact if I thought that BYSETPOS were going to show up in its full
generality in actual calendaring rules, though.

The third and fourth restrictions are related.  The "Appendix A" algorithm I
worked out is actually O(d/i), where 'd' is the duration of the recurrence,
and 'i' is the "minimum interval" -- the smallest unit of FREQ or BY* in the
rule.  That is to say, in the algorithm, a six-week duration with a
BYMONTHDAY rule would have to iterate through the algorithm approximately 42
times.

To guarantee the O(1) requirement, we have to constrain 'd' to be less than
'i'.  I could have just imposed this as a specific requirement in the CPL
specification, but that seemed likely to be a user-interface
nightmare. Instead, I just gave a simple rule: 'd' must be less than a day,
and 'i' must be greater than or equal to a day.  This seems to reflect the
actual UI restrictions most calendaring programs impose.

There are, as I see it, five possible alternatives to this solution:
* Move the limit between d and i.  There's no obvious other position for it,
  though. 
* Make the d < i restriction explicit in the code.  Like I said, probably
  a user interface and documentation nightmare.
* Allow the full RRULE set of FREQ and BY* values, but let individual CPL
  servers reject CPL scripts with a d-over-i value higher than they're
  willing to support.  This will probably result in interoperability
  nightmares.
* Impose a maximum d-over-i value (greater than 1) in the CPL specification.
  This means we still lose full iCalendar compatibility, but not as badly.
* Come up with a cleverer algorithm which is still O(1) regardless of the
  value of d-over-i.  This is obviously the best solution. :-)

There are other reasons that I wanted to restrict intervals less than a day,
the primary one of which is that it's somewhat hard to resolve in O(1) time
the rule 'FREQ=MINUTELY;INTERVAL=734;BYDAY=TU' in a local timezone, when it
might cross a DST boundary an arbitrary number of times between DTSTART and
the current time.  I think this could probably be solved, or at least
finessed, however.

I'd certainly prefer to be able to incorporate all of iCalendar's RRULE spec
into CPL, so if people have ideas as to how we could improve our algorithm
so as to increase interoperability, I'd be all for it -- that's probably the
best solution all around.  Failing that, though, there needs to be a
reasonable set of compromises between the expressive power of RRULE and the
demand for an O(1) algorithm to resolve it.  I feel that CPL made these
reasonable compromises, but if this list/working group feels that different
compromises are appropriate I'm certainly open to them.

-- 
Jonathan Lennox
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 25 Feb 2001 13:15:45 -0800

It would be good if this can be resolved, so we can put CPL to bed.

I see the questions are two important ones:

(1) Recurrence rules in IPTEL and iCalendar aren't compatible.

I feel this is not a good thing for the community. This 
incompatibility will most certainly lead to problems when CPL is 
deployed. Yes, I see the arguments about O(1) from the IPTEL pepople, 
but my view is that this is not worth the problems we get with the 
incompatibility, and that the CPL draft should allow the full 
iCalendar spec for recurrance rules.

Further, the following text in the draft:

         This allows CPLs to be generated automatically from
         calendar books. It also allows us to re-use the extensive
         existing work specifying time intervals.

...is not true. It must be replaced _IF_ the rules will still be 
incompatible to explain the incompatibility issues.

(2) Recurrence rules in IPTEL can be specified in local time without 
a time zone (what is called floating times) and this can lead to 
unexpected behavior

Example on where this can lead to a surprising behaviour is if you 
have an event which starts at 1AM, and has a duration of 4 hours. If 
this is "local time", the duration will probably be only 3 hours 
once, and 5 hours once a year -- because local time change timezone 
twice a year. If you want an event between 1AM and 5AM and explicitly 
the behaviour I talk about above, then you should use start and stop 
time. Reason for duration is that the duration should be exactly that 
every time.

More specifically, I see that the lack of timezone is something which 
is a client issue, and one can easilly force the CPL client 
application to always add the timezone to the object. I.e. I see the 
ability to not have timezone is a request for a user to not being 
forced to enter a timezone.

And, how do you map such a "floating event" back into iCalendar 
format when you don't know the timezone?

Basically, I don't feel the two standards should use different 
recurrance rule specifications, and that what one gain with the extra 
restrictions in CPL is not worth it.

Last point, I have not seen anyone in the CALSH wg commenting on the 
needs for O(1) from the CPL people, like "you can do it this way 
instead" or "we don't think that is important" or even "oooops, we 
made a mistake, we have the same requirement and need to update our 
standard".

     paf

At 18.39 -0500 01-02-12, Jonathan Lennox wrote:
>On Monday, February 12 2001, "Jonathan Lennox" wrote to 
>"[email-masked], Jonathan Rosenberg, Henning Schulzrinne, 
>John Stracke" saying:
>

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Mon, 26 Feb 2001 16:48:28 +0100

Well as I originally asked:

1) there are recurrence rules in 2445
2) in iCal these rules are only applied to the VALUE of certain properties
3) even if these rules were observed explicitly
4) would they be compatible when reconstrued as parameters and parameter
values?

Patrik:

     paf

---

From: John Stracke <[email-masked]>
Date: Mon, 26 Feb 2001 10:50:20 -0500

> a time zone (what is called floating times) and this can lead to

Can someone from IPTEL explain why this was needed? It's not clear to me how it
would be useful for CPL scheduling.  For user events, this is sometimes useful ("I
want to be reminded to take my medicine every day at 7 AM, local time, wherever I
am"); but it's not as if the telephony switch is going to migrate from timezone to
timezone.

> made a mistake, we have the same requirement and need to update our

Actually, I think it might be useful for calendaring apps, too.  We generally
expand our recurring rules when the event goes into the database, which results in
lots of DB entries.  This means extra disk space--which is fine; disks are
cheap--but it may also mean extra database CPU time spent hunting through those
tables.

In addition, there's the problem of how to build a comprehensible UI that
represents all the capabilities of iCalendar recurrence rules.  My fear is that
people are going to subset the syntax to make the UI workable, and they'll subset
it *differently*.

I was going to write up a Draft with Jonathan Lennox, proposing a uniform subset
that's O(1) and simple to work with; but I got tied up with other work last week,
and now I've missed the new-draft deadline.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"How quietly do you think we can nail these back|
[email-masked]|in?" --Calvin                                   |
\=================================================================/

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 26 Feb 2001 11:01:29 -0500

> am"); but it's not as if the telephony switch is going to migrate from timezone to

There is a somewhat related problem, as in "I don't want to receive
calls from 11 pm to 6 am, wherever I am (as I'm asleep during that
time)", but the server will have a hard time knowing which time zone
each end system is in, so I doubt that this is useful in practice.

> and now I've missed the new-draft deadline.

To amplify: from all I can tell, nobody has stepped forward and said
"yes, we implement all of the recurrence rules". Thus, consider IPtel
doing CALSCH doing the favor of identifying the features that could be
included when moving to Draft Standard :-). I think it would be really
confusing if IPtel includes all of them, then CALSCH tries to go to
Draft, discovers "oops, there aren't two implementations for much of
this, so we'll have to strike them from the draft". While calendars
generally have a reasonably close association between clients and
servers (i.e., as long as I know what my local server supports, I can
work around limitations), IPtel scripts are more likely to be "far away"
from the user, possibly moving to different servers as I roam between
providers. Having a script that works on one server but triggers a
"sorry, we don't implement this obscure recursion" on another is a
customer support nightmare.

If the CALSCH community feels the need for the non-O(1) features, I
would be much more comfortable with extracting them into an explicitly
labeled extension of some sort. Not ideal, but at least it provides a
binary rather than multi-step interoperability.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: John Stracke <[email-masked]>
Date: Mon, 26 Feb 2001 11:22:03 -0500

> 4) would they be compatible when reconstrued as parameters and parameter

No.  So? The CPL spec already requires syntax translation; and that's fine.
Syntax is easy to translate; it's semantics that we're worrying about.

--
/=================================================================\
|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: "Greg FitzPatrick" <[email-masked]>
Date: Mon, 26 Feb 2001 17:25:48 +0100

this matter is of course of great interest to the SKiCal people since we
have done approximately the same thing as the iptel people.

We have said that; OK these are pretty good recurrence rules, let us reuse
them.

In our case the motivation is that as it stands 2445 can only "recur" one
thing - one meeting, in which all variables are fixed with the exception of
the recurrence dates.

We need to be able to describe the
operating/opening/viable/valid/accessible/what-have-you times of a host of
activities and resources surrounding the event.

ex. the opening of the box office, the times when humans man the phones, hot
food is no longer served, the ferries stop running, this door opens and this
door is locked, last call on votes or reservations or advanced payment, when
you can pick up your social passes and so on.

So we transmigrated the value status of rec-rules in order to be able to
state that:

There is a Property, the value of which is qualified by an
openness-statement.

SOME-PROPERTY;
	 TERM =the date-time validity of openness
		 OPTIME = a time period of openness
			 OPRULES = rules tying the OPTIME values to particular days
				:the SOME-PROPERTY value being qualified

This is how we have notated this in our draft:

2. SKiCal specific property parameters

   The following are  SKiCal property parameters in addition to those
   defined by RFC-2445[3]

2.1 Term

   Parameter Name: TERM

   Purpose: This parameter is used to qualify properties using date and
   date-time values as defined in RFC 2445 - 4.3.4 Date and 4.3.5
   Date-Time . Term declares a datetime period during which a set of
   access rules will be valid.

   Format Definition: The property parameter is defined by the
   following notation:
         termparam  = "term" "=" (date-time / date) "/" ((date-time / date)
/ ( "THISANDPRIOR" / "THISANDFUTURE))

   Description: Facilitates date-time values as qualifiers for
   auxiliary features of a SKiSource. The  TERM parameter indicates a
   period for the property it is qualifying .  This period might be
   constructed by two date-time values separated by a "/" or one
   date-time value separated by a "/" from one of two value types;
   THISANDPRIOR and THISANDFUTURE.  By the use of THISANDPRIOR the
   date-time value is used to signify the end of a TERM whose start
   time is either not relevant or unknown.  By the use of THISANDFUTURE
   the date-time value is used to signify the start of a TERM whose
   conclusion is either not relevant or unknown.

   Example:
BOOKINGS;TERM=20010313T140000Z/THISANDFUTURE:Tickets2go

BOOKINGS;TERM=20001128T143000Z/THISANDFUTURE:Ticketmaster

BOOKINGS;TERMSTART=20001128T120000Z/20001201:Biljett Direkt

BOOKINGS;TERM=20011214T190000Z/THISANDPRIOR:The front Box-Office

BOOKINGS;TERM=20011104/20011214:The front Box-Office

2.2

2.3 Opening Times

   Parameter Name: OPTIME

   Purpose: This parameter is used to qualify properties using time
   values as defined in RFC 2445 - 4.3.12 Time.   OPTIME declares a
   period of time when a set of access rules will  be valid.

   Format Definition: The property parameter is defined by the
   following notation:
    optimeparam  = "OPTIME" "=" (period-explicit / period-start)
period-explicit = time "/" time period-start = time "/" dur-value

   Description:  Facilitates time values as qualifiers for particular
   aspects of a SKiSource.  The OPTIME parameter indicates a period of
   time when the property value is accessible or in a state of being
   "open" .  If the property permits, multiple "period" values are
   specified by a COMMA character (US-ASCII decimal 44) separated list.
   There are two forms of a period of time. First, a period    of time
   is identified by its start and its end. This format is    expressed
   as the [ISO 8601] complete representation, basic format for
   "TIME" start of the period, followed by a SOLIDUS character (US-
   ASCII decimal 47), followed by the "TIME" of the end of the
   period.

   If the start of the period is of a greater value than the end of the
   period, 24 hours will be added to the end value in order to
   calculate the correct time period (so called "Midnight crossing").

  For example 180000Z/030000Z would be calculated as starting at 18:00:00
UTC and ending at 03:00:00  	UTC on
   the following day.     A period of time can also be defined by a
   start time and a positive duration of time. The format is expressed
   as the [ISO 8601]    complete representation, basic format for the
   "TIME" start of    the period, followed by a SOLIDUS character
   (US-ASCII decimal 47),    followed by the [ISO 8601] basic format
   for "DURATION" of the period.

     Example: The period starting at
   18:00:00 UTC and    ending at 23:30:00 UTC  would be:
   180000Z/2330000Z     which is the equivalent to 180000Z/PT5H30M.
   The later method is the preferred syntax for OPTIME since it allows
   the declarations of times exceeding 24 hours.

   Examples:

BOOKINGS;TERM=20011214/THISANDPRIOR;OPTIME=130000Z/170000Z:The front Box
Office

RESOURCES;OPTIME=120000Z/220000Z:Hot food
RECOMMENDED;OPTIME=130000Z/150000Z,220000Z/230000Z:Avoid the crowds for good
seats

LOCATION;OPTIME=110000Z/023000Z:Palais de Congrès

2.4 Opening Time Rules

   Parameter Name: OPRULES

   Purpose: This parameter is used to qualify properties by the "BYxxx"
   values as defined in RFC 2445 - 4.3.10 Recurrence Rule.   OPRULES
   define the recurrence rules for  when a particular set of Opening
   Times  will  be valid.

   Format Definition: The property parameter is defined by the
   following notation:
         oprulesparam  =  (";" "BYDAY" "=" bywdaylist )          /
( ";" "BYMONTHDAY" "=" bymodaylist )    /                 ( ";" "BYYEARDAY"
"=" byyrdaylist )

   Description:  Facilitates time values as qualifiers for particular
   aspects of a SKiSource.  The OPRULES parameter works similarly to
   the Recurrence rules of RFC 2445 4.3.10 with the following
   distinctions. Frequency is limited to DAYS. The COUNT and UNTIL
   rules are not used. Multiple "recur" values are not allowed.    With
   this limited set of rules the vast majority of "Opening Times" can
   be stated.  For more complicated sets, implementers are advised to
   use the Recurrence Rules of RFC 2445.  Since most SKiSources and
   their auxiliary resources, probably have 2 or three "DAY" schedules
   it is permissible to repeat property declarations when permissible
   under RFC 2445.

    Examples:

RESOURCES;BYDAY=MO,WE,FR;OPTIME=120000/220000:The Astoria Bar

RESOURCES;BYDAY=TU,TH;OPTIME=160000/240000:The Astoria Bar

BOOKINGS;TERM=20011214/THISANDPRIOR;OPTIME=130000Z/170000Z;BYDAY=MO,TU,WE,TH
,FR:The front Box-Office

REQUIRED;OPTIME=180000Z/020000Z;BYDAY=SA:Evening Dress

RECOMMENDED;BYMONTHDAY=24:Avoid using our ATMs on national paydays

LOCATION;BYYEARDAY=1:Pasadena Rose Bowl

---

From: John Stracke <[email-masked]>
Date: Mon, 26 Feb 2001 11:31:02 -0500

> each end system is in, so I doubt that this is useful in practice.

And this effect can be obtained with regular time zones anyway.  If you're not in your
home time zone, and you want to receive calls while you're awake, you're probably going
to need to forward calls to wherever you are (unless you forward to your cellphone--in
which case you can turn it off at night).  When you set up that forwarding, you could
give it a rule such as "except from 11PM to 6AM in this time zone".

> this, so we'll have to strike them from the draft".

Ouch.  Yeah, good point; I'd forgotten that every option has to meet the "two
independent implementations" requirement, not just the spec as a whole.  (RFC-2026,
4.1.2.)

> binary rather than multi-step interoperability.

It's a possibility.  I'll start by writing up the subset in iCalendar terms, and we can
figure out what to do with the definition once we have it.

---

From: John Stracke <[email-masked]>
Date: Mon, 26 Feb 2001 11:34:34 -0500

> thing - one meeting, in which all variables are fixed with the exception of

Sounds to me like a cleaner solution would be to create a subcomponent inside the
VEVENT (or an associated VEVENT, or something) that describes the recurrence of some
other characteristic.  Then you can reuse the RRULE, EXRULE, etc. properties by
reference, without having to worry about copy-and-paste problems.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |For the life of me, I've never understood why   |
[email-masked]|people dismiss the importance of "semantics" in |
|                |communication. After all, if semantics had no   |
|                |purpleness, you'd slitheringly go bold at by-sit|
|                |it I'm climbing. -- Tangwystyl                  |
\=================================================================/

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 26 Feb 2001 11:32:41 -0500

> give it a rule such as "except from 11PM to 6AM in this time zone".

It's a little bit easier and more complicated. With SIP phones, I can
plug one (in the form of an iPaq, to cite a real-life example) into a
hotel Ethernet jack or 802.11 network and it automatically rings for my
calls, modulo what my CPL script says. No explicit forwarding is needed.
Unplugging it at night is not an option, since I want to still receive
emergency calls from my wife, say.