idnits 2.17.1 draft-ietf-calext-jscalendar-26.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 (March 8, 2020) is 1507 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: 'Alert' is mentioned on line 2759, but not defined == Missing Reference: 'Boolean' is mentioned on line 2975, but not defined == Missing Reference: 'Link' is mentioned on line 2886, but not defined == Missing Reference: 'PatchObject' is mentioned on line 2950, but not defined == Missing Reference: 'Location' is mentioned on line 2900, but not defined == Missing Reference: 'Participant' is mentioned on line 2922, but not defined == Missing Reference: 'Relation' is mentioned on line 2959, but not defined == Missing Reference: 'String' is mentioned on line 2990, but not defined == Missing Reference: 'TimeZone' is mentioned on line 3021, but not defined == Missing Reference: 'VirtualLocation' is mentioned on line 3049, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CLDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'COLORS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TZDB' Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring extensions N. Jenkins 3 Internet-Draft R. Stepanek 4 Intended status: Standards Track Fastmail 5 Expires: September 9, 2020 March 8, 2020 7 JSCalendar: A JSON representation of calendar data 8 draft-ietf-calext-jscalendar-26 10 Abstract 12 This specification defines a data model and JSON representation of 13 calendar data that can be used for storage and data exchange in a 14 calendaring and scheduling environment. It aims to be an alternative 15 and, over time, successor to the widely deployed iCalendar data 16 format, and to be unambiguous, extendable, and simple to process. In 17 contrast to the jCal format, which is also JSON-based, JSCalendar is 18 not a direct mapping from iCalendar, but defines the data model 19 independently and expands semantics where appropriate. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 9, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Motivation and Relation to iCalendar and jCal . . . . . . 5 57 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 6 58 1.3. Type Signatures . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.4.1. Int . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.4.2. UnsignedInt . . . . . . . . . . . . . . . . . . . . . 7 62 1.4.3. UTCDateTime . . . . . . . . . . . . . . . . . . . . . 7 63 1.4.4. LocalDateTime . . . . . . . . . . . . . . . . . . . . 7 64 1.4.5. Duration . . . . . . . . . . . . . . . . . . . . . . 7 65 1.4.6. SignedDuration . . . . . . . . . . . . . . . . . . . 8 66 1.4.7. Id . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1.4.8. PatchObject . . . . . . . . . . . . . . . . . . . . . 9 68 1.4.9. Time Zones . . . . . . . . . . . . . . . . . . . . . 9 69 1.4.10. Relation . . . . . . . . . . . . . . . . . . . . . . 10 70 2. JSCalendar Objects . . . . . . . . . . . . . . . . . . . . . 10 71 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3. Structure of JSCalendar Objects . . . . . . . . . . . . . . . 11 75 3.1. Normalization and Equivalence . . . . . . . . . . . . . . 11 76 3.2. Vendor-specific Property Extensions and Values . . . . . 12 77 4. Common JSCalendar Properties . . . . . . . . . . . . . . . . 12 78 4.1. Metadata Properties . . . . . . . . . . . . . . . . . . . 12 79 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 13 82 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 14 86 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.2. What and Where Properties . . . . . . . . . . . . . . . . 14 88 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 15 90 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 15 91 4.2.4. showWithoutTime . . . . . . . . . . . . . . . . . . . 15 92 4.2.5. locations . . . . . . . . . . . . . . . . . . . . . . 15 93 4.2.6. virtualLocations . . . . . . . . . . . . . . . . . . 17 94 4.2.7. links . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.2.8. locale . . . . . . . . . . . . . . . . . . . . . . . 19 96 4.2.9. keywords . . . . . . . . . . . . . . . . . . . . . . 19 97 4.2.10. categories . . . . . . . . . . . . . . . . . . . . . 19 98 4.2.11. color . . . . . . . . . . . . . . . . . . . . . . . . 20 99 4.3. Recurrence Properties . . . . . . . . . . . . . . . . . . 20 100 4.3.1. recurrenceId . . . . . . . . . . . . . . . . . . . . 20 101 4.3.2. recurrenceRules . . . . . . . . . . . . . . . . . . . 20 102 4.3.3. recurrenceOverrides . . . . . . . . . . . . . . . . . 28 103 4.3.4. excluded . . . . . . . . . . . . . . . . . . . . . . 30 104 4.4. Sharing and Scheduling Properties . . . . . . . . . . . . 30 105 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 30 106 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 30 107 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 30 108 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 32 109 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 32 110 4.5. Alerts Properties . . . . . . . . . . . . . . . . . . . . 37 111 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 37 112 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 37 113 4.6. Multilingual Properties . . . . . . . . . . . . . . . . . 39 114 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 39 115 4.7. Time Zone Properties . . . . . . . . . . . . . . . . . . 40 116 4.7.1. timeZone . . . . . . . . . . . . . . . . . . . . . . 40 117 4.7.2. timeZones . . . . . . . . . . . . . . . . . . . . . . 40 118 5. Type-specific JSCalendar Properties . . . . . . . . . . . . . 43 119 5.1. JSEvent Properties . . . . . . . . . . . . . . . . . . . 43 120 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 43 121 5.1.2. duration . . . . . . . . . . . . . . . . . . . . . . 43 122 5.1.3. status . . . . . . . . . . . . . . . . . . . . . . . 43 123 5.2. JSTask Properties . . . . . . . . . . . . . . . . . . . . 44 124 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 44 125 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 44 126 5.2.3. estimatedDuration . . . . . . . . . . . . . . . . . . 44 127 5.2.4. progress . . . . . . . . . . . . . . . . . . . . . . 44 128 5.2.5. progressUpdated . . . . . . . . . . . . . . . . . . . 45 129 5.3. JSGroup Properties . . . . . . . . . . . . . . . . . . . 45 130 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 46 131 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 46 132 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 46 133 6.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 46 134 6.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 47 135 6.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 47 136 6.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 48 137 6.5. Task with a due date . . . . . . . . . . . . . . . . . . 48 138 6.6. Event with end time-zone . . . . . . . . . . . . . . . . 49 139 6.7. Floating-time event (with recurrence) . . . . . . . . . . 49 140 6.8. Event with multiple locations and localization . . . . . 50 141 6.9. Recurring event with overrides . . . . . . . . . . . . . 51 142 6.10. Recurring event with participants . . . . . . . . . . . . 52 143 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 144 7.1. Expanding Recurrences . . . . . . . . . . . . . . . . . . 54 145 7.2. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 54 146 7.3. URI Values . . . . . . . . . . . . . . . . . . . . . . . 55 147 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 148 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 55 149 8.2. Creation of "JSCalendar Properties" Registry . . . . . . 56 150 8.2.1. Preliminary Community Review . . . . . . . . . . . . 57 151 8.2.2. Submit Request to IANA . . . . . . . . . . . . . . . 57 152 8.2.3. Designated Expert Review . . . . . . . . . . . . . . 57 153 8.2.4. Change Procedures . . . . . . . . . . . . . . . . . . 58 154 8.2.5. JMAP Properties Registry Template . . . . . . . . . . 58 155 8.2.6. Initial Contents for the JSCalendar Properties 156 Registry . . . . . . . . . . . . . . . . . . . . . . 59 157 8.3. Creation of "JSCalendar Types" Registry . . . . . . . . . 66 158 8.3.1. JMAP Types Registry Template . . . . . . . . . . . . 66 159 8.3.2. Initial Contents for the JSCalendar Types Registry . 66 160 8.4. Creation of "JSCalendar Enum Values" Registry . . . . . . 68 161 8.4.1. JMAP Enum Property Template . . . . . . . . . . . . . 68 162 8.4.2. JMAP Enum Value Template . . . . . . . . . . . . . . 68 163 8.4.3. Initial Contents for the JSCalendar Enum Registry . . 68 164 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73 165 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 166 10.1. Normative References . . . . . . . . . . . . . . . . . . 73 167 10.2. Informative References . . . . . . . . . . . . . . . . . 75 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 170 1. Introduction 172 This document defines a data model for calendar event and task 173 objects, or groups of such objects, in electronic calendar 174 applications and systems. The format aims to be unambiguous, 175 extendable and simple to process. 177 The key design considerations for this data model are as follows: 179 o The attributes of the calendar entry represented must be described 180 as simple key-value pairs. Simple events are simple to represent; 181 complex events can be modelled accurately. 183 o Wherever possible, there should be only one way to express the 184 desired semantics, reducing complexity. 186 o The data model should avoid ambiguities, which often lead to 187 interoperability issues between implementations. 189 o The data model should be compatible with the iCalendar data format 190 [RFC5545] [RFC7986] and extensions, but the specification should 191 add new attributes where the iCalendar format currently lacks 192 expressivity, and drop seldom-used, obsolete, or redundant 193 properties. This means translation with no loss of semantics 194 should be easy with most common iCalendar files. 196 o Extensions, such as new properties and components, should not 197 require updates to this document. 199 The representation of this data model is defined in the I-JSON format 200 [RFC7493], which is a strict subset of the JavaScript Object Notation 201 (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a 202 pragmatic choice: its widespread use makes JSCalendar easier to 203 adopt, and the ready availability of production-ready JSON 204 implementations eliminates a whole category of parser-related 205 interoperability issues, which iCalendar has often suffered from. 207 1.1. Motivation and Relation to iCalendar and jCal 209 The iCalendar data format [RFC5545], a widely deployed interchange 210 format for calendaring and scheduling data, has served calendaring 211 vendors for a long while, but contains some ambiguities and pitfalls 212 that can not be overcome without backward-incompatible changes. 214 Sources of implementation errors include the following: 216 o iCalendar defines various formats for local times, UTC time, and 217 dates. 219 o iCalendar requires custom time zone definitions within a single 220 calendar component. 222 o iCalendar's definition of recurrence rules is ambiguous and has 223 resulted in differing understandings even between experienced 224 calendar developers. 226 o The iCalendar format itself causes interoperability issues due to 227 misuse of CRLF-terminated strings, line continuations, and subtle 228 differences among iCalendar parsers. 230 In recent years, many new products and services have appeared that 231 wish to use a JSON representation of calendar data within their APIs. 232 The JSON format for iCalendar data, jCal [RFC7265], is a direct 233 mapping between iCalendar and JSON. In its effort to represent full 234 iCalendar semantics, it inherits all the same pitfalls and uses a 235 complicated JSON structure. 237 As a consequence, since the standardization of jCal, the majority of 238 implementations and service providers either kept using iCalendar, or 239 came up with their own proprietary JSON representations, which are 240 incompatible with each other and often suffer from common pitfalls, 241 such as storing event start times in UTC (which become incorrect if 242 the timezone's rules change in the future). JSCalendar meets the 243 demand for JSON-formatted calendar data that is free of such known 244 problems and provides a standard representation as an alternative to 245 the proprietary formats. 247 1.2. Notational Conventions 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 251 "OPTIONAL" in this document are to be interpreted as described in BCP 252 14 [RFC2119] [RFC8174] when, and only when, they appear in all 253 capitals, as shown here. 255 The underlying format used for this specification is JSON. 256 Consequently, the terms "object" and "array" as well as the four 257 primitive types (strings, numbers, booleans, and null) are to be 258 interpreted as described in Section 1 of [RFC8259]. 260 Some examples in this document contain "partial" JSON documents used 261 for illustrative purposes. In these examples, three periods "..." 262 are used to indicate a portion of the document that has been removed 263 for compactness. 265 1.3. Type Signatures 267 Type signatures are given for all JSON values in this document. The 268 following conventions are used: 270 o "*" - The type is undefined (the value could be any type, although 271 permitted values may be constrained by the context of this value). 273 o "String" - The JSON string type. 275 o "Number" - The JSON number type. 277 o "Boolean" - The JSON boolean type. 279 o "A[B]" - A JSON object where the keys are all of type "A", and the 280 values are all of type "B". 282 o "A[]" - An array of values of type "A". 284 o "A|B" - The value is either of type "A" or of type "B". 286 Other types may also be given, with their representations defined 287 elsewhere in this document. 289 1.4. Data Types 291 In addition to the standard JSON data types, the following data types 292 are used in this specification: 294 1.4.1. Int 296 Where "Int" is given as a data type, it means an integer in the range 297 -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a 298 floating-point double, represented as a JSON "Number". 300 1.4.2. UnsignedInt 302 Where "UnsignedInt" is given as a data type, it means an integer in 303 the range 0 <= value <= 2^53-1, represented as a JSON "Number". 305 1.4.3. UTCDateTime 307 This is a string in [RFC3339] "date-time" format, with the further 308 restrictions that any letters MUST be in uppercase, the time 309 component MUST be included and the time offset MUST be the character 310 "Z". Fractional second values MUST NOT be included unless non-zero 311 and MUST NOT have trailing zeros, to ensure there is only a single 312 representation for each date-time. 314 For example "2010-10-10T10:10:10.003Z" is OK, but 315 "2010-10-10T10:10:10.000Z" is invalid and is correctly encoded as 316 "2010-10-10T10:10:10Z". 318 1.4.4. LocalDateTime 320 This is a date-time string with no time zone/offset information. It 321 is otherwise in the same format as UTCDateTime, including fractional 322 seconds. For example "2006-01-02T15:04:05" and 323 "2006-01-02T15:04:05.003" are both valid. The time zone to associate 324 the LocalDateTime with comes from an associated property, or if no 325 time zone is associated it defines "floating time". Floating date- 326 times are not tied to any specific time zone. Instead, they occur in 327 each time zone at the given wall-clock time (as opposed to the same 328 instant point in time). 330 1.4.5. Duration 332 Where Duration is given as a type, it means a length of time 333 represented by a subset of ISO8601 duration format, as specified by 334 the following ABNF [RFC5234]: 336 dur-secfrac = "." 1*DIGIT 337 dur-second = 1*DIGIT [dur-secfrac] "S" 338 dur-minute = 1*DIGIT "M" [dur-second] 339 dur-hour = 1*DIGIT "H" [dur-minute] 340 dur-time = "T" (dur-hour / dur-minute / dur-second) 341 dur-day = 1*DIGIT "D" 342 dur-week = 1*DIGIT "W" 344 duration = "P" (dur-day [dur-time] / dur-time / dur-week) 346 In addition, the duration MUST NOT include fractional second values 347 unless the fraction is non-zero. 349 1.4.6. SignedDuration 351 A SignedDuration represents a length of time that may be positive or 352 negative and is typically used to express the offset of a point in 353 time relative to an associated time. It is represented as a 354 Duration, optionally preceded by a sign character. It is specified 355 by the following ABNF: 357 signed-duration = ["+" / "-"] duration 359 A negative sign indicates a point in time at or before the associated 360 time, a positive or no sign a time at or after the associated time. 362 1.4.7. Id 364 Where "Id" is given as a data type, it means a "String" of at least 1 365 and a maximum of 255 octets in size, and it MUST only contain 366 characters from the "URL and Filename Safe" base64url alphabet, as 367 defined in Section 5 of [RFC4648], excluding the pad character ("="). 368 This means the allowed characters are the ASCII alphanumeric 369 characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). 371 Unless otherwise specified, Ids are arbitrary and only have meaning 372 within the object where they are being used. Ids need not be unique 373 among different objects. For example, two JSEvent objects might use 374 the same ids in their respective "links" properties. Or within the 375 same JSEvent object the same Id could appear in the "participants" 376 and "alerts" properties. These situations do not imply any semantic 377 connections among the objects. 379 Nevertheless, a UUID is typically a good choice. 381 1.4.8. PatchObject 383 A PatchObject is of type "String[*]", and represents an unordered set 384 of patches on a JSON object. Each key is a path represented in a 385 subset of JSON pointer format [RFC6901]. The paths have an implicit 386 leading "/", so each key is prefixed with "/" before applying the 387 JSON pointer evaluation algorithm. 389 A patch within a PatchObject is only valid if all of the following 390 conditions apply: 392 1. The pointer MUST NOT insert/delete from an array; the array MUST 393 be replaced in its entirety instead. 395 2. When evaluating a path, all parts prior to the last (i.e., the 396 value after the final slash) MUST exist. 398 3. There MUST NOT be two patches in the PatchObject where the 399 pointer of one is a prefix of the pointer of the other, e.g., 400 "alerts/foo/offset" and "alerts". 402 4. The value for the patch MUST be valid for the property being set 403 (of the correct type and obeying any other applicable 404 restrictions), or if null the property MUST be optional. 406 The value associated with each pointer is either: 408 o null: Remove the property at the given path from the patched 409 object. If the property is not present in the object, this a no- 410 op. 412 o Anything else: Set the value for the property to this value (this 413 may be a replacement or addition to the object being patched). 415 Implementations MUST reject in its entirety a PatchObject if any of 416 its patches is invalid. Implementations MUST NOT apply partial 417 patches. 419 1.4.9. Time Zones 421 By default, time zones in JSCalendar are identified by their names in 422 the IANA Time Zone Database [TZDB], and the zone rules of the 423 respective zone records apply. 425 Implementations MAY embed the definitions of custom time zones in the 426 "timeZones" property (see Section 4.7.2). 428 1.4.10. Relation 430 A Relation object defines the relation to other objects, using a 431 possibly empty set of relation types. The object that defines this 432 relation is the linking object, while the other object is the linked 433 object. The Relation object has the following properties: 435 o @type: "String" (mandatory) 437 Specifies the type of this object. This MUST be "Relation". 439 o relation: "String[Boolean]" (optional, default: empty Object) 441 Describes how the linked object is related to the linking object. 442 The relation is defined as a set of relation types. If empty, the 443 relationship between the two objects is unspecified. 445 Keys in the set MUST be one of the following values, or specified 446 in the property definition where the Relation object is used, or a 447 value registered in the IANA JSCalendar Enum Registry, or a 448 vendor-specific value: 450 * "first": The linked object is the first in a series the linking 451 object is part of. 453 * "next": The linked object is the next in a series the linking 454 object is part of. 456 * "child": The linked object is a subpart of the linking object. 458 * "parent": The linking object is a subpart of the linked object. 460 The value for each key in the set MUST be true. 462 2. JSCalendar Objects 464 This section describes the calendar object types specified by 465 JSCalendar. 467 2.1. JSEvent 469 Media type: "application/jscalendar+json;type=jsevent" 471 A JSEvent represents a scheduled amount of time on a calendar, 472 typically a meeting, appointment, reminder or anniversary. It is 473 required to start at a certain point in time and typically has a non- 474 zero duration. Multiple participants may partake in the event at 475 multiple locations. 477 The @type (Section 4.1.1) property value MUST be "jsevent". 479 2.2. JSTask 481 Media type: "application/jscalendar+json;type=jstask" 483 A JSTask represents an action-item, assignment, to-do or work item. 484 It may start and be due at certain points in time, may take some 485 estimated time to complete, and may recur, none of which is required. 487 The @type (Section 4.1.1) property value MUST be "jstask". 489 2.3. JSGroup 491 Media type: "application/jscalendar+json;type=jsgroup" 493 A JSGroup is a collection of JSEvent (Section 2.1) and/or JSTask 494 (Section 2.2) objects. Typically, objects are grouped by topic 495 (e.g., by keywords) or calendar membership. 497 The @type (Section 4.1.1) property value MUST be "jsgroup". 499 3. Structure of JSCalendar Objects 501 A JSCalendar object is a JSON object, which MUST be valid I-JSON (a 502 stricter subset of JSON), as specified in [RFC8259]. Property names 503 and values are case-sensitive. 505 The object has a collection of properties, as specified in the 506 following sections. Properties are specified as being either 507 mandatory or optional. Optional properties may have a default value, 508 if explicitly specified in the property definition. 510 3.1. Normalization and Equivalence 512 JSCalendar aims to provide unambiguous definitions for value types 513 and properties, but does not define a general normalization or 514 equivalence method for JSCalendar objects and types. This is because 515 the notion of equivalence might range from byte-level equivalence to 516 semantic equivalence, depending on the respective use case (for 517 example, the CalDAV protocol [RFC4791] requires octet equivalence of 518 the encoded calendar object to determine ETag equivalence). 520 Normalization of JSCalendar objects is hindered because of the 521 following reasons: 523 o Custom JSCalendar properties may contain arbitrary JSON values, 524 including arrays. However, equivalence of arrays might or might 525 not depend on the order of elements, depending on the respective 526 property definition. 528 o Several JSCalendar property values are defined as URIs and media 529 types, but normalization of these types is inherently protocol- 530 and scheme-specific, depending on the use-case of the equivalence 531 definition (see Section 6 of [RFC3986]). 533 Considering this, the definition of equivalence and normalization is 534 left to client and server implementations and to be negotiated by a 535 calendar exchange protocol or defined elsewhere. 537 3.2. Vendor-specific Property Extensions and Values 539 Vendors MAY add additional properties to the calendar object to 540 support their custom features. The names of these properties MUST be 541 prefixed with a domain name controlled by the vendor to avoid 542 conflict, e.g., "example.com/customprop". 544 Some JSCalendar properties allow vendor-specific value extensions. 545 Such vendor-specific values MUST be prefixed with a domain name 546 controlled by the vendor, e.g., "example.com/customrel". 548 Vendors are strongly encouraged to register any new property values 549 or extensions that are useful to other systems as well, rather than 550 use a vendor-specific prefix. 552 4. Common JSCalendar Properties 554 This section describes the properties that are common to the various 555 JSCalendar object types. Specific JSCalendar object types may only 556 support a subset of these properties. The object type definitions in 557 Section 5 describe the set of supported properties per type. 559 4.1. Metadata Properties 561 4.1.1. @type 563 Type: "String" (mandatory). 565 Specifies the type which this object represents. This MUST be one of 566 the following values: 568 o "jsevent": a JSCalendar event (Section 2.1). 570 o "jstask": a JSCalendar task (Section 2.2). 572 o "jsgroup": a JSCalendar group (Section 2.3). 574 4.1.2. uid 576 Type: "String" (mandatory). 578 A globally unique identifier, used to associate the object as the 579 same across different systems, calendars and views. The value of 580 this property MUST be unique across all JSCalendar objects, even if 581 they are of different type. [RFC4122] describes a range of 582 established algorithms to generate universally unique identifiers 583 (UUID). UUID version 4, described in Section 4.4 of [RFC4122], is 584 RECOMMENDED. 586 For compatibility with [RFC5545] UIDs, implementations MUST be able 587 to receive and persist values of at least 255 octets for this 588 property, but they MUST NOT truncate values in the middle of a UTF-8 589 multi-octet sequence. 591 4.1.3. relatedTo 593 Type: "String[Relation]" (optional). 595 Relates the object to other JSCalendar objects. This is represented 596 as a map of the UIDs of the related objects to information about the 597 relation. 599 If an object is split to make a "this and future" change to a 600 recurrence, the original object MUST be truncated to end at the 601 previous occurrence before this split, and a new object created to 602 represent all the occurrences after the split. A "next" relation 603 MUST be set on the original object's relatedTo property for the UID 604 of the new object. A "first" relation for the UID of the first 605 object in the series MUST be set on the new object. Clients can then 606 follow these UIDs to get the complete set of objects if the user 607 wishes to modify them all at once. 609 4.1.4. prodId 611 Type: "String" (optional). 613 The identifier for the product that last updated the JSCalendar 614 object. This should be set whenever the data in the object is 615 modified (i.e., whenever the "updated" property is set). 617 The vendor of the implementation SHOULD ensure that this is a 618 globally unique identifier, using some technique such as an FPI 619 value, as defined in [ISO.9070.1991]. It MUST only use characters of 620 an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]). 622 This property SHOULD NOT be used to alter the interpretation of a 623 JSCalendar object beyond the semantics specified in this document. 624 For example, it is not to be used to further the understanding of 625 non-standard properties, a practice that is knows to cause long-term 626 interoperability problems. 628 4.1.5. created 630 Type: "UTCDateTime" (optional). 632 The date and time this object was initially created. 634 4.1.6. updated 636 Type: "UTCDateTime" (mandatory). 638 The date and time the data in this object was last modified (or its 639 creation date/time if not modified since). 641 4.1.7. sequence 643 Type: "UnsignedInt" (optional, default: 0). 645 Initially zero, this MUST be incremented by one every time a change 646 is made to the object, except if the change only modifies the 647 "participants" property (see Section 4.4.5). 649 This is used as part of iTIP [RFC5546] to know which version of the 650 object a scheduling message relates to. 652 4.1.8. method 654 Type: "String" (optional). 656 The iTIP [RFC5546] method, in lowercase. This MUST only be present 657 if the JSCalendar object represents an iTIP scheduling message. 659 4.2. What and Where Properties 661 4.2.1. title 663 Type: "String" (optional, default: empty String). 665 A short summary of the object. 667 4.2.2. description 669 Type: "String" (optional, default: empty String). 671 A longer-form text description of the object. The content is 672 formatted according to the "descriptionContentType" property. 674 4.2.3. descriptionContentType 676 Type: "String" (optional, default: "text/plain"). 678 Describes the media type [RFC6838] of the contents of the 679 "description" property. Media types MUST be sub-types of type 680 "text", and SHOULD be "text/plain" or "text/html" [MIME]. They MAY 681 include parameters and the "charset" parameter value MUST be "utf-8", 682 if specified. Descriptions of type "text/html" MAY contain "cid" 683 URLs [RFC2392] to reference links in the calendar object by use of 684 the "cid" property of the Link object. 686 4.2.4. showWithoutTime 688 Type: "Boolean" (optional, default: false). 690 Indicates that the time is not important to display to the user when 691 rendering this calendar object. An example of this is an event that 692 conceptually occurs all day or across multiple days, such as "New 693 Year's Day" or "Italy Vacation". While the time component is 694 important for free-busy calculations and checking for scheduling 695 clashes, calendars may choose to omit displaying it and/or display 696 the object separately to other objects to enhance the user's view of 697 their schedule. 699 Such events are also commonly known as "all-day" events. 701 4.2.5. locations 703 Type: "Id[Location]" (optional). 705 A map of location ids to Location objects, representing locations 706 associated with the object. 708 A Location object has the following properties. It MUST have at 709 least one property other than the "relativeTo" property. 711 o @type: "String" (mandatory) 713 Specifies the type of this object. This MUST be "Location". 715 o name: "String" (optional) 717 The human-readable name of the location. 719 o description: "String" (optional) 721 Human-readable, plain-text instructions for accessing this 722 location. This may be an address, set of directions, door access 723 code, etc. 725 o locationTypes: "String[Boolean]" (optional) 727 A set of one or more location types that describe this location. 728 All types MUST be from the Location Types Registry [LOCATIONTYPES] 729 as defined in [RFC4589]. The set is represented as a map, with 730 the keys being the location types. The value for each key in the 731 map MUST be true. 733 o relativeTo: "String" (optional) 735 Specifies the relation between this location and the time of the 736 JSCalendar object. This is primarily to allow events representing 737 travel to specify the location of departure (at the start of the 738 event) and location of arrival (at the end); this is particularly 739 important if these locations are in different time zones, as a 740 client may wish to highlight this information for the user. 742 This MUST be one of the following values, a value registered in 743 the IANA JSCalendar Enum Registry, or a vendor-specific value. 744 Any value the client or server doesn't understand should be 745 treated the same as if this property is omitted. 747 * "start": The event/task described by this JSCalendar object 748 occurs at this location at the time the event/task starts. 750 * "end": The event/task described by this JSCalendar object 751 occurs at this location at the time the event/task ends. 753 o timeZone: "String" (optional) 755 A time zone for this location. See also Section 1.4.9. 757 o coordinates: "String" (optional) 759 A "geo:" URI [RFC5870] for the location. 761 o linkIds: "Id[Boolean]" (optional) 762 A set of link ids for links to alternative representations of this 763 location. Each key in the set MUST be the id of a Link object 764 defined in the "links" property of this calendar object. The 765 value for each key in the set MUST be true. If there are no 766 links, this MUST be omitted (rather than specified as an empty 767 set). 769 For example, an alternative representation could be in vCard 770 format. 772 4.2.6. virtualLocations 774 Type: "Id[VirtualLocation]" (optional). 776 A map of ids to VirtualLocation objects, representing virtual 777 locations, such as video conferences or chat rooms, associated with 778 the object. 780 A VirtualLocation object has the following properties. 782 o @type: "String" (mandatory) 784 Specifies the type of this object. This MUST be 785 "VirtualLocation". 787 o name: "String" (optional, default: empty String) 789 The human-readable name of the virtual location. 791 o description: "String" (optional) 793 Human-readable plain-text instructions for accessing this 794 location. This may be an address, set of directions, door access 795 code, etc. 797 o uri: "String" (mandatory) 799 A URI that represents how to connect to this virtual location. 801 This may be a telephone number (represented using the "tel:" 802 scheme, e.g., "tel:+1-555-555-555") for a teleconference, a web 803 address for online chat, or any custom URI. 805 4.2.7. links 807 Type: "Id[Link]" (optional). 809 A map of link ids to Link objects, representing external resources 810 associated with the object. 812 A Link object has the following properties: 814 o @type: "String" (mandatory) 816 Specifies the type of this object. This MUST be "Link". 818 o href: "String" (mandatory) 820 A URI from which the resource may be fetched. 822 This MAY be a "data:" URL [RFC2397], but it is recommended that 823 the file be hosted on a server to avoid embedding arbitrarily 824 large data in JSCalendar object instances. 826 o cid: "String" (optional) 828 This MUST be a valid "content-id" value according to the 829 definition of Section 2 in [RFC2392]. The value MUST be unique 830 within this Link object but has no meaning beyond that. It MAY be 831 different from the link id for this Link object. 833 o contentType: "String" (optional) 835 The media type [RFC6838] of the resource, if known. 837 o size: "UnsignedInt" (optional) 839 The size, in octets, of the resource when fully decoded (i.e., the 840 number of octets in the file the user would download), if known. 841 Note that this is an informational estimate, and implementations 842 must be prepared to handle the actual size being quite different 843 when the resource is fetched. 845 o rel: "String" (optional) 847 Identifies the relation of the linked resource to the object. If 848 set, the value MUST be a relation type from the IANA registry 849 [LINKRELS], as established in [RFC8288]. 851 Links with a rel of "enclosure" SHOULD be considered by the client 852 as attachments for download. 854 Links with a rel of "describedby" SHOULD be considered by the 855 client to be an alternative representation of the description. 857 Links with a rel of "icon" SHOULD be considered by the client to 858 be an image that it may use when presenting the calendar data to a 859 user. The "display" property may be set to indicate the purpose 860 of this image. 862 o display: "String" (optional) 864 Describes the intended purpose of a link to an image. If set, the 865 "rel" property MUST be set to "icon". The value MUST be one of 866 the following values, a value registered in the IANA JSCalendar 867 Enum Registry, or a vendor-specific value: 869 * "badge": an image meant to be displayed alongside the title of 870 the object. 872 * "graphic": a full image replacement for the object itself. 874 * "fullsize": an image that is used to enhance the object. 876 * "thumbnail": a smaller variant of "fullsize" to be used when 877 space for the image is constrained. 879 o title: "String" (optional) 881 A human-readable plain-text description of the resource. 883 4.2.8. locale 885 Type: "String" (optional). 887 The language tag as defined in [RFC5646] that best describes the 888 locale used for the text in the calendar object, if known. 890 4.2.9. keywords 892 Type: "String[Boolean]" (optional). 894 A set of keywords or tags that relate to the object. The set is 895 represented as a map, with the keys being the keywords. The value 896 for each key in the map MUST be true. 898 4.2.10. categories 900 Type: "String[Boolean]" (optional). 902 A set of categories that relate to the calendar object. The set is 903 represented as a map, with the keys being the categories specified as 904 URIs. The value for each key in the map MUST be true. 906 In contrast to keywords, categories typically are structured. For 907 example, a vendor owning the domain "example.com" might define the 908 categories "http://example.com/categories/sports/american-football" 909 and "http://example.com/categories/music/r-b". 911 4.2.11. color 913 Type: "String" (optional). 915 A color clients MAY use when displaying this calendar object. The 916 value is a color name taken from the set of names defined in 917 Section 4.3 of CSS Color Module Level 3 [COLORS], or an RGB value in 918 hexadecimal notation, as defined in Section 4.2.1 of CSS Color Module 919 Level 3. 921 4.3. Recurrence Properties 923 Some events and tasks occur at regular or irregular intervals. 924 Rather than having to copy the data for every occurrence there can be 925 a master event with a recurrence rule, and/or overrides that add 926 extra dates or exceptions to the rule. 928 4.3.1. recurrenceId 930 Type: "LocalDateTime" (optional). 932 If present, this JSCalendar object represents one occurrence of a 933 recurring JSCalendar object. If present the "recurrenceRules" and 934 "recurrenceOverrides" properties MUST NOT be present. 936 The value is a date-time either produced by the "recurrenceRules" of 937 the master event, or added as a key to the "recurrenceOverrides" 938 property of the master event. 940 4.3.2. recurrenceRules 942 Type: "RecurrenceRule[]" (optional). 944 Defines a set of recurrence rules (repeating patterns) for recurring 945 calendar objects. 947 A JSEvent recurs by applying the recurrence rules to the "start" 948 date-time. 950 A JSTask recurs by applying the recurrence rules to the "start" date- 951 time, if defined, otherwise it recurs by the "due" date-time, if 952 defined. If the task defines neither a "start" nor "due" date-time, 953 it MUST NOT define a "recurrenceRules" property. 955 If multiple recurrence rules are given, each rule is to be applied 956 and then the union of the results used, ignoring any duplicates. 958 A RecurrenceRule object is a JSON object mapping of a RECUR value 959 type in iCalendar [RFC5545] [RFC7529] and has the same semantics. It 960 has the following properties: 962 o @type: "String" (mandatory) 964 Specifies the type of this object. This MUST be "RecurrenceRule". 966 o frequency: "String" (mandatory) 968 The time span covered by each iteration of this recurrence rule 969 (see Section 4.3.2.1 for full semantics). This MUST be one of the 970 following values: 972 * "yearly" 974 * "monthly" 976 * "weekly" 978 * "daily" 980 * "hourly" 982 * "minutely" 984 * "secondly" 986 This is the FREQ part from iCalendar, converted to lowercase. 988 o interval: "UnsignedInt" (optional, default: 1) 990 The interval of iteration periods at which the recurrence repeats. 991 If included, it MUST be an integer >= 1. 993 This is the INTERVAL part from iCalendar. 995 o rscale: "String" (optional, default: "gregorian") 997 The calendar system in which this recurrence rule operates, in 998 lowercase. This MUST be either a CLDR-registered calendar system 999 name [CLDR], or a vendor-specific value. 1001 This is the RSCALE part from iCalendar RSCALE [RFC7529], converted 1002 to lowercase. 1004 o skip: "String" (optional, default: "omit") 1006 The behaviour to use when the expansion of the recurrence produces 1007 invalid dates. This property only has an effect if the frequency 1008 is "yearly" or "monthly". It MUST be one of the following values: 1010 * "omit" 1012 * "backward" 1014 * "forward" 1016 This is the SKIP part from iCalendar RSCALE [RFC7529], converted 1017 to lowercase. 1019 o firstDayOfWeek: "String" (optional, default: "mo") 1021 The day on which the week is considered to start, represented as a 1022 lowercase abbreviated two-letter English day of the week. If 1023 included, it MUST be one of the following values: 1025 * "mo" 1027 * "tu" 1029 * "we" 1031 * "th" 1033 * "fr" 1035 * "sa" 1037 * "su" 1039 This is the WKST part from iCalendar. 1041 o byDay: "NDay[]" (optional) 1043 Days of the week on which to repeat. An "NDay" object has the 1044 following properties: 1046 * day: "String" (mandatory) 1048 A day of the week on which to repeat; the allowed values are 1049 the same as for the "firstDayOfWeek" RecurrenceRule property. 1051 This is the day-of-the-week of the BYDAY part in iCalendar, 1052 converted to lowercase. 1054 * nthOfPeriod: "Int" (optional) 1056 If present, rather than representing every occurrence of the 1057 weekday defined in the "day" property, it represents only a 1058 specific instance within the recurrence period. The value can 1059 be positive or negative, but MUST NOT be zero. A negative 1060 integer means nth-last of period. 1062 This is the ordinal part of the BYDAY value in iCalendar (e.g., 1063 1 or -3). 1065 o byMonthDay: "Int[]" (optional) 1067 Days of the month on which to repeat. Valid values are between 1 1068 and the maximum number of days any month may have in the calendar 1069 given by the "rscale" property, and the negative values of these 1070 numbers. For example, in the Gregorian calendar valid values are 1071 1 to 31 and -31 to -1. Negative values offset from the end of the 1072 month. The array MUST have at least one entry if included. 1074 This is the BYMONTHDAY part in iCalendar. 1076 o byMonth: "String[]" (optional) 1078 The months in which to repeat. Each entry is a string 1079 representation of a number, starting from "1" for the first month 1080 in the calendar (e.g., "1" means January with the Gregorian 1081 calendar), with an optional "L" suffix (see [RFC7529]) for leap 1082 months (this MUST be uppercase, e.g., "3L"). The array MUST have 1083 at least one entry if included. 1085 This is the BYMONTH part from iCalendar. 1087 o byYearDay: "Int[]" (optional) 1089 The days of the year on which to repeat. Valid values are between 1090 1 and the maximum number of days any year may have in the calendar 1091 given by the "rscale" property, and the negative values of these 1092 numbers. For example, in the Gregorian calendar valid values are 1093 1 to 366 and -366 to -1. Negative values offset from the end of 1094 the year. The array MUST have at least one entry if included. 1096 This is the BYYEARDAY part from iCalendar. 1098 o byWeekNo: "Int[]" (optional) 1099 Weeks of the year in which to repeat. Valid values are between 1 1100 and the maximum number of weeks any year may have in the calendar 1101 given by the "rscale" property, and the negative values of these 1102 numbers. For example, in the Gregorian calendar valid values are 1103 1 to 53 and -53 to -1. The array MUST have at least one entry if 1104 included. 1106 This is the BYWEEKNO part from iCalendar. 1108 o byHour: "UnsignedInt[]" (optional) 1110 The hours of the day in which to repeat. Valid values are 0 to 1111 23. The array MUST have at least one entry if included. This is 1112 the BYHOUR part from iCalendar. 1114 o byMinute: "UnsignedInt[]" (optional) 1116 The minutes of the hour in which to repeat. Valid values are 0 to 1117 59. The array MUST have at least one entry if included. 1119 This is the BYMINUTE part from iCalendar. 1121 o bySecond: "UnsignedInt[]" (optional) 1123 The seconds of the minute in which to repeat. Valid values are 0 1124 to 60. The array MUST have at least one entry if included. 1126 This is the BYSECOND part from iCalendar. 1128 o bySetPosition: "Int[]" (optional) 1130 The occurrences within the recurrence interval to include in the 1131 final results. Negative values offset from the end of the list of 1132 occurrences. The array MUST have at least one entry if included. 1133 This is the BYSETPOS part from iCalendar. 1135 o count: "UnsignedInt" (optional) 1137 The number of occurrences at which to range-bound the recurrence. 1138 This MUST NOT be included if an "until" property is specified. 1140 This is the COUNT part from iCalendar. 1142 o until: "LocalDateTime" (optional) 1144 The date-time at which to finish recurring. The last occurrence 1145 is on or before this date-time. This MUST NOT be included if a 1146 "count" property is specified. Note: if not specified otherwise 1147 for a specific JSCalendar object, this date is to be interpreted 1148 in the time zone specified in the JSCalendar object's "timeZone" 1149 property. 1151 This is the UNTIL part from iCalendar. 1153 4.3.2.1. Interpreting recurrence rules 1155 A recurrence rule specifies a set of date-times for recurring 1156 calendar objects. A recurrence rule has the following semantics. 1157 Note, wherever "year", "month" or "day of month" is used, this is 1158 within the calendar system given by the "rscale" property, which 1159 defaults to "gregorian" if omitted. 1161 1. A set of candidates is generated. This is every second within a 1162 period defined by the frequency property value: 1164 * "yearly": every second from midnight on the 1st day of a year 1165 (inclusive) to midnight the 1st day of the following year 1166 (exclusive). 1168 If skip is not "omit", the calendar system has leap months and 1169 there is a byMonth property, generate candidates for the leap 1170 months even if they don't occur in this year. 1172 If skip is not "omit" and there is a byMonthDay property, 1173 presume each month has the maximum number of days any month 1174 may have in this calendar system when generating candidates, 1175 even if it's more than this month actually has. 1177 * "monthly": every second from midnight on the 1st day of a 1178 month (inclusive) to midnight on the 1st of the following 1179 month (exclusive). 1181 If skip is not "omit" and there is a byMonthDay property, 1182 presume the month has the maximum number of days any month may 1183 have in this calendar system when generating candidates, even 1184 if it's more than this month actually has. 1186 * "weekly": every second from midnight (inclusive) on the first 1187 day of the week (as defined by the firstDayOfWeek property, or 1188 Monday if omitted), to midnight 7 days later (exclusive). 1190 * "daily": every second from midnight at the start of the day 1191 (inclusive) to midnight at the end of the day (exclusive). 1193 * "hourly": every second from the beginning of the hour 1194 (inclusive) to the beginning of the next hour (exclusive). 1196 * "minutely": every second from the beginning of the minute 1197 (inclusive) to the beginning of the next minute (exclusive). 1199 * "secondly": the second itself, only. 1201 2. Each date-time candidate is compared against all of the byX 1202 properties of the rule except bySetPosition. If any property in 1203 the rule does not match the date-time, it is eliminated. Each 1204 byX property is an array; the date-time matches the property if 1205 it matches any of the values in the array. The properties have 1206 the following semantics: 1208 * byMonth: the date-time is in the given month. 1210 * byWeekNo: the date-time is in the nth week of the year. 1211 Negative numbers mean the nth last week of the year. This 1212 corresponds to weeks according to week numbering as defined in 1213 ISO.8601.2004, with a week defined as a seven day period, 1214 starting on the firstDayOfWeek property value or Monday if 1215 omitted. Week number one of the calendar year is the first 1216 week that contains at least four days in that calendar year. 1218 If the date-time is not valid (this may happen when generating 1219 candidates with a skip property in effect), it is always 1220 eliminated by this property. 1222 * byYearDay: the date-time is on the nth day of year. Negative 1223 numbers mean the nth last day of the year. 1225 If the date-time is not valid (this may happen when generating 1226 candidates with a skip property in effect), it is always 1227 eliminated by this property. 1229 * byMonthDay: the date-time is on the given day of the month. 1230 Negative numbers mean the nth last day of the month. 1232 * byDay: the date-time is on the given day of the week. If the 1233 day is prefixed by a number, it is the nth occurrence of that 1234 day of the week within the month (if frequency is monthly) or 1235 year (if frequency is yearly). Negative numbers means nth 1236 last occurrence within that period. 1238 * byHour: the date-time has the given hour value. 1240 * byMinute: the date-time has the given minute value. 1242 * bySecond: the date-time has the given second value. 1244 If a skip property is defined and is not "omit", there may be 1245 candidates that do not correspond to valid dates (e.g., 31st 1246 February in the Gregorian calendar). In this case, the 1247 properties MUST be considered in the order above and: 1249 1. After applying the byMonth filter, if the candidate's month 1250 is invalid for the given year, increment it (if skip is 1251 "forward") or decrement it (if skip is "backward") until a 1252 valid month is found, incrementing/decrementing the year as 1253 well if passing through the beginning/end of the year. This 1254 only applies to calendar systems with leap months. 1256 2. After applying the byMonthDay filter, if the day of the month 1257 is invalid for the given month and year, change the date to 1258 the first day of the next month (if skip is "forward") or the 1259 last day of the current month (if skip is "backward"). 1261 3. If any valid date produced after applying the skip is already 1262 a candidate, eliminate the duplicate. (For example after 1263 adjusting, 30th February and 31st February would both become 1264 the same "real" date, so one is eliminated as a duplicate.) 1266 3. If a bySetPosition property is included, this is now applied to 1267 the ordered list of remaining dates. This property specifies the 1268 indexes of date-times to keep; all others should be eliminated. 1269 Negative numbers are indexes from the end of the list, with -1 1270 being the last item. 1272 4. Any date-times before the start date of the event are eliminated 1273 (see below for why this might be needed). 1275 5. If a skip property is included and is not "omit", eliminate any 1276 date-times that have already been produced by previous iterations 1277 of the algorithm. (This is not possible if skip is "omit".) 1279 6. If further dates are required (we have not reached the until 1280 date, or count limit) skip the next (interval - 1) sets of 1281 candidates, then continue from step 1. 1283 When determining the set of occurrence dates for an event or task, 1284 the following extra rules must be applied: 1286 1. The initial date-time to which the rule is applied (the "start" 1287 date-time for events; the "start" or "due" date-time for tasks) 1288 is always the first occurrence in the expansion (and is counted 1289 if the recurrence is limited by a "count" property), even if it 1290 would normally not match the rule. 1292 2. The first set of candidates to consider is that which would 1293 contain the initial date-time. This means the first set may 1294 include candidates before the initial date-time; such candidates 1295 are eliminated from the results in step (4) as outlined before. 1297 3. The following properties MUST be implicitly added to the rule 1298 under the given conditions: 1300 * If frequency is not "secondly" and no bySecond property: Add a 1301 bySecond property with the sole value being the seconds value 1302 of the initial date-time. 1304 * If frequency is not "secondly" or "minutely", and no byMinute 1305 property: Add a byMinute property with the sole value being 1306 the minutes value of the initial date-time. 1308 * If frequency is not "secondly", "minutely" or "hourly" and no 1309 byHour property: Add a byHour property with the sole value 1310 being the hours value of the initial date-time. 1312 * If frequency is "weekly" and no byDay property: Add a byDay 1313 property with the sole value being the day-of-the-week of the 1314 initial date-time. 1316 * If frequency is "monthly" and no byDay property and no 1317 byMonthDay property: Add a byMonthDay property with the sole 1318 value being the day-of-the-month of the initial date-time. 1320 * If frequency is "yearly" and no byYearDay property: 1322 + If there are no byMonth or byWeekNo properties, and either 1323 there is a byMonthDay property or there is no byDay 1324 property: Add a byMonth property with the sole value being 1325 the month of the initial date-time. 1327 + If there is no byMonthDay, byWeekNo or byDay properties: 1328 Add a byMonthDay property with the sole value being the 1329 day-of-the-month of the initial date-time. 1331 + If there is a byWeekNo property and no byMonthDay or byDay 1332 properties: Add a byDay property with the sole value being 1333 the day-of-the-week of the initial date-time. 1335 4.3.3. recurrenceOverrides 1337 Type: "LocalDateTime[PatchObject]" (optional). 1339 A map of the recurrence ids (the date-time produced by the recurrence 1340 rule) to an object of patches to apply to the generated occurrence 1341 object. 1343 If the recurrence id does not match a date-time from the recurrence 1344 rule (or no rule is specified), it is to be treated as an additional 1345 occurrence (like an RDATE from iCalendar). The patch object may 1346 often be empty in this case. 1348 If the patch object defines the "excluded" property value to be true, 1349 then the recurring calendar object does not occur at the recurrence 1350 id date-time (like an EXDATE from iCalendar). Such a patch object 1351 MUST NOT patch any other property. 1353 By default, an occurrence inherits all properties from the main 1354 object except the start (or due) date-time, which is shifted to match 1355 the recurrence id LocalDateTime. However, individual properties of 1356 the occurrence can be modified by a patch, or multiple patches. It 1357 is valid to patch the "start" property value, and this patch takes 1358 precedence over the value generated from the recurrence id. Both the 1359 recurrence id as well as the patched "start" date-time may occur 1360 before the original JSCalendar object's "start" or "due" date. 1362 A pointer in the PatchObject MUST be ignored if it starts with one of 1363 the following prefixes: 1365 o @type 1367 o method 1369 o privacy 1371 o prodId 1373 o recurrenceId 1375 o recurrenceOverrides 1377 o recurrenceRules 1379 o relatedTo 1381 o replyTo 1383 o uid 1385 4.3.4. excluded 1387 Type: "Boolean" (optional, default: false). 1389 Defines if this object is an overridden, excluded instance of a 1390 recurring JSCalendar object (see Section 4.3.3). If this property 1391 value is true, this calendar object instance MUST be removed from the 1392 occurrence expansion. The absence of this property or its default 1393 value false indicates that this instance MUST be included in the 1394 occurrence expansion. 1396 4.4. Sharing and Scheduling Properties 1398 4.4.1. priority 1400 Type: "Int" (optional, default: 0). 1402 Specifies a priority for the calendar object. This may be used as 1403 part of scheduling systems to help resolve conflicts for a time 1404 period. 1406 The priority is specified as an integer in the range 0 to 9. A value 1407 of 0 specifies an undefined priority, for which the treatment will 1408 vary by situation. A value of 1 is the highest priority. A value of 1409 2 is the second highest priority. Subsequent numbers specify a 1410 decreasing ordinal priority. A value of 9 is the lowest priority. 1411 Other integer values are reserved for future use. 1413 4.4.2. freeBusyStatus 1415 Type: "String" (optional, default: "busy"). 1417 Specifies how this calendar object should be treated when calculating 1418 free-busy state. This MUST be one of the following values, a value 1419 registered in the IANA JSCalendar Enum Registry, or a vendor-specific 1420 value: 1422 o "free": The object should be ignored when calculating whether the 1423 user is busy. 1425 o "busy": The object should be included when calculating whether the 1426 user is busy. 1428 4.4.3. privacy 1430 Type: "String" (optional, default: "public"). 1432 Calendar objects are normally collected together and may be shared 1433 with other users. The privacy property allows the object owner to 1434 indicate that it should not be shared, or should only have the time 1435 information shared but the details withheld. Enforcement of the 1436 restrictions indicated by this property are up to the API via which 1437 this object is accessed. 1439 This property MUST NOT affect the information sent to scheduled 1440 participants; it is only interpreted when the object is shared as 1441 part of a shared calendar. 1443 The value MUST be one of the following values, a value registered in 1444 the IANA JSCalendar Enum Registry, or a vendor-specific value. Any 1445 value the client or server doesn't understand should be preserved but 1446 treated as equivalent to "private". 1448 o "public": The full details of the object are visible to those whom 1449 the object's calendar is shared with. 1451 o "private": The details of the object are hidden; only the basic 1452 time and metadata is shared. The following properties MAY be 1453 shared, any other properties MUST NOT be shared: 1455 * @type 1457 * created 1459 * due 1461 * duration 1463 * estimatedDuration 1465 * freeBusyStatus 1467 * privacy 1469 * recurrenceOverrides. Only patches which apply to another 1470 permissible property are allowed to be shared. 1472 * sequence 1474 * showWithoutTime 1476 * start 1478 * timeZone 1479 * timeZones 1481 * uid 1483 * updated 1485 o "secret": The object is hidden completely (as though it did not 1486 exist) when the calendar this object is in is shared. 1488 4.4.4. replyTo 1490 Type: "String[String]" (optional). 1492 Represents methods by which participants may submit their RSVP 1493 response to the organizer of the calendar object. The keys in the 1494 property value are the available methods and MUST only contain ASCII 1495 alphanumeric characters (A-Za-z0-9). The value is a URI for the 1496 method specified in the key. Future methods may be defined in future 1497 specifications and registered with IANA; a calendar client MUST 1498 ignore any method it does not understand, but MUST preserve the 1499 method key and URI. This property MUST be omitted if no method is 1500 defined (rather than being specified as an empty object). If this 1501 property is set, the "participants" property of this calendar object 1502 MUST contain at least one participant. 1504 The following methods are defined: 1506 o "imip": The organizer accepts an iMIP [RFC6047] response at this 1507 email address. The value MUST be a "mailto:" URI. 1509 o "web": Opening this URI in a web browser will provide the user 1510 with a page where they can submit a reply to the organizer. 1512 o "other": The organizer is identified by this URI but the method 1513 for submitting the response is undefined. 1515 4.4.5. participants 1517 Type: "Id[Participant]" (optional). 1519 A map of participant ids to participants, describing their 1520 participation in the calendar object. 1522 If this property is set, then the "replyTo" property of this calendar 1523 object MUST define at least one reply method. 1525 A Participant object has the following properties: 1527 o @type: "String" (mandatory) 1529 Specifies the type of this object. This MUST be "Participant". 1531 o name: "String" (optional) 1533 The display name of the participant (e.g., "Joe Bloggs"). 1535 o email: "String" (optional) 1537 The email address for the participant. 1539 o sendTo: "String[String]" (optional) 1541 Represents methods by which the participant may receive the 1542 invitation and updates to the calendar object. 1544 The keys in the property value are the available methods and MUST 1545 only contain ASCII alphanumeric characters (A-Za-z0-9). The value 1546 is a URI for the method specified in the key. Future methods may 1547 be defined in future specifications and registered with IANA; a 1548 calendar client MUST ignore any method it does not understand, but 1549 MUST preserve the method key and URI. This property MUST be 1550 omitted if no method is defined (rather than being specified as an 1551 empty object). 1553 The following methods are defined: 1555 * "imip": The participant accepts an iMIP [RFC6047] request at 1556 this email address. The value MUST be a "mailto:" URI. It MAY 1557 be different from the value of the participant's "email" 1558 property. 1560 * "other": The participant is identified by this URI but the 1561 method for submitting the invitation is undefined. 1563 o kind: "String" (optional) 1565 What kind of entity this participant is, if known. 1567 This MUST be one of the following values, a value registered in 1568 the IANA JSCalendar Enum Registry, or a vendor-specific value. 1569 Any value the client or server doesn't understand should be 1570 treated the same as if this property is omitted. 1572 * "individual": a single person 1574 * "group": a collection of people invited as a whole 1575 * "location": a physical location that needs to be scheduled, 1576 e.g., a conference room 1578 * "resource": a non-human resource other than a location, such as 1579 a projector 1581 o roles: "String[Boolean]" (mandatory) 1583 A set of roles that this participant fulfills. 1585 At least one role MUST be specified for the participant. The keys 1586 in the set MUST be one of the following values, a value registered 1587 in the IANA JSCalendar Enum Registry, or a vendor-specific value: 1589 * "owner": The participant is an owner of the object. This 1590 signifies they have permission to make changes to it that 1591 affect the other participants. Non-owner participants may only 1592 change properties that just affect themself (for example 1593 setting their own alerts or changing their rsvp status). 1595 * "attendee": The participant is expected to attend. 1597 * "optional": The participant is invited but not required. 1599 * "informational": The participant is copied for informational 1600 reasons, and is not expected to attend. 1602 * "chair": The participant is in charge of the event/task when it 1603 occurs. 1605 The value for each key in the set MUST be true. It is expected 1606 that no more than one of the roles "attendee", "optional", or 1607 "informational" be present; if more than one are given, "optional" 1608 takes precedence over "informational", and "attendee" takes 1609 precedence over both. Roles that are unknown to the 1610 implementation MUST be preserved. 1612 o locationId: "String" (optional) 1614 The location at which this participant is expected to be 1615 attending. 1617 If the value does not correspond to any location id in the 1618 "locations" property of the JSCalendar object, this MUST be 1619 treated the same as if the participant's locationId were omitted. 1621 o language: "String" (optional) 1622 The language tag as defined in [RFC5646] that best describes the 1623 participant's preferred language, if known. 1625 o participationStatus: "String" (optional, default: "needs-action") 1627 The participation status, if any, of this participant. 1629 The value MUST be one of the following values, a value registered 1630 in the IANA JSCalendar Enum Registry, or a vendor-specific value: 1632 * "needs-action": No status yet set by the participant. 1634 * "accepted": The invited participant will participate. 1636 * "declined": The invited participant will not participate. 1638 * "tentative": The invited participant may participate. 1640 * "delegated": The invited participant has delegated their 1641 attendance to another participant, as specified in the 1642 delegatedTo property. 1644 o participationComment: "String" (optional) 1646 A note from the participant to explain their participation status. 1648 o expectReply: "Boolean" (optional, default: false) 1650 If true, the organizer is expecting the participant to notify them 1651 of their participation status. 1653 o scheduleAgent: "String" (optional, default: "server") 1655 Who is responsible for sending scheduling messages with this 1656 calendar object to the participant. 1658 The value MUST be one of the following values, a value registered 1659 in the IANA JSCalendar Enum Registry, or a vendor-specific value: 1661 * "server": The calendar server will send the scheduling 1662 messages. 1664 * "client": The calendar client will send the scheduling 1665 messages. 1667 * "none": No scheduling messages are to be sent to this 1668 participant. 1670 o scheduleSequence: "UnsignedInt" (optional, default: 0) 1672 The sequence number of the last response from the participant. If 1673 defined, this MUST be a non-negative integer. 1675 This can be used to determine whether the participant has sent a 1676 new RSVP following significant changes to the calendar object, and 1677 to determine if future responses are responding to a current or 1678 older view of the data. 1680 o scheduleUpdated: "UTCDateTime" (optional) 1682 The timestamp for the most recent response from this participant. 1684 This is the "updated" property of the last response when using 1685 iTIP. It can be compared to the "updated" property in future 1686 responses to detect and discard older responses delivered out of 1687 order. 1689 o invitedBy: "String" (optional) 1691 The participant id of the participant who invited this one, if 1692 known. 1694 o delegatedTo: "String[Boolean]" (optional) 1696 A set of participant ids that this participant has delegated their 1697 participation to. Each key in the set MUST be the id of a 1698 participant. The value for each key in the set MUST be true. If 1699 there are no delegates, this MUST be omitted (rather than 1700 specified as an empty set). 1702 o delegatedFrom: "String[Boolean]" (optional) 1704 A set of participant ids that this participant is acting as a 1705 delegate for. Each key in the set MUST be the id of a 1706 participant. The value for each key in the set MUST be true. If 1707 there are no delegators, this MUST be omitted (rather than 1708 specified as an empty set). 1710 o memberOf: "String[Boolean]" (optional) 1712 A set of group participants that were invited to this calendar 1713 object, which caused this participant to be invited due to their 1714 membership in the group(s). Each key in the set MUST be the id of 1715 a participant. The value for each key in the set MUST be true. 1716 If there are no groups, this MUST be omitted (rather than 1717 specified as an empty set). 1719 o linkIds: "String[Boolean]" (optional) 1721 A set of links to more information about this participant, for 1722 example in vCard format. The keys in the set MUST be the id of a 1723 Link object in the calendar object's "links" property. The value 1724 for each key in the set MUST be true. If there are no links, this 1725 MUST be omitted (rather than specified as an empty set). 1727 o progress: "String" (optional). This is only allowed if the 1728 Participant is part of a JSTask. It represents the progress of 1729 the participant for this task, if known. This property MUST NOT 1730 be set if the "participationStatus" of this participant is any 1731 value other than "accepted". See Section 5.2.4 for allowed values 1732 and semantics. 1734 o progressUpdated: "UTCDateTime" (optional). Specifies the date- 1735 time the progress property was last set on this participant. This 1736 is only allowed if the Participant is part of a JSTask. 1738 4.5. Alerts Properties 1740 4.5.1. useDefaultAlerts 1742 Type: "Boolean" (optional, default: false). 1744 If true, use the user's default alerts and ignore the value of the 1745 "alerts" property. Fetching user defaults is dependent on the API 1746 from which this JSCalendar object is being fetched, and is not 1747 defined in this specification. If an implementation cannot determine 1748 the user's default alerts, or none are set, it MUST process the 1749 alerts property as if "useDefaultAlerts" is set to false. 1751 4.5.2. alerts 1753 Type: "Id[Alert]" (optional). 1755 A map of alert ids to Alert objects, representing alerts/reminders to 1756 display or send to the user for this calendar object. 1758 An Alert Object has the following properties: 1760 o @type: "String" (mandatory) 1762 Specifies the type of this object. This MUST be "Alert". 1764 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" 1765 (mandatory) 1766 Defines when to trigger the alert. New types may be defined in 1767 future documents. 1769 An "OffsetTrigger" object has the following properties: 1771 * @type: "String" (mandatory) 1773 Specifies the type of this object. This MUST be 1774 "OffsetTrigger". 1776 * offset: "SignedDuration" (mandatory). 1778 Defines the offset at which to trigger the alert relative to 1779 the time property defined in the "relativeTo" property of the 1780 alert. Negative durations signify alerts before the time 1781 property, positive durations signify alerts after. If the 1782 calendar object does not define a time zone, the user's default 1783 time zone SHOULD be used when determining the offset, if known. 1784 Otherwise, the time zone to use is implementation specific. 1786 * relativeTo: "String" (optional, default: "start") 1788 Specifies the time property that the alert offset is relative 1789 to. The value MUST be one of: 1791 + "start": triggers the alert relative to the start of the 1792 calendar object 1794 + "end": triggers the alert relative to the end/due time of 1795 the calendar object 1797 An "AbsoluteTrigger" object has the following properties: 1799 * @type: "String" (mandatory) 1801 Specifies the type of this object. This MUST be 1802 "AbsoluteTrigger". 1804 * when: "UTCDateTime" (mandatory). 1806 Defines a specific UTC date-time when the alert is triggered. 1808 An "UnknownTrigger" object is an object that contains a "@type" 1809 property whose value is not recognized (i.e., not "OffsetTrigger" 1810 or "AbsoluteTrigger"), plus zero or more other properties. This 1811 is for compatibility with client extensions and future 1812 specifications. Implementations SHOULD NOT trigger for trigger 1813 types they do not understand, but MUST preserve them. 1815 o acknowledged: "UTCDateTime" (optional) 1817 This records when an alert was last acknowledged. This is set 1818 when the user has dismissed the alert; other clients that sync 1819 this property SHOULD automatically dismiss or suppress duplicate 1820 alerts (alerts with the same alert id that triggered on or before 1821 this date-time). 1823 For a recurring calendar object, the "acknowledged" property of 1824 the parent object MUST be updated, unless the alert is already 1825 overridden in the "recurrenceOverrides" property. 1827 Certain kinds of alert action may not provide feedback as to when 1828 the user sees them, for example email based alerts. For those 1829 kinds of alerts, this property SHOULD be set immediately when the 1830 alert is triggered and the action successfully carried out. 1832 o relatedTo: "String[Relation]" (optional) 1834 Relates this alert to other alerts in the same JSCalendar object. 1835 If the user wishes to snooze an alert, the application SHOULD 1836 create an alert to trigger after snoozing. All snooze alerts 1837 SHOULD set a relation to the identifier of the original alert. 1838 The Relation object SHOULD set the "parent" relation type. 1840 o action: "String" (optional, default: "display") 1842 Describes how to alert the user. 1844 The value MUST be at most one of the following values, a value 1845 registered in the IANA JSCalendar Enum Registry, or a vendor- 1846 specific value: 1848 * "display": The alert should be displayed as appropriate for the 1849 current device and user context. 1851 * "email": The alert should trigger an email sent out to the 1852 user, notifying about the alert. This action is typically only 1853 appropriate for server implementations. 1855 4.6. Multilingual Properties 1857 4.6.1. localizations 1859 Type: "String[PatchObject]" (optional). 1861 A map of language tags [RFC5646] to patch objects, which localize the 1862 calendar object into the locale of the respective language tag. 1864 See the description of PatchObject (Section 1.4.8) for the structure 1865 of the PatchObject. The patches are applied to the top-level 1866 calendar object. In addition, the "locale" property of the patched 1867 object is set to the language tag. All pointers for patches MUST end 1868 with one of the following suffixes; any patch that does not follow 1869 this MUST be ignored unless otherwise specified in a future RFC: 1871 o title 1873 o description 1875 o name 1877 A patch MUST NOT have the prefix "recurrenceOverrides"; any 1878 localization of the override MUST be a patch to the localizations 1879 property inside the override instead. For example, a patch to 1880 "locations/abcd1234/title" is permissible, but a patch to "uid" or 1881 "recurrenceOverrides/2018-01-05T14:00:00/title" is not. 1883 Note that this specification does not define how to maintain validity 1884 of localized content. For example, a client application changing a 1885 JSCalendar object's title property might also need to update any 1886 localizations of this property. Client implementations SHOULD 1887 provide the means to manage localizations, but how to achieve this is 1888 specific to the application's workflow and requirements. 1890 4.7. Time Zone Properties 1892 4.7.1. timeZone 1894 Type: "String|null" (optional, default: null). 1896 Identifies the time zone the object is scheduled in, or null for 1897 floating time. This is either a name from the IANA Time Zone 1898 Database [TZDB] or the id of a custom time zone from the "timeZones" 1899 property (see Section 1.4.9). If omitted, this MUST be presumed to 1900 be null (i.e., floating time). 1902 4.7.2. timeZones 1904 Type: "String[TimeZone]" (optional). 1906 Maps identifiers of custom time zones to their time zone definitions. 1907 The following restrictions apply for each key in the map: 1909 o It MUST start with the "/" character (ASCII decimal 47; also see 1910 Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion 1911 of the forward slash character in time zone identifiers). 1913 o It MUST be a valid "paramtext" value as specified in Section 3.1. 1914 of [RFC5545]. 1916 o At least one other property in the same JSCalendar object MUST 1917 reference a time zone using this identifier (i.e., orphaned time 1918 zones are not allowed). 1920 An identifier need only be unique to this JSCalendar object. 1922 A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545] 1923 and the semantics are as defined there. A valid time zone MUST 1924 define at least one transition rule in the "standard" or "daylight" 1925 property. Its properties are: 1927 o @type: "String" (mandatory) 1929 Specifies the type of this object. This MUST be "TimeZone". 1931 o tzId: "String" (mandatory). 1933 The TZID property from iCalendar. 1935 o lastModified: "UTCDateTime" (optional) 1937 The LAST-MODIFIED property from iCalendar. 1939 o url: "String" (optional) 1941 The TZURL property from iCalendar. 1943 o validUntil: "UTCDateTime" (optional) 1945 The TZUNTIL property from iCalendar specified in [RFC7808]. 1947 o aliases: "String[Boolean]" (optional) 1949 Maps the TZID-ALIAS-OF properties from iCalendar specified in 1950 [RFC7808] to a JSON set of aliases. The set is represented as an 1951 object, with the keys being the aliases. The value for each key 1952 in the set MUST be true. 1954 o standard: "TimeZoneRule[]" (optional) 1956 The STANDARD sub-components from iCalendar. The order MUST be 1957 preserved during conversion. 1959 o daylight: "TimeZoneRule[]" (optional). 1961 The DAYLIGHT sub-components from iCalendar. The order MUST be 1962 preserved during conversion. 1964 A TimeZoneRule object maps a STANDARD or DAYLIGHT sub-component from 1965 iCalendar, with the restriction that at most one recurrence rule is 1966 allowed per rule. It has the following properties: 1968 o @type: "String" (mandatory) 1970 Specifies the type of this object. This MUST be "TimeZoneRule". 1972 o start: "LocalDateTime" (mandatory) 1974 The DTSTART property from iCalendar. 1976 o offsetTo: "String" (mandatory) 1978 The TZOFFSETTO property from iCalendar. 1980 o offsetFrom: "String" (mandatory) 1982 The TZOFFSETFROM property from iCalendar. 1984 o recurrenceRule: "RecurrenceRule" (optional) 1986 The RRULE property mapped as specified in Section 4.3.2. During 1987 recurrence rule evaluation, the "until" property value MUST be 1988 interpreted as a local time in the UTC time zone. 1990 o recurrenceDates: "LocalDateTime[Boolean]" (optional) 1992 Maps the RDATE properties from iCalendar to a JSON set. The set 1993 is represented as an object, with the keys being the recurrence 1994 dates. The value for each key in the set MUST be true. 1996 o names: "String[Boolean]" (optional) 1998 Maps the TZNAME properties from iCalendar to a JSON set. The set 1999 is represented as an object, with the keys being the names. The 2000 value for each key in the set MUST be true. 2002 o comments: "String[]" (optional). Maps the COMMENT properties from 2003 iCalendar. The order MUST be preserved during conversion. 2005 5. Type-specific JSCalendar Properties 2007 5.1. JSEvent Properties 2009 In addition to the common JSCalendar object properties (Section 4) a 2010 JSEvent has the following properties: 2012 5.1.1. start 2014 Type: "LocalDateTime" (mandatory). 2016 The date/time the event starts in the event's time zone (as specified 2017 in the "timeZone" property, see Section 4.7.1). 2019 5.1.2. duration 2021 Type: "Duration" (optional, default: "PT0S"). 2023 The zero or positive duration of the event in the event's start time 2024 zone. 2026 Note that a duration specified using weeks or days does not always 2027 correspond to an exact multiple of 24 hours. The number of 2028 hours/minutes/seconds may vary if it overlaps a period of 2029 discontinuity in the event's time zone, for example a change from 2030 standard time to daylight-savings time. Leap seconds MUST NOT be 2031 considered when computing an exact duration. When computing an exact 2032 duration, the greatest order time components MUST be added first, 2033 that is, the number of days MUST be added first, followed by the 2034 number of hours, number of minutes, and number of seconds. 2035 Fractional seconds MUST be added last. These semantics match the 2036 iCalendar DURATION value type ([RFC5545], Section 3.3.6). 2038 A JSEvent MAY involve start and end locations that are in different 2039 time zones (e.g., a trans-continental flight). This can be expressed 2040 using the "relativeTo" and "timeZone" properties of the JSEvent's 2041 Location objects (see Section 4.2.5). 2043 5.1.3. status 2045 Type: "String" (optional, default: "confirmed"). 2047 The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be 2048 one of the following values, a value registered in the IANA 2049 JSCalendar Enum Registry, or a vendor-specific value: 2051 o "confirmed": Indicates the event is definitely happening. 2053 o "cancelled": Indicates the event has been cancelled. 2055 o "tentative": Indicates the event may happen. 2057 5.2. JSTask Properties 2059 In addition to the common JSCalendar object properties (Section 4) a 2060 JSTask has the following properties: 2062 5.2.1. due 2064 Type: "LocalDateTime" (optional). 2066 The date/time the task is due in the task's time zone. 2068 5.2.2. start 2070 Type: "LocalDateTime" (optional). 2072 The date/time the task should start in the task's time zone. 2074 5.2.3. estimatedDuration 2076 Type: "Duration" (optional). 2078 Specifies the estimated positive duration of time the task takes to 2079 complete. 2081 5.2.4. progress 2083 Type: "String" (optional). 2085 Defines the progress of this task. If omitted, the default progress 2086 (Section 4.4) of a JSTask is defined as follows (in order of 2087 evaluation): 2089 o "completed": if the "progress" property value of all participants 2090 is "completed". 2092 o "failed": if at least one "progress" property value of a 2093 participant is "failed". 2095 o "in-process": if at least one "progress" property value of a 2096 participant is "in-process". 2098 o "needs-action": If none of the other criteria match. 2100 If set, it MUST be one of the following values, a value registered in 2101 the IANA JSCalendar Enum Registry, or a vendor-specific value: 2103 o "needs-action": Indicates the task needs action. 2105 o "in-process": Indicates the task is in process. 2107 o "completed": Indicates the task is completed. 2109 o "failed": Indicates the task failed. 2111 o "cancelled": Indicates the task was cancelled. 2113 5.2.5. progressUpdated 2115 Type: "UTCDateTime" (optional). 2117 Specifies the date/time the "progress" property of either the task 2118 overall (Section 5.2.4) or a specific participant (Section 4.4.5) was 2119 last updated. 2121 If the task is recurring and has future instances, a client may want 2122 to keep track of the last progress update timestamp of a specific 2123 task recurrence, but leave other instances unchanged. One way to 2124 achieve this is by overriding the progressUpdated property in the 2125 task "recurrenceOverrides" property. However, this could produce a 2126 long list of timestamps for regularly recurring tasks. An 2127 alternative approach is to split the JSTask into a current, single 2128 instance of JSTask with this instance progress update time and a 2129 future recurring instance. See also Section 4.1.3 on splitting. 2131 5.3. JSGroup Properties 2133 JSGroup supports the following common JSCalendar properties 2134 (Section 4): 2136 o @type 2138 o categories 2140 o color 2142 o created 2144 o description 2146 o descriptionContentType 2147 o keywords 2149 o links 2151 o locale 2153 o prodId 2155 o title 2157 o updated 2159 o uid 2161 In addition, the following JSGroup-specific properties are supported: 2163 5.3.1. entries 2165 Type: "String[JSTask|JSEvent]" (mandatory). 2167 A collection of group members. This is represented as a map of the 2168 "uid" property value to the JSCalendar object member having that uid. 2169 Implementations MUST ignore entries of unknown type. 2171 5.3.2. source 2173 Type: "String" (optional). 2175 The source from which updated versions of this group may be retrieved 2176 from. The value MUST be a URI. 2178 6. Examples 2180 The following examples illustrate several aspects of the JSCalendar 2181 data model and format. The examples may omit mandatory or additional 2182 properties, which is indicated by a placeholder property with key 2183 "...". While most of the examples use calendar event objects, they 2184 are also illustrative for tasks. 2186 6.1. Simple event 2188 This example illustrates a simple one-time event. It specifies a 2189 one-time event that begins on January 15, 2018 at 1pm New York local 2190 time and ends after 1 hour. 2192 { 2193 "@type": "jsevent", 2194 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2195 "updated": "2018-01-15T18:00:00Z", 2196 "title": "Some event", 2197 "start": "2018-01-15T13:00:00", 2198 "timeZone": "America/New_York", 2199 "duration": "PT1H" 2200 } 2202 6.2. Simple task 2204 This example illustrates a simple task for a plain to-do item. 2206 { 2207 "@type": "jstask", 2208 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2209 "updated": "2018-01-15T18:00:00Z", 2210 "title": "Do something" 2211 } 2213 6.3. Simple group 2215 This example illustrates a simple calendar object group that contains 2216 an event and a task. 2218 { 2219 "@type": "jsgroup", 2220 "uid": "2a358cee-6489-4f14-a57f-c104db4dc343", 2221 "updated": "2018-01-15T18:00:00Z", 2222 "name": "A simple group", 2223 "entries": { 2224 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2225 "@type": "jsevent", 2226 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2227 "updated": "2018-01-15T18:00:00Z", 2228 "title": "Some event", 2229 "start": "2018-01-15T13:00:00", 2230 "timeZone": "America/New_York", 2231 "duration": "PT1H" 2232 }, 2233 "2a358cee-6489-4f14-a57f-c104db4dc2f2": { 2234 "@type": "jstask", 2235 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2236 "updated": "2018-01-15T18:00:00Z", 2237 "title": "Do something" 2238 } 2239 } 2240 } 2242 6.4. All-day event 2244 This example illustrates an event for an international holiday. It 2245 specifies an all-day event on April 1 that occurs every year since 2246 the year 1900. 2248 { 2249 "...": "", 2250 "title": "April Fool's Day", 2251 "showWithoutTime": true, 2252 "start": "1900-04-01T00:00:00", 2253 "duration": "P1D", 2254 "recurrenceRules": [{ 2255 "@type": "RecurrenceRule", 2256 "frequency": "yearly" 2257 }] 2258 } 2260 6.5. Task with a due date 2262 This example illustrates a task with a due date. It is a reminder to 2263 buy groceries before 6pm Vienna local time on January 19, 2018. The 2264 calendar user expects to need 1 hour for shopping. 2266 { 2267 "...": "", 2268 "title": "Buy groceries", 2269 "due": "2018-01-19T18:00:00", 2270 "timeZone": "Europe/Vienna", 2271 "estimatedDuration": "PT1H" 2272 } 2274 6.6. Event with end time-zone 2276 This example illustrates the use of end time-zones by use of an 2277 international flight. The flight starts on April 1, 2018 at 9am in 2278 Berlin local time. The duration of the flight is scheduled at 10 2279 hours 30 minutes. The time at the flights destination is in the same 2280 time-zone as Tokyo. Calendar clients could use the end time-zone to 2281 display the arrival time in Tokyo local time and highlight the time- 2282 zone difference of the flight. The location names can serve as input 2283 for navigation systems. 2285 { 2286 "...": "", 2287 "title": "Flight XY51 to Tokyo", 2288 "start": "2018-04-01T09:00:00", 2289 "timeZone": "Europe/Berlin", 2290 "duration": "PT10H30M", 2291 "locations": { 2292 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2293 "@type": "Location", 2294 "rel": "start", 2295 "name": "Frankfurt Airport (FRA)" 2296 }, 2297 "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { 2298 "@type": "Location", 2299 "rel": "end", 2300 "name": "Narita International Airport (NRT)", 2301 "timeZone": "Asia/Tokyo" 2302 } 2303 } 2304 } 2306 6.7. Floating-time event (with recurrence) 2308 This example illustrates the use of floating-time. Since January 1, 2309 2018, a calendar user blocks 30 minutes every day to practice Yoga at 2310 7am local time, in whatever time-zone the user is located on that 2311 date. 2313 { 2314 "...": "", 2315 "title": "Yoga", 2316 "start": "2018-01-01T07:00:00", 2317 "duration": "PT30M", 2318 "recurrenceRules": [{ 2319 "@type": "RecurrenceRule", 2320 "frequency": "daily" 2321 }] 2322 } 2324 6.8. Event with multiple locations and localization 2326 This example illustrates an event that happens at both a physical and 2327 a virtual location. Fans can see a live concert on premises or 2328 online. The event title and descriptions are localized. 2330 { 2331 "...": "", 2332 "title": "Live from Music Bowl: The Band", 2333 "description": "Go see the biggest music event ever!", 2334 "locale": "en", 2335 "start": "2018-07-04T17:00:00", 2336 "timeZone": "America/New_York", 2337 "duration": "PT3H", 2338 "locations": { 2339 "c0503d30-8c50-4372-87b5-7657e8e0fedd": { 2340 "@type": "Location", 2341 "name": "The Music Bowl", 2342 "description": "Music Bowl, Central Park, New York", 2343 "coordinates": "geo:40.7829,-73.9654" 2344 } 2345 }, 2346 "virtualLocations": { 2347 "6f3696c6-1e07-47d0-9ce1-f50014b0041a": { 2348 "@type": "VirtualLocation", 2349 "name": "Free live Stream from Music Bowl", 2350 "uri": "https://stream.example.com/the_band_2018" 2351 } 2352 }, 2353 "localizations": { 2354 "de": { 2355 "title": "Live von der Music Bowl: The Band!", 2356 "description": "Schau dir das groesste Musikereignis an!", 2357 "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name": 2358 "Gratis Live-Stream aus der Music Bowl" 2359 } 2360 } 2361 } 2363 6.9. Recurring event with overrides 2365 This example illustrates the use of recurrence overrides. A math 2366 course at a University is held for the first time on January 8, 2018 2367 at 9am London time and occurs every week until June 25, 2018. Each 2368 lecture lasts for one hour and 30 minutes and is located at the 2369 Mathematics department. This event has exceptional occurrences: at 2370 the last occurrence of the course is an exam, which lasts for 2 hours 2371 and starts at 10am. Also, the location of the exam differs from the 2372 usual location. On April 2 no course is held. On January 5 at 2pm 2373 is an optional introduction course, that occurs before the first 2374 regular lecture. 2376 { 2377 "...": "", 2378 "title": "Calculus I", 2379 "start": "2018-01-08T09:00:00", 2380 "timeZone": "Europe/London", 2381 "duration": "PT1H30M", 2382 "locations": { 2383 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2384 "@type": "Location", 2385 "title": "Math lab room 1", 2386 "description": "Math Lab I, Department of Mathematics" 2387 } 2388 }, 2389 "recurrenceRules": [{ 2390 "@type": "RecurrenceRule", 2391 "frequency": "weekly", 2392 "until": "2018-06-25T09:00:00" 2393 }], 2394 "recurrenceOverrides": { 2395 "2018-01-05T14:00:00": { 2396 "title": "Introduction to Calculus I (optional)" 2397 }, 2398 "2018-04-02T09:00:00": { 2399 "excluded": "true" 2400 }, 2401 "2018-06-25T09:00:00": { 2402 "title": "Calculus I Exam", 2403 "start": "2018-06-25T10:00:00", 2404 "duration": "PT2H", 2405 "locations": { 2406 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2407 "@type": "Location", 2408 "title": "Big Auditorium", 2409 "description": "Big Auditorium, Other Road" 2410 } 2411 } 2412 } 2413 } 2414 } 2416 6.10. Recurring event with participants 2418 This example illustrates scheduled events. A team meeting occurs 2419 every week since January 8, 2018 at 9am Johannesburg time. The event 2420 owner also chairs the event. Participants meet in a virtual meeting 2421 room. An attendee has accepted the invitation, but on March 8, 2018 2422 he is unavailable and declined participation for this occurrence. 2424 { 2425 "...": "", 2426 "title": "FooBar team meeting", 2427 "start": "2018-01-08T09:00:00", 2428 "timeZone": "Africa/Johannesburg", 2429 "duration": "PT1H", 2430 "virtualLocations": { 2431 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2432 "@type": "VirtualLocation", 2433 "name": "ChatMe meeting room", 2434 "uri": "https://chatme.example.com?id=1234567" 2435 } 2436 }, 2437 "recurrenceRules": [{ 2438 "@type": "RecurrenceRule", 2439 "frequency": "weekly" 2440 }], 2441 "replyTo": { 2442 "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com" 2443 }, 2444 "participants": { 2445 "dG9tQGZvb2Jhci5xlLmNvbQ": { 2446 "@type": "Participant", 2447 "name": "Tom Tool", 2448 "email": "tom@foobar.example.com", 2449 "sendTo": { 2450 "imip": "mailto:6489-4f14-a57f-c1@calendar.example.com" 2451 }, 2452 "participationStatus": "accepted", 2453 "roles": { 2454 "attendee": true 2455 } 2456 }, 2457 "em9lQGZvb2GFtcGxlLmNvbQ": { 2458 "@type": "Participant", 2459 "name": "Zoe Zelda", 2460 "email": "zoe@foobar.example.com", 2461 "sendTo": { 2462 "imip": "mailto:zoe@foobar.example.com" 2463 }, 2464 "participationStatus": "accepted", 2465 "roles": { 2466 "owner": true, 2467 "attendee": true, 2468 "chair": true 2469 } 2470 }, 2471 "...": "" 2473 }, 2474 "recurrenceOverrides": { 2475 "2018-03-08T09:00:00": { 2476 "participants/dG9tQGZvb2Jhci5xlLmNvbQ/participationStatus": 2477 "declined" 2478 } 2479 } 2480 } 2482 7. Security Considerations 2484 Calendaring and scheduling information is very privacy-sensitive. 2485 The transmission of such information must be done carefully to 2486 protect it from possible threats, such as eavesdropping, replay, 2487 message insertion, deletion, modification, and man-in-the-middle 2488 attacks. This document just defines the data format; such 2489 considerations are primarily the concern of the API or method of 2490 storage and transmission of such files. 2492 7.1. Expanding Recurrences 2494 A recurrence rule may produce infinite occurrences of an event. 2495 Implementations MUST handle expansions carefully to prevent 2496 accidental or deliberate resource exhaustion. 2498 Conversely, a recurrence rule may be specified that does not expand 2499 to anything. It is not always possible to tell this through static 2500 analysis of the rule, so implementations MUST be careful to avoid 2501 getting stuck in infinite loops, or otherwise exhausting resources 2502 while searching for the next occurrence. 2504 7.2. JSON Parsing 2506 The Security Considerations of [RFC8259] apply to the use of JSON as 2507 the data interchange format. 2509 As for any serialization format, parsers need to thoroughly check the 2510 syntax of the supplied data. JSON uses opening and closing tags for 2511 several types and structures, and it is possible that the end of the 2512 supplied data will be reached when scanning for a matching closing 2513 tag; this is an error condition, and implementations need to stop 2514 scanning at the end of the supplied data. 2516 JSON also uses a string encoding with some escape sequences to encode 2517 special characters within a string. Care is needed when processing 2518 these escape sequences to ensure that they are fully formed before 2519 the special processing is triggered, with special care taken when the 2520 escape sequences appear adjacent to other (non-escaped) special 2521 characters or adjacent to the end of data (as in the previous 2522 paragraph). 2524 If parsing JSON into a non-textual structured data format, 2525 implementations may need to allocate storage to hold JSON string 2526 elements. Since JSON does not use explicit string lengths, the risk 2527 of denial of service due to resource exhaustion is small, but 2528 implementations may still wish to place limits on the size of 2529 allocations they are willing to make in any given context, to avoid 2530 untrusted data causing excessive memory allocation. 2532 7.3. URI Values 2534 Several JSCalendar properties contain URIs as values, and processing 2535 these properties requires extra care. Section 7 of [RFC3986] 2536 discusses security risk related to URIs. 2538 A maliciously constructed JSCalendar object may contain a very large 2539 number of URIs. In the case of published calendars with a large 2540 number of subscribers, such objects could be widely distributed. 2541 Implementations should be careful to limit the automatic fetching of 2542 linked resources to reduce the risk of this being an amplification 2543 vector for a denial-of-service attack. 2545 8. IANA Considerations 2547 8.1. Media Type Registration 2549 This document defines a media type for use with JSCalendar data 2550 formatted in JSON. 2552 Type name: application 2554 Subtype name: jscalendar+json 2556 Required parameters: type 2558 The "type" parameter conveys the type of the JSCalendar data in 2559 the body part, with the value being one of "jsevent", "jstask", or 2560 "jsgroup". The parameter MUST NOT occur more than once. It MUST 2561 match the value of the "@type" property of the JSON-formatted 2562 JSCalendar object in the body. 2564 Optional parameters: none 2566 Encoding considerations: Same as encoding considerations of 2567 application/json as specified in RFC8529, Section 11 [RFC8259]. 2569 Security considerations: See Section 7 of this document. 2571 Interoperability considerations: This media type provides an 2572 alternative to iCalendar, jCal and proprietary JSON-based 2573 calendaring data formats. 2575 Published specification: This specification. 2577 Applications that use this media type: Applications that currently 2578 make use of the text/calendar and application/calendar+json media 2579 types can use this as an alternative. Similarly, applications 2580 that use the application/json media type to transfer calendaring 2581 data can use this to further specify the content. 2583 Fragment identifier considerations: N/A 2585 Additional information: 2587 Magic number(s): N/A 2589 File extensions(s): N/A 2591 Macintosh file type code(s): N/A 2593 Person & email address to contact for further information: 2594 calsify@ietf.org 2596 Intended usage: COMMON 2598 Restrictions on usage: N/A 2600 Author: See the "Author's Address" section of this document. 2602 Change controller: IETF 2604 8.2. Creation of "JSCalendar Properties" Registry 2606 The IANA will create the "JSCalendar Properties" registry to allow 2607 interoperability of extensions to JSCalendar objects. 2609 This registry follows the Expert Review process ([RFC8126], 2610 Section 4.5). If the "intended use" field is "common", sufficient 2611 documentation is required to enable interoperability. Preliminary 2612 community review for this registry is optional but strongly 2613 encouraged. 2615 A registration can have an intended use of "common", "reserved", or 2616 "obsolete". The IANA will list common-use registrations prominently 2617 and separately from those with other intended use values. 2619 A "reserved" registration reserves a property name without assigning 2620 semantics to avoid name collisions with future extensions or protocol 2621 use. 2623 An "obsolete" registration denotes a property that is no longer 2624 expected to be added by up-to-date systems. A new property has 2625 probably been defined covering the obsolete property's semantics. 2627 The JSCalendar property registration procedure is not a formal 2628 standards process but rather an administrative procedure intended to 2629 allow community comment and sanity checking without excessive time 2630 delay. It is designed to encourage vendors to document and register 2631 new properties they add for use cases not covered by the original 2632 standard, leading to increased interoperability. 2634 8.2.1. Preliminary Community Review 2636 Notice of a potential new registration SHOULD be sent to the Calext 2637 mailing list for review. This mailing list is 2638 appropriate to solicit community feedback on a proposed new property. 2640 Properties registrations must be marked with their intended use: 2641 "common", "reserved" or "obsolete". 2643 The intent of the public posting to this list is to solicit comments 2644 and feedback on the choice of the property name, the unambiguity of 2645 the specification document, and a review of any interoperability or 2646 security considerations. The submitter may submit a revised 2647 registration proposal or abandon the registration completely at any 2648 time. 2650 8.2.2. Submit Request to IANA 2652 Registration requests can be sent to . 2654 8.2.3. Designated Expert Review 2656 The primary concern of the designated expert (DE) is preventing name 2657 collisions and encouraging the submitter to document security and 2658 privacy considerations. For a common-use registration, the DE is 2659 expected to confirm that suitable documentation, as described in 2660 Section 4.6 of [RFC8126], is available to ensure interoperability. 2661 That documentation will usually be in an RFC, but simple definitions 2662 are likely to use a web/wiki page, and if a sentence or two is deemed 2663 sufficient it could be described in the registry itself. The DE 2664 should also verify that the property name does not conflict with work 2665 that is active or already published within the IETF. A published 2666 specification is not required for reserved or obsolete registrations. 2668 The DE will either approve or deny the registration request and 2669 publish a notice of the decision to the Calext WG mailing list or its 2670 successor, as well as inform IANA. A denial notice must be justified 2671 by an explanation, and, in the cases where it is possible, concrete 2672 suggestions on how the request can be modified so as to become 2673 acceptable should be provided. 2675 8.2.4. Change Procedures 2677 Once a JSCalendar property has been published by the IANA, the change 2678 controller may request a change to its definition. The same 2679 procedure that would be appropriate for the original registration 2680 request is used to process a change request. 2682 JSCalendar property registrations may not be deleted; properties that 2683 are no longer believed appropriate for use can be declared obsolete 2684 by a change to their "intended use" field; such properties will be 2685 clearly marked in the lists published by the IANA. 2687 Significant changes to a JSCalendar property's definition should be 2688 requested only when there are serious omissions or errors in the 2689 published specification, as such changes may cause interoperability 2690 issues. When review is required, a change request may be denied if 2691 it renders entities that were valid under the previous definition 2692 invalid under the new definition. 2694 The owner of a JSCalendar property may pass responsibility to another 2695 person or agency by informing the IANA; this can be done without 2696 discussion or review. 2698 8.2.5. JMAP Properties Registry Template 2700 o Property Name: The name of the property. The property name MUST 2701 NOT already be registered for any of the object types listed in 2702 the "Property Context" field of this registration. Other object 2703 types MAY already have registered a different property with the 2704 same name. 2706 o Property Type: The type of this property, using type signatures as 2707 specified in Section 1.3. The property type MUST be registed in 2708 the Type Registry. 2710 o Property Context: A comma-separated list of JSCalendar object 2711 types this property is allowed on. 2713 o Reference or Description: A brief description or RFC number and 2714 section reference where the property is specified (omitted for 2715 "reserved" property names). 2717 o Intended Use: Common, reserved, or obsolete. 2719 o Change Controller: ("IETF" for IETF-stream RFCs). 2721 8.2.6. Initial Contents for the JSCalendar Properties Registry 2723 The following table lists the initial entries of the JSCalendar 2724 Properties registry. All properties are for common-use. All RFC 2725 section references are for this document. The change controller for 2726 all these properties is "IETF". 2728 +---------------+----------------------------+------------+---------+ 2729 | Property Name | Property Type | Property | Referen | 2730 | | | Context | ce or D | 2731 | | | | escript | 2732 | | | | ion | 2733 +---------------+----------------------------+------------+---------+ 2734 | @type | String | JSEvent, | Section | 2735 | | | JSTask, | 4.1.1, | 2736 | | | JSGroup, A | Section | 2737 | | | bsoluteTri | 4.5.2, | 2738 | | | gger, | Section | 2739 | | | Alert, | 4.2.7, | 2740 | | | Link, | Section | 2741 | | | Location, | 4.2.5, | 2742 | | | OffsetTrig | Section | 2743 | | | ger, Parti | 4.4.5, | 2744 | | | cipant, Re | Section | 2745 | | | currenceRu | 4.3.2, | 2746 | | | le, | Section | 2747 | | | Relation, | 4.1.3, | 2748 | | | TimeZone, | Section | 2749 | | | VirtualLoc | 4.7.2, | 2750 | | | ation | Section | 2751 | | | | 4.2.6 | 2752 | | | | | 2753 | acknowledged | UTCDateTime | Alert | Section | 2754 | | | | 4.5.2 | 2755 | | | | | 2756 | action | String | Alert | Section | 2757 | | | | 4.5.2 | 2758 | | | | | 2759 | alerts | Id[Alert] | JSEvent, | Section | 2760 | | | JSTask | 4.5.2 | 2761 | | | | | 2762 | byDay | NDay[] | Recurrence | Section | 2763 | | | Rule | 4.3.2 | 2764 | | | | | 2765 | byHour | UnsignedInt[] | Recurrence | Section | 2766 | | | Rule | 4.3.2 | 2767 | | | | | 2768 | byMinute | UnsignedInt[] | Recurrence | Section | 2769 | | | Rule | 4.3.2 | 2770 | | | | | 2771 | byMonth | String[] | Recurrence | Section | 2772 | | | Rule | 4.3.2 | 2773 | | | | | 2774 | byMonthDay | Int[] | Recurrence | Section | 2775 | | | Rule | 4.3.2 | 2776 | | | | | 2777 | bySecond | UnsignedInt[] | Recurrence | Section | 2778 | | | Rule | 4.3.2 | 2779 | | | | | 2780 | bySetPosition | Int[] | Recurrence | Section | 2781 | | | Rule | 4.3.2 | 2782 | | | | | 2783 | byWeekNo | Int[] | Recurrence | Section | 2784 | | | Rule | 4.3.2 | 2785 | | | | | 2786 | byYearDay | Int[] | Recurrence | Section | 2787 | | | Rule | 4.3.2 | 2788 | | | | | 2789 | categories | String[Boolean] | JSEvent, | Section | 2790 | | | JSTask, | 4.2.10 | 2791 | | | JSGroup | | 2792 | | | | | 2793 | cid | String | Link | Section | 2794 | | | | 4.2.7 | 2795 | | | | | 2796 | color | String | JSEvent, | Section | 2797 | | | JSTask, | 4.2.11 | 2798 | | | JSGroup | | 2799 | | | | | 2800 | contentType | String | Link | Section | 2801 | | | | 4.2.7 | 2802 | | | | | 2803 | coordinates | String | Location | Section | 2804 | | | | 4.2.5 | 2805 | | | | | 2806 | count | UnsignedInt | Recurrence | Section | 2807 | | | Rule | 4.3.2 | 2808 | | | | | 2809 | created | UTCDateTime | JSEvent, | Section | 2810 | | | JSTask, | 4.1.5 | 2811 | | | JSGroup | | 2812 | | | | | 2813 | delegatedFrom | String[Boolean] | Participan | Section | 2814 | | | t | 4.4.5 | 2815 | | | | | 2816 | delegatedTo | String[Boolean] | Participan | Section | 2817 | | | t | 4.4.5 | 2818 | | | | | 2819 | description | String | JSEvent, | Section | 2820 | | | JSTask, | 4.2.2, | 2821 | | | Location, | Section | 2822 | | | VirtualLoc | 4.2.5, | 2823 | | | ation | Section | 2824 | | | | 4.2.6 | 2825 | | | | | 2826 | descriptionCo | String | JSEvent, | Section | 2827 | ntentType | | JSTask | 4.2.3 | 2828 | | | | | 2829 | display | String | Link | Section | 2830 | | | | 4.2.7 | 2831 | | | | | 2832 | due | LocalDateTime | JSTask | Section | 2833 | | | | 5.2.1 | 2834 | | | | | 2835 | duration | Duration | JSEvent | Section | 2836 | | | | 5.1.2 | 2837 | | | | | 2838 | email | String | Participan | Section | 2839 | | | t | 4.4.5 | 2840 | | | | | 2841 | entries | String[JSTask|JSEvent] | JSGroup | Section | 2842 | | | | 5.3.1 | 2843 | | | | | 2844 | estimatedDura | Duration | JSTask | Section | 2845 | tion | | | 5.2.3 | 2846 | | | | | 2847 | excluded | Boolean | JSEvent, | Section | 2848 | | | JSTask | 4.3.4 | 2849 | | | | | 2850 | expectReply | Boolean | Participan | Section | 2851 | | | t | 4.4.5 | 2852 | | | | | 2853 | firstDayOfWee | String | Recurrence | Section | 2854 | k | | Rule | 4.3.2 | 2855 | | | | | 2856 | freeBusyStatu | String | JSEvent, | Section | 2857 | s | | JSTask | 4.4.2 | 2858 | | | | | 2859 | frequency | String | Recurrence | Section | 2860 | | | Rule | 4.3.2 | 2861 | | | | | 2862 | href | String | Link | Section | 2863 | | | | 4.2.7 | 2864 | | | | | 2865 | interval | UnsignedInt | Recurrence | Section | 2866 | | | Rule | 4.3.2 | 2867 | | | | | 2868 | invitedBy | String | Participan | Section | 2869 | | | t | 4.4.5 | 2870 | | | | | 2871 | keywords | String[Boolean] | JSEvent, | Section | 2872 | | | JSTask, | 4.2.9 | 2873 | | | JSGroup | | 2874 | | | | | 2875 | kind | String | Participan | Section | 2876 | | | t | 4.4.5 | 2877 | | | | | 2878 | language | String | Participan | Section | 2879 | | | t | 4.4.5 | 2880 | | | | | 2881 | linkIds | Id[Boolean] | Location, | Section | 2882 | | | Participan | 4.2.5, | 2883 | | | t | Section | 2884 | | | | 4.4.5 | 2885 | | | | | 2886 | links | Id[Link] | JSGroup, | Section | 2887 | | | JSEvent, | 4.2.7 | 2888 | | | JSTask | | 2889 | | | | | 2890 | locale | String | JSGroup, | Section | 2891 | | | JSEvent, | 4.2.7 | 2892 | | | JSTask | | 2893 | | | | | 2894 | localizations | String[PatchObject] | JSEvent, | Section | 2895 | | | JSTask | 4.6.1 | 2896 | | | | | 2897 | locationId | String | Participan | Section | 2898 | | | t | 4.4.5 | 2899 | | | | | 2900 | locations | Id[Location] | JSEvent, | Section | 2901 | | | JSTask | 4.2.5 | 2902 | | | | | 2903 | locationTypes | String[Boolean] | Location | Section | 2904 | | | | 4.2.5 | 2905 | | | | | 2906 | memberOf | String[Boolean] | Participan | Section | 2907 | | | t | 4.4.5 | 2908 | | | | | 2909 | method | String | JSEvent, | Section | 2910 | | | JSTask | 4.1.8 | 2911 | | | | | 2912 | name | String | Location, | Section | 2913 | | | VirtualLoc | 4.2.5, | 2914 | | | ation, Par | Section | 2915 | | | ticipant | 4.2.6, | 2916 | | | | Section | 2917 | | | | 4.4.5 | 2918 | | | | | 2919 | offset | SignedDuration | OffsetTrig | Section | 2920 | | | ger | 4.5.2 | 2921 | | | | | 2922 | participants | Id[Participant] | JSEvent, | Section | 2923 | | | JSTask | 4.4.5 | 2924 | | | | | 2925 | participation | String | Participan | Section | 2926 | Comment | | t | 4.4.5 | 2927 | | | | | 2928 | participation | String | Participan | Section | 2929 | Status | | t | 4.4.5 | 2930 | | | | | 2931 | priority | Int | JSEvent, | Section | 2932 | | | JSTask | 4.4.1 | 2933 | | | | | 2934 | privacy | String | JSEvent, | Section | 2935 | | | JSTask | 4.4.3 | 2936 | | | | | 2937 | prodId | String | JSEvent, | Section | 2938 | | | JSTask, | 4.1.4 | 2939 | | | JSGroup | | 2940 | | | | | 2941 | progress | String | JSTask, Pa | Section | 2942 | | | rticipant | 5.2.4 | 2943 | | | | | 2944 | progressUpdat | UTCDateTime | JSTask, Pa | Section | 2945 | ed | | rticipant | 5.2.5 | 2946 | | | | | 2947 | recurrenceId | LocalDateTime | JSEvent, | Section | 2948 | | | JSTask | 4.3.1 | 2949 | | | | | 2950 | recurrenceOve | LocalDateTime[PatchObject] | JSEvent, | Section | 2951 | rrides | | JSTask | 4.3.3 | 2952 | | | | | 2953 | recurrenceRul | RecurrenceRule[] | JSEvent, | Section | 2954 | es | | JSTask | 4.3.2 | 2955 | | | | | 2956 | rel | String | Link | Section | 2957 | | | | 4.2.7 | 2958 | | | | | 2959 | relatedTo | String[Relation] | JSEvent, | Section | 2960 | | | JSTask, | 4.1.3, | 2961 | | | Alert | Section | 2962 | | | | 4.5.2 | 2963 | | | | | 2964 | relation | String[Boolean] | Relation | Section | 2965 | | | | 1.4.10 | 2966 | | | | | 2967 | relativeTo | String | OffsetTrig | Section | 2968 | | | ger, | 4.5.2, | 2969 | | | Location | Section | 2970 | | | | 4.2.5 | 2971 | | | | | 2972 | replyTo | String[String] | JSEvent, | Section | 2973 | | | JSTask | 4.4.4 | 2974 | | | | | 2975 | roles | String[Boolean] | Participan | Section | 2976 | | | t | 4.4.5 | 2977 | | | | | 2978 | rscale | String | Recurrence | Section | 2979 | | | Rule | 4.3.2 | 2980 | | | | | 2981 | scheduleAgent | String | Participan | Section | 2982 | | | t | 4.4.5 | 2983 | | | | | 2984 | scheduleSeque | UnsignedInt | Participan | Section | 2985 | nce | | t | 4.4.5 | 2986 | | | | | 2987 | scheduleUpdat | UTCDateTime | Participan | Section | 2988 | ed | | t | 4.4.5 | 2989 | | | | | 2990 | sendTo | String[String] | Participan | Section | 2991 | | | t | 4.4.5 | 2992 | | | | | 2993 | sequence | UnsignedInt | JSEvent, | Section | 2994 | | | JSTask | 4.1.7 | 2995 | | | | | 2996 | showWithoutTi | Boolean | JSEvent, | Section | 2997 | me | | JSTask | 4.2.4 | 2998 | | | | | 2999 | size | UnsignedInt | Link | Section | 3000 | | | | 4.2.7 | 3001 | | | | | 3002 | skip | String | Recurrence | Section | 3003 | | | Rule | 4.3.2 | 3004 | | | | | 3005 | source | String | JSGroup | Section | 3006 | | | | 5.3.2 | 3007 | | | | | 3008 | start | LocalDateTime | JSEvent, | Section | 3009 | | | JSTask | 5.1.1, | 3010 | | | | Section | 3011 | | | | 5.2.2 | 3012 | | | | | 3013 | status | String | JSEvent | Section | 3014 | | | | 5.1.3 | 3015 | | | | | 3016 | timeZone | String|null | JSEvent, | Section | 3017 | | | JSTask, | 4.7.1, | 3018 | | | Location | Section | 3019 | | | | 4.2.5 | 3020 | | | | | 3021 | timeZones | String[TimeZone] | JSEvent, | Section | 3022 | | | JSTask | 4.7.2 | 3023 | | | | | 3024 | title | String | JSEvent, | Section | 3025 | | | JSTask, | 4.2.1 | 3026 | | | JSGroup, | | 3027 | | | Link | | 3028 | | | | | 3029 | trigger | OffsetTrigger|AbsoluteTrig | Alert | Section | 3030 | | ger|UnknownTrigger | | 4.5.2 | 3031 | | | | | 3032 | uid | String | JSEvent, | Section | 3033 | | | JSTask, | 4.1.2 | 3034 | | | JSGroup | | 3035 | | | | | 3036 | until | LocalDateTime | Recurrence | Section | 3037 | | | Rule | 4.3.2 | 3038 | | | | | 3039 | updated | UTCDateTime | JSEvent, | Section | 3040 | | | JSTask, | 4.1.6 | 3041 | | | JSGroup | | 3042 | | | | | 3043 | uri | String | VirtualLoc | Section | 3044 | | | ation | 4.2.6 | 3045 | | | | | 3046 | useDefaultAle | Boolean | JSEvent, | Section | 3047 | rts | | JSTask | 4.5.1 | 3048 | | | | | 3049 | virtualLocati | Id[VirtualLocation] | JSEvent, | Section | 3050 | ons | | JSTask | 4.2.6 | 3051 | | | | | 3052 | when | UTCDateTime | AbsoluteTr | Section | 3053 | | | igger | 4.5.2 | 3054 +---------------+----------------------------+------------+---------+ 3056 Table 1 3058 8.3. Creation of "JSCalendar Types" Registry 3060 The IANA will create the "JSCalendar Types" registry to avoid name 3061 collisions and provide a complete reference for all data types used 3062 for JSCalendar property values. The registration process is the same 3063 as for the JSCalendar Properties registry, as defined in Section 8.2. 3065 8.3.1. JMAP Types Registry Template 3067 o Type Name: The name of the type. 3069 o Reference or Description: A brief description or RFC number and 3070 section reference where the Type is specified (may be omitted for 3071 "reserved" type names). 3073 o Intended Use: Common, reserved, or obsolete. 3075 o Change Controller: ("IETF" for IETF-stream RFCs). 3077 8.3.2. Initial Contents for the JSCalendar Types Registry 3079 The following table lists the initial entries of the JSCalendar Types 3080 registry. All properties are for common-use. All RFC section 3081 references are for this document. The change controller for all 3082 these properties is "IETF". 3084 +-----------------+--------------------------+ 3085 | Type Name | Reference or Description | 3086 +-----------------+--------------------------+ 3087 | Alert | Section 4.5.2 | 3088 | | | 3089 | Boolean | Section 1.3 | 3090 | | | 3091 | Duration | Section 1.4.5 | 3092 | | | 3093 | Id | Section 1.4.7 | 3094 | | | 3095 | Int | Section 1.4.1 | 3096 | | | 3097 | LocalDateTime | Section 1.4.4 | 3098 | | | 3099 | Link | Section 4.2.7 | 3100 | | | 3101 | Location | Section 4.2.5 | 3102 | | | 3103 | Number | Section 1.3 | 3104 | | | 3105 | Participant | Section 4.4.5 | 3106 | | | 3107 | PatchObject | Section 1.4.8 | 3108 | | | 3109 | RecurrenceRule | Section 4.3.2 | 3110 | | | 3111 | Relation | Section 1.4.10 | 3112 | | | 3113 | SignedDuration | Section 1.4.6 | 3114 | | | 3115 | String | Section 1.3 | 3116 | | | 3117 | TimeZone | Section 4.7.2 | 3118 | | | 3119 | TimeZoneRule | Section 4.7.2 | 3120 | | | 3121 | UnsignedInt | Section 1.4.2 | 3122 | | | 3123 | UTCDateTime | Section 1.4.3 | 3124 | | | 3125 | VirtualLocation | Section 4.2.6 | 3126 +-----------------+--------------------------+ 3128 Table 2 3130 8.4. Creation of "JSCalendar Enum Values" Registry 3132 The IANA will create the "JSCalendar Enum Values" registry to allow 3133 interoperable extension of semantics for properties with enumerable 3134 values. Each such property will have a subregistry of allowed 3135 values. The registration process for a new enum value or adding a 3136 new enumerable property is the same as for the JSCalendar Properties 3137 registry, as defined in Section 8.2. 3139 8.4.1. JMAP Enum Property Template 3141 This template is for adding a subregistry for a new enumerable 3142 property to the JMAP Enum registry. 3144 o Registry Name: This MUST be of the form "Enum Values for 3145 {property-name} (Context: {context})" where: 3147 {property-name} is the name(s) of the property or properties where 3148 these values may be used. This MUST be registered in the 3149 JSCalendar Properties registry. 3151 {context} is the list of allowed object types where the property 3152 or properties may appear, as registered in the JSCalendar 3153 Properties registry. This disambiguates where there may be two 3154 distinct properties with the same name in different contexts. 3156 o Change Controller: ("IETF" for properties defined in IETF-stream 3157 RFCs). 3159 o Initial Contents: The initial list of defined values for this 3160 enum, using the template defined in Section 8.4.2. 3162 8.4.2. JMAP Enum Value Template 3164 This template is for adding a new enum value to a subregistry in the 3165 JMAP Enum registry. 3167 o Enum Value: The verbatim value of the enum. 3169 o Reference or Description: A brief description or RFC number and 3170 section reference for the semantics of this value. 3172 8.4.3. Initial Contents for the JSCalendar Enum Registry 3174 For each subregistry created in this section, all RFC section 3175 references are for this document and the change controller is IETF. 3177 ------------------------------------------------------------ 3178 Enum Values for action (Context: Alert) 3180 +------------+--------------------------+ 3181 | Enum Value | Reference or Description | 3182 +------------+--------------------------+ 3183 | display | Section 4.5.2 | 3184 | | | 3185 | email | Section 4.5.2 | 3186 +------------+--------------------------+ 3188 Table 3 3190 ------------------------------------------------------------ 3192 Enum Values for display (Context: Link) 3194 +------------+--------------------------+ 3195 | Enum Value | Reference or Description | 3196 +------------+--------------------------+ 3197 | badge | Section 4.2.7 | 3198 | | | 3199 | graphic | Section 4.2.7 | 3200 | | | 3201 | fullsize | Section 4.2.7 | 3202 | | | 3203 | thumbnail | Section 4.2.7 | 3204 +------------+--------------------------+ 3206 Table 4 3208 ------------------------------------------------------------ 3210 Enum Values for freeBusyStatus (Context: JSEvent, JSTask) 3212 +------------+--------------------------+ 3213 | Enum Value | Reference or Description | 3214 +------------+--------------------------+ 3215 | free | Section 4.4.2 | 3216 | | | 3217 | busy | Section 4.4.2 | 3218 +------------+--------------------------+ 3220 Table 5 3222 ------------------------------------------------------------ 3224 Enum Values for kind (Context: Participant) 3225 +------------+--------------------------+ 3226 | Enum Value | Reference or Description | 3227 +------------+--------------------------+ 3228 | individual | Section 4.4.5 | 3229 | | | 3230 | group | Section 4.4.5 | 3231 | | | 3232 | resource | Section 4.4.5 | 3233 | | | 3234 | location | Section 4.4.5 | 3235 +------------+--------------------------+ 3237 Table 6 3239 ------------------------------------------------------------ 3241 Enum Values for participationStatus (Context: Participant) 3243 +--------------+--------------------------+ 3244 | Enum Value | Reference or Description | 3245 +--------------+--------------------------+ 3246 | needs-action | Section 4.4.5 | 3247 | | | 3248 | accepted | Section 4.4.5 | 3249 | | | 3250 | declined | Section 4.4.5 | 3251 | | | 3252 | tenative | Section 4.4.5 | 3253 | | | 3254 | delegated | Section 4.4.5 | 3255 +--------------+--------------------------+ 3257 Table 7 3259 ------------------------------------------------------------ 3261 Enum Values for privacy (Context: JSEvent, JSTask) 3262 +------------+--------------------------+ 3263 | Enum Value | Reference or Description | 3264 +------------+--------------------------+ 3265 | public | Section 4.4.3 | 3266 | | | 3267 | private | Section 4.4.3 | 3268 | | | 3269 | secret | Section 4.4.3 | 3270 +------------+--------------------------+ 3272 Table 8 3274 ------------------------------------------------------------ 3276 Enum Values for progress (Context: JSTask, Participant) 3278 +--------------+--------------------------+ 3279 | Enum Value | Reference or Description | 3280 +--------------+--------------------------+ 3281 | needs-action | Section 5.2.4 | 3282 | | | 3283 | in-process | Section 5.2.4 | 3284 | | | 3285 | completed | Section 5.2.4 | 3286 | | | 3287 | failed | Section 5.2.4 | 3288 | | | 3289 | cancelled | Section 5.2.4 | 3290 +--------------+--------------------------+ 3292 Table 9 3294 ------------------------------------------------------------ 3296 Enum Values for relation (Context: Relation) 3297 +------------+--------------------------+ 3298 | Enum Value | Reference or Description | 3299 +------------+--------------------------+ 3300 | first | Section 1.4.10 | 3301 | | | 3302 | next | Section 1.4.10 | 3303 | | | 3304 | child | Section 1.4.10 | 3305 | | | 3306 | parent | Section 1.4.10 | 3307 +------------+--------------------------+ 3309 Table 10 3311 ------------------------------------------------------------ 3313 Enum Values for relativeTo (Context: OffsetTrigger, Location) 3315 +------------+--------------------------+ 3316 | Enum Value | Reference or Description | 3317 +------------+--------------------------+ 3318 | start | Section 4.5.2 | 3319 | | | 3320 | end | Section 4.5.2 | 3321 +------------+--------------------------+ 3323 Table 11 3325 ------------------------------------------------------------ 3327 Enum Values for roles (Context: Participant) 3329 +---------------+--------------------------+ 3330 | Enum Value | Reference or Description | 3331 +---------------+--------------------------+ 3332 | owner | Section 4.4.5 | 3333 | | | 3334 | attendee | Section 4.4.5 | 3335 | | | 3336 | optional | Section 4.4.5 | 3337 | | | 3338 | informational | Section 4.4.5 | 3339 | | | 3340 | chair | Section 4.4.5 | 3341 +---------------+--------------------------+ 3343 Table 12 3345 ------------------------------------------------------------ 3347 Enum Values for scheduleAgent (Context: Participant) 3349 +------------+--------------------------+ 3350 | Enum Value | Reference or Description | 3351 +------------+--------------------------+ 3352 | server | Section 4.4.5 | 3353 | | | 3354 | client | Section 4.4.5 | 3355 | | | 3356 | none | Section 4.4.5 | 3357 +------------+--------------------------+ 3359 Table 13 3361 ------------------------------------------------------------ 3363 Enum Values for status (Context: JSEvent) 3365 +------------+--------------------------+ 3366 | Enum Value | Reference or Description | 3367 +------------+--------------------------+ 3368 | confirmed | Section 5.1.3 | 3369 | | | 3370 | cancelled | Section 5.1.3 | 3371 | | | 3372 | tentative | Section 5.1.3 | 3373 +------------+--------------------------+ 3375 Table 14 3377 9. Acknowledgments 3379 The authors would like to thank the members of CalConnect for their 3380 valuable contributions. This specification originated from the work 3381 of the API technical committee of CalConnect, the Calendaring and 3382 Scheduling Consortium. 3384 10. References 3386 10.1. Normative References 3388 [CLDR] "Unicode Common Locale Data Repository", 3389 . 3391 [COLORS] "CSS Color Module", . 3393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3394 Requirement Levels", BCP 14, RFC 2119, 3395 DOI 10.17487/RFC2119, March 1997, 3396 . 3398 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3399 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 3400 . 3402 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 3403 DOI 10.17487/RFC2397, August 1998, 3404 . 3406 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3407 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3408 . 3410 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 3411 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 3412 . 3414 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3415 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3416 . 3418 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3419 Specifications: ABNF", STD 68, RFC 5234, 3420 DOI 10.17487/RFC5234, January 2008, 3421 . 3423 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 3424 Scheduling Core Object Specification (iCalendar)", 3425 RFC 5545, DOI 10.17487/RFC5545, September 2009, 3426 . 3428 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3429 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3430 September 2009, . 3432 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 3433 Identifier for Geographic Locations ('geo' URI)", 3434 RFC 5870, DOI 10.17487/RFC5870, June 2010, 3435 . 3437 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3438 Specifications and Registration Procedures", BCP 13, 3439 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3440 . 3442 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 3443 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 3444 DOI 10.17487/RFC6901, April 2013, 3445 . 3447 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 3448 DOI 10.17487/RFC7493, March 2015, 3449 . 3451 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3452 Writing an IANA Considerations Section in RFCs", BCP 26, 3453 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3454 . 3456 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3457 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3458 May 2017, . 3460 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3461 Interchange Format", STD 90, RFC 8259, 3462 DOI 10.17487/RFC8259, December 2017, 3463 . 3465 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 3466 DOI 10.17487/RFC8288, October 2017, 3467 . 3469 [TZDB] "IANA Time Zone Database", 3470 . 3472 10.2. Informative References 3474 [LINKRELS] 3475 "IANA Link Relation Types", 3476 . 3479 [LOCATIONTYPES] 3480 "IANA Location Types Registry", 3481 . 3484 [MIME] "IANA Media Types", . 3487 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3488 Resource Identifier (URI): Generic Syntax", STD 66, 3489 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3490 . 3492 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3493 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3494 DOI 10.17487/RFC4122, July 2005, 3495 . 3497 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 3498 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 3499 DOI 10.17487/RFC4791, March 2007, 3500 . 3502 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 3503 Interoperability Protocol (iTIP)", RFC 5546, 3504 DOI 10.17487/RFC5546, December 2009, 3505 . 3507 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 3508 Interoperability Protocol (iMIP)", RFC 6047, 3509 DOI 10.17487/RFC6047, December 2010, 3510 . 3512 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 3513 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 3514 2014, . 3516 [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules 3517 in the Internet Calendaring and Scheduling Core Object 3518 Specification (iCalendar)", RFC 7529, 3519 DOI 10.17487/RFC7529, May 2015, 3520 . 3522 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 3523 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 3524 . 3526 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 3527 DOI 10.17487/RFC7986, October 2016, 3528 . 3530 Authors' Addresses 3531 Neil Jenkins 3532 Fastmail 3533 PO Box 234 3534 Collins St West 3535 Melbourne VIC 8007 3536 Australia 3538 Email: neilj@fastmailteam.com 3539 URI: https://www.fastmail.com 3541 Robert Stepanek 3542 Fastmail 3543 PO Box 234 3544 Collins St West 3545 Melbourne VIC 8007 3546 Australia 3548 Email: rsto@fastmailteam.com 3549 URI: https://www.fastmail.com