Fr:RFC Compliance/CalDAV Scheduling

Indications des progrès sur l'avancement du respect des extensions de

Aperçue
Les fonctionnalités supportées par DAViCal 0.9.8 sont essentiellement le composant libre/occuppé demande de cette RFC. Le support complet de planification n'est pas encore implémentée.

Details of Unsupported Features
Section Feature Requirement Status as at 0.9.8 3. 4.1. 4.1. 4.2. 4.2. 4.2. 4.3. 4.3. 4.3. 5.2.1.
 * The server 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.
 * style="text-align:center"|
 * A scheduling Outbox collection MUST report the DAV:collection and CALDAV:schedule-outbox XML elements in the value of the DAV::resourcetype property.
 * style="text-align:center"|
 * A scheduling Outbox collection MUST NOT be a child (at any depth) of a calendar collection resource.
 * style="text-align:center"|
 * A scheduling Inbox collection MUST report the DAV:collection and CALDAV:schedule-inbox XML elements in the value of the DAV::resourcetype property.
 * style="text-align:center"|
 * Scheduling Inbox collections MUST only contain calendar object resources that obey the restrictions specified in iTIP [I-D.ietf-calsify-2446bis]. Consequently, scheduling Inbox collections MUST NOT contain any types of collection resources.
 * style="text-align:center"|
 * A scheduling Inbox collection MUST NOT be a child (at any depth) of a calendar collection resource.
 * style="text-align:center"|
 * The Request-URI for a calendar-query or calendar-multiget report MUST be the URI of the scheduling Inbox collection or of a child resource within a scheduling Inbox collection to access the calendaring reports extensions defined in this RFC.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|

Organizer Scheduling Object Resources
5.2.1.1. & 5.2.1.2. 5.2.1.1. 5.2.1.1., 5.2.1.2. & 5.2.1.3. 5.2.1.1. & 5.2.1.2. 5.2.2.
 * style="text-align:center"|
 * 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
 * style="text-align:center"|
 * 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.
 * style="text-align:center"| NOT
 * The server MUST take into account scheduling privileges as described in Section 13.1 when handling the creation of a scheduling object resource.
 * style="text-align:center"|
 * Restrictions on calendar object resources defined in Section 4.1 of [RFC4791] MUST also be enforced.
 * style="text-align:center"|

Attendee Scheduling Object Resources
5.2.2.1.
 * style="text-align:center"|
 * 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. 5.2.2.2. 5.2.2.3. 5.2.2.3. 5.2.2.4. 5.2.2.4. 5.2.3.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"| NOT

Method Handling Changes
5.2.3.1. 5.2.3.2. 5.2.3.3. 5.2.3.4. 5.2.4.
 * style="text-align:center"|
 * PUT method handling changes
 * style="text-align:center"|
 * COPY method handling changes
 * style="text-align:center"|
 * MOVE method handling changes
 * style="text-align:center"|
 * DELETE method handling changes
 * style="text-align:center"|

Additional Method Preconditions
5.2.4.2. 5.2.5. 5.2.5. 5.2.6. 5.2.7. 6.
 * style="text-align:center"|
 * All the calendar components in a scheduling object resource MUST contain the same "ORGANIZER" property value when present.
 * style="text-align:center"|
 * 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).
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|

Processing Incoming Scheduling Messages
6. 6. 6. 6.1. 6.1. 6.1. 6.2. 6.2. 6.2. 6.3. 6.3. 6.3. 6.3. 6.3. 6.3.1. 7.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * Servers MUST take into account any scheduling Inbox collection preconditions (see Section 4.2) when delivering the scheduling message.
 * style="text-align:center"|
 * Servers MUST take into account the similar preconditions on any calendar collection which contains, or would contain, the corresponding scheduling object resource.
 * style="text-align:center"|
 * When processing an attendee reply the server MUST 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).
 * style="text-align:center"|
 * When processing an attendee reply the server MUST 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.
 * style="text-align:center"|
 * The scheduling message MUST only appear in the Organizer's scheduling Inbox collection once all automatic processing has been done.
 * style="text-align:center"|
 * When processing a new organizer message, the server MUST process the scheduling message and create a new scheduling object resource in an appropriate calendar collection for the Attendee.
 * style="text-align:center"|
 * When processing an updated organizer message, 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.
 * style="text-align:center"|
 * The scheduling message MUST only appear in the Attendee's scheduling Inbox collection once all automatic processing has been done.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * Servers MUST create new scheduling object resources in the default calendar collection, if the CALDAV:schedule-default-calendar-URL property is set.
 * style="text-align:center"|
 * Servers MUST ensure that any value stored for the CALDAV:schedule-default-calendar-URL property refers to a valid calendar collection belonging to the owner of the scheduling inbox collection.
 * style="text-align:center"|
 * Servers MUST reject any attempt to delete the default calendar collection.
 * style="text-align:center"|
 * Additional Method Preconditions
 * style="text-align:center"|

Request for Busy Time Information
7.3. 8.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|

Avoiding Conflicts
8. 8. 8. 8.
 * style="text-align:center"|
 * Servers MUST support 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * The value of the CALDAV:schedule-tag property changes according to these rules:
 * For an Organizer's copy of a scheduling object resource:
 * 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 automatically updated by the server with the Attendee's new participation status.
 * The server MUST change CALDAV:schedule-tag property value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY or MOVE).


 * For an Attendee's copy of a scheduling object resource:
 * 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.
 * 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.
 * 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.2, 8.3 & 8.4. 9.1. 9.3. 10.1. 10.1. 10.2. 10.2. 10.3. 10.3. 10.3. 11.1. 11.1. 11.1. 11.2. 11.3. 12.1. 12.2. 12.3. 12.3. 13.1. 13.1.3. 13.2.1. 13.2.2. 13.2.3 13.2.4 15.1.
 * style="text-align:center"|
 * Support the If-Schedule-Tag-Match request header to ensure that "inconsequential" changes on the server do not result in a precondition error.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * The SCHEDULE-AGENT iCalendar 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.
 * style="text-align:center"|
 * Servers MUST NOT include this parameter in any scheduling messages sent as the result of an automatic scheduling transaction.
 * style="text-align:center"|
 * Servers MUST NOT include the SCHEDULE-FORCE-SEND parameter in any scheduling messages sent as the result of an automatic scheduling transaction.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * Servers MUST add the "SCHEDULE-STATUS" property parameter to any "ATTENDEE" properties corresponding to Calendar Users who were sent a scheduling message via an automatic scheduling transaction.
 * style="text-align:center"|
 * Servers MUST add the "SCHEDULE-STATUS" property parameter to any "ORGANIZER" properties corresponding to Calendar Users who were sent a scheduling message reply by an Attendee via an automatic scheduling transaction.
 * style="text-align:center"|
 * Servers MUST NOT include the "SCHEDULE-STATUS" property parameter in any scheduling messages sent as the result of an automatic scheduling transaction.
 * style="text-align:center"|
 * When an Attendee removes 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"| NOT
 * All scheduling object resources MUST support the Schedule-Reply request header.
 * style="text-align:center"|
 * All scheduling object resources MUST support the Schedule-Tag header described in section 8.
 * style="text-align:center"|
 * All scheduling object resources MUST support the If-Schedule-Tag-Match header.
 * style="text-align:center"|
 * Support CALDAV:schedule-calendar-transp Property
 * style="text-align:center"|
 * Support CALDAV:schedule-default-calendar-URL Property
 * style="text-align:center"|
 * Support CALDAV:schedule-tag Property. The CALDAV:schedule-tag property MUST be defined on all scheduling object resources. This property is described in Section 8.
 * style="text-align:center"|
 * The CALDAV:schedule-tag Property MUST be protected.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * Support CALDAV:schedule-inbox-URL property
 * style="text-align:center"|
 * Support CALDAV:schedule-outbox-URL property
 * style="text-align:center"|
 * Support CALDAV:calendar-user-address-set property
 * style="text-align:center"|
 * Support CALDAV:calendar-user-type property
 * style="text-align:center"|

Verifying Scheduling Transactions
15.1. 15.1. 15.1. 15.1. 15.1. 15.2.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|

Verifying Busy Time Information Requests
15.2. 15.2. 15.2.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * 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.
 * style="text-align:center"|
 * }
 * }