[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