[caldav] RFC4791: CALDAV:expand [Re: Clarification(s)]
Bernard Desruisseaux <bernard.desruisseaux@oracle.com> Thu, 05 November 2009 02:34 UTC
Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2C13A69D8 for <caldav@core3.amsl.com>; Wed, 4 Nov 2009 18:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.397
X-Spam-Level:
X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4]
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 GFXdqZNSvTlI for <caldav@core3.amsl.com>; Wed, 4 Nov 2009 18:34:51 -0800 (PST)
Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 99F0D3A67E6 for <caldav@ietf.org>; Wed, 4 Nov 2009 18:34:51 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nA52Yt0A030199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Nov 2009 02:34:57 GMT
Received: from hqdfmt01.oracle.com (hqdfmt01.oracle.com [148.87.24.194]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nA52aaOx020189; Thu, 5 Nov 2009 02:36:39 GMT
Received: from [141.144.121.203] (/141.144.121.203) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2009 18:35:05 -0800
Message-ID: <4AF239D5.7010005@oracle.com>
Date: Wed, 04 Nov 2009 21:35:01 -0500
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Mike Douglass <douglm@rpi.edu>
References: <4AC23DBD.6020206@sun.com> <4AD737D5.7040300@oracle.com> <002901ca4dab$f9ba6850$ed2f38f0$@net> <88061EBB-EA5E-4129-A358-840BA7F8C794@opengroupware.org> <4AF072B2.3080202@rpi.edu>
In-Reply-To: <4AF072B2.3080202@rpi.edu>
Content-Type: multipart/alternative; boundary="------------020207060402000808020508"
X-Source-IP: hqdfmt01.oracle.com [148.87.24.194]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4AF239DD.0054:SCFSTAT9981554,ss=1,fgs=0
Cc: caldav@ietf.org
Subject: [caldav] RFC4791: CALDAV:expand [Re: Clarification(s)]
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2009 02:34:52 -0000
Hi Mike, Mike Douglass wrote: > Section 9.6.5 caldav expand element > > We have the text: > > The returned calendar components MUST NOT use recurrence > properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT > have reference to or include VTIMEZONE components. Date and local > time with reference to time zone information MUST be converted > into date with UTC time. > > I assume this is meant to apply only to recurrence instances. i.e. non > instances remain with tzinfo. > No. It applies to recurring as well as non-recurring calendar components. See: http://tools.ietf.org/html/rfc4791#section-7.6 A CalDAV client with no support for recurrence properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components, or a client unwilling to perform recurrence expansion because of limited processing capability, can request to receive only the recurrence instances that overlap a specified time range as separate calendar components that each define exactly one recurrence instance (see CALDAV:expand in Section 9.6.5.) A calendar user agent unable to handle RRULE in VEVENT components will most likely not be able to handle RRULE in VTIMEZONE components as well. > Also note that RFC 4791 example for expanded retrieval has the events > with floating time not UTC > > DTSTART:20060103T170000 > Yes. The following lines in *red* were fixed in my annotated copy of RFC4791: >> Response << HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: application/xml; charset="utf-8" Content-Length: xxxx <?xml version="1.0" encoding="utf-8" ?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:response> <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href> <D:propstat> <D:prop> <D:getetag>"fffff-abcd2"</D:getetag> <C:calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT DTSTAMP:20060206T001121Z *DTSTART:20060103T170000Z* DURATION:PT1H *RECURRENCE-ID:20060103T170000Z* SUMMARY:Event #2 UID:00959BC664CA650E933C892C@example.com END:VEVENT BEGIN:VEVENT DTSTAMP:20060206T001121Z *DTSTART:20060104T190000Z* DURATION:PT1H *RECURRENCE-ID:20060104T170000Z* SUMMARY:Event #2 bis UID:00959BC664CA650E933C892C@example.com END:VEVENT END:VCALENDAR </C:calendar-data> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href> <D:propstat> <D:prop> <D:getetag>"fffff-abcd3"</D:getetag> <C:calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com DTSTAMP:20060206T001220Z *DTSTART:20060104T150000Z* DURATION:PT1H LAST-MODIFIED:20060206T001330Z ORGANIZER:mailto:cyrus@example.com SEQUENCE:1 STATUS:TENTATIVE SUMMARY:Event #3 UID:DC6C50A017428C5216A2F1CD@example.com X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com END:VEVENT END:VCALENDAR </C:calendar-data> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> Cheers, Bernard
- [caldav] various question on scheduling draft Arnaud Quillaud
- Re: [caldav] various question on scheduling draft Bernard Desruisseaux
- Re: [caldav] various question on scheduling draft Tim Hare
- Re: [caldav] various question on scheduling draft Helge Hess
- Re: [caldav] various question on scheduling draft Tim Hare
- [caldav] Clarification(s) Mike Douglass
- [caldav] RFC4791: CALDAV:expand [Re: Clarificatio… Bernard Desruisseaux
- Re: [caldav] RFC4791: CALDAV:expand [Re: Clarific… Mike Douglass