Re: [caldav] RFC4791: CALDAV:expand [Re: Clarification(s)]

[Mike Douglass <[e-mail]>]

I can buy that and I flip-flopped between the two. I guess there's an
assumption here I hadn't seen, that the client is actually doing the
timezone processing. I'd suggest the language is changed to de-emphasize
recurring.


Bernard Desruisseaux wrote:
> 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:[e-mail]
> END:VEVENT
> BEGIN:VEVENT
> DTSTAMP:20060206T001121Z
> *DTSTART:20060104T190000Z*
> DURATION:PT1H
> *RECURRENCE-ID:20060104T170000Z*
> SUMMARY:Event #2 bis
> UID:[e-mail]
> 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:[e-mail]
> ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:[e-mail]
> DTSTAMP:20060206T001220Z
> *DTSTART:20060104T150000Z*
> DURATION:PT1H
> LAST-MODIFIED:20060206T001330Z
> ORGANIZER:mailto:[e-mail]
> SEQUENCE:1
> STATUS:TENTATIVE
> SUMMARY:Event #3
> UID:[e-mail]
> X-ABC-GUID:[e-mail]
> 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 

-- 

Mike Douglass                           [e-mail]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180