Difference between revisions of "RFC Compliance/CalDAV Scheduling"

From Davical
Jump to navigationJump to search
(New page: Indications of progress on the path to compliance with the {{CalDAV Scheduling RFC}} == Overview == == Details of Unsupported Features == {{Tlist}} {{TRlist}}Section {{THlist}}Feature {...)
 
Line 47: Line 47:
 
|{{Todo}}
 
|{{Todo}}
 
{{TRlist}}5.2.1.
 
{{TRlist}}5.2.1.
|Organizer Scheduling Object Resources
+
|
 +
=== Organizer Scheduling Object Resources ===
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
Line 67: Line 68:
 
|{{Todo}}
 
|{{Todo}}
 
{{TRlist}}5.2.2.
 
{{TRlist}}5.2.2.
|Attendee Scheduling Object Resources
+
|
 +
=== Attendee Scheduling Object Resources ===
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
Line 104: Line 106:
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
{{TRlist}}.
+
{{TRlist}}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.
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
{{TRlist}}.
+
{{TRlist}}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.
|style="text-align:center"|{{MUST}}
+
|style="text-align:center"|{{MUST}} '''''NOT'''''
 
|{{Todo}}
 
|{{Todo}}
{{TRlist}}.
+
{{TRlist}}5.2.3.1.
|
+
|PUT method handling changes
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
{{TRlist}}.
+
{{TRlist}}5.2.3.2.
|
+
|COPY method handling changes
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
|{{Todo}}
+
|{{Todo|COPY not yet implemented}}
{{TRlist}}.
+
{{TRlist}}5.2.3.3.
|
+
|MOVE method handling changes
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
{{TRlist}}.
+
{{TRlist}}5.2.3.4.
|
+
|DELETE method handling changes
 
|style="text-align:center"|{{MUST}}
 
|style="text-align:center"|{{MUST}}
 
|{{Todo}}
 
|{{Todo}}
Line 139: Line 141:
  
 
== Notes ==
 
== 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.

Revision as of 23:36, 14 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.1. PUT method handling changes MUST :  |}})
5.2.3.2. COPY method handling changes MUST :  |}}COPY not yet implemented)
5.2.3.3. MOVE method handling changes MUST :  |}})
5.2.3.4. DELETE method handling changes 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.