draft-ietf-jmap-calendars-05.txt   draft-ietf-jmap-calendars-06.txt 
JMAP N.M. Jenkins, Ed. JMAP N.M. Jenkins, Ed.
Internet-Draft Fastmail Internet-Draft Fastmail
Intended status: Standards Track M. Douglass, Ed. Intended status: Standards Track M. Douglass, Ed.
Expires: 29 July 2021 Spherical Cow Group Expires: 28 January 2022 Spherical Cow Group
25 January 2021 27 July 2021
JMAP for Calendars JMAP for Calendars
draft-ietf-jmap-calendars-05 draft-ietf-jmap-calendars-06
Abstract Abstract
This document specifies a data model for synchronizing calendar data This document specifies a data model for synchronizing calendar data
with a server using JMAP. with a server using JMAP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 July 2021. This Internet-Draft will expire on 28 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5. Calendar Events . . . . . . . . . . . . . . . . . . . . . . . 17 5. Calendar Events . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Additional JSCalendar properties . . . . . . . . . . . . 19 5.1. Additional JSCalendar properties . . . . . . . . . . . . 19
5.1.1. mayInviteSelf . . . . . . . . . . . . . . . . . . . . 19 5.1.1. mayInviteSelf . . . . . . . . . . . . . . . . . . . . 19
5.1.2. mayInviteOthers . . . . . . . . . . . . . . . . . . . 19 5.1.2. mayInviteOthers . . . . . . . . . . . . . . . . . . . 19
5.1.3. hideAttendees . . . . . . . . . . . . . . . . . . . . 19 5.1.3. hideAttendees . . . . . . . . . . . . . . . . . . . . 19
5.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Per-user properties . . . . . . . . . . . . . . . . . . . 19 5.3. Per-user properties . . . . . . . . . . . . . . . . . . . 19
5.4. Recurring events . . . . . . . . . . . . . . . . . . . . 20 5.4. Recurring events . . . . . . . . . . . . . . . . . . . . 20
5.5. Updating for "this-and-future" . . . . . . . . . . . . . 20 5.5. Updating for "this-and-future" . . . . . . . . . . . . . 20
5.5.1. Splitting an event . . . . . . . . . . . . . . . . . 21 5.5.1. Splitting an event . . . . . . . . . . . . . . . . . 21
5.5.2. Updating the master and overriding previous . . . . . 21 5.5.2. Updating the base event and overriding previous . . . 21
5.6. CalendarEvent/get . . . . . . . . . . . . . . . . . . . . 21 5.6. CalendarEvent/get . . . . . . . . . . . . . . . . . . . . 21
5.7. CalendarEvent/changes . . . . . . . . . . . . . . . . . . 23 5.7. CalendarEvent/changes . . . . . . . . . . . . . . . . . . 23
5.8. CalendarEvent/set . . . . . . . . . . . . . . . . . . . . 23 5.8. CalendarEvent/set . . . . . . . . . . . . . . . . . . . . 23
5.8.1. Patching . . . . . . . . . . . . . . . . . . . . . . 25 5.8.1. Patching . . . . . . . . . . . . . . . . . . . . . . 25
5.8.2. Sending invitations and responses . . . . . . . . . . 28 5.8.2. Sending invitations and responses . . . . . . . . . . 28
5.9. CalendarEvent/copy . . . . . . . . . . . . . . . . . . . 31 5.9. CalendarEvent/copy . . . . . . . . . . . . . . . . . . . 31
5.10. CalendarEvent/query . . . . . . . . . . . . . . . . . . . 31 5.10. CalendarEvent/query . . . . . . . . . . . . . . . . . . . 31
5.10.1. Filtering . . . . . . . . . . . . . . . . . . . . . 32 5.10.1. Filtering . . . . . . . . . . . . . . . . . . . . . 32
5.10.2. Sorting . . . . . . . . . . . . . . . . . . . . . . 33 5.10.2. Sorting . . . . . . . . . . . . . . . . . . . . . . 33
5.11. CalendarEvent/queryChanges . . . . . . . . . . . . . . . 34 5.11. CalendarEvent/queryChanges . . . . . . . . . . . . . . . 34
5.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 5.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6. Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Default alerts . . . . . . . . . . . . . . . . . . . . . 34 6.1. Default alerts . . . . . . . . . . . . . . . . . . . . . 34
6.2. Acknowledging an alert . . . . . . . . . . . . . . . . . 35 6.2. Acknowledging an alert . . . . . . . . . . . . . . . . . 35
6.3. Snoozing an alert . . . . . . . . . . . . . . . . . . . . 35 6.3. Snoozing an alert . . . . . . . . . . . . . . . . . . . . 35
6.4. Push events . . . . . . . . . . . . . . . . . . . . . . . 36 6.4. Push events . . . . . . . . . . . . . . . . . . . . . . . 35
7. Calendar Event Notifications . . . . . . . . . . . . . . . . 36 7. Calendar Event Notifications . . . . . . . . . . . . . . . . 36
7.1. Auto-deletion of Notifications . . . . . . . . . . . . . 37 7.1. Auto-deletion of Notifications . . . . . . . . . . . . . 37
7.2. Object Properties . . . . . . . . . . . . . . . . . . . . 37 7.2. Object Properties . . . . . . . . . . . . . . . . . . . . 37
7.3. CalendarEventNotification/get . . . . . . . . . . . . . . 38 7.3. CalendarEventNotification/get . . . . . . . . . . . . . . 38
7.4. CalendarEventNotification/changes . . . . . . . . . . . . 38 7.4. CalendarEventNotification/changes . . . . . . . . . . . . 38
7.5. CalendarEventNotification/set . . . . . . . . . . . . . . 38 7.5. CalendarEventNotification/set . . . . . . . . . . . . . . 38
7.6. CalendarEventNotification/query . . . . . . . . . . . . . 38 7.6. CalendarEventNotification/query . . . . . . . . . . . . . 38
7.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 38 7.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 38
7.6.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 39 7.6.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 39
7.7. CalendarEventNotification/queryChanges . . . . . . . . . 39 7.7. CalendarEventNotification/queryChanges . . . . . . . . . 39
skipping to change at page 3, line 29 skipping to change at page 3, line 29
9.1. JMAP Capability Registration for "calendars" . . . . . . 39 9.1. JMAP Capability Registration for "calendars" . . . . . . 39
9.2. JSCalendar Property Registrations . . . . . . . . . . . . 40 9.2. JSCalendar Property Registrations . . . . . . . . . . . . 40
9.2.1. id . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.2.1. id . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.2.2. calendarIds . . . . . . . . . . . . . . . . . . . . . 40 9.2.2. calendarIds . . . . . . . . . . . . . . . . . . . . . 40
9.2.3. isDraft . . . . . . . . . . . . . . . . . . . . . . . 40 9.2.3. isDraft . . . . . . . . . . . . . . . . . . . . . . . 40
9.2.4. utcStart . . . . . . . . . . . . . . . . . . . . . . 40 9.2.4. utcStart . . . . . . . . . . . . . . . . . . . . . . 40
9.2.5. utcEnd . . . . . . . . . . . . . . . . . . . . . . . 41 9.2.5. utcEnd . . . . . . . . . . . . . . . . . . . . . . . 41
9.2.6. mayInviteSelf . . . . . . . . . . . . . . . . . . . . 41 9.2.6. mayInviteSelf . . . . . . . . . . . . . . . . . . . . 41
9.2.7. mayInviteOthers . . . . . . . . . . . . . . . . . . . 41 9.2.7. mayInviteOthers . . . . . . . . . . . . . . . . . . . 41
9.2.8. hideAttendees . . . . . . . . . . . . . . . . . . . . 41 9.2.8. hideAttendees . . . . . . . . . . . . . . . . . . . . 41
10. Normative References . . . . . . . . . . . . . . . . . . . . 42 10. Normative References . . . . . . . . . . . . . . . . . . . . 41
11. Informative References . . . . . . . . . . . . . . . . . . . 42 11. Informative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
protocol for synchronizing data, such as mail, calendars or contacts, protocol for synchronizing data, such as mail, calendars or contacts,
between a client and a server. It is optimized for mobile and web between a client and a server. It is optimized for mobile and web
environments, and aims to provide a consistent interface to different environments, and aims to provide a consistent interface to different
data types. data types.
skipping to change at page 11, line 33 skipping to change at page 11, line 33
This is a standard "/set" method as described in [RFC8620], This is a standard "/set" method as described in [RFC8620],
Section 5.3. The server MAY restrict the uri values the user may Section 5.3. The server MAY restrict the uri values the user may
claim, for example only allowing "mailto:" URIs with email addresses claim, for example only allowing "mailto:" URIs with email addresses
that belong to the user. A standard "forbidden" error is returned to that belong to the user. A standard "forbidden" error is returned to
reject non-permissible changes. reject non-permissible changes.
4. Calendars 4. Calendars
A Calendar is a named collection of events. All events are A Calendar is a named collection of events. All events are
associated with one, and only one, calendar. associated with at least one calendar.
A *Calendar* object has the following properties: A *Calendar* object has the following properties:
* *id*: "Id" (immutable; server-set) The id of the calendar. * *id*: "Id" (immutable; server-set) The id of the calendar.
* *role*: "String|null" (default: null) Denotes the calendar has a * *role*: "String|null" (default: null) Denotes the calendar has a
special purpose. This MUST be one of the following: special purpose. This MUST be one of the following:
- "inbox": This is the principal's default calendar; when the - "inbox": This is the principal's default calendar; when the
principal is invited to an event, this is the calendar to which principal is invited to an event, this is the calendar to which
skipping to change at page 16, line 6 skipping to change at page 16, line 6
which this calendar belongs has the _isReadOnly_ property set to which this calendar belongs has the _isReadOnly_ property set to
true. true.
The user is an *owner* for an event if the CalendarEvent object has a The user is an *owner* for an event if the CalendarEvent object has a
"participants" property, and one of the Participant objects both: "participants" property, and one of the Participant objects both:
a) Has the "owner" role. a) Has the "owner" role.
b) Corresponds to one of the user's ParticipantIdentity objects in the account. b) Corresponds to one of the user's ParticipantIdentity objects in the account.
An event has no owner if its participants property is null or An event has no owner if its participants property is null or
omitted. omitted, or if none of the Participant objects have the "owner" role.
4.1. Calendar/get 4.1. Calendar/get
This is a standard "/get" method as described in [RFC8620], This is a standard "/get" method as described in [RFC8620],
Section 5.1. The _ids_ argument may be "null" to fetch all at once. Section 5.1. The _ids_ argument may be "null" to fetch all at once.
If mayReadFreeBusy is the only permission the user has, the calendar If mayReadFreeBusy is the only permission the user has, the calendar
MUST NOT be returned in Calendar/get and Calendar/query; it must MUST NOT be returned in Calendar/get and Calendar/query; it must
behave as though it did not exist. The data is just used as part of behave as though it did not exist. The data is just used as part of
Principal/getAvailability. Principal/getAvailability.
skipping to change at page 19, line 16 skipping to change at page 19, line 16
This document defines three new JSCalendar properties. This document defines three new JSCalendar properties.
5.1.1. mayInviteSelf 5.1.1. mayInviteSelf
Type: "Boolean" (default: false) Type: "Boolean" (default: false)
If "true", any user that has access to the event may add themselves If "true", any user that has access to the event may add themselves
to it as a participant with the "attendee" role. This property MUST to it as a participant with the "attendee" role. This property MUST
NOT be altered in the recurrenceOverrides; it may only be set on the NOT be altered in the recurrenceOverrides; it may only be set on the
master object. base object.
5.1.2. mayInviteOthers 5.1.2. mayInviteOthers
Type: "Boolean" (default: false) Type: "Boolean" (default: false)
If "true", any current participant with the "attendee" role may add If "true", any current participant with the "attendee" role may add
new participants with the "attendee" role to the event. This new participants with the "attendee" role to the event. This
property MUST NOT be altered in the recurrenceOverrides; it may only property MUST NOT be altered in the recurrenceOverrides; it may only
be set on the master object. be set on the base object.
5.1.3. hideAttendees 5.1.3. hideAttendees
Type: "Boolean" (default: false) Type: "Boolean" (default: false)
If "true", only the owners of the event may see the full set of If "true", only the owners of the event may see the full set of
participants. Other sharees of the event may only see the owners and participants. Other sharees of the event may only see the owners and
themselves. This property MUST NOT be altered in the themselves. This property MUST NOT be altered in the
recurrenceOverrides; it may only be set on the master object. recurrenceOverrides; it may only be set on the base object.
5.2. Attachments 5.2. Attachments
The Link object, as defined in [I-D.ietf-calext-jscalendar] The Link object, as defined in [I-D.ietf-calext-jscalendar]
Section 4.2.7, with a "rel" property equal to "enclosure" is used to Section 4.2.7, with a "rel" property equal to "enclosure" is used to
represent attachments. Instead of mandating an "href" property, represent attachments. Instead of mandating an "href" property,
clients may set a "blobId" property instead to reference a blob of clients may set a "blobId" property instead to reference a blob of
binary data in the account, as per [RFC8620] Section 6. binary data in the account, as per [RFC8620] Section 6.
The server MUST translate this to an embedded "data:" URL [RFC2397] The server MUST translate this to an embedded "data:" URL [RFC2397]
skipping to change at page 20, line 21 skipping to change at page 20, line 21
* useDefaultAlerts * useDefaultAlerts
* alerts * alerts
The user may also modify these properties on a per-occurrence basis The user may also modify these properties on a per-occurrence basis
for recurring events; again, these MUST be stored per-user. for recurring events; again, these MUST be stored per-user.
When writing only per-user properties, the "updated" property MUST When writing only per-user properties, the "updated" property MUST
also be stored just for that user. When fetching the "updated" also be stored just for that user. When fetching the "updated"
property, the value to return is whichever is later of the per-user property, the value to return is whichever is later of the per-user
updated time or the updated time of the master event. updated time or the updated time of the base event.
5.4. Recurring events 5.4. Recurring events
Events may recur, in which case they represent multiple occurrences Events may recur, in which case they represent multiple occurrences
or instances. The data store will either contain a single master or instances. The data store will either contain a single base
event, containing a recurrence rule and/or recurrence overrides; or, event, containing a recurrence rule and/or recurrence overrides; or,
a set of individual instances (when invited to specific occurrences a set of individual instances (when invited to specific occurrences
only). only).
The client may ask the server to expand recurrences within a specific The client may ask the server to expand recurrences within a specific
time range in "CalendarEvent/query". This will generate synthetic time range in "CalendarEvent/query". This will generate synthetic
ids representing individual instances in the requested time range. ids representing individual instances in the requested time range.
The client can fetch and update the objects using these ids and the The client can fetch and update the objects using these ids and the
server will make the appropriate changes to the master event. server will make the appropriate changes to the base event.
Synthetic ids do not appear in "CalendarEvent/changes" responses; Synthetic ids do not appear in "CalendarEvent/changes" responses;
only the ids of events as actually stored on the server. only the ids of events as actually stored on the server.
If the user is invited to specific instances then later added to the If the user is invited to specific instances then later added to the
master event, "CalendarEvent/changes" will show the ids of all the base event, "CalendarEvent/changes" will show the ids of all the
individual instances being destroyed and the id for the master event individual instances being destroyed and the id for the base event
being created. being created.
5.5. Updating for "this-and-future" 5.5. Updating for "this-and-future"
When editing a recurring event, you can either update the master When editing a recurring event, you can either update the base event
event (affecting all instances unless overriden) or update an (affecting all instances unless overriden) or update an override for
override for a specific occurrence. To update all occurrences from a a specific occurrence. To update all occurrences from a specific
specific point onwards, there are therefore two options: split the point onwards, there are therefore two options: split the event, or
event, or update the master and override all occurrences before the update the base event and override all occurrences before the split
split point back to their original values. point back to their original values.
5.5.1. Splitting an event 5.5.1. Splitting an event
If the event is not scheduled (has no participants), the simplest If the event is not scheduled (has no participants), the simplest
thing to do is to duplicate the event, modifying the recurrence rules thing to do is to duplicate the event, modifying the recurrence rules
of the original so it finishes before the split point, and the of the original so it finishes before the split point, and the
duplicate so it starts at the split point. As per JSCalendar duplicate so it starts at the split point. As per JSCalendar
[I-D.ietf-calext-jscalendar] Section 4.1.3, a "next" and "first" [I-D.ietf-calext-jscalendar] Section 4.1.3, a "next" and "first"
relation MUST be set on the new objects respectively. relation MUST be set on the new objects respectively.
Splitting an event however is problematic in the case of a scheduled Splitting an event however is problematic in the case of a scheduled
event, because the iTIP messages generated make it appear like two event, because the iTIP messages generated make it appear like two
unrelated changes, which can be confusing. unrelated changes, which can be confusing.
5.5.2. Updating the master and overriding previous 5.5.2. Updating the base event and overriding previous
For scheduled events, a better approach is to avoid splitting and For scheduled events, a better approach is to avoid splitting and
instead update the master event with the new property value for "this instead update the base event with the new property value for "this
and future", then create overrides for all occurrences before the and future", then create overrides for all occurrences before the
split point to restore the property to its previous value. Indeed, split point to restore the property to its previous value. Indeed,
this may be the only option the user has permission to do if not an this may be the only option the user has permission to do if not an
owner of the event. owner of the event.
Clients may choose to skip creating the overrides if the old data is Clients may choose to skip creating the overrides if the old data is
not important, for example if the "alerts" property is being updated, not important, for example if the "alerts" property is being updated,
it is probably not important to create overrides for events in the it is probably not important to create overrides for events in the
past with the alerts that have already fired. past with the alerts that have already fired.
skipping to change at page 21, line 48 skipping to change at page 21, line 48
recurrence overrides with a recurrence id before this date (when recurrence overrides with a recurrence id before this date (when
translated into UTC) will be returned. translated into UTC) will be returned.
* *recurrenceOverridesAfter*: "UTCDate|null" If given, only * *recurrenceOverridesAfter*: "UTCDate|null" If given, only
recurrence overrides with a recurrence id on or after this date recurrence overrides with a recurrence id on or after this date
(when translated into UTC) will be returned. (when translated into UTC) will be returned.
* *reduceParticipants*: "Boolean" (default: false) If true, only * *reduceParticipants*: "Boolean" (default: false) If true, only
participants with the "owner" role or corresponding to the user's participants with the "owner" role or corresponding to the user's
participant identities will be returned in the "participants" participant identities will be returned in the "participants"
property of the master event and any recurrence overrides. If property of the base event and any recurrence overrides. If
false, all participants will be returned. false, all participants will be returned.
* *timeZone*: "String" (default "Etc/UTC") The time zone to use when * *timeZone*: "String" (default "Etc/UTC") The time zone to use when
calculating the utcStart/utcEnd property of floating events. This calculating the utcStart/utcEnd property of floating events. This
argument has no effect if those properties are not requested. argument has no effect if those properties are not requested.
A CalendarEvent object is a JSEvent object so may have arbitrary A CalendarEvent object is a JSEvent object so may have arbitrary
properties. If the client makes a "CalendarEvent/get" call with a properties. If the client makes a "CalendarEvent/get" call with a
null or omitted "properties" argument, all properties defined on the null or omitted "properties" argument, all properties defined on the
JSEvent object in the store are returned, along with the "id", JSEvent object in the store are returned, along with the "id",
skipping to change at page 23, line 21 skipping to change at page 23, line 21
This is a standard "/set" method as described in [RFC8620], This is a standard "/set" method as described in [RFC8620],
Section 5.3, with the following extra argument: Section 5.3, with the following extra argument:
* *sendSchedulingMessages*: "Boolean" (default: false) If true then * *sendSchedulingMessages*: "Boolean" (default: false) If true then
any changes to scheduled events will be sent to all the any changes to scheduled events will be sent to all the
participants (if the user is an owner of the event) or back to the participants (if the user is an owner of the event) or back to the
owners (otherwise). If false, the changes only affect this owners (otherwise). If false, the changes only affect this
account and no scheduling messages will be sent. account and no scheduling messages will be sent.
For recurring events, an id may represent the master event or a For recurring events, an id may represent the base event or a
specific instance. When the id for a specific instance is given, the specific instance. When the id for a specific instance is given, the
server MUST process an update as an update to the recurrence override server MUST process an update as an update to the recurrence override
for that instance on the master event, and a destroy as removing just for that instance on the base event, and a destroy as removing just
that instance. that instance.
Clients MUST NOT send an update/destroy to both the master event and Clients MUST NOT send an update/destroy to both the base event and a
a specific instance in a single "/set" request; the result of this is specific instance in a single "/set" request; the result of this is
undefined. undefined.
Servers MUST enforce the user's permissions as returned in the Servers MUST enforce the user's permissions as returned in the
"myRights" property of the Calendar objects and reject changes with a "myRights" property of the Calendar objects and reject changes with a
"forbidden" SetError if not allowed. "forbidden" SetError if not allowed.
The "privacy" property MUST NOT be set to anything other than The "privacy" property MUST NOT be set to anything other than
"public" (the default) for events in a calendar that does not belong "public" (the default) for events in a calendar that does not belong
to the user (e.g. a shared team calendar). The server MUST reject to the user (e.g. a shared team calendar). The server MUST reject
this with an "invalidProperties" SetError. this with an "invalidProperties" SetError.
skipping to change at page 29, line 29 skipping to change at page 29, line 29
If sending via iMIP [RFC6047], the server MAY choose to only send If sending via iMIP [RFC6047], the server MAY choose to only send
updates it deems "essential" to avoid flooding the recipient's email updates it deems "essential" to avoid flooding the recipient's email
with changes they do not care about. For example, changes to the with changes they do not care about. For example, changes to the
participationStatus of another participant, or changes to events participationStatus of another participant, or changes to events
solely in the past may be omitted. solely in the past may be omitted.
5.8.2.1. REQUEST 5.8.2.1. REQUEST
When the server is the source for the event, a REQUEST message When the server is the source for the event, a REQUEST message
([RFC5546], Section 3.2.2) is sent to all current participants if: ([RFC5546], Section 3.2.2) is sent to all current participants if
either:
* The event is being created. * The event is being created; or
* Any non per-user property (see Section XXX) is updated on the * Any non per-user property (see Section XXX) is updated on the
event (including adding/removing participants), except if just event (including adding/removing participants), except if just
modifying the recurrenceOverrides such that CANCEL messages are modifying the recurrenceOverrides such that CANCEL messages are
generated (see the next section). generated (see the next section).
Note, if the only change is adding an additional instance (not Note, if the only change is adding an additional instance (not
generated by the event's recurrence rule) to the recurrenceOverrides, generated by the event's recurrence rule) to the recurrenceOverrides,
this MAY be handled via sending an ADD message ([RFC5546], this MAY be handled via sending an ADD message ([RFC5546],
Section 3.2.4) for the single instance rather than a REQUEST message Section 3.2.4) for the single instance rather than a REQUEST message
for the master. However, for interoperability reasons this is not for the base event. However, for interoperability reasons this is
recommended due to poor support in the wild for this type of message. not recommended due to poor support in the wild for this type of
message.
The server MUST ensure participants are only sent information about The server MUST ensure participants are only sent information about
recurrence instances they are added to when sending scheduling recurrence instances they are added to when sending scheduling
messages for recurring events. If the participant is not invited to messages for recurring events. If the participant is not invited to
the master recurring event but only individual instances, scheduling the full recurring event but only individual instances, scheduling
messages MUST be sent for just those expanded occurrences messages MUST be sent for just those expanded occurrences
individually. If a participant is invited to a recurring event, but individually. If a participant is invited to a recurring event, but
removed via a recurrence override from a particular instance, any removed via a recurrence override from a particular instance, any
scheduling messages to this participant MUST return the instance as scheduling messages to this participant MUST return the instance as
"excluded" (if it matches a recurrence rule for the event) or omit "excluded" (if it matches a recurrence rule for the event) or omit
the instance entirely (otherwise). the instance entirely (otherwise).
If the event's "hideAttendees" property is set to "true", the If the event's "hideAttendees" property is set to "true", the
recipient MUST be the only attendee in the message; all others are recipient MUST be the only attendee in the message; all others are
omitted. omitted.
5.8.2.2. CANCEL 5.8.2.2. CANCEL
When the server is the source for the event, a CANCEL message When the server is the source for the event, a CANCEL message
([RFC5546], Section 3.2.5) is sent if: ([RFC5546], Section 3.2.5) is sent if any of:
* A participant is removed from either the master event or a single * A participant is removed from either the base event or a single
instance (the message is only sent to this participant; remaining instance (the message is only sent to this participant; remaining
participants will get a REQUEST, as described above). participants will get a REQUEST, as described above).
* The event is destroyed. * The event is destroyed.
* An exclusion is added to recurrenceOverrides to remove an instance * An exclusion is added to recurrenceOverrides to remove an instance
generated by the event's recurrence rule. generated by the event's recurrence rule.
* An additional instance (not generated by the event's recurrence * An additional instance (not generated by the event's recurrence
rule) is removed from the recurrenceOverrides. rule) is removed from the recurrenceOverrides.
In each of the latter 3 cases, the message is sent to all In each of the latter 3 cases, the message is sent to all
participants. participants.
5.8.2.3. REPLY 5.8.2.3. REPLY
When the server is _not_ the source for the event, a REPLY message When the server is _not_ the source for the event, a REPLY message
([RFC5546], Section 3.2.3) is sent for any participant corresponding ([RFC5546], Section 3.2.3) is sent for any participant corresponding
to one of the user's ParticipantIdentitities in the account if: to one of the user's ParticipantIdentitities in the account if any of
the following changes are made by the user (_not_ by automatic
processing of an iTIP message):
* The "participationStatus" property of the participant is changed. * The "participationStatus" property of the participant is changed.
* The event is destroyed and the participationStatus was not "needs- * The event is destroyed and the participationStatus was not "needs-
action". action".
* The event is created and the participationStatus is not "needs- * The event is created and the participationStatus is not "needs-
action". action".
* An exclusion is added to recurrenceOverrides to remove an instance * An exclusion is added to recurrenceOverrides to remove an instance
generated by the event's recurrence rule. generated by the event's recurrence rule, and the
participationStatus for this instance was not "needs-action".
* An exclusion is removed from recurrenceOverrides (this is presumed * An exclusion is removed from recurrenceOverrides (this is presumed
to be the client undoing the deletion of a single instance). to be the client undoing the deletion of a single instance), and
the participationStatus for this instance is not "needs-action".
* An instance not generated by the event's recurrence rule is * An instance not generated by the event's recurrence rule is
removed from the recurrenceOverrides. removed from the recurrenceOverrides.
* An instance not generated by the event's recurrence rule is added * An instance not generated by the event's recurrence rule is added
to the recurrenceOverrides (this is presumed to be the client to the recurrenceOverrides (this is presumed to be the client
undoing the deletion of a single instance). undoing the deletion of a single instance).
A reply is not sent when deleting an event where the current status A reply is not sent when deleting an event where the current status
is "needs-action" as if a junk calendar event gets added by an is "needs-action" as if a junk calendar event gets added by an
skipping to change at page 38, line 20 skipping to change at page 38, line 14
* *event*: "JSEvent" The data before the change (if updated or * *event*: "JSEvent" The data before the change (if updated or
destroyed), or the data after creation (if created). destroyed), or the data after creation (if created).
* *eventPatch*: "PatchObject" (updated only) A patch encoding the * *eventPatch*: "PatchObject" (updated only) A patch encoding the
change between the data in the event property, and the data after change between the data in the event property, and the data after
the update. the update.
To reduce data, if the change only affects a single instance of a To reduce data, if the change only affects a single instance of a
recurring event, the server MAY set the event and eventPatch recurring event, the server MAY set the event and eventPatch
properties for the instance; the calendarEventId MUST still be for properties for the instance; the calendarEventId MUST still be for
the master event. the base event.
7.3. CalendarEventNotification/get 7.3. CalendarEventNotification/get
This is a standard "/get" method as described in [RFC8620], This is a standard "/get" method as described in [RFC8620],
Section 5.1. Section 5.1.
7.4. CalendarEventNotification/changes 7.4. CalendarEventNotification/changes
This is a standard "/changes" method as described in [RFC8620], This is a standard "/changes" method as described in [RFC8620],
Section 5.2. Section 5.2.
skipping to change at page 42, line 9 skipping to change at page 42, line 7
Property Context: JSEvent, JSTask Property Context: JSEvent, JSTask
Reference: This document, Section XXX. Reference: This document, Section XXX.
Intended Use: Common Intended Use: Common
10. Normative References 10. Normative References
[I-D.ietf-calext-jscalendar] [I-D.ietf-calext-jscalendar]
Jenkins, N. and R. Stepanek, "JSCalendar: A JSON Jenkins, N. and R. Stepanek, "JSCalendar: A JSON
representation of calendar data", Work in Progress, Representation of Calendar Data", Work in Progress,
Internet-Draft, draft-ietf-calext-jscalendar-32, 15 Internet-Draft, draft-ietf-calext-jscalendar-32, 15
October 2020, <https://tools.ietf.org/html/draft-ietf- October 2020, <https://datatracker.ietf.org/doc/html/
calext-jscalendar-32>. draft-ietf-calext-jscalendar-32>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998, DOI 10.17487/RFC2397, August 1998,
<https://www.rfc-editor.org/info/rfc2397>. <https://www.rfc-editor.org/info/rfc2397>.
 End of changes. 34 change blocks. 
44 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/