Difference between revisions of "RFC Compliance/CalDAV Scheduling"

From Davical
Jump to navigationJump to search
Line 113: Line 113:
 
|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.
 
|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"|{{MUST}} '''''NOT'''''
 
|style="text-align:center"|{{MUST}} '''''NOT'''''
 +
|{{Todo}}
 +
{{TRlist}}5.2.3.
 +
|
 +
=== Method Handling Changes ===
 +
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
 
{{TRlist}}5.2.3.1.
 
{{TRlist}}5.2.3.1.
Line 121: Line 126:
 
|COPY method handling changes
 
|COPY method handling changes
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
|{{Todo|COPY not yet implemented}}
+
|{{Todo|COPY unsupported}}
 
{{TRlist}}5.2.3.3.
 
{{TRlist}}5.2.3.3.
 
|MOVE method handling changes
 
|MOVE method handling changes
Line 128: Line 133:
 
{{TRlist}}5.2.3.4.
 
{{TRlist}}5.2.3.4.
 
|DELETE method handling changes
 
|DELETE method handling changes
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}5.2.4.
 +
|
 +
=== Additional Method Preconditions ===
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}5.2.4.2.
 +
|All the calendar components in a scheduling object resource MUST contain the same "ORGANIZER" property value when present.
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}5.2.5.
 +
|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"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}5.2.5.
 +
|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"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}5.2.6.
 +
|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"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}5.2.7.
 +
|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"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}6.
 +
|
 +
=== Processing Incoming Scheduling Messages ===
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}6.
 +
|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"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}6.
 +
|Servers MUST take into account any scheduling Inbox collection preconditions (see Section 4.2) when delivering the scheduling message.
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}6.
 +
|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"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}.
 +
|
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}.
 +
|
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}.
 +
|
 +
|style="text-align:center"|{{MUST}}
 +
|{{Todo}}
 +
{{TRlist}}.
 +
|
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}

Revision as of 00:49, 15 November 2009

Indications of progress on the path to compliance with the CalDAV Scheduling Extensions to WebDAV (RFC6638)

Overview

Details of Unsupported Features

Section Feature Requirement Status as at 0.9.8
3. 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. MUST :  |}})
4.1. A scheduling Outbox collection MUST report the DAV:collection and CALDAV:schedule-outbox XML elements in the value of the DAV::resourcetype property. MUST :  |}}0.9.7!)
4.1. A scheduling Outbox collection MUST NOT be a child (at any depth) of a calendar collection resource. MUST :  |}}0.9.7!)
4.2. A scheduling Inbox collection MUST report the DAV:collection and CALDAV:schedule-inbox XML elements in the value of the DAV::resourcetype property. MUST :  |}}0.9.7!)
4.2. 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. MUST :  |}})
4.2. A scheduling Inbox collection MUST NOT be a child (at any depth) of a calendar collection resource. MUST :  |}}0.9.7!)
4.3. 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. MUST :  |}})
4.3. 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. MUST :  |}})
4.3. 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. MUST :  |}})
5.2.1.

Organizer Scheduling Object Resources

MUST :  |}})
5.2.1.1. & 5.2.1.2. 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 MUST :  |}})
5.2.1.1. 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. MUST NOT :  |}})
5.2.1.1., 5.2.1.2. & 5.2.1.3. The server MUST take into account scheduling privileges as described in Section 13.1 when handling the creation of a scheduling object resource. MUST :  |}})
5.2.1.1. & 5.2.1.2. Restrictions on calendar object resources defined in Section 4.1 of [RFC4791] MUST also be enforced. MUST :  |}})
5.2.2.

Attendee Scheduling Object Resources

MUST :  |}})
5.2.2.1. 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.

MUST :  |}})
5.2.2.2. 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. MUST :  |}})
5.2.2.3. 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. MUST :  |}})
5.2.2.3. 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. MUST :  |}})
5.2.2.4. 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. MUST :  |}})
5.2.2.4. 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. MUST NOT :  |}})
5.2.3.

Method Handling Changes

MUST :  |}})
5.2.3.1. PUT method handling changes MUST :  |}})
5.2.3.2. COPY method handling changes MUST :  |}}COPY unsupported)
5.2.3.3. MOVE method handling changes MUST :  |}})
5.2.3.4. DELETE method handling changes MUST :  |}})
5.2.4.

Additional Method Preconditions

MUST :  |}})
5.2.4.2. All the calendar components in a scheduling object resource MUST contain the same "ORGANIZER" property value when present. MUST :  |}})
5.2.5. 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). MUST :  |}})
5.2.5. 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. MUST :  |}})
5.2.6. 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. MUST :  |}})
5.2.7. 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. MUST :  |}})
6.

Processing Incoming Scheduling Messages

MUST :  |}})
6. 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. MUST :  |}})
6. Servers MUST take into account any scheduling Inbox collection preconditions (see Section 4.2) when delivering the scheduling message. MUST :  |}})
6. Servers MUST take into account the similar preconditions on any calendar collection which contains, or would contain, the corresponding scheduling object resource. MUST :  |}})
. MUST :  |}})
. MUST :  |}})
. MUST :  |}})
. MUST :  |}})
. MUST :  |}})
. MUST :  |}})

Notes

According to 5.2.3.4 DELETE on a scheduling collection must remove all resources from that collection. The collection itself will not be deleted - it is protected - but this is not explicitly stated.