<!DOCTYPE html>
<html>
<head>
<title></title>
<style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
</head>
<body><div style="font-family:Arial;"># Scheduling-Enabled header<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">* Migrating an existing calendar from one server to another (e.g. changing providers)<br></div>
<div style="font-family:Arial;">* Restoring a calendar from backup after data loss<br></div>
<div style="font-family:Arial;">* keeping a synchronised copy of another calendar for backup, caching or aggregation purposes<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;"># Schedule-Address header<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">====<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">====<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Cheers,<br></div>
<div style="font-family:Arial;"><br>Bron.<br></div>
<div style="font-family:Arial;"><br></div>
<div id="sig56629417"><div class="signature">--<br></div>
<div class="signature"> Bron Gondwana, CEO, FastMail Pty Ltd<br></div>
<div class="signature"> brong@fastmailteam.com<br></div>
<div class="signature"><br></div>
</div>
<div style="font-family:Arial;"><br></div>
</body>
</html>