[CalendarServer-changes] [4437] CalendarServer/branches/config-separation
source_changes at macosforge.org
source_changes at macosforge.org
Wed Jul 8 16:19:45 PDT 2009
Revision: 4437
http://trac.macosforge.org/projects/calendarserver/changeset/4437
Author: william_short at apple.com
Date: 2009-07-08 16:19:44 -0700 (Wed, 08 Jul 2009)
Log Message:
-----------
revert 4434, 4435
Modified Paths:
--------------
CalendarServer/branches/config-separation/calendarserver/__init__.py
CalendarServer/branches/config-separation/calendarserver/tap/caldav.py
CalendarServer/branches/config-separation/calendarserver/tap/test/test_caldav.py
CalendarServer/branches/config-separation/calendarserver/tools/principals.py
CalendarServer/branches/config-separation/calendarserver/tools/util.py
CalendarServer/branches/config-separation/calendarserver/webadmin/resource.py
CalendarServer/branches/config-separation/doc/RFC/draft-desruisseaux-caldav-sched.txt
CalendarServer/branches/config-separation/doc/calendarserver_manage_principals.8
CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.auth.digest.patch
CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.dav.resource.patch
CalendarServer/branches/config-separation/pyflakes
CalendarServer/branches/config-separation/run
CalendarServer/branches/config-separation/twisted/plugins/caldav.py
CalendarServer/branches/config-separation/twistedcaldav/accesslog.py
CalendarServer/branches/config-separation/twistedcaldav/caldavxml.py
CalendarServer/branches/config-separation/twistedcaldav/directory/appleopendirectory.py
CalendarServer/branches/config-separation/twistedcaldav/directory/oldappleopendirectory.py
CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_proxyprincipalmembers.py
CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_sqldb.py
CalendarServer/branches/config-separation/twistedcaldav/directory/xmlaccountsparser.py
CalendarServer/branches/config-separation/twistedcaldav/mail.py
CalendarServer/branches/config-separation/twistedcaldav/method/delete_common.py
CalendarServer/branches/config-separation/twistedcaldav/method/put_common.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/caldav.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/icaldiff.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/implicit.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/itip.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/processing.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/scheduler.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/test/test_icaldiff.py
CalendarServer/branches/config-separation/twistedcaldav/test/test_config.py
CalendarServer/branches/config-separation/twistedcaldav/test/test_memcacheprops.py
CalendarServer/branches/config-separation/twistedcaldav/test/test_upgrade.py
CalendarServer/branches/config-separation/twistedcaldav/upgrade.py
CalendarServer/branches/config-separation/twistedcaldav/util.py
Removed Paths:
-------------
CalendarServer/branches/config-separation/calendarserver/sidecar/
CalendarServer/branches/config-separation/twext/python/log.py
CalendarServer/branches/config-separation/twistedcaldav/scheduling/utils.py
Property Changed:
----------------
CalendarServer/branches/config-separation/
Property changes on: CalendarServer/branches/config-separation
___________________________________________________________________
Modified: svn:mergeinfo
- /CalendarServer/branches/users/sagen/resource-delegates-4038:4040-4067
/CalendarServer/branches/users/sagen/resource-delegates-4066:4068-4075
/CalendarServer/trunk:4380-4382,4384-4385,4387,4389,4392-4393,4395,4397,4403,4409-4413,4415-4416,4421,4426,4428-4430
+ /CalendarServer/branches/users/sagen/resource-delegates-4038:4040-4067
/CalendarServer/branches/users/sagen/resource-delegates-4066:4068-4075
Deleted: svk:merge
- e27351fd-9f3e-4f54-a53b-843176b1656c:/CalendarServer/trunk:4430
Modified: CalendarServer/branches/config-separation/calendarserver/__init__.py
===================================================================
--- CalendarServer/branches/config-separation/calendarserver/__init__.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/calendarserver/__init__.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -17,8 +17,3 @@
"""
CalendarServer application code.
"""
-
-# setuptools is annoying
-from warnings import filterwarnings
-filterwarnings("ignore", "Module (.*) was already imported (.*)")
-del filterwarnings
Modified: CalendarServer/branches/config-separation/calendarserver/tap/caldav.py
===================================================================
--- CalendarServer/branches/config-separation/calendarserver/tap/caldav.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/calendarserver/tap/caldav.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -39,7 +39,6 @@
from twisted.python.usage import Options, UsageError
from twisted.python.reflect import namedClass
from twisted.plugin import IPlugin
-from twisted.internet.defer import DeferredList, succeed, inlineCallbacks, returnValue
from twisted.internet.reactor import callLater
from twisted.internet.process import ProcessExitedAlready
from twisted.internet.protocol import Protocol, Factory
@@ -59,12 +58,6 @@
from twext.internet.ssl import ChainingOpenSSLContextFactory
from twext.web2.channel.http import HTTP503LoggingFactory
-try:
- from twistedcaldav.version import version
-except ImportError:
- sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.dirname(__file__))), "support"))
- from version import version as getVersion
- version = "%s (%s)" % getVersion()
from twistedcaldav.log import Logger, LoggingMixIn
from twistedcaldav.log import logLevelForNamespace, setLogLevelForNamespace
from twistedcaldav.accesslog import DirectoryLogWrapperResource
@@ -343,7 +336,7 @@
implements(IPlugin, IServiceMaker)
tapname = "caldav"
- description = "Darwin Calendar Server"
+ description = "The Darwin Calendar Server"
options = CalDAVOptions
#
@@ -366,8 +359,6 @@
def makeService(self, options):
- self.log_info("%s %s starting %s process..." % (self.description, version, config.ProcessType))
-
serviceMethod = getattr(self, "makeService_%s" % (config.ProcessType,), None)
if not serviceMethod:
@@ -860,6 +851,9 @@
def makeService_Combined(self, options):
s = MultiService()
+ # Process localization string files
+ processLocalizationFiles(config.Localization)
+
# Make sure no old socket files are lying around.
self.deleteStaleSocketFiles()
@@ -1128,24 +1122,6 @@
monitor.addProcess("mailgateway", mailGatewayArgv, env=parentEnv)
- self.log_info("Adding task service")
- taskArgv = [
- sys.executable,
- config.Twisted.twistd,
- ]
- if config.UserName:
- taskArgv.extend(("-u", config.UserName))
- if config.GroupName:
- taskArgv.extend(("-g", config.GroupName))
- taskArgv.extend((
- "--reactor=%s" % (config.Twisted.reactor,),
- "-n", "caldav_task",
- "-f", options["config"],
- ))
-
- monitor.addProcess("caldav_task", taskArgv, env=parentEnv)
-
-
stats = CalDAVStatisticsServer(logger)
statsService = UNIXServer(config.GlobalStatsSocket, stats)
statsService.setServiceParent(s)
@@ -1200,8 +1176,6 @@
self.log_warn("Deleting stale socket file (not accepting connections): %s" % checkSocket)
os.remove(checkSocket)
-
-
class TwistdSlaveProcess(object):
prefix = "caldav"
Modified: CalendarServer/branches/config-separation/calendarserver/tap/test/test_caldav.py
===================================================================
--- CalendarServer/branches/config-separation/calendarserver/tap/test/test_caldav.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/calendarserver/tap/test/test_caldav.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -207,7 +207,7 @@
def tearDown(self):
config.setDefaults(DEFAULT_CONFIG)
- config.reset()
+ config.reload()
def writeConfig(self):
"""
Modified: CalendarServer/branches/config-separation/calendarserver/tools/principals.py
===================================================================
--- CalendarServer/branches/config-separation/calendarserver/tools/principals.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/calendarserver/tools/principals.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -18,21 +18,26 @@
import sys
import os
+import itertools
import operator
from getopt import getopt, GetoptError
from uuid import UUID
from pwd import getpwnam
from grp import getgrnam
+
+from twisted.python import log
+from twisted.python.reflect import namedClass
from twisted.python.util import switchUID
from twisted.internet import reactor
+from twisted.internet.defer import Deferred
from twisted.internet.address import IPv4Address
-from twisted.internet.defer import inlineCallbacks
+from twisted.internet.defer import inlineCallbacks, returnValue, succeed
from twisted.web2.dav import davxml
-from twext.python.log import StandardIOObserver
from twext.web2.dav.davxml import sname2qname, qname2sname
+from twistedcaldav import caldavxml
from twistedcaldav import memcachepool
from twistedcaldav.config import config, ConfigurationError
from twistedcaldav.stdconfig import DEFAULT_CONFIG
@@ -43,8 +48,8 @@
from twistedcaldav.notify import installNotificationClient
from twistedcaldav.static import CalendarHomeProvisioningFile
-from calendarserver.tools.util import booleanArgument, autoDisableMemcached
-from calendarserver.tools.util import loadConfig, getDirectory
+from calendarserver.tools.util import UsageError, booleanArgument, autoDisableMemcached
+from calendarserver.tools.util import loadConfig, getDirectory, dummyDirectoryRecord
from calendarserver.provision.root import RootResource
def usage(e=None):
@@ -84,12 +89,16 @@
sys.exit(0)
def main():
+
#
# Send logging output to stdout
#
- observer = StandardIOObserver()
- observer.start()
+ logFileName = "/dev/stdout"
+ observer = log.FileLogObserver(open(logFileName, "a"))
+ log.addObserver(observer.emit)
+
+
try:
(optargs, args) = getopt(
sys.argv[1:], "hf:P:", [
Modified: CalendarServer/branches/config-separation/calendarserver/tools/util.py
===================================================================
--- CalendarServer/branches/config-separation/calendarserver/tools/util.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/calendarserver/tools/util.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -22,6 +22,7 @@
"booleanArgument",
]
+import sys
import os
from time import sleep
Modified: CalendarServer/branches/config-separation/calendarserver/webadmin/resource.py
===================================================================
--- CalendarServer/branches/config-separation/calendarserver/webadmin/resource.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/calendarserver/webadmin/resource.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -24,6 +24,8 @@
import cgi
import operator
+import os
+import urllib
import urlparse
from calendarserver.tools.principals import principalForPrincipalID, proxySubprincipal, action_addProxyPrincipal, action_removeProxyPrincipal
@@ -36,6 +38,7 @@
from twisted.web2.http_headers import MimeType
from twisted.web2.stream import MemoryStream
from twisted.web2.dav import davxml
+from twisted.web2.dav.resource import TwistedACLInheritable
class WebAdminResource (ReadOnlyResourceMixIn, DAVFile):
Modified: CalendarServer/branches/config-separation/doc/RFC/draft-desruisseaux-caldav-sched.txt
===================================================================
--- CalendarServer/branches/config-separation/doc/RFC/draft-desruisseaux-caldav-sched.txt 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/doc/RFC/draft-desruisseaux-caldav-sched.txt 2009-07-08 23:19:44 UTC (rev 4437)
@@ -1,5264 +1,3192 @@
-
-
-
-Network Working Group C. Daboo
-Internet-Draft Apple Inc.
-Intended status: Standards Track B. Desruisseaux
-Expires: December 21, 2009 Oracle
- June 19, 2009
-
-
- CalDAV Scheduling Extensions to WebDAV
- draft-desruisseaux-caldav-sched-07
-
-Status of This Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79. This document may contain material
- from IETF Documents or IETF Contributions published or made publicly
- available before November 10, 2008. The person(s) controlling the
- copyright in some of this material may not have granted the IETF
- Trust the right to allow modifications of such material outside the
- IETF Standards Process. Without obtaining an adequate license from
- the person(s) controlling the copyright in such materials, this
- document may not be modified outside the IETF Standards Process, and
- derivative works of it may not be created outside the IETF Standards
- Process, except to format it for publication as an RFC or to
- translate it into languages other than English.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on December 21, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 1]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 2]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-Abstract
-
- This document defines extensions to the CalDAV "calendar-access"
- feature to specify a standard way of performing scheduling
- transactions with iCalendar-based calendar components. This document
- defines the "calendar-auto-schedule" feature of CalDAV.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
- 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 1.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8
- 1.4. Notational Conventions . . . . . . . . . . . . . . . . . . 9
- 1.5. XML Namespaces and Processing . . . . . . . . . . . . . . 9
- 2. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 11
- 3. Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 12
- 4. Scheduling Collections . . . . . . . . . . . . . . . . . . . . 13
- 4.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 13
- 4.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 14
- 4.3. Calendaring Reports Extensions . . . . . . . . . . . . . . 16
- 5. Scheduling Transactions . . . . . . . . . . . . . . . . . . . 17
- 5.1. Identifying Scheduling Object Resources . . . . . . . . . 17
- 5.2. Handling Scheduling Object Resources . . . . . . . . . . . 17
- 5.2.1. Organizer Scheduling Object Resources . . . . . . . . 17
- 5.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 18
- 5.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 19
- 5.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 20
- 5.2.2. Attendee Scheduling Object Resources . . . . . . . . . 21
- 5.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 21
- 5.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 22
- 5.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 22
- 5.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 22
- 5.2.3. HTTP Methods . . . . . . . . . . . . . . . . . . . . . 23
- 5.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 23
- 5.2.3.2. COPY . . . . . . . . . . . . . . . . . . . . . . . 24
- 5.2.3.3. MOVE . . . . . . . . . . . . . . . . . . . . . . . 24
- 5.2.3.4. DELETE . . . . . . . . . . . . . . . . . . . . . . 25
- 5.2.4. Additional Method Preconditions . . . . . . . . . . . 25
- 5.2.4.1. CALDAV:unique-scheduling-object-resource
- Precondition . . . . . . . . . . . . . . . . . . . 25
- 5.2.4.2. CALDAV:same-organizer-in-all-components
- Precondition . . . . . . . . . . . . . . . . . . . 25
- 5.2.4.3. CALDAV:allowed-organizer-scheduling-object-chan
- Precondition . . . . . . . . . . . . . . . . . . . 26
- 5.2.4.4. CALDAV:allowed-attendee-scheduling-object-chang
- Precondition . . . . . . . . . . . . . . . . . . . 27
- 5.2.5. DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 27
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 3]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- 5.2.6. Limit Recurrence Instances Sent to Attendees . . . . . 27
- 5.2.7. Forcing the Server to Send a Scheduling Message . . . 28
- 6. Processing Incoming Scheduling Messages . . . . . . . . . . . 29
- 6.1. Processing Attendee Replies . . . . . . . . . . . . . . . 29
- 6.2. Processing Organizer Requests, Additions, and
- Cancellations . . . . . . . . . . . . . . . . . . . . . . 30
- 6.3. Default Calendar Collection . . . . . . . . . . . . . . . 30
- 6.3.1. Additional Method Preconditions . . . . . . . . . . . 31
- 6.3.1.1. CALDAV:default-calendar-delete-allowed
- Precondition . . . . . . . . . . . . . . . . . . . 31
- 6.3.1.2. CALDAV:valid-schedule-default-calendar-URL
- Precondition . . . . . . . . . . . . . . . . . . . 31
- 6.4. Scheduling Messages as Notifications . . . . . . . . . . . 32
- 7. Request for Busy Time Information . . . . . . . . . . . . . . 33
- 7.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 33
- 7.2. Additional Method Preconditions . . . . . . . . . . . . . 33
- 7.2.1. DAV:need-privileges Precondition . . . . . . . . . . . 33
- 7.2.2. CALDAV:supported-collection Precondition . . . . . . . 34
- 7.2.3. CALDAV:supported-calendar-data Precondition . . . . . 35
- 7.2.4. CALDAV:valid-calendar-data Precondition . . . . . . . 35
- 7.2.5. CALDAV:valid-scheduling-message Precondition . . . . . 36
- 7.2.6. CALDAV:organizer-allowed Precondition . . . . . . . . 36
- 7.2.7. CALDAV:max-resource-size Precondition . . . . . . . . 37
- 7.3. Response to a POST request . . . . . . . . . . . . . . . . 37
- 8. Conditional Requests on Scheduling Object Resources . . . . . 38
- 8.1. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
- 8.2. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 40
- 8.3. COPY or MOVE . . . . . . . . . . . . . . . . . . . . . . . 41
- 9. Other Scheduling Considerations . . . . . . . . . . . . . . . 42
- 9.1. Attendee Participation Status . . . . . . . . . . . . . . 42
- 9.2. Schedule Status Values . . . . . . . . . . . . . . . . . . 43
- 9.3. Organizer is an Attendee . . . . . . . . . . . . . . . . . 45
- 10. Additional iCalendar Property Parameters . . . . . . . . . . . 46
- 10.1. Schedule Agent Parameter . . . . . . . . . . . . . . . . . 46
- 10.2. Schedule Force Send Parameter . . . . . . . . . . . . . . 47
- 10.3. Schedule Status Parameter . . . . . . . . . . . . . . . . 48
- 11. Additional Message Header Fields . . . . . . . . . . . . . . . 50
- 11.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 50
- 11.2. Schedule-Tag Response Header . . . . . . . . . . . . . . . 50
- 11.3. If-Schedule-Tag-Match Request Header . . . . . . . . . . . 51
- 12. Additional WebDAV Properties . . . . . . . . . . . . . . . . . 52
- 12.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 52
- 12.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 53
- 12.3. CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 54
- 13. Scheduling Access Control . . . . . . . . . . . . . . . . . . 55
- 13.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 55
- 13.1.1. Privileges on Scheduling Inbox Collections . . . . . . 55
- 13.1.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . 55
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 4]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- 13.1.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . 56
- 13.1.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . 56
- 13.1.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . 56
- 13.1.2. Privileges on Scheduling Outbox Collections . . . . . 56
- 13.1.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . 56
- 13.1.2.2. CALDAV:schedule-send-invite Privilege . . . . . . 57
- 13.1.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . 57
- 13.1.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . 57
- 13.1.3. Aggregation of Scheduling Privileges . . . . . . . . . 57
- 13.2. Additional Principal Properties . . . . . . . . . . . . . 58
- 13.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 58
- 13.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 59
- 13.2.3. CALDAV:calendar-user-address-set Property . . . . . . 59
- 13.2.4. CALDAV:calendar-user-type Property . . . . . . . . . . 60
- 14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 62
- 14.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 62
- 14.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 62
- 14.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 62
- 14.4. CALDAV:request-status XML Element . . . . . . . . . . . . 63
- 15. Security Considerations . . . . . . . . . . . . . . . . . . . 64
- 15.1. Verifying Scheduling Transactions . . . . . . . . . . . . 64
- 15.2. Verifying Busy Time Information Requests . . . . . . . . . 64
- 15.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 65
- 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
- 16.1. Message Header Field Registrations . . . . . . . . . . . . 66
- 16.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 66
- 16.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 66
- 16.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 66
- 16.2. iCalendar Property Parameter Registrations . . . . . . . . 67
- 16.3. Additional iCalendar Elements Registries . . . . . . . . . 67
- 16.3.1. Schedule Agent Values Registry . . . . . . . . . . . . 67
- 16.3.2. Schedule Force Send Values Registry . . . . . . . . . 67
- 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
- 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
- 18.1. Normative References . . . . . . . . . . . . . . . . . . . 70
- 18.2. Informative References . . . . . . . . . . . . . . . . . . 71
- Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 72
- A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 72
- A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 72
- Appendix B. Example Scheduling Transactions . . . . . . . . . . . 74
- B.1. Example: Organizer Inviting Multiple Attendees . . . . . . 74
- B.2. Example: Attendee Receiving an Invitation . . . . . . . . 76
- B.3. Example: Attendee Replying to an Invitation . . . . . . . 78
- B.4. Example: Organizer Receiving a Reply to an Invitation . . 80
- B.5. Example: Organizer Requesting Busy Time Information . . . 82
- B.6. Example: User Attempting to Invite Attendee on behalf
- of Organizer . . . . . . . . . . . . . . . . . . . . . . . 84
- B.7. Example: Attendee Declining an Instance of a Recurring
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 5]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Event . . . . . . . . . . . . . . . . . . . . . . . . . . 85
- B.8. Example: Attendee Removing an Instance of a Recurring
- Event . . . . . . . . . . . . . . . . . . . . . . . . . . 89
- Appendix C. Changes (to be removed by RFC Editor prior to
- publication) . . . . . . . . . . . . . . . . . . . . 92
- C.1. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 92
- C.2. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 92
- C.3. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 93
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 6]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-1. Introduction
-
- This document specifies extensions to the CalDAV "calendar-access"
- [RFC4791] feature to enable scheduling of iCalendar-based
- [I-D.ietf-calsify-rfc2445bis] calendar components between Calendar
- Users. This extension leverages the scheduling methods defined in
- the iCalendar Transport-independent Interoperability Protocol (iTIP)
- [I-D.ietf-calsify-2446bis] to permit Calendar Users to perform
- scheduling transactions such as schedule, reschedule, respond to
- scheduling request or cancel scheduled calendar components, as well
- as search for busy time information.
-
- Discussion of this Internet-Draft is taking place on the mailing list
- <https://www.ietf.org/mailman/listinfo/caldav>.
-
-1.1. Terminology
-
- This specification uses much of the same terminology as iCalendar
- [I-D.ietf-calsify-rfc2445bis], iTIP [I-D.ietf-calsify-2446bis],
- WebDAV [RFC4918], and CalDAV [RFC4791]. The following definitions
- are provided to aid the reader in understanding this specification.
-
- Calendar User (CU): An entity (often a human) that accesses calendar
- information [RFC3283].
-
- Calendar User Agent (CUA): Software with which the calendar user
- communicates with a calendar service or local calendar store to
- access calendar information [RFC3283].
-
- Calendar collection: A resource that acts as a container of
- references to child calendar object resources [RFC4791].
-
- Calendar object resource: A resource representing a calendar object
- (event, to-do, journal entry, or other calendar components)
- [RFC4791].
-
- Scheduling object resource: A calendar object resource contained in
- a calendar collection for which the server will take care of
- sending scheduling messages on behalf of the owner of the calendar
- collection.
-
- Organizer scheduling object resource: A scheduling object resource
- owned by an Organizer.
-
- Attendee scheduling object resource: A scheduling object resource
- owned by an Attendee.
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 7]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Automatic scheduling transaction: Add, change or remove operations
- on a scheduling object resource for which the server will deliver
- scheduling messages to other Calendar Users.
-
- Scheduling message: A calendar object resource that describes a
- scheduling transaction such as schedule, reschedule, reply, or
- cancel.
-
- Scheduling Outbox collection: A resource at which busy time
- information requests are targeted.
-
- Scheduling Inbox collection: A collection in which incoming
- scheduling messages are delivered.
-
-1.2. Approach
-
- iTIP [I-D.ietf-calsify-2446bis] outlines a model where Calendar Users
- exchange scheduling messages with one another. Often times, Calendar
- User Agents are made responsible for generating and sending
- scheduling messages as well as processing incoming scheduling
- messages. This approach yields a number of problems, including:
-
- o For most updates to a scheduled calendar component, Calendar User
- Agents need to address a separate scheduling messages to the
- Organizer or the Attendees.
-
- o The handling of incoming scheduling messages and the updates to
- calendars impacted by those messages only occurs when Calendar
- User Agents are active.
-
- o Due to the update latency, it is possible for calendars of
- different Calendar Users to reflect different, inaccurate states.
-
- This specification uses an alternative approach where the server is
- made responsible for sending scheduling messages and processing
- incoming scheduling messages. This approach frees the Calendar User
- Agents from the submission and processing of scheduling messages and
- ensures better consistency of calendar data across users' calendars.
- The operation of creating, modifying or deleting a scheduled calendar
- component in a calendar is enough to trigger the server to deliver
- the necessary scheduling messages to the appropriate Calendar Users.
-
-1.3. Limitations
-
- While the scheduling features described in this specification are
- based on iTIP [I-D.ietf-calsify-2446bis], some of its more complex
- features have deliberately been left out in order to keep this
- specification simple. In particular, the following iTIP
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 8]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- [I-D.ietf-calsify-2446bis] features are not covered: publishing,
- countering, delegating, refreshing and forwarding calendar
- components, as well as replacing the Organizer of a calendar
- component.
-
- The goal of this specification is to provide the essential scheduling
- features needed. It is expected that future extensions will be
- developed to address the more complex features.
-
-1.4. Notational Conventions
-
- The Augmented BNF (ABNF) syntax used by this document to specify the
- format definition of new iCalendar elements is defined in [RFC5234].
-
- The Augmented BNF (ABNF) syntax used by this document to specify the
- format definition of new message header fields to be used with the
- HTTP/1.1 protocol is described in Section 2.1 of [RFC2616]. Since
- this Augmented BNF uses the basic production rules provided in
- Section 2.2 of [RFC2616], these rules apply to this document as well.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
- outside of the context of an XML fragment, the string "DAV:" and
- "CALDAV:" will be prefixed to the element types respectively.
-
-1.5. XML Namespaces and Processing
-
- Definitions of XML elements in this document use XML element type
- declarations (as found in XML Document Type Declarations), described
- in Section 3.2 of [W3C.REC-xml-20081126].
-
- The XML elements specified in this document are defined in the
- "urn:ietf:params:xml:ns:caldav" XML namespace registered by CalDAV
- [RFC4791].
-
- The XML declarations used in this document do not include namespace
- information. Thus, implementers must not use these declarations as
- the only way to create valid CalDAV properties or to validate CalDAV
- XML element type. Some of the declarations refer to XML elements
- defined by WebDAV [RFC4918] which use the "DAV:" namespace. Wherever
- such XML elements appear, they are explicitly prefixed with "DAV:" to
- avoid confusion. Additionally, some of the elements used here are
- defined in CalDAV "calendar-access" [RFC4791].
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 9]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Also note that some CalDAV XML element names are identical to WebDAV
- XML element names, though their namespace differs. Care must be
- taken not to confuse the two sets of names.
-
- Processing of XML by CalDAV clients and servers MUST follow the rules
- described in Section 17 of [RFC4918].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 10]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-2. Scheduling Process
-
- The process of scheduling an event between different parties often
- involves a series of steps with different actors playing particular
- roles during the whole process. Typically there is an event
- "Organizer" whose role is to setup an event between one or more
- "Attendees", and this is done by sending out invitations and handling
- responses from each Attendee.
-
- This process can typically be broken down into two phases.
-
- In the first phase, the Organizer will query the busy time
- information of each Attendee to determine the most appropriate time
- for the event. This request is sometimes called a freebusy lookup.
-
- In the second phase, the Organizer sends out invitations to each
- Attendee using the time previously determined from the freebusy
- lookup. There then follows exchanges between Organizer and Attendees
- regarding the invitation. Some Attendees may choose to attend at the
- time proposed by the Organizer, others may decline to attend. The
- Organizer needs to process each of the replies from the Attendees and
- take appropriate action to confirm the event, reschedule it or
- perhaps cancel it.
-
- The user expectation as to how a calendaring and scheduling system
- should respond in each of these two phases is somewhat different. In
- the case of a freebusy lookup, users expect to get back results
- immediately so that they can then move on to the invitation phase as
- quickly as possible. In the case of invitations, it is expected that
- each Attendee will reply with their participation status in their own
- time, so delays in receiving replies are anticipated. Thus
- calendaring and scheduling systems should treat these two operational
- phases in different ways to accommodate the user expectations, and
- this specification does that.
-
- While the scenario described above only covers the case of scheduling
- events between Calendar Users, and requesting busy time information,
- this specification also provides support for the scheduling of to-dos
- between Calendar Users. For the majority of the following
- discussion, scheduling of events and freebusy lookups will be
- discussed, as these are the more common operations.
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 11]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-3. Scheduling Support
-
- A server that supports the features described in this document MUST
- include "calendar-auto-schedule" as a field in the DAV response
- header from an OPTIONS request on any resource that supports any
- scheduling actions, properties, privileges or methods.
-
- To advertise support for the CalDAV "calendar-auto-schedule" feature
- a server is REQUIRED to support and advertise support for the CalDAV
- "calendar-access" [RFC4791] feature.
-
- >> Request <<
-
- OPTIONS /home/cyrus/calendars/inbox/ HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 204 No Content
- Date: Thu, 31 Mar 2005 09:00:00 GMT
- Allow: OPTIONS, GET, HEAD, DELETE, TRACE, PROPFIND
- Allow: PROPPATCH, LOCK, UNLOCK, REPORT, ACL
- DAV: 1, 2, 3, access-control
- DAV: calendar-access, calendar-auto-schedule
-
- In this example, the OPTIONS response indicates that the server
- supports the "calendar-access" and "calendar-auto-schedule" features
- and that resource "/home/cyrus/calendars/inbox/" supports the
- scheduling actions, properties, privileges and methods defined in
- this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 12]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-4. Scheduling Collections
-
- This specification introduces new collection resource types that are
- used to manage scheduling object resources, scheduling privileges as
- well as provide scheduling functionality.
-
-4.1. Scheduling Outbox Collection
-
- A scheduling Outbox collection is used as the target for busy time
- information requests.
-
- A scheduling Outbox collection MUST report the DAV:collection and
- CALDAV:schedule-outbox XML elements in the value of the DAV:
- resourcetype property. The element type declaration for CALDAV:
- schedule-outbox is:
-
- <!ELEMENT schedule-outbox EMPTY>
-
- Example:
-
- <D:resourcetype xmlns:D="DAV:">
- <D:collection/>
- <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
- </D:resourcetype>
-
- New WebDAV ACL [RFC3744] privileges can be set on the scheduling
- Outbox collection to control who is allowed to send scheduling
- messages on behalf of the Calendar User associated with the
- scheduling Outbox collection. See Section 13.1 for more details.
-
- A scheduling Outbox collection MUST NOT be a child (at any depth) of
- a calendar collection resource.
-
- The following WebDAV properties specified in CalDAV "calendar-access"
- [RFC4791] MAY also be defined on scheduling Outbox collections:
-
- CALDAV:supported-calendar-component-set - when present this
- indicates the allowed calendar component types for scheduling
- messages submitted to the scheduling Outbox collection with the
- POST method.
-
- CALDAV:supported-calendar-data - when present this indicates the
- allowed media types for scheduling messages submitted to the
- scheduling Outbox collection with the POST method.
-
- CALDAV:max-resource-size - when present this indicates the maximum
- size of a resource in octets that the server is willing to accept
- for scheduling messages submitted to the scheduling Outbox
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 13]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- collection with the POST method.
-
- CALDAV:min-date-time - when present this indicates the earliest
- date and time (in UTC) that the server is willing to accept for
- any DATE or DATE-TIME value in scheduling messages submitted to
- the scheduling Outbox collection with the POST method.
-
- CALDAV:max-date-time - when present this indicates the latest date
- and time (in UTC) that the server is willing to accept for any
- DATE or DATE-TIME value in scheduling messages submitted to the
- scheduling Outbox collection with the POST method.
-
- CALDAV:max-instances - when present this indicates the maximum
- number of recurrence instances in scheduling messages submitted to
- the scheduling Outbox collection with the POST method.
-
- CALDAV:max-attendees-per-instance - when present this indicates
- the maximum number of ATTENDEE properties in any instance of
- scheduling messages submitted to the scheduling Outbox collection
- with the POST method.
-
- While there is currently no defined use for child resources in a
- scheduling Outbox collection, a scheduling Outbox collection MAY
- contain child resources.
-
-4.2. Scheduling Inbox Collection
-
- A scheduling Inbox collection contains copies of incoming scheduling
- messages. These may be requests sent by an Organizer, or replies
- sent by an Attendee in response to a request.
-
- A scheduling Inbox collection MUST report the DAV:collection and
- CALDAV:schedule-inbox XML elements in the value of the DAV:
- resourcetype property. The element type declaration for CALDAV:
- schedule-inbox is:
-
- <!ELEMENT schedule-inbox EMPTY>
-
- Example:
-
- <D:resourcetype xmlns:D="DAV:">
- <D:collection/>
- <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
- </D:resourcetype>
-
- Scheduling Inbox collections MUST only contain calendar object
- resources that obey the restrictions specified in iTIP
- [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 14]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- collections MUST NOT contain any types of collection resources.
- Restrictions defined in Section 4.1 of CalDAV "calendar-access"
- [RFC4791] on calendar object resources contained in calendar
- collections (e.g., "UID" uniqueness) don't apply to calendar object
- resources contained in a scheduling Inbox collection. Multiple
- calendar object resources contained in a scheduling Inbox collection
- MAY have the same "UID" property value (i.e., multiple scheduling
- messages for the same calendar component).
-
- New WebDAV ACL [RFC3744] privileges can be set on the scheduling
- Inbox collection to control who the Calendar User associated with the
- scheduling Inbox collection will accept scheduling messages from.
- See Section 13.1 for more details.
-
- A scheduling Inbox collection MUST NOT be a child (at any depth) of a
- calendar collection resource.
-
- The following WebDAV properties specified in CalDAV "calendar-access"
- [RFC4791] MAY also be defined on scheduling Inbox collections:
-
- CALDAV:calendar-timezone - when present this contains a time zone
- that the server can use when calendar date-time operations are
- carried out, for example when a time-range CALDAV:calendar-query
- REPORT is targeted at a scheduling Inbox collection.
-
- CALDAV:supported-calendar-component-set - when present this
- indicates the allowed calendar component types for scheduling
- messages delivered to the scheduling Inbox collection.
-
- CALDAV:supported-calendar-data - when present this indicates the
- allowed media types for scheduling messages delivered to the
- scheduling Inbox collection.
-
- CALDAV:max-resource-size - when present this indicates the maximum
- size of a resource in octets that the server is willing to accept
- for scheduling messages delivered to the scheduling Inbox
- collection.
-
- CALDAV:min-date-time - when present this indicates the earliest
- date and time (in UTC) that the server is willing to accept for
- any DATE or DATE-TIME value in scheduling messages delivered to
- the scheduling Inbox collection.
-
- CALDAV:max-date-time - when present this indicates the latest date
- and time (in UTC) that the server is willing to accept for any
- DATE or DATE-TIME value in scheduling messages delivered to the
- scheduling Inbox collection.
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 15]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- CALDAV:max-instances - when present this indicates the maximum
- number of recurrence instances in scheduling messages delivered to
- the scheduling Inbox collection.
-
- CALDAV:max-attendees-per-instance - when present this indicates
- the maximum number of ATTENDEE properties in any instance of
- scheduling messages delivered to the scheduling Inbox collection.
-
-4.3. Calendaring Reports Extensions
-
- This specification extends the CALDAV:calendar-query and CALDAV:
- calendar-multiget REPORTs to return results for calendar object
- resources in scheduling Inbox collections when the report directly
- targets such a collection. That is, the Request-URI for a report
- MUST be the URI of the scheduling Inbox collection or of a child
- resource within a scheduling Inbox collection. A report run on a
- regular collection that includes a scheduling Inbox collection as a
- child resource at any depth MUST NOT examine or return any calendar
- object resources from within any scheduling Inbox collections.
-
- When a CALDAV:calendar-query REPORT includes a time-range query and
- targets a scheduling Inbox collection, if any calendar object
- resources contain "VEVENT" calendar components that do not include a
- "DTSTART" iCalendar property (as allowed by iTIP
- [I-D.ietf-calsify-2446bis]) then such components MUST always match
- the time-range query test.
-
- Note that the CALDAV:free-busy-query REPORT is not supported on
- scheduling Inbox collections.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 16]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-5. Scheduling Transactions
-
- When a calendar object resource is created, modified or removed from
- a calendar collection (either via a PUT, DELETE, COPY or MOVE HTTP
- request), the server examines the calendar data and checks to see
- whether the data represents a scheduling object resource. If it
- does, the server will automatically attempt to deliver a scheduling
- message to the appropriate Calendar Users. Several types of
- scheduling operation can occur in this case, equivalent to iTIP
- "REQUEST", "REPLY", "CANCEL", and "ADD" operations.
-
-5.1. Identifying Scheduling Object Resources
-
- Calendar object resources on which the server performs automatic
- scheduling transactons are refered to as scheduling object resources.
- There are two types of scheduling object resources: organizer
- scheduling object resources, and attendee scheduling object
- resources.
-
- A calendar object resource is considered to be a valid organizer
- scheduling object resource if the "ORGANIZER" iCalendar property is
- present and set in all the calendar components to a value that
- matches one of the calendar user addresses of the owner of the
- calendar collection.
-
- A calendar object resource is considered to be a valid attendee
- scheduling object resource if the "ORGANIZER" iCalendar property is
- present and set in all the calendar components to the same value and
- doesn't match one of the calendar user addresses of the owner of the
- calendar collection, and that at least one of the "ATTENDEE"
- iCalendar property values match one of the calendar user addresses of
- the owner of the calendar collection.
-
- The creation of attendee scheduling object resources is typically
- done by the server, with the resource being stored in an appropriate
- calendar collection.
-
-5.2. Handling Scheduling Object Resources
-
- The server's behavior when processing a scheduling object resource
- depends on whether it is owned by the Organizer or an Attendee
- specified in the calendar data.
-
-5.2.1. Organizer Scheduling Object Resources
-
- An Organizer can create, modify or remove a scheduling object
- resource by issuing HTTP requests with an appropriate method. The
- create, modify and remove behaviors for the server are each described
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 17]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- next, and the way these are invoked via HTTP requests is described in
- Section 5.2.3.
-
-5.2.1.1. Create
-
- When a scheduling object resource is created by the Organizer, the
- server will inspect each "ATTENDEE" property to determine if a
- scheduling message should be delivered to this Attendee according to
- the value of the "SCHEDULE-AGENT" property parameter (see
- Section 10.1) as described in the table below:
-
- +------------------+-------------+
- | SCHEDULE-AGENT | iTIP METHOD |
- +==================+=============+
- | SERVER (default) | REQUEST |
- +------------------+-------------+
- | CLIENT | -- |
- +------------------+-------------+
- | NONE | -- |
- +------------------+-------------+
-
- The attempt to deliver the scheduling message will either succeed or
- fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
- iCalendar property in the scheduling object resource being created,
- and set its value as described in Section 9.2. This will result in
- the created calendar object resource differing from the calendar data
- sent in the HTTP request. As a result clients MAY reload the
- calendar data from the server as soon as it is created on the server
- in order to update to the new server generated state information.
- Servers MUST NOT set the "SCHEDULE-STATUS" property parameter on the
- "ATTENDEE" property of Attendees for which it did not attempt to
- deliver a scheduling message.
-
- Restrictions:
-
- 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar
- property parameter value of the "ATTENDEE" iCalendar property of
- other users in the calendar object resource to a value other than
- "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value
- is not present or set to the value "SERVER". To maintain
- consistency across Organizers and Attendees, a server will
- typically choose to enforce the requirement that only an Attendee
- can change their own "PARTSTAT" to a value other than "NEEDS-
- ACTION".
-
- 2. The server MAY reject attempts to create a scheduling object
- resource that specifies a "UID" property value already specified
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 18]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- in a scheduling object resource contained in another calendar
- collection of the Organizer.
-
- 3. The server MUST take into account scheduling privileges as
- described in Section 13.1 when handling the creation of a
- scheduling object resource.
-
- 4. Restrictions on calendar object resources defined in Section 4.1
- of [RFC4791] MUST also be enforced.
-
-5.2.1.2. Modify
-
- When a scheduling object resource is modified by the Organizer, the
- server will inspect each "ATTENDEE" property in the new calendar data
- to determine which ones have the "SCHEDULE-AGENT" iCalendar property
- parameter. It will then need to compare this with the "ATTENDEE"
- properties in the existing calendar object resource that is being
- modified.
-
- For each Attendee in the old and new calendar data on a per-instance
- basis, and taking into account the addition or removal of Attendees,
- the server will determine whether to deliver a scheduling message to
- the Attendee. The following table determines whether the server
- needs to deliver a scheduling message, and if so which iTIP
- scheduling method to use. The values "SERVER", "CLIENT", and "NONE"
- in the top and left titles of the table refer to the "SCHEDULE-AGENT"
- parameter value of the "ATTENDEE" property, and the values "<Absent>"
- and "<Removed>" are used to cover the cases where the "ATTENDEE"
- property is not present (Old) or is being removed (New).
-
- +---------------+-----------------------------------------------+
- | | New |
- | ATTENDEE +-----------+-----------+-----------+-----------+
- | | <Removed> | SERVER | CLIENT | NONE |
- | | | (default) | | |
- +===+===========+===========+===========+===========+===========+
- | | <Absent> | -- | REQUEST / | -- | -- |
- | | | | ADD | | |
- | +-----------+-----------+-----------+-----------+-----------+
- | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL |
- | O | (default) | | | | |
- | l +-----------+-----------+-----------+-----------+-----------+
- | d | CLIENT | -- | REQUEST / | -- | -- |
- | | | | ADD | | |
- | +-----------+-----------+-----------+-----------+-----------+
- | | NONE | -- | REQUEST / | -- | -- |
- | | | | ADD | | |
- +---+-----------+-----------+-----------+-----------+-----------+
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 19]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- The attempt to deliver the scheduling message will either succeed or
- fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter to the "ATTENDEE" iCalendar property in
- the scheduling object resource being modified, and set its value as
- described in Section 9.2. This will result in the created calendar
- object resource differing from the calendar data sent in the HTTP
- request. As a result clients MAY reload the calendar data from the
- server as soon as it is modified on the server in order to update to
- the new server generated state information.
-
- Restrictions:
-
- 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar
- property parameter value of the "ATTENDEE" iCalendar property of
- other users in the calendar object resource to a value other than
- "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value
- is not present or set to the value "SERVER". To maintain
- consistency for Organizers and Attendees, a server will typically
- choose to enforce the requirement that only an Attendee can
- change their own "PARTSTAT" to a value other than "NEEDS-ACTION".
-
- 2. The server MUST take into account scheduling privileges as
- described in Section 13.1 when handling the modification of a
- scheduling object resource.
-
- 3. Restrictions on calendar object resources defined in Section 4.1
- of [RFC4791] MUST also be enforced.
-
-5.2.1.3. Remove
-
- When a scheduling object resource is removed by the Organizer, the
- server will inspect each "ATTENDEE" property in the scheduling object
- resource being removed to determine which ones have the "SCHEDULE-
- AGENT" iCalendar property parameter.
-
- For each Attendee the server will determine whether to attempt to
- deliver a scheduling message into the Attendee's scheduling Inbox
- collection, based on the table below:
-
- +------------------+-------------+
- | SCHEDULE-AGENT | iTIP METHOD |
- +==================+=============+
- | SERVER (default) | CANCEL |
- +------------------+-------------+
- | CLIENT | -- |
- +------------------+-------------+
- | NONE | -- |
- +------------------+-------------+
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 20]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Restrictions:
-
- 1. The server MUST take into account scheduling privileges as
- described in Section 13.1 when handling the deletion of a
- scheduling object resource.
-
-5.2.2. Attendee Scheduling Object Resources
-
- An Attendee can create, modify or remove a scheduling object resource
- by issuing HTTP requests with an appropriate method. The create,
- modify and remove behaviors for the server are each described next,
- and the way these are invoked via HTTP requests is described in
- Section 5.2.3.
-
-5.2.2.1. Allowed Attendee Changes
-
- Attendees are allowed to make some changes to a scheduling object
- resource, though key properties such as start time, end time,
- location, and summary are typically under the control of the
- Organizer.
-
- The server MUST allow Attendees to:
-
- 1. change their own "PARTSTAT" iCalendar property parameter value.
-
- 2. add, modify or remove any "TRANSP" iCalendar properties.
-
- 3. add, modify or remove any "PERCENT-COMPLETE" iCalendar
- properties.
-
- 4. add, modify or remove any "VALARM" iCalendar components.
-
- 5. add, modify or remove the "CALSCALE" iCalendar property within
- the top-level "VCALENDAR" component.
-
- 6. modify the "PRODID" iCalendar property within the top-level
- "VCALENDAR" component.
-
- 7. add "EXDATE" iCalendar properties and possibly remove components
- for overridden recurrence instances.
-
- 8. add, modify or remove any "CREATED", "DTSTAMP" and "LAST-
- MODIFIED" iCalendar properties.
-
- 9. add new components to represent overridden recurrence instances,
- provided the only changes to the recurrence instance follow the
- rules above.
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 21]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-5.2.2.2. Create
-
- Typically an Attendee does not create scheduling object resources, as
- scheduling messages delivered to them on the server are automatically
- processed by the server and placed on one of their calendars (see
- Section 6). However, in some cases a scheduling message may get
- delivered directly to the client, and the Attendee may wish to store
- that on the server. In that case the client creates a scheduling
- object resource in a suitable calendar belonging to the Attendee.
- Once stored, it is then subject to the usual rules for attendee
- scheduling object resources.
-
- In some cases a server may not be able to process an Attendee
- scheduling object resource that originated from another system (i.e.,
- where the server is unable to deliver scheduling messages to the
- Organizer). In such cases the server MUST add a "SCHEDULE-AGENT"
- iCalendar property parameter to all "ORGANIZER" iCalendar properties
- in the resource and set the value of each to "NONE". The server MAY
- reject any attempt by the client to remove the "SCHEDULE-AGENT"
- property parameter or change its value.
-
-5.2.2.3. Modify
-
- When a scheduling object resource is modified by an Attendee, the
- server will inspect the changes by comparing it with the existing
- scheduling object resource being replaced.
-
- If the Attendee changes one or more "PARTSTAT" iCalendar property
- values on any component, or adds an overridden component with a
- changed "PARTSTAT" property, then the server MUST deliver an iTIP
- "REPLY" scheduling message to the Organizer to indicate the new
- participation status of the Attendee.
-
- The attempt to deliver the scheduling message will either succeed or
- fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter to the "ORGANIZER" iCalendar property in
- the scheduling object resource being created, and set its value as
- described in Section 9.2. This will result in the created calendar
- object resource differing from the calendar data sent in the HTTP
- request. As a result clients MAY reload the calendar data from the
- server as soon as it is stored in order to update to the new server
- generated state information.
-
-5.2.2.4. Remove
-
- When a scheduling object resource is removed by the Attendee, one of
- two possibilities exist:
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 22]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- 1. If the HTTP request contains a "Schedule-Reply" request header
- set to the value "T" or there is no "Schedule-Reply" request
- header, then the server MUST attempt to deliver a scheduling
- message to the Organizer indicating that the Attendee has a
- "PARTSTAT" iCalendar property parameter value set to "DECLINED".
- That is, the Attendee has chosen not to attend any instances. If
- the server is unable to deliver the scheduling message, the
- remove action MUST fail, and an appropriate "SCHEDULE-STATUS"
- iCalendar property parameter set on the "ORGANIZER" property in
- the scheduling object resource stored by the server.
-
- 2. If the HTTP request contains a request header "Schedule-Reply"
- set to the value "F", the server MUST NOT attempt to deliver a
- scheduling message. The resource is simply removed. This
- provides the client a way to silently remove unwanted scheduling
- attempts.
-
-5.2.3. HTTP Methods
-
- This section describes how use of various HTTP methods on a
- scheduling object resource will cause a create, modify or remove
- action on that resource as described above. The use of these methods
- is subject to the restrictions in [RFC4791], in addition to what is
- described below.
-
-5.2.3.1. PUT
-
- When a PUT method request is received, the server will execute the
- following actions, provided all appropriate preconditions are met:
-
- +--------------------------+--------------------------+-------------+
- | Existing Destination | Resulting Destination | Server |
- | Resource | Resource | Action |
- +--------------------------+--------------------------+-------------+
- | None | Calendar object resource | None |
- | | | |
- | None | Scheduling object | Create |
- | | resource | |
- | | | |
- | Calendar object resource | Calendar object resource | None |
- | | | |
- | Calendar object resource | Scheduling object | Create |
- | | resource | |
- | | | |
- | Scheduling object | Calendar object resource | Remove |
- | resource | | |
- | | | |
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 23]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- | Scheduling object | Scheduling object | Modify |
- | resource | resource | |
- +--------------------------+--------------------------+-------------+
-
-5.2.3.2. COPY
-
- When a COPY method request is received, the server will execute the
- following actions based on the source and destination collections in
- the request:
-
- +-------------------------+-------------------------+---------------+
- | Source Collection | Destination Collection | Server Action |
- +-------------------------+-------------------------+---------------+
- | Non-calendar collection | Non-calendar collection | None |
- | | | |
- | Non-calendar collection | Calendar collection | (1) |
- | | | |
- | Calendar collection | Non-calendar collection | None |
- | | | |
- | Calendar collection | Calendar collection | None |
- +-------------------------+-------------------------+---------------+
-
- Note 1. The same rules as used for PUT above are applied for the
- destination of the COPY request.
-
-5.2.3.3. MOVE
-
- When a MOVE method request is received, the server will execute the
- following actions based on the source and destination collections in
- the request:
-
- +-------------------------+-------------------------+---------------+
- | Source Collection | Destination Collection | Server Action |
- +-------------------------+-------------------------+---------------+
- | Non-calendar collection | Non-calendar collection | None |
- | | | |
- | Non-calendar collection | Calendar collection | (1) |
- | | | |
- | Calendar collection | Non-calendar collection | (2) |
- | | | |
- | Calendar collection | Calendar collection | None |
- +-------------------------+-------------------------+---------------+
-
- Note 1. The same rules as used for PUT above are applied for the
- destination of the MOVE request.
-
- Note 2. The same rules as used for DELETE below are applied for the
- source of the MOVE request.
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 24]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-5.2.3.4. DELETE
-
- When a DELETE method is targeted at a scheduling object resource the
- server will execute the Remove action.
-
- When a DELETE method is targeted at a calendar collection the server
- will execute the Remove action on all scheduling object resources
- contained in the calendar collection.
-
-5.2.4. Additional Method Preconditions
-
- This specification defines additional method preconditions (see
- Section 16 of WebDAV [RFC4918]) to provide machine-parsable
- information in error responses.
-
-5.2.4.1. CALDAV:unique-scheduling-object-resource Precondition
-
- Name: unique-scheduling-object-resource
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 409 Conflict
-
- Purpose: (precondition) -- Servers MAY reject requests to create a
- scheduling object resource with an iCalendar "UID" property value
- already in use by another scheduling object resource owned by the
- same user in other calendar collections. Servers SHOULD report
- the URL of the scheduling object resource that is already making
- use of the same "UID" property value in the DAV:href element.
-
- Definition:
-
- <!ELEMENT unique-scheduling-object-resource (DAV:href?)>
-
- Example:
-
- <C:unique-scheduling-object-resource xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>/home/bernard/calendars/personal/abc123.ics</D:href>
- </C:unique-scheduling-object-resource>
-
-5.2.4.2. CALDAV:same-organizer-in-all-components Precondition
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 25]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Name: same-organizer-in-all-components
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 409 Conflict
-
- Purpose: (precondition) -- All the calendar components in a
- scheduling object resource MUST contain the same "ORGANIZER"
- property value when present.
-
- Definition:
-
- <!ELEMENT same-organizer-in-all-components EMPTY>
-
- Example:
-
- <C:same-organizer-in-all-components
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-5.2.4.3. CALDAV:allowed-organizer-scheduling-object-change Precondition
-
- Name: allowed-organizer-scheduling-object-change
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 409 Conflict
-
- Purpose: (precondition) -- Servers MAY impose restrictions on
- modifications allowed by an Organizer. For instance, servers MAY
- prevent the Organizer setting the "PARTSTAT" property parameter to
- a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE"
- property has the "SCHEDULE-AGENT" property parameter set to
- "SERVER", or has no "SCHEDULE-AGENT" property parameter. See
- Section 5.2.1.
-
- Definition:
-
- <!ELEMENT allowed-organizer-scheduling-object-change EMPTY>
-
- Example:
-
- <C:allowed-organizer-scheduling-object-change
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 26]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-5.2.4.4. CALDAV:allowed-attendee-scheduling-object-change Precondition
-
- Name: allowed-attendee-scheduling-object-change
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 409 Conflict
-
- Purpose: (precondition) -- Servers MAY impose restrictions on
- modifications allowed by an Attendee. Attendee modifications that
- servers MUST allow are specified in Section 5.2.2.1.
-
- Definition:
-
- <!ELEMENT allowed-attendee-scheduling-object-change EMPTY>
-
- Example:
-
- <C:allowed-attendee-scheduling-object-change
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-5.2.5. DTSTAMP and SEQUENCE Properties
-
- Whenever the server generates a scheduling message for delivery to a
- Calendar User, it MUST ensure that a "DTSTAMP" iCalendar property is
- present and MUST set the value to the UTC time that the scheduling
- message was generated (as required by iCalendar).
-
- iTIP [I-D.ietf-calsify-2446bis] places certain requirements on how
- the "SEQUENCE" iCalendar property value in scheduling messages
- changes. The server MUST ensure that for each type of scheduling
- operation, the "SEQUENCE" iCalendar property value is appropriately
- updated. If the client does not update the "SEQUENCE" iCalendar
- property itself when that is required, the server MUST update the
- property.
-
-5.2.6. Limit Recurrence Instances Sent to Attendees
-
- When delivering scheduling messages for recurring calendar components
- to Attendees, servers MUST ensure that Attendees only get information
- about recurrence instances that explicitly include them as an
- Attendee.
-
- For example, if an Attendee is invited to a single recurrence
- instance of a recurring event, and no others, the scheduling object
- resource contained in the Organizer's calendar collection will
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 27]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- contain an overridden instance in the form of a separate calendar
- component. That separate calendar component will include the
- "ATTENDEE" property referencing the "one-off" Attendee. That
- Attendee will not be listed in any other calendar components in the
- scheduling object resource. The scheduling message that will be
- delivered to the Attendee will only contain information about this
- overridden instance.
-
- As another example, an Attendee could be excluded from one instance
- of a recurring event. In that case the scheduling object resource
- contained in the calendar collection of the Organizer will include an
- overridden instance with an "ATTENDEE" list that does not include the
- Attendee being excluded. The scheduling message that will be
- delivered to the Attendee will not specify the overridden instance
- but rather include an "EXDATE" property in the master recurring
- component defining the recurrence set.
-
-5.2.7. Forcing the Server to Send a Scheduling Message
-
- The iCalendar property parameter "SCHEDULE-FORCE-SEND" defined in
- Section 10.2 can be used by a Calendar User to force the server to
- send a scheduling message to an Attendee or the Organizer in a
- situation where the server would not normally send a scheduling
- message. For instance, an Organizer could use this property
- parameter to request an Attendee, that previously declined an
- invitation, to reconsider their participation status without being
- forced to modify the event.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 28]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-6. Processing Incoming Scheduling Messages
-
- Scheduling operations can cause the delivery of a scheduling message
- into an Organizer's or Attendee's scheduling Inbox collection. In
- the former case the scheduling messages are replies from Attendees,
- in the latter case the scheduling messages are requests,
- cancellations or additions from the Organizer.
-
- The server will automatically process incoming scheduling messages
- and make them available in the scheduling Inbox collection as an
- indicator to the client that a scheduling operation has taken place.
-
- The server MUST take into account privileges on the scheduling Inbox
- collection, when processing incoming scheduling messages, to
- determine whether delivery of the scheduling message is allowed.
- Privileges on calendars containing any matching scheduling object
- resource are not considered in this case. Additionally, servers MUST
- take into account any scheduling Inbox collection preconditions (see
- Section 4.2) when delivering the scheduling message, and it MUST take
- into account the similar preconditions on any calendar collection
- which contains, or would contain, the corresponding scheduling object
- resource.
-
-6.1. Processing Attendee Replies
-
- For a scheduling message reply sent by an Attendee, the server first
- locates the corresponding scheduling object resource belonging to the
- Organizer.
-
- The server MUST then update the "PARTSTAT" iCalendar property
- parameter value of each "ATTENDEE" iCalendar property in the
- scheduling object resource to match the changes indicated in the
- reply (taking into account the fact that an Attendee could have
- created a new overridden iCalendar component to indicate different
- participation status on one or more recurrence instances of a
- recurring event).
-
- The server MUST also update or add the "SCHEDULE-STATUS" property
- parameter on each matching "ATTENDEE" iCalendar property and sets its
- value to that of the "REQUEST-STATUS" property in the reply, or to
- "2.0" if "REQUEST-STATUS" is not present (also taking into account
- recurrence instances). If there are multiple "REQUEST-STATUS"
- properties in the reply, the "SCHEDULE-STATUS" property parameter
- value is set to a comma-separated list of status codes, one from each
- "REQUEST-STATUS" property.
-
- The server SHOULD send scheduling messages to all the other Attendees
- indicating the change in participation status of the Attendee
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 29]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- replying, subject to the recurrence requirements of Section 5.2.6.
-
- In this case, the scheduling message MUST only appear in the
- Organizer's scheduling Inbox collection once all automatic processing
- has been done.
-
-6.2. Processing Organizer Requests, Additions, and Cancellations
-
- For a scheduling message sent by an Organizer, the server first tries
- to locate a corresponding scheduling object resource belonging to the
- Attendee. If no matching scheduling object resource exists, the
- server treats the scheduling message as a new message, otherwise it
- is treated as an update.
-
- In the case of a new message, the server MUST process the scheduling
- message and create a new scheduling object resource in an appropriate
- calendar collection for the Attendee.
-
- In the case of an update, the server MUST process the scheduling
- message and update the matching scheduling object resource belonging
- to the Attendee to reflect the changes sent by the Organizer.
-
- In any case, the scheduling message MUST only appear in the
- Attendee's scheduling Inbox collection once all automatic processing
- has been done.
-
-6.3. Default Calendar Collection
-
- The server is REQUIRED to process scheduling messages that specify a
- request for a new calendar component received for an Attendee by
- creating a new scheduling object resource in a calendar collection
- belonging to the Attendee. A Calendar User who can participate as an
- Attendee in a scheduling operation MUST have at least one valid
- calendar collection available. If there is no valid calendar
- collection, then the server MUST reject the attempt to deliver the
- scheduling message to the Attendee.
-
- Servers MAY provide support for a default calendar collection, that
- is, the calendar collection in which new scheduling object resources
- will be created on reception of scheduling messages that specify a
- request for a new calendar component. The CALDAV:schedule-default-
- calendar-URL WebDAV property, which MAY be defined on the scheduling
- Inbox collection of a Calendar User, specifies if this Calendar User
- has a default calendar collection. See Section 12.2.
-
- Servers MUST create new scheduling object resources in the default
- calendar collection, if the CALDAV:schedule-default-calendar-URL
- WebDAV property is set.
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 30]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Servers MAY allow clients to change the default calendar collection
- by changing the value of the CALDAV:schedule-default-calendar-URL
- WebDAV property on the scheduling Inbox collection. However, they
- MUST ensure that any new value stored for that property refers to a
- valid calendar collection belonging to the owner of the scheduling
- inbox collection.
-
- Servers MUST reject any attempt to delete the default calendar
- collection.
-
-6.3.1. Additional Method Preconditions
-
- This specification defines additional method preconditions (see
- Section 16 of WebDAV [RFC4918]) to provide machine-parsable
- information in error responses.
-
-6.3.1.1. CALDAV:default-calendar-delete-allowed Precondition
-
- Name: default-calendar-delete-allowed
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: DELETE
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The client attempted to delete the
- calendar collection currently referenced by the CALDAV:schedule-
- default-calendar-URL property, or attempted to remove the CALDAV:
- schedule-default-calendar-URL property on the scheduling Inbox
- collection on a server that doesn't allow such operations.
-
- Definition:
-
- <!ELEMENT default-calendar-delete-allowed EMPTY>
-
- Example:
-
- <C:default-calendar-delete-allowed
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-6.3.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition
-
- Name: valid-schedule-default-calendar-URL
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 31]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PROPPATCH
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The client attempted to set the CALDAV:
- schedule-default-calendar-URL property to a DAV:href element that
- doesn't reference a valid calendar collection. Note: Servers that
- don't allow clients to change the CALDAV:schedule-default-
- calendar-URL property would simply return the DAV:cannot-modify-
- protected-property precondition defined in Section 16 of WebDAV
- [RFC4918].
-
- Definition:
-
- <!ELEMENT valid-schedule-default-calendar-URL EMPTY>
-
- Example:
-
- <C:valid-schedule-default-calendar-URL
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-6.4. Scheduling Messages as Notifications
-
- Once the processing of an incoming scheduling message is completed by
- the server, the message is made available as a child resource in the
- scheduling Inbox collection of the Calendar User that received the
- message, to serve as a notification that a change has been made to
- the corresponding scheduling object resource. Scheduling messages
- are typically removed from the scheduling Inbox collection by the
- client once it has acknowledged the change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 32]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-7. Request for Busy Time Information
-
- The POST method is used to request busy time information of one or
- more Calendar Users by targeting the request at a scheduling Outbox
- collection. The request body of a POST method MUST contain a
- "VFREEBUSY" calendar compoment with the "METHOD" iCalendar property
- set to the value "REQUEST" as specified in Section 3.3.2 of iTIP
- [I-D.ietf-calsify-2446bis]. The resource identified by the Request-
- URI MUST be a resource collection of type CALDAV:schedule-outbox
- (Section 4.1).
-
-7.1. Status Codes
-
- The following are examples of response codes one would expect to be
- used for this method. Note, however, that unless explicitly
- prohibited any 2/3/4/5xx series response code may be used in a
- response.
-
- 200 (OK) - The command succeeded.
-
- 204 (No Content) - The command succeeded.
-
- 400 (Bad Request) - The client has provided an invalid scheduling
- message.
-
- 403 (Forbidden) - The client cannot submit a scheduling message to
- the specified Request-URI.
-
- 404 (Not Found) - The URL in the Request-URI was not present.
-
- 423 (Locked) - The specified resource is locked and the client
- either is not a lock owner or the lock type requires a lock token
- to be submitted and the client did not submit it.
-
-7.2. Additional Method Preconditions
-
- This specification defines additional method preconditions for the
- POST method. Preconditions defined in WebDAV ACL [RFC3744] and
- CalDAV [RFC4791] that applies to the POST method are also listed here
- for completeness.
-
-7.2.1. DAV:need-privileges Precondition
-
- Name: need-privileges
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 33]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Namespace: DAV:
-
- Apply to: POST
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The currently authenticated user MUST be
- granted the CALDAV:schedule-send or CALDAV:schedule-send-freebusy
- privilege on the scheduling Outbox collection being targeted by
- the request.
-
- Definition:
-
- <!ELEMENT DAV:need-privileges (DAV:resource)* >
- <!ELEMENT DAV:resource (DAV:href, DAV:privilege) >
-
- Example:
-
- <D:need-privileges xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
- <D:resource>
- <D:href>/home/bernard/calendars/outbox/</D:href>
- <D:privilege><C:schedule-send-freebusy/></D:privilege>
- </D:resource>
- </D:need-privileges>
-
-7.2.2. CALDAV:supported-collection Precondition
-
- Name: supported-collection
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The Request-URI MUST identify the
- location of a scheduling Outbox collection.
-
- Definition:
-
- <!ELEMENT supported-collection EMPTY >
-
- Example:
-
- <C:supported-collection xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 34]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-7.2.3. CALDAV:supported-calendar-data Precondition
-
- Name: supported-calendar-data
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The resource body submitted in the POST
- request MUST be a supported media type (e.g., text/calendar).
-
- Definition:
-
- <!ELEMENT supported-calendar-data EMPTY >
-
- Example:
-
- <C:supported-calendar-data
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-7.2.4. CALDAV:valid-calendar-data Precondition
-
- Name: valid-calendar-data
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The resource submitted in the POST
- request MUST be valid data for the media type being specified
- (e.g., a valid iCalendar object).
-
- Definition:
-
- <!ELEMENT valid-calendar-data EMPTY>
-
- Example:
-
- <C:valid-calendar-data xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 35]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-7.2.5. CALDAV:valid-scheduling-message Precondition
-
- Name: valid-scheduling-message
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The resource submitted in the POST
- request MUST obey all restrictions specified for the POST request
- (e.g., the scheduling message follow the restrictions of iTIP).
-
- Definition:
-
- <!ELEMENT valid-scheduling-message EMPTY >
-
- Example:
-
- <C:valid-scheduling-message
- xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-7.2.6. CALDAV:organizer-allowed Precondition
-
- Name: organizer-allowed
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 409 Conflict
-
- Purpose: (precondition) -- The Calendar User identified by the
- "ORGANIZER" property in the POST request's scheduling message MUST
- be the Calendar User (or one of the Calendar Users) associated
- with the scheduling Outbox collection being targeted by the
- request;
-
- Definition:
-
- <!ELEMENT organizer-allowed EMPTY >
-
- Example:
-
- <C:organizer-allowed xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 36]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-7.2.7. CALDAV:max-resource-size Precondition
-
- Name: max-resource-size
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The resource submitted in the POST
- request MUST have an octet size less than or equal to the value of
- the CALDAV:max-resource-size property (defined in Section 5.2.5 of
- [RFC4791]) specified on the scheduling Outbox collection targeted
- by the request.
-
- Definition:
-
- <!ELEMENT max-resource-size EMPTY >
-
- Example:
-
- <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-
-7.3. Response to a POST request
-
- A POST request may deliver a scheduling message to one or more
- Calendar Users. Since the behavior of each recipient may vary, it is
- useful to get response status information for each recipient in the
- overall POST response. This specification defines a new XML response
- to convey multiple recipient status.
-
- A response to a POST method that indicates status for one or more
- recipients MUST be a CALDAV:schedule-response XML element. This MUST
- contain one or more CALDAV:response elements for each recipient, with
- each of those containing elements that indicate which recipient they
- correspond to, the scheduling status for that recipient, any error
- codes and an optional description. See Section 14.1.
-
- In the case of a freebusy request, the CALDAV:response elements can
- also contain CALDAV:calendar-data elements which contain freebusy
- information (e.g., an iCalendar VFREEBUSY component) indicating the
- busy state of the corresponding recipient, assuming that the freebusy
- request for that recipient succeeded. See Appendix B.5 for an
- example freebusy request and response.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 37]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-8. Conditional Requests on Scheduling Object Resources
-
- Because replies from Attendees and updates from Organizers are
- automatically processed by the server, clients might be in a
- situation where their copy of a calendar resource is different from
- the one currently on the server. When an Attendee or Organizer makes
- a change to the client's copy of the calendar resource, if the client
- writes the data to the server it could overwrite the changes already
- made there. Typically, HTTP clients use the ETag value and If-Match
- request header to avoid the "lost update problem".
-
- Calendar user agents can also use ETag and If-Match to avoid this
- problem. However, when doing so the client will likely have to
- resolve the differences between the new resource and the original
- one, and the changes made by the Attendee or Organizer in the client.
- This can be a complicated comparison particularly when recurring
- components are present.
-
- Additionally, the data on the server may change frequently as
- Attendees change their participation status, triggering updates to
- the Organizer and consequently other Attendees' copies of the
- scheduling object resource. If the ETag/If-Match behavior were used,
- clients would be forced to reconcile their cached copy of a
- scheduling object resource with the updated one on the server in
- order to attempt to write the user's changes back. This could lead
- to a race condition that can effectively result in a temporary denial
- of service when, for example, there is an event with a large Attendee
- list. A "storm" of updates will occur if Attendees all start
- responding at the same time, and this would prevent Attendees and the
- Organizer from being able to update their own copies of the
- scheduling object resource as the server copy is changing frequently.
-
- What would be preferable is having the server determine the best way
- to merge changes made on the server with changes being made by the
- client. For example, if an Attendee changes their participation
- status and triggers an update to the Organizer's copy of the event,
- but the Organizer also updates their cached copy of the event and
- attempts to write it back, rather than failing on a conditional If-
- Match when the Organizer writes their data, the server would instead
- take the changes made by the Organizer and apply the Attendee changes
- and store the result. Thus a form of "weak" ETag matching behavior
- is needed such that scheduling changes made automatically on the
- server do not invalidate the tag, so that when clients store data
- conditionally based on the tag value, the server knows it can apply
- the merge behavior.
-
- In order to do that, this specification introduces a new WebDAV
- resource property CALDAV:schedule-tag with a corresponding response
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 38]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
- header to allow client changes to be appropriately merged with server
- changes in the case where the changes on the server were the result
- of an "inconsequential" scheduling message update. An
- "inconsequential" scheduling message is one which simply updates the
- status information of Attendees due to a reply from an Attendee.
-
- Servers MUST support conditional requests targeted at scheduling
- object resources using the "If-Schedule-Tag-Match" request header.
- Consequently, the server MUST support the "Schedule-Tag" response
- header and CALDAV:schedule-tag property for scheduling object
- resources. Servers MUST automatically resolve conflicts with
- "inconsequential" changes done to scheduling object resources when
- the "If-Schedule-Tag-Match" request header is specified.
-
- The If-Schedule-Tag-Match request header applies only to the Request-
- URI, and not to the Destination of a COPY or MOVE in the same way as
- the If-Match request header.
-
- Clients SHOULD use conditional requests using the If-Schedule-Tag-
- Match request header.
-
- A response to any successful GET or PUT request targeting a
- scheduling object resource MUST include a Schedule-Tag response
- header with the value set to the same value as the CALDAV:schedule-
- tag WebDAV property of the resource.
-
- A response to any successful COPY or MOVE request that specifies a
- Destination request header targeting a scheduling object resource
- MUST include a Schedule-Tag response header with the value set to the
- same value as the CALDAV:schedule-tag WebDAV property of the resource
- identified in the Request-URI.
-
- The Schedule-Tag feature is designed to be used to address the
- problem of "inconsequential" changes on the server only. Normal ETag
- operations are used in all other cases, e.g., for synchronization.
-
- The value of the CALDAV:schedule-tag property changes according to
- these rules:
-
- o For an Organizer's copy of a scheduling object resource:
-
- 1. The server MUST NOT change the CALDAV:schedule-tag property
- value when the scheduling object resource is updated as the
- result of automatically processing a scheduling message reply
- from an Attendee. For instance, when an Attendee replies to
- the Organizer, the CALDAV:schedule-tag property is unchanged
- after the Organizer's scheduling object resource has been
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 39]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- automatically updated by the server with the Attendee's new
- participation status.
-
- 2. The server MUST change CALDAV:schedule-tag property value when
- the schedulng object resource is changed directly via an HTTP
- request (e.g., PUT, COPY or MOVE).
-
- o For an Attendee's copy of a scheduling object resource:
-
- 1. The server MUST change the CALDAV:schedule-tag property value
- when the scheduling object resource is changed as the result
- of processing a scheduling message update from an Organizer
- that contains changes other than just the participation status
- of Attendees.
-
- 2. The server MUST NOT change the CALDAV:schedule-tag property
- value when the scheduling object resource is changed as the
- result of processing a scheduling message update from an
- Organizer that only specify changes in the participation
- status of Attendees. For instance, when Attendee "A" replies
- to Organizer "O", and Attendee "B" receives a scheduling
- message update from Organizer "O" with the new participation
- status of Attendee "A", the CALDAV:schedule-tag property of
- Attendee "B"s scheduling object resource MUST NOT be changed.
-
- 3. The server MUST change the CALDAV:schedule-tag property value
- when the scheduling object resource is changed directly via an
- HTTP request (e.g., PUT, COPY or MOVE).
-
-8.1. PUT
-
- Clients can use the If-Schedule-Tag-Match request header to do a
- conditional PUT request that ensures that "inconsequential" changes
- on the server do not result in a precondition error. The value of
- the request header is set to the last Schedule-Tag value received for
- the resource being modified. If the value of the If-Schedule-Tag-
- Match header matches the current value of the CALDAV:schedule-tag
- property the server MUST take any "ATTENDEE" property changes for all
- Attendees other than the owner of the scheduling object resource and
- apply those to the new resource being stored. Otherwise, the server
- MUST fail the request with a 412 Precondition Failed status code.
-
-8.2. DELETE
-
- Clients can use the If-Schedule-Tag-Match request header to do a
- conditional DELETE request that ensures that "inconsequential"
- changes on the server do not result in a precondition error. The
- value of the request header is set to the last Schedule-Tag value
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 40]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- received for the resource being deleted. If the value of the If-
- Schedule-Tag-Match header matches the current value of the CALDAV:
- schedule-tag property the server performs the normal DELETE request
- processing for the resource. Otherwise, the server MUST fail the
- request with a 412 Precondition Failed status code.
-
-8.3. COPY or MOVE
-
- Clients can use the If-Schedule-Tag-Match request header to do
- conditional COPY or MOVE requests that ensures that "inconsequential"
- changes on the server do not result in a precondition error. The
- value of the request header is set to the last Schedule-Tag value
- received for the resource being copied or moved. If the value of the
- If-Schedule-Tag-Match header matches the current value of the CALDAV:
- schedule-tag property the server performs the normal COPY or MOVE
- request processing for the resource. Otherwise, the server MUST fail
- the request with a 412 Precondition Failed status code.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 41]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-9. Other Scheduling Considerations
-
-9.1. Attendee Participation Status
-
- This section specifies additional requirements on the handling of the
- "PARTSTAT" property parameter when the "SCHEDULE-AGENT" property
- parameter on the corresponding "ATTENDEE" property is set to the
- value "SERVER" or is not present.
-
- Clients SHOULD, and servers MUST reset the "PARTSTAT" property
- parameter value of all "ATTENDEE" properties, except the one that
- corresponds to the Organizer, to "NEEDS-ACTION" when the Organizer
- reschedules an event.
-
- A reschedule of an event occurs when any "DTSTART", "DTEND",
- "DURATION", "DUE", "RRULE", "RDATE", or "EXDATE" property changes in
- a calendar component such that existing recurrence instances are
- impacted by the changes, as shown in the table below.
-
- +----------+--------------------------------------------------------+
- | Property | Description |
- +----------+--------------------------------------------------------+
- | DTSTART | Any change to these properties MUST result in |
- | DTEND | "PARTSTAT" being set to "NEEDS-ACTION" |
- | DURATION | |
- | DUE | |
- | | |
- | | |
- | | |
- | RRULE | A change to or addition of this property that results |
- | | in the addition of new recurring instances or a change |
- | | in time for existing recurring instances MUST result |
- | | in "PARTSTAT" being reset to "NEEDS-ACTION" on each |
- | | affected component. |
- | | |
- | | |
- | | |
- | RDATE | A change to or addition of this property that results |
- | | in the addition of new recurring instances or a change |
- | | in time for existing recurring instances MUST result |
- | | in "PARTSTAT" being reset to "NEEDS-ACTION" on each |
- | | affected component. |
- | | |
- | | |
- | | |
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 42]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- | EXDATE | A change to or removal of this property that results |
- | | in the re-instatement of recurring instances MUST |
- | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on |
- | | each affected component. |
- +----------+--------------------------------------------------------+
-
- The server MAY allow the Organizer's client to change an Attendee's
- "PARTSTAT" property parameter value to "NEEDS-ACTION" at any other
- time (e.g., when the "LOCATION" property value changes, an Organizer
- might wish to re-invite Attendees who may be impacted by the change).
-
-9.2. Schedule Status Values
-
- When scheduling with an Attendee there are two types of status
- information that can be returned during the transaction. The first
- status information is a "delivery" status that indicates whether the
- scheduling message from the Organizer to the Attendee was delivered
- or not, or what the current status of delivery is. The second status
- information is a "reply" status corresponding to the Attendee's own
- "REQUEST-STATUS" information from the scheduling message reply that
- is sent back to the Organizer.
-
- Similarly, when an Attendee sends a reply back to the Organizer,
- there will be "delivery" status information for the scheduling
- message sent to the Organizer. However, there is no "REQUEST-STATUS"
- sent back by the Organizer, so there is no equivalent of the "reply"
- status as per scheduling messages to Attendees.
-
- The "delivery" status information on an "ORGANIZER" or "ATTENDEE"
- iCalendar property is conveyed in the "SCHEDULE-STATUS" property
- parameter value (Section 10.3). The status code value for "delivery"
- status can be one of the following:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 43]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- +----------+--------------------------------------------------------+
- | Delivery | Description |
- | Status | |
- | Code | |
- +----------+--------------------------------------------------------+
- | 1.0 | The scheduling message is pending. i.e. the server is |
- | | still in the process of sending the message. The |
- | | status code value can be expected to change once the |
- | | server has completed its sending and delivery |
- | | attempts. |
- | | |
- | | |
- | | |
- | 1.1 | The scheduling message has been successfully sent. |
- | | However, the server does not have explicit information |
- | | about whether the scheduling message was successfully |
- | | delivered to the recipient. This state can occur with |
- | | "store and forward" style scheduling protocols such as |
- | | iMIP [I-D.ietf-calsify-rfc2447bis] (iTIP using email). |
- | | |
- | | |
- | | |
- | 1.2 | The scheduling message has been successfully |
- | | delivered. |
- | | |
- | | |
- | | |
- | 3.7 | The scheduling message was not delivered because the |
- | | server did not recognize the calendar user address as |
- | | a valid calendar user. |
- | | |
- | | |
- | | |
- | 3.8 | The scheduling message was not delivered due to |
- | | insufficient privileges. |
- | | |
- | | |
- | | |
- | 5.1 | The scheduling message was not delivered because the |
- | | server could not complete delivery of the message. |
- | | This is likely due to a temporary failure, and the |
- | | originator can try to send the message again at a |
- | | later time. |
- | | |
- | | |
- | | |
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 44]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- | 5.2 | The scheduling message was not delivered because the |
- | | server was not able to find a suitable way to deliver |
- | | the message. This is likely a permanent failure, and |
- | | the originator should not try to send the message |
- | | again, at least without verifying/correcting the |
- | | calendar user address of the recipient. |
- | | |
- | | |
- | | |
- | 5.3 | The scheduling message was not delivered and was |
- | | rejected because scheduling with that recipient is not |
- | | allowed. This is likely a permanent failure, and the |
- | | originator should not try to send the message again. |
- +----------+--------------------------------------------------------+
-
- The status code for "reply" status can be any of the valid iTIP
- [I-D.ietf-calsify-2446bis] "REQUEST-STATUS" values.
-
-9.3. Organizer is an Attendee
-
- The Organizer of a scheduled event may also be an Attendee of that
- event. In such cases the server MUST NOT send a scheduling message
- to the Attendee that matches the Organizer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 45]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-10. Additional iCalendar Property Parameters
-
- This specification defines additional iCalendar property parameters
- to support the CalDAV scheduling extensions.
-
-10.1. Schedule Agent Parameter
-
- Parameter Name: SCHEDULE-AGENT
-
- Purpose: To specify the agent expected to deliver scheduling
- messages to the corresponding Organizer or Attendee.
-
- Format Definition: This property parameter is defined by the
- following notation:
-
- scheduleagentparam = "SCHEDULE-AGENT" "="
- ("SERVER" ; The server handles scheduling
- / "CLIENT" ; The client handles scheduling
- / "NONE" ; No automatic scheduling
- / x-name ; Experimental type
- / iana-token) ; Other IANA registered type
- ;
- ; Default is SERVER
-
- Description: This property parameter MAY be specified on "ORGANIZER"
- or "ATTENDEE" iCalendar properties. In the absence of this
- parameter, the value "SERVER" MUST be used for the default
- behavior. The value determines whether or not an automatic
- scheduling transaction on a server will cause a scheduling message
- to be sent to the corresponding Calendar User identified by the
- "ORGANIZER" or "ATTENDEE" property value. When the value "SERVER"
- is specified, or the parameter is absent, then it is the server's
- responsibility to send a scheduling message as part of an
- automatic scheduling transaction. When the value "CLIENT" is
- specified, that indicates that the client is handling scheduling
- messages with the Calendar User itself. When "NONE" is specified,
- no scheduling messages are being sent to the Calendar User.
-
- Servers MUST NOT include this parameter in any scheduling messages
- sent as the result of an automatic scheduling transaction.
-
- Clients SHOULD NOT include this parameter in any scheduling
- messages that they themselves send.
-
- Servers and clients MUST treat x-name and iana-token values they
- don't recognize the same way as they would the "NONE" value.
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 46]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Example:
-
- ATTENDEE;SCHEDULE-AGENT=SERVER:mailto:bernard at example.com
-
- ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus at example.com
-
-10.2. Schedule Force Send Parameter
-
- Parameter Name: SCHEDULE-FORCE-SEND
-
- Purpose: To force a scheduling message to be sent to the Calendar
- User specified by the property.
-
- Format Definition: This property parameter is defined by the
- following notation:
-
- scheduleforcesendparam = "SCHEDULE-FORCE-SEND" "="
- ("REQUEST" ; Force a "REQUEST"
- / "REPLY" ; Force a "REPLY"
- / iana-token) ; IANA registered method
-
- Description: This property parameter MAY be specified on "ATTENDEE"
- and "ORGANIZER" properties on which the "SCHEDULE-AGENT" property
- parameter is set to the value "SERVER" or is not specified. This
- property parameter is used to force a server to send a scheduling
- message to a specific Calendar User in situations where the server
- would not send a scheduling message otherwise (e.g., when no
- change that warrants the delivery of a new scheduling message was
- performed on the scheduling object resource). An Organizer MAY
- specify this parameter on an "ATTENDEE" property with the value
- "REQUEST" to force a "REQUEST" scheduling message to be sent to
- this Attendee. An Attendee MAY specify this parameter on the
- "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling
- message to be sent to the Organizer.
-
- Servers MUST NOT preserve this property parameter in scheduling
- object resources, nor include it in any scheduling messages sent
- as the result of an automatic scheduling transaction.
-
- Clients SHOULD NOT include this parameter in any scheduling
- messages that they themselves send.
-
- Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE"
- or "ORGANIZER" to 2.3 (i.e., "Success, invalid property parameter
- ignored", see Section 3.6 of [I-D.ietf-calsify-2446bis]) when the
- "SCHEDULE-FORCE-SEND" parameter is set to a x-name or iana-token
- value they don't recognize.
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 47]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Example:
-
- ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard at example.com
-
- ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:bernard at example.com
-
-10.3. Schedule Status Parameter
-
- Parameter Name: SCHEDULE-STATUS
-
- Purpose: To specify the status codes returned from processing of the
- most recent scheduling message sent to the corresponding Attendee,
- or received from the corresponding Organizer.
-
- Format Definition: This property parameter is defined by the
- following notation:
-
- schedulestatusparam = "SCHEDULE-STATUS" "="
- ( statcode
- / DQUOTE statcode *("," statcode) DQUOTE)
- ; "statcode" is defined in Section 3.8.8.3 of
- ; [I-D.ietf-calsify-rfc2445bis]. Value is a single
- ; "statcode" or a comma-separated list of "statcode" values.
-
- Description: This property parameter MAY be specified on the
- "ATTENDEE" and "ORGANIZER" properties.
-
- Servers MUST add this property parameter to any "ATTENDEE"
- properties corresponding to Calendar Users who were sent a
- scheduling message via an automatic scheduling transaction.
- Clients SHOULD NOT change or remove this parameter if it was
- provided by the server. In the case where the client is handling
- the scheduling, the client MAY add, change or remove this
- parameter to indicate the last scheduling message status it
- received.
-
- Servers MUST add this parameter to any "ORGANIZER" properties
- corresponding to Calendar Users who were sent a scheduling message
- reply by an Attendee via an automatic scheduling transaction.
- Clients SHOULD NOT change or remove this parameter if it was
- provided by the server. In the case where the client is handling
- the scheduling the client MAY add, change or remove this parameter
- to indicate the last scheduling message status it received.
-
- Servers MUST NOT include this parameter in any scheduling messages
- sent as the result of an automatic scheduling transaction.
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 48]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Clients SHOULD NOT include this parameter in any scheduling
- messages that they themselves send.
-
- Suitable values for this property parameter are described in
- Section 9.2.
-
- Example:
-
- ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard at example.com
-
- ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus at example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 49]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-11. Additional Message Header Fields
-
- This specification defines additional HTTP request and response
- headers for use with CalDAV.
-
-11.1. Schedule-Reply Request Header
-
-
- Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")
-
- Example:
-
- Schedule-Reply: F
-
- When an Attendee executes an HTTP DELETE request on a scheduling
- object resource, and the Schedule-Reply header is not present, or
- present and set to the value "T", the server MUST send an appropriate
- reply scheduling message with the Attendee's "PARTSTAT" iCalendar
- property parameter value set to "DECLINED" as part of its normal
- automatic scheduling transaction processing.
-
- When the Schedule-Reply header is set to the value "F", the server
- MUST NOT send a scheduling message as part of its normal automatic
- scheduling transaction processing.
-
- The Schedule-Reply request header is used by a client to indicate to
- a server whether or not an automatic scheduling transaction should
- occur when an Attendee deletes a scheduling object resource. In
- particular it controls whether a reply scheduling message is sent to
- the Organizer as a result of the deletion. There are situations in
- which unsolicited scheduling messages need to be silently deleted (or
- ignored) for security or privacy reasons. This request header allows
- the scheduling object resource to be deleted if such a need arises.
-
- All scheduling object resources MUST support the Schedule-Reply
- request header.
-
-11.2. Schedule-Tag Response Header
-
- The Schedule-Tag response header provides the current value of the
- CALDAV:schedule-tag property value. The behavior of this response
- header is described in Section 8.
-
- All scheduling object resources MUST support the Schedule-Tag header.
-
- Schedule-Tag = "Schedule-Tag" ":" opaque-tag
- ; "opaque-tag" is defined in Section 3.11 of [RFC2616]
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 50]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Example:
-
- Schedule-Tag: "12ab34-cd56ef"
-
-11.3. If-Schedule-Tag-Match Request Header
-
- The If-Schedule-Tag-Match request header field is used with a method
- to make it conditional. Clients can set this header to the value
- returned in the Schedule-Tag response header, or the CALDAV:schedule-
- tag property, of a scheduling object resource previously retrieved
- from the server to avoid overwriting "consequential" changes to the
- scheduling object resource.
-
- All scheduling object resources MUST support the If-Schedule-Tag-
- Match header.
-
- If-Schedule-Tag-Match = "If-Schedule-Tag-Match" ":" opaque-tag
- ; "opaque-tag" is defined in Section 3.11 of [RFC2616]
-
- Example:
-
- If-Schedule-Tag-Match: "12ab34-cd56ef"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 51]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-12. Additional WebDAV Properties
-
- The CalDAV scheduling extension defines the following new WebDAV
- properties for use with CalDAV.
-
-12.1. CALDAV:schedule-calendar-transp Property
-
- Name: schedule-calendar-transp
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Determines whether the calendar object resources in a
- calendar collection will affect the owner's freebusy.
-
- Protected: This property MAY be protected and SHOULD NOT be returned
- by a PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be kept during a MOVE
- operation, but is normally re-initialized when a resource is
- created with a COPY. It should not be set in a COPY.
-
- Description: This property SHOULD be defined on all calendar
- collections. If present, it contains one of two XML elements that
- indicate whether the calendar object resources in the calendar
- collection should contribute to the owner's freebusy or not. When
- the CALDAV:opaque element is used, all calendar object resources
- in the corresponding calendar collection MUST contribute to
- freebusy, assuming access privileges and other iCalendar
- properties allow it to. When the CALDAV:transparent XML element
- is used, the calendar object resources in the corresponding
- calendar collection MUST NOT contribute to freebusy.
-
- If this property is not present on a calendar collection, then the
- default value CALDAV:opaque MUST be assumed.
-
- Definition:
-
- <!ELEMENT schedule-calendar-transp (opaque | transparent) >
-
- <!ELEMENT opaque EMPTY>
- <!-- Affect busy time searches -->
-
- <!ELEMENT transparent EMPTY>
- <!-- Invisible to busy time searches -->
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 52]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Example:
-
- <C:schedule-calendar-transp
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <C:opaque/>
- </C:schedule-calendar-transp>
-
-12.2. CALDAV:schedule-default-calendar-URL Property
-
- Name: schedule-default-calendar-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Specifies a default calendar for an Attendee where new
- scheduling object resources are created.
-
- Protected: This property MAY be protected in the case where a server
- does not support changing the default calendar, or does not
- support a default calendar.
-
- COPY/MOVE behavior: This property is only defined on a scheduling
- Inbox collection which cannot be moved or copied.
-
- Description: This property MAY be defined on a scheduling Inbox
- collection. If present, it contains zero or one DAV:href XML
- elements. When a DAV:href element is present, its value indicates
- a URL to a calendar collection that is used as the default
- calendar. When no DAV:href element is present, it indicates that
- there is no default calendar. In the absence of this property
- there is no default calendar. When there is no default calendar
- the server is free to choose the calendar in which a new
- scheduling object resource is created. See Section 6.3.
-
- Definition:
-
- <!ELEMENT schedule-default-calendar-URL (DAV:href?) >
-
- Example:
-
- <C:schedule-default-calendar-URL xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>/home/cyrus/calendars/work/</D:href>
- </C:schedule-default-calendar-URL>
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 53]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-12.3. CALDAV:schedule-tag Property
-
- Name: schedule-tag
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Indicates whether a scheduling object resource has had a
- "consequential" change made to it.
-
- Value: opaque-tag (defined in Section 3.11 of [RFC2616])
-
- Protected: This property MUST be protected as only the server can
- update the value.
-
- COPY/MOVE behavior: This property is only defined on scheduling
- object resources. It MUST be preserved when a scheduling object
- resource is copied or moved and the resulting resource is also a
- scheduling object resource. If the source resource is not a
- scheduling object resource but the destination resource is, this
- property MUST be added to the destination resource.
-
- Description: The CALDAV:schedule-tag property MUST be defined on all
- scheduling object resources. This property is described in
- Section 8.
-
- Definition:
-
- <!ELEMENT schedule-tag (#PCDATA) >
-
- Example:
-
- <C:schedule-tag xmlns:C="urn:ietf:params:xml:ns:caldav"
- >"12345-67890"</C:schedule-tag>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 54]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-13. Scheduling Access Control
-
-13.1. Scheduling Privileges
-
- CalDAV servers MUST support and adhere to the requirements of WebDAV
- ACL [RFC3744]. Furthermore, CalDAV servers that advertise support
- for the "calendar-auto-schedule" feature MUST also support the
- scheduling privileges defined in this section.
-
- All the scheduling privileges MUST be non-abstract and MUST appear in
- the DAV:supported-privilege-set property of scheduling Outbox and
- Inbox collections on which they are defined.
-
- The tables specified in Appendix A clarify which scheduling methods
- (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling
- privilege defined in this section.
-
-13.1.1. Privileges on Scheduling Inbox Collections
-
- This section defines new WebDAV ACL privileges that are for use on
- scheduling Inbox collections. These privileges determine whether
- delivery of scheduling messages from a calendar user is allowed by
- the calendar user who "owns" the scheduling Inbox collection. This
- allows calendar users to choose which other calendar users can
- schedule with them.
-
- Note that when a scheduling message is delivered to a calendar user,
- in addition to a scheduling object resource being created in the
- calendar user's scheduling Inbox collection, a new scheduling object
- resource might be created or an existing one updated in a calendar
- belonging to the calendar user. In that case, the ability to create
- or update the scheduling object resource in the calendar is
- controlled by the privileges assigned to the scheduling Inbox
- collection.
-
- The privileges defined in this section are ignored if applied to a
- resource other than a scheduling Inbox collection.
-
-13.1.1.1. CALDAV:schedule-deliver Privilege
-
- CALDAV:schedule-deliver is an aggregate privilege that contains all
- the scheduling privileges that control the processing and delivery of
- incoming scheduling messages, that is, CALDAV:schedule-deliver-invite
- and CALDAV:schedule-deliver-reply, as well as freebusy requests
- targeted at the owner of the scheduling Inbox collection, that is,
- CALDAV:schedule-query-freebusy.
-
- <!ELEMENT schedule-deliver EMPTY >
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 55]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-13.1.1.2. CALDAV:schedule-deliver-invite Privilege
-
- The CALDAV:schedule-deliver-invite privilege controls the processing
- and delivery of scheduling messages coming from an Organizer.
-
- <!ELEMENT schedule-deliver-invite EMPTY >
-
-13.1.1.3. CALDAV:schedule-deliver-reply Privilege
-
- The CALDAV:schedule-deliver-reply privilege controls the processing
- and delivery of scheduling messages coming from an Attendee.
-
- <!ELEMENT schedule-deliver-reply EMPTY >
-
-13.1.1.4. CALDAV:schedule-query-freebusy Privilege
-
- The CALDAV:schedule-query-freebusy privilege controls freebusy
- requests targeted at the owner of the scheduling Inbox collection.
-
- <!ELEMENT schedule-query-freebusy EMPTY >
-
-13.1.2. Privileges on Scheduling Outbox Collections
-
- This section defines new WebDAV ACL privileges that are defined for
- use on scheduling Outbox collections. These privileges determine
- which calendar users are allowed to send scheduling messages on
- behalf of the calendar user who "owns" the scheduling Outbox
- collection. This allows calendar users to choose other calendar
- users who can act on their behalf to send schedule messages to other
- calendar users (e.g. assistants working on behalf of their boss).
-
- The privileges defined in this section are ignored if applied to a
- resource other than a scheduling Outbox collection.
-
-13.1.2.1. CALDAV:schedule-send Privilege
-
- CALDAV:schedule-send is an aggregate privilege that contains all the
- scheduling privileges that control the use of methods that will cause
- scheduling messages to be delivered to other users, that is, CALDAV-
- schedule-send-invite and CALDAV-schedule-send-reply, as well as
- freebusy requests to be targeted at other users, that is, CALDAV-
- schedule-send-freebusy.
-
- <!ELEMENT schedule-send EMPTY >
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 56]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-13.1.2.2. CALDAV:schedule-send-invite Privilege
-
- The CALDAV:schedule-send-invite privilege controls the sending of
- scheduling messages by Organizers.
-
- Users granted the DAV:bind privilege on a calendar collection, or
- DAV:write privilege on scheduling object resources, will also need
- the CALDAV:schedule-send-invite privilege granted on the scheduling
- Outbox collection of the owner of the calendar collection or
- scheduling object resource in order to be allowed to create, modify
- or delete scheduling object resources in a way that will trigger the
- CalDAV server to deliver organizer scheduling messages to other
- calendar users.
-
- <!ELEMENT schedule-send-invite EMPTY >
-
-13.1.2.3. CALDAV:schedule-send-reply Privilege
-
- The CALDAV:schedule-send-invite privilege controls the sending of
- scheduling messages by Attendees.
-
- Users granted the DAV:bind privilege on a calendar collection, or
- DAV:write privilege on scheduling object resources, will also need
- the CALDAV:schedule-send-reply privilege granted on the scheduling
- Outbox collection of the owner of the calendar collection or
- scheduling object resource in order to be allowed to create, modify
- or delete scheduling object resources in a way that will trigger the
- CalDAV server to deliver attendee scheduling messages to other
- calendar users.
-
- <!ELEMENT schedule-send-reply EMPTY >
-
-13.1.2.4. CALDAV:schedule-send-freebusy Privilege
-
- The CALDAV:schedule-send-freebusy privilege controls the use of the
- POST method to submit scheduling messages that specify the scheduling
- method "REQUEST" with a "VFREEBUSY" calendar component.
-
- <!ELEMENT schedule-send-freebusy EMPTY >
-
-13.1.3. Aggregation of Scheduling Privileges
-
- Server implementations MUST aggregate the scheduling privileges as
- follows:
-
- DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule-
- deliver;
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 57]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite,
- CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy;
-
- CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver-
- invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-
- freebusy.
-
- The following diagram illustrates how scheduling privileges are
- aggregated according to the above requirements.
-
- [DAV:all] (aggregate)
- |
- +-- [CALDAV:schedule-deliver] (aggregate)
- | |
- | +-- [CALDAV:schedule-deliver-invite]
- | +-- [CALDAV:schedule-deliver-reply]
- | +-- [CALDAV:schedule-query-freebusy]
- |
- +-- [CALDAV:schedule-send] (aggregate)
- |
- +-- [CALDAV:schedule-send-invite]
- +-- [CALDAV:schedule-send-reply]
- +-- [CALDAV:schedule-send-freebusy]
-
-13.2. Additional Principal Properties
-
- This section defines new properties for WebDAV principal resources as
- defined in RFC3744 [RFC3744]. These properties are likely to be
- protected but the server MAY allow them to be written by appropriate
- users.
-
-13.2.1. CALDAV:schedule-inbox-URL Property
-
- Name: schedule-inbox-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the URL of the scheduling Inbox collection owned
- by the associated principal resource.
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 58]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property is needed for a client to determine where
- the scheduling Inbox collection of the current user is located so
- that processing of scheduling messages can occur.
-
- Definition:
-
- <!ELEMENT schedule-inbox-URL (DAV:href)>
-
-13.2.2. CALDAV:schedule-outbox-URL Property
-
- Name: schedule-outbox-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the URL of the scheduling Outbox collection owned
- by the associated principal resource.
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property is needed for a client to determine where
- the scheduling Outbox collection of the current user is located so
- that sending of scheduling messages can occur.
-
- Definition:
-
- <!ELEMENT schedule-outbox-URL DAV:href>
-
-13.2.3. CALDAV:calendar-user-address-set Property
-
- Name: calendar-user-address-set
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the calendar addresses of the associated principal
- resource.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 59]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: Support for this property is REQUIRED. This property
- is needed to map calendar user addresses in iCalendar data to
- principal resources and their associated scheduling Inbox and
- Outbox collections. In the event that a user has no well defined
- identifier for their calendar user address, the URI of their
- principal resource can be used. This property SHOULD be
- searchable using the DAV:principal-property-search REPORT. The
- DAV:principal-search-property-set REPORT SHOULD identify this
- property as such.
-
- Definition:
-
- <!ELEMENT calendar-user-address-set (DAV:href*)>
-
- Example:
-
- <C:calendar-user-address-set xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:href>mailto:bernard at example.com</D:href>
- <D:href>mailto:bernard.desruisseaux at example.com</D:href>
- </C:calendar-user-address-set>
-
-13.2.4. CALDAV:calendar-user-type Property
-
- Name: calendar-user-type
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identifies the calendar user type of the associated
- principal resource.
-
- Value: Same values allowed for the iCalendar "CUTYPE" property
- parameter defined in Section 3.2.3 of
- [I-D.ietf-calsify-rfc2445bis].
-
- Protected: This property MAY be protected.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 60]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property MAY be defined on principal resources to
- indicate the type of calendar user associated with this principal
- resource. Its value is the same as the iCalendar "CUTYPE"
- property parameter that can be used on "ATTENDEE" properties.
- This property SHOULD be searchable using the DAV:principal-
- property-search REPORT. The DAV:principal-search-property-set
- REPORT SHOULD identify this property as such.
-
- Definition:
-
- <!ELEMENT calendar-user-type (#PCDATA) >
-
- Example:
-
- <C:calendar-user-type
- xmlns:C="urn:ietf:params:xml:ns:caldav">INDIVIDUAL<
- /C:calendar-user-type>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 61]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-14. XML Element Definitions
-
-14.1. CALDAV:schedule-response XML Element
-
- Name: schedule-response
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Contains the set of responses for a POST method request.
-
- Description: See Section 7.3.
-
- Definition:
-
- <!ELEMENT schedule-response (response*)>
-
-14.2. CALDAV:response XML Element
-
- Name: response
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Contains a single response for a POST method request.
-
- Description: See Section 7.3.
-
- Definition:
-
- <!ELEMENT response (recipient,
- request-status,
- calendar-data?,
- DAV:error?,
- DAV:responsedescription?)>
-
-14.3. CALDAV:recipient XML Element
-
- Name: recipient
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: The calendar user address that the enclosing response for a
- POST method request is for.
-
- Description: See Section 7.3.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 62]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Definition:
-
- <!ELEMENT recipient (DAV:href)>
-
-14.4. CALDAV:request-status XML Element
-
- Name: request-status
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: The iTIP "REQUEST-STATUS" property value for this response.
-
- Description: See Section 7.3.
-
- Definition:
-
- <!ELEMENT request-status (#PCDATA) >
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 63]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-15. Security Considerations
-
- The process of scheduling involves the sending and receiving of
- scheduling messages. As a result, the security problems related to
- messaging in general are relevant here. In particular the
- authenticity of the scheduling messages needs to be verified.
- Servers and clients MUST use an HTTP connection protected with TLS as
- defined in [RFC2818] for all scheduling transactions.
-
-15.1. Verifying Scheduling Transactions
-
- When handling a scheduling transaction:
-
- Servers MUST verify that the principal associated with the DAV:
- owner of the calendar collection in which a scheduling object
- resource is being manipulated contains a CALDAV:schedule-outbox-
- URL property value.
-
- Servers MUST verify that the currently authenticated user has the
- CALDAV:schedule-send privilege, or a suitable sub-privilege
- aggregated under this privilege, on the scheduling Outbox
- collection of the DAV:owner of the calendar collection in which a
- scheduling object resource is being manipulated.
-
- Servers MUST only deliver scheduling messages to recipients when
- the CALDAV:schedule-deliver privilege, or a suitable sub-privilege
- aggregated under this privilege, is granted on the recipient's
- scheduling Inbox collection for the principal associated with the
- DAV:owner of the calendar collection in which a scheduling object
- resource is being manipulated.
-
- To prevent impersonation of calendar users, the server MUST verify
- that the "ORGANIZER" property in an organizer scheduling object
- resource matches one of the calendar user addresses of the DAV:
- owner of the calendar collection in which the resource is stored.
-
- To prevent spoofing of an existing scheduling object resource,
- servers MUST verify that the "UID" iCalendar property value in a
- new scheduling object resource does not match that of an existing
- scheduling object resource with a different "ORGANIZER" property
- value.
-
-15.2. Verifying Busy Time Information Requests
-
- When handling a POST request on a scheduling Outbox collection:
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 64]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- Servers MUST verify that the principal associated with the
- calendar user address specified in the "ORGANIZER" property of the
- scheduling message data in the request contains a CALDAV:schedule-
- outbox-URL property value that matches the scheduling Outbox
- collection targeted by the request.
-
- Servers MUST verify that the currently authenticated user has the
- CALDAV:schedule-send privilege, or a sub-privilege aggregated
- under this privilege, on the scheduling Outbox collection targeted
- by the request.
-
- Servers MUST only return valid freebusy information for recipients
- when the CALDAV:schedule-deliver privilege, or a sub-privilege
- aggregated under this privilege, is granted on the recipient's
- scheduling Inbox collection for the principal associated with the
- DAV:owner of the scheduling Outbox collection targeted by the
- request.
-
-15.3. Privacy Issues
-
- As noted in Section 11.1, Attendees can use the Schedule-Reply
- request header with the value set to "F" to prevent notification to
- an Organizer that a scheduling object resource was deleted. This
- allows Attendees to remove unwanted scheduling messages without any
- response to the Organizer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 65]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-16. IANA Considerations
-
-16.1. Message Header Field Registrations
-
- The message header fields below should be added to the Permanent
- Message Header Field Registry (see [RFC3864]).
-
-16.1.1. Schedule-Reply
-
- Header field name: Schedule-Reply
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document(s): this specification (Section 11.1)
-
- Related information: none
-
-16.1.2. Schedule-Tag
-
- Header field name: Schedule-Tag
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document(s): this specification (Section 11.2)
-
- Related information: none
-
-16.1.3. If-Schedule-Tag-Match
-
- Header field name: If-Schedule-Tag-Match
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document(s): this specification (Section 11.3)
-
- Related information: none
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 66]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-16.2. iCalendar Property Parameter Registrations
-
- The following iCalendar property parameters should be added to the
- iCalendar Property Parameter Registry defined in Section 8.3.3 of
- [I-D.ietf-calsify-rfc2445bis].
-
- +---------------------+---------+-----------------------+
- | Parameter | Status | Reference |
- +---------------------+---------+-----------------------+
- | SCHEDULE-AGENT | Current | RFCXXXX, Section 10.1 |
- | | | |
- | SCHEDULE-STATUS | Current | RFCXXXX, Section 10.3 |
- | | | |
- | SCHEDULE-FORCE-SEND | Current | RFCXXXX, Section 10.2 |
- +---------------------+---------+-----------------------+
-
-16.3. Additional iCalendar Elements Registries
-
- The IANA should create and maintain the following additional
- registries for iCalendar elements with pointers to appropriate
- reference documents.
-
-16.3.1. Schedule Agent Values Registry
-
- The following table should be used to initialize the schedule agent
- values registry.
-
- +----------------+---------+------------------------+
- | Schedule Agent | Status | Reference |
- +----------------+---------+------------------------+
- | SERVER | Current | RFC XXXX, Section 10.1 |
- | | | |
- | CLIENT | Current | RFC XXXX, Section 10.1 |
- | | | |
- | NONE | Current | RFC XXXX, Section 10.1 |
- +----------------+---------+------------------------+
-
-16.3.2. Schedule Force Send Values Registry
-
- The following table should be used to initialize the schedule send
- values registry.
-
- +---------------------+---------+------------------------+
- | Schedule Force Send | Status | Reference |
- +---------------------+---------+------------------------+
- | REQUEST | Current | RFC XXXX, Section 10.2 |
- | | | |
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 67]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- | REPLY | Current | RFC XXXX, Section 10.2 |
- +---------------------+---------+------------------------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 68]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-17. Acknowledgements
-
- The authors would like to thank the following individuals for
- contributing their ideas and support for writing this specification:
- Mike Douglass, Lisa Dusseault, Helge Hess, Arnaud Quillaud, Julian F.
- Reschke, Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim
- Whitehead.
-
- The authors would also like to thank the Calendaring and Scheduling
- Consortium for advice with this specification, and for organizing
- interoperability testing events to help refine it.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 69]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-18. References
-
-18.1. Normative References
-
- [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport-
- Independent Interoperability Protocol
- (iTIP)", draft-ietf-calsify-2446bis-09
- (work in progress), April 2009.
-
- [I-D.ietf-calsify-rfc2445bis] Desruisseaux, B., "Internet
- Calendaring and Scheduling Core Object
- Specification (iCalendar)",
- draft-ietf-calsify-rfc2445bis-10 (work
- in progress), April 2009.
-
- [RFC2119] Bradner, S., "Key words for use in
- RFCs to Indicate Requirement Levels",
- BCP 14, RFC 2119, March 1997.
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J.,
- Frystyk, H., Masinter, L., Leach, P.,
- and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1",
- RFC 2616, June 1999.
-
- [RFC2818] Rescorla, E., "HTTP Over TLS",
- RFC 2818, May 2000.
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E.,
- and J. Whitehead, "Web Distributed
- Authoring and Versioning (WebDAV)
- Access Control Protocol", RFC 3744,
- May 2004.
-
- [RFC3864] Klyne, G., Nottingham, M., and J.
- Mogul, "Registration Procedures for
- Message Header Fields", BCP 90,
- RFC 3864, September 2004.
-
- [RFC4791] Daboo, C., Desruisseaux, B., and L.
- Dusseault, "Calendaring Extensions to
- WebDAV (CalDAV)", RFC 4791,
- March 2007.
-
- [RFC4918] Dusseault, L., "HTTP Extensions for
- Web Distributed Authoring and
- Versioning (WebDAV)", RFC 4918,
- June 2007.
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 70]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- [RFC5234] Crocker, D. and P. Overell, "Augmented
- BNF for Syntax Specifications: ABNF",
- STD 68, RFC 5234, January 2008.
-
- [W3C.REC-xml-20081126] Maler, E., Yergeau, F., Sperberg-
- McQueen, C., Paoli, J., and T. Bray,
- "Extensible Markup Language (XML) 1.0
- (Fifth Edition)", World Wide Web
- Consortium Recommendation REC-xml-
- 20081126, November 2008, <http://
- www.w3.org/TR/2008/REC-xml-20081126>.
-
-18.2. Informative References
-
- [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based
- Interoperability Protocol (iMIP)",
- draft-ietf-calsify-rfc2447bis-05 (work
- in progress), June 2008.
-
- [RFC3283] Mahoney, B., Babics, G., and A. Taler,
- "Guide to Internet Calendaring",
- RFC 3283, June 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 71]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-Appendix A. Scheduling Privileges Summary
-
-A.1. Scheduling Inbox Privileges
-
- The following tables specify which scheduling privileges grant the
- right to a calendar user to deliver a scheduling message to the
- scheduling Inbox collection of another calendar user. The
- appropriate behavior depends on the calendar component type as well
- as the scheduling "METHOD" specified in the scheduling message.
-
- +--------------------------------+
- | METHOD for VEVENT and VTODO |
- +-----------------------------+---------+-------+-----+--------+
- | Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL |
- +-----------------------------+---------+-------+-----+--------+
- | schedule-deliver | * | * | * | * |
- | schedule-deliver-invite | * | | * | * |
- | schedule-deliver-reply | | * | | |
- | schedule-query-freebusy | | | | |
- +-----------------------------+---------+-------+-----+--------+
-
-
- +----------------------+
- | METHOD for VFREEBUSY |
- +-----------------------------+----------------------+
- | Scheduling Inbox Privilege | REQUEST |
- +-----------------------------+----------------------+
- | schedule-deliver | * |
- | schedule-deliver-invite | |
- | schedule-deliver-reply | |
- | schedule-query-freebusy | * |
- +-----------------------------+----------------------+
-
-A.2. Scheduling Outbox Privileges
-
- The following tables specify which scheduling privileges grant the
- right to a Calendar User to perform busy time information requests
- and to submit scheduling messages to other Calendar Users as the
- result of a scheduling transaction. The appropriate behavior depends
- on the calendar component type as well as the scheduling "METHOD"
- specified in the scheduling message.
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 72]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- +--------------------------------+
- | METHOD for VEVENT and VTODO |
- +-----------------------------+---------+-------+-----+--------+
- | Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL |
- +-----------------------------+---------+-------+-----+--------+
- | schedule-send | * | * | * | * |
- | schedule-send-invite | * | | * | * |
- | schedule-send-reply | | * | | |
- | schedule-send-freebusy | | | | |
- +-----------------------------+---------+-------+-----+--------+
-
-
- +----------------------+
- | METHOD for VFREEBUSY |
- +-----------------------------+----------------------+
- | Scheduling Outbox Privilege | REQUEST |
- +-----------------------------+----------------------+
- | schedule-send | * |
- | schedule-send-invite | |
- | schedule-send-reply | |
- | schedule-send-freebusy | * |
- +-----------------------------+----------------------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 73]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-Appendix B. Example Scheduling Transactions
-
- This section describes some example scheduling transactions that give
- a general idea of how scheduling is carried out between CalDAV
- clients and servers from the perspective of meeting Organizers and
- Attendees.
-
- In the following examples the requests and responses are incomplete
- and are only for illustrative purposes. In particular, HTTP
- authentication headers and behaviors are not shown, even though they
- are required in normal operation.
-
-B.1. Example: Organizer Inviting Multiple Attendees
-
- In the following example, Cyrus invites Wilfredo, Bernard and Mike to
- a single instance event by simply creating a new scheduling object
- resource in one of his calendar collection by using the PUT method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 74]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Request <<
-
- PUT /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@
- example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike at example.org
- END:VEVENT
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 201 Created
- Content-Length: 0
- Date: Tue, 02 Jun 2009 18:52:54 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
- ETag: "d85561cfe74a4e785eb4639451b434fb"
- Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
-
- Once the event creation has been completed, Cyrus's client will
- retrieve the event back from the server to get the schedule status of
- each Attendee. In this example, the server reports that a scheduling
- message was delivered to Wilfredo, a scheduling message is still
- pending for Bernard, and the server was unable to deliver a
- scheduling message to Mike.
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 75]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Request <<
-
- GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:52:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185300Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=
- "1.2;Scheduling message has been delivered":mailto:wilfredo at e
- xample.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS="
- 1.0;Scheduling message is pending":mailto:bernard at example.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE;SCHEDULE-STATUS="3.7;Invalid calendar user":m
- ailto:mike at example.org
- END:VEVENT
- END:VCALENDAR
-
-B.2. Example: Attendee Receiving an Invitation
-
- In the following example, Wilfredo's client retrieves and deletes the
- new scheduling message that appeared in his scheduling Inbox
- collection after the server automatically processed it and created a
- new scheduling object resource in his default calendar collection.
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 76]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Request <<
-
- GET /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:59:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:59:58 GMT
- ETag: "da116714bc9926c89395895eb897deab"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REQUEST
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@
- example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike at example.org
- END:VEVENT
- END:VCALENDAR
-
- >> Request <<
-
- DELETE /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 77]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Response <<
-
- HTTP/1.1 204 No Content
- Date: Tue, 02 Jun 2009 20:40:36 GMT
-
-B.3. Example: Attendee Replying to an Invitation
-
- In the following example, Wilfredo's accepts Cyrus's invitation and
- sets a reminder on the event.
-
- >> Request <<
-
- PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1
- Host: cal.example.com
- If-Schedule-Tag-Match: "e78f23ed-0188-4bab-938d-2aeb3324c7e8"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo at exam
- ple.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike at example.org
- BEGIN:VALARM
- TRIGGER:-PT15M
- ACTION:DISPLAY
- DESCRIPTION:Reminder
- END:VALARM
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 78]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Content-Length: 0
- Date: Tue, 02 Jun 2009 18:57:54 GMT
- Last-Modified: Tue, 02 Jun 2009 18:57:54 GMT
- ETag: "eb4639451b434fbd85561cfe74a4e785"
- Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41"
-
- Once the event modification has been completed, Wilfredo's client
- will retrieve the event back from the server to get the schedule
- status of the Organizer.
-
- >> Request <<
-
- PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 79]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 19:03:03 GMT
- Last-Modified: Tue, 02 Jun 2009 19:02:21 GMT
- ETag: "5eb897deabda116714bc9926c8939589"
- Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T190221Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo";SCHEDULE-STATUS="1.2;Scheduling mes
- sage has been delivered":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo at exam
- ple.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike at example.org
- BEGIN:VALARM
- TRIGGER:-PT15M
- ACTION:DISPLAY
- DESCRIPTION:Reminder
- END:VALARM
- END:VEVENT
- END:VCALENDAR
-
-B.4. Example: Organizer Receiving a Reply to an Invitation
-
- On reception of Wilfredo's reply, Cyrus's server will automatically
- update Cyrus's scheduling object resource, make Wilfredo's scheduling
- message available in Cyrus's scheduling Inbox collection, and deliver
- an updated scheduling message to Bernard to share Wilfredo's updated
- participation status. In this example, Cyrus's client retrieves and
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 80]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- deletes this scheduling message in his scheduling Inbox collection.
-
- >> Request <<
-
- GET /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 19:05:02 GMT
- Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT
- ETag: "9265eb897deabc8939589da116714bc9"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REPLY
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185754Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";PARTSTAT=ACCEPTED:mailto:w
- ilfredo at example.com
- REQUEST-STATUS:2.0;Success
- END:VEVENT
- END:VCALENDAR
-
- >> Request <<
-
- DELETE /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 204 No Content
- Date: Tue, 02 Jun 2009 19:05:05 GMT
-
- Cyrus's client then retrieves the event back from the server with
- Wilfredo's updated participation status.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 81]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Request <<
-
- GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 19:05:02 GMT
- Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Schedule-Tag: "132cab27-1fe3-67ab-de13-abd348d1dee3"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T190420Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS="2.0
- ;Reply has been received":mailto:wilfredo at example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS="
- 1.0;Scheduling message is pending":mailto:bernard at example.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE;SCHEDULE-STATUS="3.7;Invalid calendar user":m
- ailto:mike at example.org
- END:VEVENT
- END:VCALENDAR
-
-B.5. Example: Organizer Requesting Busy Time Information
-
- In this example, Cyrus requests the busy time information of Wilfredo
- and Bernard.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 82]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Request <<
-
- POST /home/cyrus/calendars/outbox/ HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REQUEST
- BEGIN:VFREEBUSY
- UID:4FD3AD926350
- DTSTAMP:20090602T190420Z
- DTSTART:20090602T000000Z
- DTEND:20090604T000000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo at example.com
- ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard at example.net
- END:VFREEBUSY
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 20:07:34 GMT
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <?xml version="1.0" encoding="utf-8" ?>
- <C:schedule-response xmlns:D="DAV:"
- xmlns:C="urn:ietf:params:xml:ns:caldav">
- <C:response>
- <C:recipient>
- <D:href>mailto:wilfredo at example.com<D:href>
- </C:recipient>
- <C:request-status>2.0;Success</C:request-status>
- <C:calendar-data>BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REPLY
- BEGIN:VFREEBUSY
- UID:4FD3AD926350
- DTSTAMP:20090602T200733Z
- DTSTART:20090602T000000Z
- DTEND:20090604T000000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo at example.com
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 83]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- FREEBUSY;FBTYPE=BUSY:20090602T110000Z/20090602T120000Z
- FREEBUSY;FBTYPE=BUSY:20090603T170000Z/20090603T180000Z
- END:VFREEBUSY
- END:VCALENDAR
- </C:calendar-data>
- </C:response>
- <C:response>
- <C:recipient>
- <D:href>mailto:bernard at example.net<D:href>
- </C:recipient>
- <C:request-status>2.0;Success</C:request-status>
- <C:calendar-data>BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REPLY
- BEGIN:VFREEBUSY
- UID:4FD3AD926350
- DTSTAMP:20090602T200733Z
- DTSTART:20090602T000000Z
- DTEND:20090604T000000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard at example.net
- FREEBUSY;FBTYPE=BUSY:20090602T150000Z/20090602T160000Z
- FREEBUSY;FBTYPE=BUSY:20090603T090000Z/20090603T100000Z
- FREEBUSY;FBTYPE=BUSY:20090603T180000Z/20090603T190000Z
- END:VFREEBUSY
- END:VCALENDAR
- </C:calendar-data>
- </C:response>
- </C:schedule-response>
-
-B.6. Example: User Attempting to Invite Attendee on behalf of Organizer
-
- In the following example, Cyrus attempts to create, on behalf of
- Wilfredo, an event with Bernard specified as an Attendee. The
- request fails since Wilfredo didn't grant Cyrus the right to invite
- other Calendar Users on his behalf.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 84]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Request <<
-
- PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:3504F926D3AD
- SEQUENCE:0
- DTSTAMP:20090602T190221Z
- DTSTART:20090602T230000Z
- DTEND:20090603T000000Z
- TRANSP:OPAQUE
- SUMMARY:Dinner
- ORGANIZER;CN="Wilfredo Sanchez Vega":mailto:wilfredo at example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT=A
- CCEPTED:mailto:wilfredo at example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=NE
- EDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at exampl
- e.net
- END:VEVENT
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 403 Forbidden
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
- <D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
- <D:need-privileges>
- <D:resource>
- <D:href>/home/wilfredo/calendars/outbox/</D:href>
- <D:privilege><C:schedule-send-invite/></D:privilege>
- </D:resource>
- </D:need-privileges>
- </D:error>
-
-B.7. Example: Attendee Declining an Instance of a Recurring Event
-
- In the following example, Bernard declines the second recurrence
- instance of a daily recurring event he's been invited to by Cyrus.
-
- >> Request <<
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 85]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART;TZID=America/Montreal:20090601T150000
- DTEND;TZID=America/Montreal:20090601T160000
- RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5
- TRANSP:OPAQUE
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at exampl
- e.net
- END:VEVENT
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090602T150000
- DTSTART;TZID=America/Montreal:20090602T150000
- DTEND;TZID=America/Montreal:20090602T160000
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 86]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- TRANSP:TRANSPARENT
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at exampl
- e.net
- END:VEVENT
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Content-Length: 0
- Date: Tue, 02 Jun 2009 18:52:54 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
- ETag: "d85561cfe74a4e785eb4639451b434fb"
- Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
-
- Bernard's participation status update will cause his server to
- deliver a scheduling message to Cyrus. Cyrus's client will find the
- following reply message from Bernard in Cyrus's scheduling Inbox
- collection:
-
- >> Request <<
-
- GET /home/cyrus/calendars/inbox/9263504FD3AD.ics HTTP/1.1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 87]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:52:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REPLY
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090602T150000
- DTSTART;TZID=America/Montreal:20090602T150000
- DTEND;TZID=America/Montreal:20090602T160000
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED:
- mailto:bernard at example.net
- REQUEST-STATUS:2.0;Success
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 88]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-B.8. Example: Attendee Removing an Instance of a Recurring Event
-
- In the following example, Bernard removes from his calendar the third
- recurrence instance of a daily recurring event he's been invited to
- by Cyrus. This is accomplished by the addition of an "EXDATE"
- property to the scheduling object resource stored by Bernard.
-
- >> Request <<
-
- PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART;TZID=America/Montreal:20090601T150000
- DTEND;TZID=America/Montreal:20090601T160000
- RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5
- EXDATE;TZID=America/Montreal:20090603T150000
- TRANSP:OPAQUE
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 89]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at exampl
- e.net
- END:VEVENT
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090602T150000
- DTSTART;TZID=America/Montreal:20090602T150000
- DTEND;TZID=America/Montreal:20090602T160000
- TRANSP:TRANSPARENT
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard at exampl
- e.net
- END:VEVENT
- END:VCALENDAR
-
- Bernard's deletion of a recurrence instance will cause his server to
- deliver a scheduling message to Cyrus. Cyrus's client will find the
- following reply message from Bernard in Cyrus's scheduling Inbox
- collection:
-
- >> Request <<
-
- GET /home/cyrus/calendars/inbox/6504923FD3AD.ics HTTP/1.1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 90]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:52:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REPLY
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090603T150000
- DTSTART;TZID=America/Montreal:20090603T150000
- DTEND;TZID=America/Montreal:20090603T160000
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus at example.com
- ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED:
- mailto:bernard at example.net
- REQUEST-STATUS:2.0;Success
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 91]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-Appendix C. Changes (to be removed by RFC Editor prior to publication)
-
-C.1. Changes in -07
-
- a. Restructured document.
-
- b. Clarified that CALDAV:schedule-calendar-transp only applies to
- calendar collection.
-
- c. Removed CALDAV:schedule-state property on scheduling messages in
- the scheduling Inbox collection.
-
- d. Added conditional requests on scheduling object resources.
-
- e. Added section on handling of PARTSTAT.
-
- f. Added SCHEDULE-FORCE-SEND iCalendar property parameter.
-
- g. Added clarification on child resources in scheduling Outbox
- collections.
-
- h. Clarified Attendee changes that server MUST allow, and removed
- restrictions on changes that Attendee MUST NOT do.
-
- i. Added Example Scheduling Transactions appendix.
-
- j. Scheduling privileges are no longer required to be non-abstract.
-
- k. Removed handling of REFRESH requests.
-
- l. Removed handling of VJOURNAL components.
-
- m. Completed IANA Considerations section.
-
- n. Added references to RFC3283 and RFC5234.
-
- o. Updated references to iCalendar, iTIP and iMIP.
-
-C.2. Changes in -06
-
- a. Removed distinction between scheduling calendar collections and
- basic calendar collections - now just have calendar collections.
-
- b. Clients now "MAY" reload data rather than "SHOULD" reload data.
-
- c. Fixed <C:recipient> in examples.
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 92]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
- d. Removed CALDAV:attachments-allowed precondition on POST to Outbox
- as that is no longer relevant.
-
- e. Added CALDAV:default-calendar-delete-allowed precondition for
- DELETE.
-
- f. Relaxed MUST->MAY for Organizer setting PARTSTAT value.
-
- g. Tweaked restrictions on Create/Modify to emphasize that 4791
- restrictions also apply.
-
- h. Added comment that 'opaque' is the default when the CALDAV:
- schedule-calendar-transp property is not present.
-
- i. Description of Schedule-Reply header changed to reflect that it
- is only relevant for Attendees.
-
- j. Minor typos fixed.
-
-C.3. Changes in -05
-
- This draft has changed substantially since the -04 version. The
- primary reason for this change was implementation experience from a
- number of vendors who implemented products based on the earlier
- drafts. Experience showed that the client/server interaction was not
- reliable in keeping scheduling messages synchronized between
- organizer and attendees. In addition the latency in updates due to
- clients being offline proved unacceptable to users. These issues led
- to the redesign of this specification to support a server-based
- processing model that eliminates all the problems seen previously.
- Whilst this adds significant complexity to the server in that it
- needs to be a full blown iTIP processing agent, it does remove a lot
- of the same complexity from clients, opening up the possibility of
- supporting complex scheduling behaviors even with "thin" clients.
-
- In the judgement of the authors, we consider this new specification
- to be a substantial improvement over the old one and believe it
- represents a stronger protocol that will lead to better
- interoperability.
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 93]
-
-Internet-Draft CalDAV Scheduling Extensions June 2009
-
-
-Authors' Addresses
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- EMail: cyrus at daboo.name
- URI: http://www.apple.com/
-
-
- Bernard Desruisseaux
- Oracle Corporation
- 600 Blvd. de Maisonneuve West
- Suite 1900
- Montreal, QC H3A 3J2
- CANADA
-
- EMail: bernard.desruisseaux at oracle.com
- URI: http://www.oracle.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires December 21, 2009 [Page 94]
-
+
+
+
+Network Working Group C. Daboo
+Internet-Draft Apple Inc.
+Intended status: Standards Track B. Desruisseaux
+Expires: May 7, 2009 Oracle
+ November 3, 2008
+
+
+ CalDAV Scheduling Extensions to WebDAV
+ draft-desruisseaux-caldav-sched-06
+
+Status of This Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 7, 2009.
+
+Abstract
+
+ This document defines extensions to the CalDAV calendar-access
+ feature to specify a standard way of performing scheduling
+ transactions with iCalendar-based calendar components. This document
+ defines the "calendar-auto-schedule" feature of CalDAV.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Level of Support for iTIP . . . . . . . . . . . . . . . . 4
+ 1.2. XML Namespaces . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 1]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
+ 1.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2. CalDAV Scheduling Support . . . . . . . . . . . . . . . . . . 7
+ 3. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1. Scheduling Collections . . . . . . . . . . . . . . . . . . 9
+ 3.1.1. Scheduling Outbox Collection . . . . . . . . . . . . . 9
+ 3.1.2. Scheduling Inbox Collection . . . . . . . . . . . . . 10
+ 3.2. Automatic Scheduling Transactions . . . . . . . . . . . . 12
+ 3.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12
+ 3.2.2. Identifying Scheduling Object Resources . . . . . . . 12
+ 3.2.3. Handling Scheduling Object Resources . . . . . . . . . 13
+ 3.2.3.1. Organizer Scheduling Object Resources . . . . . . 13
+ 3.2.3.2. Attendee Scheduling Object Resources . . . . . . . 16
+ 3.2.3.3. HTTP Methods . . . . . . . . . . . . . . . . . . . 18
+ 3.3. Processing of incoming scheduling messages . . . . . . . . 20
+ 3.3.1. Automatic processing for the Organizer . . . . . . . . 21
+ 3.3.1.1. Processing an Attendee reply . . . . . . . . . . . 21
+ 3.3.1.2. Processing an Attendee refresh . . . . . . . . . . 21
+ 3.3.2. Automatic processing for the Attendee . . . . . . . . 21
+ 3.3.2.1. Processing a new scheduling message . . . . . . . 22
+ 3.3.2.2. Processing a scheduling message update . . . . . . 22
+ 3.3.3. Processing by the client . . . . . . . . . . . . . . . 22
+ 3.4. Explicit Scheduling Request . . . . . . . . . . . . . . . 23
+ 3.5. Other Considerations . . . . . . . . . . . . . . . . . . . 23
+ 3.5.1. Handling recurring items . . . . . . . . . . . . . . . 23
+ 3.5.1.1. Restricting what is sent . . . . . . . . . . . . . 23
+ 3.5.1.2. Attendee overrides . . . . . . . . . . . . . . . . 23
+ 3.5.2. Handling the Default Calendar . . . . . . . . . . . . 24
+ 3.5.3. DTSTAMP and SEQUENCE properties . . . . . . . . . . . 24
+ 3.5.4. Schedule Status Values . . . . . . . . . . . . . . . . 25
+ 3.5.5. Error Handling . . . . . . . . . . . . . . . . . . . . 26
+ 3.5.6. Organizer is an Attendee . . . . . . . . . . . . . . . 26
+ 4. New iCalendar Parameters . . . . . . . . . . . . . . . . . . . 26
+ 4.1. Schedule Agent . . . . . . . . . . . . . . . . . . . . . . 26
+ 4.2. Schedule Status . . . . . . . . . . . . . . . . . . . . . 27
+ 5. New WebDAV Request Headers . . . . . . . . . . . . . . . . . . 28
+ 5.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 28
+ 6. New WebDAV Properties . . . . . . . . . . . . . . . . . . . . 29
+ 6.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 29
+ 6.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 30
+ 6.3. CALDAV:schedule-state Property . . . . . . . . . . . . . . 31
+ 7. New Preconditions . . . . . . . . . . . . . . . . . . . . . . 32
+ 7.1. Additional Preconditions for PUT, COPY and MOVE . . . . . 32
+ 7.2. Additional Preconditions for PUT . . . . . . . . . . . . . 32
+ 7.3. Additional Precondition for DELETE . . . . . . . . . . . . 33
+ 7.4. Additional Precondition for PROPPATCH . . . . . . . . . . 33
+ 8. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+ 8.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 34
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 2]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ 8.1.1. Handling a REFRESH . . . . . . . . . . . . . . . . . . 35
+ 8.1.2. Response to a POST request . . . . . . . . . . . . . . 35
+ 8.1.3. Status Codes for use with the POST method . . . . . . 36
+ 8.1.4. Example - Simple meeting invitation refresh . . . . . 37
+ 8.1.5. Example - Freebusy lookup . . . . . . . . . . . . . . 38
+ 8.2. Retrieving incoming scheduling messages . . . . . . . . . 39
+ 9. Scheduling Access Control . . . . . . . . . . . . . . . . . . 40
+ 9.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 40
+ 9.1.1. Privileges on Scheduling Inbox Collections . . . . . . 40
+ 9.1.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . 40
+ 9.1.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . 40
+ 9.1.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . 41
+ 9.1.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . 41
+ 9.1.2. Privileges on Scheduling Outbox Collections . . . . . 41
+ 9.1.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . 41
+ 9.1.2.2. CALDAV:schedule-send-invite Privilege . . . . . . 41
+ 9.1.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . 42
+ 9.1.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . 42
+ 9.1.3. Aggregation of Scheduling Privileges . . . . . . . . . 42
+ 9.2. Additional Principal Properties . . . . . . . . . . . . . 43
+ 9.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 43
+ 9.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 43
+ 9.2.3. CALDAV:calendar-user-address-set Property . . . . . . 44
+ 9.2.4. CALDAV:calendar-user-type Property . . . . . . . . . . 45
+ 10. Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
+ 11. XML Element Definitions . . . . . . . . . . . . . . . . . . . 46
+ 11.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 46
+ 11.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 46
+ 11.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 47
+ 11.4. CALDAV:request-status XML Element . . . . . . . . . . . . 47
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47
+ 12.1. Verifying scheduling requests . . . . . . . . . . . . . . 47
+ 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 48
+ 13.1. HTTP header registration . . . . . . . . . . . . . . . . . 48
+ 13.1.1. Schedule-Reply Request Header Registration . . . . . . 49
+ 13.2. iCalendar Registrations . . . . . . . . . . . . . . . . . 49
+ 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 49
+ 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
+ 15.1. Normative References . . . . . . . . . . . . . . . . . . . 49
+ 15.2. Informative References . . . . . . . . . . . . . . . . . . 50
+ Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 50
+ A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 50
+ A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 52
+ Appendix B. Changes (to be removed prior to publication as an
+ RFC) . . . . . . . . . . . . . . . . . . . . . . . . 54
+ B.1. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 54
+ B.2. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 55
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 3]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+1. Introduction
+
+ This document specifies an extension to the CalDAV calendar-access
+ feature [RFC4791] to enable scheduling of iCalendar-based [RFC2445]
+ calendar components between calendar users. This extension leverages
+ the scheduling methods defined in the iCalendar Transport-independent
+ Interoperability Protocol iTIP [RFC2446] to permit calendar users to
+ perform scheduling transactions such as schedule, reschedule, respond
+ to scheduling request or cancel scheduled calendar components, as
+ well as search for busy time information.
+
+ iTIP [RFC2446] outlines a model where calendar users exchange
+ scheduling messages with one another. Often times, calendar user
+ agents are made responsible for generating and sending scheduling
+ messages as well as processing incoming scheduling messages. This
+ approach yields a number of problems, including:
+
+ o The handling of incoming scheduling messages and the updates to
+ calendars imposed by these messages only occurs when calendar user
+ agents are active.
+
+ o For most updates to a calendar, calendar user agents need to
+ address a separate scheduling message to the Organizer or the
+ Attendees.
+
+ o Due to the update latency it is possible for calendars of
+ different calendar users to reflect different, inaccurate states.
+
+ This specification is using an alternative approach where the server
+ is made responsible for sending most scheduling messages and
+ processing most incoming scheduling messages. This approach frees
+ the calendar user agents from the delivery and processing of most
+ scheduling messages and ensures a better consistency of the data in
+ the users' calendars on the server. The simple operation of
+ creating, modifying or deleting a calendar object resource in a
+ calendar is enough to trigger the CalDAV server to deliver
+ appropriate scheduling messages to the calendar users.
+
+ Discussion of this Internet-Draft is taking place on the mailing list
+ <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
+
+1.1. Level of Support for iTIP
+
+ While the scheduling features described in this specification are
+ based on iTIP [RFC2446], some of its more complex features have
+ deliberately not been implemented, in order to keep this
+ specification simple. In particular, the following iTIP [RFC2446]
+ features are not supported:
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 4]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ o Sending scheduling messages with the METHODs "PUBLISH", "COUNTER"
+ and "DECLINE-COUNTER"
+
+ o Delegating an Event to another calendar user
+
+ o Changing the Organizer
+
+ o Forwarding to an uninvited calendar user
+
+ The goal of this specification is to provide the essential scheduling
+ features needed, and it is anticipated that future extensions will be
+ developed to address the more complex features if the demand arises.
+
+1.2. XML Namespaces
+
+ Definitions of XML elements in this document use XML element type
+ declarations (as found in XML Document Type Declarations), described
+ in Section 3.2 of [W3C.REC-xml-20060816].
+
+ The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
+ elements defined in this specification, or in other Standards Track
+ IETF RFCs written to extend CalDAV. It MUST NOT be used for
+ proprietary extensions.
+
+ Note that the XML declarations used in this document are incomplete,
+ in that they do not include namespace information. Thus, the reader
+ MUST NOT use these declarations as the only way to create valid
+ CalDAV properties or to validate CalDAV XML element types. Some of
+ the declarations refer to XML elements defined by WebDAV which use
+ the "DAV:" namespace. Wherever such elements appear, they are
+ explicitly given the "DAV:" prefix to help avoid confusion.
+ Additionally, some of the elements used here are defined in CalDAV
+ [RFC4791].
+
+ Also note that some CalDAV XML element names are identical to WebDAV
+ XML element names, though their namespace differs. Care MUST be
+ taken not to confuse the two sets of names.
+
+1.3. Notational Conventions
+
+ The augmented BNF used by this document to describe protocol elements
+ is described in Section 2.1 of [RFC2616]. Because this augmented BNF
+ uses the basic production rules provided in Section 2.2 of [RFC2616],
+ those rules apply to this document as well.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 5]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ When XML element types in the namespaces "DAV:" and
+ "urn:ietf:params:xml:ns:caldav" are referenced in this document
+ outside of the context of an XML fragment, the string "DAV:" and
+ "CALDAV:" will be prefixed to the element types respectively.
+
+1.4. Terminology
+
+ Calendar User Agent (CUA): Software with which the calendar user
+ communicates with a calendar service or local calendar store to
+ access calendar information.
+
+ Calendar collection: Same as [RFC4791].
+
+ Calendar object resource: Same as [RFC4791].
+
+ Scheduling object resource: A calendar object resource contained in
+ a calendar collection for which the server will take care of
+ sending scheduling messages on behalf of the owner of the calendar
+ collection.
+
+ Organizer scheduling object resource: A scheduling object resource
+ owned by an Organizer.
+
+ Attendee scheduling object resource: A scheduling object resource
+ owned by an Attendee.
+
+ Automatic scheduling transaction: Add, change or remove operations
+ on a scheduling object resource for which the server will deliver
+ scheduling messages to other users.
+
+ Explicit scheduling request: Scheduling requests targeted at a
+ scheduling Outbox collection.
+
+ Scheduling message: A calendar object resource that describes a
+ scheduling transaction such as publish, schedule, reschedule,
+ respond to scheduling requests, or cancel calendar components.
+
+ Scheduling Outbox collection: A resource at which explicit
+ scheduling requests are targeted.
+
+ Scheduling Inbox collection: A collection in which a recipient's
+ incoming scheduling messages are delivered.
+
+1.5. Open Issues
+
+ 1. Need to discuss in a limited fashion how group calendar user
+ addresses might be handled.
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 6]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ 2. Need a mechanism to allow clients to be able to do "weak" If-
+ Match updates to calendar data without the "strong" ETag
+ behavior.
+
+2. CalDAV Scheduling Support
+
+ In order for a server to support the scheduling extensions defined in
+ this specification it MUST support all of the CalDAV calendar-access
+ feature [RFC4791].
+
+ A server that supports the features described in this document MUST
+ include "calendar-auto-schedule" as a field in the DAV response
+ header from an OPTIONS request on any resource that supports any
+ scheduling actions, properties, privileges or methods.
+
+ >> Request <<
+
+ OPTIONS /lisa/calendar/outbox/ HTTP/1.1
+ Host: cal.example.com
+
+ >> Response <<
+
+ HTTP/1.1 204 No Content
+ Date: Thu, 31 Mar 2005 09:00:00 GMT
+ Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE,
+ Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
+ DAV: 1, 2, 3, access-control
+ DAV: calendar-access, calendar-auto-schedule
+
+ In this example, the OPTIONS response indicates that the server
+ supports both the "calendar-access" and "calendar-auto-schedule"
+ features and that resource "/lisa/calendar/outbox/" supports the
+ properties, reports, methods, and privileges defined in this
+ specification.
+
+3. Scheduling Process
+
+ The process of scheduling a meeting between different parties often
+ involves a series of steps with different "actors" playing particular
+ roles during the whole process. Typically there is a meeting
+ "Organizer" whose role is to setup a meeting between one or more
+ meeting "Attendees", and this is done by sending out invitations and
+ handling responses from each Attendee.
+
+ This process can typically be broken down into two phases.
+
+ In the first phase, the Organizer tries to determine a time for the
+ meeting that ought to be acceptable to each Attendee. This involves
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 7]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ finding out when each Attendee is available during the period of time
+ in which the meeting needs to occur (or simply finding a suitable
+ time for all attendees to come together for the meeting), and
+ determining when the most appropriate time is for which each Attendee
+ is free. This process is called a "freebusy" lookup.
+
+ In the second phase, the Organizer sends out invitations to each
+ Attendee using the time determined from the freebusy lookup - or a
+ suitable guess as to an appropriate time based on other factors if
+ freebusy lookup is not feasible. There then follows a process of
+ negotiation between Organizer and Attendees regarding the invitation.
+ Some Attendees may choose to attend at the original time provided by
+ the Organizer, others may decline to attend. The Organizer needs to
+ process each of the replies from the Attendees and take appropriate
+ action to confirm the meeting, reschedule it or perhaps cancel it.
+
+ The user "expectation" as to how a calendaring and scheduling system
+ should respond in each of these two phases is somewhat different. In
+ the case of a freebusy lookup, users expect to get back results
+ immediately so that they can then move on to the invitation phase as
+ quickly as possible. In the case of invitations, it is expected that
+ each Attendee will reply with their participation status in their own
+ time, so delays in receiving replies are anticipated. Thus
+ calendaring and scheduling systems should treat these two operational
+ phases in different ways to accommodate the user expectations, and
+ this specification does that.
+
+ The scenario above covers the case of scheduling events ("VEVENT"
+ components) between calendar users, and doing freebusy lookups
+ ("VFREEBUSY" components). However, iCalendar [RFC2445] also allows
+ for sending "VTODO" and "VJOURNAL" components as described in iTIP
+ [RFC2446]. Since this specification is based on iTIP, "VTODO" and
+ "VJOURNAL" components can also be used. For the majority of the
+ following discussion, scheduling of events and freebusy lookups will
+ be discussed as these are the more common operations.
+
+ In this specification there are two primary modes of carrying out a
+ scheduling transaction. For an "automatic scheduling transaction",
+ calendar data created, modified or removed from calendar collections
+ cause scheduling operations to occur. For an "explicit scheduling
+ request", scheduling operations are triggered by an HTTP POST request
+ to a special resource. iTIP freebusy lookups and iTIP "METHOD:
+ REFRESH" operations are done via explicit scheduling requests. All
+ other scheduling operations defined in iTIP, except for "METHOD:
+ COUNTER" and "METHOD:DECLINECOUNTER" which are not supported, are
+ done via automatic scheduling transactions.
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 8]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+3.1. Scheduling Collections
+
+ This specification introduces new collection resource types that are
+ used for managing resources specific to scheduling, in addition to
+ regular calendar object resources.
+
+3.1.1. Scheduling Outbox Collection
+
+ A scheduling Outbox collection is used as the target for initiating
+ the processing of manual scheduling messages. Currently the only
+ defined use for this is for "VFREEBUSY" "REQUEST" iTIP messages to
+ request a synchronous freebusy lookup for a number of calendar users.
+
+ A scheduling Outbox collection MUST report the DAV:collection and
+ CALDAV:schedule-outbox XML elements in the value of the DAV:
+ resourcetype property. The element type declaration for CALDAV:
+ schedule-outbox is:
+
+ <!ELEMENT schedule-outbox EMPTY>
+
+ Example:
+
+ <resourcetype xmlns="DAV:">
+ <collection/>
+ <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
+ </resourcetype>
+
+ New WebDAV ACL [RFC3744] privileges can be used on the scheduling
+ Outbox collection to control who is allowed to send scheduling
+ messages on behalf of the calendar user associated with the
+ scheduling Outbox collection. See Section 9.1 for more details.
+
+ A scheduling Outbox collection MUST NOT be a child (at any depth) of
+ a calendar collection resource.
+
+ A scheduling Outbox collection MAY have the following WebDAV
+ properties defined (as per calendar collections in [RFC4791]):
+
+ CALDAV:supported-calendar-component-set - when present this
+ indicates the allowed calendar component types for scheduling
+ messages submitted to the scheduling Outbox collection with the
+ POST method.
+
+ CALDAV:supported-calendar-data - when present this indicates the
+ allowed media types for scheduling messages submitted to the
+ scheduling Outbox collection with the POST method.
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 9]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ CALDAV:max-resource-size - when present this indicates the maximum
+ size of a resource in octets that the server is willing to accept
+ for scheduling messages submitted to the scheduling Outbox
+ collection with the POST method.
+
+ CALDAV:min-date-time - when present this indicates the earliest
+ date and time (in UTC) that the server is willing to accept for
+ any DATE or DATE-TIME value in scheduling messages submitted to
+ the scheduling Outbox collection with the POST method.
+
+ CALDAV:max-date-time - when present this indicates the latest date
+ and time (in UTC) that the server is willing to accept for any
+ DATE or DATE-TIME value in scheduling messages submitted to the
+ scheduling Outbox collection with the POST method.
+
+ CALDAV:max-instances - when present this indicates the maximum
+ number of recurrence instances in scheduling messages submitted to
+ the scheduling Outbox collection with the POST method.
+
+ CALDAV:max-attendees-per-instance - when present this indicates
+ the maximum number of ATTENDEE properties in any instance of
+ scheduling messages submitted to the scheduling Outbox collection
+ with the POST method.
+
+3.1.2. Scheduling Inbox Collection
+
+ A scheduling Inbox collection contains incoming scheduling messages.
+ These may be requests sent by an Organizer, or replies sent by an
+ Attendee in response to a request.
+
+ A scheduling Inbox collection MUST report the DAV:collection and
+ CALDAV:schedule-inbox XML elements in the value of the DAV:
+ resourcetype property. The element type declaration for CALDAV:
+ schedule-inbox is:
+
+ <!ELEMENT schedule-inbox EMPTY>
+
+ Example:
+
+ <resourcetype xmlns="DAV:">
+ <collection/>
+ <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
+ </resourcetype>
+
+ Every resource in the scheduling Inbox collection MUST be a valid
+ calendar object resource that defines a scheduling message (i.e. an
+ iCalendar object that follows the iTIP semantic). Note, that unlike
+ calendar collections defined by the CalDAV calendar-access feature,
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 10]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ there are no restrictions on the nature of the resources stored
+ (e.g., there is no need to verify that the "UID"s of each resource
+ are unique) beyond the restrictions of iTIP itself. The removal of
+ the "UID" restriction, in particular, is needed because multiple
+ scheduling messages may be sent for one particular calendar
+ component, and each of those will have the same "UID" property in the
+ calendar object resource. This also implies that a scheduling Inbox
+ collection cannot contain any types of WebDAV collection resources.
+
+ New WebDAV ACL [RFC3744] privileges can be set on the scheduling
+ Inbox collection to control who the user associated with the
+ scheduling Inbox collection will accept scheduling messages from.
+ See Section 9.1 for more details.
+
+ A scheduling Inbox collection MUST NOT be a child (at any depth) of a
+ calendar collection resource.
+
+ A scheduling Inbox collection MAY have the following WebDAV
+ properties defined (as per calendar collections in [RFC4791]):
+
+ CALDAV:calendar-timezone - when present this contains a time zone
+ that the server can use when calendar date-time operations are
+ carried out, for example when a time-range CALDAV:calendar-query
+ REPORT is targeted at a scheduling Inbox collection.
+
+ CALDAV:supported-calendar-component-set - when present this
+ indicates the allowed calendar component types for scheduling
+ messages delivered to the scheduling Inbox collection.
+
+ CALDAV:supported-calendar-data - when present this indicates the
+ allowed media types for scheduling messages delivered to the
+ scheduling Inbox collection.
+
+ CALDAV:max-resource-size - when present this indicates the maximum
+ size of a resource in octets that the server is willing to accept
+ for scheduling messages delivered to the scheduling Inbox
+ collection.
+
+ CALDAV:min-date-time - when present this indicates the earliest
+ date and time (in UTC) that the server is willing to accept for
+ any DATE or DATE-TIME value in scheduling messages delivered to
+ the scheduling Inbox collection.
+
+ CALDAV:max-date-time - when present this indicates the latest date
+ and time (in UTC) that the server is willing to accept for any
+ DATE or DATE-TIME value in scheduling messages delivered to the
+ scheduling Inbox collection.
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 11]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ CALDAV:max-instances - when present this indicates the maximum
+ number of recurrence instances in scheduling messages delivered to
+ the scheduling Inbox collection.
+
+ CALDAV:max-attendees-per-instance - when present this indicates
+ the maximum number of ATTENDEE properties in any instance of
+ scheduling messages delivered to the scheduling Inbox collection.
+
+3.2. Automatic Scheduling Transactions
+
+3.2.1. Introduction
+
+ When a calendar object resource is created, modified or removed from
+ a calendar collection that supports the operations defined in this
+ specification (either via a PUT, DELETE, COPY or MOVE HTTP request),
+ the server examines the calendar data and checks to see whether the
+ data represents a scheduling object resource. If it does, the server
+ will take care of automatically sending and processing scheduling
+ messages to the appropriate recipients. Several types of scheduling
+ operation can occur in this case, equivalent to iTIP "REQUEST",
+ "REPLY", "CANCEL" and "ADD" operations.
+
+ When a scheduling transaction is processed by the server, it will
+ attempt to deliver a scheduling message to each recipient.
+
+3.2.2. Identifying Scheduling Object Resources
+
+ The server will only perform automatic scheduling transactions on
+ creations, modifications, and deletions of valid scheduling object
+ resources. There are two types of scheduling object resources:
+ organizer scheduling object resources, and attendee scheduling object
+ resources.
+
+ A calendar object resource is considered to be a valid organizer
+ scheduling object resource if the "ORGANIZER" iCalendar property is
+ present and set in all the calendar components to a value that
+ matches one of the calendar user addresses of the owner of the
+ calendar collection.
+
+ A calendar object resource is considered to be a valid attendee
+ scheduling object resource if the "ORGANIZER" iCalendar property is
+ present and set in all the calendar components to the same value and
+ doesn't match one of the calendar user addresses of the owner of the
+ calendar collection, and that at least one of the "ATTENDEE"
+ iCalendar property values match one of the calendar user addresses of
+ the owner of the calendar collection.
+
+ The creation of attendee scheduling object resources will typically
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 12]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ be done by the server in cases where a default calendar collection is
+ defined (see Section 3.5.2. In cases where no default calendar
+ collection is defined, the server MAY prevent calendar user agents
+ from forging attendee scheduling object resources by forbidding their
+ creation or imposing restrictions on their creation. For instance, a
+ server MAY require the presence of a scheduling message, received
+ from the "ORGANIZER" with the same "UID" property value, in the
+ scheduling Inbox collection of the owner of the calendar collection.
+
+3.2.3. Handling Scheduling Object Resources
+
+ The server's behavior when processing a scheduling object resource
+ depends on whether it is owned by the Organizer or an Attendee
+ specified in the calendar data.
+
+3.2.3.1. Organizer Scheduling Object Resources
+
+ An Organizer can create, modify or remove a scheduling object
+ resource by issuing HTTP requests with an appropriate method. The
+ create, modify and remove behaviors for the server are each described
+ next, and the way these are invoked via HTTP requests is described in
+ Section 3.2.3.3.
+
+3.2.3.1.1. Actions on Organizer Scheduling Object Resource
+
+3.2.3.1.1.1. Create
+
+ When a scheduling object resource is created by the Organizer, the
+ server will inspect each "ATTENDEE" property to determine which ones
+ have the "SCHEDULE-AGENT" iCalendar property parameter.
+
+ For each Attendee the server will determine whether to attempt to
+ deliver a scheduling message into the Attendee's scheduling Inbox
+ collection, based on the table below:
+
+ +------------------+-------------+
+ | SCHEDULE-AGENT | iTIP METHOD |
+ +==================+=============+
+ | SERVER (default) | REQUEST |
+ +------------------+-------------+
+ | CLIENT | -- |
+ +------------------+-------------+
+ | NONE | -- |
+ +------------------+-------------+
+
+ The attempt to deliver the scheduling message will either succeed or
+ fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
+ iCalendar property parameter to the "ATTENDEE" iCalendar property in
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 13]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ the scheduling object resource being created, and set its value as
+ described in Section 3.5.4. This will result in the created calendar
+ object resource differing from the calendar data sent in the HTTP
+ request. As a result clients MAY reload the calendar data from the
+ server as soon as it is stored in order to update to the new server
+ generated state information. Servers MUST NOT set the "SCHEDULE-
+ STATUS" property on any "ATTENDEE" properties for Attendees that were
+ not sent a scheduling message.
+
+ Restrictions:
+
+ 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar
+ property parameter value of the "ATTENDEE" iCalendar property of
+ other users in the calendar object resource to a value other than
+ "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value
+ is not present or set to the value "SERVER". To maintain
+ consistency for organizers and attendees hosted on the server
+ itself, a server will typically choose to enforce the requirement
+ that only an Attendee can change their own "PARTSTAT" to a value
+ other than "NEEDS-ACTION".
+
+ 2. The server MUST reject any attempt to create a duplicate
+ scheduling object resource in any of the calendar collections
+ owned by the Organizer. A duplicate scheduling object resource
+ is one with the same "UID" as an existing scheduling object
+ resource.
+
+ 3. The server MUST take into account scheduling privileges when
+ handling the creation of a scheduling object resource as
+ described in Section 9.1.
+
+ 4. Restrictions from [RFC4791] MUST also be enforced.
+
+3.2.3.1.1.2. Modify
+
+ When a scheduling object resource is modified by the Organizer, the
+ server will inspect each "ATTENDEE" property in the new calendar data
+ to determine which ones have the "SCHEDULE-AGENT" iCalendar property
+ parameter. It will then need to compare this with the "ATTENDEE"
+ properties in the existing calendar object resource that is being
+ modified.
+
+ For each Attendee in the old and new calendar data on a per-instance
+ basis, and taking into account the addition or removal of Attendees,
+ the server will determine whether to deliver a scheduling message to
+ the Attendee. The following table determines whether the server
+ needs to deliver a scheduling message, and if so which iTIP
+ scheduling method to use. The values "SERVER", "CLIENT" and "NONE"
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 14]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ in the top and left titles of the table refer to the "SCHEDULE-AGENT"
+ parameter value of the "ATTENDEE" property, and the values "<Absent>"
+ and "<Removed>" are used to cover the cases where the "ATTENDEE"
+ property is not present (Old) or is being removed (New).
+
+ +---------------+-----------------------------------------------+
+ | | New |
+ | ATTENDEE +-----------+-----------+-----------+-----------+
+ | | <Removed> | SERVER | CLIENT | NONE |
+ | | | (default) | | |
+ +===+===========+===========+===========+===========+===========+
+ | | <Absent> | -- | REQUEST / | -- | -- |
+ | | | | ADD | | |
+ | +-----------+-----------+-----------+-----------+-----------+
+ | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL |
+ | O | (default) | | | | |
+ | l +-----------+-----------+-----------+-----------+-----------+
+ | d | CLIENT | -- | REQUEST / | -- | -- |
+ | | | | ADD | | |
+ | +-----------+-----------+-----------+-----------+-----------+
+ | | NONE | -- | REQUEST / | -- | -- |
+ | | | | ADD | | |
+ +---+-----------+-----------+-----------+-----------+-----------+
+
+ The attempt to deliver the scheduling message will either succeed or
+ fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
+ iCalendar property parameter to the "ATTENDEE" iCalendar property in
+ the scheduling object resource being modified, and set its value as
+ described in Section 3.5.4. This will result in the created calendar
+ object resource differing from the calendar data sent in the HTTP
+ request. As a result clients MAY reload the calendar data from the
+ server as soon as it is stored in order to update to the new server
+ generated state information.
+
+ Restrictions:
+
+ 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar
+ property parameter value of the "ATTENDEE" iCalendar property of
+ other users in the calendar object resource to a value other than
+ "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value
+ is not present or set to the value "SERVER". To maintain
+ consistency for organizers and attendees hosted on the server
+ itself, a server will typically choose to enforce the requirement
+ that only an Attendee can change their own "PARTSTAT" to a value
+ other than "NEEDS-ACTION".
+
+ 2. The server MUST take into account scheduling privileges when
+ handling the modification of a scheduling object resources as
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 15]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ described in Section Section 9.1.
+
+ 3. Restrictions from [RFC4791] MUST also be enforced.
+
+3.2.3.1.1.3. Remove
+
+ When a scheduling object resource is removed by the Organizer, the
+ server will inspect each "ATTENDEE" property in the scheduling object
+ resource being removed to determine which ones have the "SCHEDULE-
+ AGENT" iCalendar property parameter.
+
+ For each Attendee the server will determine whether to attempt to
+ deliver a scheduling message into the Attendee's scheduling Inbox
+ collection, based on the table below:
+
+ +------------------+-------------+
+ | SCHEDULE-AGENT | iTIP METHOD |
+ +==================+=============+
+ | SERVER (default) | CANCEL |
+ +------------------+-------------+
+ | CLIENT | -- |
+ +------------------+-------------+
+ | NONE | -- |
+ +------------------+-------------+
+
+ The attempt to deliver the scheduling message will either succeed or
+ fail.
+
+ Restrictions:
+
+ 1. The server MUST take into account scheduling privileges when
+ handling the removal of a scheduling object resource as described
+ in Section 9.1.
+
+3.2.3.2. Attendee Scheduling Object Resources
+
+ An Attendee can create, modify or remove a scheduling object resource
+ by issuing HTTP requests with an appropriate method. The create,
+ modify and remove behaviors for the server are each described next,
+ and the way these are invoked via HTTP requests is described in
+ Section 3.2.3.3.
+
+3.2.3.2.1. Actions on a Scheduling Object Resource
+
+3.2.3.2.1.1. Allowed Attendee Changes
+
+ Attendees are allowed to make some changes to a scheduling object
+ resource, though the key scheduling properties such as start, end,
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 16]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ location, summary etc are typically under the control of the
+ Organizer of the event.
+
+ The server MUST allow attendees to:
+
+ 1. change their own "PARTSTAT" iCalendar property parameter value.
+
+ 2. add or remove "X-" iCalendar property parameters on their own
+ "ATTENDEE" properties.
+
+ 3. add, modify or remove any "TRANSP" iCalendar properties.
+
+ 4. add, modify or remove any "X-" iCalendar properties in any
+ component.
+
+ 5. add, modify or remove any "VALARM" iCalendar components.
+
+ 6. modify the "PRODID" iCalendar property within the top-level
+ "VCALENDAR" component.
+
+ 7. add, modify or remove "CALSCALE" or "X-" iCalendar properties
+ within the top-level "VCALENDAR" component.
+
+ 8. create new components to represent overridden recurrence
+ instances, provided the only changes to the recurrence instance
+ follow the rules above.
+
+3.2.3.2.1.2. Create
+
+ A scheduling object resource is created by an Attendee when the
+ client creates a scheduling object resource corresponding to an
+ unprocessed scheduling message currently in that Attendee's
+ scheduling Inbox collection.
+
+ The Attendee is allowed to make changes as noted above.
+
+ If the Attendee changes one or more "PARTSTAT" iCalendar property
+ values on any component, or adds an overridden component with a
+ changed "PARTSTAT" property, then the server MUST deliver an iTIP
+ "REPLY" scheduling message to the Organizer to indicate the new
+ participation status of the Attendee.
+
+ The attempt to deliver the scheduling message will either succeed or
+ fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
+ iCalendar property parameter to the "ORGANIZER" iCalendar property in
+ the scheduling object resource being created, and set its value as
+ described in Section 3.5.4. This will result in the created calendar
+ object resource differing from the calendar data sent in the HTTP
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 17]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ request. As a result clients MAY reload the calendar data from the
+ server as soon as it is stored in order to update to the new server
+ generated state information.
+
+3.2.3.2.1.3. Modify
+
+ Behavior is as per the Create action above.
+
+3.2.3.2.1.4. Remove
+
+ When a scheduling object resource is removed by the Attendee, one of
+ two possibilities exist:
+
+ 1. If the HTTP request contains a request header "Schedule-Reply"
+ set to the value "T" or there is no "Schedule-Reply" request
+ header, then the server MUST attempt to deliver a scheduling
+ message to the Organizer indicating that the Attendee has a
+ "PARTSTAT" iCalendar property parameter value set to "DECLINED".
+ i.e., the Attendee has chosen not to attend any instances. If
+ the server is unable to deliver the scheduling message, the
+ remove action MUST fail, and an appropriate "SCHEDULE-STATUS"
+ iCalendar property parameter set on the "ORGANIZER" property in
+ the scheduling object resource stored by the server.
+
+ 2. If the HTTP request contains a request header "Schedule-Reply"
+ set to the value "F", the server MUST NOT attempt to deliver a
+ scheduling message. The resource is simply removed. This
+ provides the client a way to silently remove unwanted scheduling
+ attempts.
+
+3.2.3.3. HTTP Methods
+
+ This section describes how use of various HTTP Methods on a
+ scheduling object resource will cause a create, modify or remove
+ action on that resource as described above.
+
+3.2.3.3.1. PUT
+
+ When a PUT method request is received, the server will execute the
+ following actions, provided all appropriate pre-conditions are met:
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 18]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ +--------------------------+--------------------------+-------------+
+ | Existing Destination | Resulting Destination | Server |
+ | Resource | Resource | Action |
+ +--------------------------+--------------------------+-------------+
+ | None | Calendar object resource | None (1) |
+ | None | Scheduling object | Create (2) |
+ | | resource | |
+ | Calendar object resource | Calendar object resource | None |
+ | Calendar object resource | Scheduling object | Create (1) |
+ | | resource | |
+ | Scheduling object | Calendar object resource | Remove |
+ | resource | | |
+ | Scheduling object | Scheduling object | Modify |
+ | resource | resource | |
+ +--------------------------+--------------------------+-------------+
+
+ Note 1. The server MUST verify that no scheduling object resource
+ exists in any other of the owner's calendar collections with the same
+ UID as the resource being created.
+
+ Note 2. The server MUST verify that no calendar object resource
+ exists in any other of the owner's calendar collections with the same
+ UID as the resource being created.
+
+3.2.3.3.2. COPY
+
+ When a COPY method request is received, the server will execute the
+ following actions based on the source and destination collections in
+ the request:
+
+ +-------------------------+-------------------------+---------------+
+ | Source Collection | Destination Collection | Server Action |
+ +-------------------------+-------------------------+---------------+
+ | Non-calendar collection | Non-calendar collection | None |
+ | Non-calendar collection | Calendar collection | (1) |
+ | Calendar collection | Non-calendar collection | None |
+ | Calendar collection | Calendar collection | (2) |
+ +-------------------------+-------------------------+---------------+
+
+ Note 1. The same rules as used for PUT above are applied for the
+ destination of the COPY request.
+
+ Note 2. If the resource being copied is a scheduling object resource
+ the server MUST generate an error as scheduling object resources
+ cannot be duplicated. If the resource being copied is not a
+ scheduling object resource no server action occurs.
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 19]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+3.2.3.3.3. MOVE
+
+ When a MOVE method request is received, the server will execute the
+ following actions based on the source and destination collections in
+ the request:
+
+ +-------------------------+-------------------------+---------------+
+ | Source Collection | Destination Collection | Server Action |
+ +-------------------------+-------------------------+---------------+
+ | Non-calendar collection | Non-calendar collection | None |
+ | Non-calendar collection | Calendar collection | (1) |
+ | Calendar collection | Non-calendar collection | (2) |
+ | Calendar collection | Calendar collection | (3) |
+ +-------------------------+-------------------------+---------------+
+
+ Note 1. The same rules as used for PUT above are applied for the
+ destination of the MOVE request.
+
+ Note 2. The same rules as used for DELETE below are applied for the
+ source of the MOVE request.
+
+ Note 3. If the destination resource does not exist the server action
+ is None. If the source and destination resources are not scheduling
+ object resources then the server action is None. In all other cases
+ the server MUST generate an error as scheduling object resources
+ cannot be duplicated or overwritten by different scheduling object
+ resources.
+
+3.2.3.3.4. DELETE
+
+ When a DELETE method is targeted at a scheduling object resource the
+ server will execute the Remove action.
+
+ When a DELETE method is targeted at a calendar collection the server
+ will execute the Remove action on all scheduling object resources
+ contained in the calendar collection.
+
+3.3. Processing of incoming scheduling messages
+
+ Scheduling operations can cause the delivery of a scheduling message
+ into an Organizer's or Attendee's scheduling Inbox collection. In
+ the former case the scheduling messages are replies or refresh
+ requests from Attendees, in the latter case the scheduling messages
+ are requests, cancellations or additions from the Organizer.
+
+ In some cases the server will automatically process the scheduling
+ message, in other cases the scheduling message will be left for the
+ client to process. In each case, the scheduling message in the
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 20]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ scheduling Inbox collection is used as an indicator to the client
+ that a scheduling operation has taken place.
+
+3.3.1. Automatic processing for the Organizer
+
+3.3.1.1. Processing an Attendee reply
+
+ For a scheduling message reply sent by an Attendee, the server first
+ locates the corresponding scheduling object resource belonging to the
+ Organizer.
+
+ The server MUST then update the "PARTSTAT" iCalendar parameter value
+ of each "ATTENDEE" iCalendar property in the scheduling object
+ resource to match the changes indicated in the reply (taking into
+ account the fact that an Attendee could have created a new overridden
+ iCalendar component to indicate different participation status on one
+ or more instances of a recurring event).
+
+ The server MUST also update or add the "SCHEDULE-STATUS" property
+ parameter on each matching "ATTENDEE" iCalendar property and sets its
+ value to that of the "REQUEST-STATUS" property in the reply, or to
+ "2.0" if "REQUEST-STATUS" is not present (also taking into account
+ recurrence instances).
+
+ At the same time, the server MUST add the CALDAV:schedule-state
+ WebDAV property with the value CALDAV:schedule-processed (see
+ Section 6.3) to the scheduling message in the Inbox scheduling
+ collection.
+
+ The server MUST send scheduling messages to all the other Attendees
+ indicating the change in participation status of the Attendee
+ replying, subject to the recurrence requirements of Section 3.5.1.
+
+3.3.1.2. Processing an Attendee refresh
+
+ TODO: write something here.
+
+3.3.2. Automatic processing for the Attendee
+
+ For a scheduling message sent by the Organizer, the server first
+ tries to locate a corresponding scheduling object resource belonging
+ to the Attendee. If no matching scheduling object resource exists,
+ the server treats the scheduling message as a new message, otherwise
+ it is treated as an update.
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 21]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+3.3.2.1. Processing a new scheduling message
+
+ When a scheduling message containing new calendar components is
+ detected, two possibilities exist, depending on whether a "default"
+ calendar (Section 3.5.2) is set for the Attendee:
+
+ 1. if no valid default calendar is set, the server leaves the
+ scheduling message in the scheduling Inbox collection, but it
+ MUST add the CALDAV:schedule-state WebDAV property with the value
+ CALDAV:schedule-unprocessed (see Section 6.3) to the scheduling
+ message. It is then up to the client to explicitly process the
+ scheduling message and remove it from the scheduling Inbox
+ collection once it has done so.
+
+ 2. if a valid default calendar is set, the server MUST process the
+ scheduling message and create an appropriate scheduling object
+ resource in the default calendar set for the Attendee. At the
+ same time it MUST add the CALDAV:schedule-state WebDAV property
+ with the value CALDAV:schedule-processed (see Section 6.3) to the
+ scheduling message.
+
+3.3.2.2. Processing a scheduling message update
+
+ When an update to scheduling message is detected, the server MUST
+ update the matching scheduling object resource belonging to the
+ Attendee to reflect the changes proposed in the scheduling message.
+ At the same time it MUST add the CALDAV:schedule-state WebDAV
+ property with the value CALDAV:schedule-processed (see Section 6.3)
+ to the scheduling message.
+
+3.3.3. Processing by the client
+
+ When a client detects a scheduling message in the scheduling Inbox
+ collection it needs to look at the CALDAV:schedule-state WebDAV
+ property on the resource and act accordingly:
+
+ 1. if CALDAV:schedule-state is set to CALDAV:schedule-unprocessed,
+ then it is the client's responsibility to process the scheduling
+ message and remove it from the scheduling Inbox collection once
+ it has done so.
+
+ 2. if CALDAV:schedule-state is set to CALDAV:schedule-processed,
+ then the server has already processed the scheduling message, but
+ has left it in the scheduling Inbox collection to serve as a
+ notification to the client that a change has been made to the
+ corresponding scheduling object resource. It is then the
+ client's responsibility to remove the scheduling object resource
+ from the scheduling Inbox collection once it has made note of the
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 22]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ fact that a change has occurred.
+
+3.4. Explicit Scheduling Request
+
+ An explicit scheduling request sends a scheduling message via an HTTP
+ POST request targeted at a scheduling Outbox collection. Full
+ details can be found in Section 8.1.
+
+3.5. Other Considerations
+
+3.5.1. Handling recurring items
+
+3.5.1.1. Restricting what is sent
+
+ When delivering scheduling messages for recurring calendar components
+ to Attendees, servers MUST ensure that Attendees only get information
+ about recurrence instances that explicitly include them as an
+ Attendee.
+
+ For example, if an Attendee is invited to a single recurrence
+ instance of a recurring event, and no others, the scheduling object
+ resource contained in the Organizer's calendar collection will
+ contain an overridden instance in the form of a separate calendar
+ component. That separate calendar component will include the
+ "ATTENDEE" property referencing the "one-off" Attendee. That
+ Attendee will not be listed in any other calendar components in the
+ scheduling object resource. The scheduling message that will be
+ delivered to the Attendee will only contain information about this
+ overridden instance.
+
+ As another example, an Attendee could be excluded from one instance
+ of a recurring event. In that case the scheduling object resource
+ contained in the calendar collection of the Organizer will include an
+ overridden instance with an "ATTENDEE" list that does not include the
+ Attendee being excluded. The scheduling message that will be
+ delivered to the Attendee will not specify the overridden instance
+ but rather include an "EXDATE" property in the master recurring
+ component defining the recurrence set.
+
+ This requirement is needed to ensure that Attendees only have access
+ to calendar data for items they have been explicitly invited to.
+
+3.5.1.2. Attendee overrides
+
+ When a recurring scheduling message is sent to an Attendee, that
+ Attendee may wish to reply with different participation status on one
+ or more recurrence instances. In order to do that it will need to
+ add an overridden iCalendar component for the instances with
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 23]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ different participation status, and send that as a reply back to the
+ Organizer. The Organizer will then need to incorporate any new
+ overridden instances into the matching scheduling object resource to
+ ensure that the Attendee's participation status is accurately
+ recorded for all recurrence instances.
+
+3.5.2. Handling the Default Calendar
+
+ A calendar user may have multiple calendars representing different
+ "spheres of activity". However, scheduling requests are targeted at
+ calendar users and not a specific calendar of a calendar user. Often
+ it is not appropriate to automatically deliver a scheduling message
+ to a particular calendar because that scheduling message refers to an
+ event for a different "sphere of activity". By storing all incoming
+ scheduling requests in a separate special collection, clients can
+ process the requests in that collection and choose which calendar
+ ("sphere of activity") the request belongs to and make its own
+ arrangements to place the relevant calendar object in that calendar.
+
+ This specification defines the concept of a "default" calendar
+ collection. If a valid default calendar collection is specified,
+ then servers are required to automatically process new scheduling
+ messages and create the appropriate scheduling object resource in the
+ default calendar collection. If there is no valid default calendar,
+ then the server does not automatically process new scheduling
+ messages, and instead leaves it up to the client to process the
+ scheduling message and create the appropriate scheduling object
+ resource in a calendar collection chosen by the calendar user.
+ Servers MAY prevent deletion of the default calendar.
+
+ In order to manage this behavior, a new CALDAV:schedule-default-
+ calendar-URL WebDAV property is defined for use on scheduling Inbox
+ collections. This property is used to define the default calendar
+ collection, if one is required. See Section 6.2.
+
+3.5.3. DTSTAMP and SEQUENCE properties
+
+ Whenever the server generates a scheduling message for delivery to a
+ recipient, it MUST ensure that a "DTSTAMP" iCalendar property is
+ present and MUST set the value to the UTC time that the scheduling
+ message was generated (as required by iCalendar).
+
+ iTIP [RFC2446] places certain requirements on how the "SEQUENCE"
+ iCalendar property value in scheduling messages changes. The server
+ MUST ensure that for each type of scheduling operation, the
+ "SEQUENCE" iCalendar property value is appropriately updated. If the
+ client does not update the "SEQUENCE" iCalendar property itself when
+ that is required, the server MUST update the property and change any
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 24]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ scheduling object resource accordingly.
+
+3.5.4. Schedule Status Values
+
+ When scheduling with an Attendee there are two types of status
+ information that can be returned during the transaction. The first
+ status information is a "delivery" status that indicates whether the
+ scheduling message from the Organizer to the Attendee was delivered
+ or not, or what the current status of delivery is. The second status
+ information is a "reply" status corresponding to the Attendee's own
+ "REQUEST-STATUS" information from the scheduling message reply that
+ is sent back to the Organizer.
+
+ Similarly, when an Attendee sends a reply back to the Organizer,
+ there will be "delivery" status information for the scheduling
+ message sent to the Organizer. However, there is no "REQUEST-STATUS"
+ sent back by the Organizer, so there is no equivalent of the "reply"
+ status as per scheduling messages to Attendees.
+
+ The "delivery" status information on an "ORGANIZER" or "ATTENDEE"
+ iCalendar property is conveyed in the "SCHEDULE-STATUS" property
+ parameter value (Section 4.2). The status code value for "delivery"
+ status can be one of the following:
+
+ +----------+--------------------------------------------------------+
+ | Delivery | Description |
+ | Status | |
+ | Code | |
+ +----------+--------------------------------------------------------+
+ | 1.0 | The scheduling message is pending. i.e. the server is |
+ | | still in the process of sending the message. The |
+ | | status code value can be expected to change once the |
+ | | server has completed its sending and delivery |
+ | | attempts. |
+ | | |
+ | 1.1 | The scheduling message has been successfully sent. |
+ | | However, the server does not have explicit information |
+ | | about whether the scheduling message was successfully |
+ | | delivered to the recipient. This state can occur with |
+ | | "store and forward" style scheduling protocols such as |
+ | | iMIP [RFC2447] (iTIP using email). |
+ | | |
+ | 1.2 | The scheduling message has been successfully |
+ | | delivered. |
+ | | |
+ | 3.7 | The scheduling message was not delivered because the |
+ | | server did not recognize the calendar user address of |
+ | | the recipient as being a supported URI. |
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 25]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ | | |
+ | 3.8 | The scheduling message was not delivered because |
+ | | access privileges do not allow it. |
+ | | |
+ | 5.1 | The scheduling message was not delivered because the |
+ | | server could not complete delivery of the message. |
+ | | This is likely due to a temporary failure, and the |
+ | | originator can try to send the message again at a |
+ | | later time. |
+ | | |
+ | 5.2 | The scheduling message was not delivered because the |
+ | | server was not able to find a suitable way to deliver |
+ | | the message. This is likely a permanent failure, and |
+ | | the originator should not try to send the message |
+ | | again, at least without verifying/correcting the |
+ | | calendar user address of the recipient. |
+ | | |
+ | 5.3 | The scheduling message was not delivered and was |
+ | | rejected because scheduling with that recipient is not |
+ | | allowed. This is likely a permanent failure, and the |
+ | | originator should not try to send the message again. |
+ +----------+--------------------------------------------------------+
+
+ The status code for "reply" status can be any of the valid iTIP
+ [RFC2446] "REQUEST-STATUS" values.
+
+3.5.5. Error Handling
+
+ TODO: e.g. how to deal with failed cancels.
+
+3.5.6. Organizer is an Attendee
+
+ The Organizer of a scheduled event may also be an Attendee of that
+ event. In such cases the server MUST NOT send a scheduling message
+ to the Attendee that matches the Organizer.
+
+4. New iCalendar Parameters
+
+ This section describes additions to iCalendar [RFC2445] to support
+ CalDAV scheduling.
+
+4.1. Schedule Agent
+
+ Parameter Name: SCHEDULE-AGENT
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 26]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ Purpose: Indicates what agent is expected to handle scheduling for
+ the corresponding Attendee.
+
+ Format Definition: This property parameter is defined by the
+ following notation:
+
+ scheduleagentparam = "SCHEDULE-AGENT" "="
+ ("SERVER" ; The server handles scheduling
+ / "CLIENT" ; The client handles scheduling
+ / "NONE" ; No automatic scheduling
+ / x-name ; Experimental type
+ / iana-token) ; Other IANA registered type
+ ; Default is SERVER
+
+ Description: This property parameter MAY be present on any
+ "ATTENDEE" iCalendar property. In the absence of this parameter,
+ the value "SERVER" MUST be used for the default behavior. The
+ value determines whether or not an automatic scheduling
+ transaction on a server will cause a scheduling message to be sent
+ to the corresponding calendar user identified by the "ATTENDEE"
+ property value. When the value "SERVER" is specified (or the
+ parameter is absent) then it is the server's responsibility to
+ send a scheduling messages as part of an automatic scheduling
+ transaction. When the value "CLIENT" is specified, that indicates
+ that the client is handling scheduling messages with the calendar
+ user itself. When "NONE" is specified, no scheduling messages are
+ being sent to the calendar user.
+
+ Servers MUST NOT include this parameter in any scheduling messages
+ sent as the result of an automatic scheduling transaction.
+
+ Clients SHOULD NOT include this parameter in any scheduling
+ messages that they themselves send.
+
+ Example:
+
+ ATTENDEE;SCHEDULE-AGENT=SERVER:mailto:cyrus at example.org
+
+4.2. Schedule Status
+
+ Parameter Name: SCHEDULE-STATUS
+
+ Purpose: Indicates the status code returned from processing of the
+ most recent scheduling message sent to the corresponding Attendee,
+ or received from the corresponding Organizer.
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 27]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ Format Definition: This property parameter is defined by the
+ following notation:
+
+ schedulestatusparam = "SCHEDULE-STATUS" "=" statcode
+ ; statcode defined in RFC2445.
+
+ Description: This property parameter may be present on any
+ "ATTENDEE" or "ORGANIZER" iCalendar property.
+
+ Servers MUST add this parameter to any "ATTENDEE" properties
+ corresponding to calendar users who were sent a scheduling message
+ via an automatic scheduling transaction. Clients SHOULD NOT
+ change or remove this parameter if it was provided by the server.
+ In the case where the client is handling the scheduling, the
+ client MAY add, change or remove this parameter to indicate the
+ last scheduling message status it received.
+
+ Servers MUST add this parameter to any "ORGANIZER" properties
+ corresponding to calendar users who were sent a scheduling message
+ reply by an Attendee via an automatic scheduling transaction.
+ Clients SHOULD NOT change or remove this parameter if it was
+ provided by the server. In the case where the client is handling
+ the scheduling the client MAY add, change or remove this parameter
+ to indicate the last scheduling message status it received.
+
+ Servers MUST NOT include this parameter in any scheduling messages
+ sent as the result of an automatic scheduling transaction.
+
+ Clients SHOULD NOT include this parameter in any scheduling
+ messages that they themselves send.
+
+ Suitable values for this property parameter are described in
+ Section 3.5.4.
+
+ Example:
+
+ ATTENDEE;SCHEDULE-STATUS="2.0":mailto:cyrus at example.org
+
+5. New WebDAV Request Headers
+
+ The CalDAV scheduling extension defines the following new WebDAV
+ request headers for use with CalDAV.
+
+5.1. Schedule-Reply Request Header
+
+ ScheduleReply = "Schedule-Reply" ":" ("T" | "F")
+
+ When an Attendee executes an HTTP DELETE request on a scheduling
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 28]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ object resource, and the Schedule-Reply header is not present, or
+ present and set to the value "T", the server MUST send an appropriate
+ iTIP "REPLY" scheduling message with the Attendee's "PARTSTAT"
+ iCalendar property parameter value set to "DECLINED" as part of its
+ normal automatic scheduling transaction processing.
+
+ When the Schedule-Reply header is set to the value "F", the server
+ MUST NOT send an iTIP scheduling message as part of its normal
+ automatic scheduling transaction processing.
+
+ The Schedule-Reply request header is used by a client to indicate to
+ a server whether or not an automatic scheduling transaction should
+ occur when an Attendee deletes a scheduling object resource. In
+ particular it controls whether an iTIP "REPLY" message is sent to the
+ Organizer as a result of the deletion. There are situations in which
+ unsolicited scheduling messages need to be silently deleted (or
+ ignored) for security or privacy reasons. The new header allows the
+ scheduling message to be suppressed if such a need arises.
+
+ All scheduling object resources MUST support the Schedule-Reply
+ header.
+
+6. New WebDAV Properties
+
+ The CalDAV scheduling extension defines the following new WebDAV
+ properties for use with CalDAV.
+
+6.1. CALDAV:schedule-calendar-transp Property
+
+ Name: schedule-calendar-transp
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Determines whether the calendar object resources in a
+ calendar collection will affect the owner's freebusy.
+
+ Protected: This property MAY be protected and SHOULD NOT be returned
+ by a PROPFIND allprop request (as defined in Section 14.2 of
+ [RFC4918]).
+
+ COPY/MOVE behavior: This property value SHOULD be kept during a MOVE
+ operation, but is normally re-initialized when a resource is
+ created with a COPY. It should not be set in a COPY.
+
+ Description: This property SHOULD be defined on all calendar object
+ resources. If present, it contains one of two XML elements that
+ indicate whether the calendar object resources should contribute
+ to the owner's freebusy or not. When the 'opaque' element is
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 29]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ used, all calendar object resources MUST contribute to freebusy,
+ assuming access privileges and other iCalendar properties allow it
+ to. When the 'transparent' XML element is used, all calendar
+ object resources MUST NOT contribute to freebusy.
+
+ If this property is not present on a calendar collection, then the
+ default value of 'opaque' MUST be assumed.
+
+ Definition:
+
+ <!ELEMENT schedule-calendar-transp (opaque|transparent) >
+
+ <!ELEMENT opaque EMPTY>
+ <!-- Calendar object resources affect owner freebusy -->
+
+ <!ELEMENT transparent EMPTY>
+ <!-- Calendar object resources never affect owner freebusy -->
+
+ Example:
+
+ <C:schedule-calendar-transp
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:opaque/>
+ </C:schedule-calendar-transp>
+
+6.2. CALDAV:schedule-default-calendar-URL Property
+
+ Name: schedule-default-calendar-URL
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Specifies a default calendar for an attendee that will
+ automatically have new scheduling messages deposited into it when
+ they arrive.
+
+ Protected: This property MAY be protected in the case where a server
+ supports only a single calendar collection, or does not support
+ changing the default calendar, or does not support a default
+ calendar.
+
+ COPY/MOVE behavior: This property is only defined on a scheduling
+ Inbox collection which cannot be moved or copied.
+
+ Description: This property MAY be defined on a scheduling Inbox
+ collection. If present, it contains zero or one DAV:href XML
+ elements. When a DAV:href element is present, its value indicates
+ a URL to a calendar collection that is used as the default
+ calendar. When no DAV:href element is present, it indicates that
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 30]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ there is no default calendar. In the absence of this property
+ there is no default calendar.
+
+ Definition:
+
+ <!ELEMENT schedule-default-calendar-URL (DAV:href?) >
+
+ Example:
+
+ <C:schedule-default-calendar-URL xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:href>/calendars/users/cdaboo/calendar/</D:href>
+ </C:schedule-default-calendar-URL>
+
+6.3. CALDAV:schedule-state Property
+
+ Name: schedule-state
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Indicates whether a scheduling message in a scheduling
+ Inbox collection has been processed as part of an automatic
+ scheduling transaction.
+
+ Protected: This property MUST be protected as only the server can
+ carry out automatic processing of scheduling messages.
+
+ COPY/MOVE behavior: This property is only defined on a scheduling
+ message in a scheduling Inbox collection. If a scheduling message
+ is copied or moved into a scheduling Inbox collection, this
+ property MUST NOT be set.
+
+ Description: This property MAY be defined on a scheduling resource
+ in a scheduling Inbox collection. If present, it contains one of
+ two XML elements. When the CALDAV:schedule-unprocessed XML
+ element is used, it indicates that the scheduling message has not
+ been automatically processed by the server, and thus needs action
+ on the part of the client. When the CALDAV:schedule-processed XML
+ element is used, it indicates that automatic processing of the
+ scheduling message has taken place, so no scheduling operations
+ are needed by the client.
+
+ Definition:
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 31]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ <!ELEMENT schedule-state (schedule-processed|schedule-unprocessed) >
+
+ <!ELEMENT schedule-processed EMPTY>
+ <!-- Scheduling message has been automatically processed -->
+
+ <!ELEMENT schedule-unprocessed EMPTY>
+ <!-- Scheduling message has not been automatically processed -->
+
+ Example:
+
+ <C:schedule-state xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:schedule-processed/>
+ </C:schedule-state>
+
+7. New Preconditions
+
+7.1. Additional Preconditions for PUT, COPY and MOVE
+
+ This specification requires additional Preconditions for the PUT,
+ COPY and MOVE methods. The preconditions are:
+
+ (CALDAV:unique-scheduling-object-resource): Only one scheduling
+ object resource with a particular iCalendar property "UID" value
+ MUST exist in the system for each Organizer and each Attendee.
+
+ (CALDAV:same-organizer-in-all-components): All the calendar
+ components in a scheduling object resource MUST contain the same
+ "ORGANIZER" property value if the "ORGANIZER" property is present.
+
+7.2. Additional Preconditions for PUT
+
+ This specification requires additional Preconditions for the PUT
+ method. The preconditions are:
+
+ (CALDAV:allowed-organizer-scheduling-object-change): The following
+ restrictions exist for the "PARTSTAT" property value in scheduling
+ object resources created or modified by an Organizer:
+
+ 1. when creating a scheduling object resource the Organizer MAY
+ NOT set the "PARTSTAT" iCalendar parameter value to anything
+ other than "NEEDS-ACTION" if the corresponding "ATTENDEE"
+ property includes the "SCHEDULE-AGENT" iCalendar parameter
+ with its value set to "SERVER", or no "SCHEDULE-AGENT"
+ parameter is present.
+
+ 2. when modifying a scheduling object resource the Organizer MAY
+ NOT change the "PARTSTAT" iCalendar parameter value to
+ anything other than "NEEDS-ACTION" if the corresponding
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 32]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ "ATTENDEE" property includes the "SCHEDULE-AGENT" iCalendar
+ parameter with its value set to "SERVER", or no "SCHEDULE-
+ AGENT" parameter is present.
+
+ (CALDAV:allowed-attendee-scheduling-object-change): When creating
+ or modifying a scheduling object resource the Attendee can only
+ make the following changes:
+
+ 1. any iCalendar parameter on any "ATTENDEE" property whose value
+ corresponds to the calendar user address of the Attendee
+
+ 2. add, change or remove a "TRANSP" property in any component
+
+ 3. add, change or remove a "COMMENT" property in any component
+
+ 4. add, change or remove a "PERCENT-COMPLETE" property in any
+ component
+
+ 5. change the "PRODID" property in the top-level "VCALENDAR"
+ component
+
+ 6. add, change or remove the "CALSCALE" property in the top-level
+ "VCALENDAR" component
+
+ 7. add, change or remove any "VALARM" components
+
+ 8. create overridden recurring instances with only changes as
+ detailed above
+
+ The Attendee MUST NOT make any other type of change.
+
+7.3. Additional Precondition for DELETE
+
+ This specification require an additional Preconditions for the PUT
+ method. The preconditions are:
+
+ (CALDAV:default-calendar-delete-allowed): The server MAY allow
+ deletion of the default calendar collection.
+
+7.4. Additional Precondition for PROPPATCH
+
+ This specification requires an additional Precondition for the
+ property response elements in PROPPATCH method response. The
+ precondition is:
+
+ (CALDAV:valid-schedule-default-calendar-URL): When the server
+ allows the client to change the CALDAV:schedule-default-calendar-
+ URL property on a scheduling Inbox collection, the URL specified
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 33]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ in any DAV:href element MUST reference a calendar collection owned
+ by the owner of the scheduling Inbox collection.
+
+8. Scheduling
+
+8.1. POST Method
+
+ The POST method submits a scheduling or freebusy message to one or
+ more recipients by targeting the request at the URI of a scheduling
+ Outbox collection. The request body of a POST method MUST contain a
+ scheduling message or freebusy message (e.g., an iCalendar object
+ that follows the iTIP semantic). The resource identified by the
+ Request-URI MUST be a resource collection of type CALDAV:schedule-
+ outbox (Section 3.1.1).
+
+ Only specific types of scheduling message are allowed in a POST
+ request on a scheduling Outbox collection:
+
+ +----------------+---------------------------------+
+ | iTIP METHOD | COMPONENT |
+ +----------------+---------------------------------+
+ | PUBLISH | None |
+ | REQUEST | VFREEBUSY |
+ | REPLY | None |
+ | ADD | None |
+ | CANCEL | None |
+ | REFRESH | Any except VTIMEZONE, VFREEBUSY |
+ | COUNTER | None |
+ | DECLINECOUNTER | None |
+ +----------------+---------------------------------+
+
+ Servers SHOULD reject any scheduling message that is not allowed.
+ However, for backwards compatibility with earlier versions of this
+ specification, servers MAY return a valid schedule response result
+ indicating success for the iTIP operation being executed.
+
+ Preconditions:
+
+ (CALDAV:supported-collection): The Request-URI MUST identify the
+ location of a scheduling Outbox collection;
+
+ (CALDAV:supported-calendar-data): The resource submitted in the
+ POST request MUST be a supported media type (i.e. text/calendar)
+ for scheduling or freebusy messages;
+
+ (CALDAV:valid-calendar-data): The resource submitted in the POST
+ request MUST be valid data for the media type being specified
+ (i.e. valid iCalendar object);
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 34]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ (CALDAV:valid-scheduling-message): The resource submitted in the
+ POST request MUST obey all restrictions specified for the POST
+ request (e.g., the scheduling message follows the restrictions of
+ iTIP);
+
+ (CALDAV:originator-allowed): The currently authenticated user MUST
+ be granted the CALDAV:schedule-deliver privilege or a suitable
+ sub-privilege on the scheduling Outbox collection being targeted
+ by the request;
+
+ (CALDAV:organizer-allowed): The calendar user identified by the
+ "ORGANIZER" property in the POST request's scheduling message MUST
+ be the calendar user (or one of the calendar users) associated
+ with the scheduling Outbox collection being targeted by the
+ request when the scheduling message is an outgoing scheduling
+ message;
+
+ (CALDAV:max-resource-size): The resource submitted in the POST
+ request MUST have an octet size less than or equal to the value of
+ the CALDAV:max-resource-size property value [RFC4791]on the
+ scheduling Outbox collection targeted by the request;
+
+ Postconditions: None
+
+8.1.1. Handling a REFRESH
+
+ When an iTIP REFRESH scheduling message is executed, the server
+ delivers the scheduling message to the calendar user specified by the
+ "ORGANIZER" property value in the scheduling object resource that was
+ submitted to the scheduling Outbox collection with the POST method.
+
+8.1.2. Response to a POST request
+
+ A POST request may deliver a scheduling message to one or more
+ calendar user recipients. Since the behavior of each recipient may
+ vary, it is useful to get response status information for each
+ recipient in the overall POST response. This specification defines a
+ new XML response to convey multiple recipient status.
+
+ A response to a POST method that indicates status for one or more
+ recipients MUST be a CALDAV:schedule-response XML element. This MUST
+ contain one or more CALDAV:response elements for each recipient, with
+ each of those containing elements that indicate which recipient they
+ correspond to, the scheduling status of the request for that
+ recipient, any error codes and an optional description. See
+ Section 11.1.
+
+ In the case of a freebusy request, the CALDAV:response elements can
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 35]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ also contain CALDAV:calendar-data elements which contain freebusy
+ information (e.g., an iCalendar VFREEBUSY component) indicating the
+ busy state of the corresponding recipient, assuming that the freebusy
+ request for that recipient succeeded.
+
+8.1.3. Status Codes for use with the POST method
+
+ The following are examples of response codes one would expect to be
+ used for this method. Note, however, that unless explicitly
+ prohibited any 2/3/4/5xx series response code may be used in a
+ response.
+
+ 200 (OK) - The command succeeded.
+
+ 201 (Created) - The command succeeded and a new resource was
+ created in the scheduling Outbox collection.
+
+ 400 (Bad Request) - The client has provided an invalid scheduling
+ message.
+
+ 403 (Forbidden) - The client cannot submit a scheduling message to
+ the specified Request-URI.
+
+ 404 (Not Found) - The URL in the Request-URI was not present.
+
+ 423 (Locked) - The specified resource is locked and the client
+ either is not a lock owner or the lock type requires a lock token
+ to be submitted and the client did not submit it.
+
+ 507 (Insufficient Storage) - The server did not have sufficient
+ space to record the scheduling message in a scheduling Outbox
+ collection being targeted by the POST request.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 36]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+8.1.4. Example - Simple meeting invitation refresh
+
+ >> Request <<
+
+ POST /bernard/calendar/outbox/ HTTP/1.1
+ Host: cal.example.com
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ METHOD:REFRESH
+ BEGIN:VEVENT
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:lisa at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
+ Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
+ uisseaux:mailto:bernard at example.com
+ END:VEVENT
+ END:VCALENDAR
+
+ >> Response <<
+
+ HTTP/1.1 200 OK
+ Date: Thu, 02 Sep 2004 16:53:32 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:schedule-response xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:response>
+ <C:recipient>
+ <D:href>mailto:lisa at example.com</D:href>
+ </C:recipient>
+ <C:request-status>2.0;Success</C:request-status>
+ <D:responsedescription>Delivered to recipient
+ scheduling inbox</D:responsedescription>
+ </C:response>
+ </C:schedule-response>
+
+ In this example, the client requests the server to deliver a
+ "REFRESH" scheduling message to the Organizer of the meeting
+ mailto:lisa at example.com. The response indicates that delivery to the
+ relevant scheduling Inbox collection of the Organizer was
+ accomplished successfully.
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 37]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+8.1.5. Example - Freebusy lookup
+
+ >> Request <<
+
+ POST /lisa/calendar/outbox/ HTTP/1.1
+ Host: cal.example.com
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ METHOD:REQUEST
+ BEGIN:VFREEBUSY
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:lisa at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
+ example.com
+ ATTENDEE;CN=Cyrus Daboo:mailto:cyrus at example.com
+ END:VFREEBUSY
+ END:VCALENDAR
+
+ >> Response <<
+
+ HTTP/1.1 200 OK
+ Date: Thu, 02 Sep 2004 16:53:32 GMT
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <C:schedule-response xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <C:response>
+ <C:recipient>
+ <D:href>mailto:bernard at example.com<D:href>
+ </C:recipient>
+ <C:request-status>2.0;Success</C:request-status>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Server//EN
+ METHOD:REPLY
+ BEGIN:VFREEBUSY
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:lisa at example.com
+ DTSTART:20040902T000000Z
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 38]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Bernard Desruisseaux:mailto:bernard@
+ example.com
+ FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
+ 20040902T090000Z,20040902T170000Z/20040903T000000Z
+ END:VFREEBUSY
+ END:VCALENDAR
+ </C:calendar-data>
+ </C:response>
+ <C:response>
+ <C:recipient>
+ <D:href>mailto:cyrus at example.com<D:href>
+ </C:recipient>
+ <C:request-status>2.0;Success</C:request-status>
+ <C:calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Server//EN
+ METHOD:REPLY
+ BEGIN:VFREEBUSY
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:lisa at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Cyrus Daboo:mailto:cyrus at example.com
+ FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
+ 20040902T090000Z,20040902T170000Z/20040903T000000Z
+ FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
+ END:VFREEBUSY
+ END:VCALENDAR
+ </C:calendar-data>
+ </C:response>
+ </C:schedule-response>
+
+ In this example, the client requests the server to determine the busy
+ information of the calendar users mailto:bernard at example.com and
+ mailto:cyrus at example.com, over the time range specified by the
+ scheduling message sent in the request. The response includes
+ "VFREEBUSY" components for each of those calendar users with their
+ busy time indicated.
+
+8.2. Retrieving incoming scheduling messages
+
+ Incoming scheduling messages will be stored in a scheduling Inbox
+ collection. As per Section 10, CalDAV calendar-access reports work
+ on scheduling collections, so the client can use those to get partial
+ information on scheduling messages in the scheduling Inbox
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 39]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ collection.
+
+9. Scheduling Access Control
+
+9.1. Scheduling Privileges
+
+ CalDAV servers MUST support and adhere to the requirements of WebDAV
+ ACL [RFC3744]. Furthermore, CalDAV servers that advertise support
+ for the "calendar-auto-schedule" feature MUST also support the
+ scheduling privileges defined in this section.
+
+ All the scheduling privileges MUST be non-abstract and MUST appear in
+ the DAV:supported-privilege-set property of scheduling Outbox and
+ Inbox collections on which they are defined.
+
+ The tables specified in Appendix A clarifies which scheduling methods
+ (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling
+ privilege defined in this section.
+
+9.1.1. Privileges on Scheduling Inbox Collections
+
+ This section defines new WebDAV ACL privileges that are for use on
+ scheduling Inbox collections. These privileges determine whether a
+ calendar user is allowed to have scheduling messages delivered to the
+ calendar user who "owns" the scheduling Inbox collection. This
+ allows calendar users to choose which other calendar users can
+ schedule with them.
+
+ The privileges defined in this section are ignored if applied to a
+ resource other than a scheduling Inbox collection.
+
+9.1.1.1. CALDAV:schedule-deliver Privilege
+
+ CALDAV:schedule-deliver is an aggregate privilege that contains all
+ the scheduling privileges that control the processing and delivery of
+ incoming scheduling messages, that is, CALDAV:schedule-deliver-invite
+ and CALDAV:schedule-deliver-reply, as well as freebusy requests
+ targeted at the owner of the scheduling Inbox collection, that is,
+ CALDAV:schedule-query-freebusy.
+
+ <!ELEMENT schedule-deliver EMPTY >
+
+9.1.1.2. CALDAV:schedule-deliver-invite Privilege
+
+ The CALDAV:schedule-deliver-invite privilege controls the processing
+ and delivery of scheduling messages coming from an Organizer.
+
+ <!ELEMENT schedule-deliver-invite EMPTY >
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 40]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+9.1.1.3. CALDAV:schedule-deliver-reply Privilege
+
+ The CALDAV:schedule-deliver-reply privilege controls the processing
+ and delivery of scheduling messages coming from an Attendee.
+
+ <!ELEMENT schedule-deliver-reply EMPTY >
+
+9.1.1.4. CALDAV:schedule-query-freebusy Privilege
+
+ The CALDAV:schedule-query-freebusy privilege controls freebusy
+ requests targeted at the owner of the scheduling Inbox collection.
+
+ <!ELEMENT schedule-query-freebusy EMPTY >
+
+9.1.2. Privileges on Scheduling Outbox Collections
+
+ This section defines new WebDAV ACL privileges that are defined for
+ use on scheduling Outbox collections. These privileges determine
+ which calendar users are allowed to send scheduling messages on
+ behalf of the calendar user who "owns" the scheduling Outbox
+ collection. This allows calendar users to choose other calendar
+ users who can act on their behalf to schedule with other calendar
+ users (e.g. assistants working on behalf of their boss).
+
+ The privileges defined in this section are ignored if applied to a
+ resource other than a scheduling Outbox collection.
+
+9.1.2.1. CALDAV:schedule-send Privilege
+
+ CALDAV:schedule-send is an aggregate privilege that contains all the
+ scheduling privileges that control the use of methods that will cause
+ scheduling messages to be delivered to other users, that is, CALDAV-
+ schedule-send-invite and CALDAV-schedule-send-reply, as well as
+ freebusy requests to be targeted at other users, that is, CALDAV-
+ schedule-send-freebusy.
+
+ <!ELEMENT schedule-send EMPTY >
+
+9.1.2.2. CALDAV:schedule-send-invite Privilege
+
+ The CALDAV:schedule-send-invite privilege controls the sending of
+ scheduling messages by Organizers.
+
+ Users granted the DAV:bind privilege on a calendar collection, or
+ DAV:write privilege on scheduling object resources, will also need
+ the CALDAV:schedule-send-invite privilege granted on the scheduling
+ Outbox collection of the owner of the calendar collection or
+ scheduling object resource in order to be allowed to create, modify
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 41]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ or delete scheduling object resources in a way that will trigger the
+ CalDAV server to deliver organizer scheduling messages to other
+ calendar users.
+
+ <!ELEMENT schedule-send-invite EMPTY >
+
+9.1.2.3. CALDAV:schedule-send-reply Privilege
+
+ The CALDAV:schedule-send-invite privilege controls the sending of
+ scheduling messages by Attendees.
+
+ Users granted the DAV:bind privilege on a calendar collection, or
+ DAV:write privilege on scheduling object resources, will also need
+ the CALDAV:schedule-send-reply privilege granted on the scheduling
+ Outbox collection of the owner of the calendar collection or
+ scheduling object resource in order to be allowed to create, modify
+ or delete scheduling object resources in a way that will trigger the
+ CalDAV server to deliver attendee scheduling messages to other
+ calendar users.
+
+ <!ELEMENT schedule-send-reply EMPTY >
+
+9.1.2.4. CALDAV:schedule-send-freebusy Privilege
+
+ The CALDAV:schedule-send-freebusy privilege controls the use of the
+ POST method to submit scheduling messages that specify the scheduling
+ method "REQUEST" with a "VFREEBUSY" calendar component.
+
+ <!ELEMENT schedule-send-freebusy EMPTY >
+
+9.1.3. Aggregation of Scheduling Privileges
+
+ Server implementations MUST aggregate the scheduling privileges as
+ follows:
+
+ DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule-
+ deliver;
+
+ CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite,
+ CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy;
+
+ CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver-
+ invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-
+ freebusy.
+
+ The following diagram illustrates how scheduling privileges are
+ aggregated according to the above requirements.
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 42]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ [DAV:all] (aggregate)
+ |
+ +-- [CALDAV:schedule-deliver] (aggregate)
+ | |
+ | +-- [CALDAV:schedule-deliver-invite]
+ | +-- [CALDAV:schedule-deliver-reply]
+ | +-- [CALDAV:schedule-query-freebusy]
+ |
+ +-- [CALDAV:schedule-send] (aggregate)
+ |
+ +-- [CALDAV:schedule-send-invite]
+ +-- [CALDAV:schedule-send-reply]
+ +-- [CALDAV:schedule-send-freebusy]
+
+9.2. Additional Principal Properties
+
+ This section defines new properties for WebDAV principal resources as
+ defined in RFC3744 [RFC3744]. These properties are likely to be
+ protected but the server MAY allow them to be written by appropriate
+ users.
+
+9.2.1. CALDAV:schedule-inbox-URL Property
+
+ Name: schedule-inbox-URL
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identify the URL of the scheduling Inbox collection owned
+ by the associated principal resource.
+
+ Conformance: This property MAY be protected and SHOULD NOT be
+ returned by a PROPFIND allprop request (as defined in Section 14.2
+ of [RFC4918]).
+
+ Description: This property is needed for a client to determine where
+ the scheduling Inbox collection of the current user is located so
+ that processing of scheduling messages can occur.
+
+ Definition:
+
+ <!ELEMENT schedule-inbox-URL (DAV:href)>
+
+9.2.2. CALDAV:schedule-outbox-URL Property
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 43]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ Name: schedule-outbox-URL
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identify the URL of the scheduling Outbox collection owned
+ by the associated principal resource.
+
+ Conformance: This property MAY be protected and SHOULD NOT be
+ returned by a PROPFIND allprop request (as defined in Section 14.2
+ of [RFC4918]).
+
+ Description: This property is needed for a client to determine where
+ the scheduling Outbox collection of the current user is located so
+ that sending of scheduling messages can occur.
+
+ Definition:
+
+ <!ELEMENT schedule-outbox-URL DAV:href>
+
+9.2.3. CALDAV:calendar-user-address-set Property
+
+ Name: calendar-user-address-set
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identify the calendar addresses of the associated principal
+ resource.
+
+ Conformance: This property MAY be protected and SHOULD NOT be
+ returned by a PROPFIND allprop request (as defined in Section 14.2
+ of [RFC4918]). Support for this property is REQUIRED. This
+ property SHOULD be searchable using the DAV:principal-property-
+ search REPORT. The DAV:principal-search-property-set REPORT
+ SHOULD identify this property as such.
+
+ Description: This property is needed to map calendar user addresses
+ in iCalendar data to principal resources and their associated
+ scheduling Inbox and Outbox collections. In the event that a user
+ has no well defined identifier for their calendar user address,
+ the URI of their principal resource can be used.
+
+ Definition:
+
+ <!ELEMENT calendar-user-address-set (DAV:href*)>
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 44]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ Example:
+
+ <C:calendar-user-address-set xmlns:D="DAV:"
+ xmlns:C="urn:ietf:params:xml:ns:caldav">
+ <D:href>mailto:bernard at example.com</D:href>
+ <D:href>mailto:bernard.desruisseaux at example.com</D:href>
+ </C:calendar-user-address-set>
+
+9.2.4. CALDAV:calendar-user-type Property
+
+ Name: calendar-user-type
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Identifies the calendar user type of the associated
+ principal resource.
+
+ Conformance: This property MAY be protected and SHOULD NOT be
+ returned by a PROPFIND allprop request (as defined in Section 14.2
+ of [RFC4918]). Support for this property is OPTIONAL. This
+ property SHOULD be searchable using the DAV:principal-property-
+ search REPORT. The DAV:principal-search-property-set REPORT
+ SHOULD identify this property as such.
+
+ Description: This property is used to indicate the type of calendar
+ user associated with the principal resource. Its value is the
+ same as the iCalendar "CUTYPE" property parameter that can be used
+ on "ATTENDEE" properties.
+
+ Definition:
+
+ <!ELEMENT calendar-user-type #PCDATA>
+ <!-- The supported values are those defined in iCalendar [RFC2445]
+ Section 4.2.3 for the "CUTYPE" -->
+
+ Example:
+
+ <C:calendar-user-type
+ xmlns:C="urn:ietf:params:xml:ns:caldav">INDIVIDUAL<
+ /C:calendar-user-type>
+
+10. Reports
+
+ This specification extends the CALDAV:calendar-query and CALDAV:
+ calendar-multiget reports to return results for calendar object
+ resources in scheduling Inbox collections when the report directly
+ targets such a collection. i.e. the Request-URI for a REPORT MUST be
+ the URI of the scheduling Inbox collection or of a child resource
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 45]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ within a scheduling Inbox collection. A report run on a regular
+ collection that includes a scheduling Inbox collection as a child
+ resource at any depth MUST NOT examine or return any calendar object
+ resources from within any scheduling Inbox collections.
+
+ When a CALDAV:calendar-query REPORT includes a time-range query and
+ targets a scheduling Inbox collection, if any calendar object
+ resources contain "VEVENT" calendar components that do not include a
+ "DTSTART" iCalendar property (as allowed by iTIP [RFC2446]) then such
+ components MUST always match the time-range query test.
+
+ Note that the CALDAV:free-busy-query report is NOT supported on
+ scheduling Inbox collections.
+
+11. XML Element Definitions
+
+11.1. CALDAV:schedule-response XML Element
+
+ Name: schedule-response
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Contains the set of responses for a POST method request.
+
+ Description: See Section 8.1.2.
+
+ Definition:
+
+ <!ELEMENT schedule-response (response*)>
+
+11.2. CALDAV:response XML Element
+
+ Name: response
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: Contains a single response for a POST method request.
+
+ Description: See Section 8.1.2.
+
+ Definition:
+
+ <!ELEMENT response (recipient,
+ request-status,
+ calendar-data?,
+ DAV:error?,
+ DAV:responsedescription?)>
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 46]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+11.3. CALDAV:recipient XML Element
+
+ Name: recipient
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: The calendar user address (recipient header value) that the
+ enclosing response for a POST method request is for.
+
+ Description: See Section 8.1.2.
+
+ Definition:
+
+ <!ELEMENT recipient (DAV:href)>
+
+11.4. CALDAV:request-status XML Element
+
+ Name: request-status
+
+ Namespace: urn:ietf:params:xml:ns:caldav
+
+ Purpose: The iTIP "REQUEST-STATUS" property value for this response.
+
+ Description: See Section 8.1.2.
+
+ Definition:
+
+ <!ELEMENT request-status #PCDATA>
+
+12. Security Considerations
+
+ The process of scheduling involves the sending and receiving of
+ scheduling messages. As a result, the security problems related to
+ messaging in general are relevant here. In particular the
+ authenticity of the scheduling messages needs to be verified
+ absolutely. Servers and clients MUST use an HTTP connection
+ protected with TLS as defined in [RFC2818] for all scheduling
+ transactions.
+
+12.1. Verifying scheduling requests
+
+ When handling an implicit scheduling operation:
+
+ Servers MUST verify that the currently authenticated user has the
+ CALDAV:schedule-deliver privilege or a suitable sub-privilege on
+ the scheduling Outbox collection of the DAV:owner of the calendar
+ collection in which a scheduling object resource is being
+ manipulated.
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 47]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ Servers MUST verify that the principal associated with the DAV:
+ owner of the calendar collection in which a scheduling object
+ resource is being manipulated contains a CALDAV:schedule-outbox-
+ URL property value.
+
+ Servers MUST only deliver scheduling messages to recipients when
+ the principal associated with the DAV:owner of the calendar
+ collection in which a scheduling object resource is being
+ manipulated has the CALDAV:schedule privilege or a suitable sub-
+ privilege on the scheduling Inbox collections for recipient.
+
+ To prevent impersonation of calendar users, the server MUST verify
+ that the "ORGANIZER" property in an organizer scheduling object
+ resource matches one of the calendar user addresses of the DAV:
+ owner of the calendar collection in which the resource is stored.
+
+ To prevent spoofing of an existing scheduling object resource,
+ servers MUST verify that the "UID" iCalendar property value in a
+ new scheduling object resource does not match that of an existing
+ scheduling object resource with a different "ORGANIZER" property
+ value.
+
+ When handling a POST request on a scheduling Outbox collection:
+
+ Servers MUST verify that the currently authenticated user has the
+ CALDAV:schedule-deliver privilege or a suitable sub-privilege on
+ the scheduling Outbox collection targeted by the request.
+
+ Servers MUST verify that the principal associated with the
+ calendar user address specified in the "ORGANIZER" property of the
+ scheduling message data in the request contains a CALDAV:schedule-
+ outbox-URL property value that matches the scheduling Outbox
+ collection targeted by the request.
+
+ Servers MUST verify that the principal associated with the
+ calendar user address specified in the "ORGANIZER" property of the
+ scheduling message data in the request has the CALDAV:schedule
+ privilege or a suitable sub-privilege on all of the scheduling
+ Inbox collections for those recipients to whom a scheduling
+ message is being delivered.
+
+13. IANA Consideration
+
+13.1. HTTP header registration
+
+ This specification registers one new header for use with HTTP as per
+ [RFC3864].
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 48]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+13.1.1. Schedule-Reply Request Header Registration
+
+ Header field name: Schedule-Reply
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document(s): this specification
+
+ Related information: none
+
+13.2. iCalendar Registrations
+
+ This specification registers two new iCalendar property parameters as
+ defined in XXX.
+
+14. Acknowledgements
+
+ The authors would like to thank the following individuals for
+ contributing their ideas and support for writing this specification:
+ Mike Douglass, Lisa Dusseault, Arnaud Quillaud, Julian F. Reschke,
+ Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim Whitehead.
+
+ The authors would also like to thank the Calendaring and Scheduling
+ Consortium for advice with this specification, and for organizing
+ interoperability testing events to help refine it.
+
+15. References
+
+15.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14,
+ RFC 2119, March 1997.
+
+ [RFC2445] Dawson, F. and Stenerson, D., "Internet
+ Calendaring and Scheduling Core Object
+ Specification (iCalendar)", RFC 2445,
+ November 1998.
+
+ [RFC2446] Silverberg, S., Mansour, S., Dawson, F., and
+ R. Hopson, "iCalendar Transport-Independent
+ Interoperability Protocol (iTIP) Scheduling
+ Events, BusyTime, To-dos and Journal
+ Entries", RFC 2446, November 1998.
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 49]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk,
+ H., Masinter, L., Leach, P., and T. Berners-
+ Lee, "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
+ May 2000.
+
+ [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
+ Whitehead, "Web Distributed Authoring and
+ Versioning (WebDAV) Access Control Protocol",
+ RFC 3744, May 2004.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
+ "Registration Procedures for Message Header
+ Fields", BCP 90, RFC 3864, September 2004.
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L.
+ Dusseault, "Calendaring Extensions to WebDAV
+ (CalDAV)", RFC 4791, March 2007.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web
+ Distributed Authoring and Versioning
+ (WebDAV)", RFC 4918, June 2007.
+
+ [W3C.REC-xml-20060816] Bray, T., Paoli, J., Sperberg-McQueen, C.,
+ Yergeau, F., and E. Maler, "Extensible Markup
+ Language (XML) 1.0 (Fourth Edition)", World
+ Wide Web Consortium Recommendation REC-xml-
+ 20060816, August 2006,
+ <http://www.w3.org/TR/2006/REC-xml-20060816>.
+
+15.2. Informative References
+
+ [RFC2447] Dawson, F., Mansour, S., and S. Silverberg,
+ "iCalendar Message-Based Interoperability
+ Protocol (iMIP)", RFC 2447, November 1998.
+
+Appendix A. Scheduling Privileges Summary
+
+A.1. Scheduling Inbox Privileges
+
+ The following tables specify which scheduling privileges grant the
+ right to a calendar user to deliver a scheduling message to the
+ scheduling Inbox collection of another calendar user. The
+ appropriate behavior depends on the calendar component type in the
+ scheduling message and the scheduling "METHOD" in use.
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 50]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ +-----------------------+
+ | METHOD for VEVENT |
+ +---+---+---+---+---+---+
+ | P | R | R | A | C | R |
+ | U | E | E | D | A | E |
+ | B | Q | P | D | N | F |
+ | L | U | L | | C | R |
+ | I | E | Y | | E | E |
+ +----------------------------+| S | S | | | L | S |
+ | Scheduling Inbox Privilege || H | T | | | | H |
+ +============================++===+===+===+===+===+===+
+ | schedule-deliver || * | * | * | * | * | * |
+ | schedule-deliver-invite || * | * | | * | * | |
+ | schedule-deliver-reply || | | * | | | * |
+ | schedule-query-freebusy || | | | | | |
+ +----------------------------++---+---+---+---+---+---+
+
+
+ +-----------------------+
+ | METHOD for VTODO |
+ +---+---+---+---+---+---+
+ | P | R | R | A | C | R |
+ | U | E | E | D | A | E |
+ | B | Q | P | D | N | F |
+ | L | U | L | | C | R |
+ | I | E | Y | | E | E |
+ +----------------------------+| S | S | | | L | S |
+ | Scheduling Inbox Privilege || H | T | | | | H |
+ +============================++===+===+===+===+===+===+
+ | schedule-deliver || * | * | * | * | * | * |
+ | schedule-deliver-invite || * | * | | * | * | |
+ | schedule-deliver-reply || | | * | | | * |
+ | schedule-query-freebusy || | | | | | |
+ +----------------------------++---+---+---+---+---+---+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 51]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ +-----------------------+
+ | METHOD for VJOURNAL |
+ +-------+-------+-------+
+ | P | A | C |
+ | U | D | A |
+ | B | D | N |
+ | L | | C |
+ | I | | E |
+ +----------------------------+| S | | L |
+ | Scheduling Inbox Privilege || H | | |
+ +============================++=======+=======+=======+
+ | schedule-deliver || * | * | * |
+ | schedule-deliver-invite || * | * | * |
+ | schedule-deliver-reply || | | |
+ | schedule-query-freebusy || | | |
+ +----------------------------++-------+-------+-------+
+
+
+ +---------------+
+ | METHOD for |
+ | VFREEBUSY |
+ +-------+-------+
+ | P | R |
+ | U | E |
+ | B | Q |
+ | L | U |
+ | I | E |
+ +----------------------------+| S | S |
+ | Scheduling Inbox Privilege || H | T |
+ +============================++=======+=======+
+ | schedule-deliver || * | * |
+ | schedule-deliver-invite || * | |
+ | schedule-deliver-reply || | |
+ | schedule-query-freebusy || | * |
+ +----------------------------++-------+-------+
+
+A.2. Scheduling Outbox Privileges
+
+ The following tables specify which scheduling privileges grant the
+ right to a calendar user to submit a scheduling message to another
+ calendar user, either as the result of an explicit scheduling request
+ or an automatic scheduling transaction. The appropriate behavior
+ depends on the calendar component type in the scheduling message and
+ the scheduling "METHOD" in use.
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 52]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ +-------------------+
+ | METHOD for VEVENT |
+ +---+---+---+---+---+
+ | R | R | A | C | R |
+ | E | E | D | A | E |
+ | Q | P | D | N | F |
+ | U | L | | C | R |
+ | E | Y | | E | E |
+ +-----------------------------+| S | | | L | S |
+ | Scheduling Outbox Privilege || T | | | | H |
+ +=============================++===+===+===+===+===+
+ | schedule-send || * | * | * | * | * |
+ | schedule-send-invite || * | | * | * | |
+ | schedule-send-reply || | * | | | * |
+ | schedule-send-freebusy || | | | | |
+ +-----------------------------++---+---+---+---+---+
+
+
+ +-------------------+
+ | METHOD for VTODO |
+ +---+---+---+---+---+
+ | R | R | A | C | R |
+ | E | E | D | A | E |
+ | Q | P | D | N | F |
+ | U | L | | C | R |
+ | E | Y | | E | E |
+ +-----------------------------+| S | | | L | S |
+ | Scheduling Outbox Privilege || T | | | | H |
+ +=============================++===+===+===+===+===+
+ | schedule-send || * | * | * | * | * |
+ | schedule-send-invite || * | | * | * | |
+ | schedule-send-reply || | * | | | * |
+ | schedule-send-freebusy || | | | | |
+ +-----------------------------++---+---+---+---+---+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 53]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ +-----------------------+
+ | METHOD for VJOURNAL |
+ +-------+-------+-------+
+ | P | A | C |
+ | U | D | A |
+ | B | D | N |
+ | L | | C |
+ | I | | E |
+ +-----------------------------+| S | | L |
+ | Scheduling Outbox Privilege || H | | |
+ +=============================++=======+=======+=======+
+ | schedule-send || * | * | * |
+ | schedule-send-invite || * | * | * |
+ | schedule-send-reply || | | |
+ | schedule-send-freebusy || | | |
+ +-----------------------------++-------+-------+-------+
+
+
+ +---------------+
+ | METHOD for |
+ | VFREEBUSY |
+ +-------+-------+
+ | P | R |
+ | U | E |
+ | B | Q |
+ | L | U |
+ | I | E |
+ +-----------------------------+| S | S |
+ | Scheduling Outbox Privilege || H | T |
+ +=============================++=======+=======+
+ | schedule-send || * | * |
+ | schedule-send-invite || * | |
+ | schedule-send-reply || | |
+ | schedule-send-freebusy || | * |
+ +-----------------------------++-------+-------+
+
+Appendix B. Changes (to be removed prior to publication as an RFC)
+
+B.1. Changes in -06
+
+ a. Removed distinction between scheduling calendar collections and
+ basic calendar collections - now just have calendar collections.
+
+ b. Clients now "MAY" reload data rather than "SHOULD" reload data.
+
+ c. Fixed <C:recipient> in examples.
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 54]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+ d. Removed CALDAV:attachments-allowed pre-condition on POST to
+ Outbox as that is no longer relevant.
+
+ e. Added CALDAV:default-calendar-delete-allowed precondition for
+ DELETE.
+
+ f. Relaxed MUST->MAY for Organizer setting PARTSTAT value.
+
+ g. Tweaked restrictions on Create/Modify to emphasize that 4791
+ restrictions also apply.
+
+ h. Added comment that 'opaque' is the default when the CALDAV:
+ schedule-calendar-transp property is not present.
+
+ i. Description of Schedule-Reply header changed to reflect that it
+ is only relevant for Attendees.
+
+ j. Minor typos fixed.
+
+B.2. Changes in -05
+
+ This draft has changed substantially since the -04 version. The
+ primary reason for this change was implementation experience from a
+ number of vendors who implemented products based on the earlier
+ drafts. Experience showed that the client/server interaction was not
+ reliable in keeping scheduling messages synchronized between
+ organizer and attendees. In addition the latency in updates due to
+ clients being offline proved unacceptable to users. These issues led
+ to the redesign of this specification to support a server-based
+ processing model that eliminates all the problems seen previously.
+ Whilst this adds significant complexity to the server in that it
+ needs to be a full blown iTIP processing agent, it does remove a lot
+ of the same complexity from clients, opening up the possibility of
+ supporting complex scheduling behaviors even with "thin" clients.
+
+ In the judgement of the authors, we consider this new specification
+ to be a substantial improvement over the old one and believe it
+ represents a stronger protocol that will lead to better
+ interoperability.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 55]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+Authors' Addresses
+
+ Cyrus Daboo
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus at daboo.name
+ URI: http://www.apple.com/
+
+
+ Bernard Desruisseaux
+ Oracle Corporation
+ 600 Blvd. de Maisonneuve West
+ Suite 1900
+ Montreal, QC H3A 3J2
+ CANADA
+
+ EMail: bernard.desruisseaux at oracle.com
+ URI: http://www.oracle.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 56]
+
+Internet-Draft CalDAV Schedule November 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 7, 2009 [Page 57]
+
Modified: CalendarServer/branches/config-separation/doc/calendarserver_manage_principals.8
===================================================================
--- CalendarServer/branches/config-separation/doc/calendarserver_manage_principals.8 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/doc/calendarserver_manage_principals.8 2009-07-08 23:19:44 UTC (rev 4437)
@@ -73,7 +73,6 @@
Displays usage information
.It Fl f, -config Ar FILE
Use the Calendar Server configuration specified in the given file. Defaults to /etc/caldavd/caldavd.plist.
-.El
.Sh ACTIONS
.Bl -tag -width flag
.It Fl -read-property Ar property
@@ -107,6 +106,7 @@
Get the automatic scheduling state.
.El
.Sh EXAMPLES
+.Ex
Add Alice and Bob as read proxies for Joe and display the list of Joe's proxies:
.Pp
.Dl "calendarserver_manage_principals --add-read-proxy users:alice --add-read-proxy users:bob --list-proxies users:joe"
@@ -119,6 +119,7 @@
.Pp
.Dl "calendarserver_manage_principals --set-auto-schedule true --get-auto-schedule resources:projector"
.Pp
+.El
.Sh FILES
.Bl -tag -width flag
.It /etc/caldavd/caldavd.plist
Modified: CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.auth.digest.patch
===================================================================
--- CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.auth.digest.patch 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.auth.digest.patch 2009-07-08 23:19:44 UTC (rev 4437)
@@ -54,15 +54,6 @@
)
return expected == response
-@@ -234,7 +250,7 @@
- key = "%s,%s,%s" % (nonce, clientip, str(int(self._getTime())))
- digest = md5(key + self.privateKey).hexdigest()
- ekey = key.encode('base64')
-- return "%s-%s" % (digest, ekey.strip('\n'))
-+ return "%s-%s" % (digest, ekey.replace('\n'))
-
- def verifyOpaque(self, opaque, nonce, clientip):
- """
@@ -348,7 +364,13 @@
auth.get('nonce'),
request.remoteAddr.host):
Modified: CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.dav.resource.patch
===================================================================
--- CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.dav.resource.patch 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/lib-patches/Twisted/twisted.web2.dav.resource.patch 2009-07-08 23:19:44 UTC (rev 4437)
@@ -2,95 +2,22 @@
===================================================================
--- twisted/web2/dav/resource.py (revision 26969)
+++ twisted/web2/dav/resource.py (working copy)
-@@ -49,12 +49,14 @@
+@@ -49,12 +49,13 @@
if not hasattr(__builtin__, "frozenset"):
import sets.ImmutableSet as frozenset
+import urllib
+
from zope.interface import implements
-+from twisted.cred.error import LoginFailed, UnauthorizedLogin
from twisted.python import log
from twisted.python.failure import Failure
--from twisted.internet.defer import Deferred, maybeDeferred, succeed
-+from twisted.internet.defer import Deferred, maybeDeferred, succeed, inlineCallbacks
+ from twisted.internet.defer import Deferred, maybeDeferred, succeed
from twisted.internet.defer import waitForDeferred, deferredGenerator
-from twisted.cred.error import LoginFailed, UnauthorizedLogin
from twisted.internet import reactor
from twisted.web2 import responsecode
from twisted.web2.http import HTTPError, RedirectResponse, StatusResponse
-@@ -642,41 +644,43 @@
- # Authentication
- ##
-
-+ @inlineCallbacks
- def authorize(self, request, privileges, recurse=False):
- """
- See L{IDAVResource.authorize}.
- """
-- def onAuth(result):
-- def onErrors(failure):
-- failure.trap(AccessDeniedError)
--
-- # If we were unauthorized to start with (no Authorization header from client) then
-- # we should return an unauthorized response instead to force the client to login if it can
-- if request.authnUser == davxml.Principal(davxml.Unauthenticated()):
-- d = UnauthorizedResponse.makeResponse(request.credentialFactories,
-- request.remoteAddr)
-- def _fail(response):
-- return Failure(HTTPError(response))
-- return d.addCallback(_fail)
-- else:
-- response = NeedPrivilegesResponse(request.uri,
-- failure.value.errors)
-- #
-- # We're not adding the headers here because this response
-- # class is supposed to be a FORBIDDEN status code and
-- # "Authorization will not help" according to RFC2616
-- #
-- raise HTTPError(response)
-
-- d = self.checkPrivileges(request, privileges, recurse)
-- d.addErrback(onErrors)
-- return d
-+ try:
-+ yield self.authenticate(request)
-+ except (UnauthorizedLogin, LoginFailed), e:
-+ log.msg("Authentication failed: %s" % (e,))
-+ response = (yield UnauthorizedResponse.makeResponse(
-+ request.credentialFactories,
-+ request.remoteAddr
-+ ))
-+ raise HTTPError(response)
-
-- d = maybeDeferred(self.authenticate, request)
-- d.addCallback(onAuth)
-- return d
-+ try:
-+ yield self.checkPrivileges(request, privileges, recurse)
-+ except AccessDeniedError, e:
-+ # If we were unauthenticated to start with (no Authorization header from client) then
-+ # we should return an unauthorized response instead to force the client to login if it can
-+ if request.authnUser == davxml.Principal(davxml.Unauthenticated()):
-+ response = (yield UnauthorizedResponse.makeResponse(
-+ request.credentialFactories,
-+ request.remoteAddr
-+ ))
-+ else:
-+ response = NeedPrivilegesResponse(request.uri, e.errors)
-+ #
-+ # We're not adding the headers here because this response
-+ # class is supposed to be a FORBIDDEN status code and
-+ # "Authorization will not help" according to RFC2616
-+ #
-+ raise HTTPError(response)
-
-
-+
- def authenticate(self, request):
- if not (
- hasattr(request, 'portal') and
-@@ -1880,7 +1884,7 @@
+@@ -1880,7 +1881,7 @@
# If this is a collection and the URI doesn't end in "/", redirect.
#
if self.isCollection() and request.path[-1:] != "/":
Modified: CalendarServer/branches/config-separation/pyflakes
===================================================================
--- CalendarServer/branches/config-separation/pyflakes 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/pyflakes 2009-07-08 23:19:44 UTC (rev 4437)
@@ -14,7 +14,6 @@
cd "${wd}" && "${flakes}/bin/pyflakes" "$@" | sed \
-e "/undefined name '_'/d" \
- -e "/undefined name 'CalDAVFile'/d" \
-e "/redefinition of unused/d" \
-e "/'from .* import \\*' used; unable to detect undefined names/d" \
-e "/redefinition of function/d" \
Modified: CalendarServer/branches/config-separation/run
===================================================================
--- CalendarServer/branches/config-separation/run 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/run 2009-07-08 23:19:44 UTC (rev 4437)
@@ -727,7 +727,7 @@
caldavtester="${top}/CalDAVTester";
-svn_get "CalDAVTester" "${caldavtester}" "${svn_uri_base}/CalDAVTester/trunk" 4427;
+svn_get "CalDAVTester" "${caldavtester}" "${svn_uri_base}/CalDAVTester/trunk" 4372;
#
# PyFlakes
Deleted: CalendarServer/branches/config-separation/twext/python/log.py
===================================================================
--- CalendarServer/branches/config-separation/twext/python/log.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twext/python/log.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -1,49 +0,0 @@
-##
-# Copyright (c) 2009 Apple Inc. All rights reserved.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-##
-
-"""
-Extensions to twisted.python.log.
-"""
-
-from sys import stdout, stderr
-
-from twisted.python.log import addObserver, removeObserver
-
-class StandardIOObserver (object):
- """
- Log observer that writes to standard I/O.
- """
- def emit(self, eventDict):
- text = None
-
- if eventDict["isError"]:
- output = stderr
- if "failure" in eventDict:
- text = eventDict["failure"].getTraceback()
- else:
- output = stdout
-
- if not text:
- text = " ".join([str(m) for m in eventDict["message"]]) + "\n"
-
- output.write(text)
- output.flush()
-
- def start(self):
- addObserver(self.emit)
-
- def stop(self):
- removeObserver(self.emit)
Modified: CalendarServer/branches/config-separation/twisted/plugins/caldav.py
===================================================================
--- CalendarServer/branches/config-separation/twisted/plugins/caldav.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twisted/plugins/caldav.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -34,6 +34,5 @@
TwistedCalDAV = TAP("calendarserver.tap.caldav.CalDAVServiceMaker")
-CalDAVTask = TAP("calendarserver.sidecar.task.CalDAVTaskServiceMaker")
CalDAVNotifier = TAP("twistedcaldav.notify.NotificationServiceMaker")
CalDAVMailGateway = TAP("twistedcaldav.mail.MailGatewayServiceMaker")
Modified: CalendarServer/branches/config-separation/twistedcaldav/accesslog.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/accesslog.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/accesslog.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -26,6 +26,7 @@
]
import datetime
+import logging
import os
import time
Modified: CalendarServer/branches/config-separation/twistedcaldav/caldavxml.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/caldavxml.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/caldavxml.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -1803,6 +1803,33 @@
"""
name = "schedule-send"
+class ScheduleState (CalDAVElement):
+ """
+ Indicates whether a scheduling message in an inbox has been processed
+ by the server.
+ """
+ name = "schedule-state"
+ protected = True
+
+ allowed_children = {
+ (caldav_namespace, "schedule-processed" ): (0, 1),
+ (caldav_namespace, "schedule-unprocessed" ): (0, 1),
+ }
+
+class ScheduleProcessed (CalDAVEmptyElement):
+ """
+ Indicates that a scheduling message in an inbox has been processed
+ by the server.
+ """
+ name = "schedule-processed"
+
+class ScheduleUnprocessed (CalDAVEmptyElement):
+ """
+ Indicates that a scheduling message in an inbox has not been processed
+ by the server.
+ """
+ name = "schedule-unprocessed"
+
class CalendarUserType (CalDAVTextElement):
"""
The CALDAV:calendar-user-type property from section 9.2.4 of caldav-sched-05
Modified: CalendarServer/branches/config-separation/twistedcaldav/directory/appleopendirectory.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/directory/appleopendirectory.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/directory/appleopendirectory.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -38,7 +38,7 @@
from twisted.internet.threads import deferToThread
from twisted.cred.credentials import UsernamePassword
from twisted.web2.auth.digest import DigestedCredentials
-from twistedcaldav.config import config
+from twistedcaldav.config import config, ConfigurationError
from twistedcaldav.directory.cachingdirectory import CachingDirectoryService,\
CachingDirectoryRecord
Modified: CalendarServer/branches/config-separation/twistedcaldav/directory/oldappleopendirectory.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/directory/oldappleopendirectory.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/directory/oldappleopendirectory.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -27,6 +27,8 @@
from random import random
from uuid import UUID
+from twext.python.plistlib import readPlistFromString
+
from xml.parsers.expat import ExpatError
import opendirectory
@@ -38,11 +40,8 @@
from twisted.cred.credentials import UsernamePassword
from twisted.web2.auth.digest import DigestedCredentials
-from twext.python.plistlib import readPlistFromString
-
from twistedcaldav.directory.directory import DirectoryService, DirectoryRecord
from twistedcaldav.directory.directory import DirectoryError, UnknownRecordTypeError
-from twistedcaldav.directory.principal import cuAddressConverter
from twistedcaldav.scheduling.cuaddress import normalizeCUAddr
class OpenDirectoryService(DirectoryService):
Modified: CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_proxyprincipalmembers.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_proxyprincipalmembers.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_proxyprincipalmembers.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -23,6 +23,7 @@
from twistedcaldav.directory.principal import DirectoryPrincipalResource
from twistedcaldav.directory.xmlaccountsparser import XMLAccountsParser
from twistedcaldav.directory.xmlfile import XMLDirectoryService
+from twistedcaldav.directory.calendaruserproxy import CalendarUserProxyDatabase
import twistedcaldav.test.util
from twistedcaldav.config import config
Modified: CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_sqldb.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_sqldb.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/directory/test/test_sqldb.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -18,9 +18,9 @@
from twisted.python.filepath import FilePath
-#import twistedcaldav.directory.test.util
-#import twistedcaldav.directory.test.test_xmlfile
-#from twistedcaldav.directory.sqldb import SQLDirectoryService
+import twistedcaldav.directory.test.util
+import twistedcaldav.directory.test.test_xmlfile
+from twistedcaldav.directory.sqldb import SQLDirectoryService
xmlFile = FilePath(os.path.join(os.path.dirname(__file__), "accounts.xml"))
Modified: CalendarServer/branches/config-separation/twistedcaldav/directory/xmlaccountsparser.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/directory/xmlaccountsparser.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/directory/xmlaccountsparser.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -23,6 +23,7 @@
"XMLAccountsParser",
]
+from uuid import UUID
import xml.dom.minidom
from twisted.python.filepath import FilePath
Modified: CalendarServer/branches/config-separation/twistedcaldav/mail.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/mail.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/mail.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -34,10 +34,11 @@
from twisted.mail import pop3client, imap4
from twisted.mail.smtp import messageid, rfc822date, ESMTPSenderFactory
from twisted.plugin import IPlugin
+from twisted.python import failure
from twisted.python.reflect import namedClass
from twisted.python.usage import Options, UsageError
from twisted.web import client
-from twisted.web2 import server, responsecode
+from twisted.web2 import resource, server, responsecode
from twisted.web2.channel.http import HTTPFactory
from twisted.web2.dav import auth
from twisted.web2.dav import davxml
Modified: CalendarServer/branches/config-separation/twistedcaldav/method/delete_common.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/method/delete_common.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/method/delete_common.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -168,7 +168,7 @@
yield parent.updateCTag()
# Do scheduling
- if scheduler and not self.internal_request:
+ if scheduler:
yield scheduler.doImplicitScheduling()
except MemcacheLockTimeoutError:
Modified: CalendarServer/branches/config-separation/twistedcaldav/method/put_common.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/method/put_common.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/method/put_common.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -62,7 +62,6 @@
InvalidOverriddenInstanceError
from twistedcaldav.log import Logger
from twistedcaldav.memcachelock import MemcacheLock, MemcacheLockTimeoutError
-from twistedcaldav.method.delete_common import DeleteResource
from twistedcaldav.scheduling.implicit import ImplicitScheduler
log = Logger()
@@ -972,17 +971,6 @@
yield reservation.unreserve()
returnValue(StatusResponse(responsecode.CREATED, "Resource created but immediately deleted by the server."))
-
- elif implicit_result == ImplicitScheduler.STATUS_ORPHANED_EVENT:
- if reservation:
- yield reservation.unreserve()
-
- # Now forcibly delete the event
- deleter = DeleteResource(self.request, self.destination, self.destination_uri, self.destinationparent, "0", internal_request=True)
- yield deleter.run()
-
- returnValue(StatusResponse(responsecode.OK, "Resource modified but immediately deleted by the server."))
-
else:
msg = "Invalid return status code from ImplicitScheduler: %s" % (implicit_result,)
log.err(msg)
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/caldav.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/caldav.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/caldav.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -181,6 +181,9 @@
# Store CALDAV:recipient property
child.writeDeadProperty(caldavxml.Recipient(davxml.HRef(recipient.cuaddr)))
+ # Store CALDAV:schedule-state property
+ child.writeDeadProperty(caldavxml.ScheduleState(caldavxml.ScheduleProcessed() if processed else caldavxml.ScheduleUnprocessed()))
+
# Store CS:schedule-changes property if present
if changes:
child.writeDeadProperty(changes)
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/icaldiff.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/icaldiff.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/icaldiff.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -216,7 +216,6 @@
old_attendee = old_attendees.get(value)
if old_attendee:
self._transferParameter(old_attendee, new_attendee, "PARTSTAT")
- self._transferParameter(old_attendee, new_attendee, "RSVP")
self._transferParameter(old_attendee, new_attendee, "SCHEDULE-STATUS")
def _transferParameter(self, old_property, new_property, parameter):
@@ -440,20 +439,12 @@
replyNeeded = False
- # ATTENDEE/PARTSTAT/RSVP
+ # ATTENDEE/PARTSTAT
serverAttendee = serverComponent.getAttendeeProperty((self.attendee,))
clientAttendee = clientComponent.getAttendeeProperty((self.attendee,))
if serverAttendee.params().get("PARTSTAT", ("NEEDS-ACTION",))[0] != clientAttendee.params().get("PARTSTAT", ("NEEDS-ACTION",))[0]:
serverAttendee.params()["PARTSTAT"] = clientAttendee.params().get("PARTSTAT", "NEEDS-ACTION")
replyNeeded = True
- if serverAttendee.params().get("RSVP", ("FALSE",))[0] != clientAttendee.params().get("RSVP", ("FALSE",))[0]:
- if clientAttendee.params().get("RSVP", ("FALSE",))[0] == "FALSE":
- try:
- del serverAttendee.params()["RSVP"]
- except KeyError:
- pass
- else:
- serverAttendee.params()["RSVP"] = ["TRUE",]
# Transfer these properties from the client data
replyNeeded |= self._transferProperty("X-CALENDARSERVER-PRIVATE-COMMENT", serverComponent, clientComponent)
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/implicit.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/implicit.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/implicit.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -16,7 +16,7 @@
from twext.web2.dav.davxml import ErrorResponse
-from twisted.internet.defer import inlineCallbacks, returnValue
+from twisted.internet.defer import inlineCallbacks, returnValue, succeed
from twisted.web2 import responsecode
from twisted.web2.dav import davxml
from twisted.web2.dav.util import joinURL
@@ -35,7 +35,6 @@
from twistedcaldav.scheduling.icaldiff import iCalDiff
from twistedcaldav.scheduling.itip import iTipGenerator
from twistedcaldav.scheduling.scheduler import CalDAVScheduler
-from twistedcaldav.scheduling.utils import getCalendarObjectForPrincipals
__all__ = [
"ImplicitScheduler",
@@ -54,7 +53,6 @@
# Return Status codes
STATUS_OK = 0
STATUS_ORPHANED_CANCELLED_EVENT = 1
- STATUS_ORPHANED_EVENT = 2
def __init__(self):
@@ -90,7 +88,7 @@
yield self.checkImplicitState()
# Attendees are not allowed to overwrite one type with another
- if not self.internal_request and self.state == "attendee" and (existing_type != new_type) and existing_resource:
+ if self.state == "attendee" and (existing_type != new_type) and existing_resource:
raise HTTPError(ErrorResponse(responsecode.FORBIDDEN, (caldav_namespace, "valid-attendee-change")))
returnValue((self.action != "none", new_type == "schedule",))
@@ -503,11 +501,6 @@
elif self.action == "create":
log.debug("Implicit - organizer '%s' is creating UID: '%s'" % (self.organizer, self.uid))
- # Always set RSVP=TRUE for any NEEDS-ACTION
- for attendee in self.calendar.getAllAttendeeProperties():
- if attendee.params().get("PARTSTAT", ["NEEDS-ACTION"])[0] == "NEEDS-ACTION":
- attendee.params()["RSVP"] = ["TRUE",]
-
yield self.scheduleWithAttendees()
# Always clear SCHEDULE-FORCE-SEND from all attendees after scheduling
@@ -798,9 +791,8 @@
self.return_status = ImplicitScheduler.STATUS_ORPHANED_CANCELLED_EVENT
returnValue(None)
else:
- log.debug("Attendee '%s' is not allowed to update UID: '%s' - missing organizer copy - removing entire event" % (self.attendee, self.uid,))
- self.return_status = ImplicitScheduler.STATUS_ORPHANED_EVENT
- returnValue(None)
+ log.debug("Attendee '%s' is not allowed to update UID: '%s' - missing organizer copy" % (self.attendee, self.uid,))
+ raise HTTPError(ErrorResponse(responsecode.FORBIDDEN, (caldav_namespace, "valid-attendee-change")))
elif isinstance(self.organizerAddress, InvalidCalendarUser):
log.debug("Attendee '%s' is not allowed to update UID: '%s' with invalid organizer '%s'" % (self.attendee, self.uid, self.organizer))
raise HTTPError(ErrorResponse(responsecode.FORBIDDEN, (caldav_namespace, "valid-attendee-change")))
@@ -825,10 +817,28 @@
"""
self.organizer_calendar = None
- calendar_resource, _ignore_name, _ignore_collection, _ignore_uri = (yield getCalendarObjectForPrincipals(self.request, self.organizerPrincipal, self.uid))
- if calendar_resource:
- self.organizer_calendar = calendar_resource.iCalendar()
-
+ if self.organizerPrincipal:
+ # Get Organizer's calendar-home
+ calendar_home = self.organizerPrincipal.calendarHome()
+
+ # FIXME: because of the URL->resource request mapping thing, we have to force the request
+ # to recognize this resource
+ self.request._rememberResource(calendar_home, calendar_home.url())
+
+ # Run a UID query against the UID
+
+ def queryCalendarCollection(collection, uri):
+ rname = collection.index().resourceNameForUID(self.uid)
+ if rname:
+ self.organizer_calendar = collection.iCalendar(rname)
+ return succeed(False)
+ else:
+ return succeed(True)
+
+ # NB We are by-passing privilege checking here. That should be OK as the data found is not
+ # exposed to the user.
+ yield report_common.applyToCalendarCollections(calendar_home, self.request, calendar_home.url(), "infinity", queryCalendarCollection, None)
+
def isAttendeeChangeInsignificant(self):
"""
Check whether the change is significant (PARTSTAT) or allowed
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/itip.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/itip.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/itip.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -365,13 +365,6 @@
existing_attendee.params()["SCHEDULE-STATUS"] = [reqstatus]
partstat_changed = (oldpartstat != partstat)
- # Always delete RSVP on PARTSTAT change
- if partstat_changed:
- try:
- del existing_attendee.params()["RSVP"]
- except KeyError:
- pass
-
# Handle attendee comments
if config.Scheduling.CalDAV.get("EnablePrivateComments", True):
# Look for X-CALENDARSERVER-PRIVATE-COMMENT property in iTIP component (State 1 in spec)
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/processing.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/processing.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/processing.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -16,19 +16,16 @@
from hashlib import md5
from twisted.internet import reactor
-from twisted.internet.defer import inlineCallbacks, returnValue
+from twisted.internet.defer import inlineCallbacks, returnValue, succeed
from twisted.web2.dav.method.report import NumberOfMatchesWithinLimits
from twisted.web2.dav.util import joinURL
-from twisted.web2.http import HTTPError
from twistedcaldav import customxml, caldavxml
from twistedcaldav.caldavxml import caldav_namespace
from twistedcaldav.ical import Property
-from twistedcaldav.instance import InvalidOverriddenInstanceError
from twistedcaldav.log import Logger
from twistedcaldav.method import report_common
from twistedcaldav.scheduling.cuaddress import normalizeCUAddr
from twistedcaldav.scheduling.itip import iTipProcessing, iTIPRequestStatus
-from twistedcaldav.scheduling.utils import getCalendarObjectForPrincipals
from vobject.icalendar import utc
import datetime
import time
@@ -81,27 +78,7 @@
if self.isOrganizerReceivingMessage():
result = (yield self.doImplicitOrganizer())
elif self.isAttendeeReceivingMessage():
- try:
- result = (yield self.doImplicitAttendee())
- except ImplicitProcessorException:
- # These we always pass up
- raise
- except Exception, e:
- # We attempt to recover from this. That involves trying to re-write the attendee data
- # to match that of the organizer assuming we have the organizer's full data available, then
- # we try the processing operation again.
- log.error("ImplicitProcessing - originator '%s' to recipient '%s' with UID: '%s' - exception raised will try to fix: %s" % (self.originator.cuaddr, self.recipient.cuaddr, self.uid, e))
- result = (yield self.doImplicitAttendeeEventFix(e))
- if result:
- log.error("ImplicitProcessing - originator '%s' to recipient '%s' with UID: '%s' - restored organizer's copy" % (self.originator.cuaddr, self.recipient.cuaddr, self.uid))
- try:
- result = (yield self.doImplicitAttendee())
- except Exception, e:
- log.error("ImplicitProcessing - originator '%s' to recipient '%s' with UID: '%s' - exception raised after fix: %s" % (self.originator.cuaddr, self.recipient.cuaddr, self.uid, e))
- raise ImplicitProcessorException("5.1;Service unavailable")
- else:
- log.error("ImplicitProcessing - originator '%s' to recipient '%s' with UID: '%s' - could not fix" % (self.originator.cuaddr, self.recipient.cuaddr, self.uid))
- raise ImplicitProcessorException("5.1;Service unavailable")
+ result = (yield self.doImplicitAttendee())
else:
log.error("METHOD:%s not supported for implicit scheduling." % (self.method,))
raise ImplicitProcessorException("3.14;Unsupported capability")
@@ -128,15 +105,32 @@
self.recipient_calendar = None
self.recipient_calendar_collection = None
- self.recipient_calendar_collection_uri = None
self.recipient_calendar_name = None
- calendar_resource, resource_name, calendar_collection, calendar_collection_uri = (yield getCalendarObjectForPrincipals(self.request, self.recipient.principal, self.uid))
- if calendar_resource:
- self.recipient_calendar = calendar_resource.iCalendar()
- self.recipient_calendar_collection = calendar_collection
- self.recipient_calendar_collection_uri = calendar_collection_uri
- self.recipient_calendar_name = resource_name
+ if self.recipient.principal:
+ # Get Recipient's calendar-home
+ calendar_home = self.recipient.principal.calendarHome()
+
+ # FIXME: because of the URL->resource request mapping thing, we have to force the request
+ # to recognize this resource
+ self.request._rememberResource(calendar_home, calendar_home.url())
+ # Run a UID query against the UID
+
+ def queryCalendarCollection(collection, uri):
+ rname = collection.index().resourceNameForUID(self.uid)
+ if rname:
+ self.recipient_calendar = collection.iCalendar(rname)
+ self.recipient_calendar_name = rname
+ self.recipient_calendar_collection = collection
+ self.recipient_calendar_collection_uri = uri
+ return succeed(False)
+ else:
+ return succeed(True)
+
+ # NB We are by-passing privilege checking here. That should be OK as the data found is not
+ # exposed to the user.
+ yield report_common.applyToCalendarCollections(calendar_home, self.request, calendar_home.url(), "infinity", queryCalendarCollection, None)
+
@inlineCallbacks
def doImplicitOrganizer(self):
@@ -659,47 +653,5 @@
if attendee.params().get("PARTSTAT", ("NEEDS-ACTION",))[0] != partstat:
attendee.params()["PARTSTAT"] = [partstat]
madeChanges = True
-
- # Always remove RSVP - this is only an attendee change so madeChanges
- # does not need to be changed
- try:
- del attendee.params()["RSVP"]
- except KeyError:
- pass
-
return madeChanges
-
- @inlineCallbacks
- def doImplicitAttendeeEventFix(self, ex):
-
- # Only certain types of exception should be handled - ones related to calendar data errors.
- # All others should result in the scheduling response coming back as a 5.x code
-
- if type(ex) not in (InvalidOverriddenInstanceError, HTTPError):
- raise ImplicitProcessorException("5.1;Service unavailable")
-
- # Check to see whether the originator is hosted on this server
- if not self.originator.principal:
- raise ImplicitProcessorException("5.1;Service unavailable")
-
- # Locate the originator's copy of the event
- calendar_resource, _ignore_name, _ignore_collection, _ignore_uri = (yield getCalendarObjectForPrincipals(self.request, self.originator.principal, self.uid))
- if not calendar_resource:
- raise ImplicitProcessorException("5.1;Service unavailable")
- originator_calendar = calendar_resource.iCalendar()
-
- # Get attendee's view of that
- originator_calendar.attendeesView((self.recipient.cuaddr,))
-
- # Locate the attendee's copy of the event if it exists.
- recipient_resource, recipient_resource_name, recipient_collection, recipient_collection_uri = (yield getCalendarObjectForPrincipals(self.request, self.recipient.principal, self.uid))
-
- # We only need to fix data that already exists
- if recipient_resource:
- if originator_calendar.mainType() != None:
- yield self.writeCalendarResource(recipient_collection_uri, recipient_collection, recipient_resource_name, originator_calendar)
- else:
- yield self.deleteCalendarResource(recipient_collection_uri, recipient_collection, recipient_resource_name)
-
- returnValue(True)
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/scheduler.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/scheduler.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/scheduler.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -55,7 +55,6 @@
"CalDAVScheduler",
"IScheduleScheduler",
"IMIPScheduler",
- "DirectScheduler",
]
@@ -387,7 +386,7 @@
# Now process iMIP recipients
if imip_recipients:
yield self.generateIMIPSchedulingResponses(imip_recipients, responses, freebusy)
-
+
# Return with final response if we are done
returnValue(responses)
@@ -790,33 +789,6 @@
log.err(msg)
raise HTTPError(ErrorResponse(responsecode.FORBIDDEN, (caldav_namespace, "valid-calendar-data"), description=msg))
-
-class DirectScheduler(Scheduler):
- """ An implicit scheduler meant for use by local processes which don't
- need to go through all these checks. """
-
- def checkAuthorization(self):
- pass
-
- def checkOrganizer(self):
- pass
-
- def checkOrganizerAsOriginator(self):
- pass
-
- def checkAttendeeAsOriginator(self):
- pass
-
- def securityChecks(self):
- pass
-
- def checkOriginator(self):
- pass
-
- def checkRecipients(self):
- pass
-
-
class IMIPScheduler(Scheduler):
def checkAuthorization(self):
Modified: CalendarServer/branches/config-separation/twistedcaldav/scheduling/test/test_icaldiff.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/test/test_icaldiff.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/test/test_icaldiff.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -559,7 +559,7 @@
DTSTART:20080601T120000Z
DTEND:20080601T130000Z
ATTENDEE:mailto:user1 at example.com
-ATTENDEE;PARTSTAT=ACCEPTED:mailto:user2 at example.com
+ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:mailto:user2 at example.com
ORGANIZER;CN=User 01:mailto:user1 at example.com
END:VEVENT
END:VCALENDAR
@@ -2546,7 +2546,7 @@
DTSTART:20080601T120000Z
DTEND:20080601T130000Z
ATTENDEE:mailto:user1 at example.com
-ATTENDEE;PARTSTAT=ACCEPTED:mailto:user2 at example.com
+ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:mailto:user2 at example.com
ORGANIZER;CN=User 01:mailto:user1 at example.com
END:VEVENT
END:VCALENDAR
@@ -2591,7 +2591,7 @@
DTSTART:20080601T130000Z
DTEND:20080601T140000Z
ATTENDEE:mailto:user1 at example.com
-ATTENDEE;PARTSTAT=ACCEPTED:mailto:user2 at example.com
+ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:mailto:user2 at example.com
ORGANIZER;CN=User 01:mailto:user1 at example.com
END:VEVENT
END:VCALENDAR
@@ -2686,7 +2686,7 @@
DTSTART:20080601T120000Z
DTEND:20080601T130000Z
ATTENDEE:mailto:user1 at example.com
-ATTENDEE;PARTSTAT=ACCEPTED:mailto:user2 at example.com
+ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:mailto:user2 at example.com
ORGANIZER;CN=User 01:mailto:user1 at example.com
END:VEVENT
BEGIN:VEVENT
@@ -2758,7 +2758,7 @@
DTSTART:20080601T140000Z
DTEND:20080601T150000Z
ATTENDEE:mailto:user1 at example.com
-ATTENDEE;PARTSTAT=ACCEPTED:mailto:user2 at example.com
+ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:mailto:user2 at example.com
ORGANIZER;CN=User 01:mailto:user1 at example.com
END:VEVENT
BEGIN:VEVENT
@@ -2767,7 +2767,7 @@
DTSTART:20080602T120000Z
DTEND:20080602T130000Z
ATTENDEE:mailto:user1 at example.com
-ATTENDEE;PARTSTAT=ACCEPTED:mailto:user2 at example.com
+ATTENDEE;PARTSTAT=ACCEPTED;RSVP=TRUE:mailto:user2 at example.com
ORGANIZER;CN=User 01:mailto:user1 at example.com
END:VEVENT
END:VCALENDAR
Deleted: CalendarServer/branches/config-separation/twistedcaldav/scheduling/utils.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/scheduling/utils.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/scheduling/utils.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -1,56 +0,0 @@
-#
-# Copyright (c) 2005-2009 Apple Inc. All rights reserved.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-##
-
-from twisted.internet.defer import inlineCallbacks, succeed, returnValue
-from twistedcaldav.method import report_common
-
- at inlineCallbacks
-def getCalendarObjectForPrincipals(request, principal, uid):
- """
- Get a copy of the event for a principal.
- """
-
- result = {}
- result["resource"] = None
- result["resource_name"] = None
- result["calendar_collection"] = None
- result["calendar_collection_uri"] = None
- if principal:
- # Get principal's calendar-home
- calendar_home = principal.calendarHome()
-
- # FIXME: because of the URL->resource request mapping thing, we have to force the request
- # to recognize this resource
- request._rememberResource(calendar_home, calendar_home.url())
-
- # Run a UID query against the UID
-
- def queryCalendarCollection(collection, uri):
- rname = collection.index().resourceNameForUID(uid)
- if rname:
- result["resource"] = collection.getChild(rname)
- result["resource_name"] = rname
- result["calendar_collection"] = collection
- result["calendar_collection_uri"] = uri
- return succeed(False)
- else:
- return succeed(True)
-
- # NB We are by-passing privilege checking here. That should be OK as the data found is not
- # exposed to the user.
- yield report_common.applyToCalendarCollections(calendar_home, request, calendar_home.url(), "infinity", queryCalendarCollection, None)
-
- returnValue((result["resource"], result["resource_name"], result["calendar_collection"], result["calendar_collection_uri"],))
Modified: CalendarServer/branches/config-separation/twistedcaldav/test/test_config.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/test/test_config.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/test/test_config.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -57,8 +57,8 @@
open(self.testConfig, "w").write(testConfig)
def tearDown(self):
- config.setDefaults(DEFAULT_CONFIG)
- config.reset()
+ config.setProvider(ConfigProvider(DEFAULT_CONFIG))
+ config.load(None)
def testDefaults(self):
for key, value in DEFAULT_CONFIG.iteritems():
Modified: CalendarServer/branches/config-separation/twistedcaldav/test/test_memcacheprops.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/test/test_memcacheprops.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/test/test_memcacheprops.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -28,6 +28,7 @@
from twisted.web2.http import HTTPError
+from twistedcaldav.config import config
from twistedcaldav.memcacheprops import MemcachePropertyCollection
from twistedcaldav.test.util import InMemoryPropertyStore
from twistedcaldav.test.util import TestCase
Modified: CalendarServer/branches/config-separation/twistedcaldav/test/test_upgrade.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/test/test_upgrade.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/test/test_upgrade.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -282,12 +282,6 @@
}
after = {
- "tasks" :
- {
- "incoming" :
- {
- },
- },
".calendarserver_version" :
{
"@contents" : "1",
@@ -412,12 +406,6 @@
}
after = {
- "tasks" :
- {
- "incoming" :
- {
- },
- },
".calendarserver_version" :
{
"@contents" : "1",
@@ -537,12 +525,6 @@
}
after = {
- "tasks" :
- {
- "incoming" :
- {
- },
- },
".calendarserver_version" :
{
"@contents" : "1",
@@ -668,12 +650,6 @@
}
after = {
- "tasks" :
- {
- "incoming" :
- {
- },
- },
".calendarserver_version" :
{
"@contents" : "1",
@@ -785,12 +761,6 @@
after = {
- "tasks" :
- {
- "incoming" :
- {
- },
- },
"calendars" :
{
"__uids__" :
Modified: CalendarServer/branches/config-separation/twistedcaldav/upgrade.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/upgrade.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/upgrade.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -26,7 +26,7 @@
from twistedcaldav.ical import Component
from twistedcaldav import caldavxml
from calendarserver.tools.util import getDirectory
-import xattr, os, zlib, hashlib, datetime, pwd, grp, shutil
+import xattr, os, zlib, hashlib, datetime, pwd, grp
from zlib import compress
from cPickle import loads as unpickle, UnpicklingError
@@ -218,13 +218,7 @@
try:
if not os.path.exists(config.DataRoot):
makeDirsUserGroup(config.DataRoot, uid=uid, gid=gid)
- try:
- os.rename(oldDbPath, newDbPath)
- except OSError:
- # Can't rename, must copy/delete
- shutil.copy2(oldDbPath, newDbPath)
- os.remove(oldDbPath)
-
+ os.rename(oldDbPath, newDbPath)
except Exception, e:
raise UpgradeError(
"Upgrade Error: unable to move the old calendar user proxy database at '%s' to '%s' due to %s."
@@ -286,22 +280,7 @@
if os.path.exists(dbPath):
os.chown(dbPath, uid, gid)
- def createTaskServiceDirectory(config, uid, gid):
- taskDir = os.path.join(config.DataRoot, "tasks")
- if not os.path.exists(taskDir):
- os.mkdir(taskDir)
- os.chown(taskDir, uid, gid)
-
- incomingDir = os.path.join(taskDir, "incoming")
- if not os.path.exists(incomingDir):
- os.mkdir(incomingDir)
- os.chown(incomingDir, uid, gid)
-
- return incomingDir
-
-
-
directory = getDirectory()
docRoot = config.DocumentRoot
@@ -369,10 +348,8 @@
os.rmdir(dirPath)
- # Count how many calendar homes we'll be processing, and build
- # list of pending inbox items
+ # Count how many calendar homes we'll be processing
total = 0
- inboxItems = set()
for first in os.listdir(uidHomes):
if len(first) == 2:
firstPath = os.path.join(uidHomes, first)
@@ -381,21 +358,7 @@
secondPath = os.path.join(firstPath, second)
for home in os.listdir(secondPath):
total += 1
- homePath = os.path.join(secondPath, home)
- inboxPath = os.path.join(homePath, "inbox")
- if os.path.exists(inboxPath):
- for inboxItem in os.listdir(inboxPath):
- if not inboxItem.startswith("."):
- inboxItems.add(os.path.join(inboxPath, inboxItem))
- incomingDir = createTaskServiceDirectory(config, uid, gid)
- if inboxItems:
- taskFile = os.path.join(incomingDir, "scheduleinboxes.task")
- with open(taskFile, "w") as out:
- for item in inboxItems:
- out.write("%s\n" % (item))
- os.chown(taskFile, uid, gid)
-
if total:
log.warn("Processing %d calendar homes in %s" % (total, uidHomes))
Modified: CalendarServer/branches/config-separation/twistedcaldav/util.py
===================================================================
--- CalendarServer/branches/config-separation/twistedcaldav/util.py 2009-07-08 23:10:07 UTC (rev 4436)
+++ CalendarServer/branches/config-separation/twistedcaldav/util.py 2009-07-08 23:19:44 UTC (rev 4437)
@@ -21,7 +21,7 @@
from twisted.internet import ssl, reactor
from twisted.web import client
-from twistedcaldav.log import LoggingMixIn
+from twistedcaldav.log import Logger, LoggingMixIn
from twisted.python import failure
from hashlib import md5, sha1
import base64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20090708/58ee9bec/attachment-0001.html>
More information about the calendarserver-changes
mailing list