Subject: Re: [Ietf-caldav] free-busy query
From: Helge Hess <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Sun, 31 Jul 2005 16:52:03 +0200
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

On 31. Jul 2005, at 16:32 Uhr, Mike Douglass wrote:
> Following the example shown:
>
> REPORT /home/bernard/calendar/ HTTP/1.1
...
> If that's me (mdouglass) trying to get Bernards free time I need  
> his password (or possibly an already running authenticated session)

Why would you need his password? Just access the resource with your  
credentials. The server will allow the operations you have access to  
(as defined in the ACL, eg just freebusy REPORTs).

> - on the other hand something like:
> REPORT /home/mdouglass/calendar/ HTTP/1.1
...
> <C:free-busy-query xmlns:D="DAV:"
>                   xmlns:C="urn:ietf:params:xml:ns:caldav">
> <D:href>http://cal.example.com/home/bernard/calendar/</D:href>
> <C:time-range start="20040902T090000Z"
>                  end="20040902T170000Z"/>
> </C:free-busy-query>

I imagine you are mixing up resource location with authentication.  
The REPORT you are running has nothing to do with the object located  
at "/home/mdouglass/calendar/", its run on "/home/bernard/calendar/".

Your proposal changes nothing wrt permissions. You would still need  
to have (and check) freebusy access to /home/bernard/calendar/ with  
your login/credentials.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Sun, 31 Jul 2005 10:32:27 -0400
From: Mike Douglass <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] free-busy query

Wouldn't it work better to have an href element as part of the query?

Following the example shown:

REPORT /home/bernard/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
  <C:time-range start="20040902T090000Z"
                  end="20040902T170000Z"/>
</C:free-busy-query>

If that's me (mdouglass) trying to get Bernards free time I need his 
password (or possibly an already running authenticated session) - on the 
other hand something like:

REPORT /home/mdouglass/calendar/ HTTP/1.1
Host: cal.example.com
Depth: 1
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<C:free-busy-query xmlns:D="DAV:"
                   xmlns:C="urn:ietf:params:xml:ns:caldav">
 <D:href>http://cal.example.com/home/bernard/calendar/</D:href>
 <C:time-range start="20040902T090000Z"
                  end="20040902T170000Z"/>
</C:free-busy-query>

only requires I have access to his free-busy

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Fri, 29 Jul 2005 12:00:15 -0700
Sender: [email-masked]
From: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] Autoreply: Ietf-caldav Digest, Vol 12, Issue 11

I will be out of the office until 1st August. I will read your mail on my return.

Regards,
Martin.

Date: Thu, 28 Jul 2005 12:00:07 -0700
Sender: [email-masked]
From: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] Autoreply: Ietf-caldav Digest, Vol 12, Issue 10

I will be out of the office until 1st August. I will read your mail on my return.

Regards,
Martin.

Date: Thu, 28 Jul 2005 10:50:22 -0700 (PDT)
From: "G. Barnes" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Some issues with caldav - subscriptions

On Thu, 28 Jul 2005, Mike Douglass wrote:

> I don't think that works too well for something like free-busy. What if our 
> user subscribes to our public "movies" calendar say and wants all of them to 
> count as busy time? (I guess there might be a better example.)

A better example would be a 'Holidays' calendar.  I want every Holiday to
be unschedulable busy time.

Or if I'm a member of the English Department, maybe I don't want any
meetings scheduled that overlap a lecture in the English Department's
Distinguished Lecturer series.

                   Greg Barnes
                   Computing and Communications, University of Washington
                   [email-masked]
                   (206) 685-3295
---------------------------------------------------------------------------

> Also, if we use multiple clients the user has to configure all clients the 
> same way to see the same results. I believe calendar aggregation is a 
> sufficiently useful feature that servers should (also) be doing it and I 
> believe it's also the only way to get a correct free-busy result.
>
> I understand that clients CAN do this and how. I just believe that we should 
> allow servers to do it and make the appropriate accomodation in the protocol.
>
> Cyrus Daboo wrote:
>
>> Hi Mike,
>> 
>> --On July 27, 2005 9:02:58 AM -0400 Mike Douglass <[email-masked]> wrote:
>> 
>>> The result is that those events appear within their view of events,
>>> almost as if they were actually part of the calendar.
>> 
>> 
>> I believe that providing a single view of multiple calendars is a 
>> client-side feature (preference) that is easily implemented with CalDAV by 
>> running reports on each calendar and aggregating the results into one view.
>> 
>>> There's another feature which is that of 'adding' single events from
>>> other calendars into their own calendar. This is actually implemented as
>>> a sort of reference to the real event.
>> 
>> 
>> A CalDAV server could choose to support the proposed WebDAV BIND method as 
>> discussed in 
>> <http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-12.txt> to 
>> support 'adding' single events to other calendars. I don't think we should 
>> require support of that for CalDAV - it ought to be an option that each 
>> implementation can support if it desires.
>> 
>
> -- 
>
> Mike Douglass                           [email-masked]
> Senior Systems Programmer
> Communication & Collaboration Technologies      518 276 6780(voice) 2809
> (fax)
> Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

Date: Thu, 28 Jul 2005 09:05:31 -0400
From: Mike Douglass <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-caldav] Some issues with caldav - subscriptions
Cc: CalDAV DevList <[email-masked]>

I don't think that works too well for something like free-busy. What if 
our user subscribes to our public "movies" calendar say and wants all of 
them to count as busy time? (I guess there might be a better example.)

Also, if we use multiple clients the user has to configure all clients 
the same way to see the same results. I believe calendar aggregation is 
a sufficiently useful feature that servers should (also) be doing it and 
I believe it's also the only way to get a correct free-busy result.

I understand that clients CAN do this and how. I just believe that we 
should allow servers to do it and make the appropriate accomodation in 
the protocol.

Cyrus Daboo wrote:

> Hi Mike,
>
> --On July 27, 2005 9:02:58 AM -0400 Mike Douglass <[email-masked]> wrote:
>
>> The result is that those events appear within their view of events,
>> almost as if they were actually part of the calendar.
>
>
> I believe that providing a single view of multiple calendars is a 
> client-side feature (preference) that is easily implemented with 
> CalDAV by running reports on each calendar and aggregating the results 
> into one view.
>
>> There's another feature which is that of 'adding' single events from
>> other calendars into their own calendar. This is actually implemented as
>> a sort of reference to the real event.
>
>
> A CalDAV server could choose to support the proposed WebDAV BIND 
> method as discussed in 
> <http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-12.txt> to 
> support 'adding' single events to other calendars. I don't think we 
> should require support of that for CalDAV - it ought to be an option 
> that each implementation can support if it desires.
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Wed, 27 Jul 2005 23:18:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Douglass <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Some issues with caldav - subscriptions

Hi Mike,

--On July 27, 2005 9:02:58 AM -0400 Mike Douglass <[email-masked]> wrote:

> The result is that those events appear within their view of events,
> almost as if they were actually part of the calendar.

I believe that providing a single view of multiple calendars is a 
client-side feature (preference) that is easily implemented with CalDAV by 
running reports on each calendar and aggregating the results into one view.

> There's another feature which is that of 'adding' single events from
> other calendars into their own calendar. This is actually implemented as
> a sort of reference to the real event.

A CalDAV server could choose to support the proposed WebDAV BIND method as 
discussed in 
<http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-12.txt> to 
support 'adding' single events to other calendars. I don't think we should 
require support of that for CalDAV - it ought to be an option that each 
implementation can support if it desires.

-- 
Cyrus Daboo

From: Sam Manthorpe <[email-masked]>
Subject: Re: [Ietf-caldav] Some issues with caldav - subscriptions
To: Mike Douglass <[email-masked]>, CalDAV DevList <[email-masked]>
Date: Wed, 27 Jul 2005 18:36:43 -0700 (PDT)

---- Original message ----
>Date: Wed, 27 Jul 2005 09:02:58 -0400
>From: Mike Douglass <[email-masked]>  
>Subject: [Ietf-caldav] Some issues with caldav - subscriptions  
>To: CalDAV DevList <[email-masked]>
>
>Thought I'd raise this:
>
>Our calendar allows a user to subscribe to some other calendar 
>(currently only a public calendar).
>
>The result is that those events appear within their view of events, 
>almost as if they were actually part of the calendar.
>
>There's another feature which is that of 'adding' single events from 
>other calendars into their own calendar. This is actually implemented as 
>a sort of reference to the real event.
>
>There are at least two issues raised by this - one of which probably 
>isn't for this group.
>
>Firstly - is this kind of function available in other calendar systems 
>and if so should it be part of the protocol,

The Mirapoint calendar supports subscribed calendars, both natively
using a prioprietary protocol and publicly using iCal over HTTP
a-la Apple.

Doesn't the CALDAV:calendar-query REPORT satisfy the requirements
for achieving calendar subscription using CalDav?

Regards,
-- Sam
------------------------
Sam Manthorpe, Mirapoint

Date: Wed, 27 Jul 2005 21:15:15 -0400
To: Mike Douglass <[email-masked]>, CalDAV DevList <[email-masked]>
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-caldav] Some issues with caldav - subscriptions

There's no reason that an implementation couldn't store iCalendar objects 
with other properties attached, such as "owner"; the format for iCalendar 
is intended primarily for exchange of objects but nothing says an 
individual implementation can't use X- properties of its own, just that you 
shouldn't count on a different implementation understanding your X- properties.

At 09:02 AM 7/27/2005, Mike Douglass wrote:
>Thought I'd raise this:
>
>Our calendar allows a user to subscribe to some other calendar (currently 
>only a public calendar).
>
>The result is that those events appear within their view of events, almost 
>as if they were actually part of the calendar.
>
>There's another feature which is that of 'adding' single events from other 
>calendars into their own calendar. This is actually implemented as a sort 
>of reference to the real event.
>
>There are at least two issues raised by this - one of which probably isn't 
>for this group.
>
>Firstly - is this kind of function available in other calendar systems and 
>if so should it be part of the protocol,
>
>e.g. subscribe to calendar <uri> and display the results within [new] 
>calendar collection <uri>
>
>Secondly I believe I discovered that icalendar, lacking an owner, makes it 
>difficult to distinguish events owned by the current user and those 
>appearing as a result of subscriptions etc.
>
>--
>
>Mike Douglass                           [email-masked]
>Senior Systems Programmer
>Communication & Collaboration Technologies      518 276 6780(voice) 2809
>(fax)
>Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
>_______________________________________________
>Ietf-caldav mailing list -- [email-masked]
>See http://ietf.webdav.org/caldav/ for more CalDAV resources
>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Tim Hare
Interested Bystander, Non-Inc. 

Date: Wed, 27 Jul 2005 12:00:15 -0700
Sender: [email-masked]
From: [email-masked]
To: [email-masked]
Subject: [Ietf-caldav] Autoreply: Ietf-caldav Digest, Vol 12, Issue 9

I will be out of the office until 1st August. I will read your mail on my return.

Regards,
Martin.

Date: Wed, 27 Jul 2005 09:02:58 -0400
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Some issues with caldav - subscriptions

Thought I'd raise this:

Our calendar allows a user to subscribe to some other calendar 
(currently only a public calendar).

The result is that those events appear within their view of events, 
almost as if they were actually part of the calendar.

There's another feature which is that of 'adding' single events from 
other calendars into their own calendar. This is actually implemented as 
a sort of reference to the real event.

There are at least two issues raised by this - one of which probably 
isn't for this group.

Firstly - is this kind of function available in other calendar systems 
and if so should it be part of the protocol,

e.g. subscribe to calendar <uri> and display the results within [new] 
calendar collection <uri>

Secondly I believe I discovered that icalendar, lacking an owner, makes 
it difficult to distinguish events owned by the current user and those 
appearing as a result of subscriptions etc.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Wed, 27 Jul 2005 08:54:05 -0400
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Some issues with caldav - collections

I'm still concerned about the sentence:

    Calendar collections MUST NOT contain other calendar collections.

and the reason for that. It seems an unnecessary restriction but you may 
have a different view.

In practice it seems it would make life difficult for people wanting to 
rearrange their calendars. If they have a lot of events they want to 
split into two collections, with that restriction in palce they have to 
move all their events somewhere else, create the two calendars then move 
them back.

This doesn't look like the behaviour people will assume they'll get.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

_______________________________________________
Ietf-caldav mailing list -- [email-masked]
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 21 Jul 2005 14:12:42 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Results of the Calconnect Recurrence Questionnaire are available
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Calconnect, the Calendaring and Scheduling Consortium, is happy to
announce the
availability of the Results from the Recurrence Questionnaire which we
conducted in April/May of this year.&nbsp; The results may be found on the
Consortium Website under "Work Products" or directly at <a
 href="http://www.calconnect.org/resultsfromrecurrencequestionnaire.pdf">http://www.calconnect.org/resultsfromrecurrencequestionnaire.pdf</a>.<br>
<br>
The Consortium thanks everyone who offered suggestions and especially
all of those who responded to the questionnaire.&nbsp; We hope that the
information will be of interest to you, and would welcome any feedback
or suggestions; please send to me at the e-mail below and I will ensure
that your comments are received by the Recurrence Technical Committee.<br>
<br>
We also apologize for the length of time it has taken to publish these
results since the cutoff for the questionnaire.&nbsp; We don't expect to
take as long in the future.<br>
<br>
Best regards,<br>
<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

Date: Tue, 19 Jul 2005 20:47:38 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-07.txt]

This is a multi-part message in MIME format.
--------------050302040708030607070506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

We submitted CalDAV draft -07 to the IETF last Sunday.
It is now available at the following URL:

http://www.ietf.org/internet-drafts/draft-dusseault-caldav-07.txt

B.1  Changes in -07

    a.  Various editorial changes.

    b.  Added properties calendar-restrictions and calendar-component-
        restriction-set on calendar collections.

    c.  Added properties calendar-home-URL and calendar-address-set on
        principal resources.

    d.  Removed property calendar-URL on principal resources.

    e.  Added pre- and postconditions to reports.

    f.  Added new XML elements calendar-data-only and limit-recurrent-
        set.

    g.  Modified calendar-data XML element to support the attributes
        content-type and version.

    h.  Reorganised sections 3, 4, 5 & 6 into two sections and re-ordered
        sub-sections.

    i.  Added comment about client not setting a duplicate displayname.

    j.  Removed three CalDAV OPTIONS requests.

    k.  Changed "authenticated user" to "user" in various places.

    l.  Rewrote section on calendar object resource restrictions for
        better clarity.

The draft for the Scheduling Extensions to CalDAV is still available
at the following URL:

http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-00.txt

Cheers,
Bernard

-------- Original Message --------
Subject: I-D ACTION:draft-dusseault-caldav-07.txt
Date: Tue, 19 Jul 2005 15:50:03 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Calendaring Extensions to WebDAV (CalDAV)
	Author(s)	: L. Dusseault, et al.
	Filename	: draft-dusseault-caldav-07.txt
	Pages		: 69
	Date		: 2005-7-19
	
This document specifies a set of methods, headers, message bodies,
    properties, and reports that define calendar access extensions to the
    WebDAV protocol.  The new protocol elements are intended to make
    WebDAV-based calendaring and scheduling an interoperable standard
    that supports single-user calendar access, calendar management,
    calendar sharing, and calendar publishing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-07.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-dusseault-caldav-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-dusseault-caldav-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------050302040708030607070506
Content-Type: Message/External-body;
 name="draft-dusseault-caldav-07.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-dusseault-caldav-07.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------050302040708030607070506--

From: "Kai Pan" <[email-masked]>
To: <[email-masked]>
Date: Mon, 18 Jul 2005 16:23:04 -0700
Subject: [Ietf-caldav] Some questions with respect to the CalDAV specification draft 6

This is a multi-part message in MIME format.

------=_NextPart_000_0079_01C58BB4.F977A870
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_0079_01C58BB4.F977A870
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_0079_01C58BB4.F977A870--

To: "Kervin L. Pierre" <[email-masked]>
Subject: Re: [Ietf-caldav] Truncation of large responses
Date: Fri, 15 Jul 2005 08:17:04 -0700
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Cc: CalDAV DevList <[email-masked]>

Hi Kervin,

I'm not sure the client can really page through calendar data unless full  
time ranges are received.  Paging implies some kind of ordering, possibly  
by date as you suggested, and we're not sure how to order calendar events  
(including recurring events, all-day events).  We might need to have some  
kind of canonical ordering and I'm not sure that would be so efficient for  
servers.

We'd also need some way for the server to indicate whether or not it had  
hit the limit or had found precisely N items coincidental to the limit  
requested.

Lisa

On Thu, 14 Jul 2005 13:14:13 -0700, Kervin L. Pierre <[email-masked]>  
wrote:

>
> Hello,
>
> Lisa Dusseault wrote:>
>> I don't think it's required for CalDAV, however, because we've got the   
>> date-limiting range requests in our reports.
>>
>
> It would be nice, I think, to have a 'max count limit'
> on the "time range report" requests.
>
> eg...
> <C:time-range start="20041121T000000Z"
>                   end="20041121T235959Z" limit="1000"/>
> ...Or something like that.
>
> It would be up the client though to page through the
> result.  This would be simpler now since the client can
> do a new time range report with the date of the last
> result as the start date and keeping the end date the
> same, also again with the max limit.
>
> This is not new functionality, but I think it would
> make the time-range report/queries more convenient to
> use.
>
> Regards,
> Kervin

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Thu, 14 Jul 2005 16:14:13 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Truncation of large responses
Cc: CalDAV DevList <[email-masked]>

Hello,

Lisa Dusseault wrote:>
> I don't think it's required for CalDAV, however, because we've got the  
> date-limiting range requests in our reports.
> 

It would be nice, I think, to have a 'max count limit'
on the "time range report" requests.

eg...
<C:time-range start="20041121T000000Z"
                  end="20041121T235959Z" limit="1000"/>
...Or something like that.

It would be up the client though to page through the
result.  This would be simpler now since the client can
do a new time range report with the date of the last
result as the start date and keeping the end date the
same, also again with the max limit.

This is not new functionality, but I think it would
make the time-range report/queries more convenient to
use.

Regards,
Kervin

To: "Helge Hess" <[email-masked]>, "CalDAV DevList" <[email-masked]>
Subject: Re: [Ietf-caldav] Truncation of large responses
Date: Thu, 14 Jul 2005 11:34:41 -0700
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF

Actually I once worked on an extension, which worked fine, to request a  
"page" of results at a time.  The server knew what was in the collection  
and had some idea of order so you could ask for results 1 to 40, then 41  
to 80 in a separate request.  There was no guarantee that a new item  
wouldn't slip between the cracks, but then this wasn't intended for  
synchronization -- it was intended for browsing.

I don't think it's required for CalDAV, however, because we've got the  
date-limiting range requests in our reports.

Lisa

On Thu, 14 Jul 2005 11:03:00 -0700, Helge Hess  
<[email-masked]> wrote:

> On Jul 14, 2005, at 19:56, Mike Douglass wrote:
>> Should there be some other mechanism e.g. give me a 1000 events  
>> starting at the 3000th?
>
> Such an operation probably wouldn't make a lot of sense due to  
> concurrent access on the collection.
>
> What you can do as a client to reduce transfer sizes is to first query  
> minimal information of all records (eg just the etags) and then use  
> batches to retrieve the actual content in steps.
>
> This would probably be the thing being done by offline oriented clients  
> anyway.
>
> Greets,
>    Helge

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Truncation of large responses
Date: Thu, 14 Jul 2005 20:03:00 +0200
To: CalDAV DevList <[email-masked]>

On Jul 14, 2005, at 19:56, Mike Douglass wrote:
> Should there be some other mechanism e.g. give me a 1000 events 
> starting at the 3000th?

Such an operation probably wouldn't make a lot of sense due to 
concurrent access on the collection.

What you can do as a client to reduce transfer sizes is to first query 
minimal information of all records (eg just the etags) and then use 
batches to retrieve the actual content in steps.

This would probably be the thing being done by offline oriented clients 
anyway.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Thu, 14 Jul 2005 13:56:51 -0400
From: Mike Douglass <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Truncation of large responses

Having watched the server in action (usually a bad thing) it raised the 
issue of (very) large responses.

Our anonymous caldav server gets a request to return all the events. 
Currently I don't limit that response even though there are a lot of 
events. In time there will be more and I will have to do so.

I assume the only fallback a client might have at the moment is to 
request segments of data through the use of date ranges.

Should there be some other mechanism e.g. give me a 1000 events starting 
at the 3000th?

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

From: "Paul B. Hill" <[email-masked]>
To: "'CalDAV DevList'" <[email-masked]>
Date: Tue, 12 Jul 2005 08:00:57 -0400
Subject: [Ietf-caldav] FW: [Sipping] New draft on SIP calendaring

FYI

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Aki Niemi
Sent: Tuesday, July 12, 2005 7:53 AM
To: sipping
Subject: [Sipping] New draft on SIP calendaring

Hi,

I've submitted a first stab at defining event packages for SIP based 
calendaring and scheduling. The purpose is to be able to subscribe to 
remote calendars and schedule meetings with other SIP enabled nodes 
(i.e., define a SIP binding to iTIP).

Comments are welcome. Until the draft appears in the I-D archives, you 
can get a copy at:

http://people.nokia.net/~aki/drafts/draft-niemi-sipping-cal-events-00.txt

Cheers,
Aki

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

Date: Mon, 11 Jul 2005 10:10:11 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] CalConnect Survey on the use of online event calendars
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
This message is being sent to multiple calendaring lists; my apologies
if you receive it more than once.<br>
<br>
<br class="khtml-block-placeholder">
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">CalConnect – The
Calendaring and Scheduling Consortium – is conducting a study on the
use of online event calendars within organizations and the need for
more interoperability between them.</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">The goal of the
survey is to understand the current state of event calendaring: what
types of calendars are in use (web pages, wikis, blogs, emails, etc);
which commercial and open-source solutions are most popular; what
features are most important; and how the calendars are hosted.</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">Your participation
in this survey will require less than 15 minutes of your time and will
help provide the necessary data to complete the study. Thank you in
advance for taking the survey.</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">Click on the
following link to take the survey:  &lt;</span></font><a
 href="http://www.dartmouth.edu/%7Ecalendar/survey_reg.html"><font
 class="Apple-style-span"><span class="Apple-style-span"
 style="font-size: 16px;"><font class="Apple-style-span" color="#0023f9">http://www.dartmouth.edu/~calendar/survey_reg.html</font></span></font></a><font
 class="Apple-style-span"><span class="Apple-style-span"
 style="font-size: 16px;">&gt;</span></font></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
<div style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;">This survey is
sponsored by CalConnect – The Calendaring and Scheduling Consortium – </span></font><a
 href="http://www.calconnect.org/"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"><font
 class="Apple-style-span" color="#0023f9">http://www.calconnect.org</font></span></font></a></div>
<p style="margin: 0px;"><font class="Apple-style-span"><span
 class="Apple-style-span" style="font-size: 16px;"> </span></font></p>
-- <br>
<div class="moz-signature"><b>Dave Thewlis, Executive
Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> · <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

Date: Sat, 02 Jul 2005 10:38:15 -0400
From: "Kervin L. Pierre" <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] Recent Mozilla or other CalDAV client development builds?

Hello,

I am looking for a CalDAV client for
tracing network activity so to make
sure that mine is doing the right
thing.

Heard Mozilla has an advanced client,
but does anyone have recent binaries
of their that client ( is it Sunbird
or Lightning ) with CalDAV support.

If not, are there any other CalDAV
implementations that I can download
and use?  It could be binary since I
just need the network traffic.

Thanks,
Kervin