15

As I understand it, CalDAV is an extension to WebDAV to manage iCalendar subscriptions.

And Webcal is a URL scheme that does the same thing, but not standarized.

I'm I right here? Whats the pros/cons for going either way?

user3332631
  • 334
  • 1
  • 3
  • 11

2 Answers2

25

All what Julian said, but presumably the real question is about the difference between plain iCalendar-over-HTTP (commonly called webcal, 'iCalendar subscription' or 'subscribed calendar') and CalDAV. Or in other words: what does CalDAV add.

Simply put: in iCoHTTP you usually store a whole calendar under one URL, like 'http://yahoo.com/sports/nba/schedule-2015.ics' (or webcal:). This URL represents a full calendar and is almost always readonly (you can't do a PUT to this URL). Why is that? Because to add/change/delete a single event in such a calendar, you would need to re-transfer the full calendar.

In CalDAV a calendar is a WebDAV collection, there is one URL which represents the calendar, e.g.: 'http://icloud.com/calendars/joe/home/' and then you have one child URL for each event. Like 'http://icloud.com/calendars/joe/home/buy-beer.ics', 'http://icloud.com/calendars/joe/home/family-meeting.ics' and so on. You can then just DELETE, PUT etc individual items of such a collection.

In summary: If you simply want to publish a calendar which rarely changes and is managed by other means (like a CMS), you can use iCal-over-HTTP. If you want to provide a calendar which the user (or maybe a group of people) can change from within their calendar client, you want to use CalDAV.

CalDAV also has a set of extensions, e.g. many CalDAV server can automatically perform scheduling operations for you (setting up meetings and such). There is an extension to share calendars with other people, and so on.

P.S.: This is a bit confusing, but yes, Apple also has a way of using WebDAV to manage iCalendar subscriptions. But this is yet another thing which works alongside CalDAV.

hnh
  • 13,957
  • 6
  • 30
  • 40
8

CalDAV is a protocol, extending WebDAV, thus HTTP.

Webcal is a URI scheme that AFAIK was invented by Apple and has exactly the same semantics as "http", except that Safari (and maybe some other browsers) know that the URI refers to a calendar, and thus invoke the "right" application without having to fetch the resource.

(Of course the right thing would have been just to inspect the media type (content-type header field) and then to invoke the matching application.

So this is an anti-pattern (done again by Apple with "itms" URIs).

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • The problem with doing it the 'right' way is that browsers don't launch the application with the url, but rather a local filename. Unless you write browser extensions. So if this is an anti-pattern, how do you fix this the correct way? – Evert May 25 '15 at 15:22
  • Not sure what you are trying to say here. Julian's answer contains the correct way. Right now the 'browser' has special handling for the 'webcal' URL, which is 'wrong'. Instead it should do a HEAD (or GET) request on the resource and then invoke the proper application (with the URL, not [only] a downloaded file) depending on the MIME type. The webcal scheme is just a quick hack to get things going. – hnh May 25 '15 at 19:38