Subject: Re: CAP and Timezones/Recurrence/Queries

From: Thorsten Laux <[email-masked]>
Date: Fri, 01 Oct 1999 10:56:33 GMT

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

Am 30.09.99, 22:32:40, schrieb Doug Royer <[email-masked]> zum 
Thema Re: CAP and Timezones/Recurrence/Queries:

> [email-masked] wrote:
> >
> > Doug Royer wrote, in part:
> >
> > >This implies that the CUA already knows the UID of an event.
> > >If the query is for a date-time range there does not seem
> > >to be a way to say send me the 'raw' iCalendar data or
> > >'expand' the recurrences for me.
> >
> > The scenarios that I have seen in meetings and hear discussed was a
> > CUA would query for the events within a given date/time window. For
> > example, for a UI of next 5 days, what are the events occurring in
> > this interval. Assuming that the server unzips any recurring events to
> > find events that overlap the window (this is a good assumption or the
> > whole system model is caput), then the return can be forced to be UID,
> > DTSTART, DTEND and RECURRENCE-ID and sorted by UID or even DSTART.
> > With this initial query results you can certainly determine (a) if an
> > event is a recurring one or not and also the UID of the parent.
> >
> > Did you have a different and new scenario in mind?

> Yes.

> How do you (as I understand the original post asked) get the events
> non-un-zipped) as in the raw data?

> Example:

>       The owner of an event wishes to modify an event.
>       The CU does not know the UID, so they would want
>       to fetch say a VEVENT by SUMMARY. They do not want it
>       unzipped, and it would consume bandwidth. The CUA just
>       needs the original VEVENT as PUBLISHed. So it can be
>       modified and sent back to the CS with CAP.

>       If the VEVENT was daily, do you want or need 29-31
>       copies of the event - if you only want to modify it.

>       When the VEVENT is displayed in a calendar, then
>       yes - it needs to be unzipped.

A common example for this is to have all events rendered in list form. 
Since a list opposed to the standard time views enforces no time limit 
on its events you have to resort to showing parents of recurrence 
series to keep the result set limited.

Thorsten

---

From: Thorsten Laux <[email-masked]>
Date: Fri, 01 Oct 1999 10:53:31 GMT

Ursprüngliche Nachricht vom 30.09.99, 19:35:15
Autor: [email-masked]
Thema: Re: CAP and Timezones/Recurrence/Queries

Thorsten Laux wrote, in part: 
>1. From the cap draft I can't seem to figure out, how queries can 
>specify whether they want recurrent events to be returned only once 
>(the start of the series) or once for every occurrence in the queried 
>time span. It hopefully is not the burden of the CUA to calculate all 
>recurrences from the base event!? You would specify a WHERE clause 
either for the UID for the parent, to get the whole recurrence 
definition, the RECURRENCE-ID for a particular recurrence instance, to 
get an individual occurrence, the RECURRENCE-ID and RECTYPE (i.e., 
"THISANDBEFORE" or "THISANDAFTER"), to get a range of recurrences.
>2. How do I specify the timezone of a datetime in a query? I suppose 
>the CUA does not have to readjust its query time span into GMT? 
>Burdening the CUA with timezone calculations means calculating 
>recurrence rules which I don't think is a good idea for CUAs to be 
>forced to. In the same context wouldn't it be a good idea to have the 
>CUA identify its timezone to the CS and then let the CS do all 
>timezone conversions for the client? The CS has to be able to do the 
>conversions anyway since it has (as I suppose) to calculate 
recurrence 
>instances. Why not let it do all conversion work. Having to do this 
in 
>two places is error prone - especially given the vast reservoir of 
>recurrence rules. It is clear of course that the tzid would still 
have 
>to be transmitted since it indicates the timezone, the date is tied 
>to.
Yes, specifying the date/time in terms of UTC (NOTE: GMT is 
deprecated. We all use UTC as the absolute time format) is the way to 
go. The CAP server would need to adjust/translate into absolute time 
of UTC. But good question. This should be noted in the specification. 
Actually, CUAs will have to be able to do time zone conversion for 
many UI displays of data anyway. If you have a date/time in "floating" 
time, you will have to display this in your UI in the local time zone 
of the CUA. In addition, the most common form for specification of 
iCalendar DTSTART and DTEND properties will be UTC based format of 
time. You only need a time zone when a recurring event is specified. 
So, the CUA will have to UTC to local time conversion all the time anyway.
Floating time simply means that no conversion needs to be done 
(neither on CS nor on CUA), doesn't it? The reason I am mentioning the 
timezone issue is that in our product we have been sparing the CUA 
entirely of timezone calculations and this works quite well for us. 
From our view point the data in the vevents container can be viewed 
from different viewpoints. The viewpoint consists of the access rights 
the viewing person is granted, of the timezone, the viewer resides in 
and whether he wants to see recurring events replicated. Thus clients 
and client apis need to know hardly anything about timezones (only if 
they want to schedule events outside their own timezone which is 
hardly ever the case). Isn't the existence of timezones a nasty 
implementation detail of how world time works that should be hidden as 
good as possible from clients? Actually we could leave the choice to 
the client by providing TZ convertion functions in our sql subset:
select tzconv( dtstart, MEZ), tzconv( dtend, MEZ ) where tzconf( 
dtstart, MEZ ) < endtime and tzconf( dtend, MEZ ) > starttime.
This also would allow to query on floating events:
select * where tzconv( dtstart, MEZ ) == dtstart and tzconf( dtstart, 
MEZ+1) == dtstart.
Since greater and lower for datetimes appearantly is supposed to mean 
greater and lower in UTC (since queries have to be formulated in UTC) 
we have no way to query correctly for a range containing floating 
events since they will happily float to their UTC representation 
(Server doesn't know clients timezone). Tzconv() would fix that, too.
As regarding the recurrence problem I would say that for the client 
either all events are held replicated in the server or they are not. If 
they are, I have to include recurrenceID == dtstart to your where clause 
containing the uid to get the parent (and careful! Without recurrence Id 
or time range you have endlessly many events -> illegal query). Having 
the server replicate only if one mentions recurrence ids seems very 
unclear to me. Now if the event that I want to query as parent is in the 
exclusion list of its recurences things get harry again (it is not one 
of its recurrences). It seems to me, that the recurring event container 
and the plain event container although they hold the same data are so 
different when they are accessed that one should use two containers for 
query purposes (for examlple vevent and vrecurringevent).

---

From: [email-masked]
Date: Fri, 1 Oct 1999 14:40:53 -0400

Thorsten:
The iCalendar and iTIP specification is assumed as a model and system base 
for any of the CAP discussions. Certainly, we have extensions to this base 
in CAP, also. Just to re-enforce this here, though.
So...
...Then there are only two ways to specify recurrence instances. One is 
with RRULE and RDATE in the original VEVENT/REQUEST (or PUBLISH). The 
other is with a VEVENT/ADD method that is used to add instances to an 
existing calendar component. Hence, my observation that if you query a CS 
with a CAP query statement that specifies a UID, then in the case of a 
recurring event, this is semantically how you ask for the complete event 
definition. Also, if you ask for an event specifying a  RECURRENCE-ID, 
then you are asking for a recurrence instance.
This seemed implicit, but you are right, we need examples in CAP to 
demonstrate how these various scenarios are played out in actual CAP 
commands. THANKS for pointing this out!
-- Frank

---

From: "Doug Royer" <[email-masked]>
Date: Thu, 30 Sep 1999 11:44:29 -0700

Thorsten Laux wrote:
> recurrences from the base event!?

Your right. In the requirements doc is (our used to be) a requirement
to address this issue. It has not been addressed yet.

Suggestions?

I have added this as issue 'W-27' to the action item list.

> conversions anyway since it has (as I suppose) to calculate recurrence
> instances. Why not let it do all conversion work. Having to do this in
> recurrence rules. It is clear of course that the tzid would still have

The current thoughts were that the CUA would have to be aware of
its own timeline anyway. So if the CUA only queries the CS for time
in GMT then the CUA would not have to download all of the timelines
in the CS in order to make a query.

The CS is going to have to know how to process timelines anyway.
And the CUA is going to have to know its own timeline.

Does this work for you?

-- 
Doug
--------------------------------------------------------------------------
Work: [email-masked]      Home    801 Woodside Rd #14-244
      530 E. Montecito St.         Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541            Personal Email: [email-masked]