X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9MJX1qL028321 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 22 Oct 2004 12:33:03 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <24F752B6-2461-11D9-B3E0-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Lisa Dusseault Date: Fri, 22 Oct 2004 12:32:43 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Subject: [Ietf-caldav] Meeting in Washingon, DC? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 19:33:07 -0000 I'm going to be in Washington, DC at the IETF this year, doing WebDAV and IMAPEXT among other things. Who else is going to be there, and who else wants to get together to see if we can nail out any issues in CalDAV? Reply to me with preferred times or anti-preferred times and I'll try to coordinate.... Lisa X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9JGxfaA028917 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 19 Oct 2004 09:59:42 -0700 Mime-Version: 1.0 (Apple Message framework v619) To: CalDAV DevList Message-Id: <40DE766A-21F0-11D9-8D1F-000A95B2BB72@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-9--361109398 From: Lisa Dusseault Date: Tue, 19 Oct 2004 09:59:34 -0700 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Subject: [Ietf-caldav] Fwd: CalDAV implementations X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 16:59:44 -0000 --Apple-Mail-9--361109398 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I thought I'd forward this to the CalDAV list as it has a bunch of useful comments. One of the next things I plan to work on his how to create calendar collections and whether or not one can delete them. Lisa Begin forwarded message: > From: James Mason > Date: October 19, 2004 12:09:31 AM PDT > To: Slide Developers Mailing List > Subject: Re: CalDAV implementations > Reply-To: "Slide Developers Mailing List" > > > Lisa, > > Here's some feedback on what I think it would take to build a CalDAV > server on top of Slide. I'll be referencing parts of the spec here. > > > > "5 - CalDAV defines the following new resource types for use in > calendar > repositories" > > Some of these will take more work than others. None seem too hard, but > some have some rather odd requirements that need clarification. For > instance, should itip-inbox collections inside calendars that are not > inside of calendar-collections be deleteable? > > "5.7 - CalDAV server is responsible for parsing incoming REPLY messages > and adding attendee information to events." > > This should be doable. Slide has a nice event framework that should > simplify this type of requirement. > > "7 - In addition, certain properties are required on calendars to link > to principal resources." > -and- > "13 - All these properties SHOULD exist on every principal if the > server > supports CalDAV anywhere in its namespace." > > This one could be a problem. Slide doesn't treat user stores any > different from file stores, so the properties available for a > particular > resource are dependent on the capabilities of the backend Store. For > instance, Slide can use LDAP for storing users, so to be CalDAV > compliant the LDAP repository would have to be modified to expose the > necessary properties to Slide. Since this isn't something Slide can > guarantee, this could be an issue. > > "8 - Since a calendar resource of type text/calendar has properties > which duplicate some of its internal state, it's the server's > responsibility to keep those consistent somehow." > > Again, the event framework should help with this, and Slide already has > some support for parsing internal properties of uploaded documents. > What > would be really helpful is an iCal library written in Java with a > license that's useable by the ASF. That would save a lot of time, > especially if Slide implements a CalDAV client API. > > "9.1 - SCHEDULE Method for WebDAV" > > The only really complicated thing here is fanout, I think. There's a > lot > to scheduling, though, so this is a big chunk to handle. > > "14 - A CalDAV server MUST also support the set of calendar-specific > privileges defined in this section." > > Slide's security implementation is extensible, so I don't see any big > barrier to this other than the work required to support more > complicated > privileges (such as view-free-busy). > > "15 - This section defines the reports which a CalDAV server MUST > support." > > Other than handling recurrences this isn't particularly bad, it's just > going to be a bit of work. > > > > That's about it. Sorry it took so long to get this reply out (that's a > rather long document you've put together ;) ). Here are a few things > that I think would help encourage a Slide CalDAV server: > > 1. A working client, especially a test suite. It's going to be hard to > verify functionality otherwise. On a personal note, I use Evolution at > home and Groupwise at work, so if you can get Novell to support this > (especially with Groupwise) I'd be much more inspired to work on it :). > > 2. An iCal library. A lot of the functionality required by the spec > involves parsing and modifying iCal files, so it would speed things if > there was an existing piece of work here. > > 3. Another developer or two. I'm interested in this because I like the > topic and I think it's a good thing to do, however I don't have an itch > to scratch here. Unless someone else can pick this up too I doubt I'll > have the time to implement anything useful. > > -James > > On Fri, 2004-10-15 at 16:01, Lisa Dusseault wrote: >> I'm doing some investigation of possible open source server >> implementations of CalDAV >> . >> >> - In the commercial area we've seen implementations started by >> Oracle >> and definite interest by IBM. >> - In open source, Redhat is considering working on it sometime >> soon, >> as is University of Washington, but as far as I know they haven't >> started yet. >> >> Has anybody thought of adding this to Slide? It's a natural fit since >> the biggest requirement for CalDAV is support for WebDAV + ACL. >> >> Lisa > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: slide-dev-help@jakarta.apache.org > --Apple-Mail-9--361109398 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I thought I'd forward this to the CalDAV list as it has a bunch of useful comments. One of the next things I plan to work on his how to create calendar collections and whether or not one can delete them. Lisa Begin forwarded message: 0000,0000,0000From: James Mason < 0000,0000,0000Date: October 19, 2004 12:09:31 AM PDT 0000,0000,0000To: Slide Developers Mailing List < 0000,0000,0000Subject: Re: CalDAV implementations 0000,0000,0000Reply-To: "Slide Developers Mailing List" < Lisa, Here's some feedback on what I think it would take to build a CalDAV server on top of Slide. I'll be referencing parts of the spec here. "5 - CalDAV defines the following new resource types for use in calendar repositories" Some of these will take more work than others. None seem too hard, but some have some rather odd requirements that need clarification. For instance, should itip-inbox collections inside calendars that are not inside of calendar-collections be deleteable? "5.7 - CalDAV server is responsible for parsing incoming REPLY messages and adding attendee information to events." This should be doable. Slide has a nice event framework that should simplify this type of requirement. "7 - In addition, certain properties are required on calendars to link to principal resources." -and- "13 - All these properties SHOULD exist on every principal if the server supports CalDAV anywhere in its namespace." This one could be a problem. Slide doesn't treat user stores any different from file stores, so the properties available for a particular resource are dependent on the capabilities of the backend Store. For instance, Slide can use LDAP for storing users, so to be CalDAV compliant the LDAP repository would have to be modified to expose the necessary properties to Slide. Since this isn't something Slide can guarantee, this could be an issue. "8 - Since a calendar resource of type text/calendar has properties which duplicate some of its internal state, it's the server's responsibility to keep those consistent somehow." Again, the event framework should help with this, and Slide already has some support for parsing internal properties of uploaded documents. What would be really helpful is an iCal library written in Java with a license that's useable by the ASF. That would save a lot of time, especially if Slide implements a CalDAV client API. "9.1 - SCHEDULE Method for WebDAV" The only really complicated thing here is fanout, I think. There's a lot to scheduling, though, so this is a big chunk to handle. "14 - A CalDAV server MUST also support the set of calendar-specific privileges defined in this section." Slide's security implementation is extensible, so I don't see any big barrier to this other than the work required to support more complicated privileges (such as view-free-busy). "15 - This section defines the reports which a CalDAV server MUST support." Other than handling recurrences this isn't particularly bad, it's just going to be a bit of work. That's about it. Sorry it took so long to get this reply out (that's a rather long document you've put together ;) ). Here are a few things that I think would help encourage a Slide CalDAV server: 1. A working client, especially a test suite. It's going to be hard to verify functionality otherwise. On a personal note, I use Evolution at home and Groupwise at work, so if you can get Novell to support this (especially with Groupwise) I'd be much more inspired to work on it :). 2. An iCal library. A lot of the functionality required by the spec involves parsing and modifying iCal files, so it would speed things if there was an existing piece of work here. 3. Another developer or two. I'm interested in this because I like the topic and I think it's a good thing to do, however I don't have an itch to scratch here. Unless someone else can pick this up too I doubt I'll have the time to implement anything useful. -James On Fri, 2004-10-15 at 16:01, Lisa Dusseault wrote: I'm doing some investigation of possible open source server implementations of CalDAV <. - In the commercial area we've seen implementations started by Oracle and definite interest by IBM. - In open source, Redhat is considering working on it sometime soon, as is University of Washington, but as far as I know they haven't started yet. Has anybody thought of adding this to Slide? It's a natural fit since the biggest requirement for CalDAV is support for WebDAV + ACL. Lisa --------------------------------------------------------------------- To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: slide-dev-help@jakarta.apache.org --Apple-Mail-9--361109398-- X-Envelope-From: gettes@duke.edu Received: from wilson.acpub.duke.edu (wilson.acpub.duke.edu [152.3.233.69]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9BNsbaA029566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 16:54:38 -0700 Received: from [192.168.0.6] (rdu26-59-053.nc.rr.com [66.26.59.53]) by wilson.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with ESMTP id i9BNsNPH010306; Mon, 11 Oct 2004 19:54:24 -0400 (EDT) In-Reply-To: <1198328AFDBF5841B27E40C40C331537012AE609@df-chewy-msg.exchange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537012AE609@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael R Gettes Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] comments on -02 Date: Mon, 11 Oct 2004 19:54:24 -0400 To: "Cameron Stillion" X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Cc: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 23:54:39 -0000 Is it reasonable to suggest community based ical or task oriented ical? People oriented systems might be able to limit one set of abilities within the spec whereas others, such as computing clusters and other areas, could use forms of ical that allow them to their jobs as well. Creating namespaces for ical specifications would seem to be a logical thing to do. Well known namespaces have well defined specs and uses -- this allows for local namespaces to implement other aspects of ical. Just a thought... /mrg On Oct 11, 2004, at 19:30, Cameron Stillion wrote: > > I respectfully disagree. Leaving a standard "as open as possible" can > easily lead to such difficulties in interoperability as we have all > witnessed over the past several years. The idea for calsify, I > believe, > is to actually curb the open-ended nature of iCal in favor of the more > practical bottom line: something that works for a subset that we really > really care about. > > This is not uncommon in software development, it's just that iCal is > long due for such a refocus and simplification. It's not so much a > matter of Social Restrictions - it's just that the kinds of systems we > are creating have a general purpose to them, and it is centered around > creating calendars, sharing calendars, scheduling meetings, and other > simple day-to-day things. Aligning stellar cartography hardware and > synchronizing atomic clocks are most definitely on the ragged outer > edge > of our target. > > This is not to say we should paint ourselves into a corner in the most > fundamental ways, but it does mean we need to start small, get > something > basic that we all can agree to, grow some real interoperability, and > THEN we can start tinkering with how to extend the standard to the > zillion other applications and possibilities. > > As for your specific example -- "granularity", I can easily see a > property emerge in a future version of iCal that specified > sub-15-minute > granularity. This would not break clients who didn't care (most of > them, IMHO) and would be easily read and interpreted by those who did. > > Let's avoid getting wrapped around the axle of creating "the perfect > calendaring standard" - I'm just hoping we can get something simple > that > kind of works without too much pain and suffering. > > > Cameron > > > -----Original Message----- > From: ietf-calsify-bounces@osafoundation.org > [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Lyndon > Nerenberg > Sent: Saturday, October 09, 2004 9:57 PM > To: TimHare@comcast.net; ietf-caldav@osafoundation.org; > ietf-calsify@osafoundation.org > Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02 > > --On 2004-10-6 10:25 PM -0400 TimHare@comcast.net wrote: > >> my view is that we ought to establish a standard for the granularity >> of a free/busy time map (15 minutes would be my choice) > > I disagree with this. Calendaring is much more than just scheduling > meetings (with people). I can see using iCal and friends to schedule > runtime on computing clusters, or access to radio astronomy telescopes, > or many other resources where fine-grained access times are > appropriate. > We should not be placing any form of social restrictions on the > protocols like this. They must be left as open ended as possible so as > to preclude us having to revisit the specifications in the near term > because we didn't anticipate a use for them. > > --lyndon > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: camerost@exchange.microsoft.com Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.149] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9BNUIa9027843; Mon, 11 Oct 2004 16:30:25 -0700 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.8.109]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Oct 2004 16:30:04 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-01.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 16:30:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Ietf-calsify] RE: [Ietf-caldav] comments on -02 Date: Mon, 11 Oct 2004 16:30:10 -0700 Message-ID: <1198328AFDBF5841B27E40C40C331537012AE609@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-calsify] RE: [Ietf-caldav] comments on -02 Thread-Index: AcSuhcHlVIm4b/zwQ7uWek12p1xQxgBYy+qw From: "Cameron Stillion" To: "Lyndon Nerenberg" , , , X-OriginalArrivalTime: 11 Oct 2004 23:30:14.0437 (UTC) FILETIME=[42657550:01C4AFEA] X-Scanned-By: MIMEDefang 2.45 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i9BNUIa9027843 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 23:30:26 -0000 I respectfully disagree. Leaving a standard "as open as possible" can easily lead to such difficulties in interoperability as we have all witnessed over the past several years. The idea for calsify, I believe, is to actually curb the open-ended nature of iCal in favor of the more practical bottom line: something that works for a subset that we really really care about. This is not uncommon in software development, it's just that iCal is long due for such a refocus and simplification. It's not so much a matter of Social Restrictions - it's just that the kinds of systems we are creating have a general purpose to them, and it is centered around creating calendars, sharing calendars, scheduling meetings, and other simple day-to-day things. Aligning stellar cartography hardware and synchronizing atomic clocks are most definitely on the ragged outer edge of our target. This is not to say we should paint ourselves into a corner in the most fundamental ways, but it does mean we need to start small, get something basic that we all can agree to, grow some real interoperability, and THEN we can start tinkering with how to extend the standard to the zillion other applications and possibilities. As for your specific example -- "granularity", I can easily see a property emerge in a future version of iCal that specified sub-15-minute granularity. This would not break clients who didn't care (most of them, IMHO) and would be easily read and interpreted by those who did. Let's avoid getting wrapped around the axle of creating "the perfect calendaring standard" - I'm just hoping we can get something simple that kind of works without too much pain and suffering. Cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Lyndon Nerenberg Sent: Saturday, October 09, 2004 9:57 PM To: TimHare@comcast.net; ietf-caldav@osafoundation.org; ietf-calsify@osafoundation.org Subject: [Ietf-calsify] RE: [Ietf-caldav] comments on -02 --On 2004-10-6 10:25 PM -0400 TimHare@comcast.net wrote: > my view is that we ought to establish a standard for the granularity > of a free/busy time map (15 minutes would be my choice) I disagree with this. Calendaring is much more than just scheduling meetings (with people). I can see using iCal and friends to schedule runtime on computing clusters, or access to radio astronomy telescopes, or many other resources where fine-grained access times are appropriate. We should not be placing any form of social restrictions on the protocols like this. They must be left as open ended as possible so as to preclude us having to revisit the specifications in the near term because we didn't anticipate a use for them. --lyndon _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: TimHare@comcast.net Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9ACv2a9007317; Sun, 10 Oct 2004 05:57:02 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <2004101012565201100jtmqee> (Authid: TimHare); Sun, 10 Oct 2004 12:56:52 +0000 Message-Id: <6.1.1.1.0.20041010084709.028597b0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Sun, 10 Oct 2004 08:50:55 -0400 To: Lyndon Nerenberg , ietf-caldav@osafoundation.org, ietf-calsify@osafoundation.org From: TimHare@comcast.net Subject: RE: [Ietf-caldav] comments on -02 In-Reply-To: References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchan ge.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.45 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 12:57:03 -0000 After several comments, I can see that exchanging a "bit map" of free/busy time has definite downsides, so let's drop that idea. Also, rather than continuing to cross-post I will put further discussion of how to simplify free/busy work on the calsify list rather than caldav. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: lyndon@orthanc.ca Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9A4vIaA031952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2004 21:57:18 -0700 Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9A4v3uf087760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2004 22:57:09 -0600 (MDT) Date: Sat, 09 Oct 2004 21:57:02 -0700 From: Lyndon Nerenberg To: TimHare@comcast.net, ietf-caldav@osafoundation.org, ietf-calsify@osafoundation.org Subject: RE: [Ietf-caldav] comments on -02 Message-ID: In-Reply-To: <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchan ge.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca X-Scanned-By: MIMEDefang 2.45 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 04:57:19 -0000 --On 2004-10-6 10:25 PM -0400 TimHare@comcast.net wrote: > my view is that we ought to establish a standard for the granularity > of a free/busy time map (15 minutes would be my choice) I disagree with this. Calendaring is much more than just scheduling meetings (with people). I can see using iCal and friends to schedule runtime on computing clusters, or access to radio astronomy telescopes, or many other resources where fine-grained access times are appropriate. We should not be placing any form of social restrictions on the protocols like this. They must be left as open ended as possible so as to preclude us having to revisit the specifications in the near term because we didn't anticipate a use for them. --lyndon X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i97HaF0f018432 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 7 Oct 2004 10:36:16 -0700 Received: from Royer.com (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i97HaBx3015166 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 7 Oct 2004 10:36:12 -0700 Message-ID: <41657E8A.7030505@Royer.com> Date: Thu, 07 Oct 2004 11:36:10 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] comments on -02 References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> <2AC2E790-1813-11D9-9014-000A95B2BB72@osafoundation.org> In-Reply-To: <2AC2E790-1813-11D9-9014-000A95B2BB72@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070409010101090702000600" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.45 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 17:36:17 -0000 This is a cryptographically signed message in MIME format. --------------ms070409010101090702000600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I don't see why a bit map has any advantages over a free busy summary > with begin/end times for each busy blocks. And the begin/end > timestamps have some advantages: they're human-readable (or at least > developer/debugger readable), and don't require us to choose an > arbitrary maximum granularity (why fifteen minutes? why not five? > one? Can I negotiate granularity?). I agree. VFREEBUSY is already in effect a bit map represented in ASCII. > > ... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms070409010101090702000600 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA3MTczNjEwWjAjBgkqhkiG9w0BCQQxFgQUChGRjx7FJktRKPkrufe+ YZKlr4gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAbE42ROKZXxC7oRjBZBSNc3plr+xmNU8A25O8I2aPdJg5W8VXCIQKlLyVY2OgUoAT c32pjxL0ubJHSFwmpAl7v0yydxvhpIf3mVsxqjy3dMeA6w7PLQkSqwoMF2cok5lYDgsl/ykX HqyoTxcvyRQGdyGDBT8zTM0VLP0sTdGFwJHNoqD8zXHVL4YeVhbUTX2NRETAgjAyYSeLHxzz VNYj5Uo59cFj5BqBdUKVvqSfZwHg6UULkP8+fa4Iqpv7hfVBSbiwJB8DS7dXS9Quo6dfCgl1 GrSwqbkOWZNE6lkV/2GQp5pFxGGnF490z5NdQ45nRhlvnI05xp1B5x5b39PeswAAAAAAAA== --------------ms070409010101090702000600-- X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id i976e80e021114 for ; Wed, 6 Oct 2004 23:40:09 -0700 Received: (qmail 4856 invoked by uid 65534); 7 Oct 2004 06:40:02 -0000 Received: from pD9FF0095.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.0.149) by mail.gmx.net (mp012) with SMTP; 07 Oct 2004 08:40:02 +0200 X-Authenticated: #1915285 Message-ID: <4164E4C0.3060407@gmx.de> Date: Thu, 07 Oct 2004 08:40:00 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] comments on -02 (creating items) References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> <763336BA-17DB-11D9-958E-000D93C1A604@opengroupware.org> In-Reply-To: <763336BA-17DB-11D9-958E-000D93C1A604@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 06:40:11 -0000 Helge Hess wrote: > ... > Yes, I know. This wasn't my point. I expect that CalDAV will be used to > expose legacy systems which implies that it needs to deal with the above > situation (object naming done by the server). > I wanted to know whether a regular WebDAV client is supposed to be able > to deal with the above sequence (and in turn, CalDAV). In this case, a regular WebDAV client is just an HTTP client (PUT is defined in RFC2616, and WebDAV doesn't modify it's semantics). A properly written client *should* go back to the user, display the redirect target and ask whether (s)he wants to write to that URL instead. I'm not sure anybody is doing that, though. Another approach may be to actually allow the PUT, but to return a Location header in the response that contains the actual URL. Again, I doubt many clients will expect this. If this is a scenario that needs to be taken care, it seems there should be a specific protocol extension for it (possibly in a separate spec). > Eg one example Dan already brought up (and which I always wanted to > implement ;-), is the Bugzilla/WebDAV gateway. You certainly want to > have the bug ids as the "filenames". (sounds interesting) > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i973iR0f008870 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 6 Oct 2004 20:44:30 -0700 In-Reply-To: <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2AC2E790-1813-11D9-9014-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] comments on -02 Date: Wed, 6 Oct 2004 20:44:18 -0700 To: TimHare@comcast.net X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Cc: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 03:44:32 -0000 I don't see why a bit map has any advantages over a free busy summary with begin/end times for each busy blocks. And the begin/end timestamps have some advantages: they're human-readable (or at least developer/debugger readable), and don't require us to choose an arbitrary maximum granularity (why fifteen minutes? why not five? one? Can I negotiate granularity?). The calendar agent can always translate begin/end times into a bitmap for summarization -- that's implementation-dependent. I have a prejudice against binary formats, too :) Lisa On Oct 6, 2004, at 7:25 PM, TimHare@comcast.net wrote: > Free/Busy is a property of the user/owner of the calendar more than > anything else; in essence I really want a logical AND of all of my > free/busy time so that none of my events, personal or business, get > overbooked. In iCalendar, however, we have to represent those at the > VCALENDAR level. I am cross-posting this to the calsify list, because > it really belongs there - my view is that we ought to establish a > standard for the granularity of a free/busy time map (15 minutes would > be my choice), and then just exchange a "bit map" of the time between > two dates that are requested as the endpoints - call it a VBUSYMAP > deliverable as other binary objects are, in Base64. Then, scheduling > a meeting might go something like this: > > Organizer to each attendee: Show me your free/busy map between date X > and date Y. > Each attendee: here is the VBUSYMAP of my time > Organizer then finds (hopefully) a time when all are free, and sends > out meeting requests for that time;or, finding no acceptable time, > picks two different dates and tries again. > > This, to me, simplifies and shortens the scheduling process. Your code > doesn't have to parse all of the VFREEBUSY items. In fact, an > implementation can choose to maintain the map in whatever backing > store it uses, and keep it updated as VEVENTS are added or removed. > > At 08:36 PM 10/6/04, Cameron Stillion wrote: >> But if you don't want to be scheduled, that means you want the time to >> appear as if you are "scheduled" already... Right? You can do this >> now >> by putting an appointment on your calendar marked as "OOF" - and the >> free/busy view of this event will clearly mark this as already taken. >> >> Having someone schedule you on Saturday or Sunday is really a social >> problem though. If it is your wife, it makes sense. If it's your >> co-worker, then there are social checks and balances that say this >> won't >> happen if it isn't appropriate. The protocol is not meant to solve >> the >> social aspect. Clearly good software would keep this in mind and help >> you do the right thing, but it can't know all the human >> implications... >> >> I still stand by the fact that free/busy is merely a translation of >> events, and that anything else is unnecessarily complex with really no >> benefit - to the standard most especially, but even more to >> applications >> and systems. >> >> >> cameron >> >> >> -----Original Message----- >> From: ietf-caldav-bounces@osafoundation.org >> [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of G. Barnes >> Sent: Wednesday, October 06, 2004 10:26 AM >> To: ietf-caldav@osafoundation.org >> Subject: Re: [Ietf-caldav] comments on -02 >> >> On Wed, 6 Oct 2004, Lisa Dusseault wrote: >> >> > I could go either way on allowing users to store standalone >> VFREEBUSY >> > components. Keeping it is a small feature/flexibility; removing it >> is >> >> > a small simplification. Who else has use cases or problems with >> > keeping or removing that feature? >> >> I have a problem with removing it. I want to be able to say, 'no one >> can schedule me on Saturday or Sunday' (among other times). Othewise, >> some jerk is going to schedule a mandatory meeting at 7am Saturday. >> Creating a VEVENT would presumably mean something shows up in my >> calendar. >> But I don't necessarily have an event scheduled; I just want to be >> left >> alone. The most obvious way to do this is to create a standalone >> VFREEBUSY. >> >> Greg Barnes >> Computing and Communications, University of >> Washington >> gsbarnes@washington.edu >> (206) 685-3295 >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav >> >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Tim Hare > Interested Bystander, Non-Inc. > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: TimHare@comcast.net Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i972Ua0e003061; Wed, 6 Oct 2004 19:30:36 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <200410070230290150037l8he> (Authid: TimHare); Thu, 7 Oct 2004 02:30:30 +0000 Message-Id: <6.1.1.1.0.20041006221253.0285c380@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 06 Oct 2004 22:25:15 -0400 To: , ietf-calsify@osafoundation.org From: TimHare@comcast.net Subject: RE: [Ietf-caldav] comments on -02 In-Reply-To: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exch ange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.45 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 02:30:36 -0000 Free/Busy is a property of the user/owner of the calendar more than anything else; in essence I really want a logical AND of all of my free/busy time so that none of my events, personal or business, get overbooked. In iCalendar, however, we have to represent those at the VCALENDAR level. I am cross-posting this to the calsify list, because it really belongs there - my view is that we ought to establish a standard for the granularity of a free/busy time map (15 minutes would be my choice), and then just exchange a "bit map" of the time between two dates that are requested as the endpoints - call it a VBUSYMAP deliverable as other binary objects are, in Base64. Then, scheduling a meeting might go something like this: Organizer to each attendee: Show me your free/busy map between date X and date Y. Each attendee: here is the VBUSYMAP of my time Organizer then finds (hopefully) a time when all are free, and sends out meeting requests for that time;or, finding no acceptable time, picks two different dates and tries again. This, to me, simplifies and shortens the scheduling process. Your code doesn't have to parse all of the VFREEBUSY items. In fact, an implementation can choose to maintain the map in whatever backing store it uses, and keep it updated as VEVENTS are added or removed. At 08:36 PM 10/6/04, Cameron Stillion wrote: >But if you don't want to be scheduled, that means you want the time to >appear as if you are "scheduled" already... Right? You can do this now >by putting an appointment on your calendar marked as "OOF" - and the >free/busy view of this event will clearly mark this as already taken. > >Having someone schedule you on Saturday or Sunday is really a social >problem though. If it is your wife, it makes sense. If it's your >co-worker, then there are social checks and balances that say this won't >happen if it isn't appropriate. The protocol is not meant to solve the >social aspect. Clearly good software would keep this in mind and help >you do the right thing, but it can't know all the human implications... > >I still stand by the fact that free/busy is merely a translation of >events, and that anything else is unnecessarily complex with really no >benefit - to the standard most especially, but even more to applications >and systems. > > >cameron > > >-----Original Message----- >From: ietf-caldav-bounces@osafoundation.org >[mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of G. Barnes >Sent: Wednesday, October 06, 2004 10:26 AM >To: ietf-caldav@osafoundation.org >Subject: Re: [Ietf-caldav] comments on -02 > >On Wed, 6 Oct 2004, Lisa Dusseault wrote: > > > I could go either way on allowing users to store standalone VFREEBUSY > > components. Keeping it is a small feature/flexibility; removing it is > > > a small simplification. Who else has use cases or problems with > > keeping or removing that feature? > >I have a problem with removing it. I want to be able to say, 'no one >can schedule me on Saturday or Sunday' (among other times). Othewise, >some jerk is going to schedule a mandatory meeting at 7am Saturday. >Creating a VEVENT would presumably mean something shows up in my >calendar. >But I don't necessarily have an event scheduled; I just want to be left >alone. The most obvious way to do this is to create a standalone >VFREEBUSY. > > Greg Barnes > Computing and Communications, University of >Washington > gsbarnes@washington.edu > (206) 685-3295 >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: camerost@exchange.microsoft.com X-Envelope-To: Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.149] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i970ao0e028400 for ; Wed, 6 Oct 2004 17:36:51 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Oct 2004 17:36:45 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Oct 2004 17:37:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-caldav] comments on -02 Date: Wed, 6 Oct 2004 17:36:42 -0700 Message-ID: <1198328AFDBF5841B27E40C40C331537012347CF@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] comments on -02 Thread-Index: AcSr4oPx81uo4VzFS7qcsWbu0lT2BgAIonNw From: "Cameron Stillion" To: "G. Barnes" , X-OriginalArrivalTime: 07 Oct 2004 00:37:57.0698 (UTC) FILETIME=[E4392220:01C4AC05] X-Scanned-By: MIMEDefang 2.45 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i970ao0e028400 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2004 00:36:52 -0000 But if you don't want to be scheduled, that means you want the time to appear as if you are "scheduled" already... Right? You can do this now by putting an appointment on your calendar marked as "OOF" - and the free/busy view of this event will clearly mark this as already taken. Having someone schedule you on Saturday or Sunday is really a social problem though. If it is your wife, it makes sense. If it's your co-worker, then there are social checks and balances that say this won't happen if it isn't appropriate. The protocol is not meant to solve the social aspect. Clearly good software would keep this in mind and help you do the right thing, but it can't know all the human implications... I still stand by the fact that free/busy is merely a translation of events, and that anything else is unnecessarily complex with really no benefit - to the standard most especially, but even more to applications and systems. cameron -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of G. Barnes Sent: Wednesday, October 06, 2004 10:26 AM To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] comments on -02 On Wed, 6 Oct 2004, Lisa Dusseault wrote: > I could go either way on allowing users to store standalone VFREEBUSY > components. Keeping it is a small feature/flexibility; removing it is > a small simplification. Who else has use cases or problems with > keeping or removing that feature? I have a problem with removing it. I want to be able to say, 'no one can schedule me on Saturday or Sunday' (among other times). Othewise, some jerk is going to schedule a mandatory meeting at 7am Saturday. Creating a VEVENT would presumably mean something shows up in my calendar. But I don't necessarily have an event scheduled; I just want to be left alone. The most obvious way to do this is to create a standalone VFREEBUSY. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 _______________________________________________ Ietf-caldav mailing list Ietf-caldav@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i96LbW0e012620 for ; Wed, 6 Oct 2004 14:37:32 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6D345292C3C for ; Wed, 6 Oct 2004 23:05:39 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 5B7B3292C3B for ; Wed, 6 Oct 2004 23:05:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <763336BA-17DB-11D9-958E-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] comments on -02 (creating items) Date: Wed, 6 Oct 2004 23:05:33 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 21:37:33 -0000 On Oct 6, 2004, at 18:27, Cyrus Daboo wrote: >> Question: in WebDAV, would that be viable: >> a) PUT on /1234.ics >> b) server detects as a new item (1234 not available) >> c) server creates new item name (54321) >> d) server redirects client to /54321.ics >> e) client will reattempt PUT on /54321.ics >> Is this acceptable WebDAV? (I know that almost no HTTP client properly >> supports redirects ...) > First of all there are ways in HTTP & WebDAV to ensure that a new > resource is created when doing a PUT - e.g. use of 'If-None-Match: *' > header and/or lock-nulls. Yes, I know. This wasn't my point. I expect that CalDAV will be used to expose legacy systems which implies that it needs to deal with the above situation (object naming done by the server). I wanted to know whether a regular WebDAV client is supposed to be able to deal with the above sequence (and in turn, CalDAV). Eg one example Dan already brought up (and which I always wanted to implement ;-), is the Bugzilla/WebDAV gateway. You certainly want to have the bug ids as the "filenames". BTW: letting the server create the uid isn't the worst idea either since it reduces locking (you would need to lock the whole folder?!) and neither requires looping to find an available name. (though this isn't my main motivation, see above) > I believe the choice of URL naming should be left to the client, > rather than having some kind of special POST or redirect approach. Maybe POST/redirect might be too difficult. But if support for the redirect as outlined above is already required for a conforming WebDAV/HTTP client anyway, then we get the functionality for free. This is something I would like to get an OK for ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i96Ksp0e007416 for ; Wed, 6 Oct 2004 13:54:52 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 70AC1292BEF for ; Wed, 6 Oct 2004 22:54:24 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id BFBEC292BE6 for ; Wed, 6 Oct 2004 22:54:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041005195450.02854990@mail.comcast.net> <1097075440.8798.328.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] comments on -02 Date: Wed, 6 Oct 2004 22:54:23 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 20:54:53 -0000 On Oct 6, 2004, at 17:16, Lisa Dusseault wrote: > I could go either way on allowing users to store standalone VFREEBUSY > components. Keeping it is a small feature/flexibility; removing it is > a small simplification. Who else has use cases or problems with > keeping or removing that feature? I agree with Dan here. VFREEBUSY is just a stripped external representation of VEVENTs. Its natural for the OGo storage which doesn't dinstinguish between and event and conflict information (its just one SQL table type queried for everything). On the other side supporting VFREEBUSY PUTs in the protocol server is relatively easy. It would just create a fullfledged appointment on the server with a read access configuration which only allows for startdate and enddate read access. The difficult or unnatural thing here is to remember that an appointment created by a freebusy PUT and return the event as exactly that in subsequent requests. Summary: I would prefer to see that an event collection can only contain events. Having to deal with two different things only makes it more complicated and requires more explanation. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: gsbarnes@u.washington.edu X-Envelope-To: Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i96HPt0f001362 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 6 Oct 2004 10:25:55 -0700 Received: from mead12.u.washington.edu (mead12.u.washington.edu [140.142.12.176]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i96HPsJa026316 for ; Wed, 6 Oct 2004 10:25:54 -0700 Received: from localhost (gsbarnes@localhost) by mead12.u.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i96HPsN0716812 for ; Wed, 6 Oct 2004 10:25:54 -0700 Date: Wed, 6 Oct 2004 10:25:54 -0700 (PDT) From: "G. Barnes" To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] comments on -02 In-Reply-To: Message-ID: References: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041005195450.02854990@mail.comcast.net> <1097075440.8798.328.camel@twelve-monkeys.boston.ximian.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.45 X-Mailman-Approved-At: Wed, 06 Oct 2004 13:23:43 -0700 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 17:25:56 -0000 On Wed, 6 Oct 2004, Lisa Dusseault wrote: > I could go either way on allowing users to store standalone VFREEBUSY > components. Keeping it is a small feature/flexibility; removing it is a > small simplification. Who else has use cases or problems with keeping or > removing that feature? I have a problem with removing it. I want to be able to say, 'no one can schedule me on Saturday or Sunday' (among other times). Othewise, some jerk is going to schedule a mandatory meeting at 7am Saturday. Creating a VEVENT would presumably mean something shows up in my calendar. But I don't necessarily have an event scheduled; I just want to be left alone. The most obvious way to do this is to create a standalone VFREEBUSY. Greg Barnes Computing and Communications, University of Washington gsbarnes@washington.edu (206) 685-3295 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i96GRA0f025889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Oct 2004 09:27:11 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i96G3Xo3006450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 12:03:34 -0400 Date: Wed, 06 Oct 2004 12:27:03 -0400 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] comments on -02 (creating items) Message-ID: In-Reply-To: References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.45 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 16:27:12 -0000 Hi Helge, --On Tuesday, October 5, 2004 2:15 AM +0200 Helge Hess wrote: > Question: in WebDAV, would that be viable: > a) PUT on /1234.ics > b) server detects as a new item (1234 not available) > c) server creates new item name (54321) > d) server redirects client to /54321.ics > e) client will reattempt PUT on /54321.ics > Is this acceptable WebDAV? (I know that almost no HTTP client properly > supports redirects ...) First of all there are ways in HTTP & WebDAV to ensure that a new resource is created when doing a PUT - e.g. use of 'If-None-Match: *' header and/or lock-nulls. I believe the choice of URL naming should be left to the client, rather than having some kind of special POST or redirect approach. CalDAV should recommend a suitable naming scheme (e.g. a lightweight hash of (UID, SEQ, RECURRENCE-ID, LAST_MODIFIED), as well as ensure clients use the proper HTTP/WebDAV approach for ensuring creation of new resources. -- Cyrus Daboo X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i96FGI0f018718 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 6 Oct 2004 08:16:24 -0700 In-Reply-To: <1097075440.8798.328.camel@twelve-monkeys.boston.ximian.com> References: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041005195450.02854990@mail.comcast.net> <1097075440.8798.328.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] comments on -02 Date: Wed, 6 Oct 2004 08:16:10 -0700 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 15:16:25 -0000 I could go either way on allowing users to store standalone VFREEBUSY components. Keeping it is a small feature/flexibility; removing it is a small simplification. Who else has use cases or problems with keeping or removing that feature? lisa On Oct 6, 2004, at 8:10 AM, Dan Winship wrote: > On Tue, 2004-10-05 at 20:00 -0400, TimHare@comcast.net wrote: >> This is a response to a VFREBUSY request (from RFC 2445) > ... >> As you can perhaps see, it's a pretty compact method of representing >> busy >> time over the requested period, the requestor doesn't have to >> retrieve and >> parse all of the VEVENTS in the period > > Sure, the server should definitely return VFREEBUSY objects in response > to a free-busy-time request, but that doesn't mean the user needs to be > able to create arbitrary VFREEBUSY objects. The server can construct an > appropriate VFREEBUSY response automatically from the VEVENTs. > >> and as Doug Royer pointed out, >> your busy time could be longer than the event time (or shorter, but I >> can't >> think of a use case for that) > > The use case for shorter would be "I only care about the first half of > the agenda, so I'm going to leave early". But both of these are > examples > of constructing use cases based on what happens to be possible > according > to the wording of the spec. I don't think anything in the RFCs suggests > that VFREEBUSY was supposed to be able to address either of these > cases. > > (If we did want to implement something like this, it would make more > sense to add a property or parameter to the VEVENT itself, maybe using > syntax similar to the VALARM TRIGGER parameter, to add or remove busy > time from either end of the event. That way, if the event was > rescheduled, the freebusy hack would move along with it. Not that I'm > suggesting we do that any time before calsify finishes :-) > > -- Dan > > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i96FDE0f018418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 6 Oct 2004 08:13:19 -0700 Received: (qmail 28471 invoked from network); 6 Oct 2004 15:13:08 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 6 Oct 2004 15:13:08 -0000 Subject: RE: [Ietf-caldav] comments on -02 From: Dan Winship To: TimHare@comcast.net In-Reply-To: <6.1.1.1.0.20041005195450.02854990@mail.comcast.net> References: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> <6.1.1.1.0.20041005195450.02854990@mail.comcast.net> Content-Type: text/plain Date: Wed, 06 Oct 2004 11:10:40 -0400 Message-Id: <1097075440.8798.328.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 15:13:22 -0000 On Tue, 2004-10-05 at 20:00 -0400, TimHare@comcast.net wrote: > This is a response to a VFREBUSY request (from RFC 2445) ... > As you can perhaps see, it's a pretty compact method of representing busy > time over the requested period, the requestor doesn't have to retrieve and > parse all of the VEVENTS in the period Sure, the server should definitely return VFREEBUSY objects in response to a free-busy-time request, but that doesn't mean the user needs to be able to create arbitrary VFREEBUSY objects. The server can construct an appropriate VFREEBUSY response automatically from the VEVENTs. > and as Doug Royer pointed out, > your busy time could be longer than the event time (or shorter, but I can't > think of a use case for that) The use case for shorter would be "I only care about the first half of the agenda, so I'm going to leave early". But both of these are examples of constructing use cases based on what happens to be possible according to the wording of the spec. I don't think anything in the RFCs suggests that VFREEBUSY was supposed to be able to address either of these cases. (If we did want to implement something like this, it would make more sense to add a property or parameter to the VEVENT itself, maybe using syntax similar to the VALARM TRIGGER parameter, to add or remove busy time from either end of the event. That way, if the event was rescheduled, the freebusy hack would move along with it. Not that I'm suggesting we do that any time before calsify finishes :-) -- Dan X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i9605h0e022772 for ; Tue, 5 Oct 2004 17:05:43 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc12) with SMTP id <2004100600053701400s2irke> (Authid: TimHare); Wed, 6 Oct 2004 00:05:38 +0000 Message-Id: <6.1.1.1.0.20041005195450.02854990@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 05 Oct 2004 20:00:35 -0400 To: "CalDAV DevList" From: TimHare@comcast.net Subject: RE: [Ietf-caldav] comments on -02 In-Reply-To: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exch ange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2004 00:05:44 -0000 This is a response to a VFREBUSY request (from RFC 2445) BEGIN:VFREEBUSY ORGANIZER:jsmith@host.com DTSTART:19980313T141711Z DTEND:19980410T141711Z FREEBUSY:19980314T233000Z/19980315T003000Z FREEBUSY:19980316T153000Z/19980316T163000Z FREEBUSY:19980318T030000Z/19980318T040000Z URL:http://www.host.com/calendar/busytime/jsmith.ifb END:VFREEBUSY As you can perhaps see, it's a pretty compact method of representing busy time over the requested period, the requestor doesn't have to retrieve and parse all of the VEVENTS in the period, and as Doug Royer pointed out, your busy time could be longer than the event time (or shorter, but I can't think of a use case for that). The shortest representation of free/busy time I've seen implemented was a binary bit-map of every 15 minutes in a month - 31 x (24 x 4 bits = 96 bits = 12 octets) = 372 octets for a whole month!, with 0=free 1=busy. T15At 11:41 PM 10/4/04, Cameron Stillion wrote: >I've always been confused by the difference between VFREEBUSY and the >VEVENT with precisely the same attributes... > >You seem to be arguing here that VFB's are useful as a scaled down >version for those with reduced permissions. However, I can, using >VEVENTS, accomplish the same thing. In fact, I can impose a far more >granular set of permissions applied to any subset of the calendar. >Free/Busy, IMHO is simply a version of VEVENT listings that does not >contain the "full" enchilada. Free/Busy and other scaled down versions >of VEVENTS will always be calculated from the full source VEVENTS >anyway. Why do we need a different schematic representation? > >Perhaps this argument would better appear on calsify, but we've already >opened the box... > > >-----Original Message----- >From: ietf-caldav-bounces@osafoundation.org >[mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of >TimHare@comcast.net >Sent: Monday, October 04, 2004 8:18 PM >To: CalDAV DevList >Subject: Re: [Ietf-caldav] comments on -02 > >VFREEBUSY is used for query/retrieval of busy time - sometimes a client >is authorized to know free and busy times and nothing else - no details >of events, no summary description of events, nothing but "the time is >blocked from 8 to 9". Scheduling is also potentially faster when you >just inquire into VFREEBUSY, not retrieve every event over a time range >and construct a free/busy time map. > > At 08:10 PM 10/4/04, Helge Hess wrote: > >On Oct 5, 2004, at 1:41, Lisa Dusseault wrote: > >>>>and each one contains exactly one VEVENT or VFREEBUSY object. > >>>Do we really want static VFREEBUSY objects? > >>yes- these don't duplicate VEVENT data, they supplement it with > >>blocked out time. > > > >Hm, this will probably complicate things? I would see a vfreebusy as a > >stripped representation of an vevent. If you want to block a time, > >create a proper event (and attach information why this is blocked). > > > >A more interesting case is free time. But not to complicate things I > >tend to suggest that those are implemented as some rrule property on > >the event collection. > > > >For conflict detection a server would probably do: > >a) calculate busy time based on existing events > >b) restrict the remaining free time by freetime data (eg the work hours >at the > > office) > >If we really want to support VFREEBUSY objects in an event collection, > >most servers probably will convert them to real events (with no > >additional > >info) on the fly. I would like to avoid this. > > > >Greets, > > Helge > >-- > >http://docs.opengroupware.org/Members/helge/ > >OpenGroupware.org > > > >_______________________________________________ > >Ietf-caldav mailing list > >Ietf-caldav@osafoundation.org > >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > >Tim Hare >Interested Bystander, Non-Inc. > > >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id i95JbH0e005089 for ; Tue, 5 Oct 2004 12:37:18 -0700 Received: (qmail 21309 invoked by uid 65534); 5 Oct 2004 19:37:11 -0000 Received: from pD9535980.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.89.128) by mail.gmx.net (mp016) with SMTP; 05 Oct 2004 21:37:11 +0200 X-Authenticated: #1915285 Message-ID: <4162F7E4.2040905@gmx.de> Date: Tue, 05 Oct 2004 21:37:08 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 Subject: [Ietf-caldav] Comments on draft 02 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 19:37:20 -0000 Hi, below are some comments on the -02 draft, primarily from a WebDAV p.o.v. (so little to no Calendaring knowledge involved here :-). 02-C01 Section 1.1.1 "Specifying new URL formats..." -- is this about new URI schemes (I think so)? In this case, the text should use the proper IETF terminology. 02-C02 Section 1.1.3+4 This makes it sound as if Locking is a mandatory WebDAV feature, which is incorrect. 02-C03 Section 1.1.6 Looking at the IETF status of the SASL draft it seems that it needs to be revised (also it's at draft 11 in the meantime). At some point of time this (calDav) spec needs to decide whether it wants to refer to work-in-progress or not... 02-C04 Section 2 Why are the following features required? - Locking - WebDAV SEARCH I suspect there's some desire to promote certain WebDAV features/extensions (to which I'm sympathetic). However, just requiring lots of (IMHO orthogonal) stuff will just raise the entry barrier, thus affect acceptance (because people do not embrace CalDAV) or interop (because people will subset anyway) negatively. IMHO it's better to keep the required WebDAV feature set minimal, and then explain who certain extensions optionall can make things even better. Similar thoughts apply to requiring RFC3744. I can easily imagine a server that has a custom ACL system that for some reason doesn't get exposed as WebDAV ACLs. As far as I can tell, that system would still be fully functional with the restriction that a calendaring client wouldn't be able to display ACLs or author them. Also, saying that a server "may" support DeltaV doesn't say anything useful. It may also support any other HTTP extension (such as ordered collections, bindings or redirects). Please remove that paragraph. 02-C05 Section 3 I'm not sure we need new DAV: header tokens. It seems that both scenarios can already be addressed using supported-live-property-set and supported-method-set (and of course also the Allow header returned upon OPTIONS). 02-C06, Section 6 It's ok to recommend a certain file extension, but requiring it is against HTTP and the overall Web architecture. The content type of a resource served via HTTP is defined by the Content-Type response parameter, nothing else. Even IE get's this right in XPSP2. Editorial 02-E01 Document needs to refer to RFC3667 in the boilerplate. 02-E02, Section 5.1 starting in there are several examples using a namespace name of "DAV" instead of "DAV:". 02-E03, Section 6 Non-ASCII (in this case Chinese) characters are not allowed in IETF spec text content. 02-E04, References The reference to WebDAV SEARCH has an incorrect date; anyway, in the meantime the draft has been updated, see . 02-E05, Section 4.1, typo s/calenadr/calendar/ Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i95Hmq0f028078 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 5 Oct 2004 10:48:54 -0700 Received: from Royer.com (royer.com [4.23.9.161]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id i95Hmhxt022037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Oct 2004 10:48:46 -0700 Message-ID: <4162DE7B.8000508@Royer.com> Date: Tue, 05 Oct 2004 11:48:43 -0600 From: Doug Royer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] comments on -02 References: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> In-Reply-To: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040805050200070800040201" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: CalDAV DevList List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 17:48:55 -0000 This is a cryptographically signed message in MIME format. --------------ms040805050200070800040201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit There is no rule that says the your BUSY time == your VEVENT time. They are not quite the same thing. I could say that +/- 15 to every VEVENT - tag as busy. I could say that weekends and 5pm - 8am tag as busy all of the time. Cameron Stillion wrote: >I've always been confused by the difference between VFREEBUSY and the >VEVENT with precisely the same attributes... > >You seem to be arguing here that VFB's are useful as a scaled down >version for those with reduced permissions. However, I can, using >VEVENTS, accomplish the same thing. In fact, I can impose a far more >granular set of permissions applied to any subset of the calendar. >Free/Busy, IMHO is simply a version of VEVENT listings that does not >contain the "full" enchilada. Free/Busy and other scaled down versions >of VEVENTS will always be calculated from the full source VEVENTS >anyway. Why do we need a different schematic representation? > >Perhaps this argument would better appear on calsify, but we've already >opened the box... > > -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)520-4044 http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040805050200070800040201 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDQxMDA1MTc0ODQzWjAjBgkqhkiG9w0BCQQxFgQU9w3SAAeVUMrqPQYd+rM8 OPxhYzUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAEfusodIPxfuKNzxXyP6Wq0z9zkEQi0SEjmgsY6XiUTUHvg7JjkTPjCwZOAssC1NF 88LC+gmvGb1MrZSygkOuoU+DK55YzFxrKwpfoXRJeKRZSsCoke5Ijwj2rUY37zJCot4jM7Zu uouGsg8VHCMmFC2j3v0AK+RyhhAbGo6L/L81Ejg2rRDBEbeGfaHI/uV9mImnmMqmlhAejiEC 1vgDn0wXOeUExwCwZBKBzQvWovnePe34x/ViDae4mNm01Bq64OGY/kG6C43xY1ebj8fdoLAh yVtS2ZMZUvha6STRv5t15oI2bVkm/kLFqat7lBn6kFYLtwvDKYtFRUeF1XiLrAAAAAAAAA== --------------ms040805050200070800040201-- X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id i95GoE0e024200 for ; Tue, 5 Oct 2004 09:50:15 -0700 Received: (qmail 31227 invoked by uid 65534); 5 Oct 2004 16:50:08 -0000 Received: from p50824591.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.69.145) by mail.gmx.net (mp002) with SMTP; 05 Oct 2004 18:50:08 +0200 X-Authenticated: #1915285 Message-ID: <4162D0BF.4030302@gmx.de> Date: Tue, 05 Oct 2004 18:50:07 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] comments on -02 References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> <416248CE.2080906@gmx.de> <3F08131C-16EB-11D9-939B-000A95B2BB72@osafoundation.org> In-Reply-To: <3F08131C-16EB-11D9-939B-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 16:50:17 -0000 Lisa Dusseault wrote: > I'd always thought of a principal resource as a WebDAV resource because > it MUST have certain properties. In what way is it not a WebDAV > resource if it has properties? Sure, MOVE and COPY and DELETE and > PROPPATCH and LOCK may all be forbidden, but those could all be > forbidden on any read-only WebDAV resource. This leads us into the fuzzy area of what a "WebDAV resource" is. As WebDAV level 1 for instance requires supports for PROPPATCH, I would expect a "WebDAV" resource to never ever return 405, something which is explicitly allowed for a principal resource in RFC3744. As you note, in practice this doesn't make a big difference (for instance, you may get a 403 because you're missing privileges). Anyway, I think the authors of RFC3744 intentionally did *not* say that a principal is a WebDAV resource, so CalDav shouldn't claim that it's saying that. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i95GQ90f022847 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Oct 2004 09:26:09 -0700 In-Reply-To: <416248CE.2080906@gmx.de> References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> <416248CE.2080906@gmx.de> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3F08131C-16EB-11D9-939B-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] comments on -02 Date: Tue, 5 Oct 2004 09:26:01 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 16:26:10 -0000 I'd always thought of a principal resource as a WebDAV resource because it MUST have certain properties. In what way is it not a WebDAV resource if it has properties? Sure, MOVE and COPY and DELETE and PROPPATCH and LOCK may all be forbidden, but those could all be forbidden on any read-only WebDAV resource. Lisa On Oct 5, 2004, at 12:10 AM, Julian Reschke wrote: > Lisa Dusseault wrote: > > ... >> fixed text: "The WebDAV ACL specification requires that any principal >> to whom permissions >> can be granted is represented via a WebDAV resource" >> ... > > Not so (): > > "...However, servers implementing this specification MUST expose > principal resources at an http(s) URL, which is a privileged scheme > that points to resources that have additional properties, as described > in Section 4. So, a principal resource can have multiple URIs, one of > which has to be an http(s) scheme URL. Although an implementation > SHOULD support PROPFIND and MAY support PROPPATCH to access and modify > information about a principal, it is not required to do so." > > Best regards, Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id i957AJ0e027306 for ; Tue, 5 Oct 2004 00:10:20 -0700 Received: (qmail 30544 invoked by uid 65534); 5 Oct 2004 07:10:07 -0000 Received: from pD9535980.dip.t-dialin.net (EHLO [192.168.0.3]) (217.83.89.128) by mail.gmx.net (mp011) with SMTP; 05 Oct 2004 09:10:07 +0200 X-Authenticated: #1915285 Message-ID: <416248CE.2080906@gmx.de> Date: Tue, 05 Oct 2004 09:10:06 +0200 From: Julian Reschke User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] comments on -02 References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.45 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 07:10:21 -0000 Lisa Dusseault wrote: > ... > fixed text: "The WebDAV ACL specification requires that any principal to > whom permissions > can be granted is represented via a WebDAV resource" > ... Not so (): "...However, servers implementing this specification MUST expose principal resources at an http(s) URL, which is a privileged scheme that points to resources that have additional properties, as described in Section 4. So, a principal resource can have multiple URIs, one of which has to be an http(s) scheme URL. Although an implementation SHOULD support PROPFIND and MAY support PROPPATCH to access and modify information about a principal, it is not required to do so." Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: camerost@exchange.microsoft.com X-Envelope-To: Received: from exchange.microsoft.com (exchange.microsoft.com [131.107.76.149] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i953fL0e015589 for ; Mon, 4 Oct 2004 20:41:21 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Oct 2004 20:41:10 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 4 Oct 2004 20:41:22 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-caldav] comments on -02 Date: Mon, 4 Oct 2004 20:41:18 -0700 Message-ID: <1198328AFDBF5841B27E40C40C331537011B3C68@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-caldav] comments on -02 Thread-Index: AcSqitmvsTZKoarASHCi8EJJOlV7MgAAaVNg From: "Cameron Stillion" To: , "CalDAV DevList" X-OriginalArrivalTime: 05 Oct 2004 03:41:22.0062 (UTC) FILETIME=[2E8252E0:01C4AA8D] X-Scanned-By: MIMEDefang 2.45 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id i953fL0e015589 X-Mailman-Approved-At: Tue, 05 Oct 2004 09:20:46 -0700 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 03:41:22 -0000 I've always been confused by the difference between VFREEBUSY and the VEVENT with precisely the same attributes... You seem to be arguing here that VFB's are useful as a scaled down version for those with reduced permissions. However, I can, using VEVENTS, accomplish the same thing. In fact, I can impose a far more granular set of permissions applied to any subset of the calendar. Free/Busy, IMHO is simply a version of VEVENT listings that does not contain the "full" enchilada. Free/Busy and other scaled down versions of VEVENTS will always be calculated from the full source VEVENTS anyway. Why do we need a different schematic representation? Perhaps this argument would better appear on calsify, but we've already opened the box... -----Original Message----- From: ietf-caldav-bounces@osafoundation.org [mailto:ietf-caldav-bounces@osafoundation.org] On Behalf Of TimHare@comcast.net Sent: Monday, October 04, 2004 8:18 PM To: CalDAV DevList Subject: Re: [Ietf-caldav] comments on -02 VFREEBUSY is used for query/retrieval of busy time - sometimes a client is authorized to know free and busy times and nothing else - no details of events, no summary description of events, nothing but "the time is blocked from 8 to 9". Scheduling is also potentially faster when you just inquire into VFREEBUSY, not retrieve every event over a time range and construct a free/busy time map. At 08:10 PM 10/4/04, Helge Hess wrote: >On Oct 5, 2004, at 1:41, Lisa Dusseault wrote: >>>>and each one contains exactly one VEVENT or VFREEBUSY object. >>>Do we really want static VFREEBUSY objects? >>yes- these don't duplicate VEVENT data, they supplement it with >>blocked out time. > >Hm, this will probably complicate things? I would see a vfreebusy as a >stripped representation of an vevent. If you want to block a time, >create a proper event (and attach information why this is blocked). > >A more interesting case is free time. But not to complicate things I >tend to suggest that those are implemented as some rrule property on >the event collection. > >For conflict detection a server would probably do: >a) calculate busy time based on existing events >b) restrict the remaining free time by freetime data (eg the work hours at the > office) >If we really want to support VFREEBUSY objects in an event collection, >most servers probably will convert them to real events (with no >additional >info) on the fly. I would like to avoid this. > >Greets, > Helge >-- >http://docs.opengroupware.org/Members/helge/ >OpenGroupware.org > >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. _______________________________________________ Ietf-caldav mailing list Ietf-caldav@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i953Mg0e014788 for ; Mon, 4 Oct 2004 20:22:42 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc12) with SMTP id <20041005032236012004qdfge> (Authid: TimHare); Tue, 5 Oct 2004 03:22:36 +0000 Message-Id: <6.1.1.1.0.20041004231535.0283b0b0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 04 Oct 2004 23:18:08 -0400 To: CalDAV DevList From: TimHare@comcast.net Subject: Re: [Ietf-caldav] comments on -02 In-Reply-To: <078C3138-1663-11D9-958E-000D93C1A604@opengroupware.org> References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> <078C3138-1663-11D9-958E-000D93C1A604@opengroupware.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 03:22:43 -0000 VFREEBUSY is used for query/retrieval of busy time - sometimes a client is authorized to know free and busy times and nothing else - no details of events, no summary description of events, nothing but "the time is blocked from 8 to 9". Scheduling is also potentially faster when you just inquire into VFREEBUSY, not retrieve every event over a time range and construct a free/busy time map. At 08:10 PM 10/4/04, Helge Hess wrote: >On Oct 5, 2004, at 1:41, Lisa Dusseault wrote: >>>>and each one contains exactly one VEVENT or VFREEBUSY object. >>>Do we really want static VFREEBUSY objects? >>yes- these don't duplicate VEVENT data, they supplement it with blocked >>out time. > >Hm, this will probably complicate things? I would see a vfreebusy as a >stripped representation of an vevent. If you want to block a time, create >a proper event (and attach information why this is blocked). > >A more interesting case is free time. But not to complicate things I tend >to suggest that those are implemented as some rrule property on the event >collection. > >For conflict detection a server would probably do: >a) calculate busy time based on existing events >b) restrict the remaining free time by freetime data (eg the work hours at the > office) >If we really want to support VFREEBUSY objects in an event collection, >most servers probably will convert them to real events (with no additional >info) on the fly. I would like to avoid this. > >Greets, > Helge >-- >http://docs.opengroupware.org/Members/helge/ >OpenGroupware.org > >_______________________________________________ >Ietf-caldav mailing list >Ietf-caldav@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i950G40e006759 for ; Mon, 4 Oct 2004 17:16:05 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id C9FF829207F for ; Tue, 5 Oct 2004 02:15:33 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 3D391291F9B for ; Tue, 5 Oct 2004 02:15:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] comments on -02 (creating items) Date: Tue, 5 Oct 2004 02:15:58 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 00:16:05 -0000 On Oct 5, 2004, at 1:41, Lisa Dusseault wrote: >>> 6. Creating Resources >> >> Why not just say that the client should use POST (to the collection >> URL) >> rather than PUT, and let the server generate an object URL? > That's not a standard part of WebDAV although as we know Exchange > server does that :) > > I'm not against that feature but it's not one that WebDAV servers > already do, so CalDAV servers would need to add that if we specify > that. +1 for POST. In most RDBMS based servers some kind of sequence will decide the identifier for new objects. Question: in WebDAV, would that be viable: a) PUT on /1234.ics b) server detects as a new item (1234 not available) c) server creates new item name (54321) d) server redirects client to /54321.ics e) client will reattempt PUT on /54321.ics Is this acceptable WebDAV? (I know that almost no HTTP client properly supports redirects ...) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i950B50e006481 for ; Mon, 4 Oct 2004 17:11:05 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A5A7E291F91 for ; Tue, 5 Oct 2004 02:10:33 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 4B019291827 for ; Tue, 5 Oct 2004 02:10:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <078C3138-1663-11D9-958E-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] comments on -02 Date: Tue, 5 Oct 2004 02:10:56 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 00:11:06 -0000 On Oct 5, 2004, at 1:41, Lisa Dusseault wrote: >>> and each one contains exactly one VEVENT or VFREEBUSY object. >> Do we really want static VFREEBUSY objects? > yes- these don't duplicate VEVENT data, they supplement it with > blocked out time. Hm, this will probably complicate things? I would see a vfreebusy as a stripped representation of an vevent. If you want to block a time, create a proper event (and attach information why this is blocked). A more interesting case is free time. But not to complicate things I tend to suggest that those are implemented as some rrule property on the event collection. For conflict detection a server would probably do: a) calculate busy time based on existing events b) restrict the remaining free time by freetime data (eg the work hours at the office) If we really want to support VFREEBUSY objects in an event collection, most servers probably will convert them to real events (with no additional info) on the fly. I would like to avoid this. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i94Nff0f004739 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 4 Oct 2004 16:41:42 -0700 In-Reply-To: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> References: <1096476066.4924.266.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] comments on -02 Date: Mon, 4 Oct 2004 16:41:33 -0700 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.45 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 23:41:44 -0000 Responses to these comments inline... On Sep 29, 2004, at 9:41 AM, Dan Winship wrote: >> 4.2 Recurrence and the Data Model > > How/where are "detached" instances of a recurrence represented? Eg, if > I > change the SUMMARY of one instance of a meeting, does that require > creating a new resource (with the same UID as an existing resource)? My intent was that would create a new WebDAV resource with the same UID as an existing resource. Anybody else have other suggestions? > >> 4.3 CalDAV and timezones > > This feels like it presupposes a certain calsify outcome... It supposes that either iCalendar will keep VTIMEZONES in recurring VEVENTS, or that even if it does change CalDAV servers will have to deal with RFC2445 compliant VEVENTS. If calsify makes a bunch of changes we'll certainly have to rewrite this and other sections but it's too early to do that now. > >> 4.4 Scheduling, Fanout and the Data model > >> The Inbox contains inbound iTIP messages long after they are >> handled/seen by the user > > OK. How long? How about this language, later on after the overview material? "Servers SHOULD NOT delete messages before or after a client has retrieved the messages in the inbox; instead the server SHOULD leave Inbox cleanup to the client. A server MAY apply a quota to the iTIP Inbox (limiting the number of messages, the total size, or some other measurable) and MAY bounce incoming messages if the iTIP inbox is full or some other repository or account problem has occurred." > >> CalDAV defines an iTIP Outbox collection... > > In email clients and real life, an outbox/"out box" is for things that > are on their way out. The CalDAV Outbox stores things that have > *already* gone out. Seems weird, but I don't know if this is going to > annoy anyone but me. :) I know, we realized this after putting that wording in a bunch of places, and haven't resolved the wording because we may still be debating the purpose. If we in fact use it to store things that have already gone out we should rename it to "sent" or something. Any input on the purpose of the iTIP "outbox" ? Is it useful to have a collection of sent invitations? > >> Two users coordinating scheduling with one calendar (e.g. a calendar >> user and her assistant) can see what scheduling messages the other >> user has sent. > > But does that actually tell them what they want to know? Wouldn't it > would be better to look in the calendar folder instead? > > * If some invitees have already responded to the invite, the copy > of the event in the calendar will show updated PARTSTATs, but > the copy in the Outbox won't. > * If the other user made changes to the event after first > scheduling it (eg, added an attendee who was forgotten in the > original invite), that will be reflected all in one place in > the > calendar folder, but the information would be split across > multiple separate Outbox messages. > * If a meeting was scheduled entirely via iMIP (perhaps because > it > was received as a REQUEST from a non-CalDAV user), then it will > appear in the calendar, but not in the Outbox. > > Another problem is that the Outbox doesn't record the responses to the > SCHEDULE request. So you might see an invite that appears to have been > sent to several people, when in fact the server returned a 502 for > every > Recipient. An event in the calendar doesn't tell you what the wording in the invitation has, necessarily. Don't forget you can theoretically send out an invitation for a meeting which you're not an attendee of . Maybe we should clarify whether an invitation in the sent items folder necessarily has to correspond to an event in the calendar? Also the sent items record tells you when the invitation went out, which could be after the event item was created. I don't know what to do about recording the responses to the SCHEDULE request. A concrete proposal would be welcome here. > >> However, the server MAY be configured (how is not defined here) to >> auto-accept or auto-reject invitations, and if the server >> auto-accepts invitations then the server is responsible for creating >> VEVENT resources in the user's calendar. > > ("VEVENT" is wrong here, it might be automatically accepting VTODOs > too.) I'm fixing that.... > > If the spec is going to explicitly allow servers to do this, it should > specify how the client is expected to behave in such a situation. How > does a client determine if the server has already processed an > invitation? And is the server allowed (or REQUIRED) to process it > *before* putting it in the Inbox, to avoid a race condition? Wouldn't this be the same case as detecting whether another client has already processed the invitation? It's the same problem as the multi-client problem -- the server is just another potential active client or user agent. I do like the idea of processing it before it shows up to avoid a race condition. However, that problem might also have to be solved for the multi-client use cases. in fact this shows me we'll need another section in the scheduling/fanout section of the document, explaining *how* to accept/reject invitations and avoid race conditions. (To avoid race conditions I'll recommend how to use locks or strong ETags). > >> 5.2 Calendars Collection > >> A WebDAV collection which corresponds to a single calendar or VAGENDA >> is a Calendar. > > VAGENDA is a CAP-ism. RFC 2445 has only VCALENDARs. Fixing... > >> It MUST contain one event collection > > Any reason for that? What if a system wants to support just todo data? > (Eg, a bug-tracking system could export your bugs as tasks.) Thats a pretty good idea. so the server MAY contain one and no more than one event collection, just like todos. > >> and one alarm collection. > > That's wrong now, right? Fixing... > >> 5.3 Event Collection > >> and each one contains exactly one VEVENT or VFREEBUSY object. > > Do we really want static VFREEBUSY objects? yes- these don't duplicate VEVENT data, they supplement it with blocked out time. > >> 5.7 iTIP Outbox Collection > >> Every non-collection resource in the scheduling collection is >> considered to be a REQUEST or REPLY. > > No COUNTER, DECLINE-COUNTER, etc? I thought COUNTER was a REPLY? Do you think these should also be added? > >> 6. Creating Resources > > Why not just say that the client should use POST (to the collection > URL) > rather than PUT, and let the server generate an object URL? That's not a standard part of WebDAV although as we know Exchange server does that :) I'm not against that feature but it's not one that WebDAV servers already do, so CalDAV servers would need to add that if we specify that. > >> 7. Users and Groups >> >> The WebDAV ACL specification requires that any principal to whom >> permissions can be represented via a WebDAV resource (complete with >> WebDAV properties and a HTTP URL). > > Something is missing in that sentence. (s/can be represented/can be > granted can be represented/ ?) fixed text: "The WebDAV ACL specification requires that any principal to whom permissions can be granted is represented via a WebDAV resource" > >> 9. Scheduling and Fanout > >> In other words, the server MUST handle fanout if requested > > I think that sentence predates the calendar-schedule capability... the > section probably needs a little rewriting Yeah, deleted that sentence. > >> CalDAV servers that return the value "calendar-schedule" in the DAV >> response header MUST support iTIP to send and receive scheduling >> requests as well as reply to scheduling request. Outgoing iTIP >> messages MUST be submitted to an iTIP Outbox collection. > > Who is being MUSTed in the second sentence? The paragraph starts out > talking about servers, but servers don't submit things to Outboxes. And > if it means "Clients MUST submit outgoing iTIP messages to an iTIP > Outbox collection", that would imply they weren't allowed to do iMIP, > which also sounds wrong. This seems better to me: "These servers MUST handle outgoing iTIP messages submitted to an iTIP Outbox collection, and MUST deliver incoming iTIP messages to an iTIP Inbox collection." > >> Incoming iTIP messages MUST be delivered to an iTIP Inbox collection. > > Another dangling MUST. see above > >> 9.1 SCHEDULE Method for WebDAV > >> The list of attendees and the organizer information in this request >> body might well be redundant with the values of the Recipient and >> Originator headers. This is intentional, so that the client can have >> more control over who receives invitations and who sends them: > > I think each of the three examples you give is redundant with existing > iCalendar/iTIP functionality: > >> o The client may send invitations to calendar users not on the >> attendee list (for example, to an assistant, caterer, observer, >> etc). > > They could also be listed as ATTENDEEs with ROLE=NON-PARTICIPANT. That's like a "cc", the way we outlined in the draft is more like a "bcc". The difference is whether everybody else sees that they are in the attendee list or not. > >> o The client may choose not to send invitations to calendar users >> who are on the attendee list (for example, attendees who have been >> scheduled through an out-of-band mechanism). > > Maybe they could just be listed with PARTSTAT=ACCEPTED? (Maybe not...) I don't like that -- that seems to be overloading something to mean something that it doesn't mean. > >> o The originator may be different than the organizer, for example an >> assistant who has calendar-bind privileges on the organizer's >> calendar. > > You can specify that with the SENT-BY property on the ORGANIZER. Hmm, I recall something convincing here that made our header trick a neat one, but now i can't reconstruct the details... what a four-day vacation can do to you! > >> 9.1.1 Status Codes for use with 207 (Multi-Status) > > Tying back to the Outbox comments earlier, does every successful > SCHEDULE result in a message being appended to Outbox, even when every > Recipient fails? I would say, yes, that's the intended model... as I said above it would be even more useful to have some way to store the results as well as the outgoing message. > > Need a little more discussion of the exact scheduling flow. Section 9 > mentions "(c) a new method requests fanout of a resource that has > already been uploaded", but the description of SCHEDULE itself doesn't > mention ordering at all, which it probably should. (If you do SCHEDULE > first, then PUT, there's a race condition in that someone else's REPLY > could come in before you PUT the event they're REPLYing to, especially > if there are auto-accepting/rejecting resources on the system.) > > OTOH, what's the advantage in doing a PUT to the calendar followed by a > SCHEDULE to the Outbox, rather than just doing a SCHEDULE to the > calendar? The PUT and the SCHEDULE are intended to be independent because otherwise we tend to design them together and limit what clients can do. - PUT is the operation which stores the event on a specific calendar. - SCHEDULE is the operation which sends an invitation to multiple recipients. What can the client do special if we keep them independent? - I can SCHEDULE to a single Outbox, and independently decide whether to PUT the event to my karate calendar or my work calendar. - Can SCHEDULE without doing PUT: scheduling a meeting that the scheduler doesn't actually attend (and I don't show up in attendee list). e.g. when our HR person schedules an interview for me and a candidate. - Can PUT without SCHEDULE (any event that doesn't have attendees other than myself) - Can PUT an event that *does* have attendees, and can use another mechanism besides SCHEDULE to notify them (Chandler needs this use case). - Can PUT an event on my calendar long in advance, then when date/location are confirmed and I'm ready to write the invitation, send SCHEDULE. But if we continue with this model, you're right, we do need to recommend that if the event is going to go on a calendar at all it should go before the SCHEDULE is sent. > >> 202 (Accepted) - The request was accepted, but the server has not >> performed any action with it yet. > > What happens if the server returns a 202 and is then unable to complete > the transaction? (Presumably if it *knew* it was going to be able to > succeed, it would have just returned a 200 instead.) Eg, it might > return > a 202 if it forwards the request to a remote user via iMIP, but then > what happens if the iMIP message bounces? There doesn't seem to be any > way for the server to inform the client of that. Yep, Bernard & I discussed this at great length when we got together. No good answers yet. > >> 507 (Insufficient Storage) - The server did not have sufficient space >> to record the iTIP message. > > "in the Recipient's iTIP Inbox". Presumably if the Originator is over > quota, the SCHEDULE would get back a top-level 507 rather than a 207. True enough. thx. > >> 9.2.1 Example - Retrieve incoming iTIP Message > > The example has an "Originator" header in the response. Is that a bug? > If not, something needs to say explicitly somewhere that that > information is preserved. (And that the Recipient information isn't? > What about in the copy in Outbox?) Actually the text does say "The originator of the iTIP message will be specified in the Originator response header." > >> 13. CalDAV Principal Properties > > Many of these properties would be useful (or maybe even necessary) for > resource-type calendars as well, which (according to section 12) > wouldn't have any principal associated with them. Is there any reason > these couldn't be defined on the Calendar or Calendar Container instead > of the Principal? Cyrus? Bernard? I think this might be a good idea... > >> 13.3 itip-inbox-URL Property >> 13.4 itip-outbox-URL Property > > Both of these are multi-valued... is there any particular behavior > expected of clients in the presence of multiple Inboxes or Outboxes? > (If > not, then why can you have more than one?) Damn, you ask too many good questions. We should discuss the value of multiple inboxes/outboxes, and whether the value is worth the complexity. Somebody, please respond with a new subject so we can discuss :) > >> 14.3 calendar-bind Privilege > >> Recipient header. The SCHEDULE request If the server's calendar-bind >> privilege check fails for a given inbox, the rest of the SCHEDULE > > I think the "The SCHEDULE request " there is a cut+pasto. Correct > >> 15.1 calendar-time-range Report > > Need to clarify how free/busy works in CalDAV (probably with an > explicit > example). Do you have to request the Vfreebusy component-filter? What > does the response data look like? The text sort of implies that view- > free-busy gives you the ability to ask for and see the dtstart and > dtend > of VEVENTs, as opposed to just asking for a time range and getting back > a VFREEBUSY object containing anonymous time ranges. > > If the response uses VFREEBUSY, are BUSY-TENTATIVE and BUSY-UNAVAILABLE > periods ever used? (Perhaps the server MAY return BUSY-TENTATIVE > periods > corresponding to unprocessed invites, and MAY allow the user to mark a > time period BUSY-UNAVAILABLE?) Agreed. For now this is a TODO in the spec. > >> 15.1.2 Response to 'calendar-time-range' > >> The response to this report is a WebDAV Multi-Status response, >> containing one element for each event AND for each >> recurrence. This differs from the PROPFIND response to an event >> collection only in that the relevant recurrences each have their own >> element, not just the master event. > > That's sort of ambiguous about whether or not the master event is > returned. Oooh, good point. I intended one resource for each recurrence. > > -- Dan > > Thanks Dan! Great review.