[Ietf-caldav] vCalender 1.0 component possible as return type?
cyrus at daboo.name
Wed Jun 21 06:02:58 PDT 2006
--On June 21, 2006 10:52:44 AM +0200 Alexander Traud
<alexander.traud at macnews.de> wrote:
> In reply to:
> I hope I understand this correctly, please correct me if I am wrong:
> - There is no requirement forcing a CalDAV client to understand or send
> iCalendar components. A CalDAV client can use for example vCalendar 1.0 or
> xCal or whatever as exchange format as long as the client states this in
> in Accept HTTP headers, of course. Nevertheless, if that succeeds,
> depends on the server.
Section 5.2.4 of the draft describes the CALDAV:supported-calendar-data.
That is used by the server to advertise what types of calendar data it
supports. In the absence of that property the server ONLY supports
text/calendar VERSION:2.0. So a good client wanting to store calendar data
in some other format will first check what is supported by the server and
then only use a format that is known to be supported.
In theory a server could advertise:
<C:calendar-data content-type="text/calendar" version="1.0"/>
Which would mean it ONLY supported vCalendar. However, section 2 states
that iCalendar MUST be supported - so there is a little discrepancy there -
I will look into fixing that.
> - There is no requirement forcing a CalDAV server to alter a received
> vCalendar 1.0 component to iCalendar (on PUT or any other method) except a
> non-vCalendar aware client asks for the component. So a PUT with a
> vCalendar might be saved 1:1 by the server.
Correct - nothing forces a server to return calendar data in a format other
than what was used to store it, but nothing prevents a server from doing
Question: do you really have a need to still use vCalendar as opposed to
iCalendar? If so, what is keeping you from upgrading?
More information about the Ietf-caldav