<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-ietf-calext-caldav-scheduling-controls-00" updates="6638">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="CalDAV SchedControl">CalDAV Extension for scheduling controls</title>

<author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana">
<organization>FastMail</organization>
<address>
<postal>
<street>Level 2, 114 William St</street>
<city>Melbourne</city>
<code>VIC 3000</code>
<country>Australia</country>
<region></region>
</postal>
<phone></phone>
<email>brong@fastmailteam.com</email>
<uri>https://www.fastmail.com</uri>
</address>
</author>
<date year="2019" month="March" day="26"/>

<area>Applications</area>
<workgroup>calext</workgroup>
<keyword>CalDAV</keyword>
<keyword>Calendar</keyword>
<keyword>Scheduling</keyword>


<abstract>
<t>This document adds headers to control and restrict the scheduling
behaviour of CalDAV servers when updating calendaring resources.
</t>
</abstract>


</front>

<middle>

<section anchor="introduction" title="Introduction">
<t><xref target="RFC6638"/> defines automatic scheduling operations for resources stored
on [!@RFC4791] CalDAV servers.
</t>
<t><xref target="RFC6638"/> defines the <spanx style="verb">Schedule-Reply</spanx> header in Section 8.1,
however this header is not sufficient for controlling scheduling in all
cases.
</t>
<t>Cases where it might be necessary to update the data store on a server without
causing scheduling messages to be sent include backup after a data loss event
on the server, or importing calendar events from another system.
</t>
<t>Calendar server operators deal with these other needs by either using
a different method than CalDAV to update their server, or by adding a
custom method to suppress scheduling.  This document defines a standard
method to suppress scheduling, allowing CalDAV to be directly used for
restores and imports.
</t>
<t>Complex sites can have users who have multiple aliases, and in the most
complex cases, a user may have multiple identities who are present on a
scheduling event as organizer and/or attendee.  When an event is updated
over CalDAV, the server must calculate or guess which of those addresses
the current user is acting as.  This document defines a header which
allows the client to inform the server precisely which address they are
acting as when adding, modifying or removing a resource.
</t>
</section>

<section anchor="conventions-used-in-this-document" title="Conventions Used In This Document">
<t>In examples, &quot;C:&quot; indicates data sent by a client that is connected
to a server. &quot;S:&quot; indicates data sent by the server to the client.
</t>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;,
&quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as
described in <xref target="RFC2119"/> when they appear in ALL CAPS.  These words may
also appear in this document in lower case as plain English words,
absent their normative meanings.
</t>
</section>

<section anchor="extending-the-caldav-options-response" title="Extending the CalDAV OPTIONS response">
<t>A server supporting the features described in this document MUST
include &quot;scheduling-controls&quot; as a field in the DAV response header
from an OPTIONS request.  A value of &quot;scheduling-controls&quot; in the
DAV response header indicates to clients that the server supports all
the requirements specified in this document.
</t>

<section anchor="example-using-options-for-the-discovery-of-scheduling-controls-support" title="Example: Using OPTIONS for the Discovery of Scheduling Controls Support">
<t>Request:
</t>

<figure align="center"><artwork align="center">
OPTIONS /home/brong/calendars/ HTTP/1.1
Host: cal.example.com
</artwork></figure>
<t>Response:
</t>

<figure align="center"><artwork align="center">
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control, calendar-access,
 scheduling-controls
Date: Thu, 8 Feb 2019 10:16:37 GMT
Content-Length: 0
</artwork></figure>
</section>
</section>

<section anchor="new-headers" title="New headers">
<t>This document adds two new headers for use on PUT, PROPPATCH and DELETE:
</t>

<section anchor="scheduling-header" title="Scheduling header">
<t>Scheduling: {all|none|internal-only|external-only|X-...}
</t>
<t>Default: all
</t>
<t>Not providing this header, or providing the value of &quot;all&quot;, instructs the
server to follow the behaviour in <xref target="RFC6638"/> Section 3.2.
</t>
<t>Providing the value &quot;none&quot; instructs the server to perform no scheduling
at all, and to just store the event (useful for restoring from backup)
</t>
<t>The value &quot;internal-only&quot; instructs the server to update the events in
other calendars within its system where that can be done silently, but not
to send visible notifications to users (where permitted by policy).  This
is useful when importing multiple related calendars into a new system
without flooding external parties with notifications.
</t>
<t>The value &quot;external-only&quot; instructs the server to import the data without
updating local calendars, but to send notifications to external attendees
so they are aware of the event.  This is useful when migrating calendar
events to a new system where external parties need to have a way to update
their participation status in the new system.
</t>
<t>e.g.
</t>

<figure align="center"><artwork align="center">
Scheduling: none
</artwork></figure>
<t>TODO: specify error codes
</t>
</section>

<section anchor="scheduleuseraddress-header" title="Schedule-User-Address header">
<t>Schedule-User-Address: URI
</t>
<t>Default: not present
</t>
<t>If this header is not present, the server will calculate the address from
the authenticated user, or from the CALDAV:schedule-user-address property
on the calendar or principal.
</t>
<t>If this header is provided, it overrides the server's internal calculation,
and informs the server to perform any scheduling as the specified user.
</t>
<t>TODO: specify error codes
</t>
<t>e.g.
</t>

<figure align="center"><artwork align="center">
Schedule-User-Address: mailto:foo@example.com
</artwork></figure>
</section>
</section>

<section anchor="implementation-considerations" title="Implementation considerations">
<t>Any server implementing this extension MUST ensure it has a way to validate
Schedule-User-Address settings.
</t>
</section>

<section anchor="iana-considerations" title="IANA Considerations">
<t>TODO: IANA request for OPTIONS item
</t>
<t>TODO: IANA request for named headers
</t>
</section>

<section anchor="security-considerations" title="Security Considerations">
<t>The &quot;Scheduling&quot; header only allows reduction of the cases in which the
server will creating scheduling requests.  This is generally good for user
privacy, allowing copies of events to be updated without notifying the
owner or attendees.  This is particularly valuable for cleaning up spam.
</t>
<t>The &quot;Schedule-User-Address&quot; header allows the client to override the
server choice of address for the user to act as.  Servers MUST
ensure that the authenticated user has permission to act as the specified
address, as well as applying any local policy limitations.
</t>
</section>

<section anchor="acknowledgments" title="Acknowledgments">
<t>
<list style="symbols">
<t>Lucia Kristiansen, Google</t>
<t>CalConnect</t>
<t>The calext working group</t>
</list>
</t>
</section>

<section anchor="version-history" title="Version History">
<t>Remove before publishing
</t>

<section anchor="ietfcalextv00-20190326" title="ietf-calext-v00, 2019-03-26">
<t>
<list style="symbols">
<t>Adopt into calext working group based on no objections on the list</t>
</list>
</t>
</section>

<section anchor="gondwanav01-20190308" title="gondwana-v01, 2019-03-08">
<t>
<list style="symbols">
<t>correct name in acknowledgements</t>
</list>
</t>
</section>

<section anchor="gondwanav00-20190208" title="gondwana-v00, 2019-02-08">
<t>
<list style="symbols">
<t>Initial draft based on discussion at CalConnect about Google and FastMail private implementations.</t>
</list>
</t>
</section>
</section>

</middle>
<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6638.xml"?>
</references>

</back>
</rfc>
