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 9337280844 for ; Thu, 17 Jan 2008 12:17:33 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F3CAB14227E for ; Thu, 17 Jan 2008 12:17:15 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 w3DyS5FGhRSz for ; Thu, 17 Jan 2008 12:17:09 -0800 (PST) Received: from mail.franticfilms.com (mail.franticfilms.com [139.142.208.99]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9DFCA142217 for ; Thu, 17 Jan 2008 12:17:07 -0800 (PST) Received: from [10.0.10.28] (foo.franticfilms.com [139.142.208.98]) by mail.franticfilms.com (Postfix) with ESMTP id 069A8B04BD for ; Thu, 17 Jan 2008 14:17:05 -0600 (CST) Message-ID: <478FB7DB.90500@franticfilms.com> Date: Thu, 17 Jan 2008 14:17:31 -0600 From: Josh Millar-Usiskin User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ietf-caldav] Processing the ScheduleInbox 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, 17 Jan 2008 20:17:33 -0000 Hello everyone. I am currently developing a CalDAV(-schedule) API library. I've been using the CalDAV and CalDAV-schedule RFCs as reference. One thing that I believe CalDAV-schedule has missed is how to determine which calendar collection a message is dealing with. I have two use cases of concern: 1) Upon receiving the first REQUEST message, which calendar collection should the event be created in, if accepted? 2) Upon receiving an update REQUEST message, the only way that I can think of to match the message to the calendar object resource is by UID. But according to CalDAV [RFC 4791], a UID is only unique for a particular calendar collection. Conceivably, there could be two events with the same UID in separate calendar collections for the acting CU. Any insight that I may have overlooked would be greatly appreciated. Thanks, Josh Usiskin 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 CA43A8058E for ; Tue, 15 Jan 2008 07:20:09 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2AFAF142254 for ; Tue, 15 Jan 2008 07:20:12 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-50 required=4 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.001] 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 jUddCXp1Euq2 for ; Tue, 15 Jan 2008 07:20:10 -0800 (PST) Received: from mail.uk.scalix.com (mail.uk.scalix.com [85.118.4.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E343C14227E for ; Tue, 15 Jan 2008 07:20:09 -0800 (PST) Received: from mail.uk.scalix.com (localhost.localdomain [127.0.0.1]) by mail.uk.scalix.com (8.13.8/8.13.8) with ESMTP id m0FFK4tL007580 for ; Tue, 15 Jan 2008 15:20:04 GMT Received: from crowley.uk.scalix.com (crowley.uk.scalix.com [10.11.108.213]) by mail.uk.scalix.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Tue, 15 Jan 2008 15:20:03 +0000 (GMT) Date: Tue, 15 Jan 2008 15:20:02 +0000 From: Gren Elliot To: CalDAV DevList Message-ID: <478CCF22.8040208@scalix.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 Content-Type: text/html; charset="US-ASCII" Content-Disposition: inline Subject: [Ietf-caldav] draft-desruisseaux-caldav-sched-04 a few potential corrections 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, 15 Jan 2008 15:20:09 -0000 Hi,

draft-desruisseaux-caldav-sched-04 section 5.4.1 on Conformance says :
Conformance:  This property MUST be protected and SHOULD NOT be
      returned by [RFC4918]).
I assume this should be like text elsewhere :
   Conformance:  This property MUST be protected and SHOULD NOT be
      returned by a PROPFIND allprop request (as defined in Section 14.2
      of [RFC4918]).

----------------------------------------
9.1.5.  CALDAV:schedule-post-vfreebusy Privilege
   The CALDAV:schedule-post-vfreebusy privilege controls the use of the
   POST method to submit scheduling messages for VFREEBUSY calendar
   components on the resource.  It is ignored for resources that are not
   scheduling Outbox collections.

   <!ELEMENT schedule-post-vfreebusy EMPTY >
I assume this is talking about requesting FREEBUSY information by posting to the outbox URL? If so, I would prefer wording something like

   The CALDAV:schedule-post-vfreebusy privilege controls the use of the
   POST method to request FREEBUSY information. It is ignored for resources that are not
   scheduling Outbox collections.
as to me, asking for freebusy information is not the same as submitting a scheduling message.

Regards,
Gren.

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 22F6F80ADD for ; Mon, 7 Jan 2008 08:20:09 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7123014229B for ; Mon, 7 Jan 2008 08:20:11 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-50 required=4 tests=[AWL=0.259, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 wCH2s1jA7eXY for ; Mon, 7 Jan 2008 08:20:08 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 79029142254 for ; Mon, 7 Jan 2008 08:20:08 -0800 (PST) Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m07GK3ce022460; Mon, 7 Jan 2008 09:20:04 -0700 Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m07CYi3T004858; Mon, 7 Jan 2008 09:20:00 -0700 Received: from bdesruis-ca.ca.oracle.com by acsmt350.oracle.com with ESMTP id 3481207391199722737; Mon, 07 Jan 2008 08:18:57 -0800 Message-ID: <478250F0.3040406@oracle.com> Date: Mon, 07 Jan 2008 11:18:56 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gren Elliot Subject: Re: [Ietf-caldav] draft-desruisseaux-caldav-sched-04 PROPPATCH precondition CALDAV:valid-free-busy-set References: <47824016.7020403@scalix.com> In-Reply-To: <47824016.7020403@scalix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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: Mon, 07 Jan 2008 16:20:09 -0000 Hi Gren, The text currently specify when the precondition identifier is returned in the response of a failed PROPPATCH request. We should rephrase this to specify what is the actual requirement instead. Thanks for pointing this out. Cheers, Bernard Gren Elliot wrote: > Hi, > > draft-desruisseaux-caldav-sched-04 Section 5.3.2 Additional > Precondition for PROPPATCH > says the precondition is : > > (CALDAV:valid-free-busy-set): One or more resources referenced in > a CALDAV:calendar-free-busy-set property being stored on a > scheduling Inbox collection is invalid. > > Should the "invalid" read "valid"? I can understand that some of the > resources might be invalid due to calendar deletions or future additions > but requiring one to be invalid seems wrong. > > Regards, > Gren. > _______________________________________________ > 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 13FCA80B13 for ; Mon, 7 Jan 2008 07:07:09 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 62045142254 for ; Mon, 7 Jan 2008 07:07:11 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 DP0X2rbHwhKr for ; Mon, 7 Jan 2008 07:07:08 -0800 (PST) Received: from mail.uk.scalix.com (mail.uk.scalix.com [85.118.4.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A09AC142207 for ; Mon, 7 Jan 2008 07:07:08 -0800 (PST) Received: from mail.uk.scalix.com (localhost.localdomain [127.0.0.1]) by mail.uk.scalix.com (8.13.8/8.13.8) with ESMTP id m07F73ng030594 for ; Mon, 7 Jan 2008 15:07:03 GMT Received: from crowley.uk.scalix.com (crowley.uk.scalix.com [10.11.108.213]) by mail.uk.scalix.com (Scalix SMTP Relay 11.3.0.11339) via ESMTP; Mon, 07 Jan 2008 15:07:03 +0000 (GMT) Date: Mon, 7 Jan 2008 15:07:02 +0000 From: Gren Elliot To: CalDAV DevList Message-ID: <47824016.7020403@scalix.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Ietf-caldav] draft-desruisseaux-caldav-sched-04 PROPPATCH precondition CALDAV:valid-free-busy-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: Mon, 07 Jan 2008 15:07:09 -0000 Hi, draft-desruisseaux-caldav-sched-04 Section 5.3.2 Additional Precondition for PROPPATCH says the precondition is : (CALDAV:valid-free-busy-set): One or more resources referenced in a CALDAV:calendar-free-busy-set property being stored on a scheduling Inbox collection is invalid. Should the "invalid" read "valid"? I can understand that some of the resources might be invalid due to calendar deletions or future additions but requiring one to be invalid seems wrong. Regards, Gren.