[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