454180 - Support for SCHEDULE-STATUS attribute wrt. server-based auto-scheduling

Status: NEW

(Calendar :: Provider: CalDAV, enhancement)

Description

[Daniel Boelzle [:dbo]]

Quoting a recent mail from Bernard:

"A CalDAV server that advertise the "calendar-auto-schedule" feature in the DAV response header will take care of sending scheduling  messages (e.g., REQUEST, ADD, CANCEL) and processing incoming scheduling messages (e.g., REPLY). The simple operation of creating, modifying or deleting a calendar object resource in a calendar is enough to trigger the CalDAV server to deliver appropriate scheduling messages to other calendar users.

Ideally a CalDAV client shouldn't have to care if the Organizer or Attendees are hosted on the same CalDAV server as you or not. In the case of calendar users hosted on a different system than you, the CalDAV server should take care of delivering the appropriate scheduling messages to their respective system using the Internet Scheduling Protocol (iSchedule) or any other protocol (proprietary or not).

If the CalDAV server is unable to deliver a scheduling message to the Organizer or Attendees it must let the CalDAV client know by setting the new SCHEDULE-STATUS parameter on the respective ORGANIZER or ATTENDEE property in the calendar object resource contained in the calendar collection of the user. Then, it becomes the CalDAV client's responsibility to decide if it should itself send a scheduling message (e.g., with iMIP) to the Organizer or Attendee."

Comment 1

[Daniel Boelzle [:dbo]]

Attachment: [checked in] proposed patch - leaving out SCHEDULE-STATUS handling

This patch checks for calendar-auto-scheduling and disables client-side iTIP/iMIP if it is set.

Comment 2

[Bernard Desruisseaux]

(In reply to comment #1)
> This patch checks for calendar-auto-scheduling and disables client-side
> iTIP/iMIP if it is set.

Thanks a lot! I've tested this patch successfully against a development build of the CalDAV server of an upcoming release of Oracle Beehive.

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 337418 [details] [diff] [review]
[checked in] proposed patch - leaving out SCHEDULE-STATUS handling

Looks good, r=philipp

Extra points for non-anonymous getters/setters.

Comment 4

[Daniel Boelzle [:dbo]]

Comment on attachment 337418 [details] [diff] [review]
[checked in] proposed patch - leaving out SCHEDULE-STATUS handling

Checked in on HEAD, MOZILLA_1_8_BRANCH and SUNBIRD_0_9_BRANCH.

Comment 5

[Daniel Boelzle [:dbo]]

Leaving bug open to implement the SCHEDULE-STATUS handling.

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to comment #0)
> If the CalDAV server is unable to deliver a scheduling message to the Organizer
> or Attendees it must let the CalDAV client know by setting the new
> SCHEDULE-STATUS parameter on the respective ORGANIZER or ATTENDEE property in
> the calendar object resource contained in the calendar collection of the user.
> Then, it becomes the CalDAV client's responsibility to decide if it should
> itself send a scheduling message (e.g., with iMIP) to the Organizer or
> Attendee.

Does this mean that the server has totally given up trying, or that it will try again. Of course we need to avoid double invitations :-) Also, can this Prop be dropped? If not, I don't think we roundtrip X-Attrs on attendees in the storage provider currently?

Comment 7

[Bernard Desruisseaux]

(In reply to comment #6)
> Does this mean that the server has totally given up trying, or that it will
> try again.

The status-code value specified in SCHEDULE-STATUS will tell you.
Have a look at the possible classes of status codes:
http://tools.ietf.org/html/rfc2445#page-135

The client should only worry when it sees a 3.xx or 4.xx status codes.
BTW, CalDAV scheduling will most likely define new 1.xx status codes.

> Of course we need to avoid double invitations :-) Also, can this Prop be
> dropped? If not, I don't think we roundtrip X-Attrs on attendees in the
> storage provider currently?

This parameter could be dropped for ATTENDEE without the SCHEDULE-AGENT parameter or with SCHEDULE-AGENT=SERVER (the default) since the SCHEDULE-STATUS value is managed by the server. But this parameter should be kept for ATTENDEE with SCHEDULE-AGENT=NONE (attendees not scheduled) or SCHEDULE-AGENT=CLIENT (attendees scheduled by client (e.g., with iMIP)) since the SCHEDULE-STATUS value is managed by the client.

The upcoming draft-05 should make this clear.

Comment 8

[Bernard Desruisseaux]

(In reply to comment #1)
> This patch checks for calendar-auto-scheduling and disables client-side
> iTIP/iMIP if it is set.

This patch does not only disable the sending of REQUEST/ADD and REPLY iMIP messages, it also disables the ability to import incoming iMIP requests in a calendar hosted on a CalDAV server that provides support for the calendar-auto-schedule feature. Such calendars are not proposed in the list of calendars in which the meeting invitation should be imported.

This bug should probably be renamed to:

  Properly support CalDAV calendar-auto-schedule with iMIP

Check "SCHEDULE-AGENT=CLIENT" in draft -05:
http://ietfreport.isoc.org/idref/draft-desruisseaux-caldav-sched/