Subject: RE: queries for unbounded recurring components

From: "Lowde, Chris A" <[email-masked]>
Date: Wed, 27 Oct 1999 14:17:43 -0500

There is a slight problem with the following statement:

Then the server says, "OK, 19970105 is a Sunday; is the day being
asked about a Sunday?".

When it is Sunday in Houston, it could well, and for 6 hours, 5 for 1 week
in April,  will be, Monday in London.  

When the calendar user is traveling and is looking at a calendar that is
housed in TimeZone1, is currently in TimeZone2 and is looking at an event
for a time when they are in TimeZone3 the issue of who is expanding what
becomes non-trivial.  In general it should be done by the server which will
be the only system that will have all the information about the user on
which to base the expansion.

Chris.
?
?????????????????
Christopher A Lowde
Texaco
4800 Fournace Pl.
Bellaire, TX 77401-2324
Tel: +1(713)432-2901
Fax: +1(713)838-4529
mailto:[email-masked]

 -----Original Message-----
From: 	John Stracke [mailto:[email-masked]] 
Sent:	Wednesday, October 27, 1999 11:25
To:	calsch WG
Subject:	Re: queries for unbounded recurring components

"Lisa Lippert (Dusseault) (Platinum)" wrote:

> Generally I agree with John's principle to push things to the
> edges, but I'm not so sure on this one.  The problem is that to
> do a simple query such as "what appointments do I have today?",
> the client has to either rely on the server to do expansion, OR
> the client has to download all appointments today, plus all
> appointments that recur.

Not necessarily; the server may not have to expand the recurring
event in order to find out whether it occurs on a given day.  For
example, if we have:

DTSTART;TZID=US-Eastern:19970105T083000
RECUR:FREQ=WEEKLY

Then the server says, "OK, 19970105 is a Sunday; is the day being
asked about a Sunday?".

> It may be reasonable to limit the amount of expansion the
> server has to do, though.  It could be interesting to allow the
> client to request recurrance expansion for a range of dates,
> and for the server to be able to respond "no".  (Then the
> client just has to download the recurring items).  That
> flexibility on the server allows it to tune for the best
> performance, both CPU and on the wire.

Yeah, but every extra bit of flexibility in the protocol makes
for more cases to test for interop--and it's a combinatorial
problem, not linear.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Time is money, and price is information."   |
[email-masked]|--Russ Nelson                                |
\==============================================================/

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Oct 1999 13:09:12 -0700

> which to base the expansion.

The proposal in CAP is that CUAs ask for times in UTC.
And the server would dish out the correct replies. If the CUA
wishes to know the original timezones, then it MUST ask for TZID
and fetch the approiate VTIMEZONE data from the CS.

So in a sense your are correct. The CS must understand timezones. So
John's email is still correct in that the CS can fetch the data
given the search criteria.

I think the debate is, does a CS:

	1) Only return un-expanded components?
	2) Only return expanded components - with some limit?
	3) Only return components expanded by request. Default un-expanded.
	4) Only return components un-expanded by request. Default expanded.

If we get concensus on one of these, then the issue is how do we ask?

I would like to see a poll with responses:

	1-YES, 1-NO, 1-ABSTAIN
	2-YES, 2-NO, 2-ABSTAIN
	3-YES, 3-NO, 3-ABSTAIN
	4-YES, 4-NO, 4-ABSTAIN

And of cource any examples on how to ask the CS given the CAP ~language~.

I would say:

	1-NO, 2-NO, 3-YES, 4-NO

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Oct 1999 14:07:48 -0700

> and fetch the approiate VTIMEZONE data from the CS.

As Bruce pointed out to me in email, TZID is in DTSTART - oops.

So a CUA must ask for DTSTART and/or DTEND to get the TZID.

---

From: John Stracke <[email-masked]>
Date: Sat, 30 Oct 1999 11:08:27 -0400

>         4) Only return components un-expanded by request. Default expanded.

1, Yes; others, No.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Chris is the most self-effacing guy I know."|
[email-masked]|"Well, I'm not *that* good at it."           |
\==============================================================/