Subject: Re: [Ietf-caldav] Event creation
From: Lisa Dusseault <[email-masked]>
To: Mike Douglass <[email-masked]>
Cc: [email-masked]
Date: Mon, 28 Mar 2005 18:00:30 -0800
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Hi Mike,

We have had some discussion of this, e.g. in  
http://lists.osafoundation.org/pipermail/ietf-caldav/2005-March/ 
000324.html.   I agree it's harder for servers to do, but it's not that  
much harder -- the server just needs to keep a list of the URLs that it  
assigned based on the client choices, and map those URLs to its  
internal identifiers.  This is one more data table and a tiny fraction  
of the overall data that is stored.

Lisa

On Mar 24, 2005, at 7:03 PM, Mike Douglass wrote:

> First an apology:
> As a late entrant to the caldav world (since calconnect Jan 2005) I've  
> not been a party to the ongoing discussions so forgive me for  
> reopening old discussions. I'll also point out I'm a consumer rather  
> than creator of protocols so please excuse any imprecision on my part.
>
> I am implementing caldav for the UW calendar so I guess I am bringing  
> a server side perspective to things.
>
> Is it possible to agree (or at least accept) that requiring servers to  
> accept any URI they are given will make caldav implementations more  
> difficult than they need be.
>
> I for one believe the POST + 201 approach allowing the server to  
> determine the eventual resource name is a reasonable approach given  
> that the PUT + 201 appears to be doomed.
>
> Even for a simple server implementation, there are reasons why the  
> client supplied name may be unacceptable. If each event is stored in a  
> file the servers file system may disallow the proposed name. For  
> systems which exists already, events are already identified by other  
> schemes, the caldav implementor may be unable to change that so any  
> protocol which forces the server to accept arbitrary names for new  
> events requires implementors to build new mapping schemes just for  
> caldav.
>
> Some of the proposed alternatives involve redirects or maybe an extra  
> trip to the server and there have been suggestions that this may cause  
> efficency or performance problems.
>
> Firstly I'd point out that redirects after a POST are now considered  
> the appropriate way of building applications, they avoid a number of  
> problems and I don't believe many people are worrying too much about  
> response times or performance issues  
> (http://www.theserverside.com/articles/article.tss? 
> l=RedirectAfterPost2 for a discussion)
>
> Second, the client I tried (which doesn't support draft-5) does a PUT  
> followed by a  PROPFIND so already does two trips. Other clients would  
> probably do the same. If the client wants an accurate copy of what the  
> server has created it is probably going to have to retrieve the event.  
> I have to believe calendar servers are not going to store exactly what  
> the client sends, they will add other information and possibly change  
> some - we're not dealing with a file storage mechanism but an  
> information storage system.
>
> I'd suggest that some mechanism which allowed the client to send a  
> representation of a new event followed by a response containing the  
> server view of that new event is likely to be more efficient.
>
> In addition, even if the calendar is on the same machine as the mail  
> servers, human initiated activity is just background noise. We're a  
> small institution but we get in the order of 650,000 pop requests a  
> day on one machine, that doesn't count imap, smtp or all the other  
> rejected connection attempts. 50, 100, 200 people responding to an  
> invitation over a period of time doesn't even register, even if it  
> takes 3 trips.
>
> As for the form of the names, clients presumably already have to  
> accept the URI that a server produces. We already have 1000s of events  
> with a naming scheme, caldav clients will accept those events with  
> those URI's - they have to - they can't rename every event. When a new  
> event is created the name the server chooses has to be acceptable to  
> the client.
>
> In any case, given the stateless nature of caldav/webdav accepting and  
> storing arbitrary URI's involves a db update before we respond - much  
> more of a performance problem than a redirect.
>
> The alternative of a server accepting any URI the client  chooses is a  
> significant implementation problem at the server side. Now when we  
> retrieve events for a given calendar we also have to maintain and  
> search a table to see if some client(s) out there provided us with  
> events and return those names as the URI. We also have to do more  
> complex searches to retrieve events.
>
> It's bad enough if we have access to the server code itself. It will  
> be much worse for those trying to develop a caldav server for a  
> preexisting calendar implementation. Without the ability to tell the  
> client what the new resource is named a caldav implementation requires  
> db tables and a lot of searching. With that ability caldav server  
> implementations can use the existing calendar server with no  
> subsidiary tables.
>
> -- 
>
> 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, 24 Mar 2005 22:03:38 -0500
From: Mike Douglass <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] Event creation

First an apology:
As a late entrant to the caldav world (since calconnect Jan 2005) I've 
not been a party to the ongoing discussions so forgive me for reopening 
old discussions. I'll also point out I'm a consumer rather than creator 
of protocols so please excuse any imprecision on my part.

I am implementing caldav for the UW calendar so I guess I am bringing a 
server side perspective to things.

Is it possible to agree (or at least accept) that requiring servers to 
accept any URI they are given will make caldav implementations more 
difficult than they need be.

I for one believe the POST + 201 approach allowing the server to 
determine the eventual resource name is a reasonable approach given that 
the PUT + 201 appears to be doomed.

Even for a simple server implementation, there are reasons why the 
client supplied name may be unacceptable. If each event is stored in a 
file the servers file system may disallow the proposed name. For systems 
which exists already, events are already identified by other schemes, 
the caldav implementor may be unable to change that so any protocol 
which forces the server to accept arbitrary names for new events 
requires implementors to build new mapping schemes just for caldav.

Some of the proposed alternatives involve redirects or maybe an extra 
trip to the server and there have been suggestions that this may cause 
efficency or performance problems.

Firstly I'd point out that redirects after a POST are now considered the 
appropriate way of building applications, they avoid a number of 
problems and I don't believe many people are worrying too much about 
response times or performance issues 
(http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2 
for a discussion)

Second, the client I tried (which doesn't support draft-5) does a PUT 
followed by a  PROPFIND so already does two trips. Other clients would 
probably do the same. If the client wants an accurate copy of what the 
server has created it is probably going to have to retrieve the event. I 
have to believe calendar servers are not going to store exactly what the 
client sends, they will add other information and possibly change some - 
we're not dealing with a file storage mechanism but an information 
storage system.

I'd suggest that some mechanism which allowed the client to send a 
representation of a new event followed by a response containing the 
server view of that new event is likely to be more efficient.

In addition, even if the calendar is on the same machine as the mail 
servers, human initiated activity is just background noise. We're a 
small institution but we get in the order of 650,000 pop requests a day 
on one machine, that doesn't count imap, smtp or all the other rejected 
connection attempts. 50, 100, 200 people responding to an invitation 
over a period of time doesn't even register, even if it takes 3 trips.

As for the form of the names, clients presumably already have to accept 
the URI that a server produces. We already have 1000s of events with a 
naming scheme, caldav clients will accept those events with those URI's 
- they have to - they can't rename every event. When a new event is 
created the name the server chooses has to be acceptable to the client.

In any case, given the stateless nature of caldav/webdav accepting and 
storing arbitrary URI's involves a db update before we respond - much 
more of a performance problem than a redirect.

The alternative of a server accepting any URI the client  chooses is a 
significant implementation problem at the server side. Now when we 
retrieve events for a given calendar we also have to maintain and search 
a table to see if some client(s) out there provided us with events and 
return those names as the URI. We also have to do more complex searches 
to retrieve events.

It's bad enough if we have access to the server code itself. It will be 
much worse for those trying to develop a caldav server for a preexisting 
calendar implementation. Without the ability to tell the client what the 
new resource is named a caldav implementation requires db tables and a 
lot of searching. With that ability caldav server implementations can 
use the existing calendar server with no subsidiary tables.

-- 

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: Thu, 24 Mar 2005 17:55:57 -0800
From: BrianBoy <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] Free busy query:  rephrased

According to the scheduling draft a calendar-time-range report can be used
to see if a calendar owner is free similarly free-busy-query report which
acts on a calendar collection to return the free busy times of that
collection.

The problem here is if meeting has a high number of participants a free-busy
query  for every participants calendar will be an overkill and induce delays
from the client side .

Is is possible to do a single free busy query to  find out the freebusy time
for  multiple attends of a meeting ? .

If not,  a special type of report is required that  is not a calendar
collection specific but honors an iTip body, or attendee info passed through
the report header.

Brian

Date: Thu, 24 Mar 2005 11:27:15 -0800
From: BrianBoy <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] Free-Busy Report Query

I have a couple of questions on the CALDAV Free busy queries,

Is is possible to do a single free busy query to  find out the freebusy time
for  multiple attends in a meeting ? . If so where is the multiple attendee
u information specified in the body ? Because most of the report request
queries are only using dav xml tags instead of a iCalendar type info . But
the responses do have icalendar(iTip) information.

Can some one show  me a simple free busy report request query with multiple
attendees.

Brian

Date: Wed, 23 Mar 2005 19:50:33 -0500
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Fwd: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation

Forgive the duplicate post, I meant for the first sentence to read:

RFC2739 addressed calendar properties in LDAP, perhaps you could build on, 
or use that?

And the link should be:

http://www.ietf.org/rfc/rfc2739.txt

The "official" link.

>Date: Wed, 23 Mar 2005 19:48:22 -0500
>To: [email-masked]>
>From: Tim Hare <[email-masked]>
>Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation
>
>RFC2739 addressed this for iCalendar, perhaps you could build on that?
>
>http://www.faqs.org/rfcs/rfc2739.html
>
>
>
>At 04:28 PM 3/23/2005, BrianBoy wrote:
>>Thanks. It is clear now .
>>
>>Is the source code for the server available in Some CVS site where I can
>>download etc?
>>
>>Brian.
>>
>>
>>
>>On 3/23/05 12:50 PM, "Cyrus Daboo" <[email-masked]> wrote:
>>
>> > Hi,
>> >
>> > --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy <[email-masked]>
>> > wrote:
>> >
>> >> How will a caldav client discover the caldav server structure.  Since
>> >> caldav needs to operate on urls for eg.
>> >>
>> >> www.mydomain.com/caldav/users/brian/calendar
>> >>
>> >> Once the URL is known according to the draft it is possible to know it is
>> >> a calendar resource by checking the property.
>> >>
>> >> Or does the client browse through the various collections to find a users
>> >> calendar collection.?
>> >
>> > In my current client/server implementation what I have done is to 
>> designate
>> > a portion of the URI space on the server as being the 'calendar store':
>> >
>> > <http://www.mulberrymail.com:8080/slide/files/calendars>
>> >
>> > The client gets configured with that URI and that forms the root of a
>> > hierarchical browser that does PROPFINDs to display a hierarchy of
>> > collections/calendars to the user. Below that URI I currently have 
>> 'public'
>> > and 'users' collections, and with 'users' are collections for each 
>> user id.
>> > Each user then maintains their own calendars within that.
>> >
>> > This model mimics what would typically be done on an IMAP mail server. It
>> > would be nice if there were a way for the client to discover the relevant
>> > portions of the URI space on the server (as per the IMAP NAMESPACE
>> > extension) but the CalDAV authors have had varying opinions on whether 
>> that
>> > is needed and how it should be done...
>> >
>> >> how would it even know that brian's calendar is in this url?  how 
>> would it
>> >> know if brian's url changed?
>> >
>> > See section 7.2 of the current CalDAV draft. Basically we define a new
>> > property on principal resources that indicates the primary location of
>> > calendars for that principal.
>> >
>> > In terms of discovering what URI to use for some random user - that's out
>> > of scope for CalDAV itself. That's more of a service discovery type 
>> problem
>> > and is related to how you go about defining a 'calendar address' for a
>> > particular user. One simple solution is to say calendar addresses are 
>> email
>> > addresses so to find my calendar address you would find the caldav server
>> > at my domain then query for my principal resource and look at the property
>> > there.
>> >
>> >>
>> >> 2) Does anybody out there have a caldav implementation on top of 
>> slide . I
>> >> know there was a lot of discussion on this. I am wondering if a version
>> >> exist? If  it did where can I get it?
>> >
>> > Our current CalDAV prototype server (on top of Slide) is available for
>> > public access/testing at the URI above. This is not complete in terms of
>> > implementing the current spec (e.g. we have not implemented the free-busy
>> > report yet), but it should be OK for preliminary tests. You will need to
>> > use user id and password both set to 'guest' to access the server.
>>
>>_______________________________________________
>>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.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Wed, 23 Mar 2005 19:48:22 -0500
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation

RFC2739 addressed this for iCalendar, perhaps you could build on that?

http://www.faqs.org/rfcs/rfc2739.html

At 04:28 PM 3/23/2005, BrianBoy wrote:
>Thanks. It is clear now .
>
>Is the source code for the server available in Some CVS site where I can
>download etc?
>
>Brian.
>
>
>
>On 3/23/05 12:50 PM, "Cyrus Daboo" <[email-masked]> wrote:
>
> > Hi,
> >
> > --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy <[email-masked]>
> > wrote:
> >
> >> How will a caldav client discover the caldav server structure.  Since
> >> caldav needs to operate on urls for eg.
> >>
> >> www.mydomain.com/caldav/users/brian/calendar
> >>
> >> Once the URL is known according to the draft it is possible to know it is
> >> a calendar resource by checking the property.
> >>
> >> Or does the client browse through the various collections to find a users
> >> calendar collection.?
> >
> > In my current client/server implementation what I have done is to designate
> > a portion of the URI space on the server as being the 'calendar store':
> >
> > <http://www.mulberrymail.com:8080/slide/files/calendars>
> >
> > The client gets configured with that URI and that forms the root of a
> > hierarchical browser that does PROPFINDs to display a hierarchy of
> > collections/calendars to the user. Below that URI I currently have 'public'
> > and 'users' collections, and with 'users' are collections for each user id.
> > Each user then maintains their own calendars within that.
> >
> > This model mimics what would typically be done on an IMAP mail server. It
> > would be nice if there were a way for the client to discover the relevant
> > portions of the URI space on the server (as per the IMAP NAMESPACE
> > extension) but the CalDAV authors have had varying opinions on whether that
> > is needed and how it should be done...
> >
> >> how would it even know that brian's calendar is in this url?  how would it
> >> know if brian's url changed?
> >
> > See section 7.2 of the current CalDAV draft. Basically we define a new
> > property on principal resources that indicates the primary location of
> > calendars for that principal.
> >
> > In terms of discovering what URI to use for some random user - that's out
> > of scope for CalDAV itself. That's more of a service discovery type problem
> > and is related to how you go about defining a 'calendar address' for a
> > particular user. One simple solution is to say calendar addresses are email
> > addresses so to find my calendar address you would find the caldav server
> > at my domain then query for my principal resource and look at the property
> > there.
> >
> >>
> >> 2) Does anybody out there have a caldav implementation on top of slide . I
> >> know there was a lot of discussion on this. I am wondering if a version
> >> exist? If  it did where can I get it?
> >
> > Our current CalDAV prototype server (on top of Slide) is available for
> > public access/testing at the URI above. This is not complete in terms of
> > implementing the current spec (e.g. we have not implemented the free-busy
> > report yet), but it should be OK for preliminary tests. You will need to
> > use user id and password both set to 'guest' to access the server.
>
>_______________________________________________
>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, 23 Mar 2005 13:28:49 -0800
Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation
From: BrianBoy <[email-masked]>
To: Cyrus Daboo <[email-masked]>, <[email-masked]>
Cc: 

Thanks. It is clear now .

Is the source code for the server available in Some CVS site where I can
download etc? 

Brian.

On 3/23/05 12:50 PM, "Cyrus Daboo" <[email-masked]> wrote:

> Hi,
> 
> --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy <[email-masked]>
> wrote:
> 
>> How will a caldav client discover the caldav server structure.  Since
>> caldav needs to operate on urls for eg.
>> 
>> www.mydomain.com/caldav/users/brian/calendar
>> 
>> Once the URL is known according to the draft it is possible to know it is
>> a calendar resource by checking the property.
>> 
>> Or does the client browse through the various collections to find a users
>> calendar collection.?
> 
> In my current client/server implementation what I have done is to designate
> a portion of the URI space on the server as being the 'calendar store':
> 
> <http://www.mulberrymail.com:8080/slide/files/calendars>
> 
> The client gets configured with that URI and that forms the root of a
> hierarchical browser that does PROPFINDs to display a hierarchy of
> collections/calendars to the user. Below that URI I currently have 'public'
> and 'users' collections, and with 'users' are collections for each user id.
> Each user then maintains their own calendars within that.
> 
> This model mimics what would typically be done on an IMAP mail server. It
> would be nice if there were a way for the client to discover the relevant
> portions of the URI space on the server (as per the IMAP NAMESPACE
> extension) but the CalDAV authors have had varying opinions on whether that
> is needed and how it should be done...
> 
>> how would it even know that brian's calendar is in this url?  how would it
>> know if brian's url changed?
> 
> See section 7.2 of the current CalDAV draft. Basically we define a new
> property on principal resources that indicates the primary location of
> calendars for that principal.
> 
> In terms of discovering what URI to use for some random user - that's out
> of scope for CalDAV itself. That's more of a service discovery type problem
> and is related to how you go about defining a 'calendar address' for a
> particular user. One simple solution is to say calendar addresses are email
> addresses so to find my calendar address you would find the caldav server
> at my domain then query for my principal resource and look at the property
> there.
> 
>> 
>> 2) Does anybody out there have a caldav implementation on top of slide . I
>> know there was a lot of discussion on this. I am wondering if a version
>> exist? If  it did where can I get it?
> 
> Our current CalDAV prototype server (on top of Slide) is available for
> public access/testing at the URI above. This is not complete in terms of
> implementing the current spec (e.g. we have not implemented the free-busy
> report yet), but it should be OK for preliminary tests. You will need to
> use user id and password both set to 'guest' to access the server.

Date: Wed, 23 Mar 2005 15:50:05 -0500
From: Cyrus Daboo <[email-masked]>
To: BrianBoy <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation
Cc: 

Hi,

--On Wednesday, March 23, 2005 12:23 -0800 BrianBoy <[email-masked]> 
wrote:

> How will a caldav client discover the caldav server structure.  Since
> caldav needs to operate on urls for eg.
>
> www.mydomain.com/caldav/users/brian/calendar
>
> Once the URL is known according to the draft it is possible to know it is
> a calendar resource by checking the property.
>
> Or does the client browse through the various collections to find a users
> calendar collection.?

In my current client/server implementation what I have done is to designate 
a portion of the URI space on the server as being the 'calendar store':

<http://www.mulberrymail.com:8080/slide/files/calendars>

The client gets configured with that URI and that forms the root of a 
hierarchical browser that does PROPFINDs to display a hierarchy of 
collections/calendars to the user. Below that URI I currently have 'public' 
and 'users' collections, and with 'users' are collections for each user id. 
Each user then maintains their own calendars within that.

This model mimics what would typically be done on an IMAP mail server. It 
would be nice if there were a way for the client to discover the relevant 
portions of the URI space on the server (as per the IMAP NAMESPACE 
extension) but the CalDAV authors have had varying opinions on whether that 
is needed and how it should be done...

> how would it even know that brian's calendar is in this url?  how would it
> know if brian's url changed?

See section 7.2 of the current CalDAV draft. Basically we define a new 
property on principal resources that indicates the primary location of 
calendars for that principal.

In terms of discovering what URI to use for some random user - that's out 
of scope for CalDAV itself. That's more of a service discovery type problem 
and is related to how you go about defining a 'calendar address' for a 
particular user. One simple solution is to say calendar addresses are email 
addresses so to find my calendar address you would find the caldav server 
at my domain then query for my principal resource and look at the property 
there.

>
> 2) Does anybody out there have a caldav implementation on top of slide . I
> know there was a lot of discussion on this. I am wondering if a version
> exist? If  it did where can I get it?

Our current CalDAV prototype server (on top of Slide) is available for 
public access/testing at the URI above. This is not complete in terms of 
implementing the current spec (e.g. we have not implemented the free-busy 
report yet), but it should be OK for preliminary tests. You will need to 
use user id and password both set to 'guest' to access the server.

-- 
Cyrus Daboo

Date: Wed, 23 Mar 2005 12:32:59 -0800
From: Brian Moseley <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation

BrianBoy wrote:

> how would it even know that brian's calendar is in this url?  how would it
> know if brian's url changed?

the million dollar question :) i don't believe it has been (or is 
planned to be) addressed by the spec, as Lisa and i have had several 
conversations on how users can communicate their calendar URLs to each 
other.

> 2) Does anybody out there have a caldav implementation on top of slide . I
> know there was a lot of discussion on this. I am wondering if a version
> exist? If  it did where can I get it?

we're working on a CalDAV implementation at OSAF, of course. i've been 
prototyping with both Slide and Jackrabbit (the JSR 170 reference 
implementation), but i haven't chosen which we'll use yet (tho i'm 
leaning heavily towards Jackrabbit).

Date: Wed, 23 Mar 2005 12:23:17 -0800
From: BrianBoy <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-caldav] Question on Discovery and CalDav Implementation

I have a couple of questions

1) I am not sure this question was asked before anyways

How will a caldav client discover the caldav server structure.  Since caldav
needs to operate on urls for eg.

www.mydomain.com/caldav/users/brian/calendar

Once the URL is known according to the draft it is possible to know it is a
calendar resource by checking the property.

Or does the client browse through the various collections to find a users
calendar collection.?
 
how would it even know that brian's calendar is in this url?  how would it
know if brian's url changed?

2) Does anybody out there have a caldav implementation on top of slide . I
know there was a lot of discussion on this. I am wondering if a version
exist? If  it did where can I get it?

Brian

Date: Tue, 15 Mar 2005 22:11:43 -0500
To: Lisa Dusseault <[email-masked]>, Helge Hess <[email-masked]>
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Cc: CalDAV DevList <[email-masked]>

I would imagine the problem of detecting a calendar which contains itself 
would be a real pain, too (Calendar A includes Calendar B which includes 
Calendar D, which includes Calendar A, for example).

Besides, from the iCal-Basic / calsify standpoint, we're having enough 
trouble standardizing ONE level of calendar <grin>.

At 02:16 PM 3/15/2005, Lisa Dusseault wrote:

>On Mar 15, 2005, at 6:56 AM, Helge Hess wrote:
>
>>On Mar 7, 2005, at 1:53, Cyrus Daboo wrote:
>>>>Whats the motivation behind this? Is there a particular reason why one
>>>>calendar collection may not contain others?
>>>> From IMAP experience I can tell you that having mailboxes that can contain
>>>both messages and other 'sub' mailboxes is a real nightmare - from a 
>>>usability standpoint. I think it is well worth avoiding that mess if we can.
>>
>>Are there any technical reasons?
>
>Half-way between "technical reason" and "usability reason" is 
>ease-of-implementation reasons.  It's significantly easier to implement a 
>client if the client knows that a calendar collection cannot contain 
>others.  Not only does the code not have to handle both cases but the 
>design (GUI, workflow) can also can be simpler.
>
>>
>>
>>Section 4.2
>>I have another question on the 1:1 mapping between UIDs and collection 
>>relative URLs:
>>---snip---
>>That is, each WebDAV resource MUST only contain iCalendar components with 
>>the same iCalendar UID property value, and all iCalendar components with 
>>the same iCalendar UID property value MUST be stored in the same WebDAV 
>>resource.
>>---snap---
>>
>>I wonder what is supposed to happen if a client writes an iCalendar 
>>vevent with a UID which already exists in the storage to a _new_ resource 
>>name (attempts to make a copy).
>>Is the server supposed to ensure consistency? What kind of error should 
>>it return if it detects an attempt to create a duplicate uid?
>
>We certainly need to answer this question in the draft -- I think the 
>server should return an error but we haven't defined which one.
>
>>
>>Would it makes sense to enforce that the relative URL equals the UID? 
>>This would ensure that the mapping is always correct.
>That does follow the KISS principle, but I'm not sure that would work very 
>well in all cases.  In a scheduling inbox we might see many resources with 
>the same UID, for example.  I've been pushing for independence of URLs 
>from a gut feeling of it being a better decision in the long run, but I'm 
>not entirely satisfied with my own explanations of what's behind that gut 
>feeling.  Part of the principle I followed there is that I would like to 
>keep the resource addressing independent of the data model and syntax 
>details of iCalendar.  A possible benefit of independent URLs is that 
>clients could attempt some sort-of human-readable URL scheme if that 
>feature seemed valuable. And even if the benefits are a little vague, I 
>don't think this feature has much cost.
>
>Lisa
>
>_______________________________________________
>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: Tue, 15 Mar 2005 15:11:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Cc: 

Hi Helge,

--On Tuesday, March 15, 2005 21:00 +0100 Helge Hess 
<[email-masked]> wrote:

>> All kinds of debates about how to compute busy time and
>> what to show in the TOP calendar caused us to abandon the idea.
>
> Isn't the semantic on that well covered by the WebDAV depth header?

Right now CalDAV does not forbid having regular collections (which could 
contain iCal components) inside of a calendar collection. So if calendar 
collections were also allowed inside, then there would be scoping issues 
wrt depth searches etc. Of course we could easily add a new option to the 
reports to handle that case, but that will just add more complexity.

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Tue, 15 Mar 2005 21:08:12 +0100
To: CalDAV DevList <[email-masked]>

On Mar 15, 2005, at 20:16, Lisa Dusseault wrote:
> We certainly need to answer this question in the draft -- I think the 
> server should return an error but we haven't defined which one.

OK.

>> Would it makes sense to enforce that the relative URL equals the UID? 
>> This would ensure that the mapping is always correct.
>>
> That does follow the KISS principle, but I'm not sure that would work 
> very well in all cases.

Ok. I just fear that using two identifiers for the same thing calls for 
trouble in implementations. Will be easy to confuse and get wrong, 
especially since the majority of calendaring clients will probably just 
reuse the uid as the URL anyway.

> In a scheduling inbox we might see many resources with the same UID, 
> for example.

A scheduling inbox would probably be a completely different kind of 
collection which doesn't follow the uid-constraint?

Will scheduling be an addition to CalDAV or will that be in -06?

> I've been pushing for independence of URLs from a gut feeling of it 
> being a better decision in the long run, but I'm not entirely 
> satisfied with my own explanations of what's behind that gut feeling.

I have basically the same feeling because a generic client won't know 
about the UID, so you can't just drop a file into the collection and 
expect that to work.
On the other side, it won't be able to deal with any dup-uid errors 
anyway.

Mayb a redirect would help here (this time a real 302 which redirects 
to the uid location).

> Part of the principle I followed there is that I would like to keep 
> the resource addressing independent of the data model and syntax 
> details of iCalendar.

Reasonable. After all the UID is supposed to be unique across 
collections while the relative URL is only unique inside the 
collection.

> A possible benefit of independent URLs is that clients could attempt 
> some sort-of human-readable URL scheme if that feature seemed 
> valuable.

Ok, not sure whether it is really valuable, but I can imagine having a 
URL like /Calendar/MyMeeting[1] where MyMeeting[1] is the subject (+ 
uniquer).

> And even if the benefits are a little vague, I don't think this 
> feature has much cost.

Well, the cost is that you need additional error handling and tracking 
of two IDs in both, client and server.

Anyway, just wanted to know.

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Tue, 15 Mar 2005 21:00:04 +0100
To: CalDAV DevList <[email-masked]>

On Mar 15, 2005, at 20:49, Doug Royer wrote:
> All kinds of debates about how to compute busy time and
> what to show in the TOP calendar caused us to abandon the idea.

Isn't the semantic on that well covered by the WebDAV depth header?

But I see your point, I understand that this might raise discussions 
(personally I would have assumed that a folder is self contained and 
that the hierarchy has no special semantics).

Consider my question answered.

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

Date: Tue, 15 Mar 2005 12:49:09 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: CalDAV DevList <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms090301080701050109080707
Content-Type: multipart/mixed; boundary="------------030301010204030301080902"

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

Lisa Dusseault wrote:
> 
> On Mar 15, 2005, at 6:56 AM, Helge Hess wrote:
> 
>> On Mar 7, 2005, at 1:53, Cyrus Daboo wrote:
>>
>>>> Whats the motivation behind this? Is there a particular reason why one
>>>> calendar collection may not contain others?
>>>> From IMAP experience I can tell you that having mailboxes that can 
>>>> contain
>>>
>>> both messages and other 'sub' mailboxes is a real nightmare - from a 
>>> usability standpoint. I think it is well worth avoiding that mess if 
>>> we can.
>>
>>
>> Are there any technical reasons?
> 
> Half-way between "technical reason" and "usability reason" is
 > ease-of-implementation reasons. It's significantly easier to implement
 > a client if the client knows that a calendar collection cannot contain
 > others.  Not only does the code not have to handle both cases but the
 > design (GUI, workflow) can also can be simpler.

And the fact that iCal does not allow it. This debate took place
on the calsch mailing list and produced the RELATED-TO property
for showing relationships between calendars and components. (parent,
child, sibling). See the hierarchical calendars / roll-up debates.

All kinds of debates about how to compute busy time and
what to show in the TOP calendar caused us to abandon the idea.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------030301010204030301080902
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030301010204030301080902--

--------------ms090301080701050109080707
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090301080701050109080707--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Tue, 15 Mar 2005 11:16:12 -0800
To: Helge Hess <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

On Mar 15, 2005, at 6:56 AM, Helge Hess wrote:

> On Mar 7, 2005, at 1:53, Cyrus Daboo wrote:
>>> Whats the motivation behind this? Is there a particular reason why 
>>> one
>>> calendar collection may not contain others?
>>> From IMAP experience I can tell you that having mailboxes that can 
>>> contain
>> both messages and other 'sub' mailboxes is a real nightmare - from a 
>> usability standpoint. I think it is well worth avoiding that mess if 
>> we can.
>
> Are there any technical reasons?

Half-way between "technical reason" and "usability reason" is 
ease-of-implementation reasons.  It's significantly easier to implement 
a client if the client knows that a calendar collection cannot contain 
others.  Not only does the code not have to handle both cases but the 
design (GUI, workflow) can also can be simpler.

>
>
> Section 4.2
> I have another question on the 1:1 mapping between UIDs and collection 
> relative URLs:
> ---snip---
> That is, each WebDAV resource MUST only contain iCalendar components 
> with the same iCalendar UID property value, and all iCalendar 
> components with the same iCalendar UID property value MUST be stored 
> in the same WebDAV resource.
> ---snap---
>
> I wonder what is supposed to happen if a client writes an iCalendar 
> vevent with a UID which already exists in the storage to a _new_ 
> resource name (attempts to make a copy).
> Is the server supposed to ensure consistency? What kind of error 
> should it return if it detects an attempt to create a duplicate uid?

We certainly need to answer this question in the draft -- I think the 
server should return an error but we haven't defined which one.

>
> Would it makes sense to enforce that the relative URL equals the UID? 
> This would ensure that the mapping is always correct.
>
That does follow the KISS principle, but I'm not sure that would work 
very well in all cases.  In a scheduling inbox we might see many 
resources with the same UID, for example.  I've been pushing for 
independence of URLs from a gut feeling of it being a better decision 
in the long run, but I'm not entirely satisfied with my own 
explanations of what's behind that gut feeling.  Part of the principle 
I followed there is that I would like to keep the resource addressing 
independent of the data model and syntax details of iCalendar.  A 
possible benefit of independent URLs is that clients could attempt some 
sort-of human-readable URL scheme if that feature seemed valuable. And 
even if the benefits are a little vague, I don't think this feature has 
much cost.

Lisa

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Tue, 15 Mar 2005 15:56:05 +0100
To: CalDAV DevList <[email-masked]>

On Mar 7, 2005, at 1:53, Cyrus Daboo wrote:
>> Whats the motivation behind this? Is there a particular reason why one
>> calendar collection may not contain others?
>> From IMAP experience I can tell you that having mailboxes that can 
>> contain
> both messages and other 'sub' mailboxes is a real nightmare - from a 
> usability standpoint. I think it is well worth avoiding that mess if 
> we can.

Are there any technical reasons?

Section 4.2
I have another question on the 1:1 mapping between UIDs and collection 
relative URLs:
---snip---
That is, each WebDAV resource MUST only contain iCalendar components 
with the same iCalendar UID property value, and all iCalendar 
components with the same iCalendar UID property value MUST be stored in 
the same WebDAV resource.
---snap---

I wonder what is supposed to happen if a client writes an iCalendar 
vevent with a UID which already exists in the storage to a _new_ 
resource name (attempts to make a copy).
Is the server supposed to ensure consistency? What kind of error should 
it return if it detects an attempt to create a duplicate uid?

Would it makes sense to enforce that the relative URL equals the UID? 
This would ensure that the mapping is always correct.

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

Date: Mon, 07 Mar 2005 21:17:05 -0600
From: Jeffrey Harris <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: CalDAV article online

Hi Folks,

The URL for the CalDAV article at IEEE Distributed Systems Online
required cutting and pasting for me, I thought I'd save everyone else
the effort, here's a tinyurl for it:

<http://tinyurl.com/4luos>

Sincerely,
Jeffrey Harris

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Mon, 7 Mar 2005 18:12:58 -0800
Subject: [Ietf-caldav] Fwd: CalDAV article online

--Apple-Mail-1-944276136
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

FYI

Begin forwarded message:

> From: "Jim Whitehead" <[email-masked]>
> Date: March 7, 2005 1:32:37 PM PST
> To: "'Lisa Dusseault'" <[email-masked]>
> Subject: CalDAV article online
> Reply-To: <[email-masked]>
>
> Lisa,
>
> It appears the CalDAV article is freely available online at:
>
> http://dsonline.computer.org/portal/site/dsonline/ 
> menuitem.9ed3d9924aeb0dcd8
> 2ccc6716bbe36ec/index.jsp?
> <http://dsonline.computer.org/portal/site/dsonline/ 
> menuitem.9ed3d9924aeb0dcd
> 82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/ 
> 0504&file=w2sta.x
> ml&xsl=article.xsl&>
> &pName=dso_level1&path=dsonline/0504&file=w2sta.xml&xsl=article.xsl&
>
> (horrible URL, but it works)
>
> - Jim
>

--Apple-Mail-1-944276136
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

FYI

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>"Jim Whitehead" <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>March
7, 2005 1:32:37 PM PST

<bold><color><param>0000,0000,0000</param>To: </color></bold>"'Lisa
Dusseault'" <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>CalDAV
article online

<color><param>0000,0000,0000</param>Reply-To:
</color></bold><<[email-masked]>

Lisa,

It appears the CalDAV article is freely available online at:

http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd8

2ccc6716bbe36ec/index.jsp?

<<http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd

82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/0504&file=w2sta.x

ml&xsl=article.xsl&>

&pName=dso_level1&path=dsonline/0504&file=w2sta.xml&xsl=article.xsl&

(horrible URL, but it works)

- Jim 

</excerpt>
--Apple-Mail-1-944276136--

Date: Sun, 06 Mar 2005 19:57:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, ietf-caldav <[email-masked]>
Subject: Re: [Ietf-caldav] GroupDAV / CalDAV relationship
Cc: [email-masked]

Hi Helge,

--On Sunday, March 06, 2005 09:51:25 PM +0100 Helge Hess 
<[email-masked]> wrote:

> Hopefully the two efforts will be able to work together in a useful way.
> At least I'm going to work on that - why?, because at least for OGo the
> efforts are complementary. GroupDAV to get basic native client
> connectivity, CalDAV to have a well specified protocol to access advanced
> calendaring features.

I kind of see the two as similar to the POP and IMAP relationship. The key 
difference between those two is that the server does a lot more work in 
IMAP on behalf of the client (e.g. server side searching, sorting, partial 
downloads etc). In a similar manner CalDAV has server-side 'smart' features 
for doing partial retrieval at different levels - plus it will also handle 
the scheduling part itself.

-- 
Cyrus Daboo

Date: Sun, 06 Mar 2005 19:53:15 -0500
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Cc: 

Hi Helge,

--On Monday, March 07, 2005 12:54:02 AM +0100 Helge Hess 
<[email-masked]> wrote:

> I just wonder about this:
>     http://greenbytes.de/tech/webdav/draft-dusseault-caldav
> -05.html#calendar-collection
>
> ---snip---
> Calendar collections MUST NOT contain other calendar collections.
> ---snap---
>
> Whats the motivation behind this? Is there a particular reason why one
> calendar collection may not contain others?

>From IMAP experience I can tell you that having mailboxes that can contain 
both messages and other 'sub' mailboxes is a real nightmare - from a 
usability standpoint. I think it is well worth avoiding that mess if we can.

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Mon, 7 Mar 2005 00:54:02 +0100
To: CalDAV DevList <[email-masked]>

Hi,

I just wonder about this:
    
http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
-05.html#calendar-collection

---snip---
Calendar collections MUST NOT contain other calendar collections.
---snap---

Whats the motivation behind this? Is there a particular reason why one  
calendar collection may not contain others?

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Sun, 6 Mar 2005 21:56:16 +0100
To: CalDAV DevList <[email-masked]>

On 6. Mrz 2005, at 21:41 Uhr, Cyrus Daboo wrote:
> OK - just to put this one to bed, at least in regards to CalDAV - it 
> is our (the authors') intention to remove this 'redirect on PUT' 
> behaviour from the CalDAV draft. Instead, if a server has this type of 
> behaviour, then it can use whatever generic http solution is finally 
> settled on (ADDMEMBER, POST, PUT + status code etc).

Hm, yes, I think this makes perfect sense. After all a server which has 
this type of behaviour would be HTTP compliant in any case, the 
"location" is just an optimization to reduce roundtrips and 
"likeliness" of a conflict.
There is no difference whether the server renames the item concurrently 
or some other client/user, so the client cannot expect a permanent URL 
in any case. If the next PUT with an etag fails, it will probably need 
to find the "new" URL using an iCal UID search (that there is a 1:1 
relationship between URL and UID is already in the -05 draft I think).
I suppose this should be outlined in the draft?

Or if the above is not allowed/intended, it should state that once an 
iCal resource with a given UID was bound to a certain URL that this may 
not change (also that a MOVE would be forbidden).

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

From: Helge Hess <[email-masked]>
Date: Sun, 6 Mar 2005 21:51:25 +0100
To: ietf-caldav <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] GroupDAV / CalDAV relationship

Hi,

last week there was an inappropriate post about GroupDAV on Slashdot as 
most of you probably have noticed. Being one of the primary creators of 
the draft I think I need to clear up some of the confusion that 
resulted from the post (again: this was _not_ a post by the GroupDAV 
group, it was a posting by one individual). I hope that this longish 
mail manages to explain what our effort is about.

GroupDAV is something which was invented for a very specific need, less 
as a general protocol which is supposed to get submitted to the IETF 
like CalDAV. We definitely do not intend to compete with CalDAV as a 
standard - this is out of question due to our specific focus.

Our goal is to fix the issue that there are some excellent OpenSource 
groupware clients and loads of OpenSource groupware servers, yet they 
do not connect at all. Its kinda weird if the only "official" option to 
connect a server like OGo to Evolution in _2005_ is to fake being a 
proprietary server, be that Exchange (like OGo did) or Groupwise.
In our opinion this is/was mostly because a single OpenSource server 
project does not have the "critical mass" to be interesting to the 
client vendors.

So whats different. Our focus is to connect _just_ the three popular 
OpenSource groupware clients - Kontact, Evolution and Sunbird (in that 
order) with "arbitary" OpenSource groupware servers. "Arbitary", 
because a lot of the servers often have a quite specific focus, eg we 
want to cover a server like Bugzilla in a useful way.
This puts us in an environment like this:
1) we only need to specify offline synchronisation to the local client, 
no
    other reports like range queries are needed (except maybe for folder 
discovery)
2) we can assume perfect iCalendar/vCard compatibility in the local 
clients, since
    all of them are based fully on iCalendar/vCard
3) we need to deal with less than perfect iCal/vCard compatibility in 
the servers
4) we MUST be trivial to implement in existing servers, few OpenSource 
people will
    bother if it requires a week to implement the protocol, they usually 
do the work
    in their sparetime
5) we need to support a bit more functionality, for groupware we at 
least want to
    share contact data using HTTP
6) the far majority of OpenSource servers are based on HTTP (whether 
PHP, Perl
    or some other technology)
7) few servers will have full WebDAV compliance, if WebDAV support at 
all

The major consequences are that
a) The client must expect that it may not be able to save all 
iCalendar/vCard
    information in the server or that the servers deal with it in a 
different way.
    Eg recurrences are one thing which are very often handled different 
to iCal.
b) Both, client and server implementations are very simple. Basically 
they
    just need to support HTTP PUT/GET/DELETE with etags plus one fixed 
PROPFIND
    query to detect changes.
Yes, we know that the results of that is not 100% perfect. But we 
consider a panel which tells the user that something could not be 
written with some info on how to workaround that better than having no 
client support at all.

Notably a GroupDAV server doesn't even need to support WebDAV. It just 
needs to support one predefined PROPFIND on two specific properties for 
cache synchronisation. No arbitary property queries, no arbitary iCal 
content reports.

What we have accomplished so far.

Draft: we still only have the first revision of the draft plus a 
collection of issues which need to get incorporated. The document 
should be treated as such, not like a fully reviewed specification.

Clients: The Kontact support for GroupDAV was the effort which actually 
resulted in the draft. The implementation required just two days to get 
reasonable interoperability plus some sparetime work to fix some open 
issues.
Fortunately OGo as a project is sufficiently popular today so that some 
real world customers actually sponsored the development of a GroupDAV 
connector for Evolution as well as for Sunbird. The Evolution one is 
working well, the Sunbird one is work in progress.
Summary: we have almost accomplished our goals at the client side. Of 
course the client connectors need to mature just like the draft.

Servers: currently there are just three servers implementing GroupDAV, 
two of them based on the OGo frameworks. We hope that this will change 
once the draft and clients stabilize. Getting support for all the major 
OpenSource clients with very little work should be quite interesting 
for servers.

How does all that matter to CalDAV? IMHO any work being done on 
GroupDAV connectors is an excellent basis for developing support for 
full featured CalDAV implementations, that is, it pushes CalDAV 
adoption.
Actually our goal is to keep GroupDAV as compatible with CalDAV as 
possible - ideally you would be able to use a GroupDAV client connector 
with any full blown CalDAV server immediatly.

Is GroupDAV the "CalDAV Level 0" which was asked for in the past? 
Maybe, I don't know.
At least one difference is that GroupDAV also provides vCard 
synchronisation which is important in our context.
I would be happy to discuss that matter, but I fear the GroupDAV 
approach might be too "pragmatic" as an IETF standard. Eg requiring 
full WebDAV would be a no-go.

Hopefully the two efforts will be able to work together in a useful 
way. At least I'm going to work on that - why?, because at least for 
OGo the efforts are complementary. GroupDAV to get basic native client 
connectivity, CalDAV to have a well specified protocol to access 
advanced calendaring features.

Feel free to ask me any questions you have.

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

Date: Sun, 06 Mar 2005 15:41:43 -0500
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Cc: CalDAV DevList <[email-masked]>

Hi Julian,

--On Sunday, March 06, 2005 09:22:54 PM +0100 Julian Reschke 
<[email-masked]> wrote:

> Helge Hess wrote:
>> On 6. Mrz 2005, at 21:05 Uhr, Julian Reschke wrote:
>>
>>> Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986)
>>> that this is a protocol violation; see
>>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/
>>> 0066.html>).
>>
>>
>> I don't find a simple
>> ---snip---
>> That is not allowed in HTTP.
>> ---snap---
>> particulary convincing (the rest of the text is about using POST).
>
> ...in which case you should follow up to Roy's posting over at the IETF
> HTTP WG.
>
> I think I've done my part in documenting the issue and proposing
> alternatives :-)
>
>> ...

OK - just to put this one to bed, at least in regards to CalDAV - it is our 
(the authors') intention to remove this 'redirect on PUT' behaviour from 
the CalDAV draft. Instead, if a server has this type of behaviour, then it 
can use whatever generic http solution is finally settled on (ADDMEMBER, 
POST, PUT + status code etc).

-- 
Cyrus Daboo

Date: Sun, 06 Mar 2005 21:22:54 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> On 6. Mrz 2005, at 21:05 Uhr, Julian Reschke wrote:
> 
>> Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986)  
>> that this is a protocol violation; see  
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/ 
>> 0066.html>).
> 
> 
> I don't find a simple
> ---snip---
> That is not allowed in HTTP.
> ---snap---
> particulary convincing (the rest of the text is about using POST).

...in which case you should follow up to Roy's posting over at the IETF 
HTTP WG.

I think I've done my part in documenting the issue and proposing 
alternatives :-)

> ...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Sun, 6 Mar 2005 21:17:51 +0100
To: CalDAV DevList <[email-masked]>

On 6. Mrz 2005, at 21:05 Uhr, Julian Reschke wrote:
> Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986)  
> that this is a protocol violation; see  
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/ 
> 0066.html>).

I don't find a simple
---snip---
That is not allowed in HTTP.
---snap---
particulary convincing (the rest of the text is about using POST).

If thats not allowed in HTTP the HTTP spec probably should be reviewed  
to state that fact explicitly. I think that such a review is required  
is fairly obvious since a lot of people (including me) interpret the  
text in a different way.

Personally I'm still very open to get convinced that PUT+location is  
wrong. But some suitable arguments are required for that (please do not  
repost the ones you already brough up ;-)

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

Date: Sun, 06 Mar 2005 21:05:50 +0100
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Cc: CalDAV DevList <[email-masked]>

Helge Hess wrote:
> On 6. Mrz 2005, at 20:44 Uhr, Julian Reschke wrote:
> 
>> 04-C06, Section 6.2
>>
>> <http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
>> -04.html#rfc.section.6.2>
>>
>> The example given (resource created at a different URI) seems to  
>> violate HTTP semantics: if PUT doesn't actually create a resource at  
>> the Request-URI, a status code of 201 (actually any 2xx code) seems 
>> to  be wrong.
> 
> 
> That the opinions are mixed on the PUT+location is nothing new ;-)
> 
> Yet the response still has a problem because it uses location and the  
> etag. I think this is invalid in any case, if the server returns a new  
> location, the client must fetch the etag of the resource from the new  
> location.

That's correct.

Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986) that 
this is a protocol violation; see 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/0066.html>).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05
Date: Sun, 6 Mar 2005 20:59:15 +0100
To: CalDAV DevList <[email-masked]>

On 6. Mrz 2005, at 20:44 Uhr, Julian Reschke wrote:
> 04-C06, Section 6.2
>
> <http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> -04.html#rfc.section.6.2>
>
> The example given (resource created at a different URI) seems to  
> violate HTTP semantics: if PUT doesn't actually create a resource at  
> the Request-URI, a status code of 201 (actually any 2xx code) seems to  
> be wrong.

That the opinions are mixed on the PUT+location is nothing new ;-)

Yet the response still has a problem because it uses location and the  
etag. I think this is invalid in any case, if the server returns a new  
location, the client must fetch the etag of the resource from the new  
location.

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

Date: Sun, 06 Mar 2005 20:44:06 +0100
From: Julian Reschke <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Comments on draft-dusseault-caldav-05

Hi,

below are some comments on the current draft, mainly from a WebDAV (as 
opposed to Calendaring) perspective.

Best regards, Julian

05-C01, Section 2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.2>

It doesn't make sense to state that a server MAY support additional 
WebDAV features. A server is free to support any additional 
methods/properties/REPORTs it likes.

05-C02, Section 4.1, Calendar Collection

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.4.1>

"...A calendar collection MUST have ..., and a DAV:resourcetype property..."

*Any* WebDAV resource MUST have a DAV:resourcetype property. Remove that 
part of the sentence.

05-C03, Section 4.1, Calendar Collection

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.4.1>

It would be nice if there would be a single place that would state what 
additional properties a DAV collection must have to be a calendar 
collection. As far as I can tell, it's the special resource type, and 
the restriction that calendar collections can't be nested. Is there 
anything else?

05-C04, Section 5.1, MKCALENDAR

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.5.1.p.3>

"In the event that the DAV:displayname property is empty, the client MAY 
use the last part of the calendar-collection URI as the name."

That should read: "In the event the DAV:displayname property isn't 
present, ..."

05-C05, Section 5.1, MKCALENDAR

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.5.1.p.6>

"(CALDAV:insufficient-privilege): The DAV:bind privilege MUST be granted 
to the current authenticated user."

This conflicts with DAV:needs-privileges; defined in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1>.

05-C06, Section 5.1.1, MKCALENDAR status codes

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.5.1.1>

It's dangerous to attempt lists like these. Either drop it or make sure 
these are only examples. Clients MUST handle status codes as defined per 
RFC2616, in particular those not mentioned here.

05-C07, Section 5.2.1, Capability discovery

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.5.2.1>

Is there anything a client can detect using the "calendar-access" DAV 
compliance class that it couldn't find out based on live properties, 
resource types and supported methods? If "no", please consider removing 
this.

05-C08, Section 5.2, OPTIONS request bodies

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.5.2>

I'm aware that this re-uses marshalling from RFC3253, but exactly this 
feature is deprecated (see 
<http://lists.w3.org/Archives/Public/ietf-dav-versioning/2002JulSep/0003.html> 
and issues 5.5_OPTIONS_BODY and 5.5_USE_PROPERTIES on the DeltaV Issues 
List (<http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm>). 
Just make those live properties instead.

05-C09, Section 5.2.3, CALDAV:current-user-calendar-collection-set

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.5.2.3>

"A CALDAV:current-user-calendar-collection-set element MAY be included 
in the request body to identify the calendar collections owned by the 
current authenticated user."

I think the concept of "the" authenticated user may be a bit vague. An 
authenticated principal may "match" more than a single principal, for 
instance a group. Would URIs or group calendars be included here?

05-C10, Section 6.1, CALDAV:calendar-description

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.6.1>

The definition of this property seems to be exactly identical to 
DAV:displayname. What's the difference?

05-C11, Section 8, Calendaring Reports

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.8.p.3>

"Clients SHOULD request the DAV:getetag property whenever executing 
reports that return calendar data, to ensure that any local cache used 
for synchronization is kept up to date with the latest changes on the 
server"

Just requesting them will not have that effect :-). Later in the 
document this is explained with more detail; so maybe a dorward 
reference would be useful.

05-C12, CALDAV:calendar-data element

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-05.html#rfc.section.10.2>

I suspect that complexity in the spec could be reduced by simply 
exposing what's called CALDAV:calendar-data as a live property.

04-C06, Section 6.2

<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-04.html#rfc.section.6.2>

The example given (resource created at a different URI) seems to violate 
HTTP semantics: if PUT doesn't actually create a resource at the 
Request-URI, a status code of 201 (actually any 2xx code) seems to be wrong.

Date: Fri, 04 Mar 2005 17:00:54 -0600
From: Scott Carr <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] Novel Nula project - Article

Figured everyone here may be interested in this article.  It talks about 
CalDav.

http://www.linuxworld.com.au/index.php/id;483367312;fp;2;fpid;3

Have fun...

-- 
Scott Carr
OpenOffice.org
Documentation Co-Lead
http://documentation.openoffice.org