tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6638

 
 
 

Scheduling Extensions to CalDAV

Part 3 of 4, p. 34 to 54
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 34 
4.  Processing Incoming Scheduling Messages

   Scheduling operations can cause the delivery of a scheduling message
   into an "Organizer's" or "Attendee's" scheduling Inbox collection.
   Servers MUST automatically process incoming scheduling messages using
   the rules defined by [RFC5546], by creating or updating the
   corresponding scheduling object resources on calendars owned by the
   owner of the scheduling Inbox collection.  In addition, the
   scheduling message is stored in the scheduling Inbox collection as an
   indicator to the client that a scheduling operation has taken place.
   Scheduling messages are typically removed from the scheduling Inbox
   collection by the client once the calendar user has acknowledged the
   change.

   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 (i.e., a schedule message from another user
   can cause modifications to resources in calendar collections that the
   other user would not normally have read or write access to).
   Additionally, servers MUST take into account any scheduling Inbox
   collection preconditions (see Section 2.2) when delivering the
   scheduling message, and MUST take into account the similar
   preconditions on any calendar collection that contains, or would
   contain, the corresponding scheduling object resource.

4.1.  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 processes the scheduling
   message and creates a new scheduling object resource as per
   Section 4.3.

   In the case of an update, the server processes the scheduling message
   and updates the matching scheduling object resource belonging to the
   "Attendee" to reflect the changes sent by the "Organizer".

   In each case, the scheduling message MUST only appear in the
   "Attendee's" scheduling Inbox collection once all automatic
   processing has been done.

Top      Up      ToC       Page 35 
4.2.  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".  If the corresponding scheduling object resource
   cannot be found, the server SHOULD ignore the scheduling message.

   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 instances of a recurring event).

   The server MUST also update or add the "SCHEDULE-STATUS" property
   parameter on each matching "ATTENDEE" iCalendar property and set 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" replying, subject to the recurrence requirements of
   Section 3.2.6.

   The scheduling message MUST only appear in the "Organizer's"
   scheduling Inbox collection once all automatic processing has been
   done.

4.3.  Default Calendar Collection

   The server processes scheduling messages received for an "Attendee"
   by creating a new scheduling object resource in a calendar collection
   belonging to the "Attendee", when one does not already exist.  A
   calendar user that is 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.  The CALDAV:schedule-default-calendar-URL WebDAV
   property, which can be present on the scheduling Inbox collection of
   a calendar user, specifies whether this calendar user has a default
   calendar collection.  See Section 9.2.

Top      Up      ToC       Page 36 
   Servers SHOULD create new scheduling object resources in the default
   calendar collection, if the CALDAV:schedule-default-calendar-URL
   WebDAV property is set.

   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, the
   server MUST ensure that any new value 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.

4.3.1.  Additional Method Preconditions

   This specification defines additional method preconditions (see
   Section 16 of WebDAV [RFC4918]) to provide machine-parseable
   information in error responses.

4.3.1.1.  CALDAV:default-calendar-needed Precondition

   Name:  default-calendar-needed

   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-needed EMPTY>

4.3.1.2.  CALDAV:valid-schedule-default-calendar-URL Precondition

   Name:  valid-schedule-default-calendar-URL

   Namespace:  urn:ietf:params:xml:ns:caldav

   Apply to:  PROPPATCH

Top      Up      ToC       Page 37 
   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
      do not 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>

5.  Request for Busy Time Information

   Busy time information of one or more calendar users can be determined
   by submitting a POST request targeted at the scheduling Outbox
   collection of the calendar user requesting the information (the
   "Organizer").  To accomplish this, the request body MUST contain a
   "VFREEBUSY" calendar component with the "METHOD" iCalendar property
   set to the value "REQUEST" as specified in Section 3.3.2 of iTIP
   [RFC5546].  The resource identified by the Request-URI MUST be a
   resource collection of type CALDAV:schedule-outbox (Section 2.1).
   The "ORGANIZER" property value in the "VFREEBUSY" component MUST
   match one of the calendar user addresses of the owner of the Outbox
   collection.

   A response to a busy time request that indicates status for one or
   more calendar users MUST be an XML document with a CALDAV:schedule-
   response XML element as its root element.  This element MUST contain
   one CALDAV:response element for each calendar user, with each such
   element in turn containing elements that indicate which calendar user
   they correspond to, the scheduling status for that calendar user, any
   error codes, and an optional description.  For a successful busy time
   request, a CALDAV:calendar-data element is also present for each
   calendar user, containing the actual busy time information (i.e., an
   iCalendar "VFREEBUSY" component).  See Section 10 for details on the
   child elements.  See Appendix B.5 for an example busy time request
   and response.

Top      Up      ToC       Page 38 
5.1.  Status Codes

   The list below summarizes the most common status codes used for this
   method.  However, clients need to be prepared to handle other
   2/3/4/5xx series status codes as well.

      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.

5.2.  Additional Method Preconditions

   The following are existing preconditions that are reused for the POST
   method on an Outbox collection.

   o  DAV:need-privileges [RFC3744]

   o  CALDAV:supported-calendar-data [RFC4791]

   o  CALDAV:valid-calendar-data [RFC4791]

   o  CALDAV:max-resource-size [RFC4791]

   The following are new method preconditions for the POST method on an
   Outbox collection.

5.2.1.  CALDAV:valid-scheduling-message Precondition

   Name:  valid-scheduling-message

   Namespace:  urn:ietf:params:xml:ns:caldav

   Apply to:  POST

   Use with:  400 Bad Request

Top      Up      ToC       Page 39 
   Purpose:  (precondition) -- The resource submitted in the POST
      request MUST obey all the restrictions specified in Section 3.3.2
      of iTIP [RFC5546].

   Definition:

     <!ELEMENT valid-scheduling-message EMPTY>

5.2.2.  CALDAV:valid-organizer Precondition

   Name:  valid-organizer

   Namespace:  urn:ietf:params:xml:ns:caldav

   Apply to:  POST

   Use with:  403 Forbidden

   Purpose:  (precondition) -- The "ORGANIZER" property value in the
      POST request's scheduling message MUST match one of the calendar
      user addresses of the owner of the scheduling Outbox collection
      being targeted by the request.

   Definition:

     <!ELEMENT valid-organizer EMPTY>

6.  Scheduling Privileges

   New scheduling privileges are 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.

6.1.  Privileges on Scheduling Inbox Collections

   This section defines new WebDAV Access Control List (ACL) [RFC3744]
   privileges that are defined 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.

Top      Up      ToC       Page 40 
   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.

6.1.1.  CALDAV:schedule-deliver Privilege

   CALDAV:schedule-deliver is an aggregate privilege as per Section 6.3.

     <!ELEMENT schedule-deliver EMPTY>

6.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>

6.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>

6.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>

6.2.  Privileges on Scheduling Outbox Collections

   This section defines new WebDAV ACL [RFC3744] 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 (e.g., assistants working
   on behalf of their boss).

Top      Up      ToC       Page 41 
   The privileges defined in this section are ignored if applied to a
   resource other than a scheduling Outbox collection.

6.2.1.  CALDAV:schedule-send Privilege

   CALDAV:schedule-send is an aggregate privilege as per Section 6.3.

     <!ELEMENT schedule-send EMPTY>

6.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 the
   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 scheduling messages to "Attendees".

     <!ELEMENT schedule-send-invite EMPTY>

6.2.3.  CALDAV:schedule-send-reply Privilege

   The CALDAV:schedule-send-reply privilege controls the sending of
   scheduling messages by "Attendees".

   Users granted the DAV:bind privilege on a calendar collection, or the
   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 scheduling message replies to the
   "Organizer".

     <!ELEMENT schedule-send-reply EMPTY>

6.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>

Top      Up      ToC       Page 42 
6.3.  Aggregation of Scheduling Privileges

   Server implementations MUST aggregate the scheduling privileges as
   follows:

      DAV:all contains CALDAV:schedule-deliver and CALDAV:schedule-send;

      CALDAV:schedule-deliver contains CALDAV:schedule-deliver-invite,
      CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-freebusy;

      CALDAV:schedule-send contains CALDAV:schedule-send-invite, CALDAV:
      schedule-send-reply, and CALDAV:schedule-send-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]

7.  Additional iCalendar Property Parameters

   This specification defines additional iCalendar property parameters
   to support the CalDAV scheduling extensions.

7.1.  Schedule Agent Parameter

   Parameter Name:  SCHEDULE-AGENT

   Purpose:  To specify the agent expected to deliver scheduling
      messages to the corresponding "Organizer" or "Attendee".

Top      Up      ToC       Page 43 
   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 scheduling
                     / x-name        ; Experimental type
                     / iana-token)   ; Other IANA-registered type
     ;
     ; If the parameter is not present, its value defaults to SERVER.
     ; "x-name" and "iana-token" are defined in Section 3.1 of
     ; [RFC5545].

   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 a scheduling
      operation 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 a
      scheduling operation.  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 a scheduling operation.

      Clients MUST NOT include this parameter in any scheduling messages
      that they themselves send.

      The parameter value MUST be the same on every "ORGANIZER" property
      in a scheduling object resource.

      The parameter value MUST be the same on each "ATTENDEE" property
      whose values match in a scheduling object resource.

      Servers and clients MUST treat x-name and iana-token values they
      do not recognize the same way as they would the "NONE" value.

   Example:

     ORGANIZER;SCHEDULE-AGENT=SERVER:mailto:bernard@example.com
     ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus@example.com

Top      Up      ToC       Page 44 
7.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-token" is defined in Section 3.1 of [RFC5545].  Its value
     ; MUST be an IANA-registered iCalendar "METHOD" property value.

   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 a scheduling operation.

      Clients MUST 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 [RFC5546]) when the "SCHEDULE-FORCE-
      SEND" parameter is set to an iana-token value they do not
      recognize.

Top      Up      ToC       Page 45 
   Example:

     ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com
     ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com

7.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 [RFC5545].  The
     ; 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 only add or change this property parameter on any
      "ATTENDEE" properties corresponding to calendar users who were
      sent a scheduling message via a scheduling operation.  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 a scheduling operation.  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 a scheduling operation.

      Clients MUST NOT include this parameter in any scheduling messages
      that they themselves send.

Top      Up      ToC       Page 46 
      Values for this property parameter are described in Section 3.2.9.

   Example:

     ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com
     ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com

8.  Additional Message Header Fields

   This specification defines additional HTTP request and response
   headers for use with CalDAV.

8.1.  Schedule-Reply Request Header

     Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")

   Example:

     Schedule-Reply: F

   When an "Attendee" removes a scheduling object resource as per
   Section 3.2.2.4, and the Schedule-Reply header is set to the value
   "T" (true) or is not present, 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
   scheduling operation processing.

   When the Schedule-Reply header is set to the value "F" (false), the
   server MUST NOT send a scheduling message as part of its normal
   scheduling operation processing.

   The Schedule-Reply request header is used by a client to indicate to
   a server whether or not a scheduling operation ought to 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 removal.  There are situations in
   which unsolicited scheduling messages need to be silently removed (or
   ignored) for security or privacy reasons.  This request header allows
   the scheduling object resource to be removed if such a need arises.

8.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 3.2.10.

   All scheduling object resources MUST support the Schedule-Tag header.

Top      Up      ToC       Page 47 
     Schedule-Tag = "Schedule-Tag" ":" opaque-tag
     ; "opaque-tag" is defined in Section 3.11 of [RFC2616].

   Example:

     Schedule-Tag: "12ab34-cd56ef"

8.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"

9.  Additional WebDAV Properties

   This specification defines the following new WebDAV properties for
   use with CalDAV.

9.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 busy time information.

   Protected:  This property MAY be protected and SHOULD NOT be returned
      by a PROPFIND DAV:allprop request (as defined in Section 14.2 of
      [RFC4918]).

   COPY/MOVE behavior:  This property value SHOULD be kept during a MOVE
      operation, and SHOULD be copied and preserved in a COPY.

Top      Up      ToC       Page 48 
   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 ought to contribute to the owner's busy time.  When the
      CALDAV:opaque element is used, all calendar object resources in
      the corresponding calendar collection MUST contribute to busy
      time, assuming that 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 busy time.

      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>
     <!-- Affects busy time searches -->

     <!ELEMENT transparent EMPTY>
     <!-- Invisible to busy time searches -->

   Example:

     <C:schedule-calendar-transp
          xmlns:C="urn:ietf:params:xml:ns:caldav">
       <C:opaque/>
     </C:schedule-calendar-transp>

9.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 that cannot be moved or copied.

Top      Up      ToC       Page 49 
   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 4.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>

9.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 value is determined by the server
      and MAY be different from the value on the source resource.

   Description:  The CALDAV:schedule-tag property MUST be defined on all
      scheduling object resources.  This property is described in
      Section 3.2.10.

   Definition:

     <!ELEMENT schedule-tag (#PCDATA)>

Top      Up      ToC       Page 50 
   Example:

     <C:schedule-tag xmlns:C="urn:ietf:params:xml:ns:caldav"
     >"12345-67890"</C:schedule-tag>

10.  XML Element Definitions

10.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 5.

   Definition:

     <!ELEMENT schedule-response (response*)>

10.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 5.

   Definition:

     <!ELEMENT response (recipient,
                         request-status,
                         calendar-data?,
                         DAV:error?,
                         DAV:responsedescription?)>

     <!-- CALDAV:calendar-data is defined in Section 9.6 of
     RFC 4791 and when used here uses the definition with
     content (#PCDATA) only. -->

10.3.  CALDAV:recipient XML Element

   Name:  recipient

   Namespace:  urn:ietf:params:xml:ns:caldav

Top      Up      ToC       Page 51 
   Purpose:  The calendar user address that the enclosing response for a
      POST method request is for.

   Description:  See Section 5.

   Definition:

     <!ELEMENT recipient (DAV:href)>

10.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 5.

   Definition:

     <!ELEMENT request-status (#PCDATA)>

11.  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
   Transport Layer Security (TLS) as defined in [RFC2818] for all
   scheduling operations.  Clients MUST use the procedures detailed in
   Section 6 of [RFC6125] to verify the authenticity of the server.
   Servers MUST make use of HTTP authentication [RFC2617] to verify the
   authenticity of the calendar user for whom the client is sending
   requests.

11.1.  Preventing Denial-of-Service Attacks

   Servers MUST ensure that clients cannot consume excessive server
   resources by carrying out "large" scheduling operations.  In
   particular, servers SHOULD enforce CALDAV:max-resource-size, CALDAV:
   max-instances, and CALDAV:max-attendees-per-instance preconditions as
   applicable for scheduling Inbox and Outbox collections.

Top      Up      ToC       Page 52 
11.2.  Verifying Scheduling Operations

   When handling a scheduling operation:

   1.  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.

   2.  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 of the
       DAV:owner of the calendar collection in which a scheduling object
       resource is being manipulated.

   3.  Servers MUST only deliver scheduling messages to 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 calendar collection in which a scheduling object
       resource is being manipulated.

   4.  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.

   5.  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.

11.3.  Verifying Busy Time Information Requests

   When handling a POST request on a scheduling Outbox collection:

   1.  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.

   2.  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.

Top      Up      ToC       Page 53 
   3.  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.

11.4.  Privacy Issues

   This specification only defines how calendar users on the same server
   are able to schedule with each other -- unauthenticated users have no
   way to carry out scheduling operations.  Access control privileges
   (as per Section 6) can control which of those users can schedule with
   others.  Calendar users not wishing to expose their calendar
   information to other users can do so by denying privileges to
   specific users, or all users, for all scheduling operations, or
   perhaps only freebusy.

   "Attendees" can also use the Schedule-Reply request header
   (Section 8.1) 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".

   Servers MUST NOT expose any private iCalendar data, or WebDAV
   resource state information (URLs, WebDAV properties, etc.) for one
   calendar user to another via scheduling messages or error responses
   to scheduling operations.  In particular, as per Section 8.1 of
   [RFC4918], authorization errors MUST take preference over other
   errors.

11.5.  Mitigation of iTIP Threats

   Section 6.1 of iTIP [RFC5546] defines a set of potential threats in a
   scheduling system, and Section 6.2 of [RFC5546] defines
   recommendations on how those can be addressed in protocols using
   iTIP.  This specification addresses the iTIP threats in the following
   manner:

   Spoofing the "Organizer":  Addressed by item 4 in Section 11.2.

   Spoofing the "Attendee":  Addressed by Section 3.2.2.1 and item 2 in
      Section 11.2.

   Unauthorized Replacement of the "Organizer":  Addressed by item 5 in
      Section 11.2.

   Eavesdropping and Data Integrity:  Addressed by requiring TLS.

Top      Up      ToC       Page 54 
   Flooding a Calendar:  Addressed by requirements in Section 11.1.

   Unauthorized REFRESH Requests:  This specification does not support
      the REFRESH method.



(page 54 continued on part 4)

Next RFC Part