1.  Scope

This document defines a new iCalendar IETF RFC 5545 component that allows small “patches” to be applied to large iCalendar data objects, to allow for efficient data updates. It also describes how this new component can be used with the CalDAV calendar data access protocol IETF RFC 4791.

2.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

IETF RFC 4791, C. DABOO, B. DESRUISSEAUX and L. DUSSEAULT. Calendaring Extensions to WebDAV (CalDAV). 2007. RFC Publisher. https://www.rfc-editor.org/info/rfc4791.

IETF RFC 5234, P. OVERELL. Augmented BNF for Syntax Specifications: ABNF. 2008. RFC Publisher. https://www.rfc-editor.org/info/rfc5234.

IETF RFC 5545, B. DESRUISSEAUX (ed.). Internet Calendaring and Scheduling Core Object Specification (iCalendar). 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5545.

IETF RFC 5546, C. DABOO (ed.). iCalendar Transport-Independent Interoperability Protocol (iTIP). 2009. RFC Publisher. https://www.rfc-editor.org/info/rfc5546.

IETF RFC 7953, C. DABOO and M. DOUGLASS. Calendar Availability. 2016. RFC Publisher. https://www.rfc-editor.org/info/rfc7953.

3.  Overview

The basic design of the patch format is a “VPATCH” component (defined in Section 10.1) containing one or more “PATCH” components (defined in Section 10.1.1), each specifying a path (which identifies one or more components in the iCalendar object being patched), and other components and properties that define the set of changes to be made.

When multiple “VPATCH” components are present in an iCalendar object, the order in which they are applied is defined by the value of any “PATCH-ORDER” properties in the “VPATCH” components. The “VPATCH” components are sorted in order from lowest “PATCH-ORDER” integer value to highest, with any components not containing a “PATCH-ORDER” property placed last. The patch process is then applied in sorted order (any components with the same “PATCH-ORDER” value can be applied in any order).

No specific processing order is defined for multiple “PATCH” components in a “VPATCH” component.

The “VPATCH” component also contains an optional “PATCH-VERSION” property to allow future extensions to the format to be recognized. This document only defines version number “1”. The “PATCH-VERSION” property only needs to be present if the version number is greater than “1”. If a patch processing engine is unable to handle the indicated version it MUST reject the entire patch operation defined by the enclosing iCalendar object, even if other “VPATCH” components have a “PATCH-VERSION” number that is supported.

After applying a patch to an iCalendar object, the basic validity of the resulting iCalendar object SHOULD be checked by the processing engine (e.g., if the patch added an extra “DTSTART” property to a “VEVENT” component that would be considered a violation of IETF RFC 5545‘s cardinality rules for the “DTSTART” property in a “VEVENT”). If this occurs, the patch operation MUST fail.

Other validity constraints can be applied if needed. For example, CalDAV IETF RFC 4791 requires that the “UID” property be the same in all components in a calendar object resource stored on the server. If a patch operation adds a component to an iCalendar object with a different “UID” value than the existing components, that result would be an invalid CalDAV calendar object resource. If other validity constraints are violated, the patch operation MUST fail.

Any failure to process a “VPATCH” component, for whatever reason, MUST result in the entire patch operation being cancelled, with the iCalendar object being patched left in its original state.

4.  PATCH Component

A “PATCH” component (defined in Section 10.1.1) MUST contain one “PATCH-TARGET” property whose value is an iCalendar path (see Section 5) that identifies components within the iCalendar object being patched (see Section 11.2 for special handling of components representing recurring items). The set of components thus identified are the “target components” for the patch operations. The set of patch operations defined by the other components and properties present in the “PATCH” component are then applied to each target component (in the order specified below). If a “PATCH-TARGET” property does not match any components in the iCalendar object being patched, then the patch operation MUST succeed without any changes being applied to the iCalendar object being patched.

Four patch operations are supported:

When processing a “PATCH” component, the processing engine MUST follow this order:

5.  iCalendar Path

The “PATCH-TARGET”, “PATCH-DELETE”, and “PATCH-PARAMETER” property values are all iCalendar “paths”. The path is used to match iCalendar elements that the patch operation will be applied to. The path is a list of “segments” (separated by the “/”, “#”, “;” or “=” characters) that matches an iCalendar element in the iCalendar object model hierarchy (a component, a property, a property parameter, a property value, or a property parameter value). A path can either be “absolute” (referring to items within the top-level iCalendar object being patched) or “relative” (referring to items within some other component as determined by the scope of the operation).

A path can start with a series of component segments (which always have a “/” prefix). Those can be followed by a property segment (which always has a “#” prefix”). A property segment can be followed by either a parameter segment (which always has a “;” prefix), or a value segment (which always has a “=” prefix). A parameter segment can be followed by a value segment (which always has a “=” prefix).

An absolute path always starts with a “/VCALENDAR” component segment since an iCalendar object is always a single “VCALENDAR” component.

A relative path can start with a component segment or a property segment, with the path assumed to be relative to an enclosing component defined by the context.

To target a component inside of another component, a component segment is appended to the path. Component segments can include an optional match item. When present, this allows targeting of components that match a specific “UID” property value, and/or a “RECURRENCE-ID” value (or lack of “RECURRENCE-ID” property to target a “master” recurrence component). See Section 11.2 for special handling of components representing recurring items.

To target a property inside of a component, a property segment is added to the path. A property segment can include an optional match item. When present, this allows targeting of properties by value (matching or not matching a specific value), or which have a named property parameter present, or by property parameter value (matching or not matching a specific value).

To target a property parameter, a parameter segment is added to the property segment at the end of the path.

To target a single value in a multi-valued property, a value segment is added to the property segment at the end of the path.

To target a single value in a multi-valued property parameter, a value segment is added to the parameter segment at the end of the path.

Values in match items MUST use URL-style percent (%) encoding of the characters “/”, “#”, “;”, “=”, and “]”. This allows a path to be quickly split into segments by breaking apart the text on the relevant delimiter characters.

The syntax for a path is defined by the following notation (note that some of the syntax elements defined here are not used by this specification, however, it is anticipated that this general path syntax will be useful for other specifications):

abs-path         = abs-comp-path [prop-all-path]
       ; Absolute path for any iCalendar element

rel-full-path    = (comp-path [prop-all-path]) / prop-all-path
       ; Relative path for any iCalendar element at any depth
       ; within the enclosing component

rel-one-path     = comp-path / prop-all-path
       ; Relative path for any iCalendar element immediately
       ; within the enclosing component

abs-comp-path    = "/VCALENDAR" *comp-segment
       ; Absolute path for components only

comp-path        = 1*comp-segment
       ; Path for components only

prop-path        = prop-segment
       ; Relative path for properties only

prop-param-path  = prop-segment [param-segment]
       ; Relative path for property and parameter only

prop-all-path    = prop-segment [param-segment] [value-segment]
       ; Relative path for any element of a property

comp-segment     = "/" name comp-match
comp-match       = [uid-match] [rid-match]
uid-match        = "[UID=" value-escaped "]"
rid-match        = "[RID=" ("M" / ridval) "]"
       ; "M" matches "master" component

prop-segment     = prop-prefix [prop-match]
prop-prefix      = "#" name
prop-match       = "[" ( prop-equal / prop-not-equal /
                        param-match ) "]"

prop-equal       = "=" value-escaped
prop-not-equal   = "!" value-escaped

param-match      = "@" param-name [ ( param-equal /
                                     param-not-equal ) ]
param-equal      = "=" param-value-escaped
param-not-equal  = "!" param-value-escaped

param-segment    = ";" param-name

value-segment    = "=" (value / param-value)

value-escaped       = value
                   ; % encoding for "/", "#", ";", and "]"

param-value-escaped = param-value
                   ; % encoding for "/", "#", ";", and "]"

Some examples of “path” items follow.

Targeting components (path contains exactly one or more component segments):

Targeting properties (path contains exactly zero or more component segments, and one property segment):

Targeting property parameters (path contains exactly zero or more component segments, one property segment, and one parameter segment):

Targeting property values (path contains exactly zero or more component segments, one property segment, and one value segment):

Targeting property parameter values (path contains exactly zero or more component segments, one property segment, one parameter segment, and one value segment):

6.  Adding or Updating Components

Any iCalendar component defined in the “PATCH” component (referred to below as the “action component”) is treated as either an addition to the target component, or as an update of an existing component in the target component. The following rules are used to process such components:

7.  Adding or Updating Properties

Any iCalendar property defined in the “PATCH” component (referred to below as the “action property”) is treated as either an addition to the target component, or as an update of an existing property in the target component. A “PATCH-ACTION” (Section 10.4) property parameter can be defined on action properties and is used to control how the action is processed. Any “PATCH-ACTION” property parameter MUST be removed from the action property when it is added to the target component. The following rules are used to process such properties:

The “PATCH-ACTION=BYNAME” operation is used for adding or updating “singleton” properties — properties that only appear once in a given iCalendar component (e.g., “DTSTART”, “DTEND”, “LOCATION”, etc).

The “PATCH-ACTION=CREATE” operation is used for adding “multi- occurring” properties — properties that can appear more than once in a given iCalendar component (e.g., “ATTENDEE”, “ATTACH”, “EXDATE”, etc).

The “PATCH-ACTION=BYVALUE” operation is used for updating a specific “multi-occurring” property that can be uniquely identified by its value (e.g., the “ATTENDEE” property can appear multiple times in a “VEVENT” component, but each property will have a unique value in that component). This operation cannot be used when the value of the property is being changed. Instead, the “PATCH-ACTION=BYPARAM” operation can be used to identify the target property.

The “PATCH-ACTION=BYPARAM” operation is used for updating a specific “multi-occurring” property that can be uniquely identified by a parameter value that is the same in the action and target properties.

There may be some situations where a multi-occurring property cannot be uniquely identified. In such cases, the solution to updating one or more of them is to use a “PATCH-ACTION=BYNAME” to replace all the existing properties with one new one, then use “PATCH-ACTION=CREATE” to add back others that are unchanged or also being updated. Whilst this is not ideal, it is anticipated that these situations can be avoided by adding appropriate property parameters with unique values to help disambiguate the multi-occurring properties.

8.  Deleting Components, Properties, or Property Parameters

The “PATCH-DELETE” property (defined in Section 10.3.2) is used to indicate deletion of iCalendar elements from the component identified by the “PATCH-TARGET” property in the same “PATCH” component as the “PATCH-DELETE” property. As such, the value of the “PATCH-DELETE” property is always a relative path (see Section 5) that refers to an element that is an immediate “child” of the target component.

The following operations are supported:

9.  Adding or Updating Property Parameters

The “PATCH-PARAMETER” property (defined in Section 10.3.3) is used to indicate addition or update of property parameters and property parameter values to properties contained in the components identified by the “PATCH-TARGET” property in the same “PATCH” component as the “PATCH-PARAMETER” property. As such, the value of the “PATCH- PARAMETER” property is always a relative path (see Section 5) that refers to a property that is an immediate “child” of the target component.

The following operations are supported:

10.  iCalendar Extensions

This specification adds a new “VPATCH” calendar component to iCalendar. The “VPATCH” component is itself a container for a new “PATCH” sub-component.

11.  VPATCH Component

12.  VPATCH Properties

The “VPATCH” properties are attributes that apply to the “VPATCH” component, as a whole. These properties do not appear within “VPATCH” sub-components. They SHOULD be specified after the “BEGIN:VPATCH” delimiter string and prior to any sub-component.

PATCH-VERSION:1

PATCH-ORDER:1

13.  PATCH Component Properties

The following properties can appear within PATCH components.

PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]

PATCH-PARAMETER;PARTSTAT=NEEDS-ACTION:
 #ATTENDEE[=mailto:cyrus@example.com]
PATCH-PARAMETER;PARTSTAT=NEEDS-ACTION:#ATTENDEE<&#xa0;<CN=Cyrus Daboo>>
PATCH-PARAMETER;MEMBER=mailto:newgroup@example.com:#ATTENDEE;MEMBER

ATTENDEE;PATCH-ACTION=BYVALUE;PARTSTAT=NEEDS-ACTION:
mailto:cyrus@example.com
DESCRIPTION;PATCH-ACTION="BYPARAM@LANGUAGE=en_GB";LANGUAGE=en_US:
Meeting to discuss VPATCH

14.  Additional Considerations

BEGIN:VCALENDAR
PRODID:test
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160902T120000Z
DURATION:PT1H
SUMMARY:Master component
RRULE:FREQ=DAILY
END:VEVENT
END:VCALENDAR

BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234][RID=20160903T120000Z]
SUMMARY:Override second instance
END:PATCH
END:VPATCH

BEGIN:VCALENDAR
PRODID:test
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160902T120000Z
DURATION:PT1H
SUMMARY:Master component
RRULE:FREQ=DAILY
END:VEVENT
BEGIN:VEVENT
UID:1234
RECURRENCE-ID=20160903T120000Z
DTSTART:20160903T120000Z
DURATION:PT1H
SUMMARY:Override second instance
END:VEVENT
END:VCALENDAR

BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR
PATCH-DELETE:/VEVENT[UID=1234][RID=20160903T120000Z]
END:PATCH
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234][RID=M]
EXDATE;PATCH-ACTION=CREATE:20160903T120000Z
END:PATCH
END:VPATCH

BEGIN:VCALENDAR
PRODID:test
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160902T120000Z
DURATION:PT1H
SUMMARY:Master component
RRULE:FREQ=DAILY
EXDATE:20160903T120000Z
END:VEVENT
END:VCALENDAR

DESCRIPTION:Line one\nLine two

PATCH-DELETE:#DESCRIPTION[=Line one\nLine two]

BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT
DESCRIPTION:Line one\nLine two\nLine three
END:PATCH
END:VPATCH

15.  Use with iTIP

iTIP IETF RFC 5546 defines how iCalendar data can be sent between calendar user agents to schedule calendar components between calendar users. This specification does not define how iCalendar patch documents can be used with iTIP.

16.  Use with CalDAV and HTTP

The CalDAV IETF RFC 4791 calendar access protocol allows clients and servers to exchange iCalendar data. iCalendar data is typically stored in calendar object resources on a CalDAV server. A CalDAV client typically updates the calendar object resource data via an HTTP PUT request, which requires sending the entire iCalendar object in the HTTP request body.

A server can also support the HTTP PATCH method IETF RFC 5789 which allows a patch document to be specified in the request body, and for that patch document to be applied to the resource targeted by the HTTP request. In this case, the server would advertise the “text/ calendar” media type in an “Accept-Patch” header field as described in Section 3.1 of IETF RFC 5789. Note that the requirements for parameters on this media type when advertised in “Accept-Patch” are as follows:

Accept-Patch: text/calendar; component=VPATCH;
optinfo="PATCH-VERSION:1"; charset=utf-8

The PATCH-TARGET property defined by this specification does not allow targeting the entire iCalendar object, and hence an HTTP PATCH request cannot be used to create a new resource (a normal HTTP PUT request is used instead).

17.  Security Considerations

Patch processing engines MUST ensure that the result of applying a patch is a valid iCalendar object in the context of the application using the calendar data. At the very least, the resulting iCalendar object MUST comply with the requirements of IETF RFC 5545.

Security considerations described in IETF RFC 5545, IETF RFC 5789, and IETF RFC 4791 MUST be adhered to.

18.  Privacy considerations

Privacy considerations described in IETF RFC 5545, IETF RFC 5789, and IETF RFC 4791 MUST be adhered to.

19.  IANA Considerations

20.  VPATCH Examples

Examples of single command patch documents for common iCalendar data operations.

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR
BEGIN:VEVENT
UID:1234
DTSTART:20160902T103000Z
DURATION:PT1H
SUMMARY:Test event
END:VEVENT
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
BEGIN:VALARM
UID:4567
ACTION:DISPLAY
TRIGGER:-PT30M
DESCRIPTION:Time to leave
END:VALARM
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
BEGIN:VEVENT
UID:1234
DTSTART:20160903T123000Z
DURATION:PT2H
SUMMARY:Changed event
END:VEVENT
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR
PATCH-DELETE:/VEVENT[UID=1234]
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VTODO[UID=4321]
STATUS;PATCH-ACTION=CREATE:COMPLETED
COMPLETED;PATCH-ACTION=CREATE:20160902T224515Z
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
SUMMARY:Title was changed
LOCATION:New place
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
ATTENDEE;PATCH-ACTION=BYVALUE;PARTSTAT=ACCEPTED:
mailto:cyrus@example.com
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
PATCH-DELETE:#URL
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
PATCH-DELETE:#ATTENDEE[=mailto:cyrus@example.com]
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
PATCH-PARAMETER;PARTSTAT=ACCEPTED:
=ATTENDEE[=mailto:cyrus@example.com]
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
PATCH-DELETE:#ATTENDEE[=mailto:cyrus@example.com];PARTSTAT
END:PATCH
END:VPATCH
END:VCALENDAR

21.  Remove a value from a multi-valued parameter on a property with a specific value from a component

Remove the “mailto:calext@example.com” value from the “MEMBER” parameter on the “ATTENDEE” property with the value “mailto:cyrus@example.com” in the “VEVENT” component with the “UID” property value “1234”.

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
PATCH-DELETE:#ATTENDEE[=mailto:cyrus@example.com]
;MEMBER=mailto:calext@example.com
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[UID=1234]
PATCH-DELETE:#EXDATE=20160903T120000Z
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT
PATCH-DELETE:#ATTENDEE[=mailto:cyrus@example.com];RSVP
PATCH-PARAMETER;PARTSTAT=ACCEPTED:
=ATTENDEE[=mailto:cyrus@example.com]
TRANSP:OPAQUE
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160905
DURATION:PT1H
SUMMARY:Test event
RRULE:FREQ=DAILY
END:VEVENT
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[RID=20160906]
SUMMARY:Test event - modified
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160905
DURATION:PT1H
SUMMARY:Test event
RRULE:FREQ=DAILY
END:VEVENT
BEGIN:VEVENT
UID:1234
RECURRENCE-ID:20160906
DTSTART:20160905
DURATION:PT1H
SUMMARY:Test event - modified
END:VEVENT
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160905
DURATION:PT1H
SUMMARY:Test event
RRULE:FREQ=DAILY
END:VEVENT
BEGIN:VEVENT
UID:1234
RECURRENCE-ID:20160906
DTSTART:20160905
DURATION:PT1H
SUMMARY:Test event - modified
END:VEVENT
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VPATCH
UID:abcd
DTSTAMP:20160901T000000Z
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR
PATCH-DELETE:/VEVENT[RID=20160906]
END:PATCH
BEGIN:PATCH
PATCH-TARGET:/VCALENDAR/VEVENT[RID=M]
EXDATE;PATCH-ACTION=CREATE:20160906
END:PATCH
END:VPATCH
END:VCALENDAR

BEGIN:VCALENDAR
PRODID:Example
VERSION:2.0
BEGIN:VEVENT
UID:1234
DTSTART:20160905
DURATION:PT1H
SUMMARY:Test event
RRULE:FREQ=DAILY
EXDATE:20160906
END:VEVENT
END:VCALENDAR

22.  Acknowledgements

Thanks to the following for feedback: Michael Douglass

This specification originated from work at the Calendaring and Scheduling Consortium CalConnect, which has helped with the development and testing of implementations.

Bibliography

[1]  IETF RFC 2119, S. BRADNER. Key words for use in RFCs to Indicate Requirement Levels. 1997. RFC Publisher. https://www.rfc-editor.org/info/rfc2119.

[2]  IETF RFC 5789, L. DUSSEAULT and J. SNELL. PATCH Method for HTTP. 2010. RFC Publisher. https://www.rfc-editor.org/info/rfc5789.

[3]  CalConnect, The Calendaring and Scheduling Consortium