From julian.reschke@gmx.de Mon Jul 13 04:52:27 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC093A6D86 for ; Mon, 13 Jul 2009 04:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcTIo0JrmobW for ; Mon, 13 Jul 2009 04:52:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8271128C36B for ; Mon, 13 Jul 2009 04:52:26 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2009 11:46:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 13 Jul 2009 13:46:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/dskJcQILdhjkWDqf6BUz0oAkDeY86ieYxrMKx/4 LqJD8DB1J/V5zB Message-ID: <4A5B1E76.7020803@gmx.de> Date: Mon, 13 Jul 2009 13:45:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bernard Desruisseaux References: <4A40F50F.3030002@oracle.com> In-Reply-To: <4A40F50F.3030002@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 11:52:27 -0000 Bernard Desruisseaux wrote: > Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF > last week. See Internet-Draft announcement below. > > Before requesting the IESG to consider this Internet-Draft as a Proposed > Standard, we would like to get as much feedback as possible from the > participants of the "caldav" mailing list as well as from the members of > the WebDAV and Calsify Working Groups. > > Please review the document and send your comments to the caldav@ietf.org > mailing list by July 7th, 2009. > > We would like to submit draft -08 before July 13, 2009, i.e., the final > submission cut-off for the 75th IETF in Stockholm, Sweden. > ... Hi Bernard, I'm sorry that I'm late with my feedback (attached below). Most are nits of editorial nature. Also, I have only read the spec from an HTTP/WebDAV point of view, as I'm no expert on calendaring at all. There is a single non-editorial issue I found, and that is the introduction of the scheduling tag, with associated HTTP headers. I think it would be good to discuss this in more detail. BR, Julian --- snip --- 1.5. XML Namespaces and Processing Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of [W3C.REC-xml-20081126]. JR: should this be a section reference? The XML declarations used in this document do not include namespace information. Thus, implementers must not use these declarations as the only way to create valid CalDAV properties or to validate CalDAV XML element type. Some of the declarations refer to XML elements JR: I realize this sentence is borrowed from 4791. Does anybody recall what the "...create valid CalDAV properties..." refers to? What does the DTD have to do with that? 4.1. Scheduling Outbox Collection While there is currently no defined use for child resources in a scheduling Outbox collection, a scheduling Outbox collection MAY contain child resources. JR: may say "...MAY contain child resources, whose semantics are undefined for now..."? ...if this is correct, is it planned to add semantics later? How? 4.2. Scheduling Inbox Collection Scheduling Inbox collections MUST only contain calendar object resources that obey the restrictions specified in iTIP [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox collections MUST NOT contain any types of collection resources. Restrictions defined in Section 4.1 of CalDAV "calendar-access" [RFC4791] on calendar object resources contained in calendar collections (e.g., "UID" uniqueness) don't apply to calendar object resources contained in a scheduling Inbox collection. Multiple calendar object resources contained in a scheduling Inbox collection MAY have the same "UID" property value (i.e., multiple scheduling messages for the same calendar component). JR: last sentence just seems to rephrase the previous one. So maybe say "Thus, ..." and remove the RFC2119 keyword. 5.1. Identifying Scheduling Object Resources Calendar object resources on which the server performs automatic scheduling transactons are refered to as scheduling object resources. JR: spelling. 5.2.1.1. Create The attempt to deliver the scheduling message will either succeed or fail. In all cases, the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter (see Section 10.3) to the "ATTENDEE" iCalendar property in the scheduling object resource being created, and set its value as described in Section 9.2. This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server as soon as it is created on the server in order to update to the new server generated state information. The "MAY" doesn't seem to be right here. This is not an interop requirement but simply a statement of fact. They "MAY" reload whenever they want anyway :-) (there are more occurrences of this language later on). 7.2.7. CALDAV:max-resource-size Precondition Name: max-resource-size Namespace: urn:ietf:params:xml:ns:caldav Apply to: POST Use with: 403 Forbidden Purpose: (precondition) -- The resource submitted in the POST request MUST have an octet size less than or equal to the value of JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"? 8. Conditional Requests on Scheduling Object Resources In order to do that, this specification introduces a new WebDAV resource property CALDAV:schedule-tag with a corresponding response header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request header to allow client changes to be appropriately merged with server changes in the case where the changes on the server were the result of an "inconsequential" scheduling message update. An "inconsequential" scheduling message is one which simply updates the status information of Attendees due to a reply from an Attendee. JR: that sounds really heavy-weight; I think it would be good to discuss this scenario over on the HTTPbis working group's mailing list. Even if new state tokens need to be added it is not totally clear why the RFC4918 can not be used for checking. 11.1. Schedule-Reply Request Header Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") Example: Schedule-Reply: F When an Attendee executes an HTTP DELETE request on a scheduling object resource, and the Schedule-Reply header is not present, or present and set to the value "T", the server MUST send an appropriate reply scheduling message with the Attendee's "PARTSTAT" iCalendar property parameter value set to "DECLINED" as part of its normal automatic scheduling transaction processing. JR: is this header really really needed? Would it be possible to pass that information in the request body instead? From julian.reschke@gmx.de Mon Jul 13 05:00:32 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43FC28C3ED; Mon, 13 Jul 2009 05:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=-1.322, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcK86ib+-COk; Mon, 13 Jul 2009 05:00:31 -0700 (PDT) Received: from mail384c25.carrierzone.com (mail384c25.carrierzone.com [209.235.146.154]) by core3.amsl.com (Postfix) with ESMTP id 707FD28C3C6; Mon, 13 Jul 2009 05:00:28 -0700 (PDT) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail384c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6DC0qS5025790; Mon, 13 Jul 2009 12:00:53 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Jul 2009 08:00:52 -0400 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07132009-080049-12590.MMD@TencoAssembliesInc.local; Mon, 13 Jul 2009 08:00:49 -0400 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail368c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6DBmBUA004857 for ; Mon, 13 Jul 2009 07:48:13 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MQJzb-0004ez-JC for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jul 2009 11:46:47 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MQJzZ-0004dd-6b for w3c-dist-auth@listhub.w3.org; Mon, 13 Jul 2009 11:46:45 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.63) (envelope-from ) id 1MQJzQ-0006p3-Dw for w3c-dist-auth@w3.org; Mon, 13 Jul 2009 11:46:44 +0000 Received: (qmail invoked by alias); 13 Jul 2009 11:46:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 13 Jul 2009 13:46:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/dskJcQILdhjkWDqf6BUz0oAkDeY86ieYxrMKx/4 LqJD8DB1J/V5zB Message-ID: <4A5B1E76.7020803@gmx.de> Date: Mon, 13 Jul 2009 13:45:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bernard Desruisseaux References: <4A40F50F.3030002@oracle.com> In-Reply-To: <4A40F50F.3030002@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1MQJzQ-0006p3-Dw 972ca17b37d1a3fd277451ffca1b2d33 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13138 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 13 Jul 2009 11:46:47 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 13 Jul 2009 12:00:52.0115 (UTC) FILETIME=[91A5FE30:01CA03B1] Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 12:00:33 -0000 Bernard Desruisseaux wrote: > Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF > last week. See Internet-Draft announcement below. > > Before requesting the IESG to consider this Internet-Draft as a Proposed > Standard, we would like to get as much feedback as possible from the > participants of the "caldav" mailing list as well as from the members of > the WebDAV and Calsify Working Groups. > > Please review the document and send your comments to the caldav@ietf.org > mailing list by July 7th, 2009. > > We would like to submit draft -08 before July 13, 2009, i.e., the final > submission cut-off for the 75th IETF in Stockholm, Sweden. > ... Hi Bernard, I'm sorry that I'm late with my feedback (attached below). Most are nits of editorial nature. Also, I have only read the spec from an HTTP/WebDAV point of view, as I'm no expert on calendaring at all. There is a single non-editorial issue I found, and that is the introduction of the scheduling tag, with associated HTTP headers. I think it would be good to discuss this in more detail. BR, Julian --- snip --- 1.5. XML Namespaces and Processing Definitions of XML elements in this document use XML element type declarations (as found in XML Document Type Declarations), described in Section 3.2 of [W3C.REC-xml-20081126]. JR: should this be a section reference? The XML declarations used in this document do not include namespace information. Thus, implementers must not use these declarations as the only way to create valid CalDAV properties or to validate CalDAV XML element type. Some of the declarations refer to XML elements JR: I realize this sentence is borrowed from 4791. Does anybody recall what the "...create valid CalDAV properties..." refers to? What does the DTD have to do with that? 4.1. Scheduling Outbox Collection While there is currently no defined use for child resources in a scheduling Outbox collection, a scheduling Outbox collection MAY contain child resources. JR: may say "...MAY contain child resources, whose semantics are undefined for now..."? ...if this is correct, is it planned to add semantics later? How? 4.2. Scheduling Inbox Collection Scheduling Inbox collections MUST only contain calendar object resources that obey the restrictions specified in iTIP [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox collections MUST NOT contain any types of collection resources. Restrictions defined in Section 4.1 of CalDAV "calendar-access" [RFC4791] on calendar object resources contained in calendar collections (e.g., "UID" uniqueness) don't apply to calendar object resources contained in a scheduling Inbox collection. Multiple calendar object resources contained in a scheduling Inbox collection MAY have the same "UID" property value (i.e., multiple scheduling messages for the same calendar component). JR: last sentence just seems to rephrase the previous one. So maybe say "Thus, ..." and remove the RFC2119 keyword. 5.1. Identifying Scheduling Object Resources Calendar object resources on which the server performs automatic scheduling transactons are refered to as scheduling object resources. JR: spelling. 5.2.1.1. Create The attempt to deliver the scheduling message will either succeed or fail. In all cases, the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter (see Section 10.3) to the "ATTENDEE" iCalendar property in the scheduling object resource being created, and set its value as described in Section 9.2. This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server as soon as it is created on the server in order to update to the new server generated state information. The "MAY" doesn't seem to be right here. This is not an interop requirement but simply a statement of fact. They "MAY" reload whenever they want anyway :-) (there are more occurrences of this language later on). 7.2.7. CALDAV:max-resource-size Precondition Name: max-resource-size Namespace: urn:ietf:params:xml:ns:caldav Apply to: POST Use with: 403 Forbidden Purpose: (precondition) -- The resource submitted in the POST request MUST have an octet size less than or equal to the value of JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"? 8. Conditional Requests on Scheduling Object Resources In order to do that, this specification introduces a new WebDAV resource property CALDAV:schedule-tag with a corresponding response header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request header to allow client changes to be appropriately merged with server changes in the case where the changes on the server were the result of an "inconsequential" scheduling message update. An "inconsequential" scheduling message is one which simply updates the status information of Attendees due to a reply from an Attendee. JR: that sounds really heavy-weight; I think it would be good to discuss this scenario over on the HTTPbis working group's mailing list. Even if new state tokens need to be added it is not totally clear why the RFC4918 can not be used for checking. 11.1. Schedule-Reply Request Header Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") Example: Schedule-Reply: F When an Attendee executes an HTTP DELETE request on a scheduling object resource, and the Schedule-Reply header is not present, or present and set to the value "T", the server MUST send an appropriate reply scheduling message with the Attendee's "PARTSTAT" iCalendar property parameter value set to "DECLINED" as part of its normal automatic scheduling transaction processing. JR: is this header really really needed? Would it be possible to pass that information in the request body instead? From julian.reschke@gmx.de Mon Jul 13 13:12:07 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23BE528C4CC for ; Mon, 13 Jul 2009 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=-2.612, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yp2DPR7vwBO for ; Mon, 13 Jul 2009 13:12:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4D66C28C4AC for ; Mon, 13 Jul 2009 13:12:05 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2009 20:12:34 -0000 Received: from p508FE94A.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.233.74] by mail.gmx.net (mp034) with SMTP; 13 Jul 2009 22:12:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+/QPNxOVy/VFnwHbmL3SfDSmRe9yRLWjWqIuFLU9 bQYIGCxsQcrflX Message-ID: <4A5B9526.1010900@gmx.de> Date: Mon, 13 Jul 2009 22:12:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bernard Desruisseaux References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> In-Reply-To: <4A5B1E76.7020803@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 20:12:07 -0000 Julian Reschke wrote: > ... > 8. Conditional Requests on Scheduling Object Resources > > In order to do that, this specification introduces a new WebDAV > resource property CALDAV:schedule-tag with a corresponding response > header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request > header to allow client changes to be appropriately merged with server > changes in the case where the changes on the server were the result > of an "inconsequential" scheduling message update. An > "inconsequential" scheduling message is one which simply updates the > status information of Attendees due to a reply from an Attendee. > > JR: that sounds really heavy-weight; I think it would be good to discuss > this scenario over on the HTTPbis working group's mailing list. Even if new > state tokens need to be added it is not totally clear why the RFC4918 > can not be used for checking. > ... Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...". BR, Julian From julian.reschke@gmx.de Mon Jul 13 13:31:09 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B914328C636; Mon, 13 Jul 2009 13:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.191 X-Spam-Level: X-Spam-Status: No, score=-5.191 tagged_above=-999 required=5 tests=[AWL=-2.592, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igskxAirqWLj; Mon, 13 Jul 2009 13:31:08 -0700 (PDT) Received: from mail382c25.carrierzone.com (mail382c25.carrierzone.com [209.235.146.152]) by core3.amsl.com (Postfix) with ESMTP id 4AA0028C2E0; Mon, 13 Jul 2009 13:31:02 -0700 (PDT) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail382c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6DKUsme032747; Mon, 13 Jul 2009 20:30:55 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Jul 2009 16:30:53 -0400 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07132009-163049-12764.MMD@TencoAssembliesInc.local; Mon, 13 Jul 2009 16:30:49 -0400 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail374c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6DKG4ov024252 for ; Mon, 13 Jul 2009 16:16:06 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MQRuj-00076y-RN for w3c-dist-auth-dist@listhub.w3.org; Mon, 13 Jul 2009 20:14:17 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MQRtj-0006zU-HN for w3c-dist-auth@listhub.w3.org; Mon, 13 Jul 2009 20:13:15 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1MQRta-00045b-Ta for w3c-dist-auth@w3.org; Mon, 13 Jul 2009 20:13:15 +0000 Received: (qmail invoked by alias); 13 Jul 2009 20:12:34 -0000 Received: from p508FE94A.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.233.74] by mail.gmx.net (mp034) with SMTP; 13 Jul 2009 22:12:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+/QPNxOVy/VFnwHbmL3SfDSmRe9yRLWjWqIuFLU9 bQYIGCxsQcrflX Message-ID: <4A5B9526.1010900@gmx.de> Date: Mon, 13 Jul 2009 22:12:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bernard Desruisseaux References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> In-Reply-To: <4A5B1E76.7020803@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1MQRta-00045b-Ta 14e30a44ac14a1c38fccbc6728a4aea1 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13139 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Mon, 13 Jul 2009 20:14:17 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 13 Jul 2009 20:30:53.0990 (UTC) FILETIME=[D1C98C60:01CA03F8] Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 20:31:10 -0000 Julian Reschke wrote: > ... > 8. Conditional Requests on Scheduling Object Resources > > In order to do that, this specification introduces a new WebDAV > resource property CALDAV:schedule-tag with a corresponding response > header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request > header to allow client changes to be appropriately merged with server > changes in the case where the changes on the server were the result > of an "inconsequential" scheduling message update. An > "inconsequential" scheduling message is one which simply updates the > status information of Attendees due to a reply from an Attendee. > > JR: that sounds really heavy-weight; I think it would be good to discuss > this scenario over on the HTTPbis working group's mailing list. Even if new > state tokens need to be added it is not totally clear why the RFC4918 > can not be used for checking. > ... Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...". BR, Julian From julian.reschke@gmx.de Tue Jul 14 06:44:21 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19483A6E7C for ; Tue, 14 Jul 2009 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-1.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn4IWomQ45Z1 for ; Tue, 14 Jul 2009 06:44:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E2F043A6EAE for ; Tue, 14 Jul 2009 06:44:02 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2009 12:43:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 14 Jul 2009 14:43:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX187bdsKpZ47ZQe6GzMh/9uzXAIAca0DiwyI5+VYpT VWp/bb1PCnlwri Message-ID: <4A5C7D64.1000109@gmx.de> Date: Tue, 14 Jul 2009 14:43:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bernard Desruisseaux References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> <4A5B9526.1010900@gmx.de> In-Reply-To: <4A5B9526.1010900@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 13:44:21 -0000 Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 8. Conditional Requests on Scheduling Object Resources >> >> In order to do that, this specification introduces a new WebDAV >> resource property CALDAV:schedule-tag with a corresponding response >> header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request >> header to allow client changes to be appropriately merged with server >> changes in the case where the changes on the server were the result >> of an "inconsequential" scheduling message update. An >> "inconsequential" scheduling message is one which simply updates the >> status information of Attendees due to a reply from an Attendee. >> >> JR: that sounds really heavy-weight; I think it would be good to discuss >> this scenario over on the HTTPbis working group's mailing list. Even >> if new >> state tokens need to be added it is not totally clear why the RFC4918 >> can not be used for checking. >> ... > > Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...". > > BR, Julian Expanding on that...: The spec currently introduces a new type of etag, the "schedule-tag", exposed as a live WebDAV property, and a new HTTP response header, plus a new conditional HTTP request header. WebDAV (RFC 4918) however already supports "state tokens" in the "If" header; right now only lock tokens are used, but there is no reason why a protocol wouldn't be able to introduce new state tokens, and allow them to be checked using the "If" header. -- That would at least avoid introducing a new conditional request header. That being said, it would be nice to get rid of the new state tokens ( schedule tags altogether. I do understand the problem with many clients updating the attendee information simultaneously. Two thoughts on this: 1) In general, issues like that can be avoided by enhancing the granularity of the resource that needs to be updated. For instance, the status for each attendee could be modeled as a separate resource, that could then respond to GET/PUT/DELETE. (I guess the server could advertise its URL as a parameter on the ATTENDEE). 2) It may also be possible to use PATCH for updating the attendee status; we would just need to define a simple payload format which can guard the client from unintentionally changing the status on an event that just changed (my understanding is that PATCH is likely to be finished in time for this spec). Best regards, Julian From julian.reschke@gmx.de Tue Jul 14 10:07:51 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CC328C0E0; Tue, 14 Jul 2009 10:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.896 X-Spam-Level: X-Spam-Status: No, score=-3.896 tagged_above=-999 required=5 tests=[AWL=-1.297, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMhOw7FEJPEJ; Tue, 14 Jul 2009 10:07:50 -0700 (PDT) Received: from mail383c25.carrierzone.com (mail383c25.carrierzone.com [209.235.146.153]) by core3.amsl.com (Postfix) with ESMTP id C59253A6917; Tue, 14 Jul 2009 10:07:49 -0700 (PDT) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail383c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6ED0wMb004212; Tue, 14 Jul 2009 13:00:59 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jul 2009 09:00:57 -0400 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07142009-090051-12913.MMD@TencoAssembliesInc.local; Tue, 14 Jul 2009 09:00:51 -0400 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail367c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6ECkmbA010527 for ; Tue, 14 Jul 2009 08:46:51 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MQhNe-00069U-Oy for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jul 2009 12:45:10 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MQhMe-000549-Ej for w3c-dist-auth@listhub.w3.org; Tue, 14 Jul 2009 12:44:08 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.63) (envelope-from ) id 1MQhMU-000506-H4 for w3c-dist-auth@w3.org; Tue, 14 Jul 2009 12:44:08 +0000 Received: (qmail invoked by alias); 14 Jul 2009 12:43:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 14 Jul 2009 14:43:26 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX187bdsKpZ47ZQe6GzMh/9uzXAIAca0DiwyI5+VYpT VWp/bb1PCnlwri Message-ID: <4A5C7D64.1000109@gmx.de> Date: Tue, 14 Jul 2009 14:43:16 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bernard Desruisseaux References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> <4A5B9526.1010900@gmx.de> In-Reply-To: <4A5B9526.1010900@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1MQhMU-000506-H4 dc48fd177a7343491a10e912c9454911 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13140 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 14 Jul 2009 12:45:10 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 14 Jul 2009 13:00:57.0764 (UTC) FILETIME=[21321E40:01CA0483] Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 17:07:51 -0000 Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 8. Conditional Requests on Scheduling Object Resources >> >> In order to do that, this specification introduces a new WebDAV >> resource property CALDAV:schedule-tag with a corresponding response >> header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request >> header to allow client changes to be appropriately merged with server >> changes in the case where the changes on the server were the result >> of an "inconsequential" scheduling message update. An >> "inconsequential" scheduling message is one which simply updates the >> status information of Attendees due to a reply from an Attendee. >> >> JR: that sounds really heavy-weight; I think it would be good to discuss >> this scenario over on the HTTPbis working group's mailing list. Even >> if new >> state tokens need to be added it is not totally clear why the RFC4918 >> can not be used for checking. >> ... > > Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...". > > BR, Julian Expanding on that...: The spec currently introduces a new type of etag, the "schedule-tag", exposed as a live WebDAV property, and a new HTTP response header, plus a new conditional HTTP request header. WebDAV (RFC 4918) however already supports "state tokens" in the "If" header; right now only lock tokens are used, but there is no reason why a protocol wouldn't be able to introduce new state tokens, and allow them to be checked using the "If" header. -- That would at least avoid introducing a new conditional request header. That being said, it would be nice to get rid of the new state tokens ( schedule tags altogether. I do understand the problem with many clients updating the attendee information simultaneously. Two thoughts on this: 1) In general, issues like that can be avoided by enhancing the granularity of the resource that needs to be updated. For instance, the status for each attendee could be modeled as a separate resource, that could then respond to GET/PUT/DELETE. (I guess the server could advertise its URL as a parameter on the ATTENDEE). 2) It may also be possible to use PATCH for updating the attendee status; we would just need to define a simple payload format which can guard the client from unintentionally changing the status on an event that just changed (my understanding is that PATCH is likely to be finished in time for this spec). Best regards, Julian From bernard.desruisseaux@oracle.com Tue Jul 14 12:46:30 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157013A6942; Tue, 14 Jul 2009 12:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=2.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ablpg-hXNtb3; Tue, 14 Jul 2009 12:46:29 -0700 (PDT) Received: from mail383c25.carrierzone.com (mail383c25.carrierzone.com [209.235.146.153]) by core3.amsl.com (Postfix) with ESMTP id 7CEAC3A6868; Tue, 14 Jul 2009 12:46:29 -0700 (PDT) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail383c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6EJjxnY021835; Tue, 14 Jul 2009 19:46:02 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jul 2009 15:45:59 -0400 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07142009-154552-13080.MMD@TencoAssembliesInc.local; Tue, 14 Jul 2009 15:45:52 -0400 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail364c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n6EJfKb2019107 for ; Tue, 14 Jul 2009 15:41:22 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MQnqa-0005oy-Gy for w3c-dist-auth-dist@listhub.w3.org; Tue, 14 Jul 2009 19:39:28 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MQnqZ-0005oI-25 for w3c-dist-auth@listhub.w3.org; Tue, 14 Jul 2009 19:39:27 +0000 Received: from acsinet11.oracle.com ([141.146.126.233]) by maggie.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MQnqP-0001pS-Ip for w3c-dist-auth@w3.org; Tue, 14 Jul 2009 19:39:26 +0000 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6EJXbeC030076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jul 2009 19:33:38 GMT Received: from hqdfmt01.oracle.com (hqdfmt01.oracle.com [148.87.35.11]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6EJXw7O020084; Tue, 14 Jul 2009 19:33:59 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Jul 2009 12:33:27 -0700 Message-ID: <4A5CDD7D.9030300@oracle.com> Date: Tue, 14 Jul 2009 15:33:17 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julian Reschke References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> In-Reply-To: <4A5B1E76.7020803@gmx.de> Content-Type: multipart/alternative; boundary="------------020105010202080001070607" X-Source-IP: hqdfmt01.oracle.com [148.87.35.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0201.4A5CDD8A.0249:SCFSTAT3499757,ss=1,fgs=0 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: maggie.w3.org 1MQnqP-0001pS-Ip 303ac09f2ff4b07cc8beff0fe41613e4 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13141 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 14 Jul 2009 19:39:28 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 14 Jul 2009 19:45:59.0829 (UTC) FILETIME=[B65AF450:01CA04BB] Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 19:46:30 -0000 This is a multi-part message in MIME format. --------------020105010202080001070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Julian, After our offline discussion here's a summary of the changes we will do (see comments inline below) Thanks a lot for your review! Cheers, Bernard Julian Reschke wrote: > Bernard Desruisseaux wrote: >> Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF >> last week. See Internet-Draft announcement below. >> >> Before requesting the IESG to consider this Internet-Draft as a >> Proposed Standard, we would like to get as much feedback as possible >> from the participants of the "caldav" mailing list as well as from >> the members of the WebDAV and Calsify Working Groups. >> >> Please review the document and send your comments to the >> caldav@ietf.org mailing list by July 7th, 2009. >> >> We would like to submit draft -08 before July 13, 2009, i.e., the >> final submission cut-off for the 75th IETF in Stockholm, Sweden. >> ... > > Hi Bernard, > > I'm sorry that I'm late with my feedback (attached below). Most are > nits of editorial nature. Also, I have only read the spec from an > HTTP/WebDAV point of view, as I'm no expert on calendaring at all. > > There is a single non-editorial issue I found, and that is the > introduction of the scheduling tag, with associated HTTP headers. I > think it would be good to discuss this in more detail. > > BR, Julian > > --- snip --- > 1.5. XML Namespaces and Processing > > Definitions of XML elements in this document use XML element type > declarations (as found in XML Document Type Declarations), described > in Section 3.2 of [W3C.REC-xml-20081126]. > > JR: should this be a section reference? > > The XML declarations used in this document do not include namespace > information. Thus, implementers must not use these declarations as > the only way to create valid CalDAV properties or to validate CalDAV > XML element type. Some of the declarations refer to XML elements > > JR: I realize this sentence is borrowed from 4791. Does anybody recall > what > the "...create valid CalDAV properties..." refers to? What does the > DTD have > to do with that? We will modify Section 1.5 to use the same text as currently specified in Section 2 of vCard Extensions to WebDAV (CardDAV) . > > > 4.1. Scheduling Outbox Collection > > While there is currently no defined use for child resources in a > scheduling Outbox collection, a scheduling Outbox collection MAY > contain child resources. > > JR: may say "...MAY contain child resources, whose semantics are > undefined for now..."? > ...if this is correct, is it planned to add semantics later? How? We will change the text to specify that the use of child resources is reserved for future revisions or extensions of this specifications. > > > 4.2. Scheduling Inbox Collection > > Scheduling Inbox collections MUST only contain calendar object > resources that obey the restrictions specified in iTIP > [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox > collections MUST NOT contain any types of collection resources. > Restrictions defined in Section 4.1 of CalDAV "calendar-access" > [RFC4791] on calendar object resources contained in calendar > collections (e.g., "UID" uniqueness) don't apply to calendar object > resources contained in a scheduling Inbox collection. Multiple > calendar object resources contained in a scheduling Inbox collection > MAY have the same "UID" property value (i.e., multiple scheduling > messages for the same calendar component). > > JR: last sentence just seems to rephrase the previous one. So maybe > say "Thus, ..." > and remove the RFC2119 keyword. Will add "Thus," and change MAY to "can". > > 5.1. Identifying Scheduling Object Resources > > Calendar object resources on which the server performs automatic > scheduling transactons are refered to as scheduling object resources. > > JR: spelling. s/transactons are refered/transactions are referred/ > > > 5.2.1.1. Create > > The attempt to deliver the scheduling message will either succeed or > fail. In all cases, the server MUST add a "SCHEDULE-STATUS" > iCalendar property parameter (see Section 10.3) to the "ATTENDEE" > iCalendar property in the scheduling object resource being created, > and set its value as described in Section 9.2. This will result in > the created calendar object resource differing from the calendar data > sent in the HTTP request. As a result clients MAY reload the > calendar data from the server as soon as it is created on the server > in order to update to the new server generated state information. > > The "MAY" doesn't seem to be right here. This is not an interop > requirement > but simply a statement of fact. They "MAY" reload whenever they want > anyway :-) (there are more occurrences of this language later on). s/MAY/can/ > > > > > 7.2.7. CALDAV:max-resource-size Precondition > > Name: max-resource-size > > Namespace: urn:ietf:params:xml:ns:caldav > > Apply to: POST > > Use with: 403 Forbidden > > Purpose: (precondition) -- The resource submitted in the POST > request MUST have an octet size less than or equal to the value of > > JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"? Yes. > > > > 8. Conditional Requests on Scheduling Object Resources > > In order to do that, this specification introduces a new WebDAV > resource property CALDAV:schedule-tag with a corresponding response > header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request > header to allow client changes to be appropriately merged with server > changes in the case where the changes on the server were the result > of an "inconsequential" scheduling message update. An > "inconsequential" scheduling message is one which simply updates the > status information of Attendees due to a reply from an Attendee. > > JR: that sounds really heavy-weight; I think it would be good to discuss > this scenario over on the HTTPbis working group's mailing list. Even > if new > state tokens need to be added it is not totally clear why the RFC4918 > can not be used for checking. We will modify the text to make it clear that If-Schedule-Tag-Match is more than a conditional header, i.e., the server is required to resolve conflicts when this request header is specified. > > > > 11.1. Schedule-Reply Request Header > > > Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") > > Example: > > Schedule-Reply: F > > When an Attendee executes an HTTP DELETE request on a scheduling > object resource, and the Schedule-Reply header is not present, or > present and set to the value "T", the server MUST send an appropriate > reply scheduling message with the Attendee's "PARTSTAT" iCalendar > property parameter value set to "DECLINED" as part of its normal > automatic scheduling transaction processing. > > JR: is this header really really needed? Would it be possible to pass > that information in the request body instead? We would like to avoid defining a new request body just for that purpose. As discussed, this request header can also be specified on the MOVE method. BTW, we will clarify the text to specify that this request header applies to any "removal" operation, i.e., DELETE or MOVE request directly targeted at a resource or targeted at any parent of a resource (e.g., DELETE on calendar collection). Thanks, Bernard --------------020105010202080001070607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Julian,

After our offline discussion here's a summary of the changes we will do (see comments inline below)

Thanks a lot for your review!

Cheers,
Bernard

Julian Reschke wrote:
Bernard Desruisseaux wrote:
Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week.  See Internet-Draft announcement below.

Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups.

Please review the document and send your comments to the caldav@ietf.org mailing list by July 7th, 2009.

We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden.
...

Hi Bernard,

I'm sorry that I'm late with my feedback (attached below). Most are nits of editorial nature. Also, I have only read the spec from an HTTP/WebDAV point of view, as I'm no expert on calendaring at all.

There is a single non-editorial issue I found, and that is the introduction of the scheduling tag, with associated HTTP headers. I think it would be good to discuss this in more detail.

BR, Julian

--- snip ---
1.5.  XML Namespaces and Processing

   Definitions of XML elements in this document use XML element type
   declarations (as found in XML Document Type Declarations), described
   in Section 3.2 of [W3C.REC-xml-20081126].

JR: should this be a section reference?

   The XML declarations used in this document do not include namespace
   information.  Thus, implementers must not use these declarations as
   the only way to create valid CalDAV properties or to validate CalDAV
   XML element type.  Some of the declarations refer to XML elements

JR: I realize this sentence is borrowed from 4791. Does anybody recall what
the "...create valid CalDAV properties..." refers to? What does the DTD have
to do with that?
We will modify Section 1.5 to use the same text as currently specified in Section 2 of vCard Extensions to WebDAV (CardDAV).


4.1.  Scheduling Outbox Collection

   While there is currently no defined use for child resources in a
   scheduling Outbox collection, a scheduling Outbox collection MAY
   contain child resources.

JR: may say "...MAY contain child resources, whose semantics are undefined for now..."?
...if this is correct, is it planned to add semantics later? How?
We will change the text to specify that the use of child resources is reserved for future revisions or extensions of this specifications.


4.2.  Scheduling Inbox Collection

   Scheduling Inbox collections MUST only contain calendar object
   resources that obey the restrictions specified in iTIP
   [I-D.ietf-calsify-2446bis].  Consequently, scheduling Inbox
   collections MUST NOT contain any types of collection resources.
   Restrictions defined in Section 4.1 of CalDAV "calendar-access"
   [RFC4791] on calendar object resources contained in calendar
   collections (e.g., "UID" uniqueness) don't apply to calendar object
   resources contained in a scheduling Inbox collection.  Multiple
   calendar object resources contained in a scheduling Inbox collection
   MAY have the same "UID" property value (i.e., multiple scheduling
   messages for the same calendar component).

JR: last sentence just seems to rephrase the previous one. So maybe say "Thus, ..."
and remove the RFC2119 keyword.
Will add "Thus," and change MAY to "can".

5.1.  Identifying Scheduling Object Resources

   Calendar object resources on which the server performs automatic
   scheduling transactons are refered to as scheduling object resources.

JR: spelling.
s/transactons are refered/transactions are referred/


5.2.1.1.  Create

   The attempt to deliver the scheduling message will either succeed or
   fail.  In all cases, the server MUST add a "SCHEDULE-STATUS"
   iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
   iCalendar property in the scheduling object resource being created,
   and set its value as described in Section 9.2.  This will result in
   the created calendar object resource differing from the calendar data
   sent in the HTTP request.  As a result clients MAY reload the
   calendar data from the server as soon as it is created on the server
   in order to update to the new server generated state information.

The "MAY" doesn't seem to be right here. This is not an interop requirement
but simply a statement of fact. They "MAY" reload whenever they want
anyway :-) (there are more occurrences of this language later on).
s/MAY/can/




7.2.7.  CALDAV:max-resource-size Precondition

   Name:  max-resource-size

   Namespace:  urn:ietf:params:xml:ns:caldav

   Apply to:  POST

   Use with:  403 Forbidden

   Purpose:  (precondition) -- The resource submitted in the POST
      request MUST have an octet size less than or equal to the value of

JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"?
Yes.



8.  Conditional Requests on Scheduling Object Resources

   In order to do that, this specification introduces a new WebDAV
   resource property CALDAV:schedule-tag with a corresponding response
   header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
   header to allow client changes to be appropriately merged with server
   changes in the case where the changes on the server were the result
   of an "inconsequential" scheduling message update.  An
   "inconsequential" scheduling message is one which simply updates the
   status information of Attendees due to a reply from an Attendee.

JR: that sounds really heavy-weight; I think it would be good to discuss
this scenario over on the HTTPbis working group's mailing list. Even if new
state tokens need to be added it is not totally clear why the RFC4918
can not be used for checking.

We will modify the text to make it clear that If-Schedule-Tag-Match is more than a conditional header, i.e., the server is required to resolve conflicts when this request header is specified.



11.1.  Schedule-Reply Request Header


      Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")

   Example:

      Schedule-Reply: F

   When an Attendee executes an HTTP DELETE request on a scheduling
   object resource, and the Schedule-Reply header is not present, or
   present and set to the value "T", the server MUST send an appropriate
   reply scheduling message with the Attendee's "PARTSTAT" iCalendar
   property parameter value set to "DECLINED" as part of its normal
   automatic scheduling transaction processing.

JR: is this header really really needed? Would it be possible to pass
that information in the request body instead?

We would like to avoid defining a new request body just for that purpose.  As discussed, this request header can also be specified on the MOVE method.  BTW, we will clarify the text to specify that this request header applies to any "removal" operation, i.e., DELETE or  MOVE request directly targeted at a resource or targeted at any parent of a resource (e.g., DELETE on calendar collection).

Thanks,
Bernard
--------------020105010202080001070607-- From bernard.desruisseaux@oracle.com Tue Jul 14 16:39:31 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DCB3A6846; Tue, 14 Jul 2009 16:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.478 X-Spam-Level: X-Spam-Status: No, score=-4.478 tagged_above=-999 required=5 tests=[AWL=-1.880, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nsgLbIc37P8; Tue, 14 Jul 2009 16:39:30 -0700 (PDT) Received: from acsinet14.oracle.com (acsinet14.oracle.com [141.146.126.236]) by core3.amsl.com (Postfix) with ESMTP id BF6B43A685A; Tue, 14 Jul 2009 16:39:28 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by acsinet14.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6EJgTJP004617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jul 2009 19:42:30 GMT Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6EJXbeC030076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jul 2009 19:33:38 GMT Received: from hqdfmt01.oracle.com (hqdfmt01.oracle.com [148.87.35.11]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n6EJXw7O020084; Tue, 14 Jul 2009 19:33:59 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Jul 2009 12:33:27 -0700 Message-ID: <4A5CDD7D.9030300@oracle.com> Date: Tue, 14 Jul 2009 15:33:17 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julian Reschke References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> In-Reply-To: <4A5B1E76.7020803@gmx.de> Content-Type: multipart/alternative; boundary="------------020105010202080001070607" X-Source-IP: acsinet11.oracle.com [141.146.126.233] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.4A5CDEC2.0182:SCFMA922111,ss=1,fgs=0 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Alexey Melnikov , Lisa Dusseault Subject: Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 23:39:31 -0000 This is a multi-part message in MIME format. --------------020105010202080001070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Julian, After our offline discussion here's a summary of the changes we will do (see comments inline below) Thanks a lot for your review! Cheers, Bernard Julian Reschke wrote: > Bernard Desruisseaux wrote: >> Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF >> last week. See Internet-Draft announcement below. >> >> Before requesting the IESG to consider this Internet-Draft as a >> Proposed Standard, we would like to get as much feedback as possible >> from the participants of the "caldav" mailing list as well as from >> the members of the WebDAV and Calsify Working Groups. >> >> Please review the document and send your comments to the >> caldav@ietf.org mailing list by July 7th, 2009. >> >> We would like to submit draft -08 before July 13, 2009, i.e., the >> final submission cut-off for the 75th IETF in Stockholm, Sweden. >> ... > > Hi Bernard, > > I'm sorry that I'm late with my feedback (attached below). Most are > nits of editorial nature. Also, I have only read the spec from an > HTTP/WebDAV point of view, as I'm no expert on calendaring at all. > > There is a single non-editorial issue I found, and that is the > introduction of the scheduling tag, with associated HTTP headers. I > think it would be good to discuss this in more detail. > > BR, Julian > > --- snip --- > 1.5. XML Namespaces and Processing > > Definitions of XML elements in this document use XML element type > declarations (as found in XML Document Type Declarations), described > in Section 3.2 of [W3C.REC-xml-20081126]. > > JR: should this be a section reference? > > The XML declarations used in this document do not include namespace > information. Thus, implementers must not use these declarations as > the only way to create valid CalDAV properties or to validate CalDAV > XML element type. Some of the declarations refer to XML elements > > JR: I realize this sentence is borrowed from 4791. Does anybody recall > what > the "...create valid CalDAV properties..." refers to? What does the > DTD have > to do with that? We will modify Section 1.5 to use the same text as currently specified in Section 2 of vCard Extensions to WebDAV (CardDAV) . > > > 4.1. Scheduling Outbox Collection > > While there is currently no defined use for child resources in a > scheduling Outbox collection, a scheduling Outbox collection MAY > contain child resources. > > JR: may say "...MAY contain child resources, whose semantics are > undefined for now..."? > ...if this is correct, is it planned to add semantics later? How? We will change the text to specify that the use of child resources is reserved for future revisions or extensions of this specifications. > > > 4.2. Scheduling Inbox Collection > > Scheduling Inbox collections MUST only contain calendar object > resources that obey the restrictions specified in iTIP > [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox > collections MUST NOT contain any types of collection resources. > Restrictions defined in Section 4.1 of CalDAV "calendar-access" > [RFC4791] on calendar object resources contained in calendar > collections (e.g., "UID" uniqueness) don't apply to calendar object > resources contained in a scheduling Inbox collection. Multiple > calendar object resources contained in a scheduling Inbox collection > MAY have the same "UID" property value (i.e., multiple scheduling > messages for the same calendar component). > > JR: last sentence just seems to rephrase the previous one. So maybe > say "Thus, ..." > and remove the RFC2119 keyword. Will add "Thus," and change MAY to "can". > > 5.1. Identifying Scheduling Object Resources > > Calendar object resources on which the server performs automatic > scheduling transactons are refered to as scheduling object resources. > > JR: spelling. s/transactons are refered/transactions are referred/ > > > 5.2.1.1. Create > > The attempt to deliver the scheduling message will either succeed or > fail. In all cases, the server MUST add a "SCHEDULE-STATUS" > iCalendar property parameter (see Section 10.3) to the "ATTENDEE" > iCalendar property in the scheduling object resource being created, > and set its value as described in Section 9.2. This will result in > the created calendar object resource differing from the calendar data > sent in the HTTP request. As a result clients MAY reload the > calendar data from the server as soon as it is created on the server > in order to update to the new server generated state information. > > The "MAY" doesn't seem to be right here. This is not an interop > requirement > but simply a statement of fact. They "MAY" reload whenever they want > anyway :-) (there are more occurrences of this language later on). s/MAY/can/ > > > > > 7.2.7. CALDAV:max-resource-size Precondition > > Name: max-resource-size > > Namespace: urn:ietf:params:xml:ns:caldav > > Apply to: POST > > Use with: 403 Forbidden > > Purpose: (precondition) -- The resource submitted in the POST > request MUST have an octet size less than or equal to the value of > > JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"? Yes. > > > > 8. Conditional Requests on Scheduling Object Resources > > In order to do that, this specification introduces a new WebDAV > resource property CALDAV:schedule-tag with a corresponding response > header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request > header to allow client changes to be appropriately merged with server > changes in the case where the changes on the server were the result > of an "inconsequential" scheduling message update. An > "inconsequential" scheduling message is one which simply updates the > status information of Attendees due to a reply from an Attendee. > > JR: that sounds really heavy-weight; I think it would be good to discuss > this scenario over on the HTTPbis working group's mailing list. Even > if new > state tokens need to be added it is not totally clear why the RFC4918 > can not be used for checking. We will modify the text to make it clear that If-Schedule-Tag-Match is more than a conditional header, i.e., the server is required to resolve conflicts when this request header is specified. > > > > 11.1. Schedule-Reply Request Header > > > Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") > > Example: > > Schedule-Reply: F > > When an Attendee executes an HTTP DELETE request on a scheduling > object resource, and the Schedule-Reply header is not present, or > present and set to the value "T", the server MUST send an appropriate > reply scheduling message with the Attendee's "PARTSTAT" iCalendar > property parameter value set to "DECLINED" as part of its normal > automatic scheduling transaction processing. > > JR: is this header really really needed? Would it be possible to pass > that information in the request body instead? We would like to avoid defining a new request body just for that purpose. As discussed, this request header can also be specified on the MOVE method. BTW, we will clarify the text to specify that this request header applies to any "removal" operation, i.e., DELETE or MOVE request directly targeted at a resource or targeted at any parent of a resource (e.g., DELETE on calendar collection). Thanks, Bernard --------------020105010202080001070607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Julian,

After our offline discussion here's a summary of the changes we will do (see comments inline below)

Thanks a lot for your review!

Cheers,
Bernard

Julian Reschke wrote:
Bernard Desruisseaux wrote:
Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week.  See Internet-Draft announcement below.

Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups.

Please review the document and send your comments to the caldav@ietf.org mailing list by July 7th, 2009.

We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden.
...

Hi Bernard,

I'm sorry that I'm late with my feedback (attached below). Most are nits of editorial nature. Also, I have only read the spec from an HTTP/WebDAV point of view, as I'm no expert on calendaring at all.

There is a single non-editorial issue I found, and that is the introduction of the scheduling tag, with associated HTTP headers. I think it would be good to discuss this in more detail.

BR, Julian

--- snip ---
1.5.  XML Namespaces and Processing

   Definitions of XML elements in this document use XML element type
   declarations (as found in XML Document Type Declarations), described
   in Section 3.2 of [W3C.REC-xml-20081126].

JR: should this be a section reference?

   The XML declarations used in this document do not include namespace
   information.  Thus, implementers must not use these declarations as
   the only way to create valid CalDAV properties or to validate CalDAV
   XML element type.  Some of the declarations refer to XML elements

JR: I realize this sentence is borrowed from 4791. Does anybody recall what
the "...create valid CalDAV properties..." refers to? What does the DTD have
to do with that?
We will modify Section 1.5 to use the same text as currently specified in Section 2 of vCard Extensions to WebDAV (CardDAV).


4.1.  Scheduling Outbox Collection

   While there is currently no defined use for child resources in a
   scheduling Outbox collection, a scheduling Outbox collection MAY
   contain child resources.

JR: may say "...MAY contain child resources, whose semantics are undefined for now..."?
...if this is correct, is it planned to add semantics later? How?
We will change the text to specify that the use of child resources is reserved for future revisions or extensions of this specifications.


4.2.  Scheduling Inbox Collection

   Scheduling Inbox collections MUST only contain calendar object
   resources that obey the restrictions specified in iTIP
   [I-D.ietf-calsify-2446bis].  Consequently, scheduling Inbox
   collections MUST NOT contain any types of collection resources.
   Restrictions defined in Section 4.1 of CalDAV "calendar-access"
   [RFC4791] on calendar object resources contained in calendar
   collections (e.g., "UID" uniqueness) don't apply to calendar object
   resources contained in a scheduling Inbox collection.  Multiple
   calendar object resources contained in a scheduling Inbox collection
   MAY have the same "UID" property value (i.e., multiple scheduling
   messages for the same calendar component).

JR: last sentence just seems to rephrase the previous one. So maybe say "Thus, ..."
and remove the RFC2119 keyword.
Will add "Thus," and change MAY to "can".

5.1.  Identifying Scheduling Object Resources

   Calendar object resources on which the server performs automatic
   scheduling transactons are refered to as scheduling object resources.

JR: spelling.
s/transactons are refered/transactions are referred/


5.2.1.1.  Create

   The attempt to deliver the scheduling message will either succeed or
   fail.  In all cases, the server MUST add a "SCHEDULE-STATUS"
   iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
   iCalendar property in the scheduling object resource being created,
   and set its value as described in Section 9.2.  This will result in
   the created calendar object resource differing from the calendar data
   sent in the HTTP request.  As a result clients MAY reload the
   calendar data from the server as soon as it is created on the server
   in order to update to the new server generated state information.

The "MAY" doesn't seem to be right here. This is not an interop requirement
but simply a statement of fact. They "MAY" reload whenever they want
anyway :-) (there are more occurrences of this language later on).
s/MAY/can/




7.2.7.  CALDAV:max-resource-size Precondition

   Name:  max-resource-size

   Namespace:  urn:ietf:params:xml:ns:caldav

   Apply to:  POST

   Use with:  403 Forbidden

   Purpose:  (precondition) -- The resource submitted in the POST
      request MUST have an octet size less than or equal to the value of

JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"?
Yes.



8.  Conditional Requests on Scheduling Object Resources

   In order to do that, this specification introduces a new WebDAV
   resource property CALDAV:schedule-tag with a corresponding response
   header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
   header to allow client changes to be appropriately merged with server
   changes in the case where the changes on the server were the result
   of an "inconsequential" scheduling message update.  An
   "inconsequential" scheduling message is one which simply updates the
   status information of Attendees due to a reply from an Attendee.

JR: that sounds really heavy-weight; I think it would be good to discuss
this scenario over on the HTTPbis working group's mailing list. Even if new
state tokens need to be added it is not totally clear why the RFC4918
can not be used for checking.

We will modify the text to make it clear that If-Schedule-Tag-Match is more than a conditional header, i.e., the server is required to resolve conflicts when this request header is specified.



11.1.  Schedule-Reply Request Header


      Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")

   Example:

      Schedule-Reply: F

   When an Attendee executes an HTTP DELETE request on a scheduling
   object resource, and the Schedule-Reply header is not present, or
   present and set to the value "T", the server MUST send an appropriate
   reply scheduling message with the Attendee's "PARTSTAT" iCalendar
   property parameter value set to "DECLINED" as part of its normal
   automatic scheduling transaction processing.

JR: is this header really really needed? Would it be possible to pass
that information in the request body instead?

We would like to avoid defining a new request body just for that purpose.  As discussed, this request header can also be specified on the MOVE method.  BTW, we will clarify the text to specify that this request header applies to any "removal" operation, i.e., DELETE or  MOVE request directly targeted at a resource or targeted at any parent of a resource (e.g., DELETE on calendar collection).

Thanks,
Bernard
--------------020105010202080001070607-- From helge.hess@opengroupware.org Sun Jul 19 06:41:42 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5EC3A6C12; Sun, 19 Jul 2009 06:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ+n9v3LsUrX; Sun, 19 Jul 2009 06:41:39 -0700 (PDT) Received: from mail.mdlink.net (mail.mdlink.net [213.211.192.40]) by core3.amsl.com (Postfix) with ESMTP id B46D63A6C38; Sun, 19 Jul 2009 06:41:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0E1B61AA10B2; Sun, 19 Jul 2009 15:41:32 +0200 (CEST) Received: from [192.168.0.111] (77-20-255-89-dynip.superkabel.de [77.20.255.89]) by mail.mdlink.net (Postfix) with ESMTP id BD0C41AA0EA8; Sun, 19 Jul 2009 15:41:31 +0200 (CEST) Message-Id: From: Helge Hess To: Bernard Desruisseaux In-Reply-To: <4A5B1E76.7020803@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 19 Jul 2009 15:41:30 +0200 References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> X-Mailer: Apple Mail (2.935.3) Cc: caldav@ietf.org, calsify@ietf.org Subject: Re: [caldav] [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 13:41:42 -0000 Hi, small request. It would be good if the example B.5. (Organizer Requesting Busy Time Information) would include an ATTENDEE which cannot be resolved by the server. Thanks, Helge From helge.hess@opengroupware.org Sun Jul 19 07:18:07 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873733A6928; Sun, 19 Jul 2009 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05UrPmmsmuOA; Sun, 19 Jul 2009 07:18:06 -0700 (PDT) Received: from mail.mdlink.net (mail.mdlink.net [213.211.192.40]) by core3.amsl.com (Postfix) with ESMTP id 8F23F3A6929; Sun, 19 Jul 2009 07:18:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CFC5B2D000C; Sun, 19 Jul 2009 16:18:04 +0200 (CEST) Received: from [192.168.0.111] (77-20-255-89-dynip.superkabel.de [77.20.255.89]) by mail.mdlink.net (Postfix) with ESMTP id 86D452D000E; Sun, 19 Jul 2009 16:18:04 +0200 (CEST) Message-Id: From: Helge Hess To: Bernard Desruisseaux In-Reply-To: <4A5B1E76.7020803@gmx.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 19 Jul 2009 16:18:03 +0200 References: <4A40F50F.3030002@oracle.com> <4A5B1E76.7020803@gmx.de> X-Mailer: Apple Mail (2.935.3) Cc: caldav@ietf.org, calsify@ietf.org Subject: Re: [caldav] [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 14:18:07 -0000 Hi, the 'schedule-default-calendar-URL' WebDAV property is currently defined on the Outbox. Would it be possible to have that on the principal resource instead? This would make it a bit easier for us with Outlook, which also has a concept of a 'primary calendar'. Thanks, Helge -- http://zideone.com/ From rick.denatale@gmail.com Tue Jul 28 07:41:06 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAA33A6FE7 for ; Tue, 28 Jul 2009 07:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEtOQhhZN9lf for ; Tue, 28 Jul 2009 07:41:05 -0700 (PDT) Received: from mail-yx0-f183.google.com (mail-yx0-f183.google.com [209.85.210.183]) by core3.amsl.com (Postfix) with ESMTP id 1588E3A6F62 for ; Tue, 28 Jul 2009 07:41:05 -0700 (PDT) Received: by yxe13 with SMTP id 13so106690yxe.29 for ; Tue, 28 Jul 2009 07:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sGMovC2KjfJFQmJ9gcmqrdFbzx5B9EEQUi4wmSGA40o=; b=a8Y2USqdxtETR35CExCk5NblRAvqfD3WqqICwY4XofcvmyO+0qsBjAUG7/rdSlp3df rtU3HMjheN1wUF+5oU1Po6aazNUpN9SLzg24SzF9Nujc9852zXByvn7GWch5EdblLJ/s nw5eJITZ1Z7d3TCh2P3gO452w9v9XoYDxNles= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=DVZOQJDQnlrIIVf4SbuIIHKsNw6k1CYILBQNQ+q9XNX/xk8A77+u8JepIAfD+V/Y8N V27Yp06hpr6sY8/vBUF/yGdBGlVUtWdL3gDlmBdOf/7b+ieajAGQTTb6Tb5W3v3PLhQv INT0/+ZztYnBK9+zbxOZCbLy5xiWJzZ+eu0QI= MIME-Version: 1.0 Received: by 10.90.67.6 with SMTP id p6mr7097748aga.100.1248792064513; Tue, 28 Jul 2009 07:41:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jul 2009 10:41:04 -0400 Message-ID: From: Rick DeNatale To: caldav@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [caldav] Fwd: Looking for resources to debug webdav server X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 14:41:07 -0000 I'm hoping someone can point me to some help sources. =A0I'm striking out with google. While I find caldav threads, most appear to be from the client viewpoint. I tried finding irc channels and the like but can't find anything which appears to be active. I'm trying to add webdav support to an existing ruby on rails application which already supports calendars. I've been trying to figure out the realities of caldav by snooping on the conversation between ical.app and google calendar establishing a webdav account and then syncing, and then trying, as a first step to send canned responses to the propfind requests sent by ical.app from my server app. But I'm seeing some strange things. First, for the first connection to google calendar in establishing an account, ical.app is sending some propfinds which I am not seeing when it tries to establish an account with my server app. =A0Instead it sends a propfind which only occurs after the connection setup handshaking with google cal. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Second, when I respond to the propfind with what I think is a valid response, same headers, and valid xml for the body, ical.app doesn't seem to like it HTTP/1.1 207 Multi-Status X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.4 Cache-Control: private, max-age=3D0 Status: 207 Multi-Status X-Runtime: 0.54242 Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7l DAV/2 Phusion_Passenger/2.2.4 DAV: 1, calendar-access, calendar-schedule, calendar-proxy Date: Thu, 23 Jul 2009 14:29:05 GMT Content-Length: 1375 Content-Type: application/xml; charset=3Dutf-8 Connection: Keep-Alive, close =A0 =A0 /caldav/calendar/Personal/ =A0 =A0 =A0 HTTP/1.1 200 OK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /caldav/calendar/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mailto:virtuser@cals.37s.backpack.com =A0 =A0 =A0 =A0 /caldav/calendar/virtuser%40cals.37s.backpack.com/u= ser/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /caldav/calendar/virtuser%40cals.37s.backpack.com/i= nbox/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /caldav/calendar/virtuser%40cals.37s.backpack.com/o= utbox/ =A0 =A0 =A0 =A0 =A0 =A0 Personal =A0 =A0 =A0 =A0 =A0 =A0 HTTP/1.1 404 Not Found =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But ical.app puts up an error dialog with the message "Request encountered an unexpected error (domain CalDAV No Calendar Home Error / code 1)." I've tried to find an irc channel which might have someone who could help I found a calendarserver irc channel (for Apple's CalendarServer project) but no one seems to be responsive. =A0There's another caldav channel associated with Chandler, but no one seems to be home. So, does anyone have any suggestions about where I might get some help in figuring this out? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From helge.hess@opengroupware.org Tue Jul 28 08:02:48 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E673A6FE4 for ; Tue, 28 Jul 2009 08:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aGPcqHM9z-b for ; Tue, 28 Jul 2009 08:02:47 -0700 (PDT) Received: from mail.mdlink.net (mail.mdlink.net [213.211.192.40]) by core3.amsl.com (Postfix) with ESMTP id 81DB03A6FE2 for ; Tue, 28 Jul 2009 08:02:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 3897B1AA0C6B; Tue, 28 Jul 2009 17:02:48 +0200 (CEST) Received: from helge-111.in.skyrix.com (xl0-wan.skyrix.com [213.211.192.114]) by mail.mdlink.net (Postfix) with ESMTP id 078CE1AA02D0; Tue, 28 Jul 2009 17:02:48 +0200 (CEST) Message-Id: <339147D8-4BD0-4B98-942B-77A3D345E719@opengroupware.org> From: Helge Hess To: Rick DeNatale In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 17:02:47 +0200 References: X-Mailer: Apple Mail (2.935.3) Cc: caldav@ietf.org Subject: Re: [caldav] [calsify] Looking for resources to debug webdav server X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:02:48 -0000 Hi, On 28.07.2009, at 16:32, Rick DeNatale wrote: > I'm trying to add webdav support to an existing ruby on rails > application which already supports calendars. those might be helpful: http://www.ruby-forum.com/search?query=caldav&submit=Search > First, for the first connection to google calendar in establishing an > account, ical.app is sending some propfinds which I am not seeing when > it tries to establish an account with my server app. I wouldn't be surprised if iCal does some Google specific stuff. Which iCal.app version are we talking about? You are not using the Google tool to setup iCal.app for GCal? > Instead it sends > a propfind which only occurs after the connection setup handshaking > with google cal. > > > xmlns:x1="urn:ietf:params:xml:ns:caldav" xmlns:x0="DAV:"> > > > > > > > > > > Yes, thats a typical entry point query used to discover the CalDAV account setup. > Second, when I respond to the propfind with what I think is a valid > response, same headers, and valid xml for the body, ical.app doesn't > seem to like it The XML looks good. I assume that '/caldav/calendar/Personal/' exactly matches the URL iCal is requesting? (full HTTP request dump would be helpful) Is there a 401 step involved? I would recommend installing Darwin CalendarServer (calendarserver.org) as a reference and see what this is emitting. Eg it sends: ---snip--- /calendars/__uids__/41770B64-643D-40FC- B832-9EC9BFE68861 ---snap--- Stupid try: maybe this specific iCal codepath has no XML namespace processing ...? > So, does anyone have any suggestions about where I might get some help > in figuring this out? This mailing list is a starting point. CalConnect provides additional resources, but you need to be a member for accessing those ... Greets, Helge -- Helge Hess http://zideone.com/ From cyrus@daboo.name Wed Jul 29 14:20:22 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E95E3A6A90 for ; Wed, 29 Jul 2009 14:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cM8QNal7nvR2 for ; Wed, 29 Jul 2009 14:20:21 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 16A7C3A69E3 for ; Wed, 29 Jul 2009 14:20:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D00201760C82; Wed, 29 Jul 2009 17:20:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuS1YW-gPrSv; Wed, 29 Jul 2009 17:20:21 -0400 (EDT) Received: from [10.43.1.28] (unknown [77.241.97.148]) by daboo.name (Postfix) with ESMTP id 2F5BB1760C7B; Wed, 29 Jul 2009 17:20:19 -0400 (EDT) Date: Wed, 29 Jul 2009 23:20:14 +0200 From: Cyrus Daboo To: Rick DeNatale , caldav@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=872 Subject: Re: [caldav] Fwd: Looking for resources to debug webdav server X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 21:20:22 -0000 Hi Rick, --On July 28, 2009 10:41:04 AM -0400 Rick DeNatale wrote: > > So, does anyone have any suggestions about where I might get some help > in figuring this out? Please file a bug at http://bugreporter.apple.com and include the full protocol traces you have (if possible complete ones that show the initial request line etc). Also, please use the Console.app to check for any messages coming from iCal as you try to setup the account. Attach protocol traces and console logs to the bug report, then email me the resulting bug number privately. At first glance what you are doing should work but there are some things that are certainly different from what other servers typically do. Also, if you have a way to make a test server available with test accounts that could be used, that may help in debugging this. -- Cyrus Daboo