Free busy queries should be targeted at calendar users addresses, not at specific calendars owned by those users. It should not be required to use specific calendar names to obtain free busy information. For security concerns, the calendar name(s) should NOT be returned in the response.

A free busy query should allow a user to specify any calendar user address (URI). The server should differentiate an error response where the calendar user is internal but access is denied (privilege error), and where the calendar user is external and the server doesn’t know how to get that user’s calendar (unknown user error) — so that the client may try alternative methods to get the external user’s calendar if it is able. The protocol should support error codes for the following cases:

A user should be able to get the free busy information of multiple users in a single request to the server.

Often times the organizer of an event is unable to schedule the event at a time where all the attendees are free. The organizer should have access to the individual free busy information to know which users his event will create a conflict with (e.g., a manager may decide to double book one of the attendees under his direct control, but may want to avoid double booking his own manager). The server must not aggregate free-busy information for different users, so that the client software will be able to present the free-busy information or error status on a per-user basis.

This may require additional human interaction to know what an external group is, and to be able to specify it in the request — or an understanding that external groups have an email address too. A separate VFREEBUSY component should be returned per group member. The protocol should support group names as an element for the request AND error codes for the following cases:

The protocol should support group names as an element for the request but suppress some error codes for privacy, to insure clients can’t infer group members. See Requirement 2 for more response information.

Typically, users are only interested in the free busy information of other users for a limited period of time (e.g., this week only).

The administrative assistant of a manager must be able to query the free busy information of users that have granted the manager the right to query their free busy information. See Requirement 14

Users want to get an immediate response to a free busy query to be able to schedule an event immediately with the same people whose free busy information was queried. Note: Given that the response to a free busy query must be synchronous, there is no purpose in keeping a copy of a free busy query on the CalDAV server.

Timeouts must be considered for the following cases:

Different status codes could be used for the following conditions: (1) the information was correctly returned, (2) the calendar user address is invalid, (3) the calendar user address doesn’t exist, (4) free busy information is not available synchronously for this calendar user — timeout, or (5) permission has been denied to access the free busy information of this calendar user, etc. iTIP status codes should be used.

A user may own calendars that don’t impact their availability and their availability may be impacted by calendars that they do not own. As such, a user should be able to specify any calendar on any server(s) which may impact their availability.

Most users only need to locate the resource that specifies the calendar collections that contributes to their own free busy information, but administrative assistants may need to locate/edit/manage the resource that specifies the calendar collections that contributes to the free busy information of their managers. The protocol should support granting permissions to and allowing others to manage these resources on behalf of oneself.

See Requirement 1.

The user will receive the scheduling message, but the user IS NOT listed as an attendee. This means that the message is FYI only, and the user is not expected to respond to the scheduling request. The recipient information must not be exposed to any other recipient or attendee for security/privacy issues.

If it is desired to communicate that this user was informed of the schedule request, they may be listed as a non-required attendee in the iCalendar data, which means everyone will know that user may have received the message.

The implication here is that the local CalDAV server must be the directory lookup service and the forwarder of the request — not the requesting client.

The organizer of an event may want to send a copy of a meeting invitation to the manager of one of the attendee to inform him. The organizer doesn’t necessarily want the attendee to know that a copy of the meeting invitation was sent to his manager. This “manager” recipient is not an attendee, and thus, cannot respond to the message.

Noting that Internet group support is weak, at best, the protocol must not prevent a group request, where all member permissions/grants are correct, from allowing a scheduling message to be posted. The minimum functionality of a “group” being a convenient way of maintaining a collection of existing users must be supported.

Group permissions/grants do not override individual member permissions/grants. You need both to successfully receive information.

Groups may be inclusive (all members participate) or exclusive (only one help desk person must respond).

See Requirement 2/Requirement 5 for response status/errors.

The organizer may receive attendee replies to a scheduling request out of order. The organizer should have a way to know whether they should ignore a reply from an attendee given that a more recent reply was already received from that attendee.

The organizer may receive a reply, from an attendee, that makes reference to a scheduling request that preceded the last scheduling request sent to that attendee.

This is currently an issue due to the existing requirement of explicitly granting access to each submitter.

Attendees may receive requests from an organizer out of order or multiple times. The attendee should have a way to detect out of order or duplicate requests and ignore them. This requires maintaining enough state information on the server and/or client to detect any problems.

If an attendee receives a scheduling request, they should be able to respond to it, if a response is required.

Attendees need to be allowed to “change their minds” about a reply they have previously sent to an organizer. So they must be able to send additional replies to the same scheduling request, each indicating a change in status. These replies need to be appropriately tracked by the organizer to ensure proper sequencing.

The originator might be a different user than the organizer (e.g., a calendar user forwarding a scheduling message, a calendar user sending a scheduling message on behalf of the organizer).

Security issue: We must notify the client and/or log on the server that the organizer has changed, to insure no one is masquerading.

Users should be able to specify which users are granted the right to schedule their time — i.e.: their managers and/or administrative assistant.

A manager should be able to grant their administrative assistant the right to submit/accept schedule requests.

The protocol is stateless — the original invite should/may not be stored on the server. New attendees may have been added and the organizer may have changed from the original message. The user must specify who he/she will receive schedule replies from.

Handled by the requirement to BCC (blind copy) a recipient.

A user may wish to forward the request to their boss for permission, or their admin/delegate to manage. Security issue: A lot of potentially sensitive information is contained in the message. Difficult to differentiate (Re:/FYI:/or real scheduling message) — recommend to use email.

The client application needs to be able to display these states, and the server needs to be able to store these statuses— via message sequencing, etc. This requirement is out of scope for the scheduling protocol.