idnits 2.17.1 draft-ietf-jmap-tasks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 April 2021) is 1101 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXX' is mentioned on line 205, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-jmap-calendars-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JMAP J.M. Baum, Ed. 3 Internet-Draft H.J. Happel, Ed. 4 Intended status: Standards Track audriga 5 Expires: 23 October 2021 21 April 2021 7 JMAP for Tasks 8 draft-ietf-jmap-tasks-00 10 Abstract 12 This document specifies a data model for synchronizing task data with 13 a server using JMAP. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 23 October 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 50 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.3. Data Model Overview . . . . . . . . . . . . . . . . . . . 4 52 1.4. Addition to the Capabilities Object . . . . . . . . . . . 4 53 1.4.1. urn:ietf:params:jmap:tasks . . . . . . . . . . . . . 4 54 2. Principals . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Principal Capability urn:ietf:params:jmap:tasks . . . . . 5 56 3. Assignee Identities . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. AssigneeIdentity/get . . . . . . . . . . . . . . . . . . 6 58 3.2. AssigneeIdentity/changes . . . . . . . . . . . . . . . . 6 59 3.3. AssigneeIdentity/set . . . . . . . . . . . . . . . . . . 6 60 4. TaskLists . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. TaskList/get . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2. TaskList/changes . . . . . . . . . . . . . . . . . . . . 9 63 4.3. TaskList/set . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Additional JSCalendar properties . . . . . . . . . . . . 10 66 5.1.1. mayInviteSelf . . . . . . . . . . . . . . . . . . . . 10 67 5.1.2. mayInviteOthers . . . . . . . . . . . . . . . . . . . 10 68 5.1.3. hideAttendees . . . . . . . . . . . . . . . . . . . . 11 69 5.1.4. relatedTo . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2. Properties similar in JMAP for Calendar . . . . . . . . . 11 71 5.3. Task/get . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.4. Task/changes . . . . . . . . . . . . . . . . . . . . . . 11 73 5.5. Task/set . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.6. Task/copy . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.7. Task/query . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.8. Task/queryChanges . . . . . . . . . . . . . . . . . . . . 12 77 6. Task Notifications . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. Object Properties . . . . . . . . . . . . . . . . . . . . 12 79 6.2. TaskNotification/get . . . . . . . . . . . . . . . . . . 13 80 6.3. TaskNotification/changes . . . . . . . . . . . . . . . . 13 81 6.4. TaskNotification/set . . . . . . . . . . . . . . . . . . 13 82 6.5. TaskNotification/query . . . . . . . . . . . . . . . . . 14 83 6.5.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 14 84 6.5.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.6. TaskNotification/queryChanges . . . . . . . . . . . . . . 14 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 8.1. JMAP Capability Registration for "tasks" . . . . . . . . 14 89 8.2. JSCalendar Property Registrations . . . . . . . . . . . . 15 90 9. Normative References . . . . . . . . . . . . . . . . . . . . 15 91 10. Informative References . . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic 97 protocol for synchronizing data, such as mail, calendars or contacts, 98 between a client and a server. It is optimized for mobile and web 99 environments, and aims to provide a consistent interface to different 100 data types. 102 JMAP for Calendars ([I-D.ietf-jmap-calendars]) defines a data model 103 for synchronizing calendar data between a client and a server using 104 JMAP. The data model is designed to allow a server to provide 105 consistent access to the same data via CalDAV [RFC4791] as well as 106 JMAP. 108 While CalDAV defines access to tasks, JMAP for Calendars does not. 109 This specification fills this gap and defines a data model for 110 synchronizing task data between a client and a server using JMAP. It 111 is built upon JMAP for Calendars and reuses most of its definitions. 112 For better readability this document only outlines differences 113 between this specification and JMAP for Calendars. If not stated 114 otherwise, the same specifics that apply to Calendar, CalendarEvent 115 and CalendarEventNotification objects as defined in the aforemetioned 116 specification also apply to similar data types introduced in this 117 specification. 119 1.1. Notational Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 Type signatures, examples, and property descriptions in this document 128 follow the conventions established in Section 1.1 of [RFC8620]. Data 129 types defined in the core specification are also used in this 130 document. 132 1.2. Terminology 134 The same terminology is used in this document as in the core JMAP 135 specification, see [RFC8620], Section 1.6. 137 The terms ParticipantIdentity, TaskList, Task and TaskNotification 138 are used to refer to the data types defined in this document and 139 instances of those data types. 141 1.3. Data Model Overview 143 Similar to JMAP for Calendar, an Account (see [RFC8620], 144 Section 1.6.2) contains zero or more TaskList objects, which is a 145 named collection of Tasks belonging to a Principal (see 146 [I-D.jenkins-jmap-sharing] Section XXX). Task lists can also provide 147 defaults, such as alerts and a color to apply to tasks in the 148 calendar. Clients commonly let users toggle visibility of tasks 149 belonging to a particular task list on/off. Servers may allow a task 150 to belong to multiple TaskLists within an account. 152 A Task is a representation of a single task or recurring series of 153 Tasks in JSTask [I-D.ietf-calext-jscalendar] format. Recurrence 154 rules and alerts as defined in JMAP for Calendars (see 155 [I-D.ietf-jmap-calendars] Section XXX) apply. 157 Just like the CalendarEventNotification objects (see 158 [I-D.ietf-jmap-calendars] Section XXX), TaskNotification objects keep 159 track of the history of changes made to a task by other users. 160 Similarly, the ShareNotification type (see [I-D.jenkins-jmap-sharing] 161 Section XXX) notifies the user when their access to another user's 162 calendar is granted or revoked. 164 1.4. Addition to the Capabilities Object 166 The capabilities object is returned as part of the JMAP Session 167 object; see [RFC8620], Section 2. This document defines one 168 additional capability URI. 170 1.4.1. urn:ietf:params:jmap:tasks 172 This represents support for the TaskList, Task and TaskNotification 173 data types and associated API methods. The value of this property in 174 the JMAP Session capabilities property is an empty object. 176 The value of this property in an account's accountCapabilities 177 property is an object that MUST contain the following information on 178 server capabilities and permissions for that account: 180 * *shareesActAs*: "String" This MUST be one of: 182 - "self" - sharees act as themselves when using tasks in this 183 account. 185 - "secretary"- sharees act as the principal to which this account 186 belongs. 188 * *minDateTime*: "LocalDate" The earliest date-time the server is 189 willing to accept for any date stored in a Task. 191 * *maxDateTime*: "LocalDate" The latest date-time the server is 192 willing to accept for any date stored in a Task. 194 * *maxExpandedQueryDuration*: "Duration" The maximum duration the 195 user may query over when asking the server to expand recurrences. 197 * *maxAssigneesPerTask*: "Number|null" The maximum number of 198 assignees a single task may have, or null for no limit. 200 * *mayCreateTaskList*: "Boolean" If true, the user may create a task 201 list in this account. 203 2. Principals 205 For systems that also support JMAP Sharing [RFC XXX], the tasks 206 capability is used to indicate that this principal may be used with 207 tasks. 209 2.1. Principal Capability urn:ietf:params:jmap:tasks 211 A "urn:ietf:params:jmap:tasks" property is added to the Principal 212 "capabilities" object, the value of which is an object with the 213 following properties: 215 * *accountId*: "Id|null" Id of Account with the 216 "urn:ietf:params:jmap:tasks" capability that contains the task 217 data for this principal, or null if none (e.g. the Principal is a 218 group just used for permissions management), or the user does not 219 have access to any data in the account. 221 * *account*: "Account|null" The JMAP Account object corresponding to 222 the accountId, null if none. 224 * *sendTo*: "String[String]|null" If this principal may be added as 225 a participant to an event, this is the map of methods for adding 226 it, in the same format as Participant#sendTo in JSTask (see 227 [I-D.ietf-calext-jscalendar], Section 4.4.5). 229 3. Assignee Identities 231 An AssigneeIdentity stores information about a URI that represents 232 the user within that account in an event's assignees. It has the 233 following properties: 235 * *id*: "Id" (immutable; server-set) The id of the AssigneeIdentity. 237 * *name*: "String" (default: "") The display name of the assignee to 238 use when adding this assignee to a task, e.g. "Jane Bloggs". 240 * *sendTo*: "String[String]" Represents methods by which the 241 participant may receive invitations and updates to an event. 243 The keys in the property value are the available methods and MUST 244 only contain ASCII alphanumeric characters (A-Za-z0-9). The value 245 is a URI for the method specified in the key. 247 An assignee in an task corresponds to an AssigneeIdentity if any of 248 the method/uri pairs in the sendTo property of the participant are 249 identical to a method/uri pair in the sendTo property of the 250 identity. 252 The following JMAP methods are supported. 254 3.1. AssigneeIdentity/get 256 This is a standard "/get" method as described in [RFC8620], 257 Section 5.1. The _ids_ argument may be "null" to fetch all at once. 259 3.2. AssigneeIdentity/changes 261 This is a standard "/changes" method as described in [RFC8620], 262 Section 5.2. 264 3.3. AssigneeIdentity/set 266 This is a standard "/set" method as described in [RFC8620], 267 Section 5.3. The server MAY restrict the uri values the user may 268 claim, for example only allowing "mailto:" URIs with email addresses 269 that belong to the user. A standard "forbidden" error is returned to 270 reject non-permissible changes. 272 4. TaskLists 274 A TaskList is a named collection of tasks. All tasks are associated 275 with exactly one TaskList. 277 A *TaskList* object has the following properties: 279 * *id*: "Id" (immutable; server-set) The id of the task list. 281 * *role*: "String|null" (default: null) Denotes the task list has a 282 special purpose. This MUST be one of the following: 284 - "inbox": This is the principal's default task list; 285 - "trash": This task list holds messages the user has discarded; 287 * *name*: "String" The user-visible name of the task list. This may 288 be any UTF-8 string of at least 1 character in length and maximum 289 255 octets in size. 291 * *description*: "String|null" (default: null) An optional longer- 292 form description of the task list, to provide context in shared 293 environments where users need more than just the name. 295 * *color*: "String|null" (default: null) A color to be used when 296 displaying events associated with the task list. 298 If not null, the value MUST be a case-insensitive color name taken 299 from the set of names defined in Section 4.3 of CSS Color Module 300 Level 3 COLORS (https://www.w3.org/TR/css-color-3/), or an RGB 301 value in hexadecimal notation, as defined in Section 4.2.1 of CSS 302 Color Module Level 3. 304 The color SHOULD have sufficient contrast to be used as text on a 305 white background. 307 * *sortOrder*: "UnsignedInt" (default: 0) Defines the sort order of 308 task lists when presented in the client's UI, so it is consistent 309 between devices. The number MUST be an integer in the range 0 <= 310 sortOrder < 2^(31.) 312 A task list with a lower order should be displayed before a list 313 with a higher order in any list of task lists in the client's UI. 314 Task lists with equal order SHOULD be sorted in alphabetical order 315 by name. The sorting should take into account locale-specific 316 character order convention. 318 * *isSubscribed*: "Boolean" Has the user indicated they wish to see 319 this task list in their client? This SHOULD default to false for 320 task lists in shared accounts the user has access to and true for 321 any new task list created by the user themself. 323 If false, the task list should only be displayed when the user 324 explicitly requests it or to offer it for the user to subscribe 325 to. 327 * *defaultAlertsWithTime*: "Id[Alert]|null" (default: null) A map of 328 alert ids to Alert objects (see [I-D.ietf-calext-jscalendar], 329 Section 4.5.2) to apply for events where "showWithoutTime" is 330 false and "useDefaultAlerts" is true. Ids MUST be unique across 331 all default alerts in the account, including those in other task 332 lists; a UUID is recommended. 334 * *defaultAlertsWithoutTime*: "Id[Alert]|null" (default: null) A map 335 of alert ids to Alert objects (see [I-D.ietf-calext-jscalendar], 336 Section 4.5.2) to apply for events where "showWithoutTime" is true 337 and "useDefaultAlerts" is true. Ids MUST be unique across all 338 default alerts in the account, including those in other task 339 lists; a UUID is recommended. 341 * *timeZone*: "String|null" (default: null) The time zone to use for 342 events without a time zone when the server needs to resolve them 343 into absolute time, e.g., for alerts or availability calculation. 344 The value MUST be a time zone id from the IANA Time Zone Database 345 TZDB (https://www.iana.org/time-zones). If "null", the timeZone 346 of the account's associated Principal will be used. Clients 347 SHOULD use this as the default for new events in this task list if 348 set. 350 * *shareWith*: "Id[CalendarRights]|null" (default: null) A map of 351 Principal id to rights for principals this calendar is shared 352 with. The principal to which this task list belongs MUST NOT be 353 in this set. This is null if the user requesting the object does 354 not have the mayAdmin right, or if the task list is not shared 355 with anyone. May be modified only if the user has the mayAdmin 356 right. The account id for the principals may be found in the 357 "urn:ietf:params:jmap:principals:owner" capability of the Account 358 to which the calendar belongs. 360 The user is an *owner* for a task if the Task object has an 361 "assignee" property, and one of the Participant objects both: 363 1. Has the "chair" role. 365 2. Corresponds to one of the user's AssigneeIdentity objects in the 366 account. 368 A task has no owner if its assignee property is null or omitted. 370 TODO currently disregarding "myRights" 372 4.1. TaskList/get 374 This is a standard "/get" method as described in [RFC8620], 375 Section 5.1. The _ids_ argument may be "null" to fetch all at once. 377 TODO add part about rights properties. 379 4.2. TaskList/changes 381 This is a standard "/changes" method as described in [RFC8620], 382 Section 5.2. 384 4.3. TaskList/set 386 This is the "Calendar/set" method as described in 387 [I-D.ietf-jmap-calendars], Section XXX. 389 TODO copy+paste from "Calendar/set" and replace 390 "onDestroyRemoveEvents" by "onDestroyRemoveTasks" (and 391 "calendarHasEvent"). 393 5. Tasks 395 A *Task* object contains information about a task, or recurring 396 series of tasks. It is a JSTask object, as defined in 397 [I-D.ietf-calext-jscalendar], with the following additional 398 properties: 400 * *id*: "Id" The id of the Task. This property is immutable. The 401 id uniquely identifies a JSTask with a particular "uid" and 402 "recurrenceId" within a particular account. 404 * *taskListId*: "Id" The TaskList id this task belongs to. A task 405 MUST belong to exactly one TaskList at all times (until it is 406 destroyed). 408 * *isDraft*: "Boolean" If true, this task is to be considered a 409 draft. The server will not send any push notifications for 410 alerts. This may only be set to true upon creation. Once set to 411 false, the value cannot be updated to true. This property MUST 412 NOT appear in "recurrenceOverrides". 414 * *utcStart*: "UTCDate" For simple clients that do not or cannot 415 implement time zone support. Clients should only use this if also 416 asking the server to expand recurrences, as you cannot accurately 417 expand a recurrence without the original time zone. 419 This property is calculated at fetch time by the server. Time 420 zones are political, and they can and do change at any time. 421 Fetching exactly the same property again may return different 422 results if the time zone data has been updated on the server. 423 Time zone data changes are not considered "updates" to the task. 425 If set, the server will convert to the task's current time zone 426 using its current time zone data and store the local time. 428 This is not included by default and must be requested explicitly. 430 Floating tasks (tasks without a time zone) will be interpreted as 431 per the time zone given as a Task/get argument. 433 Note that it is not possible to accurately calculate the expansion 434 of recurrence rules or recurrence overrides with the utcStart 435 property rather than the local start time. Even simple 436 recurrences such as "repeat weekly" may cross a daylight-savings 437 boundary and end up at a different UTC time. Clients that wish to 438 use "utcStart" are RECOMMENDED to request the server expand 439 recurrences (see Section XXX). 441 * *utcDue*: "UTCDate" The server calculates the end time in UTC from 442 the start/timeZone/duration properties of the task. This is not 443 included by default and must be requested explicitly. Like 444 utcStart, this is calculated at fetch time if requested and may 445 change due to time zone data changes. Floating tasks will be 446 interpreted as per the time zone given as a Task/get argument. 448 * *sortOrder*: "UnsignedInt" (default: 0) Defines the sort order of 449 a task when presented in the client's UI, so it is consistent 450 between devices. The number MUST be an integer in the range 0 <= 451 sortOrder < 2^(31.) 453 A task with a lower order should be displayed before a task with a 454 higher order in any list of tasks in the client's UI. Tasks with 455 equal order SHOULD be sorted in alphabetical order by name. The 456 sorting should take into account locale-specific character order 457 convention. 459 5.1. Additional JSCalendar properties 461 This document defines four new JSCalendar properties. 463 5.1.1. mayInviteSelf 465 Type: "Boolean" (default: false) 467 If "true", any user that has access to the event may add themselves 468 to it as a participant with the "attendee" role. This property MUST 469 NOT be altered in the recurrenceOverrides; it may only be set on the 470 master object. 472 5.1.2. mayInviteOthers 474 Type: "Boolean" (default: false) 475 If "true", any current participant with the "attendee" role may add 476 new participants with the "attendee" role to the event. This 477 property MUST NOT be altered in the recurrenceOverrides; it may only 478 be set on the master object. 480 5.1.3. hideAttendees 482 Type: "Boolean" (default: false) 484 If "true", only the owners of the event may see the full set of 485 participants. Other sharees of the event may only see the owners and 486 themselves. This property MUST NOT be altered in the 487 recurrenceOverrides; it may only be set on the master object. 489 5.1.4. relatedTo 491 Type: "Id[String]|null" (default: null) 493 A map of task ids to relations. Relation SHOULD be one of: - 494 "blockedBy": Blocked by task with id. - "clonedBy": Task with id was 495 cloned from this issue. - "duplicatedBy": Task with id is a 496 duplicate of this issue. - "causedBy": Task with id was the cause 497 for this task. - "relatesTo": Task with id is related. - "childOf": 498 Task with id is parent. 500 5.2. Properties similar in JMAP for Calendar 502 Attachments, per-user properties, recurrences and updates to 503 recurrences are described in [I-D.ietf-jmap-calendars], Section XXX. 505 5.3. Task/get 507 This is the "CalendarEvent/get" method as described in 508 [I-D.ietf-jmap-calendars], Section XXX. 510 TODO redefine this here. Similar to "TaskList/get" we only need to 511 replace a few definitions. For example, replace "reduceParticipants" 512 with "reduceAssignees". Copy+Paste most of the stuff. 514 5.4. Task/changes 516 This is a standard "/changes" method as described in [RFC8620], 517 Section 5.2. 519 5.5. Task/set 521 This is the "CalendarEvent/set" method as described in 522 [I-D.ietf-jmap-calendars], Section XXX. 524 TODO copy+paste most stuff from "CalendarEvent/set". It should be 525 fine to just reference patching. 527 5.6. Task/copy 529 This is a standard "/copy" method as described in [RFC8620], 530 Section 5.4. 532 5.7. Task/query 534 This is the "CalendarEvent/query" method as described in 535 [I-D.ietf-jmap-calendars], Section XXX. 537 TODO copy+paste most stuff from "CalendarEvent/query". Mainly 538 filtering should be different. 540 5.8. Task/queryChanges 542 This is a standard "/queryChanges" method as described in [RFC8620], 543 Section 5.6. 545 6. Task Notifications 547 The TaskNotification data type records changes made by external 548 entities to tasks in calendars the user is subscribed to. 549 Notifications are stored in the same Account as the Task that was 550 changed. 552 This is the same specification as the CalendarEventNotification 553 object from [I-D.ietf-jmap-calendars], Section XXX. Only the object 554 properties differ slightly and are therefore fully described in this 555 document. 557 6.1. Object Properties 559 The *TaskNotification* object has the following properties: 561 * *id*: "String" The id of the TaskNotification. 563 * *created*: "UTCDate" The time this notification was created. 565 * *changedBy*: "Person" Who made the change. 567 - *name*: "String" The name of the person who made the change. 569 - *email*: "String" The email of the person who made the change, 570 or null if no email is available. 572 - *principalId*: "String|null" The id of the principal 573 corresponding to the person who made the change, if any. This 574 will be null if the change was due to receving an iTIP message. 576 * *comment*: "String|null" Comment sent along with the change by the 577 user that made it. (e.g. COMMENT property in an iTIP message). 579 * *type*: "String" This MUST be one of 581 - created 583 - updated 585 - destroyed 587 * *TaskId*: "String" The id of the Task that this notification is 588 about. 590 * *isDraft*: "Boolean" (created/updated only) Is this event a draft? 592 * *event*: "JSTask" The data before the change (if updated or 593 destroyed), or the data after creation (if created). 595 * *eventPatch*: "PatchObject" (updated only) A patch encoding the 596 change between the data in the event property, and the data after 597 the update. 599 To reduce data, if the change only affects a single instance of a 600 recurring event, the server MAY set the event and eventPatch 601 properties for the instance; the calendarEventId MUST still be for 602 the master event. 604 6.2. TaskNotification/get 606 This is a standard "/get" method as described in [RFC8620], 607 Section 5.1. 609 6.3. TaskNotification/changes 611 This is a standard "/changes" method as described in [RFC8620], 612 Section 5.2. 614 6.4. TaskNotification/set 616 This is a standard "/changes" method as described in [RFC8620], 617 Section 5.3. 619 Only destroy is supported; any attempt to create/update MUST be 620 rejected with a "forbidden" SetError. 622 6.5. TaskNotification/query 624 This is a standard "/query" method as described in [RFC8620], 625 Section 5.5. 627 6.5.1. Filtering 629 A *FilterCondition* object has the following properties: 631 * *after*: "UTCDate|null" The creation date must be on or after this 632 date to match the condition. 634 * *before*: "UTCDate|null" The creation date must be before this 635 date to match the condition. 637 * *type*: "String" The type property must be the same to match the 638 condition. 640 * *taskIds*: "Id[]|null" A list of task ids. The taskId property of 641 the notification must be in this list to match the condition. 643 6.5.2. Sorting 645 The "created" property MUST be supported for sorting. 647 6.6. TaskNotification/queryChanges 649 This is a standard "/queryChanges" method as described in [RFC8620], 650 Section 5.6. 652 7. Security Considerations 654 All security considerations of JMAP for Calendars 655 [I-D.ietf-jmap-calendars] apply to this specification. 657 8. IANA Considerations 659 8.1. JMAP Capability Registration for "tasks" 661 TODO Actually register 663 IANA will register the "tasks" JMAP Capability as follows: 665 Capability Name: "urn:ietf:params:jmap:tasks" 666 Specification document: this document 668 Intended use: common 670 Change Controller: IETF 672 Security and privacy considerations: this document, Section XXX 674 8.2. JSCalendar Property Registrations 676 All IANA registrations for JSTask are described in JMAP for Calendars 677 [I-D.ietf-jmap-calendars]. 679 9. Normative References 681 [I-D.ietf-calext-jscalendar] 682 Jenkins, N. and R. Stepanek, "JSCalendar: A JSON 683 representation of calendar data", Work in Progress, 684 Internet-Draft, draft-ietf-calext-jscalendar-32, 15 685 October 2020, . 688 [I-D.ietf-jmap-calendars] 689 Jenkins, N. and M. Douglass, "JMAP for Calendars", Work in 690 Progress, Internet-Draft, draft-ietf-jmap-calendars-05, 24 691 January 2021, . 694 [I-D.jenkins-jmap-sharing] 695 Jenkins, N., "JMAP Sharing", Work in Progress, Internet- 696 Draft, draft-jenkins-jmap-sharing-00, 15 December 2020, 697 . 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, 702 DOI 10.17487/RFC2119, March 1997, 703 . 705 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 706 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 707 May 2017, . 709 [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application 710 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 711 2019, . 713 10. Informative References 715 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 716 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 717 DOI 10.17487/RFC4791, March 2007, 718 . 720 Authors' Addresses 722 Joris Baum (editor) 723 audriga 724 Durlacher Allee 47 725 76131 Karlsruhe 726 Germany 728 Email: joris@audriga.com 729 URI: https://www.audriga.com 731 Hans-Joerg (editor) 732 audriga 733 Durlacher Allee 47 734 76131 Karlsruhe 735 Germany 737 Email: hans-joerg@audriga.com 738 URI: https://www.audriga.com