Subject: [caldav] Clarification(s)

From: Mike Douglass <[email-masked]>
Date: Tue, 03 Nov 2009 13:13:06 -0500

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.

Also note that RFC 4791 example for expanded retrieval has the events
with floating time not UTC

   DTSTART:20060103T170000

Helge Hess wrote:
> On 15.10.2009, at 17:27, Tim Hare wrote:
>> In RFC 5445 for PRODID
>>
>> "   Purpose:  This property specifies the identifier for the product
>> that
>>      created the iCalendar object."
>>
>> While it doesn't say this is REQUIRED or 'MUST specify' I believe
>> that is
>> the intent.  The language could perhaps specify that requirement in the
>> future, with some standardized form for 'hand-edited' items.  For
>> interop
>> troubleshooting issues it is critical that we know what created the
>> particular object we're looking at.
>
> In the context of CalDAV its a bit more complicated than with the
> throwaway iMIP entities (which the original iCal authors probably had
> in mind).
> For example our Outlook plugin only touches the parts of the iCalendar
> entity which it knows about, other parts are preserved as-is. Hence
> the resulting iCalendar entity after PUT operations is like a mixture
> between two or even more clients.
>
> I'm not sure what the PRODID is good for anyways, user-agent sniffing
> is dangerous ...
>
> Greets,
>   Helge

-- 

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 04 Nov 2009 21:35:01 -0500

Hi Mike,

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

---

From: Mike Douglass <[email-masked]>
Date: Thu, 05 Nov 2009 00:49:03 -0500

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.

--