From julian.reschke@gmx.de Mon Jul 13 04:45:37 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86C53A6D8B for ; Mon, 13 Jul 2009 04:45:37 -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 DBflNq04GLfE for ; Mon, 13 Jul 2009 04:45:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 518F93A6D86 for ; Mon, 13 Jul 2009 04:45:36 -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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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:45:37 -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 calsify-bounces@ietf.org Mon Jul 13 04:45:39 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222453A6D8B; Mon, 13 Jul 2009 04:45:39 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86C53A6D8B for ; Mon, 13 Jul 2009 04:45:37 -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 DBflNq04GLfE for ; Mon, 13 Jul 2009 04:45:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 518F93A6D86 for ; Mon, 13 Jul 2009 04:45:36 -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> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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? _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From calsify-bounces@ietf.org Mon Jul 13 05:00:33 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F58D28C3EE; Mon, 13 Jul 2009 05:00:33 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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 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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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? _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From julian.reschke@gmx.de Mon Jul 13 05:00:32 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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:21:26 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21BC28C596 for ; Mon, 13 Jul 2009 13:21:26 -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 SSWwaiTN-0o7 for ; Mon, 13 Jul 2009 13:21:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6D95728C672 for ; Mon, 13 Jul 2009 13:18:58 -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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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:21:27 -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 calsify-bounces@ietf.org Mon Jul 13 13:21:27 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6AB28C672; Mon, 13 Jul 2009 13:21:27 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21BC28C596 for ; Mon, 13 Jul 2009 13:21:26 -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 SSWwaiTN-0o7 for ; Mon, 13 Jul 2009 13:21:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6D95728C672 for ; Mon, 13 Jul 2009 13:18:58 -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> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From calsify-bounces@ietf.org Mon Jul 13 13:31:14 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A8528C636; Mon, 13 Jul 2009 13:31:13 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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 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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From julian.reschke@gmx.de Mon Jul 13 13:31:09 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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 05:43:25 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E85228C0E4 for ; Tue, 14 Jul 2009 05:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[AWL=-1.295, 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 mFfnQ8qxuYJG for ; Tue, 14 Jul 2009 05:43:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 204AF3A6822 for ; Tue, 14 Jul 2009 05:43:23 -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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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 12:43:25 -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 calsify-bounces@ietf.org Tue Jul 14 05:43:27 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5302028C104; Tue, 14 Jul 2009 05:43:27 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E85228C0E4 for ; Tue, 14 Jul 2009 05:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.894 X-Spam-Level: X-Spam-Status: No, score=-3.894 tagged_above=-999 required=5 tests=[AWL=-1.295, 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 mFfnQ8qxuYJG for ; Tue, 14 Jul 2009 05:43:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 204AF3A6822 for ; Tue, 14 Jul 2009 05:43:23 -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> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: w3c-dist-auth@w3.org, caldav@ietf.org, calsify@ietf.org, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From julian.reschke@gmx.de Tue Jul 14 10:07:51 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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 calsify-bounces@ietf.org Tue Jul 14 10:07:52 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F358E28C132; Tue, 14 Jul 2009 10:07:51 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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 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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From calsify-bounces@ietf.org Tue Jul 14 12:46:31 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957453A6942; Tue, 14 Jul 2009 12:46:31 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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 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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1631870491==" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org This is a multi-part message in MIME format. --===============1631870491== Content-Type: multipart/alternative; boundary="------------020105010202080001070607" 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-- --===============1631870491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --===============1631870491==-- From bernard.desruisseaux@oracle.com Tue Jul 14 12:46:30 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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: calsify@core3.amsl.com Delivered-To: calsify@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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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 calsify-bounces@ietf.org Tue Jul 14 16:39:33 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2E83A68E6; Tue, 14 Jul 2009 16:39:33 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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, Lisa Dusseault Subject: Re: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1276805029==" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org This is a multi-part message in MIME format. --===============1276805029== Content-Type: multipart/alternative; boundary="------------020105010202080001070607" 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-- --===============1276805029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --===============1276805029==-- From helge.hess@opengroupware.org Sun Jul 19 06:41:42 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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 calsify-bounces@ietf.org Sun Jul 19 06:41:46 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C855F3A6C4E; Sun, 19 Jul 2009 06:41:46 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From helge.hess@opengroupware.org Sun Jul 19 07:18:07 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@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 calsify-bounces@ietf.org Sun Jul 19 07:18:08 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED94B3A6A87; Sun, 19 Jul 2009 07:18:08 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@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> 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: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org 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/ _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From ietf-calsify-bounces@osafoundation.org Tue Jul 21 16:45:16 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0973A6AAF for ; Tue, 21 Jul 2009 16:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 XZFQCMxxh9hH for ; Tue, 21 Jul 2009 16:45:10 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id B3FFF3A6B8D for ; Tue, 21 Jul 2009 16:45:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EDCD677D70B; Tue, 21 Jul 2009 16:45:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ciqJCZD1sQg; Tue, 21 Jul 2009 16:44:59 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C39AF79401D; Tue, 21 Jul 2009 16:44:56 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 39F27794030 for ; Tue, 21 Jul 2009 16:44:54 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp3Bao8ExNGB for ; Tue, 21 Jul 2009 16:44:42 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id DA8A877D70B for ; Tue, 21 Jul 2009 16:44:42 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 21 Jul 2009 16:44:42 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.179]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Tue, 21 Jul 2009 16:44:42 -0700 From: Steven Lees To: "ietf-calsify@osafoundation.org" Thread-Topic: XML iCalendar issues and questions Thread-Index: AcoKWMNqod6xD03eSLaKKNhzQuKv5Q== Date: Tue, 21 Jul 2009 23:44:42 +0000 Message-ID: <854B3F17B7AF524E9E6CB4A9004F8C6C162299C0@tk5ex14mbxc105.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: [ietf-calsify] XML iCalendar issues and questions X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227411857==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============0227411857== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_854B3F17B7AF524E9E6CB4A9004F8C6C162299C0tk5ex14mbxc105r_" --_000_854B3F17B7AF524E9E6CB4A9004F8C6C162299C0tk5ex14mbxc105r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I haven't seen much public comment on the XML iCalendar draft (http://www.i= etf.org/id/draft-daboo-et-al-icalendar-in-xml-00.txt) that Cyrus, Mike, and= I submitted in June. I thought it might be helpful to write up a quick sum= mary of some of the issues that people have mentioned to me. Since one of o= ur goals is to have consistency between vCard-in-XML and iCalendar-in-XML, = I've also written up my understanding of how the vCard-XML draft handles th= ese issues. 1) Date-time format: The xCalendar draft breaks out date/time values into separate XML elements = for year/month/day and hour/minute/second. The main reason for choosing thi= s format was to make it easier for implementers who want to transform the X= ML into a presentation format like HTML. The separate elements mean that no= additional parsing is necessary. It does significantly increase the size o= f the XML format, however. One compromise that has been suggested is to mak= e the XML element names smaller, i.e. instead of . Here's an example: 200926 1200 The xCard draft embeds the vCard time value in a single XML element:, which= is obviously much more compact: 20090808T1430-0500 2) Extensibility: The xCalendar draft describes two kinds of extensions. Extensions that orig= inate in iCal with the "x-" prefix are converted to XML elements with the s= ame name (but in lowercase). Those extensions are in the same XML namespace= as other xCalendar elements. This makes it straightforward to convert thos= e extensions back to the iCal format. Other XML extension elements are allo= wed as well, but such extensions must not be in the xCalendar XML namespace= . Such extensions are not convertible to the iCal format. In contrast, the xCard draft describes only the second kind of extension: t= hose that are in a separate XML namespace. As far as I can tell, the xCard = draft doesn't describe a way to convert those extensions to the vCard forma= t. 3) XML attributes: The xCalendar draft currently uses attributes in two places. There is a "ut= c" attribute on date-time elements, and a "sign" attribute on duration elem= ents. The xCard draft doesn't appear to use any XML attributes. This allows a sim= ple transformation to key/value formats like JSON. It would be great to hear opinions on these or other issues. If you're atte= nding IETF next week in Stockholm, the topic of XML formats for vCard and i= Calendar is on the agenda for the vcarddav working group on Tuesday July 28= : http://www.ietf.org/mail-archive/web/vcarddav/current/msg01105.html. Thanks, Steven --_000_854B3F17B7AF524E9E6CB4A9004F8C6C162299C0tk5ex14mbxc105r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I haven’t seen much public comment on the XML iCalendar draft (h= ttp://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-00.txt) that Cyrus, Mike, and I submitted in June. I thought it might be helpful to= write up a quick summary of some of the issues that people have mentioned to me. = Since one of our goals is to have consistency between vCard-in-XML and iCalendar-= in-XML, I’ve also written up my understanding of how the vCard-XML draft hand= les these issues.

 

1) Date-time format:

The xCalendar draft breaks out date/time values into separate XML elements for year/month/day and hour/minute/second. The main reason for choosing this format was to make it easier for implementers who = want to transform the XML into a presentation format like HTML. The separate elements mean that no additional parsing is necessary. It does significantl= y increase the size of the XML format, however. One compromise that has been suggested is to make the XML element names smaller, i.e. <y> instead = of <year>.

 

Here’s an example:

        <dtstart= >

          <date-time utc=3D"yes">

         =    <year>2009</year><month>2</month><day>6</d= ay>

         =    <hour>12</hour><minute>0</minute><second>0<= ;/second>

          </date-time>

        </dtstar= t>

 

The xCard draft embeds the vCard time value in a singl= e XML element:, which is obviously much more compact:

 

        <date-ti= me>20090808T1430-0500</date-time>

 

2) Extensibility:

The xCalendar draft describes two kinds of extensions. Extensions that originate in iCal with the "x-" prefix are conver= ted to XML elements with the same name (but in lowercase). Those extensions are= in the same XML namespace as other xCalendar elements. This makes it straightforward to convert those extensions back to the iCal format. Other = XML extension elements are allowed as well, but such extensions must not be in = the xCalendar XML namespace. Such extensions are not convertible to the iCal format.=

 

In contrast, the xCard draft describes only the second= kind of extension: those that are in a separate XML namespace. As far as I can t= ell, the xCard draft doesn't describe a way to convert those extensions to the v= Card format.

 

3) XML attributes:

The xCalendar draft currently uses attributes in two p= laces. There is a "utc" attribute on date-time elements, and a "sign" attribute on duration elements.

 

The xCard draft doesn't appear to use any XML attribut= es. This allows a simple transformation to key/value formats like JSON.

 

 

It would be great to hear opinions on these or other i= ssues. If you’re attending IETF next week in Stockholm, the topic of XML for= mats for vCard and iCalendar is on the agenda for the vcarddav working group on Tuesday July 28: http://www.ietf.org/mail-archive/web/vcarddav/current/msg01105.html.<= o:p>

 

Thanks,

Steven

 

--_000_854B3F17B7AF524E9E6CB4A9004F8C6C162299C0tk5ex14mbxc105r_-- --===============0227411857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============0227411857==-- From ietf-calsify-bounces@osafoundation.org Tue Jul 21 18:51:41 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9BB28C0ED for ; Tue, 21 Jul 2009 18:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 mu3HWk6oA2dL for ; Tue, 21 Jul 2009 18:51:34 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id D765D3A6ABC for ; Tue, 21 Jul 2009 18:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4E4C677D719; Tue, 21 Jul 2009 18:51:35 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV1Jqu4QRWNJ; Tue, 21 Jul 2009 18:51:22 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 427C879401D; Tue, 21 Jul 2009 18:51:20 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5E02677D719 for ; Tue, 21 Jul 2009 18:51:18 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB3EZ4v3mgQW for ; Tue, 21 Jul 2009 18:51:08 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by leka.osafoundation.org (Postfix) with ESMTP id BE10B77D70B for ; Tue, 21 Jul 2009 18:51:07 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Jo8y1c00C0Fqzac58pr81q; Wed, 22 Jul 2009 01:51:08 +0000 Received: from THare ([71.203.105.66]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Jpr61c0031RyUCv3Upr6x0; Wed, 22 Jul 2009 01:51:07 +0000 From: "Tim Hare" To: "'Steven Lees'" , Date: Tue, 21 Jul 2009 21:51:10 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <854B3F17B7AF524E9E6CB4A9004F8C6C162299C0@tk5ex14mbxc105.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcoKWMNqod6xD03eSLaKKNhzQuKv5QAFDY4g Message-Id: <20090722015107.BE10B77D70B@leka.osafoundation.org> Subject: Re: [ietf-calsify] XML iCalendar issues and questions X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1693887371==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============1693887371== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CA0A4D.5D556EC0" This is a multi-part message in MIME format. ------=_NextPart_000_0049_01CA0A4D.5D556EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I won't be in Stockholm, but I'll throw my two cents in. I'm not an implementer (currently) but I think separating out all the elements of date and time doesn't gain that much - there are well-developed libraries of routines for parsing dates in ISO format, I believe, so it should not be that costly to extract the date-time value as in xCard and deal with it. My next comment is more of a question. I would have mapped components and properties (VEVENT, DTSTART) to XML elements, and all property parameters to attributes - for example ... Can you tell me what the thought process was for having so few attributes? Tim Hare Interested Bystander, Non-Inc. _____ From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Steven Lees Sent: Tuesday, July 21, 2009 7:45 PM To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] XML iCalendar issues and questions Hello, I haven't seen much public comment on the XML iCalendar draft (http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-00.txt) that Cyrus, Mike, and I submitted in June. I thought it might be helpful to write up a quick summary of some of the issues that people have mentioned to me. Since one of our goals is to have consistency between vCard-in-XML and iCalendar-in-XML, I've also written up my understanding of how the vCard-XML draft handles these issues. 1) Date-time format: The xCalendar draft breaks out date/time values into separate XML elements for year/month/day and hour/minute/second. The main reason for choosing this format was to make it easier for implementers who want to transform the XML into a presentation format like HTML. The separate elements mean that no additional parsing is necessary. It does significantly increase the size of the XML format, however. One compromise that has been suggested is to make the XML element names smaller, i.e. instead of . Here's an example: 200926 1200 The xCard draft embeds the vCard time value in a single XML element:, which is obviously much more compact: 20090808T1430-0500 2) Extensibility: The xCalendar draft describes two kinds of extensions. Extensions that originate in iCal with the "x-" prefix are converted to XML elements with the same name (but in lowercase). Those extensions are in the same XML namespace as other xCalendar elements. This makes it straightforward to convert those extensions back to the iCal format. Other XML extension elements are allowed as well, but such extensions must not be in the xCalendar XML namespace. Such extensions are not convertible to the iCal format. In contrast, the xCard draft describes only the second kind of extension: those that are in a separate XML namespace. As far as I can tell, the xCard draft doesn't describe a way to convert those extensions to the vCard format. 3) XML attributes: The xCalendar draft currently uses attributes in two places. There is a "utc" attribute on date-time elements, and a "sign" attribute on duration elements. The xCard draft doesn't appear to use any XML attributes. This allows a simple transformation to key/value formats like JSON. It would be great to hear opinions on these or other issues. If you're attending IETF next week in Stockholm, the topic of XML formats for vCard and iCalendar is on the agenda for the vcarddav working group on Tuesday July 28: http://www.ietf.org/mail-archive/web/vcarddav/current/msg01105.html. Thanks, Steven ------=_NextPart_000_0049_01CA0A4D.5D556EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I won't be in Stockholm, but I'll throw my two = cents=20 in. 
 
I'm not an implementer (currently) but I = think=20 separating out all the elements of date and time doesn't gain that much = - there=20 are well-developed libraries of routines for parsing dates in ISO = format, I=20 believe,  so it should not be that costly to extract the date-time = value as=20 in xCard and deal with it.
 
My next comment is more of a question.  I = would have=20 mapped components and properties (VEVENT, DTSTART) to XML elements, and = all=20 property parameters to attributes - for example
 
    <ATTACH = fmttype=3D"text/plain"=20 encoding=3D"BASE64" = value=3D"binary">...</ATTACH>
 
Can you tell me what the thought process was = for having so=20 few attributes?
 
Tim Hare
Interested Bystander,=20 Non-Inc.
 

From: = ietf-calsify-bounces@osafoundation.org=20 [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of = Steven=20 Lees
Sent: Tuesday, July 21, 2009 7:45 PM
To:=20 ietf-calsify@osafoundation.org
Subject: [ietf-calsify] XML = iCalendar=20 issues and questions

Hello,

 

I haven’t seen much public comment on the XML = iCalendar draft=20 (http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-00.txt)=20 that Cyrus, Mike, and I submitted in June. I thought it might be helpful = to=20 write up a quick summary of some of the issues that people have = mentioned to me.=20 Since one of our goals is to have consistency between vCard-in-XML and=20 iCalendar-in-XML, I’ve also written up my understanding of how the = vCard-XML=20 draft handles these issues.

 

1) Date-time format:

The xCalendar draft breaks out date/time values = into separate=20 XML elements for year/month/day and hour/minute/second. The main reason = for=20 choosing this format was to make it easier for implementers who want to=20 transform the XML into a presentation format like HTML. The separate = elements=20 mean that no additional parsing is necessary. It does significantly = increase the=20 size of the XML format, however. One compromise that has been suggested = is to=20 make the XML element names smaller, i.e. <y> instead of=20 <year>.

 

Here’s an example:

       =20 <dtstart>

          = <date-time utc=3D"yes">

         &= nbsp; =20 <year>2009</year><month>2</month><day>6<= /day>

         &= nbsp; =20 <hour>12</hour><minute>0</minute><second>0&= lt;/second>

          = </date-time>

       =20 </dtstart>

 

The xCard draft embeds the vCard time value in a = single XML=20 element:, which is obviously much more compact:

 

       =20 <date-time>20090808T1430-0500</date-time>

 

2) Extensibility:

The xCalendar draft describes two kinds of = extensions.=20 Extensions that originate in iCal with the "x-" prefix are converted to = XML=20 elements with the same name (but in lowercase). Those extensions are in = the same=20 XML namespace as other xCalendar elements. This makes it straightforward = to=20 convert those extensions back to the iCal format. Other XML extension = elements=20 are allowed as well, but such extensions must not be in the xCalendar = XML=20 namespace. Such extensions are not convertible to the iCal=20 format.

 

In contrast, the xCard draft describes only the = second kind=20 of extension: those that are in a separate XML namespace. As far as I = can tell,=20 the xCard draft doesn't describe a way to convert those extensions to = the vCard=20 format.

 

3) XML attributes:

The xCalendar draft currently uses attributes in = two places.=20 There is a "utc" attribute on date-time elements, and a "sign" attribute = on=20 duration elements.

 

The xCard draft doesn't appear to use any XML = attributes.=20 This allows a simple transformation to key/value formats like=20 JSON.

 

 

It would be great to hear opinions on these or = other issues.=20 If you’re attending IETF next week in Stockholm, the topic of XML = formats for=20 vCard and iCalendar is on the agenda for the vcarddav working group on = Tuesday=20 July 28: http://www.ietf.org/mail-archive/web/vcarddav/current/msg01105.html.

 

Thanks,

Steven

 

------=_NextPart_000_0049_01CA0A4D.5D556EC0-- --===============1693887371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============1693887371==-- From ietf-calsify-bounces@osafoundation.org Thu Jul 23 12:12:29 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B46C3A6A48 for ; Thu, 23 Jul 2009 12:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 KryiuunQG9cY for ; Thu, 23 Jul 2009 12:12:24 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id B5C003A69C5 for ; Thu, 23 Jul 2009 12:12:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id ED65E3E3FB5; Thu, 23 Jul 2009 12:10:58 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7goc5kepbce; Thu, 23 Jul 2009 12:10:49 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 150AB3E3FBA; Thu, 23 Jul 2009 12:10:45 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 6EDBC3E3FBA for ; Thu, 23 Jul 2009 12:10:43 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePR5+pRw44h0 for ; Thu, 23 Jul 2009 12:10:35 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id E6C103E3FB5 for ; Thu, 23 Jul 2009 12:10:34 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 23 Jul 2009 12:10:33 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.179]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi; Thu, 23 Jul 2009 12:10:33 -0700 From: Steven Lees To: Tim Hare , "ietf-calsify@osafoundation.org" Thread-Topic: [ietf-calsify] XML iCalendar issues and questions Thread-Index: AQHKCm8ZguRZ/bk8w0GTUjVWSh77XJCDeuhg Date: Thu, 23 Jul 2009 19:10:33 +0000 Message-ID: <854B3F17B7AF524E9E6CB4A9004F8C6C1623729A@tk5ex14mbxc105.redmond.corp.microsoft.com> References: <854B3F17B7AF524E9E6CB4A9004F8C6C162299C0@tk5ex14mbxc105.redmond.corp.microsoft.com> <20090722015107.BE10B77D70B@leka.osafoundation.org> In-Reply-To: <20090722015107.BE10B77D70B@leka.osafoundation.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: Re: [ietf-calsify] XML iCalendar issues and questions X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2130568841==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============2130568841== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_854B3F17B7AF524E9E6CB4A9004F8C6C1623729Atk5ex14mbxc105r_" --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1623729Atk5ex14mbxc105r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim Hare wrote: "I'm not an implementer (currently) but I think separating out all the elem= ents of date and time doesn't gain that much - there are well-developed lib= raries of routines for parsing dates in ISO format, I believe, so it shoul= d not be that costly to extract the date-time value as in xCard and deal wi= th it." As you'd expect, we discussed this quite a bit. We did have a preference fo= r the format shown in the current draft, but if there's strong opinion the = other way I don't think any of the co-authors would strongly object to a si= ngle element. Tim also wrote: "My next comment is more of a question. I would have mapped components and= properties (VEVENT, DTSTART) to XML elements, and all property parameters = to attributes - for example ...= Can you tell me what the thought process was for having so few attributes?" It's been a while since we settled on that part of the format, so I don't r= emember all of the reasons. One reason was that there are a couple of multi= -valued parameters such as delegated-from and delegated-to, and we didn't w= ant to have to stuff all of the values in a single attribute string. We cou= ld have special-cased those parameters, but we wanted to maintain consisten= cy if possible to make implementation easier. We were also leaning slightly= away from attributes because if you don't use them at all, then you can do= a simple translation between XML and JSON. Steven --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1623729Atk5ex14mbxc105r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim Hare wrote:

 =

“I'm not an implementer (currently) but I think separating out all the elements of date and time doesn't gain that much - t= here are well-developed libraries of routines for parsing dates in ISO format, I believe,  so it should not be that costly to extract the date-time val= ue as in xCard and deal with it.”

 =

As you’d expect, w= e discussed this quite a bit. We did have a preference for the format shown i= n the current draft, but if there’s strong opinion the other way I don&= #8217;t think any of the co-authors would strongly object to a single element.=

 =

Tim also wrote:

 =

“My next comment is more of a question.  I would hav= e mapped components and properties (VEVENT, DTSTART) to XML elements, and all proper= ty parameters to attributes - for example

 

    <ATTACH fmttype=3D"text/plain" encoding=3D"BASE64" value=3D"binary">...</ATTACH&= gt;

 

Can you tell me what the thought process was for having so few attributes?”

 

It’s been a while = since we settled on that part of the format, so I don’t remember all of the reasons. One reason was that there are a couple of multi-valued parameters = such as delegated-from and delegated-to, and we didn’t want to have to stu= ff all of the values in a single attribute string. We could have special-cased= those parameters, but we wanted to maintain consistency if possible to make implementation easier. We were also leaning slightly away from attributes because if you don’t use them at all, then you can do a simple transl= ation between XML and JSON.

 

Steven=

 =

 

--_000_854B3F17B7AF524E9E6CB4A9004F8C6C1623729Atk5ex14mbxc105r_-- --===============2130568841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============2130568841==-- From calsify-bounces@ietf.org Tue Jul 28 07:32:56 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA17E3A7011; Tue, 28 Jul 2009 07:32:56 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960233A7011; Tue, 28 Jul 2009 07:32:55 -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 ceov7azyE1OF; Tue, 28 Jul 2009 07:32:52 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 382893A6FFE; Tue, 28 Jul 2009 07:32:52 -0700 (PDT) Received: by gxk9 with SMTP id 9so93399gxk.13 for ; Tue, 28 Jul 2009 07:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=leG84ezo152qqG8PkDT9lvpPh7kDV7QVYew2g8g0vmk=; b=jiOZ+FRrdTWMlkdL9he+MEa0950rXEdrSm/WzvR2AEvElvj6IDe0Ty1//PwnjMT8lb MbFyl8T9M8EIzKTG5HZHGfpw7kYHuK8VAMWnXBpt6oeFKq9ozzvgtHkeYiNuYB9W9WIX JH3gEz8AldhAJhcupuWG/3/dwFQnpwSBM4WUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=CedcTtZhXOWnBFWPH/gBHU2tX9CKSM3rQriOT58H/AL6jpr0YdFyMuF5NK1oiy60Ck HFJigU0NFDp8Qk3HJs1nNcuNyRr5aSy7gZmXWdCUc3HfuMWRJoU91y4ZttUld8btGpbj nEJLPQv9qf//KwYyZy+zV9m9Qf4OcMlWa3G/A= MIME-Version: 1.0 Received: by 10.90.116.15 with SMTP id o15mr7095359agc.75.1248791569772; Tue, 28 Jul 2009 07:32:49 -0700 (PDT) Date: Tue, 28 Jul 2009 10:32:49 -0400 Message-ID: From: Rick DeNatale To: caldav@ietf.org, calsify@ietf.org Subject: [calsify] Looking for resources to debug webdav server X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org I'm hoping someone can point me to some help sources. I'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. Instead it sends a propfind which only occurs after the connection setup handshaking with google cal. 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=0 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=utf-8 Connection: Keep-Alive, close /caldav/calendar/Personal/ HTTP/1.1 200 OK /caldav/calendar/ mailto:virtuser@cals.37s.backpack.com /caldav/calendar/virtuser%40cals.37s.backpack.com/user/ /caldav/calendar/virtuser%40cals.37s.backpack.com/inbox/ /caldav/calendar/virtuser%40cals.37s.backpack.com/outbox/ Personal HTTP/1.1 404 Not Found 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. There'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 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From rick.denatale@gmail.com Tue Jul 28 07:32:55 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960233A7011; Tue, 28 Jul 2009 07:32:55 -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 ceov7azyE1OF; Tue, 28 Jul 2009 07:32:52 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 382893A6FFE; Tue, 28 Jul 2009 07:32:52 -0700 (PDT) Received: by gxk9 with SMTP id 9so93399gxk.13 for ; Tue, 28 Jul 2009 07:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=leG84ezo152qqG8PkDT9lvpPh7kDV7QVYew2g8g0vmk=; b=jiOZ+FRrdTWMlkdL9he+MEa0950rXEdrSm/WzvR2AEvElvj6IDe0Ty1//PwnjMT8lb MbFyl8T9M8EIzKTG5HZHGfpw7kYHuK8VAMWnXBpt6oeFKq9ozzvgtHkeYiNuYB9W9WIX JH3gEz8AldhAJhcupuWG/3/dwFQnpwSBM4WUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=CedcTtZhXOWnBFWPH/gBHU2tX9CKSM3rQriOT58H/AL6jpr0YdFyMuF5NK1oiy60Ck HFJigU0NFDp8Qk3HJs1nNcuNyRr5aSy7gZmXWdCUc3HfuMWRJoU91y4ZttUld8btGpbj nEJLPQv9qf//KwYyZy+zV9m9Qf4OcMlWa3G/A= MIME-Version: 1.0 Received: by 10.90.116.15 with SMTP id o15mr7095359agc.75.1248791569772; Tue, 28 Jul 2009 07:32:49 -0700 (PDT) Date: Tue, 28 Jul 2009 10:32:49 -0400 Message-ID: From: Rick DeNatale To: caldav@ietf.org, calsify@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [calsify] Looking for resources to debug webdav server X-BeenThere: calsify@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:32:55 -0000 I'm hoping someone can point me to some help sources. I'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. Instead it sends a propfind which only occurs after the connection setup handshaking with google cal. 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=0 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=utf-8 Connection: Keep-Alive, close /caldav/calendar/Personal/ HTTP/1.1 200 OK /caldav/calendar/ mailto:virtuser@cals.37s.backpack.com /caldav/calendar/virtuser%40cals.37s.backpack.com/user/ /caldav/calendar/virtuser%40cals.37s.backpack.com/inbox/ /caldav/calendar/virtuser%40cals.37s.backpack.com/outbox/ Personal HTTP/1.1 404 Not Found 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. There'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 calsify-bounces@ietf.org Tue Jul 28 10:54:29 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390C33A6ABA; Tue, 28 Jul 2009 10:54:29 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DF33A6ABA; Tue, 28 Jul 2009 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.366 X-Spam-Level: **** X-Spam-Status: No, score=4.366 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, 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 J-YtlSyhCYcV; Tue, 28 Jul 2009 10:54:26 -0700 (PDT) Received: from carancho.yaco.es (38.Red-80-36-82.staticIP.rima-tde.net [80.36.82.38]) by core3.amsl.com (Postfix) with ESMTP id 51FF63A68A5; Tue, 28 Jul 2009 10:54:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by carancho.yaco.es (Postfix) with ESMTP id 08F979E4067; Tue, 28 Jul 2009 20:03:30 +0200 (CEST) Received: from carancho.yaco.es ([127.0.0.1]) by localhost (carancho.yaco.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18824-01-79; Tue, 28 Jul 2009 20:03:29 +0200 (CEST) Received: from [192.168.1.6] (unknown [84.76.239.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by carancho.yaco.es (Postfix) with ESMTP id 891459E403B; Tue, 28 Jul 2009 20:03:28 +0200 (CEST) From: Ernesto Revilla To: Rick DeNatale In-Reply-To: References: Date: Tue, 28 Jul 2009 19:54:18 +0200 Message-Id: <1248803658.7304.10.camel@trac.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at yaco.es Cc: caldav@ietf.org, calsify@ietf.org Subject: Re: [calsify] Looking for resources to debug webdav server X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org SSBkb24ndCBzZWUgYW55IGVycm9ycywgYnV0IGNvdWxkIHlvdSB0cnkgdG8gcHV0IHRoZSBDOiBu YW1lc3BhY2UKZGVjbGFyYXRpb24gaW50byB0aGUgbXVsdGlzdGF0dXMgcmVzcG9uc2U/Cgpzb21l dGhpbmcgbGlrZSB0aGlzOiAoREFWOiBpcyBkZWZhdWx0IG5hbWVzcGFjZSkKCjw/eG1sIHZlcnNp b249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+CjxtdWx0aXN0YXR1cyB4bWxucz0iREFWOiIgeG1s bnM6bnMxPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmNhbGRhdiI+CiA8cmVzcG9uc2U+CiAgIDxo cmVmPi9jYWxkYXYvY2FsZW5kYXIvUGVyc29uYWwvPC9ocmVmPgogICA8cHJvcHN0YXQ+CiAgICAg PHN0YXR1cz5IVFRQLzEuMSAyMDAgT0s8L3N0YXR1cz4KICAgICA8cHJvcD4KICAgICAgIDxDOmNh bGVuZGFyLWhvbWUtc2V0PgogICAgICAgICA8aHJlZj4vY2FsZGF2L2NhbGVuZGFyLzxocmVmPgog ICAgICAgPC9DOmNhbGVuZGFyLWhvbWUtc2V0PgogICAgICAgPEM6Y2FsZW5kYXItdXNlci1hZGRy ZXNzLXNldD4KICAgICAgICAgPGhyZWY+bWFpbHRvOnZpcnR1c2VyQGNhbHMuMzdzLmJhY2twYWNr LmNvbTwvaHJlZj4KICAgICAgICAgPGhyZWY+L2NhbGRhdi9jYWxlbmRhci92aXJ0dXNlciU0MGNh bHMuMzdzLmJhY2twYWNrLmNvbS91c2VyLzwvaHJlZj4KICAgICAgIDwvQzpjYWxlbmRhci11c2Vy LWFkZHJlc3Mtc2V0PgogICAgICAgPGRpc3BsYXluYW1lPlBlcnNvbmFsPC9kaXNwbGF5bmFtZT4K ICAgICA8L3Byb3A+CiAgIDwvcHJvcHN0YXQ+CiA8L3Jlc3BvbnNlPgo8bXVsdGlzdGF0dXM+CgpS ZWdhcmRzLgpFcm55CllhY28gU2lzdGVtYXMKU3BhaW4KCgoKRWwgbWFyLCAyOC0wNy0yMDA5IGEg bGFzIDEwOjMyIC0wNDAwLCBSaWNrIERlTmF0YWxlIGVzY3JpYmnDszoKPiBJJ20gaG9waW5nIHNv bWVvbmUgY2FuIHBvaW50IG1lIHRvIHNvbWUgaGVscCBzb3VyY2VzLiAgSSdtIHN0cmlraW5nCj4g b3V0IHdpdGggZ29vZ2xlLiBXaGlsZSBJIGZpbmQgY2FsZGF2IHRocmVhZHMsIG1vc3QgYXBwZWFy IHRvIGJlIGZyb20KPiB0aGUgY2xpZW50IHZpZXdwb2ludC4gSSB0cmllZCBmaW5kaW5nIGlyYyBj aGFubmVscyBhbmQgdGhlIGxpa2UgYnV0Cj4gY2FuJ3QgZmluZCBhbnl0aGluZyB3aGljaCBhcHBl YXJzIHRvIGJlIGFjdGl2ZS4KPiAKPiBJJ20gdHJ5aW5nIHRvIGFkZCB3ZWJkYXYgc3VwcG9ydCB0 byBhbiBleGlzdGluZyBydWJ5IG9uIHJhaWxzCj4gYXBwbGljYXRpb24gd2hpY2ggYWxyZWFkeSBz dXBwb3J0cyBjYWxlbmRhcnMuCj4gCj4gSSd2ZSBiZWVuIHRyeWluZyB0byBmaWd1cmUgb3V0IHRo ZSByZWFsaXRpZXMgb2YgY2FsZGF2IGJ5IHNub29waW5nIG9uCj4gdGhlIGNvbnZlcnNhdGlvbiBi ZXR3ZWVuIGljYWwuYXBwIGFuZCBnb29nbGUgY2FsZW5kYXIgZXN0YWJsaXNoaW5nIGEKPiB3ZWJk YXYgYWNjb3VudCBhbmQgdGhlbiBzeW5jaW5nLCBhbmQgdGhlbiB0cnlpbmcsIGFzIGEgZmlyc3Qg c3RlcCB0bwo+IHNlbmQgY2FubmVkIHJlc3BvbnNlcyB0byB0aGUgcHJvcGZpbmQgcmVxdWVzdHMg c2VudCBieSBpY2FsLmFwcCBmcm9tCj4gbXkgc2VydmVyIGFwcC4KPiAKPiBCdXQgSSdtIHNlZWlu ZyBzb21lIHN0cmFuZ2UgdGhpbmdzLgo+IAo+IEZpcnN0LCBmb3IgdGhlIGZpcnN0IGNvbm5lY3Rp b24gdG8gZ29vZ2xlIGNhbGVuZGFyIGluIGVzdGFibGlzaGluZyBhbgo+IGFjY291bnQsIGljYWwu YXBwIGlzIHNlbmRpbmcgc29tZSBwcm9wZmluZHMgd2hpY2ggSSBhbSBub3Qgc2VlaW5nIHdoZW4K PiBpdCB0cmllcyB0byBlc3RhYmxpc2ggYW4gYWNjb3VudCB3aXRoIG15IHNlcnZlciBhcHAuICBJ bnN0ZWFkIGl0IHNlbmRzCj4gYSBwcm9wZmluZCB3aGljaCBvbmx5IG9jY3VycyBhZnRlciB0aGUg Y29ubmVjdGlvbiBzZXR1cCBoYW5kc2hha2luZwo+IHdpdGggZ29vZ2xlIGNhbC4KPiAKPiA8P3ht bCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtOCI/Pgo+IDx4MDpwcm9wZmluZCB4bWxuczp4 Mj0iaHR0cDovL2NhbGVuZGFyc2VydmVyLm9yZy9ucy8iCj4geG1sbnM6eDE9InVybjppZXRmOnBh cmFtczp4bWw6bnM6Y2FsZGF2IiB4bWxuczp4MD0iREFWOiI+Cj4gIDx4MDpwcm9wPgo+ICA8eDE6 Y2FsZW5kYXItaG9tZS1zZXQvPgo+ICA8eDE6Y2FsZW5kYXItdXNlci1hZGRyZXNzLXNldC8+Cj4g IDx4MTpzY2hlZHVsZS1pbmJveC1VUkwvPgo+ICA8eDE6c2NoZWR1bGUtb3V0Ym94LVVSTC8+Cj4g IDx4Mjpkcm9wYm94LWhvbWUtVVJMLz4KPiAgPHgyOm5vdGlmaWNhdGlvbnMtVVJMLz4KPiAgPHgw OmRpc3BsYXluYW1lLz4KPiAgPC94MDpwcm9wPgo+IDwveDA6cHJvcGZpbmQ+Cj4gCj4gU2Vjb25k LCB3aGVuIEkgcmVzcG9uZCB0byB0aGUgcHJvcGZpbmQgd2l0aCB3aGF0IEkgdGhpbmsgaXMgYSB2 YWxpZAo+IHJlc3BvbnNlLCBzYW1lIGhlYWRlcnMsIGFuZCB2YWxpZCB4bWwgZm9yIHRoZSBib2R5 LCBpY2FsLmFwcCBkb2Vzbid0Cj4gc2VlbSB0byBsaWtlIGl0Cj4gCj4gSFRUUC8xLjEgMjA3IE11 bHRpLVN0YXR1cwo+IFgtUG93ZXJlZC1CeTogUGh1c2lvbiBQYXNzZW5nZXIgKG1vZF9yYWlscy9t b2RfcmFjaykgMi4yLjQKPiBDYWNoZS1Db250cm9sOiBwcml2YXRlLCBtYXgtYWdlPTAKPiBTdGF0 dXM6IDIwNyBNdWx0aS1TdGF0dXMKPiBYLVJ1bnRpbWU6IDAuNTQyNDIKPiBTZXJ2ZXI6IEFwYWNo ZS8yLjIuMTEgKFVuaXgpIG1vZF9zc2wvMi4yLjExIE9wZW5TU0wvMC45LjdsIERBVi8yCj4gUGh1 c2lvbl9QYXNzZW5nZXIvMi4yLjQKPiBEQVY6IDEsIGNhbGVuZGFyLWFjY2VzcywgY2FsZW5kYXIt c2NoZWR1bGUsIGNhbGVuZGFyLXByb3h5Cj4gRGF0ZTogVGh1LCAyMyBKdWwgMjAwOSAxNDoyOTow NSBHTVQKPiBDb250ZW50LUxlbmd0aDogMTM3NQo+IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v eG1sOyBjaGFyc2V0PXV0Zi04Cj4gQ29ubmVjdGlvbjogS2VlcC1BbGl2ZSwgY2xvc2UKPiAKPiA8 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pgo+IDxEOm11bHRpc3RhdHVzIHht bG5zOkQ9IkRBVjoiPgo+ICA8RDpyZXNwb25zZT4KPiAgICA8RDpocmVmPi9jYWxkYXYvY2FsZW5k YXIvUGVyc29uYWwvPC9EOmhyZWY+Cj4gICAgPEQ6cHJvcHN0YXQ+Cj4gICAgICA8RDpzdGF0dXM+ SFRUUC8xLjEgMjAwIE9LPC9EOnN0YXR1cz4KPiAgICAgIDxEOnByb3A+Cj4gICAgICAgIDxDOmNh bGVuZGFyLWhvbWUtc2V0IHhtbG5zOkM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6Y2FsZGF2Ij4K PiAgICAgICAgICA8RDpocmVmPi9jYWxkYXYvY2FsZW5kYXIvPC9EOmhyZWY+Cj4gICAgICAgIDwv QzpjYWxlbmRhci1ob21lLXNldD4KPiAgICAgICAgPEM6Y2FsZW5kYXItdXNlci1hZGRyZXNzLXNl dCB4bWxuczpDPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmNhbGRhdiI+Cj4gICAgICAgICAgPEQ6 aHJlZj5tYWlsdG86dmlydHVzZXJAY2Fscy4zN3MuYmFja3BhY2suY29tPC9EOmhyZWY+Cj4gICAg ICAgICAgPEQ6aHJlZj4vY2FsZGF2L2NhbGVuZGFyL3ZpcnR1c2VyJTQwY2Fscy4zN3MuYmFja3Bh Y2suY29tL3VzZXIvPC9EOmhyZWY+Cj4gICAgICAgIDwvQzpjYWxlbmRhci11c2VyLWFkZHJlc3Mt c2V0Pgo+ICAgICAgICA8QzpzY2hlZHVsZS1pbmJveC1VUkwgeG1sbnM6Qz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpjYWxkYXYiPgo+ICAgICAgICAgIDxEOmhyZWY+L2NhbGRhdi9jYWxlbmRhci92 aXJ0dXNlciU0MGNhbHMuMzdzLmJhY2twYWNrLmNvbS9pbmJveC88L0Q6aHJlZj4KPiAgICAgICAg PC9DOnNjaGVkdWxlLWluYm94LVVSTD4KPiAgICAgICAgPEM6c2NoZWR1bGUtb3V0Ym94LVVSTCB4 bWxuczpDPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmNhbGRhdiI+Cj4gICAgICAgICAgPEQ6aHJl Zj4vY2FsZGF2L2NhbGVuZGFyL3ZpcnR1c2VyJTQwY2Fscy4zN3MuYmFja3BhY2suY29tL291dGJv eC88L0Q6aHJlZj4KPiAgICAgICAgPC9DOnNjaGVkdWxlLW91dGJveC1VUkw+Cj4gICAgICAgIDxE OmRpc3BsYXluYW1lPlBlcnNvbmFsPC9EOmRpc3BsYXluYW1lPgo+ICAgICAgPC9EOnByb3A+Cj4g ICAgPC9EOnByb3BzdGF0Pgo+ICAgIDxEOnByb3BzdGF0Pgo+ICAgICAgPEQ6c3RhdHVzPkhUVFAv MS4xIDQwNCBOb3QgRm91bmQ8L0Q6c3RhdHVzPgo+ICAgICAgPEQ6cHJvcD4KPiAgICAgICAgPHgy OmRyb3Bib3gtaG9tZS1VUkwgeG1sbnM6eDI9Imh0dHA6Ly9jYWxlbmRhcnNlcnZlci5vcmcvbnMv IiAvPgo+ICAgICAgICA8eDI6bm90aWZpY2F0aW9ucy1VUkwgeG1sbnM6eDI9Imh0dHA6Ly9jYWxl bmRhcnNlcnZlci5vcmcvbnMvIiAvPgo+ICAgICAgPC9EOnByb3A+Cj4gICAgPC9EOnByb3BzdGF0 Pgo+ICA8L0Q6cmVzcG9uc2U+Cj4gPC9EOm11bHRpc3RhdHVzPgo+IAo+IEJ1dCBpY2FsLmFwcCBw dXRzIHVwIGFuIGVycm9yIGRpYWxvZyB3aXRoIHRoZSBtZXNzYWdlICJSZXF1ZXN0Cj4gZW5jb3Vu dGVyZWQgYW4gdW5leHBlY3RlZCBlcnJvciAoZG9tYWluIENhbERBViBObyBDYWxlbmRhciBIb21l IEVycm9yCj4gLyBjb2RlIDEpLiIKPiAKPiBJJ3ZlIHRyaWVkIHRvIGZpbmQgYW4gaXJjIGNoYW5u ZWwgd2hpY2ggbWlnaHQgaGF2ZSBzb21lb25lIHdobyBjb3VsZCBoZWxwCj4gCj4gSSBmb3VuZCBh IGNhbGVuZGFyc2VydmVyIGlyYyBjaGFubmVsIChmb3IgQXBwbGUncyBDYWxlbmRhclNlcnZlcgo+ IHByb2plY3QpIGJ1dCBubyBvbmUgc2VlbXMgdG8gYmUgcmVzcG9uc2l2ZS4gIFRoZXJlJ3MgYW5v dGhlciBjYWxkYXYKPiBjaGFubmVsIGFzc29jaWF0ZWQgd2l0aCBDaGFuZGxlciwgYnV0IG5vIG9u ZSBzZWVtcyB0byBiZSBob21lLgo+IAo+IFNvLCBkb2VzIGFueW9uZSBoYXZlIGFueSBzdWdnZXN0 aW9ucyBhYm91dCB3aGVyZSBJIG1pZ2h0IGdldCBzb21lIGhlbHAKPiBpbiBmaWd1cmluZyB0aGlz IG91dD8KPiAKPiAtLSAKPiBSaWNrIERlTmF0YWxlCj4gCj4gQmxvZzogaHR0cDovL3RhbGtsaWtl YWR1Y2suZGVuaGF2ZW4yLmNvbS8KPiBUd2l0dGVyOiBodHRwOi8vdHdpdHRlci5jb20vUmlja0Rl TmF0YWxlCj4gV1dSOiBodHRwOi8vd3d3Lndvcmtpbmd3aXRocmFpbHMuY29tL3BlcnNvbi85MDIx LXJpY2stZGVuYXRhbGUKPiBMaW5rZWRJbjogaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcmlj a2RlbmF0YWxlCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiBjYWxzaWZ5IG1haWxpbmcgbGlzdAo+IGNhbHNpZnlAaWV0Zi5vcmcKPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmNhbHNpZnkgbWFpbGluZyBsaXN0CmNhbHNpZnlA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5Cg== From erevilla@yaco.es Tue Jul 28 10:54:27 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DF33A6ABA; Tue, 28 Jul 2009 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.366 X-Spam-Level: **** X-Spam-Status: No, score=4.366 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, 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 J-YtlSyhCYcV; Tue, 28 Jul 2009 10:54:26 -0700 (PDT) Received: from carancho.yaco.es (38.Red-80-36-82.staticIP.rima-tde.net [80.36.82.38]) by core3.amsl.com (Postfix) with ESMTP id 51FF63A68A5; Tue, 28 Jul 2009 10:54:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by carancho.yaco.es (Postfix) with ESMTP id 08F979E4067; Tue, 28 Jul 2009 20:03:30 +0200 (CEST) Received: from carancho.yaco.es ([127.0.0.1]) by localhost (carancho.yaco.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18824-01-79; Tue, 28 Jul 2009 20:03:29 +0200 (CEST) Received: from [192.168.1.6] (unknown [84.76.239.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by carancho.yaco.es (Postfix) with ESMTP id 891459E403B; Tue, 28 Jul 2009 20:03:28 +0200 (CEST) From: Ernesto Revilla To: Rick DeNatale In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Tue, 28 Jul 2009 19:54:18 +0200 Message-Id: <1248803658.7304.10.camel@trac.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at yaco.es Cc: caldav@ietf.org, calsify@ietf.org Subject: Re: [calsify] Looking for resources to debug webdav server X-BeenThere: calsify@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 17:54:27 -0000 I don't see any errors, but could you try to put the C: namespace declaration into the multistatus response? something like this: (DAV: is default namespace) /caldav/calendar/Personal/ HTTP/1.1 200 OK /caldav/calendar/ mailto:virtuser@cals.37s.backpack.com /caldav/calendar/virtuser%40cals.37s.backpack.com/user/ Personal Regards. Erny Yaco Sistemas Spain El mar, 28-07-2009 a las 10:32 -0400, Rick DeNatale escribió: > I'm hoping someone can point me to some help sources. I'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. 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:"> > > > > > > > > > > > > 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=0 > 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=utf-8 > Connection: Keep-Alive, close > > > > > /caldav/calendar/Personal/ > > HTTP/1.1 200 OK > > > /caldav/calendar/ > > > mailto:virtuser@cals.37s.backpack.com > /caldav/calendar/virtuser%40cals.37s.backpack.com/user/ > > > /caldav/calendar/virtuser%40cals.37s.backpack.com/inbox/ > > > /caldav/calendar/virtuser%40cals.37s.backpack.com/outbox/ > > Personal > > > > HTTP/1.1 404 Not Found > > > > > > > > > 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. There'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 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify