Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DF1917F5A8 for ; Wed, 25 Jan 2006 10:59:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C92D3142295 for ; Wed, 25 Jan 2006 10:59:54 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21745-04 for ; Wed, 25 Jan 2006 10:59:54 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 965EC142280 for ; Wed, 25 Jan 2006 10:59:54 -0800 (PST) Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k0PIxnGN007093; Wed, 25 Jan 2006 10:59:51 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay7.apple.com (Apple SCV relay) with ESMTP id F2B2A155; Wed, 25 Jan 2006 10:59:48 -0800 (PST) In-Reply-To: <43D6D624.5020209@oracle.com> References: <43D6D624.5020209@oracle.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] supported-calendar-component-set Date: Wed, 25 Jan 2006 10:59:46 -0800 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, SUBJ_HAS_UNIQ_ID X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 25 Jan 2006 18:59:55 -0000 Perfect, thanks. -wsv On Jan 24, 2006, at 5:36 PM, Bernard Desruisseaux wrote: > Wilfredo, > > There is a precondition defined for this purpose. See section > 5.3.2. Creating Calendar Object Resources: > > Additional Preconditions for PUT within calendar collections: > > [...] > > (CALDAV:supported-calendar-component): The resource submitted in > the PUT request MUST contain a type of calendar component =20 > that is > supported in the targeted calendar collection; and > > Cheers, > Bernard > > Wilfredo S=E1nchez Vega wrote: >> I'm looking at the example section 5.3.1.2 in draft-09 and I'm =20 >> wondering what happens if I send the server one of more component =20= >> types in the supported-calendar-component-set that the server =20 >> doesn't support. >> Should I expect the server to: >> 1- Include the component in the supported list anyway >> ie. is a server required to store any calendar component type? >> 2- Silently remove the unsupported components from my list. >> 3- Return an error. If so: >> a- Which status code? NOT_IMPLEMENTED? FORBIDDEN? >> b- There's no pre/postcondition element defined for this =20 >> condition AFAICT >> In the case of this example, say I'm talking to a to-do server =20 >> that knows about VTODO but doesn't know about VEVENT. >> Thanks, >> -wsv >> _______________________________________________ >> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 13E7A7F545 for ; Tue, 24 Jan 2006 17:36:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1A53142295 for ; Tue, 24 Jan 2006 17:36:47 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25630-05 for ; Tue, 24 Jan 2006 17:36:47 -0800 (PST) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B0418142291 for ; Tue, 24 Jan 2006 17:36:47 -0800 (PST) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0P1ai80015914; Tue, 24 Jan 2006 19:36:45 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k0P1ahlY003846; Tue, 24 Jan 2006 18:36:43 -0700 Received: from [127.0.0.1] (dhcp-amer-rmdc-csvpn-gw5-141-144-104-128.vpn.oracle.com [141.144.104.128]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k0P1aWi7003794; Tue, 24 Jan 2006 18:36:36 -0700 Message-ID: <43D6D624.5020209@oracle.com> Date: Tue, 24 Jan 2006 20:36:36 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] supported-calendar-component-set References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL, SUBJ_HAS_UNIQ_ID X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 25 Jan 2006 01:36:48 -0000 Wilfredo, There is a precondition defined for this purpose. See section 5.3.2. Creating Calendar Object Resources: Additional Preconditions for PUT within calendar collections: [...] (CALDAV:supported-calendar-component): The resource submitted in the PUT request MUST contain a type of calendar component that is supported in the targeted calendar collection; and Cheers, Bernard Wilfredo Sánchez Vega wrote: > I'm looking at the example section 5.3.1.2 in draft-09 and I'm > wondering what happens if I send the server one of more component types > in the supported-calendar-component-set that the server doesn't support. > > Should I expect the server to: > > 1- Include the component in the supported list anyway > ie. is a server required to store any calendar component type? > > 2- Silently remove the unsupported components from my list. > > 3- Return an error. If so: > a- Which status code? NOT_IMPLEMENTED? FORBIDDEN? > b- There's no pre/postcondition element defined for this > condition AFAICT > > In the case of this example, say I'm talking to a to-do server that > knows about VTODO but doesn't know about VEVENT. > > Thanks, > -wsv > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4ECBB7F56C for ; Tue, 24 Jan 2006 11:16:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3853C142281 for ; Tue, 24 Jan 2006 11:16:09 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07127-02 for ; Tue, 24 Jan 2006 11:16:09 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 15475142280 for ; Tue, 24 Jan 2006 11:16:09 -0800 (PST) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k0OJG6A1002353 for ; Tue, 24 Jan 2006 11:16:08 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay5.apple.com (Apple SCV relay) with ESMTP id B067B324002 for ; Tue, 24 Jan 2006 11:16:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: CalDAV DevList From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Date: Tue, 24 Jan 2006 11:16:05 -0800 X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, SUBJ_HAS_UNIQ_ID X-Spam-Level: Subject: [Ietf-caldav] supported-calendar-component-set X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 24 Jan 2006 19:16:09 -0000 I'm looking at the example section 5.3.1.2 in draft-09 and I'm wondering what happens if I send the server one of more component types in the supported-calendar-component-set that the server doesn't support. Should I expect the server to: 1- Include the component in the supported list anyway ie. is a server required to store any calendar component type? 2- Silently remove the unsupported components from my list. 3- Return an error. If so: a- Which status code? NOT_IMPLEMENTED? FORBIDDEN? b- There's no pre/postcondition element defined for this condition AFAICT In the case of this example, say I'm talking to a to-do server that knows about VTODO but doesn't know about VEVENT. Thanks, -wsv Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ED79C7F535 for ; Wed, 18 Jan 2006 03:44:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DCB09142272 for ; Wed, 18 Jan 2006 03:44:33 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08226-10 for ; Wed, 18 Jan 2006 03:44:33 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 353D4142270 for ; Wed, 18 Jan 2006 03:44:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 85B173984CD for ; Wed, 18 Jan 2006 12:39:57 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-232-130.reverse.mdcc-fun.de [213.211.232.130]) by mail.mdlink.net (Postfix) with ESMTP id CE61E3984C9 for ; Wed, 18 Jan 2006 12:39:56 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43CDA05C.6090303@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> <43CDA05C.6090303@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Wed, 18 Jan 2006 12:44:25 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 18 Jan 2006 11:44:34 -0000 On 18. Jan 2006, at 02:56 Uhr, Jeffrey Harris wrote: > Here's what I (naively) would like to do. Take my original > every Thursday meeting. No invitations, just a public calendar. If > jenny@example.com decides she would like to attend only two > occurrences > (by which I mean individual instances of the expanded recurrence > pattern), I'd like her to be able store a resource that looks like: > > BEGIN:VCALENDAR [entity containing vevents with recurrence-ids but w/o a rrule follows] > This resource specifies no recurrence pattern. I realize that's not > allowed What I don't understand is why Jenny doesn't update the resource containing the rrule? Why do you need to create a _new_ resource just containing the exceptions? [actually I can imagine situations, eg if the public resource is write protected, but in this case you would probably need to resort to copy the event and keep it in sync by other means, eg iMIP messages to the organizer, which should have write access] > I just think that's too bad. :) Well, the rational for that is given in the CalDAV spec very much in the beginning of the text :-) > Chandler doesn't yet have a notion of attendees, so it doesn't really > help to include an exception to the general rule with a different > attendee. I think I begin to understand what you want to do: a) you have a rrule event as one resource in a public calendar collection b) you want to store the exceptions (with the different attendee) in the private calendar collection of 'Jenny' but keep referring the public event by using its UID Honestly I don't think that this makes a lot of sense for various reasons. Instead of doing an unnecessary iCalendar hack like: > X-OSAF-INCLUDE:FALSE why not just filter on the attendee field? Sounds like it would be the same amount of implementation work and is the correct thing to do anyway ... > I'd like to have an interoperable way to suggest that most of a > recurring event isn't included, without confusing things by using a > different UID or specifying a different recurrence pattern. The interoperable way to determine what events to show for a given user is to filter on the attendee. If a user is not really an attendee of the meeting but is "just interested" on changes to the record etc, I would still add the user as an attendee with the NON-PARTICIPANT role (so it will be irrelevant for scheduling, but still be part of iMIP updates and such). CalDAV doesn't really help you with keeping events consistent _across_ collections. The CalDAV rules (like uid<->resource mapping) are all focused on a single collection (correct me if I'm wrong ...). I think if you want to do cross-collection stuff you need to make exact copies and keep them in sync (eg by using iMIP, but automatic approaches could also be possible [some agent running in Chandler which tracks UIDs and merges them on changes]). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 838497F535 for ; Tue, 17 Jan 2006 17:56:54 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 69C8414227B; Tue, 17 Jan 2006 17:56:54 -0800 (PST) Message-ID: <43CDA05C.6090303@osafoundation.org> Date: Tue, 17 Jan 2006 17:56:44 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> In-Reply-To: <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 18 Jan 2006 01:56:54 -0000 Hi Helge, >> This passage doesn't specifically forbid a RECURRENCE-ID in the absence >> of a recurrence rule, but it does implicitly forbid having two >> occurrences with difference RECURRENCE-IDs without having the event that >> defines the whole recurrence pattern. > > Its a bit difficult to follow you because you use different terminology > along your description :-) What do you mean by "occurence" here? I guess > you refer to resources. Sorry, I should've been more clear. The iTIP example confused the issue. Here's what I (naively) would like to do. Take my original every Thursday meeting. No invitations, just a public calendar. If jenny@example.com decides she would like to attend only two occurrences (by which I mean individual instances of the expanded recurrence pattern), I'd like her to be able store a resource that looks like: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RECURRENCE-ID:20060119T104500 SEQUENCE:1 DTSTART:20060119T104500 DTEND:20060119T114500 SUMMARY:OSAF Staff Mtg END:VEVENT BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RECURRENCE-ID:20060126T104500 SEQUENCE:2 DTSTART:20060126T104500 DTEND:20060126T114500 SUMMARY:OSAF Staff Mtg END:VEVENT END:VCALENDAR This resource specifies no recurrence pattern. I realize that's not allowed, I just think that's too bad. :) Chandler doesn't yet have a notion of attendees, so it doesn't really help to include an exception to the general rule with a different attendee. My workaround for dealing with this use case will likely look something like: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RRULE:FREQ=WEEKLY SEQUENCE:0 DTSTART:20040527T104500 DTEND:20040527T114500 SUMMARY:OSAF Staff Mtg X-OSAF-INCLUDE:FALSE END:VEVENT BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RECURRENCE-ID:20060119T104500 SEQUENCE:1 DTSTART:20060119T104500 DTEND:20060119T114500 SUMMARY:OSAF Staff Mtg X-OSAF-INCLUDE:TRUE END:VEVENT BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RECURRENCE-ID:20060126T104500 SEQUENCE:2 DTSTART:20060126T104500 DTEND:20060126T114500 SUMMARY:OSAF Staff Mtg X-OSAF-INCLUDE:TRUE END:VEVENT END:VCALENDAR I'd like to have an interoperable way to suggest that most of a recurring event isn't included, without confusing things by using a different UID or specifying a different recurrence pattern. Sincerely, Jeffrey Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 203027F545 for ; Tue, 17 Jan 2006 16:20:13 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A3B5142283 for ; Tue, 17 Jan 2006 16:20:13 -0800 (PST) Message-ID: <43CD89B3.2060707@osafoundation.org> Date: Tue, 17 Jan 2006 16:20:03 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> <43CD479D.1070705@Royer.com> In-Reply-To: <43CD479D.1070705@Royer.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 18 Jan 2006 00:20:13 -0000 Hi Doug, > Many seem to confuse what is sent over the wire with the contents > of the calendar store. Indeed, I do confuse these things occasionally. > You can generate a single instance (NO RRULE) VEVENT/REQUEST > and send it to anyone. And it does not need the RRULE or > RECURRENCE-ID as long as your code knows when it gets > the REPLY to match it up with what was sent. iTIP is a little off topic for the caldav list, perhaps this portion of the discussion should move to a different list. Since I don't know which list, I'll continue here, though: So in iTIP you're saying it's acceptable to send an invitation to a few instances of a recurring event, but not to all of them, and the VEVENTs on the wire are allowed to have the same UIDs as the full recurring event? I suppose there's no iCalendar idempotency god up in the sky, but this seems somehow wrong to me. If not, great. > Is what really seems to be your problem is tying that > unique VEVENT back to your store. Not really. The problem is that the CalDAV server becomes the source of truth about events, not my data store. If I can't express this use case in valid CalDAV semantics that preserve the identities of events, that makes things a little more bumpy for me. Again, I can work around it, it's certainly not a show stopper. Sincerely, Jeffrey Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7E07B7F565 for ; Tue, 17 Jan 2006 11:53:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6E190142276 for ; Tue, 17 Jan 2006 11:53:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25699-07 for ; Tue, 17 Jan 2006 11:53:57 -0800 (PST) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id D43AC142273 for ; Tue, 17 Jan 2006 11:53:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 566393975DE for ; Tue, 17 Jan 2006 20:49:16 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-232-130.reverse.mdcc-fun.de [213.211.232.130]) by mail.mdlink.net (Postfix) with ESMTP id EB2A93950A8 for ; Tue, 17 Jan 2006 20:49:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <43CD457F.5000900@osafoundation.org> References: <43CD457F.5000900@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3e14252d15d649deaa33a97a9f0a797f@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Recurrence exception without master? Date: Tue, 17 Jan 2006 20:53:54 +0100 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jan 2006 19:53:57 -0000 On Jan 17, 2006, at 20:29, Jeffrey Harris wrote: > As far as I can tell, this isn't allowed in iTIP, you can't invite > someone to a subset of a recurring meeting. Really? Wouldn't that be a regular exception? > Is the same true of CalDAV > resources, a resource cannot represent a subset of a recurring event? A resource cannot contain a (connected) exception for a _different_ resource. Exceptions must be stored together with the "master" vevent (in the same resource). > This passage doesn't specifically forbid a RECURRENCE-ID in the absence > of a recurrence rule, but it does implicitly forbid having two > occurrences with difference RECURRENCE-IDs without having the event > that > defines the whole recurrence pattern. Its a bit difficult to follow you because you use different terminology along your description :-) What do you mean by "occurence" here? I guess you refer to resources. CalDAV states that all events with the same UID MUST be contained in the same HTTP resource (so there is a 1:1 mapping between UIDs and relative resource names). For recurrences that means that a single HTTP resource contains the "master" vevent and all vevents for the exceptions, in your case: ---snip--- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 DTSTART:20040527T104500 DTEND:20040527T114500 RRULE:FREQ=WEEKLY SUMMARY:OSAF Staff Mtg END:VEVENT BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RECURRENCE-ID:20060119T104500 SEQUENCE:1 ORGANIZER:Mailto:jeffrey@osafoundation.org ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:jeffrey@osafoundation.org ATTENDEE:Mailto:A@example.com DTSTART:20060119T104500 DTEND:20060119T114500 SUMMARY:OSAF Staff Mtg END:VEVENT END:VCALENDAR ---snap--- Not sure whether this answers your question. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2F6CD7F564 for ; Tue, 17 Jan 2006 11:38:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D443714227B for ; Tue, 17 Jan 2006 11:38:08 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19921-07 for ; Tue, 17 Jan 2006 11:38:08 -0800 (PST) Received: from S4.cableone.net (s4.cableone.net [24.116.0.230]) by laweleka.osafoundation.org (Postfix) with ESMTP id 21CF7142278 for ; Tue, 17 Jan 2006 11:38:08 -0800 (PST) Received: from [192.168.168.10] (unverified [24.119.163.152]) by S4.cableone.net (CableOne SMTP Service S4) with ESMTP id 43093106 for ; Tue, 17 Jan 2006 13:06:57 -0700 Message-ID: <43CD479D.1070705@Royer.com> Date: Tue, 17 Jan 2006 12:38:05 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Recurrence exception without master? References: <43CD457F.5000900@osafoundation.org> In-Reply-To: <43CD457F.5000900@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020002080807030503020002" X-SpamDetect: ***: 3.250000 Content: cid=309(2.0) =2.0,NakedCR=2.0,Aspam=-0.8 X-NakedCr: Body contained naked cr characters X-NotAscii: charset=utf-8; X-IP-stats: Incoming Outgoing Last 0, First 27, in=88, out=79, spam=0 Known=true X-External-IP: 24.119.163.152 X-Abuse-Info: Send abuse complaints to abuse@cableone.net X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-caldav@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: Tue, 17 Jan 2006 19:38:09 -0000 This is a cryptographically signed message in MIME format. --------------ms020002080807030503020002 Content-Type: multipart/mixed; boundary="------------020804080706020402020609" This is a multi-part message in MIME format. --------------020804080706020402020609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Many seem to confuse what is sent over the wire with the contents of the calendar store. You can generate a single instance (NO RRULE) VEVENT/REQUEST and send it to anyone. And it does not need the RRULE or RECURRENCE-ID as long as your code knows when it gets the REPLY to match it up with what was sent. Is what really seems to be your problem is tying that unique VEVENT back to your store. Jeffrey Harris wrote: > Hi Folks, > > In working on recurrence for Chandler at OSAF, I've come across an > interesting use case that I think isn't possible with CalDAV. I'm > prepared to work around this in Chandler, but I want to make sure this > won't work. > > Take a recurring meeting. > > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:-//PYVOBJECT//NONSGML Version 1//EN > BEGIN:VEVENT > UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 > DTSTART:20040527T104500 > DTEND:20040527T114500 > RRULE:FREQ=WEEKLY > SUMMARY:OSAF Staff Mtg > END:VEVENT > END:VCALENDAR > > Suppose I want to invite A@example.com to just one occurrence of this > meeting, say, > > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:-//PYVOBJECT//NONSGML Version 1//EN > BEGIN:VEVENT > UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 > RECURRENCE-ID:20060119T104500 > SEQUENCE:1 > ORGANIZER:Mailto:jeffrey@osafoundation.org > ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:jeffrey@osafoundation.org > ATTENDEE:Mailto:A@example.com > DTSTART:20060119T104500 > DTEND:20060119T114500 > SUMMARY:OSAF Staff Mtg > END:VEVENT > END:VCALENDAR > > As far as I can tell, this isn't allowed in iTIP, you can't invite > someone to a subset of a recurring meeting. Is the same true of CalDAV > resources, a resource cannot represent a subset of a recurring event? > That's how I interpret the passage: > > Calendar components with the same UID property value, in a given > calendar collection, MUST be contained in the same calendar object > resource. This ensures that all components in a recurrence "set" are > contained in the same calendar object resource. In that case there > will be one component without a RECURRENCE-ID property (the component > that defines the recurrence pattern) and all the rest will have that > property (these are the recurrence exceptions). > > This passage doesn't specifically forbid a RECURRENCE-ID in the absence > of a recurrence rule, but it does implicitly forbid having two > occurrences with difference RECURRENCE-IDs without having the event that > defines the whole recurrence pattern. > > In Chandler, it would be natural to allow someone to subscribe to a > calendar with a recurring meeting and choose just a few meetings to > attend, dragging those occurrences into their personal calendar. As far > as I can tell, to support this functionality and still sync to a CalDAV > server, I'll need to make a copy of the exceptions of interest, > assigning a new UID. > > Sincerely, > Jeffrey > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020804080706020402020609 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;;;;;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: Support@INET-Consulting.com=0D=0A= Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard --------------020804080706020402020609-- --------------ms020002080807030503020002 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMzDCC 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+P7FTCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJKoZIhvcNAQEFBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDUwOTE4MDAw MDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZ BFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcXyhjd000rAUjGGRvVkyBX 6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn/F5GRB/nwlOS3ip2Q+30 AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwch1k9f48As0/8YCstHjka 32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5ojZ8hCYUo6H6hZanIyqd ptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zXAgMBAAGjgcswgcgwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYDVR0fBCwwKjAooCagJIYi aHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQUFAAOBgQBT 5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+I+GfeEZ8087H9QKcBrrU eXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xKI/vH7PFBoa2bfMAxSfGO UEBY2wBeWT4QhxxV3TuDSI3NgzCCBK8wggQYoAMCAQICEFsGSvEntexpo94qqcjJuhAwDQYJ KoZIhvcNAQEFBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwHhcNMDUwOTE4MDAwMDAwWhcNMDYwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxU RChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0 YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBS b3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDZBFhLbROJ3gBYIeuP8+vR6G9dT4K3lXeeK+a9TO0qfqkxm6B3RDcX yhjd000rAUjGGRvVkyBX6EjXkqCILRMAkbU5Zvk8nMyh0a27CzZH5JPHgw9bUutozhECZSDn /F5GRB/nwlOS3ip2Q+30AvwX7x2h/12yyjyO9op9HIZLnpKXqgJETp/fmiOgfPg7xu8OBrwc h1k9f48As0/8YCstHjka32q/jEqWboVtE40sk48ROWca6KMLXli3HfVdj/NIZkYc8UFjK6Y5 ojZ8hCYUo6H6hZanIyqdptDd5T5/TuQHcJH7M6kq/BUgTzDJgRXdQEPxISfZGCRj7NckF5zX AgMBAAGjgcswgcgwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYI KwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAUBgpghkgBhvhFAQYHBAYWBE5vbmUwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkq hkiG9w0BAQUFAAOBgQBT5VLp42EyzXxqDBuVNmtAkVqt6U3GOY9gWKUUzBSRtlepDPiR3yF+ I+GfeEZ8087H9QKcBrrUeXQlQ68hFm/nH1XVTVGdQ3wZOSnC/6JrZUvlurzw9bjjXXaUx2xK I/vH7PFBoa2bfMAxSfGOUEBY2wBeWT4QhxxV3TuDSI3NgzGCBKowggSmAgEBMIHhMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnI yboQMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA2MDExNzE5MzgwNVowIwYJKoZIhvcNAQkEMRYEFEwkT7eOb+2rNue1uZlk22Yc QyScMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQxgeQwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFsGSvEntexp o94qqcjJuhAwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZl cmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBbBkrxJ7XsaaPeKqnIyboQMA0GCSqGSIb3DQEBAQUA BIIBAHPTtiaeXAhQaSLSOkcLQ+sqqehdPtxXhKORQr2eT7SvPucIqxb8Q7vglO6m4eINrPNq IDZ1Rinc8vpf8OjY0JjK1JAqPY8SR/BaLx//mCexSzEAIn/K9d54z61KUTaYF5iyimRwzLIN oaif0ycbZZSzBtlGAGTQDotD7OJ3OFnSq/ZuhTFGc54kS7EX64ViBx4igomAZka6rvRsvPKu MVGOEm53aEpitHbWJ7d0Dst7uSrYgQq5UJHdL4JRHJtUQrxsrsL5WYpxnGiTnpZw2F3YZxlf iDPxJrgHn9GPNi9DV5UU3bSqeOC16+kijCdDbv8zu+M2B1tD7MoUvvdFitEAAAAAAAA= --------------ms020002080807030503020002-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C8D877F57C for ; Tue, 17 Jan 2006 11:29:10 -0800 (PST) Received: from [192.168.101.74] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B17B414226E for ; Tue, 17 Jan 2006 11:29:10 -0800 (PST) Message-ID: <43CD457F.5000900@osafoundation.org> Date: Tue, 17 Jan 2006 11:29:03 -0800 From: Jeffrey Harris User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Ietf-caldav] Recurrence exception without master? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 17 Jan 2006 19:29:10 -0000 Hi Folks, In working on recurrence for Chandler at OSAF, I've come across an interesting use case that I think isn't possible with CalDAV. I'm prepared to work around this in Chandler, but I want to make sure this won't work. Take a recurring meeting. BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 DTSTART:20040527T104500 DTEND:20040527T114500 RRULE:FREQ=WEEKLY SUMMARY:OSAF Staff Mtg END:VEVENT END:VCALENDAR Suppose I want to invite A@example.com to just one occurrence of this meeting, say, BEGIN:VCALENDAR VERSION:2.0 PRODID:-//PYVOBJECT//NONSGML Version 1//EN BEGIN:VEVENT UID:829970E6-9865-41F6-8B4A-D672F8F93CC0 RECURRENCE-ID:20060119T104500 SEQUENCE:1 ORGANIZER:Mailto:jeffrey@osafoundation.org ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:jeffrey@osafoundation.org ATTENDEE:Mailto:A@example.com DTSTART:20060119T104500 DTEND:20060119T114500 SUMMARY:OSAF Staff Mtg END:VEVENT END:VCALENDAR As far as I can tell, this isn't allowed in iTIP, you can't invite someone to a subset of a recurring meeting. Is the same true of CalDAV resources, a resource cannot represent a subset of a recurring event? That's how I interpret the passage: Calendar components with the same UID property value, in a given calendar collection, MUST be contained in the same calendar object resource. This ensures that all components in a recurrence "set" are contained in the same calendar object resource. In that case there will be one component without a RECURRENCE-ID property (the component that defines the recurrence pattern) and all the rest will have that property (these are the recurrence exceptions). This passage doesn't specifically forbid a RECURRENCE-ID in the absence of a recurrence rule, but it does implicitly forbid having two occurrences with difference RECURRENCE-IDs without having the event that defines the whole recurrence pattern. In Chandler, it would be natural to allow someone to subscribe to a calendar with a recurring meeting and choose just a few meetings to attend, dragging those occurrences into their personal calendar. As far as I can tell, to support this functionality and still sync to a CalDAV server, I'll need to make a copy of the exceptions of interest, assigning a new UID. Sincerely, Jeffrey Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 31D2B7F5B2 for ; Thu, 5 Jan 2006 07:28:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 223221422B5 for ; Thu, 5 Jan 2006 07:28:56 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31644-01 for ; Thu, 5 Jan 2006 07:28:56 -0800 (PST) Received: from linux.site (unknown [202.144.95.244]) by laweleka.osafoundation.org (Postfix) with ESMTP id B19441422B4 for ; Thu, 5 Jan 2006 07:28:55 -0800 (PST) Received: by linux.site (Postfix, from userid 1000) id 961662C138; Thu, 5 Jan 2006 20:59:46 +0530 (IST) From: pnayak To: CalDAV DevList , "ietf-calendar@imc.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 05 Jan 2006 20:59:46 +0530 Message-Id: <1136474986.8953.8.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: X-Mailman-Approved-At: Mon, 09 Jan 2006 08:52:31 -0800 Subject: [Ietf-caldav] CalDAV server X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 05 Jan 2006 15:28:56 -0000 Hi I am sorry if I am not supposed to send this message in this list. I would like to know if any CalDAV server is ready as on date. I wanted this info to test caldav support in 'Evolution' client. Thanks Poornima Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 365DC7F553; Wed, 4 Jan 2006 13:23:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 24DDC1422A3; Wed, 4 Jan 2006 13:23:52 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30042-10; Wed, 4 Jan 2006 13:23:51 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C07B814226F; Wed, 4 Jan 2006 13:23:51 -0800 (PST) Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k04LNo6L017495; Wed, 4 Jan 2006 13:23:50 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay8.apple.com (Apple SCV relay) with ESMTP id E5F653B8; Wed, 4 Jan 2006 13:23:49 -0800 (PST) In-Reply-To: <29783137fcee7b8bc7e03a4be50a13ba@osafoundation.org> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> <47EE239B-53CB-4185-8DC3-1344EEB6D8BC@opengroupware.org> <43AD1F95.2090703@gmx.de> <29783137fcee7b8bc7e03a4be50a13ba@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7176A495-5A94-43CB-86E3-CC578A18166E@apple.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Wed, 4 Jan 2006 13:23:49 -0800 To: Lisa Dusseault X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 04 Jan 2006 21:23:52 -0000 Well, a better version of that idea is to go ahead and assign strong etags, but disallow content changes during the first second that file is created. Weak etags shouldn't be necessary in that case at all. It does create a situation where a PUT would result in a FORBIDDEN response for a short period, not sure how people would feel about that. Perhaps a harder problem is that there are other ways for content to change, and you'd have to cover them all. Unfortunately, on some servers, content is modified by software other than the HTTP server, so you can't make this guarantee; in those cases you could then end up with an unchanged etag backed by changed content, which is, I think a more untenable situation than the current one, at least for people to whom that might be a usage scenario. You could then work around that problem by keeping the "weak etag for the first second" logic in place, but then you've got a very slight improvement (more in spec, but not in a way that helps any existing clients; remember the main complaints are the changed etag with not content change and the weak->strong transition, and we'd still have these) over the status quo regarding etags, and this new baggage of (probably unexpected by clients) FORBIDDEN responses in the first second. -wsv On Dec 25, 2005, at 9:15 AM, Lisa Dusseault wrote: > That does suggest a way for Apache to avoid the within-second > overwrite risk: to disallow PUT operations while there's a weak > ETag. That would be consistent with HTTP as far as I can see. It > would still, however, theoretically cause clients to reload the > resource content when the server switches to the strong ETag. > > lisa > > On Dec 24, 2005, at 2:14 AM, Julian Reschke wrote: > >> Helge Hess wrote: >>> On 24. Dez 2005, at 01:31 Uhr, Mike Shaver wrote: >>>> On 12/22/05, Julian Reschke wrote: >>>>> Apache simply has decided that multiple updates within one >>>>> second *are* >>>>> semantically equivalent. >>>> >>>> Do you mean to indicate that such a decision on the part of >>>> Apache is >>>> reasonable, given the requirements of the HTTP specification? It >>>> certainly doesn't seem that way to me, but I am probably the >>>> biggest >>>> HTTP dullard on this list, so I'm happy to learn. >>> Maybe I'm wrong but if I understood Julian correctly Apache will >>> ensure that there will be only one PUT in the timeframe of 1s. If >>> the server ensures that, a timestamp with 1s granularity should >>> be enough for an etag? >> >> No, that's not what I intended to say. As far as I know, it >> currently allows multiple PUTs. >> >> Best regards, Julian >> _______________________________________________ >> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7789E7F521 for ; Wed, 4 Jan 2006 13:12:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 66F531422A3 for ; Wed, 4 Jan 2006 13:12:58 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07637-01 for ; Wed, 4 Jan 2006 13:12:58 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F7F81422A2 for ; Wed, 4 Jan 2006 13:12:58 -0800 (PST) Received: from relay7.apple.com (a17-128-113-37.apple.com [17.128.113.37]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k04LCrqM015675; Wed, 4 Jan 2006 13:12:53 -0800 (PST) Received: from [17.221.42.43] (pucca.apple.com [17.221.42.43]) by relay7.apple.com (Apple SCV relay) with ESMTP id A770983; Wed, 4 Jan 2006 13:12:53 -0800 (PST) In-Reply-To: <43AD1F95.2090703@gmx.de> References: <9FCE89D6-3ECC-4AAC-BF1A-A878F7A8E199@opengroupware.org> <66f2f334f39a5bce0b411db90922a8b4@osafoundation.org> <43AAF5F6.4080507@gmx.de> <47EE239B-53CB-4185-8DC3-1344EEB6D8BC@opengroupware.org> <43AD1F95.2090703@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= Subject: Re: [Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis Date: Wed, 4 Jan 2006 13:12:52 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.2 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 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, 04 Jan 2006 21:12:59 -0000 On Dec 24, 2005, at 2:14 AM, Julian Reschke wrote: >> Maybe I'm wrong but if I understood Julian correctly Apache will >> ensure that there will be only one PUT in the timeframe of 1s. If >> the server ensures that, a timestamp with 1s granularity should be >> enough for an etag? > > No, that's not what I intended to say. As far as I know, it > currently allows multiple PUTs. This is correct. -wsv