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. 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.
Section 3.2.6. The scheduling message MUST only appear in the "Organizer's" scheduling Inbox collection once all automatic processing has been done. Section 9.2.
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. Section 16 of WebDAV [RFC4918]) to provide machine-parseable information in error responses.
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> 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.
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> Appendix A clarify which scheduling methods (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling privilege defined in this section. 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.
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. Section 6.3. <!ELEMENT schedule-deliver EMPTY> 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).
The privileges defined in this section are ignored if applied to a resource other than a scheduling Outbox collection. Section 6.3. <!ELEMENT schedule-send EMPTY>
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:firstname.lastname@example.org ATTENDEE;SCHEDULE-AGENT=NONE:mailto:email@example.com
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.
Example: ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:firstname.lastname@example.org ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:email@example.com Section 22.214.171.124 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.
Values for this property parameter are described in Section 3.2.9. Example: ATTENDEE;SCHEDULE-STATUS="2.0":mailto:firstname.lastname@example.org ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:email@example.com Section 126.96.36.199, 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. Section 3.2.10. 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]. Example: Schedule-Tag: "12ab34-cd56ef" Section 3.11 of [RFC2616]. Example: If-Schedule-Tag-Match: "12ab34-cd56ef" 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.
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>
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> 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)>
Example: <C:schedule-tag xmlns:C="urn:ietf:params:xml:ns:caldav" >"12345-67890"</C:schedule-tag> Section 5. Definition: <!ELEMENT schedule-response (response*)> 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. -->
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)> Section 5. Definition: <!ELEMENT request-status (#PCDATA)> 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.
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. 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. 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 188.8.131.52 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.
Flooding a Calendar: Addressed by requirements in Section 11.1. Unauthorized REFRESH Requests: This specification does not support the REFRESH method.