+ do NOT use ORGANIZER for events without further participants or a different organizer
+ do not include event owner/ORGANIZER as participant in his own calendar, if he is only participant
--> all other cases include ORGANZIER and additional as ATTENDEE (tested with iCal on iOS and OS X)
- implemented schedule-tag and If-Schedule-Tag-Match header from CalDAV Scheduling
- allow to change participant status and add/remove alarms with schedule-tag instead of ETag
--> If-Schedule-Tag-Match header has precedence over If-Match (ETag) header, but limits changes to participant status and alarms
--> ToDo: test accepting, rejecting recurrences
--> participants are - thanks to CalDAV scheduling - now setable for new event, thought searching for them does NOT yet work, no idea why ;-)
- added somehow missing calendar-query report to supported-report-set
- had to implement a workaround for Lightning, as it wrongly interprets principal-property-search for calendar-home-set in the principal-collection-set
matching our *DAV root returning all principals, as all have a matching calendar-home-set, as NOT supporting CalDAV scheduling
--> search only current user's principal, when Lightning searches for calendar-home-set
- OPTIONS / return now calendar-auto-scheduling too, as Lightning only searches there, to check if server supports CalDAV scheduling
- fixed outbox freebusy request to cope with no X-CALENDARSERVER-MASK-UID and a single attendee
- principal reports scheduling-inbox-URL /<username>/inbox/ and scheduling-outbox-URL /<username>/outbox/
- outbox collection contains no events
- outbox correctly answers POST for freebusy information
- outbox respons to all other POST with "204 No Content", ignore client request to deliver invitations
- inbox collection contains events of unknown status (PARTSTAT=NEEDS-ACTION)
- inbox responds to DELETE with "200 Ok"
--> iCal under OS X now shows freebusy times :-)
(had to add "write-content" privilege for calendar collections user has edit rights for, to allow adding events)
+ currently only standard WebDAV privileges: read, read-current-user-privilege-set, write-content, bind and unbind used
+ they get only queried for collections, thought we dont report any write* on collections, as we dont allow to create calendars or change properties
- new groupdav::add_resource() method used to add all resources (incl. collections) to propfind or report requests
- improved autoindex to show nicely indented hierarchical properties
- only define addressbook-home-set and calendar-home-set for principal-collections
- advertice /addressbook/ as addressbook-gateway (searchable collection for all contacts accessible to a user)
