[caldav] Clarification(s)

[Mike Douglass <[e-mail]>]

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                           [e-mail]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180