JMAP Tasks

This document specifies a data model for synchronizing todo/task data with a server using JMAP.

Introduction

JMAP ([@!RFC8620] – JSON Meta Application Protocol) is a generic protocol for synchronizing data, such as mail, calendars or contacts, between a client and a server. It is optimized for mobile and web environments, and aims to provide a consistent interface to different data types.

JMAP for Calendars ([@!I-D.ietf-jmap-calendars]) defines a data model for synchronizing calendar data between a client and a server using JMAP. The data model is designed to allow a server to provide consistent access to the same data via CalDAV [@?RFC4791] as well as JMAP.

While CalDAV defines access to tasks, JMAP for Calendars does not. This specification fills this gap and defines a data model for synchronizing task data between a client and a server using JMAP. It is built upon JMAP for Calendars and reuses most of its definitions. For better readability this document only outlines differences between this specification and JMAP for Calendars. If not stated otherwise, the same specifics that apply to Calendar, CalendarEvent and CalendarEventNotification objects as defined in the aforemetioned specification also apply to similar data types introduced in this specification.

Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [@!RFC2119] [@!RFC8174] when, and only when, they appear in all capitals, as shown here.

Type signatures, examples, and property descriptions in this document follow the conventions established in Section 1.1 of [@!RFC8620]. Data types defined in the core specification are also used in this document.

Terminology

The same terminology is used in this document as in the core JMAP specification, see [@!RFC8620], Section 1.6.

The terms ParticipantIdentity, TaskList, Task and TaskNotification are used to refer to the data types defined in this document and instances of those data types.

Data Model Overview

Similar to JMAP for Calendar, an Account (see [@!RFC8620], Section 1.6.2) contains zero or more TaskList objects, which is a named collection of Tasks belonging to a Principal (see [@!I-D.jenkins-jmap-sharing] Section XXX). Task lists can also provide defaults, such as alerts and a color to apply to tasks in the calendar. Clients commonly let users toggle visibility of tasks belonging to a particular task list on/off. Servers may allow a task to belong to multiple TaskLists within an account.

A Task is a representation of a single task or recurring series of Tasks in JSTask [@!I-D.ietf-calext-jscalendar] format. Recurrence rules and alerts as defined in JMAP for Calendars (see [@!I-D.ietf-jmap-calendars] Section XXX) apply.

Just like the CalendarEventNotification objects (see [@!I-D.ietf-jmap-calendars] Section XXX), TaskNotification objects keep track of the history of changes made to a task by other users. Similarly, the ShareNotification type (see [@!I-D.jenkins-jmap-sharing] Section XXX) notifies the user when their access to another user’s calendar is granted or revoked.

Addition to the Capabilities Object

The capabilities object is returned as part of the JMAP Session object; see [@!RFC8620], Section 2. This document defines one additional capability URI.

urn:ietf:params:jmap:tasks

This represents support for the TaskList, Task and TaskNotification data types and associated API methods. The value of this property in the JMAP Session capabilities property is an empty object.

The value of this property in an account’s accountCapabilities property is an object that MUST contain the following information on server capabilities and permissions for that account:

Principals

For systems that also support JMAP Sharing [RFC XXX], the tasks capability is used to indicate that this principal may be used with tasks.

Principal Capability urn:ietf:params:jmap:tasks

A “urn:ietf:params:jmap:tasks” property is added to the Principal “capabilities” object, the value of which is an object with the following properties:

Assignee Identities

An AssigneeIdentity stores information about a URI that represents the user within that account in an event’s assignees. It has the following properties:

An assignee in an task corresponds to an AssigneeIdentity if any of the method/uri pairs in the sendTo property of the participant are identical to a method/uri pair in the sendTo property of the identity.

The following JMAP methods are supported.

AssigneeIdentity/get

This is a standard “/get” method as described in [@!RFC8620], Section 5.1. The ids argument may be null to fetch all at once.

AssigneeIdentity/changes

This is a standard “/changes” method as described in [@!RFC8620], Section 5.2.

AssigneeIdentity/set

This is a standard “/set” method as described in [@!RFC8620], Section 5.3. The server MAY restrict the uri values the user may claim, for example only allowing mailto: URIs with email addresses that belong to the user. A standard forbidden error is returned to reject non-permissible changes.

TaskLists

A TaskList is a named collection of tasks. All tasks are associated with at least one TaskList.

A TaskList object has the following properties:

The user is an owner for a task if the Task object has an “assignee” property, and one of the Participant objects both:

  1. Has the “chair” role.
  2. Corresponds to one of the user’s AssigneeIdentity objects in the account.

A task has no owner if its assignee property is null or omitted.

TODO currently disregarding myRights

TaskList/get

This is a standard “/get” method as described in [@!RFC8620], Section 5.1. The ids argument may be null to fetch all at once.

TODO add part about rights properties.

TaskList/changes

This is a standard “/changes” method as described in [@!RFC8620], Section 5.2.

TaskList/set

This is the “Calendar/set” method as described in [@!I-D.ietf-jmap-calendars], Section XXX.

TODO copy+paste from “Calendar/set” and replace onDestroyRemoveEvents by onDestroyRemoveTasks (and calendarHasEvent).

Tasks

A Task object contains information about a task, or recurring series of tasks. It is a JSTask object, as defined in [@!I-D.ietf-calext-jscalendar], with the following additional properties:

Additional JSCalendar properties

This document defines four new JSCalendar properties.

mayInviteSelf

Type: Boolean (default: false)

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 NOT be altered in the recurrenceOverrides; it may only be set on the master object.

mayInviteOthers

Type: Boolean (default: false)

If true, any current participant with the “attendee” role may add new participants with the “attendee” role to the event. This property MUST NOT be altered in the recurrenceOverrides; it may only be set on the master object.

hideAttendees

Type: Boolean (default: false)

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 themselves. This property MUST NOT be altered in the recurrenceOverrides; it may only be set on the master object.

relatedTo

Type: Id[String]|null (default: null)

A map of task ids to relations. Relation SHOULD be one of: - blockedBy: Blocked by task with id. - clonedBy: Task with id was cloned from this issue. - duplicatedBy: Task with id is a duplicate of this issue. - causedBy: Task with id was the cause for this task. - relatesTo: Task with id is related. - childOf: Task with id is parent.

Properties similar in JMAP for Calendar

Attachments, per-user properties, recurrences and updates to recurrences are described in [@!I-D.ietf-jmap-calendars], Section XXX.

Task/get

This is the “CalendarEvent/get” method as described in [@!I-D.ietf-jmap-calendars], Section XXX.

TODO redefine this here. Similar to “TaskList/get” we only need to replace a few definitions. For example, replace reduceParticipants with reduceAssignees. Copy+Paste most of the stuff.

Task/changes

This is a standard “/changes” method as described in [@!RFC8620], Section 5.2.

Task/set

This is the “CalendarEvent/set” method as described in [@!I-D.ietf-jmap-calendars], Section XXX.

TODO copy+paste most stuff from “CalendarEvent/set”. It should be fine to just reference patching.

Task/copy

This is a standard “/copy” method as described in [@!RFC8620], Section 5.4.

Task/query

This is the “CalendarEvent/query” method as described in [@!I-D.ietf-jmap-calendars], Section XXX.

TODO copy+paste most stuff from “CalendarEvent/query”. Mainly filtering should be different.

Task/queryChanges

This is a standard “/queryChanges” method as described in [@!RFC8620], Section 5.6.

Task Notifications

The TaskNotification data type records changes made by external entities to tasks in calendars the user is subscribed to. Notifications are stored in the same Account as the Task that was changed.

This is the same specification as the CalendarEventNotification object from [@!I-D.ietf-jmap-calendars], Section XXX. Only the object properties differ slightly and are therefore fully described in this document.

Object Properties

The TaskNotification object has the following properties:

To reduce data, if the change only affects a single instance of a recurring event, the server MAY set the event and eventPatch properties for the instance; the calendarEventId MUST still be for the master event.

TaskNotification/get

This is a standard “/get” method as described in [@!RFC8620], Section 5.1.

TaskNotification/changes

This is a standard “/changes” method as described in [@!RFC8620], Section 5.2.

TaskNotification/set

This is a standard “/changes” method as described in [@!RFC8620], Section 5.3.

Only destroy is supported; any attempt to create/update MUST be rejected with a forbidden SetError.

TaskNotification/query

This is a standard “/query” method as described in [@!RFC8620], Section 5.5.

Filtering

A FilterCondition object has the following properties:

Sorting

The “created” property MUST be supported for sorting.

TaskNotification/queryChanges

This is a standard “/queryChanges” method as described in [@!RFC8620], Section 5.6.

Security Considerations

All security considerations of JMAP for Calendars [@!I-D.ietf-jmap-calendars] apply to this specification.

IANA Considerations

JMAP Capability Registration for “tasks”

TODO Actually register

IANA will register the “tasks” JMAP Capability as follows:

Capability Name: urn:ietf:params:jmap:tasks

Specification document: this document

Intended use: common

Change Controller: IETF

Security and privacy considerations: this document, Section XXX

JSCalendar Property Registrations

All IANA registrations for JSTask are described in JMAP for Calendars [@!I-D.ietf-jmap-calendars].