Re: iptel and iCalendar

[Jonathan Lennox <lennox@xxxxxxxxxxxxxxx>]

On Monday, February 12 2001, "John Stracke" wrote to "ietf-calendar@xxxxxxx,
jdrosen@xxxxxxxxxxxxxxx":

> Jonathan Rosenberg wrote:
> 
> > 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.
> 
> 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.

> > 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."
>
> > 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
> 
> 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.

> 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.

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
lennox@xxxxxxxxxxxxxxx