User:Bbbrowning

Random notes, thoughts, plots, and musings concerning the Sunbird/Lightning CalDAV provider:

CalDAV URL schemata

For a user $user with given name $firstname and surname $lastname:
Apple's (Darwin) CalendarServer uses http(s)://host:port/calendars/users/$user/calendar/
Bedework uses http(s)://host:port/ucaldav/user/$user/calendar/
Chandler uses a UUID-based URL that you pretty much have to get from their web client
DAViCal uses http(s)://host(:port)/caldav.php/$user/home/
Google uses https://www.google.com/calendar/dav/$googleuserid/events
Scalix uses http(s)://host:port/api/dav/Calendars/Users/$user/Calendar/ where $user is in the form of an email address
SOGo uses http(s):host:port/SOGo/dav/$user/Calendar/personal
Zimbra uses http(s)://host:port/dav/$user/Calendar In some cases $user is an email address, not simply a username

In all of these cases the last segment of the URI (calendar|Calendar||home||whatever) is a CalDAV calendar collection automatically provisioned when the user principal is created. The $user "folder" immediately above that is not a calendar collection (can't be, since the specs say that calendar collections cannot nest); instead it serves as the principal's "home directory", and $user can create other calendar collections there. Sunbird/Lightning currently cannot create calendar collections, so new collections need to be created either in the server's Web interface (in cases where that's possible) or from the command line. Example of the latter on an Apple server:

curl -X MKCALENDAR -u username:userpass http(s)://host:port/calendars/users/$user/newcalendar/