Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B28E27F966 for ; Sun, 30 Jul 2006 11:26:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A43DD14226B for ; Sun, 30 Jul 2006 11:26:47 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25393-08 for ; Sun, 30 Jul 2006 11:26:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id D6E72142269 for ; Sun, 30 Jul 2006 11:26:45 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2006 18:26:43 -0000 Received: from p508FB5C9.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.181.201] by mail.gmx.net (mp001) with SMTP; 30 Jul 2006 20:26:43 +0200 X-Authenticated: #1915285 Message-ID: <44CCF9D1.40902@gmx.de> Date: Sun, 30 Jul 2006 20:26:25 +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: iesg@ietf.org References: <44CBD0FF.9010904@gmx.de> In-Reply-To: <44CBD0FF.9010904@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: CalDAV DevList Subject: [Ietf-caldav] Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav) X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 18:26:47 -0000 Hi, below are last call comments, interleaved with the spec text. Best regards, Julian -- Section 1., para. 2: Discussion of this specification is taking place on the mailing list . [[anchor2: Clarify that this paragraph should be removed upon publication --reschke]] Section 1.2., para. 3: 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. [[anchor5: "...MUST NOT use these declarations as the only way..." is extremly hard to understand; the presence of RFC2119 keywords make things worse in that the reader is confused to believe that a normative statement is being made. As far as I can tell, all this wants to say is that the missing namespace needs to be taken into account. Please clarify. --reschke]] Some of the declarations refer to XML elements defined by WebDAV [I-D.ietf-webdav-rfc2518bis] which use the "DAV:" namespace. Wherever such XML elements appear, they are explicitly prefixed with "DAV:" to avoid confusion. Section 2., para. 5: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); [[anchor6: I assume that the down reference to RFC2818 (informational RFC) is intended; but what about the stuff with RFC2246? Why doesn't spec refer to RFC4346 instead? --reschke]] Section 3.1., para. 4: The CalDAV server or repository is the canonical location for calendar data and state information. [[anchor8: "server or repository": I think it would be good if the spec would choose one term and stick with it --reschke]] Both CalDAV servers and clients MUST ensure that the data is consistent and compliant. [[anchor9: What does it exactly mean for the data to be "consistent" and "compliant"? If there's no exact definition for that then the "MUST" should go --reschke]] Clients may submit requests to change data or download data. Clients may store calendar objects offline and attempt to synchronize at a later time. However, clients MUST be prepared for calendar data on the server to change between the time of last synchronization and when attempting an update, as calendar collections may be shared and accessible via multiple clients. Entity tags and other features make this possible. Section 5.2.4., para. 5: Description: The CALDAV:supported-calendar-data property is used to specify the media type supported for the calendar object resources contained in a given calendar collection (e.g., iCalendar version 2.0). Any attempt by the client to store calendar object resources with a media type not listed in this property MUST result in an error, with the CALDAV:supported-calendar-data precondition (Section 5.3.2.1) being violated. In the absence of this property the server MUST accept data with the media type "text/calendar" and iCalendar version 2.0, and clients can assume that. [[anchor15: What about other types in this case? --reschke]] Section 5.3.1., para. 3: Clients SHOULD use the DAV:displayname property for a human-readable name of the calendar. Clients can either specify the value of the DAV:displayname property in the request body of the MKCALENDAR request, or alternatively issue a PROPPATCH request to change the DAV:displayname property to the appropriate value immediately after issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: displayname property to be the same as any other calendar collection at the same URI "level". When displaying calendar collections to users, clients SHOULD check the DAV:displayname property and use that value as the name of the calendar. In the event that the DAV: displayname property is empty, the client MAY use the last part of the calendar collection URI as the name, however that path segment may be "opaque" and not represent any meaningful human-readable text. [[anchor17: This seems to profile DAV:displayname as defined by RFC2518bis. Furthermore it's not clear what happens when the client violates the constraint. --reschke]] Section 5.3.4., para. 4: In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted calendar object resource, the behavior of the ETag response header is not specified here, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, clients may need to retrieve the modified calendar object resource (and ETag) as a basis for further changes, rather than use the calendar object resource it had sent with the PUT request. [[anchor22: See comments on ietf- discuss mailing list. --reschke]] Section 6.2.1., para. 4: Conformance: This property MAY be defined in a principal resource. If defined, it MAY be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [I-D.ietf-webdav-rfc2518bis]). Support for this property is RECOMMENDED. [[anchor24: Doesn't compute. Is this a MAY (OPTIONAL) or a SHOULD (RECOMMENDED)? --reschke]] Section 7.5., para. 1: Some calendaring REPORTs defined in this document allow partial retrieval of calendar object resources. A CalDAV client MAY specify what information to return in the body of a calendaring REPORT request. [[anchor29: Why does this simple statement require RFC2219 terminology? Please don't over-use it. In particular, please check that all "MAY" requirements really are needed for the purposes outlined in RFC2219. --reschke]] Section 7.7.6., para. 1: In this example, the client requests the server to return the VEVENT component that has the UID property set to "DC6C50A017428C5216A2F1CD@example.com". [[anchor37: Is whitespace significant here? In which case the example below would be invalid. -reschke]] Section 7.8., para. 4: The request body MUST be a CALDAV:calendar-multiget XML element (see Section 9.9). If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client. [[anchor42: Bad idea. Just stick with RFC3253/RFC3744 terminology (invalid depth values are rejected by the server, not ignored). This leaves the possibilily to later define semantics for these values. --reschke]] If the Request-URI refers to a non-collection resource, then there MUST be a single DAV:href element that is equivalent to the Request-URI. Section 8.4., para. 3: For calendar sharing and scheduling use cases, one might wish to find the calendar belonging to another user. If the other user has a calendar in the same repository, that calendar can be found by using the principal namespace required by WebDAV ACL support. For other cases, the authors have no universal solution but implementers can consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards together with calendar attributes [RFC2739]. [[anchor55: LDAP reference is outdated. --reschke]] Section 8.5.2., para. 1: CalDAV clients SHOULD support downloading of external attachments referenced by arbitrary URI schemes, by either processing them directly, or by passing the attachment URI to a suitable "helper application" for processing, if such an application exists. CalDAV clients MUST support downloading of external attachments referenced by the "http" URI scheme, and MAY support downloading of external attachments referenced by the "https" URI scheme. An external attachment could be: [[anchor59: Very confusing: MAY, SHOULD and MUST requirements for basically the same thing. In particular, the MAY for "https" is bogus, because the spec just stated that the client SHOULD support arbitrary schemes. --reschke]] Section 9.5., para. 7: Note: The CALDAV:calendar-data XML element is specified in requests and responses inside the DAV:prop XML element as if it were a WebDAV property. However, the CALDAV:calendar-data XML element is not a WebDAV property and as such it is not returned in PROPFIND responses nor used in PROPPATCH requests. [[anchor62: For this reason, I think a syntax where it can't be confused with a property whould be better. --reschke]] Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 694D57F815 for ; Sat, 29 Jul 2006 14:20:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 563F1142284 for ; Sat, 29 Jul 2006 14:20:11 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10587-08 for ; Sat, 29 Jul 2006 14:20:11 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 98C1114227B for ; Sat, 29 Jul 2006 14:20:09 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2006 21:19:58 -0000 Received: from p508FADCC.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.173.204] by mail.gmx.net (mp010) with SMTP; 29 Jul 2006 23:19:58 +0200 X-Authenticated: #1915285 Message-ID: <44CBD0FF.9010904@gmx.de> Date: Sat, 29 Jul 2006 23:19:59 +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: iesg@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030400070702060103000103" X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Mailman-Approved-At: Wed, 02 Aug 2006 10:27:43 -0700 Cc: CalDAV DevList Subject: [Ietf-caldav] Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav) X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 21:20:11 -0000 This is a multi-part message in MIME format. --------------030400070702060103000103 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, below are last call comments, interleaved with the spec text (plus additional as HTML formatted diffs to draft 13). Best regards, Julian -- Section 1., para. 2: OLD: Discussion of this specification is taking place on the mailing list . NEW: Discussion of this specification is taking place on the mailing list . [[anchor2: Clarify that this paragraph should be removed upon publication --reschke]] Section 1.2., para. 3: OLD: 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 defined by WebDAV [I-D.ietf-webdav-rfc2518bis] which use the "DAV:" namespace. Wherever such XML elements appear, they are explicitly prefixed with "DAV:" to avoid confusion. NEW: 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. [[anchor5: "...MUST NOT use these declarations as the only way..." is extremly hard to understand; the presence of RFC2119 keywords make things worse in that the reader is confused to believe that a normative statement is being made. As far as I can tell, all this wants to say is that the missing namespace needs to be taken into account. Please clarify. --reschke]] Some of the declarations refer to XML elements defined by WebDAV [I-D.ietf-webdav-rfc2518bis] which use the "DAV:" namespace. Wherever such XML elements appear, they are explicitly prefixed with "DAV:" to avoid confusion. Section 2., para. 5: OLD: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); NEW: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); [[anchor6: I assume that the down reference to RFC2818 (informational RFC) is intended; but what about the stuff with RFC2246? Why doesn't spec refer to RFC4346 instead? --reschke]] Section 3.1., para. 4: OLD: The CalDAV server or repository is the canonical location for calendar data and state information. Both CalDAV servers and clients MUST ensure that the data is consistent and compliant. Clients may submit requests to change data or download data. Clients may store calendar objects offline and attempt to synchronize at a later time. However, clients MUST be prepared for calendar data on the server to change between the time of last synchronization and when attempting an update, as calendar collections may be shared and accessible via multiple clients. Entity tags and other features make this possible. NEW: The CalDAV server or repository is the canonical location for calendar data and state information. [[anchor8: "server or repository": I think it would be good if the spec would choose one term and stick with it --reschke]] Both CalDAV servers and clients MUST ensure that the data is consistent and compliant. [[anchor9: What does it exactly mean for the data to be "consistent" and "compliant"? If there's no exact definition for that then the "MUST" should go --reschke]] Clients may submit requests to change data or download data. Clients may store calendar objects offline and attempt to synchronize at a later time. However, clients MUST be prepared for calendar data on the server to change between the time of last synchronization and when attempting an update, as calendar collections may be shared and accessible via multiple clients. Entity tags and other features make this possible. Section 5.2.4., para. 5: OLD: Description: The CALDAV:supported-calendar-data property is used to specify the media type supported for the calendar object resources contained in a given calendar collection (e.g., iCalendar version 2.0). Any attempt by the client to store calendar object resources with a media type not listed in this property MUST result in an error, with the CALDAV:supported-calendar-data precondition (Section 5.3.2.1) being violated. In the absence of this property the server MUST accept data with the media type "text/calendar" and iCalendar version 2.0, and clients can assume that. NEW: Description: The CALDAV:supported-calendar-data property is used to specify the media type supported for the calendar object resources contained in a given calendar collection (e.g., iCalendar version 2.0). Any attempt by the client to store calendar object resources with a media type not listed in this property MUST result in an error, with the CALDAV:supported-calendar-data precondition (Section 5.3.2.1) being violated. In the absence of this property the server MUST accept data with the media type "text/calendar" and iCalendar version 2.0, and clients can assume that. [[anchor15: What about other types in this case? --reschke]] Section 5.3.1., para. 3: OLD: Clients SHOULD use the DAV:displayname property for a human-readable name of the calendar. Clients can either specify the value of the DAV:displayname property in the request body of the MKCALENDAR request, or alternatively issue a PROPPATCH request to change the DAV:displayname property to the appropriate value immediately after issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: displayname property to be the same as any other calendar collection at the same URI "level". When displaying calendar collections to users, clients SHOULD check the DAV:displayname property and use that value as the name of the calendar. In the event that the DAV: displayname property is empty, the client MAY use the last part of the calendar collection URI as the name, however that path segment may be "opaque" and not represent any meaningful human-readable text. NEW: Clients SHOULD use the DAV:displayname property for a human-readable name of the calendar. Clients can either specify the value of the DAV:displayname property in the request body of the MKCALENDAR request, or alternatively issue a PROPPATCH request to change the DAV:displayname property to the appropriate value immediately after issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: displayname property to be the same as any other calendar collection at the same URI "level". When displaying calendar collections to users, clients SHOULD check the DAV:displayname property and use that value as the name of the calendar. In the event that the DAV: displayname property is empty, the client MAY use the last part of the calendar collection URI as the name, however that path segment may be "opaque" and not represent any meaningful human-readable text. [[anchor17: This seems to profile DAV:displayname as defined by RFC2518bis. Furthermore it's not clear what happens when the client violates the constraint. --reschke]] Section 5.3.4., para. 4: OLD: In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted calendar object resource, the behavior of the ETag response header is not specified here, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, clients may need to retrieve the modified calendar object resource (and ETag) as a basis for further changes, rather than use the calendar object resource it had sent with the PUT request. NEW: In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted calendar object resource, the behavior of the ETag response header is not specified here, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, clients may need to retrieve the modified calendar object resource (and ETag) as a basis for further changes, rather than use the calendar object resource it had sent with the PUT request. [[anchor22: See comments on ietf- discuss mailing list. --reschke]] Section 6.2.1., para. 4: OLD: Conformance: This property MAY be defined in a principal resource. If defined, it MAY be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [I-D.ietf-webdav-rfc2518bis]). Support for this property is RECOMMENDED. NEW: Conformance: This property MAY be defined in a principal resource. If defined, it MAY be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 14.2 of [I-D.ietf-webdav-rfc2518bis]). Support for this property is RECOMMENDED. [[anchor24: Doesn't compute. Is this a MAY (OPTIONAL) or a SHOULD (RECOMMENDED)? --reschke]] Section 7.5., para. 1: OLD: Some calendaring REPORTs defined in this document allow partial retrieval of calendar object resources. A CalDAV client MAY specify what information to return in the body of a calendaring REPORT request. NEW: Some calendaring REPORTs defined in this document allow partial retrieval of calendar object resources. A CalDAV client MAY specify what information to return in the body of a calendaring REPORT request. [[anchor29: Why does this simple statement require RFC2219 terminology? Please don't over-use it. In particular, please check that all "MAY" requirements really are needed for the purposes outlined in RFC2219. --reschke]] Section 7.7.6., para. 1: OLD: In this example, the client requests the server to return the VEVENT component that has the UID property set to "DC6C50A017428C5216A2F1CD@example.com". See Appendix B for the calendar data being targeted by this example. NEW: In this example, the client requests the server to return the VEVENT component that has the UID property set to "DC6C50A017428C5216A2F1CD@example.com". [[anchor37: Is whitespace significant here? In which case the example below would be invalid. -reschke]] See Appendix B for the calendar data being targeted by this example. Section 7.8., para. 4: OLD: The request body MUST be a CALDAV:calendar-multiget XML element (see Section 9.9). If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client. If the Request-URI refers to a non-collection resource, then there MUST be a single DAV:href element that is equivalent to the Request-URI. NEW: The request body MUST be a CALDAV:calendar-multiget XML element (see Section 9.9). If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client. [[anchor42: Bad idea. Just stick with RFC3253/RFC3744 terminology (invalid depth values are rejected by the server, not ignored). This leaves the possibilily to later define semantics for these values. --reschke]] If the Request-URI refers to a non-collection resource, then there MUST be a single DAV:href element that is equivalent to the Request-URI. Section 8.4., para. 3: OLD: For calendar sharing and scheduling use cases, one might wish to find the calendar belonging to another user. If the other user has a calendar in the same repository, that calendar can be found by using the principal namespace required by WebDAV ACL support. For other cases, the authors have no universal solution but implementers can consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards together with calendar attributes [RFC2739]. NEW: For calendar sharing and scheduling use cases, one might wish to find the calendar belonging to another user. If the other user has a calendar in the same repository, that calendar can be found by using the principal namespace required by WebDAV ACL support. For other cases, the authors have no universal solution but implementers can consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards together with calendar attributes [RFC2739]. [[anchor55: LDAP reference is outdated. --reschke]] Section 8.5.2., para. 1: OLD: CalDAV clients SHOULD support downloading of external attachments referenced by arbitrary URI schemes, by either processing them directly, or by passing the attachment URI to a suitable "helper application" for processing, if such an application exists. CalDAV clients MUST support downloading of external attachments referenced by the "http" URI scheme, and MAY support downloading of external attachments referenced by the "https" URI scheme. An external attachment could be: NEW: CalDAV clients SHOULD support downloading of external attachments referenced by arbitrary URI schemes, by either processing them directly, or by passing the attachment URI to a suitable "helper application" for processing, if such an application exists. CalDAV clients MUST support downloading of external attachments referenced by the "http" URI scheme, and MAY support downloading of external attachments referenced by the "https" URI scheme. An external attachment could be: [[anchor59: Very confusing: MAY, SHOULD and MUST requirements for basically the same thing. In particular, the MAY for "https" is bogus, because the spec just stated that the client SHOULD support arbitrary schemes. --reschke]] --------------030400070702060103000103 Content-Type: text/html; charset=ISO-8859-1; name="draft-dusseault-caldav-13-jr-from-.diff.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dusseault-caldav-13-jr-from-.diff.html" Diff: draft-dusseault-caldav-13.txt - draft-dusseault-caldav-13-jr.txt
 draft-dusseault-caldav-13.txt   draft-dusseault-caldav-13-jr.txt 
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
1.2. XML Namespaces and Processing . . . . . . . . . . . . . . 5 1.2. XML Namespaces and Processing . . . . . . . . . . . . . . 5
2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Overview . . . . . . . . . . . . . . . . . . . . 6
3. Calendaring Data Model . . . . . . . . . . . . . . . . . . . 7 3. Calendaring Data Model . . . . . . . . . . . . . . . . . . . 7
3.1. Calendar Server . . . . . . . . . . . . . . . . . . . . . 7 3.1. Calendar Server . . . . . . . . . . . . . . . . . . . . . 7
3.2. Recurrence and the Data Model . . . . . . . . . . . . . . 8 3.2. Recurrence and the Data Model . . . . . . . . . . . . . . 8
4. Calendar Resources . . . . . . . . . . . . . . . . . . . . . 8 4. Calendar Resources . . . . . . . . . . . . . . . . . . . . . 9
4.1. Calendar Object Resources . . . . . . . . . . . . . . . . 8 4.1. Calendar Object Resources . . . . . . . . . . . . . . . . 9
4.2. Calendar Collection . . . . . . . . . . . . . . . . . . . 10 4.2. Calendar Collection . . . . . . . . . . . . . . . . . . . 10
5. Calendar Access Feature . . . . . . . . . . . . . . . . . . . 11 5. Calendar Access Feature . . . . . . . . . . . . . . . . . . . 11
5.1. Calendar Access Support . . . . . . . . . . . . . . . . . 11 5.1. Calendar Access Support . . . . . . . . . . . . . . . . . 11
5.1.1. Example: Using OPTIONS for the Discovery of 5.1.1. Example: Using OPTIONS for the Discovery of
Calendar Access Support . . . . . . . . . . . . . . . 11 Calendar Access Support . . . . . . . . . . . . . . . 12
5.2. Calendar Collection Properties . . . . . . . . . . . . . 11 5.2. Calendar Collection Properties . . . . . . . . . . . . . 12
5.2.1. CALDAV:calendar-description Property . . . . . . . . 12 5.2.1. CALDAV:calendar-description Property . . . . . . . . 12
5.2.2. CALDAV:calendar-timezone Property . . . . . . . . . . 12 5.2.2. CALDAV:calendar-timezone Property . . . . . . . . . . 13
5.2.3. CALDAV:supported-calendar-component-set Property . . 14 5.2.3. CALDAV:supported-calendar-component-set Property . . 14
5.2.4. CALDAV:supported-calendar-data Property . . . . . . . 15 5.2.4. CALDAV:supported-calendar-data Property . . . . . . . 16
5.2.5. CALDAV:max-resource-size Property . . . . . . . . . . 16 5.2.5. CALDAV:max-resource-size Property . . . . . . . . . . 16
5.2.6. CALDAV:min-date-time Property . . . . . . . . . . . . 17 5.2.6. CALDAV:min-date-time Property . . . . . . . . . . . . 17
5.2.7. CALDAV:max-date-time Property . . . . . . . . . . . . 18 5.2.7. CALDAV:max-date-time Property . . . . . . . . . . . . 18
5.2.8. CALDAV:max-instances Property . . . . . . . . . . . . 19 5.2.8. CALDAV:max-instances Property . . . . . . . . . . . . 19
5.2.9. CALDAV:max-attendees-per-instance Property . . . . . 19 5.2.9. CALDAV:max-attendees-per-instance Property . . . . . 20
5.2.10. Additional Precondition for PROPPATCH . . . . . . . . 20 5.2.10. Additional Precondition for PROPPATCH . . . . . . . . 21
5.3. Creating Resources . . . . . . . . . . . . . . . . . . . 21 5.3. Creating Resources . . . . . . . . . . . . . . . . . . . 21
5.3.1. MKCALENDAR Method . . . . . . . . . . . . . . . . . . 21 5.3.1. MKCALENDAR Method . . . . . . . . . . . . . . . . . . 21
5.3.1.1. Status Codes . . . . . . . . . . . . . . . . . . 22 5.3.1.1. Status Codes . . . . . . . . . . . . . . . . . . 23
5.3.1.2. Example: Successful MKCALENDAR request . . . . . 23 5.3.1.2. Example: Successful MKCALENDAR request . . . . . 24
5.3.2. Creating Calendar Object Resources . . . . . . . . . 25 5.3.2. Creating Calendar Object Resources . . . . . . . . . 26
5.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 26 5.3.2.1. Additional Preconditions for PUT, COPY and MOVE . 27
5.3.3. Non-standard components, properties and parameters . 28 5.3.3. Non-standard components, properties and parameters . 29
5.3.4. Calendar Object Resource Entity Tag . . . . . . . . . 29 5.3.4. Calendar Object Resource Entity Tag . . . . . . . . . 30
6. Calendaring Access Control . . . . . . . . . . . . . . . . . 29 6. Calendaring Access Control . . . . . . . . . . . . . . . . . 30
6.1. Calendaring Privilege . . . . . . . . . . . . . . . . . . 29 6.1. Calendaring Privilege . . . . . . . . . . . . . . . . . . 30
6.1.1. CALDAV:read-free-busy Privilege . . . . . . . . . . . 29 6.1.1. CALDAV:read-free-busy Privilege . . . . . . . . . . . 30
6.2. Additional Principal Property . . . . . . . . . . . . . . 30 6.2. Additional Principal Property . . . . . . . . . . . . . . 31
6.2.1. CALDAV:calendar-home-set Property . . . . . . . . . . 30 6.2.1. CALDAV:calendar-home-set Property . . . . . . . . . . 31
7. Calendaring Reports . . . . . . . . . . . . . . . . . . . . . 31 7. Calendaring Reports . . . . . . . . . . . . . . . . . . . . . 32
7.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 31 7.1. REPORT Method . . . . . . . . . . . . . . . . . . . . . . 32
7.2. Ordinary collections . . . . . . . . . . . . . . . . . . 31 7.2. Ordinary collections . . . . . . . . . . . . . . . . . . 33
7.3. Date and floating time . . . . . . . . . . . . . . . . . 32 7.3. Date and floating time . . . . . . . . . . . . . . . . . 33
7.4. Time range filtering . . . . . . . . . . . . . . . . . . 32 7.4. Time range filtering . . . . . . . . . . . . . . . . . . 33
7.5. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 33 7.5. Partial Retrieval . . . . . . . . . . . . . . . . . . . . 34
7.6. Non-standard components, properties and parameters . . . 34 7.6. Non-standard components, properties and parameters . . . 35
7.7. CALDAV:calendar-query Report . . . . . . . . . . . . . . 34 7.7. CALDAV:calendar-query Report . . . . . . . . . . . . . . 35
7.7.1. Example: Partial retrieval of events by time range . 36 7.7.1. Example: Partial retrieval of events by time range . 37
7.7.2. Example: Partial retrieval of recurring events . . . 40 7.7.2. Example: Partial retrieval of recurring events . . . 41
7.7.3. Example: Expanded retrieval of recurring events . . . 43 7.7.3. Example: Expanded retrieval of recurring events . . . 44
7.7.4. Example: Partial retrieval of stored free busy 7.7.4. Example: Partial retrieval of stored free busy
components . . . . . . . . . . . . . . . . . . . . . 45 components . . . . . . . . . . . . . . . . . . . . . 46
7.7.5. Example: Retrieval of to-dos by alarm time range . . 47 7.7.5. Example: Retrieval of to-dos by alarm time range . . 48
7.7.6. Example: Retrieval of event by UID . . . . . . . . . 49 7.7.6. Example: Retrieval of event by UID . . . . . . . . . 50
7.7.7. Example: Retrieval of events by PARTSTAT . . . . . . 51 7.7.7. Example: Retrieval of events by PARTSTAT . . . . . . 52
7.7.8. Example: Retrieval of events only . . . . . . . . . . 53 7.7.8. Example: Retrieval of events only . . . . . . . . . . 54
7.7.9. Example: Retrieval of all pending to-dos . . . . . . 57 7.7.9. Example: Retrieval of all pending to-dos . . . . . . 58
7.7.10. Example: Attempt to query unsupported property . . . 60 7.7.10. Example: Attempt to query unsupported property . . . 61
7.8. CALDAV:calendar-multiget Report . . . . . . . . . . . . . 61 7.8. CALDAV:calendar-multiget Report . . . . . . . . . . . . . 62
7.8.1. Example: Successful CALDAV:calendar-multiget Report . 62 7.8.1. Example: Successful CALDAV:calendar-multiget Report . 63
7.9. CALDAV:free-busy-query Report . . . . . . . . . . . . . . 64 7.9. CALDAV:free-busy-query Report . . . . . . . . . . . . . . 65
7.9.1. Example: Successful CALDAV:free-busy-query Report . . 66 7.9.1. Example: Successful CALDAV:free-busy-query Report . . 67
8. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 67 8. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.1. Client-to-client Interoperability . . . . . . . . . . . . 67 8.1. Client-to-client Interoperability . . . . . . . . . . . . 68
8.2. Synchronization Operations . . . . . . . . . . . . . . . 67 8.2. Synchronization Operations . . . . . . . . . . . . . . . 68
8.2.1. Use of Reports . . . . . . . . . . . . . . . . . . . 68 8.2.1. Use of Reports . . . . . . . . . . . . . . . . . . . 69
8.2.1.1. Restrict the Time Range . . . . . . . . . . . . . 68 8.2.1.1. Restrict the Time Range . . . . . . . . . . . . . 69
8.2.1.2. Synchronize by Time Range . . . . . . . . . . . . 68 8.2.1.2. Synchronize by Time Range . . . . . . . . . . . . 69
8.2.1.3. Synchronization Process . . . . . . . . . . . . . 68 8.2.1.3. Synchronization Process . . . . . . . . . . . . . 69
8.2.2. Restrict the Properties Returned . . . . . . . . . . 70 8.2.2. Restrict the Properties Returned . . . . . . . . . . 71
8.3. Use of Locking . . . . . . . . . . . . . . . . . . . . . 70 8.3. Use of Locking . . . . . . . . . . . . . . . . . . . . . 71
8.4. Finding calendars . . . . . . . . . . . . . . . . . . . . 71 8.4. Finding calendars . . . . . . . . . . . . . . . . . . . . 72
8.5. Storing and Using Attachments . . . . . . . . . . . . . . 72 8.5. Storing and Using Attachments . . . . . . . . . . . . . . 73
8.5.1. Inline attachments . . . . . . . . . . . . . . . . . 72 8.5.1. Inline attachments . . . . . . . . . . . . . . . . . 73
8.5.2. External attachments . . . . . . . . . . . . . . . . 73 8.5.2. External attachments . . . . . . . . . . . . . . . . 74
8.6. Storing and Using Alarms . . . . . . . . . . . . . . . . 74 8.6. Storing and Using Alarms . . . . . . . . . . . . . . . . 75
9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 75 9. XML Element Definitions . . . . . . . . . . . . . . . . . . . 76
9.1. CALDAV:calendar XML Element . . . . . . . . . . . . . . . 75 9.1. CALDAV:calendar XML Element . . . . . . . . . . . . . . . 76
9.2. CALDAV:mkcalendar XML Element . . . . . . . . . . . . . . 76 9.2. CALDAV:mkcalendar XML Element . . . . . . . . . . . . . . 77
9.3. CALDAV:mkcalendar-response XML Element . . . . . . . . . 76 9.3. CALDAV:mkcalendar-response XML Element . . . . . . . . . 77
9.4. CALDAV:calendar-query XML Element . . . . . . . . . . . . 76 9.4. CALDAV:calendar-query XML Element . . . . . . . . . . . . 77
9.5. CALDAV:calendar-data XML Element . . . . . . . . . . . . 77 9.5. CALDAV:calendar-data XML Element . . . . . . . . . . . . 78
9.5.1. CALDAV:comp XML Element . . . . . . . . . . . . . . . 78 9.5.1. CALDAV:comp XML Element . . . . . . . . . . . . . . . 79
9.5.2. CALDAV:allcomp XML Element . . . . . . . . . . . . . 79 9.5.2. CALDAV:allcomp XML Element . . . . . . . . . . . . . 80
9.5.3. CALDAV:allprop XML Element . . . . . . . . . . . . . 79 9.5.3. CALDAV:allprop XML Element . . . . . . . . . . . . . 80
9.5.4. CALDAV:prop XML Element . . . . . . . . . . . . . . . 79 9.5.4. CALDAV:prop XML Element . . . . . . . . . . . . . . . 80
9.5.5. CALDAV:expand XML Element . . . . . . . . . . . . . . 80 9.5.5. CALDAV:expand XML Element . . . . . . . . . . . . . . 81
9.5.6. CALDAV:limit-recurrence-set XML Element . . . . . . . 81 9.5.6. CALDAV:limit-recurrence-set XML Element . . . . . . . 82
9.5.7. CALDAV:limit-freebusy-set XML Element . . . . . . . . 82 9.5.7. CALDAV:limit-freebusy-set XML Element . . . . . . . . 83
9.6. CALDAV:filter XML Element . . . . . . . . . . . . . . . . 82 9.6. CALDAV:filter XML Element . . . . . . . . . . . . . . . . 83
9.6.1. CALDAV:comp-filter XML Element . . . . . . . . . . . 83 9.6.1. CALDAV:comp-filter XML Element . . . . . . . . . . . 84
9.6.2. CALDAV:prop-filter XML Element . . . . . . . . . . . 84 9.6.2. CALDAV:prop-filter XML Element . . . . . . . . . . . 85
9.6.3. CALDAV:param-filter XML Element . . . . . . . . . . . 84 9.6.3. CALDAV:param-filter XML Element . . . . . . . . . . . 85
9.6.4. CALDAV:is-not-defined XML Element . . . . . . . . . . 85 9.6.4. CALDAV:is-not-defined XML Element . . . . . . . . . . 86
9.6.5. CALDAV:text-match XML Element . . . . . . . . . . . . 85 9.6.5. CALDAV:text-match XML Element . . . . . . . . . . . . 86
9.7. CALDAV:timezone XML Element . . . . . . . . . . . . . . . 86 9.7. CALDAV:timezone XML Element . . . . . . . . . . . . . . . 87
9.8. CALDAV:time-range XML Element . . . . . . . . . . . . . . 87 9.8. CALDAV:time-range XML Element . . . . . . . . . . . . . . 88
9.9. CALDAV:calendar-multiget XML Element . . . . . . . . . . 91 9.9. CALDAV:calendar-multiget XML Element . . . . . . . . . . 92
9.10. CALDAV:free-busy-query XML Element . . . . . . . . . . . 92 9.10. CALDAV:free-busy-query XML Element . . . . . . . . . . . 93
10. Internationalization Considerations . . . . . . . . . . . . . 92 10. Internationalization Considerations . . . . . . . . . . . . . 93
11. Security Considerations . . . . . . . . . . . . . . . . . . . 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 93
12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 93 12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 94
12.1. Namespace Registration . . . . . . . . . . . . . . . . . 93 12.1. Namespace Registration . . . . . . . . . . . . . . . . . 94
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
14.1. Normative References . . . . . . . . . . . . . . . . . . 94 14.1. Normative References . . . . . . . . . . . . . . . . . . 95
14.2. Informative References . . . . . . . . . . . . . . . . . 95 14.2. Informative References . . . . . . . . . . . . . . . . . 96
Appendix A. CalDAV Method Privilege Table (Normative) . . . . . 95 Appendix A. CalDAV Method Privilege Table (Normative) . . . . . 96
Appendix B. Calendar collections used in the examples . . . . . 96 Appendix B. Calendar collections used in the examples . . . . . 97
Appendix C. Changes (to be removed prior to publication as an Appendix C. Changes (to be removed prior to publication as an
RFC) . . . . . . . . . . . . . . . . . . . . . . . . 102 RFC) . . . . . . . . . . . . . . . . . . . . . . . . 103
C.1. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 102 C.1. Changes in -13 . . . . . . . . . . . . . . . . . . . . . 103
C.2. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 103 C.2. Changes in -12 . . . . . . . . . . . . . . . . . . . . . 104
C.3. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 103 C.3. Changes in -11 . . . . . . . . . . . . . . . . . . . . . 104
C.4. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 104 C.4. Changes in -10 . . . . . . . . . . . . . . . . . . . . . 105
C.5. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 105 C.5. Changes in -09 . . . . . . . . . . . . . . . . . . . . . 106
C.6. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 106 C.6. Changes in -08 . . . . . . . . . . . . . . . . . . . . . 107
C.7. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 107 C.7. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 108
C.8. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 108 C.8. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 109
C.9. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 108 C.9. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 109
C.10. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 109 C.10. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 110
C.11. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 110 C.11. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 111
C.12. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 110 C.12. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 111
C.13. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 110 C.13. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 111
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111
Intellectual Property and Copyright Statements . . . . . . . . . 112 Intellectual Property and Copyright Statements . . . . . . . . . 113
1. Introduction 1. Introduction
The concept of using HTTP [RFC2616] and WebDAV The concept of using HTTP [RFC2616] and WebDAV
[I-D.ietf-webdav-rfc2518bis] as a basis for a calendar access [I-D.ietf-webdav-rfc2518bis] as a basis for a calendar access
protocol is by no means a new concept: it was discussed in the IETF protocol is by no means a new concept: it was discussed in the IETF
CALSCH working group as early as 1997 or 1998. Several companies CALSCH working group as early as 1997 or 1998. Several companies
have implemented calendar access protocols using HTTP to upload and have implemented calendar access protocols using HTTP to upload and
download iCalendar [RFC2445] objects, and using WebDAV to get download iCalendar [RFC2445] objects, and using WebDAV to get
listings of resources. However, those implementations do not listings of resources. However, those implementations do not
interoperate because there are many small and big decisions to be interoperate because there are many small and big decisions to be
made in how to model calendaring data as WebDAV resources, as well as made in how to model calendaring data as WebDAV resources, as well as
how to implement required features that aren't already part of how to implement required features that aren't already part of
WebDAV. This document proposes a way to model calendar data in WebDAV. This document proposes a way to model calendar data in
WebDAV, with additional features to make an interoperable calendar WebDAV, with additional features to make an interoperable calendar
access protocol. access protocol.
Discussion of this specification is taking place on the mailing list Discussion of this specification is taking place on the mailing list
<http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>. <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
[[anchor2: Clarify that this paragraph should be removed upon
publication --reschke]]
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The term "protected" is used in the Conformance field of property The term "protected" is used in the Conformance field of property
definitions as defined in Section 1.4.2 of [RFC3253]. definitions as defined in Section 1.4.2 of [RFC3253].
skipping to change at page 6, line 4 skipping to change at page 6, line 6
The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
elements defined in this specification, its revisions, and related elements defined in this specification, its revisions, and related
CalDAV specifications. XML elements defined by individual CalDAV specifications. XML elements defined by individual
implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav" implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav"
namespace, and instead should use a namespace that they control. namespace, and instead should use a namespace that they control.
The XML declarations used in this document do not include namespace The XML declarations used in this document do not include namespace
information. Thus, implementers MUST NOT use these declarations as information. Thus, implementers MUST NOT use these declarations as
the only way to create valid CalDAV properties or to validate CalDAV the only way to create valid CalDAV properties or to validate CalDAV
XML element type. Some of the declarations refer to XML elements XML element type. [[anchor5: "...MUST NOT use these declarations as
defined by WebDAV [I-D.ietf-webdav-rfc2518bis] which use the "DAV:" the only way..." is extremly hard to understand; the presence of
namespace. Wherever such XML elements appear, they are explicitly RFC2119 keywords make things worse in that the reader is confused to
prefixed with "DAV:" to avoid confusion. believe that a normative statement is being made. As far as I can
tell, all this wants to say is that the missing namespace needs to be
taken into account. Please clarify. --reschke]] Some of the
declarations refer to XML elements defined by WebDAV
[I-D.ietf-webdav-rfc2518bis] which use the "DAV:" namespace.
Wherever such XML elements appear, they are explicitly prefixed with
"DAV:" to avoid confusion.
Also note that some CalDAV XML element names are identical to WebDAV Also note that some CalDAV XML element names are identical to WebDAV
XML element names, though their namespace differs. Care must be XML element names, though their namespace differs. Care must be
taken not to confuse the two sets of names. taken not to confuse the two sets of names.
Processing of XML by CalDAV clients and servers MUST follow the rules Processing of XML by CalDAV clients and servers MUST follow the rules
described in [I-D.ietf-webdav-rfc2518bis], in particular Sections 8.2 described in [I-D.ietf-webdav-rfc2518bis], in particular Sections 8.2
and 17, and Appendix A of that specification. and 17, and Appendix A of that specification.
2. Requirements Overview 2. Requirements Overview
skipping to change at page 6, line 32 skipping to change at page 6, line 40
o MUST support iCalendar [RFC2445] as a media type for calendar o MUST support iCalendar [RFC2445] as a media type for calendar
object resource format; object resource format;
o MUST support WebDAV Class 1 and Class 3 o MUST support WebDAV Class 1 and Class 3
[I-D.ietf-webdav-rfc2518bis]; [I-D.ietf-webdav-rfc2518bis];
o MUST support WebDAV ACL [RFC3744] with the additional privilege o MUST support WebDAV ACL [RFC3744] with the additional privilege
defined in Section 6.1 of this document; defined in Section 6.1 of this document;
o MUST support transport over TLS [RFC2246] as defined in [RFC2818] o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
(note that [RFC2246] has been obsoleted by [RFC4346]); (note that [RFC2246] has been obsoleted by [RFC4346]); [[anchor6:
I assume that the down reference to RFC2818 (informational RFC) is
intended; but what about the stuff with RFC2246? Why doesn't spec
refer to RFC4346 instead? --reschke]]
o MUST support ETags [RFC2616] with additional requirements o MUST support ETags [RFC2616] with additional requirements
specified in Section 5.3.4 of this document; specified in Section 5.3.4 of this document;
o MUST support all calendaring REPORTs defined in Section 7 of this o MUST support all calendaring REPORTs defined in Section 7 of this
document; and document; and
o MUST advertise support on all calendar collections and calendar o MUST advertise support on all calendar collections and calendar
object resources for the calendaring REPORTs in the DAV:supported- object resources for the calendaring REPORTs in the DAV:supported-
report-set property as defined in Versioning Extensions to WebDAV report-set property as defined in Versioning Extensions to WebDAV
[RFC3253]. [RFC3253].
In addition, a server: In addition, a server:
o SHOULD support the MKCALENDAR method defined in Section 5.3.1 of o SHOULD support the MKCALENDAR method defined in Section 5.3.1 of
this document. this document.
skipping to change at page 8, line 4 skipping to change at page 8, line 15
/home/lisa/calendars/ as well as in /home/bernard/calendars/, and /home/lisa/calendars/ as well as in /home/bernard/calendars/, and
non-calendar data in /home/lisa/contacts/). Or, it might mean that non-calendar data in /home/lisa/contacts/). Or, it might mean that
calendar data can be found only in certain sections of the repository calendar data can be found only in certain sections of the repository
(e.g., /calendar/). Calendaring features are only required in the (e.g., /calendar/). Calendaring features are only required in the
repository sections that are or contain calendar object resources. repository sections that are or contain calendar object resources.
So a repository confining calendar data to the /calendar/ collection So a repository confining calendar data to the /calendar/ collection
would only need to support the CalDAV required features within that would only need to support the CalDAV required features within that
collection. collection.
The CalDAV server or repository is the canonical location for The CalDAV server or repository is the canonical location for
calendar data and state information. Both CalDAV servers and clients calendar data and state information. [[anchor8: "server or
MUST ensure that the data is consistent and compliant. Clients may repository": I think it would be good if the spec would choose one
submit requests to change data or download data. Clients may store term and stick with it --reschke]] Both CalDAV servers and clients
calendar objects offline and attempt to synchronize at a later time. MUST ensure that the data is consistent and compliant. [[anchor9:
However, clients MUST be prepared for calendar data on the server to What does it exactly mean for the data to be "consistent" and
change between the time of last synchronization and when attempting "compliant"? If there's no exact definition for that then the "MUST"
an update, as calendar collections may be shared and accessible via should go --reschke]] Clients may submit requests to change data or
multiple clients. Entity tags and other features make this possible. download data. Clients may store calendar objects offline and
attempt to synchronize at a later time. However, clients MUST be
prepared for calendar data on the server to change between the time
of last synchronization and when attempting an update, as calendar
collections may be shared and accessible via multiple clients.
Entity tags and other features make this possible.
3.2. Recurrence and the Data Model 3.2. Recurrence and the Data Model
Recurrence is an important part of the data model because it governs Recurrence is an important part of the data model because it governs
how many resources are expected to exist. This specification models how many resources are expected to exist. This specification models
a recurring calendar component and its recurrence exceptions as a a recurring calendar component and its recurrence exceptions as a
single resource. In this model, recurrence rules, recurrence dates, single resource. In this model, recurrence rules, recurrence dates,
exception rules, and exception dates are all part of the data in a exception rules, and exception dates are all part of the data in a
single calendar object resource. This model avoids problems of single calendar object resource. This model avoids problems of
limiting how many recurrence instances to store in the repository, limiting how many recurrence instances to store in the repository,
skipping to change at page 15, line 49 skipping to change at page 16, line 28
Description: The CALDAV:supported-calendar-data property is used to Description: The CALDAV:supported-calendar-data property is used to
specify the media type supported for the calendar object resources specify the media type supported for the calendar object resources
contained in a given calendar collection (e.g., iCalendar version contained in a given calendar collection (e.g., iCalendar version
2.0). Any attempt by the client to store calendar object 2.0). Any attempt by the client to store calendar object
resources with a media type not listed in this property MUST resources with a media type not listed in this property MUST
result in an error, with the CALDAV:supported-calendar-data result in an error, with the CALDAV:supported-calendar-data
precondition (Section 5.3.2.1) being violated. In the absence of precondition (Section 5.3.2.1) being violated. In the absence of
this property the server MUST accept data with the media type this property the server MUST accept data with the media type
"text/calendar" and iCalendar version 2.0, and clients can assume "text/calendar" and iCalendar version 2.0, and clients can assume
that. that. [[anchor15: What about other types in this case? --reschke]]
Definition: Definition:
<!ELEMENT supported-calendar-data (calendar-data*)> <!ELEMENT supported-calendar-data (calendar-data*)>
Example: Example:
<C:supported-calendar-data <C:supported-calendar-data
xmlns:C="urn:ietf:params:xml:ns:caldav"> xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:calendar-data content-type="text/calendar" version="2.0"/> <C:calendar-data content-type="text/calendar" version="2.0"/>
skipping to change at page 21, line 44 skipping to change at page 22, line 5
request, or alternatively issue a PROPPATCH request to change the request, or alternatively issue a PROPPATCH request to change the
DAV:displayname property to the appropriate value immediately after DAV:displayname property to the appropriate value immediately after
issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV:
displayname property to be the same as any other calendar collection displayname property to be the same as any other calendar collection
at the same URI "level". When displaying calendar collections to at the same URI "level". When displaying calendar collections to
users, clients SHOULD check the DAV:displayname property and use that users, clients SHOULD check the DAV:displayname property and use that
value as the name of the calendar. In the event that the DAV: value as the name of the calendar. In the event that the DAV:
displayname property is empty, the client MAY use the last part of displayname property is empty, the client MAY use the last part of
the calendar collection URI as the name, however that path segment the calendar collection URI as the name, however that path segment
may be "opaque" and not represent any meaningful human-readable text. may be "opaque" and not represent any meaningful human-readable text.
[[anchor17: This seems to profile DAV:displayname as defined by
RFC2518bis. Furthermore it's not clear what happens when the client
violates the constraint. --reschke]]
If a MKCALENDAR request fails, the server state preceding the request If a MKCALENDAR request fails, the server state preceding the request
MUST be restored. MUST be restored.
Marshalling: Marshalling:
If a request body is included, it MUST be a CALDAV:mkcalendar XML If a request body is included, it MUST be a CALDAV:mkcalendar XML
element. Instruction processing MUST occur in the order element. Instruction processing MUST occur in the order
instructions are received (i.e., from top to bottom). instructions are received (i.e., from top to bottom).
Instructions MUST either all be executed or none executed. Thus Instructions MUST either all be executed or none executed. Thus
if any error occurs during processing, all executed instructions if any error occurs during processing, all executed instructions
MUST be undone and a proper error result returned. Instruction MUST be undone and a proper error result returned. Instruction
processing details can be found in the definition of the DAV:set processing details can be found in the definition of the DAV:set
instruction in Section 14.26 of [I-D.ietf-webdav-rfc2518bis]. instruction in Section 14.26 of [I-D.ietf-webdav-rfc2518bis].
<!ELEMENT mkcalendar (DAV:set)> <!ELEMENT mkcalendar (DAV:set)>
If a response body for a successful request is included, it MUST If a response body for a successful request is included, it MUST
be a CALDAV:mkcalendar-response XML element. be a CALDAV:mkcalendar-response XML element.
skipping to change at page 29, line 32 skipping to change at page 30, line 32
know that if they are equal, then the calendar object resource on the know that if they are equal, then the calendar object resource on the
server has not been changed. server has not been changed.
In the case where the data stored by a server as a result of a PUT In the case where the data stored by a server as a result of a PUT
request is not equivalent by octet equality to the submitted calendar request is not equivalent by octet equality to the submitted calendar
object resource, the behavior of the ETag response header is not object resource, the behavior of the ETag response header is not
specified here, with the exception that a strong entity tag MUST NOT specified here, with the exception that a strong entity tag MUST NOT
be returned in the response. As a result, clients may need to be returned in the response. As a result, clients may need to
retrieve the modified calendar object resource (and ETag) as a basis retrieve the modified calendar object resource (and ETag) as a basis
for further changes, rather than use the calendar object resource it for further changes, rather than use the calendar object resource it
had sent with the PUT request. had sent with the PUT request. [[anchor22: See comments on ietf-
discuss mailing list. --reschke]]
6. Calendaring Access Control 6. Calendaring Access Control
6.1. Calendaring Privilege 6.1. Calendaring Privilege
CalDAV servers MUST support and adhere to the requirements of WebDAV CalDAV servers MUST support and adhere to the requirements of WebDAV
ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set ACL [RFC3744]. WebDAV ACL provides a framework for an extensible set
of privileges that can be applied to WebDAV collections and ordinary of privileges that can be applied to WebDAV collections and ordinary
resources. CalDAV servers MUST also support the calendaring resources. CalDAV servers MUST also support the calendaring
privilege defined in this section. privilege defined in this section.
skipping to change at page 30, line 42 skipping to change at page 31, line 42
Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
Purpose: Identifies the URL of any WebDAV collections that contain Purpose: Identifies the URL of any WebDAV collections that contain
calendar collections owned by the associated principal resource. calendar collections owned by the associated principal resource.
Conformance: This property MAY be defined in a principal resource. Conformance: This property MAY be defined in a principal resource.
If defined, it MAY be protected and SHOULD NOT be returned by a If defined, it MAY be protected and SHOULD NOT be returned by a
PROPFIND DAV:allprop request (as defined in Section 14.2 of PROPFIND DAV:allprop request (as defined in Section 14.2 of
[I-D.ietf-webdav-rfc2518bis]). Support for this property is [I-D.ietf-webdav-rfc2518bis]). Support for this property is
RECOMMENDED. RECOMMENDED. [[anchor24: Doesn't compute. Is this a MAY
(OPTIONAL) or a SHOULD (RECOMMENDED)? --reschke]]
Description: The CALDAV:calendar-home-set property is meant to allow Description: The CALDAV:calendar-home-set property is meant to allow
users to easily find the calendar collections owned by the users to easily find the calendar collections owned by the
principal. Typically, users will group all the calendar principal. Typically, users will group all the calendar
collections that they own under a common collection. This collections that they own under a common collection. This
property specifies the URL of collections that either are calendar property specifies the URL of collections that either are calendar
collections or ordinary collections that have child or descendant collections or ordinary collections that have child or descendant
calendar collections owned by the principal. calendar collections owned by the principal.
Definition: Definition:
skipping to change at page 33, line 22 skipping to change at page 34, line 27
components. The server MUST expand recurring components to determine components. The server MUST expand recurring components to determine
whether any recurrence instances overlap the specified time range. whether any recurrence instances overlap the specified time range.
If one or more recurrence instances overlap the time range, then the If one or more recurrence instances overlap the time range, then the
calendar object resource matches the filter element. calendar object resource matches the filter element.
7.5. Partial Retrieval 7.5. Partial Retrieval
Some calendaring REPORTs defined in this document allow partial Some calendaring REPORTs defined in this document allow partial
retrieval of calendar object resources. A CalDAV client MAY specify retrieval of calendar object resources. A CalDAV client MAY specify
what information to return in the body of a calendaring REPORT what information to return in the body of a calendaring REPORT
request. request. [[anchor29: Why does this simple statement require RFC2219
terminology? Please don't over-use it. In particular, please check
that all "MAY" requirements really are needed for the purposes
outlined in RFC2219. --reschke]]
A CalDAV client MAY request particular WebDAV property values, all A CalDAV client MAY request particular WebDAV property values, all
WebDAV property values, or a list of the names of the resource's WebDAV property values, or a list of the names of the resource's
WebDAV properties. A CalDAV client MAY also request calendar data to WebDAV properties. A CalDAV client MAY also request calendar data to
be returned and whether all calendar components and properties should be returned and whether all calendar components and properties should
be returned or only particular ones. See CALDAV:calendar-data in be returned or only particular ones. See CALDAV:calendar-data in
Section 9.5. Section 9.5.
By default, the returned calendar data will include the component By default, the returned calendar data will include the component
that defines the recurrence set, referred to as the "master that defines the recurrence set, referred to as the "master
skipping to change at page 49, line 47 skipping to change at page 50, line 47
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
7.7.6. Example: Retrieval of event by UID 7.7.6. Example: Retrieval of event by UID
In this example, the client requests the server to return the VEVENT In this example, the client requests the server to return the VEVENT
component that has the UID property set to component that has the UID property set to
"DC6C50A017428C5216A2F1CD@example.com". "DC6C50A017428C5216A2F1CD@example.com". [[anchor37: Is whitespace
significant here? In which case the example below would be invalid.
-reschke]]
See Appendix B for the calendar data being targeted by this example. See Appendix B for the calendar data being targeted by this example.
>> Request << >> Request <<
REPORT /bernard/work/ HTTP/1.1 REPORT /bernard/work/ HTTP/1.1
Host: cal.example.com Host: cal.example.com
Depth: 1 Depth: 1
Content-Type: application/xml; charset="utf-8" Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxxx
skipping to change at page 61, line 39 skipping to change at page 62, line 39
Support for the calendar-multiget REPORT is REQUIRED. Support for the calendar-multiget REPORT is REQUIRED.
Marshalling: Marshalling:
The request body MUST be a CALDAV:calendar-multiget XML element The request body MUST be a CALDAV:calendar-multiget XML element
(see Section 9.9). If the Request-URI is a collection resource, (see Section 9.9). If the Request-URI is a collection resource,
then the DAV:href elements MUST refer to calendar object resources then the DAV:href elements MUST refer to calendar object resources
within that collection, and they MAY refer to calendar object within that collection, and they MAY refer to calendar object
resources at any depth within the collection. As a result the resources at any depth within the collection. As a result the
"Depth" header MUST be ignored by the server and SHOULD NOT be "Depth" header MUST be ignored by the server and SHOULD NOT be
sent by the client. If the Request-URI refers to a non-collection sent by the client. [[anchor42: Bad idea. Just stick with
resource, then there MUST be a single DAV:href element that is RFC3253/RFC3744 terminology (invalid depth values are rejected by
equivalent to the Request-URI. the server, not ignored). This leaves the possibilily to later
define semantics for these values. --reschke]] If the Request-URI
refers to a non-collection resource, then there MUST be a single
DAV:href element that is equivalent to the Request-URI.
The response body for a successful request MUST be a DAV: The response body for a successful request MUST be a DAV:
multistatus XML element. multistatus XML element.
The response body for a successful CALDAV:calendar-multiget REPORT The response body for a successful CALDAV:calendar-multiget REPORT
request MUST contain a DAV:response element for each calendar request MUST contain a DAV:response element for each calendar
object resource referenced by the provided set of DAV:href object resource referenced by the provided set of DAV:href
elements. Calendar data is being returned in the CALDAV:calendar- elements. Calendar data is being returned in the CALDAV:calendar-
data element inside the DAV:prop element. data element inside the DAV:prop element.
skipping to change at page 71, line 35 skipping to change at page 72, line 35
CalDAV usage. This specification does not offer a way through this CalDAV usage. This specification does not offer a way through this
other than making the information available in the OPTIONS response other than making the information available in the OPTIONS response
should this be requested. should this be requested.
For calendar sharing and scheduling use cases, one might wish to find For calendar sharing and scheduling use cases, one might wish to find
the calendar belonging to another user. If the other user has a the calendar belonging to another user. If the other user has a
calendar in the same repository, that calendar can be found by using calendar in the same repository, that calendar can be found by using
the principal namespace required by WebDAV ACL support. For other the principal namespace required by WebDAV ACL support. For other
cases, the authors have no universal solution but implementers can cases, the authors have no universal solution but implementers can
consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards
together with calendar attributes [RFC2739]. together with calendar attributes [RFC2739]. [[anchor55: LDAP
reference is outdated. --reschke]]
Because CalDAV requires servers to support WebDAV ACL [RFC3744] Because CalDAV requires servers to support WebDAV ACL [RFC3744]
including principal namespaces, and with the addition of the CALDAV: including principal namespaces, and with the addition of the CALDAV:
calendar-home-set property, there are a couple options for CalDAV calendar-home-set property, there are a couple options for CalDAV
clients to find one's own calendar or another user's calendar. clients to find one's own calendar or another user's calendar.
In this case, a DAV:principal-match REPORT is used to find a named In this case, a DAV:principal-match REPORT is used to find a named
property (the CALDAV:calendar-home-set) on the Principal-URL of the property (the CALDAV:calendar-home-set) on the Principal-URL of the
current user. Using this, a WebDAV client can learn "who am I" and current user. Using this, a WebDAV client can learn "who am I" and
"where are my calendars". The REPORT request body looks like this: "where are my calendars". The REPORT request body looks like this:
skipping to change at page 73, line 30 skipping to change at page 74, line 30
8.5.2. External attachments 8.5.2. External attachments
CalDAV clients SHOULD support downloading of external attachments CalDAV clients SHOULD support downloading of external attachments
referenced by arbitrary URI schemes, by either processing them referenced by arbitrary URI schemes, by either processing them
directly, or by passing the attachment URI to a suitable "helper directly, or by passing the attachment URI to a suitable "helper
application" for processing, if such an application exists. CalDAV application" for processing, if such an application exists. CalDAV
clients MUST support downloading of external attachments referenced clients MUST support downloading of external attachments referenced
by the "http" URI scheme, and MAY support downloading of external by the "http" URI scheme, and MAY support downloading of external
attachments referenced by the "https" URI scheme. An external attachments referenced by the "https" URI scheme. An external
attachment could be: attachment could be: [[anchor59: Very confusing: MAY, SHOULD and MUST
requirements for basically the same thing. In particular, the MAY
for "https" is bogus, because the spec just stated that the client
SHOULD support arbitrary schemes. --reschke]]
o In a collection in the calendar collection containing the calendar o In a collection in the calendar collection containing the calendar
object resource; object resource;
o Somewhere else in the same repository that hosts the calendar o Somewhere else in the same repository that hosts the calendar
collection; or collection; or
o On an HTTP or FTP server elsewhere. o On an HTTP or FTP server elsewhere.
CalDAV servers MAY provide support for child collections in calendar CalDAV servers MAY provide support for child collections in calendar
skipping to change at page 77, line 47 skipping to change at page 78, line 47
calendar-data XML element MAY be invalid per their media type calendar-data XML element MAY be invalid per their media type
specification if the CALDAV:calendar-data XML element part of the specification if the CALDAV:calendar-data XML element part of the
calendaring REPORT request did not specify required properties calendaring REPORT request did not specify required properties
(e.g., UID, DTSTAMP, etc.) or specified a CALDAV:prop XML element (e.g., UID, DTSTAMP, etc.) or specified a CALDAV:prop XML element
with the "novalue" attribute set to "yes". with the "novalue" attribute set to "yes".
Note: The CALDAV:calendar-data XML element is specified in requests Note: The CALDAV:calendar-data XML element is specified in requests
and responses inside the DAV:prop XML element as if it were a and responses inside the DAV:prop XML element as if it were a
WebDAV property. However, the CALDAV:calendar-data XML element is WebDAV property. However, the CALDAV:calendar-data XML element is
not a WebDAV property and as such it is not returned in PROPFIND not a WebDAV property and as such it is not returned in PROPFIND
responses nor used in PROPPATCH requests. responses nor used in PROPPATCH requests. [[anchor62: For this
reason, I think a syntax where it can't be confused with a
property whould be better. --reschke]]
Note: The iCalendar data embedded within the CALDAV:calendar-data Note: The iCalendar data embedded within the CALDAV:calendar-data
XML element MUST follow the standard XML character data encoding XML element MUST follow the standard XML character data encoding
rules, including use of &lt;, &gt;, &amp; etc entity encoding or rules, including use of &lt;, &gt;, &amp; etc entity encoding or
the use of a <[!CDATA[ ... ]]> construct. In the later case the the use of a <[!CDATA[ ... ]]> construct. In the later case the
iCalendar data cannot contain the character sequence "]]>" which iCalendar data cannot contain the character sequence "]]>" which
is the end delimiter for the CDATA section. is the end delimiter for the CDATA section.
Definition: Definition:
<!ELEMENT calendar-data ((comp?, (expand | <!ELEMENT calendar-data ((comp?, (expand |
 End of changes. 

This html diff was produced by rfcdiff 1.12, available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--------------030400070702060103000103-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A7DFD7F6E0 for ; Tue, 25 Jul 2006 14:08:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 97DA414227E for ; Tue, 25 Jul 2006 14:08:20 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01704-09 for ; Tue, 25 Jul 2006 14:08:19 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by laweleka.osafoundation.org (Postfix) with ESMTP id C9172142277 for ; Tue, 25 Jul 2006 14:08:18 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id l36so512595nfa for ; Tue, 25 Jul 2006 14:08:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AwF7NN7tKWi8y2PkiPFrUCa0e7L62T+XZN1xmPtaBmHs0rn4TAEJvSN1yYpM63Ma0lYSPjj68R8lek0bpEg03MUHUw/Z6u4XWj0xnAPttH8KcM6gkI88+1o1KwwqsV6+5R2k4O94dvtK1Gn87pC2y6w2Mer1Yt6Ue0eDwWmFU1Q= Received: by 10.49.19.18 with SMTP id w18mr1204443nfi; Tue, 25 Jul 2006 14:08:17 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Tue, 25 Jul 2006 14:08:17 -0700 (PDT) Message-ID: <68fba5c50607251408j16fb57gb39b9f37288f6607@mail.gmail.com> Date: Tue, 25 Jul 2006 17:08:17 -0400 From: "Robert Sayre" To: "Julian Reschke" Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 In-Reply-To: <44C67F07.1050802@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> <44C67F07.1050802@gmx.de> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: X-Mailman-Approved-At: Wed, 26 Jul 2006 09:57:48 -0700 Cc: Ted Hardie , ietf@ietf.org, CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 21:08:20 -0000 On 7/25/06, Julian Reschke wrote: > > Again, this profiles HTTP in a way that may turn out to be incompatible > with the way the issue will be resolved in general; also this conflicts > with ETag requirements in XCAP, which is also under IESG evaluation. By > all means, please let this issue be clarified in a *single* place and in > a way consistent for all HTTP resources. Neither draft obsoletes RFC2616, right? It seems obviously inappropriate for either draft to redefine ETag. If the protocols need something HTTP doesn't provide, they can mint a new header name, rather than base the semantics of the ETag response header on the results of a previous request. Wouldn't it be easier send "Sync: OK" or something? -- Robert Sayre Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 739567F7E6 for ; Tue, 25 Jul 2006 13:29:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 642E114225A for ; Tue, 25 Jul 2006 13:29:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02349-01 for ; Tue, 25 Jul 2006 13:29:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by laweleka.osafoundation.org (Postfix) with SMTP id 26BB7142290 for ; Tue, 25 Jul 2006 13:29:13 -0700 (PDT) Received: (qmail invoked by alias); 25 Jul 2006 20:29:12 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp042) with SMTP; 25 Jul 2006 22:29:12 +0200 X-Authenticated: #1915285 Message-ID: <44C67F07.1050802@gmx.de> Date: Tue, 25 Jul 2006 22:28:55 +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: Cyrus Daboo Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> <44512C9B.6090102@gmx.de> <44847841.8080902@gmx.de> <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> In-Reply-To: <074E50A7C8A95FFDB5E8B5E6@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , ietf@ietf.org, CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 20:29:17 -0000 Cyrus Daboo schrieb: > Hi Julian, > > --On June 5, 2006 8:30:25 PM +0200 Julian Reschke > wrote: > >> I notice that draft-dusseault-caldav-12 now is in IESG Evaluation >> (> =11253>). >> >> For the record: as far as I can tell, the issue that I raised below is >> critical (given the fact that we have a separate activity to clarify this >> in HTTP), and has not been addressed. It's not clear to me whether the >> client issue it attempts to solve really is important. If it is, there is >> a simpler way to accomplish this ([1]) that doesn't risk making CalDAV >> incompatible with other specs extending HTTP (or HTTP itself, for that >> matter). > > We are planning on addressing this ETag issue in a revision now that > last-call is over. Authors are discussing right now. The new text says (): "A response to a GET request targeted at a calendar object resource MUST contain an ETag response header field indicating the current value of the strong entity tag of the calendar object resource. Servers SHOULD return a strong entity tag (ETag header) in a PUT response when the stored calendar object resource is equivalent by octet equality to the calendar object resource submitted in the body of the PUT request. This allows clients to reliably use the returned strong entity tag for data synchronization purposes. For instance, the client can do a PROPFIND request on the stored calendar object resource and have the DAV:getetag property returned, and compare that value with the strong entity tag it received on the PUT response, and know that if they are equal, then the calendar object resource on the server has not been changed. In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted calendar object resource, the behavior of the ETag response header is not specified here, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, clients may need to retrieve the modified calendar object resource (and ETag) as a basis for further changes, rather than use the calendar object resource it had sent with the PUT request." Again, this profiles HTTP in a way that may turn out to be incompatible with the way the issue will be resolved in general; also this conflicts with ETag requirements in XCAP, which is also under IESG evaluation. By all means, please let this issue be clarified in a *single* place and in a way consistent for all HTTP resources. Also note a proposal was made back in April how CalDAV *could* resolve the syncing issue without relying on a specific ETag behavior which may not be the one a clarification of HTTP yields (see [1]). It would have been nice if the authors would have given feedback on why the proposed solution doesn't work for them. Best regards, Julian [1] Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DB8047F6AF for ; Mon, 3 Jul 2006 05:54:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CD67014228F for ; Mon, 3 Jul 2006 05:54:47 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05754-04 for ; Mon, 3 Jul 2006 05:54:41 -0700 (PDT) Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F9D614228D for ; Mon, 3 Jul 2006 05:54:41 -0700 (PDT) Received: from [10.0.1.4] ([10.0.1.4]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id k63Csb3L012663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jul 2006 08:54:38 -0400 Date: Mon, 03 Jul 2006 08:54:39 -0400 From: Cyrus Daboo To: Adam Laurie , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] What happened to the CalDav website? Message-ID: <428F7572DCDBF7076A067C9B@ninevah.local> In-Reply-To: <44A3BBD4.4020608@thebunker.net> References: <44A3BBD4.4020608@thebunker.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-3.3 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 12:54:48 -0000 Hi Adam, --On June 29, 2006 12:39:00 PM +0100 Adam Laurie wrote: > For the past couple of weeks I've been trying to find a download with no > joy... All URLS previously mentioned appear to be down: > > http://ietf.cse.ucsc.edu/caldav > http://caldav.org/ > http://www.caldav.org/ > http://ietf.webdav.org/caldav/ > > Is there CVS or some other access, or is the distribution site likely to > come back any time soon? > > BTW, please copy me on replies - I'm not subscribed to this list. The website has moved, but the owner of caldav.org has not updated to redirect to the new site. -- Cyrus Daboo