Scheduling - notes on develoment

Essentially we are implementing iTip. The iTip rfc 2446 is here so that we can annotate it as we progress. We should delete sections as we complete them leaving the section headers until it's all gone.

CalDAV and scheduling

In common with all other development what we build has to be consistent with the calendaring world and in particular CalDAV.

For scheduling, this means supporitng the inbox and outbox in a way that is consistent with the CalDAV protocol as well as iTip.

A user receives scheduling requests through the inbox. iMip will place them there (unimplemented), CalDAV and the web interface call the svc layer schedule method which places them there.

Shecduling events have to remain in the inbox and outbox, at least until the meeting has taken place. The interactions that take place depend upon the current state of the originator and recipients and that is recorded in the event entry in the in/outbox. We need to take care when deleting in/outbox entries. We cannot altogether disallow it but users need to be aware that deleting an entry can have consequences later on.

Attendees/recipients organizer/originator

These are all different things. A CU (calendar user) can be an attendee but need not be a recipient. The organizer could just set the partstat to ACCEPTED. Somebody may be a recipient, but not an attendee, perhaps they just want to be aware a meeting is taking place - or they are acting on behalf of the attendee, for example as a secretary.

Similarly, the originator may not be the organizer. Maybe it's the secretary to the CIO organizing a meeting on the CIOs behalf.

The default state is to have attendees being the recipients but the system has to allow and accept otherwise.

Flow of events

This should look something like the following

Sending (PUBLISH/REQUEST)

  1. An event is built with schedule method set to publish or request.
  2. CalDAV POST method or web client calls svc schedule.
  3. For each internal recipient (not attendee) a copy is placed in the inbox
  4. The event is placed in the originators outbox. If there are any external recipients it is marked unprocessed, otherwise it is marked processed.
  5. At some later time (soon after) the unporcessed event is processed by an imip mailer which mails requests to the external recipients and marks the event as processed.

Upating, resending

As an organizer we may need to resend the request either because of changes or just to renotify users. From a CalDAV perspective we just rePOST the event - probably with RSVP=TRUE on all attendees. From the web client we display the event for modification, set all attendee rsvps true then call schedule.

This should result in us updating the attendee entries for each recipient which shoudl result in a notification to those recipients.

Replying

For an external user they will use iMip or CalDAV both of which should call svc schedule with the scheduling method set to REPLY (or COUNTER or REFRESH).

Section 2.1.5 - need to preserve last seen sequence per attendee.

Questions

  1. Currently removing all recipients when adding to inbox. Add current user back.
  2. Do we keep a history in the outbox?

Current status

Event

  1. PUBLISH works?
  2. Event REQUEST
    1. initial request OK
    2. reschedule OK
    3. update/reconfirm OK
    4. Delegating - untested
    5. Change organizer - unimplemented
    6. Send of behalf of Organizer - unimplemented/untested
    7. Forward to uninvited CU - untested
    8. Update attendee status - OK
  3. REPLY ok
  4. ADD - unimplemented
  5. CANCEL - OK
  6. REFRESH - OK
  7. COUNTER - OK
  8. DECLINECOUNTER - OK
  9. Accept COUNTER - OK