[caldeveloper-l] Proposed draft: Caldav-scheduling-controls

[Bron Gondwana]

# Scheduling-Enabled header

RFC6638 Section 8.1 defines the Schedule-Reply header to suppress server-
sent scheduling messages when removing a resource (e.g. when cleaning up
spam), however there are other situations in which a client may wish to
update the resource stored on a server without sending scheduling
resources, for example:
* Migrating an existing calendar from one server to another (e.g.
  changing providers)* Restoring a calendar from backup after data loss
* keeping a synchronised copy of another calendar for backup, caching or
  aggregation purposes
Setting schedule-agent to CLIENT is not a good solution, because other
clients will continue to leave the value set to CLIENT and then
scheduling won't work on that event.
So - I propose replacing and/or supplementing "Schedule-Reply: F" with
another header - "Scheduling-Enabled: F" which suppresses all scheduling
actions on the server, and stores the resource as-is.  This is an HTTP
header on the PUT action, and the resource can then be interacted with
normally by clients.
# Schedule-Address header

Email has the concept of aliases, however CalDAV does not.  When storing
or updating a resource, the server calculates which of the ORGANIZER or
ATTENDEE properties refers to the acting user by looking at the calendar-user-
address property on the calendar, or by the username of the
authenticated user.  This header provides a way for the client to tell
the server "this is the address I am acting as", overriding those hints.
====

With these two headers, it's possible to use CalDAV for all interactions
with the server, without needing a separate protocol for backup restore
or for injecting iMIP messages sent to aliases.  I assume I'd also need
a way to define in some server info on the server that these headers
were supported - so I'd love suggestions there.
I'm happy to write this up as an IETF draft and bring it to calext,
particularly if there's general support of the idea.  I'm happy to
consider new names for the headers as well - it's pretty easy to change
on our server and client code at FastMail.  Both these headers are
implemented and in production on our systems.
====

Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong at fastmailteam.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180606/57bd78e4/attachment.html>