idnits 2.17.1 draft-ietf-calext-jscalendar-23.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 (February 18, 2020) is 1529 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 2736, but not defined == Missing Reference: 'Boolean' is mentioned on line 2952, but not defined == Missing Reference: 'Link' is mentioned on line 2863, but not defined == Missing Reference: 'PatchObject' is mentioned on line 2927, but not defined == Missing Reference: 'Location' is mentioned on line 2877, but not defined == Missing Reference: 'Participant' is mentioned on line 2899, but not defined == Missing Reference: 'Relation' is mentioned on line 2936, but not defined == Missing Reference: 'String' is mentioned on line 2967, but not defined == Missing Reference: 'TimeZone' is mentioned on line 2998, but not defined == Missing Reference: 'VirtualLocation' is mentioned on line 3026, but not defined Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). 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: August 21, 2020 February 18, 2020 7 JSCalendar: A JSON representation of calendar data 8 draft-ietf-calext-jscalendar-23 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 15 alternative, and over time successor to, the widely deployed 16 iCalendar data format and to be unambiguous, extendable and simple to 17 process. In contrast to the JSON-based jCal format, it is not a 18 direct mapping from iCalendar and expands semantics where 19 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 August 21, 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 . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . 42 119 5.1. JSEvent Properties . . . . . . . . . . . . . . . . . . . 42 120 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 42 121 5.1.2. duration . . . . . . . . . . . . . . . . . . . . . . 43 122 5.1.3. status . . . . . . . . . . . . . . . . . . . . . . . 43 123 5.2. JSTask Properties . . . . . . . . . . . . . . . . . . . . 43 124 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . . . . . 46 135 6.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 47 136 6.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 47 137 6.5. Task with a due date . . . . . . . . . . . . . . . . . . 48 138 6.6. Event with end time-zone . . . . . . . . . . . . . . . . 48 139 6.7. Floating-time event (with recurrence) . . . . . . . . . . 49 140 6.8. Event with multiple locations and localization . . . . . 49 141 6.9. Recurring event with overrides . . . . . . . . . . . . . 50 142 6.10. Recurring event with participants . . . . . . . . . . . . 51 143 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 144 7.1. Expanding Recurrences . . . . . . . . . . . . . . . . . . 53 145 7.2. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 53 146 7.3. URI Values . . . . . . . . . . . . . . . . . . . . . . . 54 147 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 148 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 54 149 8.2. Creation of "JSCalendar Properties" Registry . . . . . . 55 150 8.2.1. Preliminary Community Review . . . . . . . . . . . . 56 151 8.2.2. Submit Request to IANA . . . . . . . . . . . . . . . 56 152 8.2.3. Designated Expert Review . . . . . . . . . . . . . . 56 153 8.2.4. Change Procedures . . . . . . . . . . . . . . . . . . 57 154 8.2.5. JMAP Properties Registry Template . . . . . . . . . . 57 155 8.2.6. Initial Contents for the JSCalendar Properties 156 Registry . . . . . . . . . . . . . . . . . . . . . . 58 157 8.3. Creation of "JSCalendar Types" Registry . . . . . . . . . 65 158 8.3.1. JMAP Types Registry Template . . . . . . . . . . . . 65 159 8.3.2. Initial Contents for the JSCalendar Types Registry . 65 160 8.4. Creation of "JSCalendar Enum Values" Registry . . . . . . 67 161 8.4.1. JMAP Enum Subregistry Creation Template . . . . . . . 67 162 8.4.2. JMAP Enum Subregistry Template . . . . . . . . . . . 67 163 8.4.3. Initial Contents for the JSCalendar Enum Registry . . 68 164 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 72 165 10. Informative References . . . . . . . . . . . . . . . . . . . 72 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 168 1. Introduction 170 This document defines a data model for calendar event and task 171 objects, or groups of such objects, in electronic calendar 172 applications and systems. It aims to be unambiguous, extendable and 173 simple to process. 175 The key design considerations for this data model are as follows: 177 o The attributes of the calendar entry represented must be described 178 as a simple key-value pair. Simple events are simple to 179 represent, complex events can be modelled accurately. 181 o Wherever possible, there should be only one way to express the 182 desired semantics, reducing complexity. 184 o The data model should avoid ambiguities and make it difficult to 185 make mistakes during implementation. 187 o The data model should be compatible with the iCalendar data format 188 [RFC5545] [RFC7986] and extensions, but the specification should 189 add new attributes where the iCalendar format currently lacks 190 expressivity, and drop widely unused, obsolete or redundant 191 properties. This means translation with no loss of semantics 192 should be easy with most common iCalendar files but is not 193 guaranteed with the full specification. 195 o Extensions, such as new properties and components, MUST NOT lead 196 to requiring an update to this document. 198 The representation of this data model is defined in the I-JSON format 199 [RFC7493], which is a strict subset of the JavaScript Object Notation 200 (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a 201 pragmatic choice: its widespread use makes JSCalendar easier to 202 adopt, and the ready availability of production-ready JSON 203 implementations eliminates a whole category of parser-related 204 interoperability issues, which iCalendar has often suffered from. 206 1.1. Motivation and Relation to iCalendar and jCal 208 The iCalendar data format [RFC5545], a widely deployed interchange 209 format for calendaring and scheduling data, has served calendaring 210 vendors for a long while, but contains some ambiguities and pitfalls 211 that can not be overcome without backward-incompatible changes. 213 For example, iCalendar defines various formats for local times, UTC 214 time and dates, which confuses new users and often leads to 215 implementation errors. Other sources for errors are the requirement 216 for custom time zone definitions within a single calendar component, 217 as well as the iCalendar format itself; the latter causing 218 interoperability issues due to misuse of CR LF terminated strings, 219 line continuations and subtle differences between iCalendar parsers. 220 The definition of recurrence rules is ambiguous and has resulted in 221 differing understandings even between experienced calendar 222 developers. 224 In recent years, many new products and services have appeared that 225 wish to use a JSON representation of calendar data within their API. 226 The JSON format for iCalendar data, jCal [RFC7265], is a direct 227 mapping between iCalendar and JSON. In its effort to represent full 228 iCalendar semantics, it inherits all the same pitfalls and uses a 229 complicated JSON structure unlike most common JSON data 230 representations. 232 As a consequence, since the standardization of jCal, the majority of 233 implementations and service providers either kept using iCalendar, or 234 came up with their own proprietary JSON representations, which are 235 incompatible with each other and often suffer from common pitfalls, 236 such as storing event start times in UTC (which become incorrect if 237 the timezone's rules change in the future). JSCalendar is intended 238 to meet this demand for JSON-formatted calendar data, and to provide 239 a standard, elegant representation as an alternative to new 240 proprietary formats. 242 1.2. Notational Conventions 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. 248 The underlying format used for this specification is JSON. 249 Consequently, the terms "object" and "array" as well as the four 250 primitive types (strings, numbers, booleans, and null) are to be 251 interpreted as described in Section 1 of [RFC8259]. 253 Some examples in this document contain "partial" JSON documents used 254 for illustrative purposes. In these examples, three periods "..." 255 are used to indicate a portion of the document that has been removed 256 for compactness. 258 1.3. Type Signatures 260 Type signatures are given for all JSON values in this document. The 261 following conventions are used: 263 o "*" - The type is undefined (the value could be any type, although 264 permitted values may be constrained by the context of this value). 266 o "String" - The JSON string type. 268 o "Number" - The JSON number type. 270 o "Boolean" - The JSON boolean type. 272 o "A[B]" - A JSON object where the keys are all of type "A", and the 273 values are all of type "B". 275 o "A[]" - An array of values of type "A". 277 o "A|B" - The value is either of type "A" or of type "B". 279 Other types may also be given, with their representation defined 280 elsewhere in this document. 282 1.4. Data Types 284 In addition to the standard JSON data types, the following data types 285 are used in this specification: 287 1.4.1. Int 289 Where "Int" is given as a data type, it means an integer in the range 290 -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a 291 floating-point double, represented as a JSON "Number". 293 1.4.2. UnsignedInt 295 Where "UnsignedInt" is given as a data type, it means an "Int" where 296 the value MUST be in the range 0 <= value <= 2^53-1. 298 1.4.3. UTCDateTime 300 This is a string in [RFC3339] "date-time" format, with the further 301 restrictions that any letters MUST be in uppercase, the time 302 component MUST be included and the time offset MUST be the character 303 "Z". Fractional second values MUST NOT be included unless non-zero 304 and MUST NOT have trailing zeros, to ensure there is only a single 305 representation for each date-time. 307 For example "2010-10-10T10:10:10.003Z" is OK, but 308 "2010-10-10T10:10:10.000Z" is invalid and MUST be encoded as 309 "2010-10-10T10:10:10Z". 311 In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". 313 1.4.4. LocalDateTime 315 This is a date-time string with no time zone/offset information. It 316 is otherwise in the same format as UTCDateTime, including fractional 317 seconds. For example "2006-01-02T15:04:05" and 318 "2006-01-02T15:04:05.003" are both valid. The time zone to associate 319 the LocalDateTime with comes from an associated property, or if no 320 time zone is associated it defines *floating time*. Floating date- 321 times are not tied to any specific time zone. Instead, they occur in 322 every time zone at the same wall-clock time (as opposed to the same 323 instant point in time). 325 1.4.5. Duration 327 Where Duration is given as a type, it means a length of time 328 represented by a subset of ISO8601 duration format, as specified by 329 the following ABNF: 331 dur-secfrac = "." 1*DIGIT 332 dur-second = 1*DIGIT [dur-secfrac] "S" 333 dur-minute = 1*DIGIT "M" [dur-second] 334 dur-hour = 1*DIGIT "H" [dur-minute] 335 dur-time = "T" (dur-hour / dur-minute / dur-second) 336 dur-day = 1*DIGIT "D" 337 dur-week = 1*DIGIT "W" 339 duration = "P" (dur-day [dur-time] / dur-time / dur-week) 341 In addition, the duration MUST NOT include fractional second values 342 unless the fraction is non-zero. 344 1.4.6. SignedDuration 346 A SignedDuration represents a length of time that may be positive or 347 negative and is typically used to express the offset of a point in 348 time relative to an associated time. It is represented as a 349 Duration, optionally preceded by a sign character. It is specified 350 by the following ABNF: 352 signed-duration = (["+"] / "-") duration 354 A negative sign indicates a point in time at or before the associated 355 time, a positive or no sign a time at or after the associated time. 357 1.4.7. Id 359 Where "Id" is given as a data type, it means a "String" of at least 1 360 and a maximum of 255 octets in size, and it MUST only contain 361 characters from the "URL and Filename Safe" base64 alphabet, as 362 defined in Section 5 of [RFC4648], excluding the pad character ("="). 363 This means the allowed characters are the ASCII alphanumeric 364 characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). 366 Unless otherwise specified, Ids are arbitrary and only have meaning 367 within the object where they are being used. Ids need not be unique 368 between different objects. For example, two JSEvent objects MAY use 369 the same ids in their respective "links" properties. Or within the 370 same JSEvent object the same Id could appear in the "participants" 371 and "alerts" properties. This does not imply any semantic connection 372 between the two. 374 Nevertheless, a UUID is typically a good choice. 376 1.4.8. PatchObject 378 A PatchObject is of type "String[*]", and represents an unordered set 379 of patches on a JSON object. The keys are a path in a subset of 380 [RFC6901] JSON pointer format, with an implicit leading "/" (i.e. 381 prefix each key with "/" before applying the JSON pointer evaluation 382 algorithm). 384 A patch within a PatchObject is only valid if all of the following 385 conditions apply: 387 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT 388 insert/delete from an array; the array MUST be replaced in its 389 entirety instead). 391 2. When evaluating a path, all parts prior to the last (i.e. the 392 value after the final slash) MUST exist. 394 3. There MUST NOT be two patches in the PatchObject where the 395 pointer of one is the prefix of the pointer of the other, e.g. 396 "alerts/foo/offset" and "alerts". 398 The value associated with each pointer is either: 400 o null: Remove the property from the patched object. If not present 401 in the parent, this a no-op. 403 o Anything else: The value to set for this property (this may be a 404 replacement or addition to the object being patched). 406 Implementations MUST reject a PatchObject if any of its patches are 407 invalid. 409 1.4.9. Time Zones 411 By default, time zones in JSCalendar are identified by their name in 412 the IANA Time Zone Database [TZDB], and the zone rules of the 413 respective zone record apply. 415 Implementations MAY embed the definition of custom time zones in the 416 "timeZones" property (see Section 4.7.2). 418 1.4.10. Relation 420 A Relation object defines the relation to other objects, using a 421 possibly empty set of relation types. The object that defines this 422 relation is the linking object, the other object is the linked 423 object. The Relation object has the following property: 425 o @type: "String" (mandatory) 427 Specifies the type of this object. This MUST be "Relation". 429 o relation: "String[Boolean]" (optional, default: empty Object) 431 Describes how the linked object is related to the linking object. 432 The relation is defined as a set of relation types. If empty, the 433 relationship between the two objects is unspecified. 435 Keys in the set MUST be one of the following values, or specified 436 in the property definition where the Relation object is used, or 437 an IANA-registered value, or a vendor-specific value: 439 * "first": The linked object is the first in a series the linking 440 object is part of. 442 * "next": The linked object is the next in a series the linking 443 object is part of. 445 * "child": The linked object is a subpart of the linking object. 447 * "parent": The linking object is part of the overall linked 448 object. 450 The value for each key in the set MUST be true. 452 Note, the Relation object only has one property (except @type); it is 453 specified as an object with a single property to allow for extension 454 in the future. 456 2. JSCalendar Objects 458 This section describes the calendar object types specified by 459 JSCalendar. 461 2.1. JSEvent 463 MIME type: "application/jscalendar+json;type=jsevent" 465 A JSEvent represents a scheduled amount of time on a calendar, 466 typically a meeting, appointment, reminder or anniversary. Multiple 467 participants may partake in the event at multiple locations. 469 The @type (Section 4.1.1) property value MUST be "jsevent". 471 2.2. JSTask 473 MIME type: "application/jscalendar+json;type=jstask" 475 A JSTask represents an action-item, assignment, to-do or work item. 477 The @type (Section 4.1.1) property value MUST be "jstask". 479 A JSTask may start and be due at certain points in time, may take 480 some estimated time to complete and may recur; none of which is 481 required. This notably differs from JSEvent (Section 2.1) which is 482 required to start at a certain point in time and typically takes some 483 non-zero duration to complete. 485 2.3. JSGroup 487 MIME type: "application/jscalendar+json;type=jsgroup" 489 A JSGroup is a collection of JSEvent (Section 2.1) and/or JSTask 490 (Section 2.2) objects. Typically, objects are grouped by topic (e.g. 491 by keywords) or calendar membership. 493 The @type (Section 4.1.1) property value MUST be "jsgroup". 495 3. Structure of JSCalendar Objects 497 A JSCalendar object is a JSON object, which MUST be valid I-JSON (a 498 stricter subset of JSON), as specified in [RFC8259]. Property names 499 and values are case-sensitive. 501 The object has a collection of properties, as specified in the 502 following sections. Properties are specified as being either 503 mandatory or optional. Optional properties may have a default value, 504 if explicitly specified in the property definition. 506 3.1. Normalization and Equivalence 508 JSCalendar aims to provide unambiguous definitions for value types 509 and properties, but does not define a general normalization or 510 equivalence method for JSCalendar objects and types. This is because 511 the notion of equivalence might range from byte-level equivalence to 512 semantic equivalence, depending on the respective use case (for 513 example, the CalDAV protocol [RFC4791] requires octet equivalence of 514 the encoded calendar object to determine ETag equivalence). 516 Normalization of JSCalendar objects is hindered because of the 517 following reasons: 519 o Custom JSCalendar properties may contain arbitrary JSON values, 520 including arrays. However, equivalence of arrays might or might 521 not depend on the order of elements, depending on the respective 522 property definition. 524 o Several JSCalendar property values are defined as URIs and MIME 525 types, but normalization of these types is inherently protocol and 526 scheme-specific, depending on the use-case of the equivalence 527 definition (see Section 6 of [RFC3986]). 529 Considering this, the definition of equivalence and normalization is 530 left to client and server implementations and to be negotiated by a 531 calendar exchange protocol or defined by another RFC. 533 3.2. Vendor-specific Property Extensions and Values 535 Vendors MAY add additional properties to the calendar object to 536 support their custom features. The names of these properties MUST be 537 prefixed with a domain name controlled by the vendor to avoid 538 conflict, e.g. "example.com/customprop". 540 Some JSCalendar properties allow vendor-specific value extensions. 541 If so, vendor-specific values MUST be prefixed with a domain name 542 controlled by the vendor, e.g. "example.com/customrel". 544 Vendors are strongly encouraged to register any new property values 545 or extensions that are useful to other systems as well, rather than 546 use a vendor-specific prefix. 548 4. Common JSCalendar Properties 550 This section describes the properties that are common to the various 551 JSCalendar object types. Specific JSCalendar object types may only 552 support a subset of these properties. The object type definitions in 553 Section 5 describe the set of supported properties per type. 555 4.1. Metadata Properties 557 4.1.1. @type 559 Type: "String" (mandatory). 561 Specifies the type which this object represents. This MUST be one of 562 the following values, an IANA-registered value, or a vendor-specific 563 value: 565 o "jsevent": a JSCalendar event (Section 2.1). 567 o "jstask": a JSCalendar task (Section 2.2). 569 o "jsgroup": a JSCalendar group (Section 2.3). 571 4.1.2. uid 573 Type: "String" (mandatory). 575 A globally unique identifier, used to associate the object as the 576 same across different systems, calendars and views. The value of 577 this property MUST be unique across all JSCalendar objects, even if 578 they are of different type. [RFC4122] describes a range of 579 established algorithms to generate universally unique identifiers 580 (UUID), and the random or pseudo-random version is recommended. 582 For compatibility with [RFC5545] UIDs, implementations MUST be able 583 to receive and persist values of at least 255 octets for this 584 property, but they MUST NOT truncate values in the middle of a UTF-8 585 multi-octet sequence. 587 4.1.3. relatedTo 589 Type: "String[Relation]" (optional). 591 Relates the object to other JSCalendar objects. This is represented 592 as a map of the UIDs of the related objects to information about the 593 relation. 595 If an object is split to make a "this and future" change to a 596 recurrence, the original object MUST be truncated to end at the 597 previous occurrence before this split, and a new object created to 598 represent all the occurrences after the split. A "next" relation 599 MUST be set on the original object's relatedTo property for the UID 600 of the new object. A "first" relation for the UID of the first 601 object in the series MUST be set on the new object. Clients can then 602 follow these UIDs to get the complete set of objects if the user 603 wishes to modify them all at once. 605 4.1.4. prodId 607 Type: "String" (optional). 609 The identifier for the product that last updated the JSCalendar 610 object. This should be set whenever the data in the object is 611 modified (i.e., whenever the "updated" property is set). 613 The vendor of the implementation SHOULD ensure that this is a 614 globally unique identifier, using some technique such as an FPI 615 value, as defined in [ISO.9070.1991]. It MUST only use characters of 616 an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]). 618 This property SHOULD NOT be used to alter the interpretation of a 619 JSCalendar object beyond the semantics specified in this document. 620 For example, it is not to be used to further the understanding of 621 non-standard properties. 623 4.1.5. created 625 Type: "UTCDateTime" (optional). 627 The date and time this object was initially created. 629 4.1.6. updated 631 Type: "UTCDateTime" (mandatory). 633 The date and time the data in this object was last modified. 635 4.1.7. sequence 637 Type: "UnsignedInt" (optional, default: 0). 639 Initially zero, this MUST be incremented by one every time a change 640 is made to the object, except if the change only modifies the 641 "participants" property (see Section 4.4.5). 643 This is used as part of iTIP [RFC5546] to know which version of the 644 object a scheduling message relates to. 646 4.1.8. method 648 Type: "String" (optional). 650 The iTIP [RFC5546] method, in lowercase. This MUST only be present 651 if the JSCalendar object represents an iTIP scheduling message. 653 4.2. What and Where Properties 655 4.2.1. title 657 Type: "String" (optional, default: empty String). 659 A short summary of the object. 661 4.2.2. description 663 Type: "String" (optional, default: empty String). 665 A longer-form text description of the object. The content is 666 formatted according to the "descriptionContentType" property. 668 4.2.3. descriptionContentType 670 Type: "String" (optional, default: "text/plain"). 672 Describes the media type [RFC6838] of the contents of the 673 "description" property. Media types MUST be sub-types of type 674 "text", and SHOULD be "text/plain" or "text/html" [MIME]. They MAY 675 define parameters and the "charset" parameter value MUST be "utf-8", 676 if specified. Descriptions of type "text/html" MAY contain "cid" 677 URLs [RFC2392] to reference links in the calendar object by use of 678 the "cid" property of the Link object. 680 4.2.4. showWithoutTime 682 Type: "Boolean" (optional, default: false). 684 Indicates the time is not important to display to the user when 685 rendering this calendar object, for example an event that 686 conceptually occurs all day or across multiple days, such as "New 687 Year's Day" or "Italy Vacation". While the time component is 688 important for free-busy calculations and checking for scheduling 689 clashes, calendars may choose to omit displaying it and/or display 690 the object separately to other objects to enhance the user's view of 691 their schedule. 693 Such events are also commonly known as "all-day" events. 695 4.2.5. locations 697 Type: "Id[Location]" (optional). 699 A map of location ids to Location objects, representing locations 700 associated with the object. 702 A Location object has the following properties. It MUST have at 703 least one property other than the "relativeTo" property. 705 o @type: "String" (mandatory) 707 Specifies the type of this object. This MUST be "Location". 709 o name: "String" (optional) 711 The human-readable name of the location. 713 o description: "String" (optional) 715 Human-readable, plain-text instructions for accessing this 716 location. This may be an address, set of directions, door access 717 code, etc. 719 o locationTypes: "String[Boolean]" (optional) 721 A set of one or more location types that describe this location. 722 All types MUST be from the Location Types Registry as defined in 723 [RFC4589]. The set is represented as a map, with the keys being 724 the location types. The value for each key in the map MUST be 725 true. 727 o relativeTo: "String" (optional) 729 The relation type of this location to the JSCalendar object. 731 This MUST be either one of the following values, an IANA- 732 registered value, or a vendor-specific value. Any value the 733 client or server doesn't understand should be treated the same as 734 if this property is omitted. 736 * "start": The JSCalendar object starts at this location. 738 * "end": The JSCalendar object ends at this location. 740 o timeZone: "String" (optional) 742 A time zone for this location. See also Section 1.4.9. 744 o coordinates: "String" (optional) 746 A "geo:" URI [RFC5870] for the location. 748 o linkIds: "Id[Boolean]" (optional) 750 A set of link ids for links to alternate representations of this 751 location. Each key in the set MUST be the id of a Link object 752 defined in the "links" property of this calendar object. The 753 value for each key in the set MUST be true. This MUST be omitted 754 if none (rather than an empty set). 756 For example, an alternative representation could be in vCard 757 format. 759 4.2.6. virtualLocations 761 Type: "Id[VirtualLocation]" (optional). 763 A map of ids to VirtualLocation objects, representing virtual 764 locations, such as video conferences or chat rooms, associated with 765 the object. 767 A VirtualLocation object has the following properties. 769 o @type: "String" (mandatory) 771 Specifies the type of this object. This MUST be 772 "VirtualLocation". 774 o name: "String" (optional, default: empty String) 776 The human-readable name of the virtual location. 778 o description: "String" (optional) 780 Human-readable plain-text instructions for accessing this 781 location. This may be an address, set of directions, door access 782 code, etc. 784 o uri: "String" (mandatory) 786 A URI that represents how to connect to this virtual location. 788 This may be a telephone number (represented using the "tel:" 789 scheme, e.g., "tel:+1-555-555-555") for a teleconference, a web 790 address for online chat, or any custom URI. 792 4.2.7. links 794 Type: "Id[Link]" (optional). 796 A map of link ids to Link objects, representing external resources 797 associated with the object. 799 A Link object has the following properties: 801 o @type: "String" (mandatory) 803 Specifies the type of this object. This MUST be "Link". 805 o href: "String" (mandatory) 807 A URI from which the resource may be fetched. 809 This MAY be a "data:" URL, but it is recommended that the file be 810 hosted on a server to avoid embedding arbitrarily large data in 811 JSCalendar object instances. 813 o cid: "String" (optional) 815 This MUST be a valid "content-id" value according to the 816 definition of Section 2 in [RFC2392]. The value MUST be unique 817 within this Link object but has no meaning beyond that. It MAY be 818 different from the link id for this Link object. 820 o contentType: "String" (optional) 822 The content-type [RFC6838] of the resource, if known. 824 o size: "UnsignedInt" (optional) 826 The size, in octets, of the resource when fully decoded (i.e. the 827 number of octets in the file the user would download), if known. 829 o rel: "String" (optional) 831 Identifies the relation of the linked resource to the object. If 832 set, the value MUST be a relation type from the IANA registry 833 [LINKRELS], as established in [RFC8288]. 835 Links with a rel of "enclosure" SHOULD be considered by the client 836 as attachments for download. 838 Links with a rel of "describedby" SHOULD be considered by the 839 client to be an alternate representation of the description. 841 Links with a rel of "icon" SHOULD be considered by the client to 842 be an image that it MAY use when presenting the calendar data to a 843 user. The "display" property MAY be set to indicate the purpose 844 of this image. 846 o display: "String" (optional) 848 Describes the intended purpose of a link to an image. If set, the 849 "rel" property MUST be set to "icon". The value MUST be either 850 one of the following values, an IANA-registered value, or a 851 vendor-specific value: 853 * "badge": an image inline with the title of the object. 855 * "graphic": a full image replacement for the object itself. 857 * "fullsize": an image that is used to enhance the object. 859 * "thumbnail": a smaller variant of "fullsize" to be used when 860 space for the image is constrained. 862 o title: "String" (optional) 864 A human-readable plain-text description of the resource. 866 4.2.8. locale 868 Type: "String" (optional). 870 The language tag as defined in [RFC5646] that best describes the 871 locale used for the text in the calendar object, if known. 873 4.2.9. keywords 875 Type: "String[Boolean]" (optional). 877 A set of keywords or tags that relate to the object. The set is 878 represented as a map, with the keys being the keywords. The value 879 for each key in the map MUST be true. 881 4.2.10. categories 883 Type: "String[Boolean]" (optional). 885 A set of categories that relate to the calendar object. The set is 886 represented as a map, with the keys being the categories specified as 887 URIs. The value for each key in the map MUST be true. 889 In contrast to keywords, categories typically are structured. For 890 example, a vendor owning the domain "example.com" might define the 891 categories "http://example.com/categories/sports/american-football"" 892 and "http://example.com/categories/music/r-b". 894 4.2.11. color 896 Type: "String" (optional). 898 A color clients MAY use when displaying this calendar object. The 899 value is a case-insensitive color name taken from the set of names 900 defined in Section 4.3 of CSS Color Module Level 3 [COLORS], or an 901 RGB value in hexadecimal notation, as defined in Section 4.2.1 of CSS 902 Color Module Level 3. 904 4.3. Recurrence Properties 906 Some events and tasks occur at regular, or indeed irregular, 907 intervals. Rather than having to copy the data for every occurrence, 908 you can instead have a master event with a recurrence rule generating 909 the occurrences, and/or overrides that add extra dates or exceptions 910 to the rule. 912 4.3.1. recurrenceId 914 Type: "LocalDateTime" (optional). 916 If present, this JSCalendar object represents one occurrence of a 917 recurring JSCalendar object. If present the "recurrenceRules" and 918 "recurrenceOverrides" properties MUST NOT be present. 920 The value is a date-time either produced by the "recurrenceRules" of 921 the master event, or added as a key to the "recurrenceOverrides" 922 property of the master event. 924 4.3.2. recurrenceRules 926 Type: "RecurrenceRule[]" (optional). 928 Defines a set of recurrence rules (repeating patterns) for recurring 929 calendar objects. 931 A JSEvent recurs by applying the recurrence rules to the "start" 932 date-time. 934 A JSTask recurs by applying the recurrence rules to the "start" date- 935 time, if defined, otherwise it recurs by the "due" date-time, if 936 defined. If the task defines neither a "start" nor "due" date-time, 937 its "recurrenceRules" property value MUST be null. 939 If multiple recurrence rules are given, each rule is to be applied 940 and then the union of the results used, ignoring any duplicates. 942 A RecurrenceRule object is a JSON object mapping of a RECUR value 943 type in iCalendar [RFC5545] [RFC7529] and has the same semantics. It 944 has the following properties: 946 o @type: "String" (mandatory) 948 Specifies the type of this object. This MUST be "RecurrenceRule". 950 o frequency: "String" (mandatory) 952 The time span covered by each iteration of this recurrence rule 953 (see Section 4.3.2.1 for full semantics). This MUST be one of the 954 following values: 956 * "yearly" 958 * "monthly" 960 * "weekly" 962 * "daily" 964 * "hourly" 966 * "minutely" 968 * "secondly" 970 This is the FREQ part from iCalendar, converted to lowercase. 972 o interval: "UnsignedInt" (optional, default: 1) 974 The interval of iteration periods at which the recurrence repeats. 975 If included, it MUST be an integer >= 1. 977 This is the INTERVAL part from iCalendar. 979 o rscale: "String" (optional, default: "gregorian") 981 The calendar system in which this recurrence rule operates, in 982 lowercase. This MUST be either a CLDR-registered calendar system 983 name, or a non-standard, experimental calendar system name 984 prefixed with the characters "x-". 986 This is the RSCALE part from iCalendar RSCALE [RFC7529], converted 987 to lowercase. 989 o skip: "String" (optional, default: "omit") 991 The behaviour to use when the expansion of the recurrence produces 992 invalid dates. This property only has an effect if the frequency 993 is "yearly" or "monthly". It MUST be one of the following values: 995 * "omit" 997 * "backward" 998 * "forward" 1000 This is the SKIP part from iCalendar RSCALE [RFC7529], converted 1001 to lowercase. 1003 o firstDayOfWeek: "String" (optional, default: "mo") 1005 The day on which the week is considered to start, represented as a 1006 lowercase abbreviated two-letter English day of the week. If 1007 included, it MUST be one of the following values: 1009 * "mo" 1011 * "tu" 1013 * "we" 1015 * "th" 1017 * "fr" 1019 * "sa" 1021 * "su" 1023 This is the WKST part from iCalendar. 1025 o byDay: "NDay[]" (optional) 1027 Days of the week on which to repeat. An *NDay* object has the 1028 following properties: 1030 * day: "String" (mandatory) 1032 A day of the week on which to repeat; the allowed values are 1033 the same as for the "firstDayOfWeek" RecurrenceRule property. 1035 This is the day-of-the-week of the BYDAY part in iCalendar, 1036 converted to lowercase. 1038 * nthOfPeriod: "Int" (optional) 1040 If present, rather than representing every occurrence of the 1041 weekday defined in the "day" property, it represents only a 1042 specific instance within the recurrence period. The value can 1043 be positive or negative, but MUST NOT be zero. A negative 1044 integer means nth-last of period. 1046 This is the ordinal part of the BYDAY value in iCalendar (e.g. 1047 1 or -3). 1049 o byMonthDay: "Int[]" (optional) 1051 Days of the month on which to repeat. Valid values are between 1 1052 and the maximum number of days any month may have in the calendar 1053 given by the "rscale" property, and the negative values of these 1054 numbers. For example, in the Gregorian calendar valid values are 1055 1 to 31 and -31 to -1. Negative values offset from the end of the 1056 month. The array MUST have at least one entry if included. 1058 This is the BYMONTHDAY part in iCalendar. 1060 o byMonth: "String[]" (optional) 1062 The months in which to repeat. Each entry is a string 1063 representation of a number, starting from "1" for the first month 1064 in the calendar (e.g. "1" means January with the Gregorian 1065 calendar), with an optional "L" suffix (see [RFC7529]) for leap 1066 months (this MUST be uppercase, e.g. "3L"). The array MUST have 1067 at least one entry if included. 1069 This is the BYMONTH part from iCalendar. 1071 o byYearDay: "Int[]" (optional) 1073 The days of the year on which to repeat. Valid values are between 1074 1 and the maximum number of days any year may have in the calendar 1075 given by the "rscale" property, and the negative values of these 1076 numbers. For example, in the Gregorian calendar valid values are 1077 1 to 366 and -366 to -1. Negative values offset from the end of 1078 the year. The array MUST have at least one entry if included. 1080 This is the BYYEARDAY part from iCalendar. 1082 o byWeekNo: "Int[]" (optional) 1084 Weeks of the year in which to repeat. Valid values are between 1 1085 and the maximum number of weeks any year may have in the calendar 1086 given by the "rscale" property, and the negative values of these 1087 numbers. For example, in the Gregorian calendar valid values are 1088 1 to 53 and -53 to -1. The array MUST have at least one entry if 1089 included. 1091 This is the BYWEEKNO part from iCalendar. 1093 o byHour: "UnsignedInt[]" (optional) 1094 The hours of the day in which to repeat. Valid values are 0 to 1095 23. The array MUST have at least one entry if included. This is 1096 the BYHOUR part from iCalendar. 1098 o byMinute: "UnsignedInt[]" (optional) 1100 The minutes of the hour in which to repeat. Valid values are 0 to 1101 59. The array MUST have at least one entry if included. 1103 This is the BYMINUTE part from iCalendar. 1105 o bySecond: "UnsignedInt[]" (optional) 1107 The seconds of the minute in which to repeat. Valid values are 0 1108 to 60. The array MUST have at least one entry if included. 1110 This is the BYSECOND part from iCalendar. 1112 o bySetPosition: "Int[]" (optional) 1114 The occurrences within the recurrence interval to include in the 1115 final results. Negative values offset from the end of the list of 1116 occurrences. The array MUST have at least one entry if included. 1117 This is the BYSETPOS part from iCalendar. 1119 o count: "UnsignedInt" (optional) 1121 The number of occurrences at which to range-bound the recurrence. 1122 This MUST NOT be included if an "until" property is specified. 1124 This is the COUNT part from iCalendar. 1126 o until: "LocalDateTime" (optional) 1128 The date-time at which to finish recurring. The last occurrence 1129 is on or before this date-time. This MUST NOT be included if a 1130 "count" property is specified. Note: if not specified otherwise 1131 for a specific JSCalendar object, this date is to be interpreted 1132 in the time zone specified in the JSCalendar object's "timeZone" 1133 property. 1135 This is the UNTIL part from iCalendar. 1137 4.3.2.1. Interpreting recurrence rules 1139 A recurrence rule specifies a set of date-times for recurring 1140 calendar objects. A recurrence rule has the following semantics. 1141 Note, wherever "year", "month" or "day of month" is used, this is 1142 within the calendar system given by the "rscale" property, which 1143 defaults to "gregorian" if omitted. 1145 1. A set of candidates is generated. This is every second within a 1146 period defined by the frequency property value: 1148 * "yearly": every second from midnight on the 1st day of a year 1149 (inclusive) to midnight the 1st day of the following year 1150 (exclusive). 1152 If skip is not "omit", the calendar system has leap months and 1153 there is a byMonth property, generate candidates for the leap 1154 months even if they don't occur in this year. 1156 If skip is not "omit" and there is a byMonthDay property, 1157 presume each month has the maximum number of days any month 1158 may have in this calendar system when generating candidates, 1159 even if it's more than this month actually has. 1161 * "monthly": every second from midnight on the 1st day of a 1162 month (inclusive) to midnight on the 1st of the following 1163 month (exclusive). 1165 If skip is not "omit" and there is a byMonthDay property, 1166 presume the month has the maximum number of days any month may 1167 have in this calendar system when generating candidates, even 1168 if it's more than this month actually has. 1170 * "weekly": every second from midnight (inclusive) on the first 1171 day of the week (as defined by the firstDayOfWeek property, or 1172 Monday if omitted), to midnight 7 days later (exclusive). 1174 * "daily": every second from midnight at the start of the day 1175 (inclusive) to midnight at the end of the day (exclusive). 1177 * "hourly": every second from the beginning of the hour 1178 (inclusive) to the beginning of the next hour (exclusive). 1180 * "minutely": every second from the beginning of the minute 1181 (inclusive) to the beginning of the next minute (exclusive). 1183 * "secondly": the second itself, only. 1185 2. Each date-time candidate is compared against all of the byX 1186 properties of the rule except bySetPosition. If any property in 1187 the rule does not match the date-time, it is eliminated. Each 1188 byX property is an array; the date-time matches the property if 1189 it matches any of the values in the array. The properties have 1190 the following semantics: 1192 * byMonth: the date-time is in the given month. 1194 * byWeekNo: the date-time is in the nth week of the year. 1195 Negative numbers mean the nth last week of the year. This 1196 corresponds to weeks according to week numbering as defined in 1197 ISO.8601.2004, with a week defined as a seven day period, 1198 starting on the firstDayOfWeek property value or Monday if 1199 omitted. Week number one of the calendar year is the first 1200 week that contains at least four days in that calendar year. 1202 If the date-time is not valid (this may happen when generating 1203 candidates with a skip property in effect), it is always 1204 eliminated by this property. 1206 * byYearDay: the date-time is on the nth day of year. Negative 1207 numbers mean the nth last day of the year. 1209 If the date-time is not valid (this may happen when generating 1210 candidates with a skip property in effect), it is always 1211 eliminated by this property. 1213 * byMonthDay: the date-time is on the given day of the month. 1214 Negative numbers mean the nth last day of the month. 1216 * byDay: the date-time is on the given day of the week. If the 1217 day is prefixed by a number, it is the nth occurrence of that 1218 day of the week within the month (if frequency is monthly) or 1219 year (if frequency is yearly). Negative numbers means nth 1220 last occurrence within that period. 1222 * byHour: the date-time has the given hour value. 1224 * byMinute: the date-time has the given minute value. 1226 * bySecond: the date-time has the given second value. 1228 If a skip property is defined and is not "omit", there may be 1229 candidates that do not correspond to valid dates (e.g. 31st 1230 February in the Gregorian calendar). In this case, the 1231 properties MUST be considered in the order above and: 1233 1. After applying the byMonth filter, if the candidate's month 1234 is invalid for the given year increment it (if skip is 1235 "forward") or decrement it (if skip is "backward") until a 1236 valid month is found, incrementing/decrementing the year as 1237 well if you pass through the beginning/end of the year. This 1238 only applies to calendar systems with leap months. 1240 2. After applying the byMonthDay filter, if the day of the month 1241 is invalid for the given month and year, change the date to 1242 the first day of the next month (if skip == "forward") or the 1243 last day of the current month (if skip == "backward"). 1245 3. If any valid date produced after applying the skip is already 1246 a candidate, eliminate the duplicate. (For example after 1247 adjusting, 30th February and 31st February would both become 1248 the same "real" date, so one is eliminated as a duplicate.) 1250 3. If a bySetPosition property is included, this is now applied to 1251 the ordered list of remaining dates. This property specifies the 1252 indexes of date-times to keep; all others should be eliminated. 1253 Negative numbers are indexes from the end of the list, with -1 1254 being the last item. 1256 4. Any date-times before the start date of the event are eliminated 1257 (see below for why this might be needed). 1259 5. If a skip property is included and is not "omit", eliminate any 1260 date-times that have already been produced by previous iterations 1261 of the algorithm. (This is not possible if skip == "omit".) 1263 6. If further dates are required (we have not reached the until 1264 date, or count limit) skip the next (interval - 1) sets of 1265 candidates, then continue from step 1. 1267 When determining the set of occurrence dates for an event or task, 1268 the following extra rules must be applied: 1270 1. The initial date-time to which the rule is applied (the "start" 1271 date-time for events; the "start" or "due" date-time for tasks) 1272 is always the first occurrence in the expansion (and is counted 1273 if the recurrence is limited by a "count" property), even if it 1274 would normally not match the rule. 1276 2. The first set of candidates to consider is that which would 1277 contain the initial date-time. This means the first set may 1278 include candidates before the initial date-time; such candidates 1279 are eliminated from the results in step (4) as outlined before. 1281 3. The following properties MUST be implicitly added to the rule 1282 under the given conditions: 1284 * If frequency is not "secondly" and no bySecond property: Add a 1285 bySecond property with the sole value being the seconds value 1286 of the initial date-time. 1288 * If frequency is not "secondly" or "minutely", and no byMinute 1289 property: Add a byMinute property with the sole value being 1290 the minutes value of the initial date-time. 1292 * If frequency is not "secondly", "minutely" or "hourly" and no 1293 byHour property: Add a byHour property with the sole value 1294 being the hours value of the initial date-time. 1296 * If frequency is "weekly" and no byDay property: Add a byDay 1297 property with the sole value being the day-of-the-week of the 1298 initial date-time. 1300 * If frequency is "monthly" and no byDay property and no 1301 byMonthDay property: Add a byMonthDay property with the sole 1302 value being the day-of-the-month of the initial date-time. 1304 * If frequency is "yearly" and no byYearDay property: 1306 + If there are no byMonth or byWeekNo properties, and either 1307 there is a byMonthDay property or there is no byDay 1308 property: Add a byMonth property with the sole value being 1309 the month of the initial date-time. 1311 + If there is no byMonthDay, byWeekNo or byDay properties: 1312 Add a byMonthDay property with the sole value being the 1313 day-of-the-month of the initial date-time. 1315 + If there is a byWeekNo property and no byMonthDay or byDay 1316 properties: Add a byDay property with the sole value being 1317 the day-of-the-week of the initial date-time. 1319 4.3.3. recurrenceOverrides 1321 Type: "LocalDateTime[PatchObject]" (optional). 1323 A map of the recurrence ids (the date-time produced by the recurrence 1324 rule) to an object of patches to apply to the generated occurrence 1325 object. 1327 If the recurrence id does not match a date-time from the recurrence 1328 rule (or no rule is specified), it is to be treated as an additional 1329 occurrence (like an RDATE from iCalendar). The patch object may 1330 often be empty in this case. 1332 If the patch object defines the "excluded" property value to be true, 1333 then the recurring calendar object does not occur at the recurrence 1334 id date-time (like an EXDATE from iCalendar). Such a patch object 1335 MUST NOT patch any other property. 1337 By default, an occurrence inherits all properties from the main 1338 object except the start (or due) date-time, which is shifted to match 1339 the recurrence id LocalDateTime. However, individual properties of 1340 the occurrence can be modified by a patch, or multiple patches. It 1341 is valid to patch the "start" property value, and this patch takes 1342 precedence over the value generated from the recurrence id. Both the 1343 recurrence id as well as the patched "start" date-time may occur 1344 before the original JSCalendar object's "start" or "due" date. 1346 A pointer in the PatchObject MUST be ignored if it starts with one of 1347 the following prefixes: 1349 o @type 1351 o method 1353 o privacy 1355 o prodId 1357 o recurrenceId 1359 o recurrenceOverrides 1361 o recurrenceRules 1363 o relatedTo 1365 o replyTo 1367 o uid 1369 4.3.4. excluded 1371 Type: "Boolean" (optional, default: false). 1373 Defines if this object is an overridden, excluded instance of a 1374 recurring JSCalendar object (see Section 4.3.3). If this property 1375 value is true, this calendar object instance MUST be removed from the 1376 occurrence expansion. The absence of this property or its default 1377 value false indicates that this instance MUST be included in the 1378 occurrence expansion. 1380 4.4. Sharing and Scheduling Properties 1382 4.4.1. priority 1384 Type: "Int" (optional, default: 0). 1386 Specifies a priority for the calendar object. This may be used as 1387 part of scheduling systems to help resolve conflicts for a time 1388 period. 1390 The priority is specified as an integer in the range 0 to 9. A value 1391 of 0 specifies an undefined priority. A value of 1 is the highest 1392 priority. A value of 2 is the second highest priority. Subsequent 1393 numbers specify a decreasing ordinal priority. A value of 9 is the 1394 lowest priority. Other integer values are reserved for future use. 1396 4.4.2. freeBusyStatus 1398 Type: "String" (optional, default: "busy"). 1400 Specifies how this property should be treated when calculating free- 1401 busy state. This MUST be one of the following values, an IANA- 1402 registered value, or a vendor-specific value: 1404 o "free": The object should be ignored when calculating whether the 1405 user is busy. 1407 o "busy": The object should be included when calculating whether the 1408 user is busy. 1410 4.4.3. privacy 1412 Type: "String" (optional, default: "public"). 1414 Calendar objects are normally collected together and may be shared 1415 with other users. The privacy property allows the object owner to 1416 indicate that it should not be shared, or should only have the time 1417 information shared but the details withheld. Enforcement of the 1418 restrictions indicated by this property are up to the API via which 1419 this object is accessed. 1421 This property MUST NOT affect the information sent to scheduled 1422 participants; it is only interpreted when the object is shared as 1423 part of a shared calendar. 1425 The value MUST be either one of the following values, an IANA- 1426 registered value, or a vendor-specific value. Any value the client 1427 or server doesn't understand should be preserved but treated as 1428 equivalent to "private". 1430 o "public": The full details of the object are visible to those whom 1431 the object's calendar is shared with. 1433 o "private": The details of the object are hidden; only the basic 1434 time and metadata is shared. The following properties MAY be 1435 shared, any other properties MUST NOT be shared: 1437 * @type 1439 * created 1441 * due 1443 * duration 1445 * estimatedDuration 1447 * freeBusyStatus 1449 * privacy 1451 * recurrenceOverrides. Only patches which apply to another 1452 permissible property are allowed to be shared. 1454 * sequence 1456 * showWithoutTime 1458 * start 1460 * timeZone 1462 * timeZones 1464 * uid 1466 * updated 1468 o "secret": The object is hidden completely (as though it did not 1469 exist) when the calendar this object is in is shared. 1471 4.4.4. replyTo 1473 Type: "String[String]" (optional). 1475 Represents methods by which participants may submit their RSVP 1476 response to the organizer of the calendar object. The keys in the 1477 property value are the available methods and MUST only contain ASCII 1478 alphanumeric characters (A-Za-z0-9). The value is a URI to use that 1479 method. Future methods may be defined in future specifications and 1480 registered with IANA; a calendar client MUST ignore any method it 1481 does not understand, but MUST preserve the method key and URI. This 1482 property MUST be omitted if no method is defined (rather than an 1483 empty object). If this property is set, the "participants" property 1484 of this calendar object MUST contain at least one participant. 1486 The following methods are defined: 1488 o "imip": The organizer accepts an iMIP [RFC6047] response at this 1489 email address. The value MUST be a "mailto:" URI. 1491 o "web": Opening this URI in a web browser will provide the user 1492 with a page where they can submit a reply to the organizer. 1494 o "other": The organizer is identified by this URI but the method 1495 how to submit the RSVP is undefined. 1497 4.4.5. participants 1499 Type: "Id[Participant]" (optional). 1501 A map of participant ids to participants, describing their 1502 participation in the calendar object. 1504 If this property is set, then the "replyTo" property of this calendar 1505 object MUST define at least one reply method. 1507 A Participant object has the following properties: 1509 o @type: "String" (mandatory) 1511 Specifies the type of this object. This MUST be "Participant". 1513 o name: "String" (optional) 1515 The display name of the participant (e.g. "Joe Bloggs"). 1517 o email: "String" (optional) 1518 The email address for the participant. 1520 o sendTo: "String[String]" (optional) 1522 Represents methods by which the participant may receive the 1523 invitation and updates to the calendar object. 1525 The keys in the property value are the available methods and MUST 1526 only contain ASCII alphanumeric characters (A-Za-z0-9). The value 1527 is a URI to use that method. Future methods may be defined in 1528 future specifications and registered with IANA; a calendar client 1529 MUST ignore any method it does not understand, but MUST preserve 1530 the method key and URI. This property MUST be omitted if no 1531 method is defined (rather than an empty object). 1533 The following methods are defined: 1535 * "imip": The participant accepts an iMIP [RFC6047] request at 1536 this email address. The value MUST be a "mailto:" URI. It MAY 1537 be different from the value of the participant's "email" 1538 property. 1540 * "other": The participant is identified by this URI but the 1541 method how to submit the invitation or update is undefined. 1543 o kind: "String" (optional) 1545 What kind of entity this participant is, if known. 1547 This MUST be either one of the following values, an IANA- 1548 registered value, or a vendor-specific value. Any value the 1549 client or server doesn't understand should be treated the same as 1550 if this property is omitted. 1552 * "individual": a single person 1554 * "group": a collection of people invited as a whole 1556 * "resource": a non-human resource, e.g. a projector 1558 * "location": a physical location involved in the calendar object 1559 that needs to be scheduled, e.g. a conference room. 1561 o roles: "String[Boolean]" (mandatory) 1563 A set of roles that this participant fulfills. 1565 At least one role MUST be specified for the participant. The keys 1566 in the set MUST be either one of the following values, an IANA- 1567 registered value, or a vendor-specific value: 1569 * "owner": The participant is an owner of the object. This 1570 signifies they have permission to make changes to it that 1571 affect the other participants. Non-owner participants may only 1572 change properties that just affect themself (for example 1573 setting their own alerts or changing their rsvp status). 1575 * "attendee": The participant is expected to attend. 1577 * "optional": The participant is invited but not required. 1579 * "informational": The participant is copied for informational 1580 reasons, and is not expected to attend. 1582 * "chair": The participant is in charge of the event/task when it 1583 occurs. 1585 The value for each key in the set MUST be true. It is expected 1586 that no more than one of the roles "attendee", "optional", or 1587 "informational" be present; if more than one are given, "optional" 1588 takes precedence over "informational", and "attendee" takes 1589 precedence over both. Roles that are unknown to the 1590 implementation MUST be preserved. 1592 o locationId: "String" (optional) 1594 The location at which this participant is expected to be 1595 attending. 1597 If the value does not correspond to any location id in the 1598 "locations" property of the JSCalendar object, this MUST be 1599 treated the same as if the participant's locationId were omitted. 1601 o language: "String" (optional) 1603 The language tag as defined in [RFC5646] that best describes the 1604 participant's preferred language, if known. 1606 o participationStatus: "String" (optional, default: "needs-action") 1608 The participation status, if any, of this participant. 1610 The value MUST be either one of the following values, an IANA- 1611 registered value, or a vendor-specific value: 1613 * "needs-action": No status yet set by the participant. 1615 * "accepted": The invited participant will participate. 1617 * "declined": The invited participant will not participate. 1619 * "tentative": The invited participant may participate. 1621 * "delegated": The invited participant has delegated their 1622 attendance to another participant, as specified in the 1623 delegatedTo property. 1625 o participationComment: "String" (optional) 1627 A note from the participant to explain their participation status. 1629 o expectReply: "Boolean" (optional, default: false) 1631 If true, the organizer is expecting the participant to notify them 1632 of their participation status. 1634 o scheduleAgent: "String" (optional, default: "server") 1636 Who is responsible for sending scheduling messages with this 1637 calendar object to the participant. 1639 The value MUST be either one of the following values, an IANA- 1640 registered value, or a vendor-specific value: 1642 * "server": The calendar server will send the scheduling 1643 messages. 1645 * "client": The calendar client will send the scheduling 1646 messages. 1648 * "none": No scheduling messages are to be sent to this 1649 participant. 1651 o scheduleSequence: "UnsignedInt" (optional, default: 0) 1653 The sequence number of the last response from the participant. If 1654 defined, this MUST be a non-negative integer. 1656 This can be used to determine whether the participant has sent a 1657 new RSVP following significant changes to the calendar object, and 1658 to determine if future responses are responding to a current or 1659 older view of the data. 1661 o scheduleUpdated: "UTCDateTime" (optional) 1663 The "updated" property of the last iTIP response from the 1664 participant. 1666 This can be compared to the "updated" property timestamp in future 1667 iTIP responses to determine if the response is older or newer than 1668 the current data. 1670 o invitedBy: "String" (optional) 1672 The participant id of the participant who invited this one, if 1673 known. 1675 o delegatedTo: "String[Boolean]" (optional) 1677 A set of participant ids that this participant has delegated their 1678 participation to. Each key in the set MUST be the id of a 1679 participant. The value for each key in the set MUST be true. 1680 This MUST be omitted if none (rather than an empty set). 1682 o delegatedFrom: "String[Boolean]" (optional) 1684 A set of participant ids that this participant is acting as a 1685 delegate for. Each key in the set MUST be the id of a 1686 participant. The value for each key in the set MUST be true. 1687 This MUST be omitted if none (rather than an empty set). 1689 o memberOf: "String[Boolean]" (optional) 1691 A set of group participants that were invited to this calendar 1692 object, which caused this participant to be invited due to their 1693 membership of the group(s). Each key in the set MUST be the id of 1694 a participant. The value for each key in the set MUST be true. 1695 This MUST be omitted if none (rather than an empty set). 1697 o linkIds: "String[Boolean]" (optional) 1699 A set of links to more information about this participant, for 1700 example in vCard format. The keys in the set MUST be the id of a 1701 Link object in the calendar object's "links" property. The value 1702 for each key in the set MUST be true. This MUST be omitted if 1703 none (rather than an empty set). 1705 o progress: "String" (optional). This is only allowed if the 1706 Participant is part of a JSTask. It represents the progress of 1707 the participant for this task, if known. This property MUST NOT 1708 be set if the "participationStatus" of this participant is any 1709 value other than "accepted". See Section 5.2.4 for allowed values 1710 and semantics. 1712 o progressUpdated: "UTCDateTime" (optional). Specifies the date- 1713 time the progress property was last set on this participant. This 1714 is only allowed if the Participant is part of a JSTask. 1716 4.5. Alerts Properties 1718 4.5.1. useDefaultAlerts 1720 Type: "Boolean" (optional, default: false). 1722 If true, use the user's default alerts and ignore the value of the 1723 "alerts" property. Fetching user defaults is dependent on the API 1724 from which this JSCalendar object is being fetched, and is not 1725 defined in this specification. If an implementation cannot determine 1726 the user's default alerts, or none are set, it MUST process the 1727 alerts property as if "useDefaultAlerts" is set to false. 1729 4.5.2. alerts 1731 Type: "Id[Alert]" (optional). 1733 A map of alert ids to Alert objects, representing alerts/reminders to 1734 display or send to the user for this calendar object. 1736 An Alert Object has the following properties: 1738 o @type: "String" (mandatory) 1740 Specifies the type of this object. This MUST be "Alert". 1742 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" 1743 (mandatory) 1745 Defines when to trigger the alert. New types may be defined in 1746 future RFCs. 1748 An *OffsetTrigger* object has the following properties: 1750 * @type: "String" (mandatory) 1752 Specifies the type of this object. This MUST be 1753 "OffsetTrigger". 1755 * offset: "SignedDuration" (mandatory). 1757 Defines the offset at which to trigger the alert relative to 1758 the time property defined in the "relativeTo" property of the 1759 alert. Negative durations signify alerts before the time 1760 property, positive durations signify alerts after. If the 1761 calendar object does not define a time zone, the user's default 1762 time zone SHOULD be used when determining the offset, if known. 1763 Otherwise, the time zone to use is implementation specific. 1765 * relativeTo: "String" (optional, default: "start") 1767 Specifies the time property that the alert offset is relative 1768 to. The value MUST be one of: 1770 + "start": triggers the alert relative to the start of the 1771 calendar object 1773 + "end": triggers the alert relative to the end/due time of 1774 the calendar object 1776 An *AbsoluteTrigger* object has the following properties: 1778 * @type: "String" (mandatory) 1780 Specifies the type of this object. This MUST be 1781 "AbsoluteTrigger". 1783 * when: "UTCDateTime" (mandatory). 1785 Defines a specific UTC date-time when the alert is triggered. 1787 An *UnknownTrigger* object is an object that contains a *@type* 1788 property whose value is not recognized (i.e., not "OffsetTrigger" 1789 or "AbsoluteTrigger"), plus zero or more other properties. This 1790 is for compatibility with client extensions and future RFCs. 1791 Implementations SHOULD NOT trigger for trigger types they do not 1792 understand, but MUST preserve them. 1794 o acknowledged: "UTCDateTime" (optional) 1796 This records when an alert was last acknowledged. This is set 1797 when the user has dismissed the alert; other clients that sync 1798 this property SHOULD automatically dismiss or suppress duplicate 1799 alerts (alerts with the same alert id that triggered on or before 1800 this date-time). 1802 For a recurring calendar object, the "acknowledged" property of 1803 the parent object MUST be updated, unless the alert is already 1804 overridden in the "recurrenceOverrides" property. 1806 Certain kinds of alert action may not provide feedback as to when 1807 the user sees them, for example email based alerts. For those 1808 kinds of alerts, this property SHOULD be set immediately when the 1809 alert is triggered and the action successfully carried out. 1811 o relatedTo: "String[Relation]" (optional) 1813 Relates this alert to other alerts in the same JSCalendar object. 1814 If the user wishes to snooze an alert, the application SHOULD 1815 create an alert to trigger after snoozing. All snooze alerts 1816 SHOULD set a relation to the identifier of the original alert. 1817 The Relation object SHOULD set the "parent" relation type, but MAY 1818 be empty. 1820 o action: "String" (optional, default: "display") 1822 Describes how to alert the user. 1824 The value MUST be at most one of the following values, an IANA- 1825 registered value, or a vendor-specific value: 1827 * "display": The alert should be displayed as appropriate for the 1828 current device and user context. 1830 * "email": The alert should trigger an email sent out to the 1831 user, notifying about the alert. This action is typically only 1832 appropriate for server implementations. 1834 4.6. Multilingual Properties 1836 4.6.1. localizations 1838 Type: "String[PatchObject]" (optional). 1840 A map of [RFC5646] language tags to patch objects, which localize the 1841 calendar object into the locale of the respective language tag. 1843 See the description of PatchObject (Section 1.4.8) for the structure 1844 of the PatchObject. The patches are applied to the top-level 1845 calendar object. In addition, the "locale" property of the patched 1846 object is set to the language tag. All pointers for patches MUST end 1847 with one of the following suffixes; any patch that does not follow 1848 this MUST be ignored unless otherwise specified in a future RFC: 1850 o title 1852 o description 1853 o name 1855 A patch MUST NOT have the prefix "recurrenceOverrides"; any 1856 localization of the override MUST be a patch to the localizations 1857 property inside the override instead. For example, a patch to 1858 "locations/abcd1234/title" is permissible, but a patch to "uid" or 1859 "recurrenceOverrides/2018-01-05T14:00:00/title" is not. 1861 Note that this specification does not define how to maintain validity 1862 of localized content. For example, a client application changing a 1863 JSCalendar object's title property might also need to update any 1864 localizations of this property. Client implementations SHOULD 1865 provide the means to manage localizations, but how to achieve this is 1866 specific to the application's workflow and requirements. 1868 4.7. Time Zone Properties 1870 4.7.1. timeZone 1872 Type: "String|null" (optional, default: null). 1874 Identifies the time zone the object is scheduled in, or null for 1875 floating time. This is either a name from the IANA Time Zone 1876 Database [TZDB] or the id of a custom time zone from the "timeZones" 1877 property (see Section 1.4.9). If omitted, this MUST be presumed to 1878 be null (i.e., floating time). 1880 4.7.2. timeZones 1882 Type: "String[TimeZone]" (optional). 1884 Maps identifiers of custom time zones to their time zone definition. 1885 The following restrictions apply for each key in the map: 1887 o It MUST start with the "/" character (ASCII decimal 47; also see 1888 Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion 1889 of the forward slash character in time zone identifiers). 1891 o It MUST be a valid "paramtext" value as specified in Section 3.1. 1892 of [RFC5545]. 1894 o At least one other property in the same JSCalendar object MUST 1895 reference a time zone using this identifier (i.e. orphaned time 1896 zones are not allowed). 1898 An identifier need only be unique to this JSCalendar object. 1900 A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545] 1901 and the semantics are as defined there. A valid time zone MUST 1902 define at least one transition rule in the "standard" or "daylight" 1903 property. Its properties are: 1905 o @type: "String" (mandatory) 1907 Specifies the type of this object. This MUST be "TimeZone". 1909 o tzId: "String" (mandatory). 1911 The TZID property from iCalendar. 1913 o lastModified: "UTCDateTime" (optional) 1915 The LAST-MODIFIED property from iCalendar. 1917 o url: "String" (optional) 1919 The TZURL property from iCalendar. 1921 o validUntil: "UTCDateTime" (optional) 1923 The TZUNTIL property from iCalendar specified in [RFC7808]. 1925 o aliases: "String[Boolean]" (optional) 1927 Maps the TZID-ALIAS-OF properties from iCalendar specified in 1928 [RFC7808] to a JSON set of aliases. The set is represented as an 1929 object, with the keys being the aliases. The value for each key 1930 in the set MUST be true. 1932 o standard: "TimeZoneRule[]" (optional) 1934 The STANDARD sub-components from iCalendar. The order MUST be 1935 preserved during conversion. 1937 o daylight: "TimeZoneRule[]" (optional). 1939 The DAYLIGHT sub-components from iCalendar. The order MUST be 1940 preserved during conversion. 1942 A TimeZoneRule object maps a STANDARD or DAYLIGHT sub-component from 1943 iCalendar, with the restriction that at most one recurrence rule is 1944 allowed per rule. It has the following properties: 1946 o @type: "String" (mandatory) 1947 Specifies the type of this object. This MUST be "TimeZoneRule". 1949 o start: "LocalDateTime" (mandatory) 1951 The DTSTART property from iCalendar. 1953 o offsetTo: "String" (mandatory) 1955 The TZOFFSETTO property from iCalendar. 1957 o offsetFrom: "String" (mandatory) 1959 The TZOFFSETFROM property from iCalendar. 1961 o recurrenceRule: "RecurrenceRule" (optional) 1963 The RRULE property mapped as specified in Section 4.3.2. During 1964 recurrence rule evaluation, the "until" property value MUST be 1965 interpreted as a local time in the UTC time zone. 1967 o recurrenceDates: "LocalDateTime[Boolean]" (optional) 1969 Maps the RDATE properties from iCalendar to a JSON set. The set 1970 is represented as an object, with the keys being the recurrence 1971 dates. The value for each key in the set MUST be true. 1973 o names: "String[Boolean]" (optional) 1975 Maps the TZNAME properties from iCalendar to a JSON set. The set 1976 is represented as an object, with the keys being the names. The 1977 value for each key in the set MUST be true. 1979 o comments: "String[]" (optional). Maps the COMMENT properties from 1980 iCalendar. The order MUST be preserved during conversion. 1982 5. Type-specific JSCalendar Properties 1984 5.1. JSEvent Properties 1986 In addition to the common JSCalendar object properties (Section 4) a 1987 JSEvent has the following properties: 1989 5.1.1. start 1991 Type: "LocalDateTime" (mandatory). 1993 The date/time the event starts in the event's time zone (as specified 1994 in the "timeZone" property, see Section 4.7.1). 1996 5.1.2. duration 1998 Type: "Duration" (optional, default: "PT0S"). 2000 The zero or positive duration of the event in the event's start time 2001 zone. 2003 Note that a duration specified using weeks or days does not always 2004 correspond to an exact multiple of 24 hours. The number of 2005 hours/minutes/seconds may vary if it overlaps a period of 2006 discontinuity in the event's time zone, for example a change from 2007 standard time to daylight-savings time. Leap seconds MUST NOT be 2008 considered when computing an exact duration. When computing an exact 2009 duration, the greatest order time components MUST be added first, 2010 that is, the number of days MUST be added first, followed by the 2011 number of hours, number of minutes, and number of seconds. 2012 Fractional seconds MUST be added last. These semantics match the 2013 iCalendar DURATION value type ([RFC5545], Section 3.3.6). 2015 A JSEvent MAY involve start and end locations that are in different 2016 time zones (e.g. a trans-continental flight). This can be expressed 2017 using the "relativeTo" and "timeZone" properties of the JSEvent's 2018 Location objects (see Section 4.2.5). 2020 5.1.3. status 2022 Type: "String" (optional, default: "confirmed"). 2024 The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be 2025 one of the following values, an IANA-registered value, or a vendor- 2026 specific value: 2028 o "confirmed": Indicates the event is definitely happening. 2030 o "cancelled": Indicates the event has been cancelled. 2032 o "tentative": Indicates the event may happen. 2034 5.2. JSTask Properties 2036 In addition to the common JSCalendar object properties (Section 4) a 2037 JSTask has the following properties: 2039 5.2.1. due 2041 Type: "LocalDateTime" (optional). 2043 The date/time the task is due in the task's time zone. 2045 5.2.2. start 2047 Type: "LocalDateTime" (optional). 2049 The date/time the task should start in the task's time zone. 2051 5.2.3. estimatedDuration 2053 Type: "Duration" (optional). 2055 Specifies the estimated positive duration of time the task takes to 2056 complete. 2058 5.2.4. progress 2060 Type: "String" (optional). 2062 Defines the progress of this task. If omitted, the default progress 2063 (Section 4.4) of a JSTask is defined as follows (in order of 2064 evaluation): 2066 o "completed": if the "progress" property value of all participants 2067 is "completed". 2069 o "failed": if at least one "progress" property value of a 2070 participant is "failed". 2072 o "in-process": if at least one "progress" property value of a 2073 participant is "in-process". 2075 o "needs-action": If none of the other criteria match. 2077 If set, it MUST be one of the following values, an IANA-registered 2078 value, or a vendor-specific value: 2080 o "needs-action": Indicates the task needs action. 2082 o "in-process": Indicates the task is in process. 2084 o "completed": Indicates the task is completed. 2086 o "failed": Indicates the task failed. 2088 o "cancelled": Indicates the task was cancelled. 2090 5.2.5. progressUpdated 2092 Type: "UTCDateTime" (optional). 2094 Specifies the date/time the "progress" property of either the task 2095 overall (Section 5.2.4) or a specific participant (Section 4.4.5) was 2096 last updated. 2098 If the task is recurring and has future instances, a client may want 2099 to keep track of the last progress update timestamp of a specific 2100 task recurrence, but leave other instances unchanged. One way to 2101 achieve this is by overriding the progressUpdated property in the 2102 task "recurrenceOverrides" property. However, this could produce a 2103 long list of timestamps for regularly recurring tasks. An 2104 alternative approach is to split the JSTask into a current, single 2105 instance of JSTask with this instance progress update time and a 2106 future recurring instance. See also Section 4.1.3 on splitting. 2108 5.3. JSGroup Properties 2110 JSGroup supports the following common JSCalendar properties 2111 (Section 4): 2113 o @type 2115 o categories 2117 o color 2119 o created 2121 o description 2123 o descriptionContentType 2125 o keywords 2127 o links 2129 o locale 2131 o prodId 2133 o title 2135 o updated 2137 o uid 2138 In addition, the following JSGroup-specific properties are supported: 2140 5.3.1. entries 2142 Type: "String[JSTask|JSEvent]" (mandatory). 2144 A collection of group members. This is represented as a map of the 2145 "uid" property value to the JSCalendar object member having that uid. 2146 Implementations MUST ignore entries of unknown type. 2148 5.3.2. source 2150 Type: "String" (optional). 2152 The source from which updated versions of this group may be retrieved 2153 from. The value MUST be a URI. 2155 6. Examples 2157 The following examples illustrate several aspects of the JSCalendar 2158 data model and format. The examples may omit mandatory or additional 2159 properties, which is indicated by a placeholder property with key 2160 "...". While most of the examples use calendar event objects, they 2161 are also illustrative for tasks. 2163 6.1. Simple event 2165 This example illustrates a simple one-time event. It specifies a 2166 one-time event that begins on January 15, 2018 at 1pm New York local 2167 time and ends after 1 hour. 2169 { 2170 "@type": "jsevent", 2171 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2172 "updated": "2018-01-15T18:00:00Z", 2173 "title": "Some event", 2174 "start": "2018-01-15T13:00:00", 2175 "timeZone": "America/New_York", 2176 "duration": "PT1H" 2177 } 2179 6.2. Simple task 2181 This example illustrates a simple task for a plain to-do item. 2183 { 2184 "@type": "jstask", 2185 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2186 "updated": "2018-01-15T18:00:00Z", 2187 "title": "Do something" 2188 } 2190 6.3. Simple group 2192 This example illustrates a simple calendar object group that contains 2193 an event and a task. 2195 { 2196 "@type": "jsgroup", 2197 "uid": "2a358cee-6489-4f14-a57f-c104db4dc343", 2198 "updated": "2018-01-15T18:00:00Z", 2199 "name": "A simple group", 2200 "entries": { 2201 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2202 "@type": "jsevent", 2203 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2204 "updated": "2018-01-15T18:00:00Z", 2205 "title": "Some event", 2206 "start": "2018-01-15T13:00:00", 2207 "timeZone": "America/New_York", 2208 "duration": "PT1H" 2209 }, 2210 "2a358cee-6489-4f14-a57f-c104db4dc2f2": { 2211 "@type": "jstask", 2212 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2213 "updated": "2018-01-15T18:00:00Z", 2214 "title": "Do something" 2215 } 2216 } 2217 } 2219 6.4. All-day event 2221 This example illustrates an event for an international holiday. It 2222 specifies an all-day event on April 1 that occurs every year since 2223 the year 1900. 2225 { 2226 "...": "", 2227 "title": "April Fool's Day", 2228 "showWithoutTime": true, 2229 "start": "1900-04-01T00:00:00", 2230 "duration": "P1D", 2231 "recurrenceRules": [{ 2232 "@type": "RecurrenceRule", 2233 "frequency": "yearly" 2234 }] 2235 } 2237 6.5. Task with a due date 2239 This example illustrates a task with a due date. It is a reminder to 2240 buy groceries before 6pm Vienna local time on January 19, 2018. The 2241 calendar user expects to need 1 hour for shopping. 2243 { 2244 "...": "", 2245 "title": "Buy groceries", 2246 "due": "2018-01-19T18:00:00", 2247 "timeZone": "Europe/Vienna", 2248 "estimatedDuration": "PT1H" 2249 } 2251 6.6. Event with end time-zone 2253 This example illustrates the use of end time-zones by use of an 2254 international flight. The flight starts on April 1, 2018 at 9am in 2255 Berlin local time. The duration of the flight is scheduled at 10 2256 hours 30 minutes. The time at the flights destination is in the same 2257 time-zone as Tokyo. Calendar clients could use the end time-zone to 2258 display the arrival time in Tokyo local time and highlight the time- 2259 zone difference of the flight. The location names can serve as input 2260 for navigation systems. 2262 { 2263 "...": "", 2264 "title": "Flight XY51 to Tokyo", 2265 "start": "2018-04-01T09:00:00", 2266 "timeZone": "Europe/Berlin", 2267 "duration": "PT10H30M", 2268 "locations": { 2269 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2270 "@type": "Location", 2271 "rel": "start", 2272 "name": "Frankfurt Airport (FRA)" 2273 }, 2274 "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { 2275 "@type": "Location", 2276 "rel": "end", 2277 "name": "Narita International Airport (NRT)", 2278 "timeZone": "Asia/Tokyo" 2279 } 2280 } 2281 } 2283 6.7. Floating-time event (with recurrence) 2285 This example illustrates the use of floating-time. Since January 1, 2286 2018, a calendar user blocks 30 minutes every day to practice Yoga at 2287 7am local time, in whatever time-zone the user is located on that 2288 date. 2290 { 2291 "...": "", 2292 "title": "Yoga", 2293 "start": "2018-01-01T07:00:00", 2294 "duration": "PT30M", 2295 "recurrenceRules": [{ 2296 "@type": "RecurrenceRule", 2297 "frequency": "daily" 2298 }] 2299 } 2301 6.8. Event with multiple locations and localization 2303 This example illustrates an event that happens at both a physical and 2304 a virtual location. Fans can see a live convert on premises or 2305 online. The event title and descriptions are localized. 2307 { 2308 "...": "", 2309 "title": "Live from Music Bowl: The Band", 2310 "description": "Go see the biggest music event ever!", 2311 "locale": "en", 2312 "start": "2018-07-04T17:00:00", 2313 "timeZone": "America/New_York", 2314 "duration": "PT3H", 2315 "locations": { 2316 "c0503d30-8c50-4372-87b5-7657e8e0fedd": { 2317 "@type": "Location", 2318 "name": "The Music Bowl", 2319 "description": "Music Bowl, Central Park, New York", 2320 "coordinates": "geo:40.7829,73.9654" 2321 } 2322 }, 2323 "virtualLocations": { 2324 "6f3696c6-1e07-47d0-9ce1-f50014b0041a": { 2325 "@type": "VirtualLocation", 2326 "name": "Free live Stream from Music Bowl", 2327 "uri": "https://stream.example.com/the_band_2018" 2328 } 2329 }, 2330 "localizations": { 2331 "de": { 2332 "title": "Live von der Music Bowl: The Band!", 2333 "description": "Schau dir das groesste Musikereignis an!", 2334 "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name": 2335 "Gratis Live-Stream aus der Music Bowl" 2336 } 2337 } 2338 } 2340 6.9. Recurring event with overrides 2342 This example illustrates the use of recurrence overrides. A math 2343 course at a University is held for the first time on January 8, 2018 2344 at 9am London time and occurs every week until June 25, 2018. Each 2345 lecture lasts for one hour and 30 minutes and is located at the 2346 Mathematics department. This event has exceptional occurrences: at 2347 the last occurrence of the course is an exam, which lasts for 2 hours 2348 and starts at 10am. Also, the location of the exam differs from the 2349 usual location. On April 2 no course is held. On January 5 at 2pm 2350 is an optional introduction course, that occurs before the first 2351 regular lecture. 2353 { 2354 "...": "", 2355 "title": "Calculus I", 2356 "start": "2018-01-08T09:00:00", 2357 "timeZone": "Europe/London", 2358 "duration": "PT1H30M", 2359 "locations": { 2360 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2361 "@type": "Location", 2362 "title": "Math lab room 1", 2363 "description": "Math Lab I, Department of Mathematics" 2364 } 2365 }, 2366 "recurrenceRules": [{ 2367 "@type": "RecurrenceRule", 2368 "frequency": "weekly", 2369 "until": "2018-06-25T09:00:00" 2370 }], 2371 "recurrenceOverrides": { 2372 "2018-01-05T14:00:00": { 2373 "title": "Introduction to Calculus I (optional)" 2374 }, 2375 "2018-04-02T09:00:00": { 2376 "excluded": "true" 2377 }, 2378 "2018-06-25T09:00:00": { 2379 "title": "Calculus I Exam", 2380 "start": "2018-06-25T10:00:00", 2381 "duration": "PT2H", 2382 "locations": { 2383 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2384 "@type": "Location", 2385 "title": "Big Auditorium", 2386 "description": "Big Auditorium, Other Road" 2387 } 2388 } 2389 } 2390 } 2391 } 2393 6.10. Recurring event with participants 2395 This example illustrates scheduled events. A team meeting occurs 2396 every week since January 8, 2018 at 9am Johannesburg time. The event 2397 owner also chairs the event. Participants meet in a virtual meeting 2398 room. An attendee has accepted the invitation, but on March 8, 2018 2399 he is unavailable and declined participation for this occurrence. 2401 { 2402 "...": "", 2403 "title": "FooBar team meeting", 2404 "start": "2018-01-08T09:00:00", 2405 "timeZone": "Africa/Johannesburg", 2406 "duration": "PT1H", 2407 "virtualLocations": { 2408 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2409 "@type": "VirtualLocation", 2410 "name": "ChatMe meeting room", 2411 "uri": "https://chatme.example.com?id=1234567" 2412 } 2413 }, 2414 "recurrenceRules": [{ 2415 "@type": "RecurrenceRule", 2416 "frequency": "weekly" 2417 }], 2418 "replyTo": { 2419 "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com" 2420 }, 2421 "participants": { 2422 "dG9tQGZvb2Jhci5xlLmNvbQ": { 2423 "@type": "Participant", 2424 "name": "Tom Tool", 2425 "email": "tom@foobar.example.com", 2426 "sendTo": { 2427 "imip": "mailto:6489-4f14-a57f-c1@calendar.example.com" 2428 }, 2429 "participationStatus": "accepted", 2430 "roles": { 2431 "attendee": true 2432 } 2433 }, 2434 "em9lQGZvb2GFtcGxlLmNvbQ": { 2435 "@type": "Participant", 2436 "name": "Zoe Zelda", 2437 "email": "zoe@foobar.example.com", 2438 "sendTo": { 2439 "imip": "mailto:zoe@foobar.example.com" 2440 }, 2441 "participationStatus": "accepted", 2442 "roles": { 2443 "owner": true, 2444 "attendee": true, 2445 "chair": true 2446 } 2447 }, 2448 "...": "" 2450 }, 2451 "recurrenceOverrides": { 2452 "2018-03-08T09:00:00": { 2453 "participants/dG9tQGZvb2Jhci5xlLmNvbQ/participationStatus": 2454 "declined" 2455 } 2456 } 2457 } 2459 7. Security Considerations 2461 Calendaring and scheduling information is very privacy-sensitive. 2462 The transmission of such information must be careful to protect it 2463 from possible threats, such as eavesdropping, replay, message 2464 insertion, deletion, modification, and man-in-the-middle attacks. 2465 This document just defines the data format; such considerations are 2466 primarily the concern of the API or method of storage and 2467 transmission of such files. 2469 7.1. Expanding Recurrences 2471 A recurrence rule may produce infinite occurrences of an event. 2472 Implementations MUST handle expansions carefully to prevent 2473 accidental or deliberate resource exhaustion. 2475 Conversely, a recurrence rule may be specified that does not expand 2476 to anything. It is not always possible to tell this through static 2477 analysis of the rule, so implementations MUST be careful to avoid 2478 getting stuck in an infinite loop, or otherwise exhausting resources, 2479 searching for the next occurrence. 2481 7.2. JSON Parsing 2483 The Security Considerations of [RFC8259] apply to the use of JSON as 2484 the data interchange format. 2486 As for any serialization format, parsers need to thoroughly check the 2487 syntax of the supplied data. JSON uses opening and closing tags for 2488 several types and structures, and it is possible that the end of the 2489 supplied data will be reached when scanning for a matching closing 2490 tag; this is an error condition, and implementations need to stop 2491 scanning at the end of the supplied data. 2493 JSON also uses a string encoding with some escape sequences to encode 2494 special characters within a string. Care is needed when processing 2495 these escape sequences to ensure that they are fully formed before 2496 the special processing is triggered, with special care taken when the 2497 escape sequences appear adjacent to other (non-escaped) special 2498 characters or adjacent to the end of data (as in the previous 2499 paragraph). 2501 If parsing JSON into a non-textual structured data format, 2502 implementations may need to allocate storage to hold JSON string 2503 elements. Since JSON does not use explicit string lengths, the risk 2504 of denial of service due to resource exhaustion is small, but 2505 implementations may still wish to place limits on the size of 2506 allocations they are willing to make in any given context, to avoid 2507 untrusted data causing excessive memory allocation. 2509 7.3. URI Values 2511 Several JSCalendar properties contain URIs as values, and processing 2512 these properties requires extra care. Section 7 of [RFC3986] 2513 discusses security risk related to URIs. 2515 8. IANA Considerations 2517 8.1. Media Type Registration 2519 This document defines a MIME media type for use with JSCalendar data 2520 formatted in JSON. 2522 Type name: application 2524 Subtype name: jscalendar+json 2526 Required parameters: type 2528 The "type" parameter conveys the type of the JSCalendar data in 2529 the body part, with the value being one of "jsevent", "jstask", or 2530 "jsgroup". The parameter MUST NOT occur more than once. It MUST 2531 match the value of the "@type" property of the JSON-formatted 2532 JSCalendar object in the body. 2534 Optional parameters: none 2536 Encoding considerations: Same as encoding considerations of 2537 application/json as specified in RFC8529, Section 11 [RFC8259]. 2539 Security considerations: See Section 7 of this document. 2541 Interoperability considerations: This media type provides an 2542 alternative to iCalendar, jCal and proprietary JSON-based 2543 calendaring data formats. 2545 Published specification: This specification. 2547 Applications that use this media type: Applications that currently 2548 make use of the text/calendar and application/calendar+json media 2549 types can use this as an alternative. Similarly, applications 2550 that use the application/json media type to transfer calendaring 2551 data can use this to further specify the content. 2553 Fragment identifier considerations: N/A 2555 Additional information: 2557 Magic number(s): N/A 2559 File extensions(s): N/A 2561 Macintosh file type code(s): N/A 2563 Person & email address to contact for further information: 2564 calext@ietf.org 2566 Intended usage: COMMON 2568 Restrictions on usage: N/A 2570 Author: See the "Author's Address" section of this document. 2572 Change controller: IETF 2574 8.2. Creation of "JSCalendar Properties" Registry 2576 The IANA will create the "JSCalendar Properties" registry to allow 2577 interoperability of extensions to JSCalendar objects. 2579 This registry follows the Expert Review process ([RFC8126], 2580 Section 4.5) unless the "intended use" field is "common", in which 2581 case registration follows the Specification Required process 2582 ([RFC8126], Section 4.6). Preliminary community review for this 2583 registry is optional but strongly encouraged. 2585 A registration can have an intended use of "common", "reserved", or 2586 "obsolete". The IANA will list common-use registrations prominently 2587 and separately from those with other intended use values. 2589 A "reserved" registration reserves a property name without assigning 2590 semantics to avoid name collisions with future extensions or protocol 2591 use. 2593 An "obsolete" registration denotes a property that is no longer 2594 expected to be added by up-to-date systems. A new property has 2595 probably been defined covering the obsolete property's semantics. 2597 The JSCalendar property registration procedure is not a formal 2598 standards process but rather an administrative procedure intended to 2599 allow community comment and sanity checking without excessive time 2600 delay. It is designed to encourage vendors to document and register 2601 new properties they add for use cases not covered by the original 2602 standard, leading to increased interoperability. 2604 8.2.1. Preliminary Community Review 2606 Notice of a potential new registration SHOULD be sent to the Calext 2607 mailing list for review. This mailing list is 2608 appropriate to solicit community feedback on a proposed new property. 2610 Properties registrations must be marked with their intended use: 2611 "common", "reserved" or "obsolete". 2613 The intent of the public posting to this list is to solicit comments 2614 and feedback on the choice of the property name, the unambiguity of 2615 the specification document, and a review of any interoperability or 2616 security considerations. The submitter may submit a revised 2617 registration proposal or abandon the registration completely at any 2618 time. 2620 8.2.2. Submit Request to IANA 2622 Registration requests can be sent to . 2624 8.2.3. Designated Expert Review 2626 The primary concern of the designated expert (DE) is preventing name 2627 collisions and encouraging the submitter to document security and 2628 privacy considerations. For a common-use registration, the DE is 2629 expected to confirm that suitable documentation, as described in 2630 Section 4.6 of [RFC8126], is available to ensure interoperability. 2631 This preferably takes the form of an RFC, but for simple definitions 2632 a description in the registry may be sufficient. The DE should also 2633 verify that the property name does not conflict with work that is 2634 active or already published within the IETF. A published 2635 specification is not required for reserved or obsolete registrations. 2637 Before a period of 30 days has passed, the DE will either approve or 2638 deny the registration request and publish a notice of the decision to 2639 the Calext WG mailing list or its successor, as well as inform IANA. 2640 A denial notice must be justified by an explanation, and, in the 2641 cases where it is possible, concrete suggestions on how the request 2642 can be modified so as to become acceptable should be provided. 2644 If the DE does not respond within 30 days, the registrant may request 2645 the IESG take action to process the request in a timely manner. 2647 8.2.4. Change Procedures 2649 Once a JSCalendar property has been published by the IANA, the change 2650 controller may request a change to its definition. The same 2651 procedure that would be appropriate for the original registration 2652 request is used to process a change request. 2654 JSCalendar property registrations may not be deleted; properties that 2655 are no longer believed appropriate for use can be declared obsolete 2656 by a change to their "intended use" field; such properties will be 2657 clearly marked in the lists published by the IANA. 2659 Significant changes to a JSCalendar property's definition should be 2660 requested only when there are serious omissions or errors in the 2661 published specification, as such changes may cause interoperability 2662 issues. When review is required, a change request may be denied if 2663 it renders entities that were valid under the previous definition 2664 invalid under the new definition. 2666 The owner of a JSCalendar property may pass responsibility to another 2667 person or agency by informing the IANA; this can be done without 2668 discussion or review. 2670 The IESG may reassign responsibility for a JSCalendar property. The 2671 most common case of this will be to enable changes to be made to a 2672 registration where the author of the registration has died, moved out 2673 of contact, or is otherwise unable to make changes that are important 2674 to the community. 2676 8.2.5. JMAP Properties Registry Template 2678 o Property Name: The name of the property. The property name MUST 2679 NOT already be registered for any of the objects listed in 2680 Context. Objects not listed in Context MAY already have 2681 registered a different property with the same name. 2683 o Property Type: The type of this property, using type signatures as 2684 specified in Section 1.3. The property type MUST be registed in 2685 the Type Registry. 2687 o Property Context: A comma-separated list of JSCalendar object 2688 types this property is allowed on. 2690 o Reference or Description: A brief description or RFC number and 2691 section reference where the property is specified (omitted for 2692 "reserved" property names). 2694 o Intended Use: Common, reserved, or obsolete. 2696 o Change Controller: ("IETF" for IETF-stream RFCs). 2698 8.2.6. Initial Contents for the JSCalendar Properties Registry 2700 The following table lists the initial entries of the JSCalendar 2701 Properties registry. All properties are for common-use. All RFC 2702 section references are for this document. The change controller for 2703 all these properties is "IETF". 2705 +---------------+----------------------------+------------+---------+ 2706 | Property Name | Property Type | Property | Referen | 2707 | | | Context | ce or D | 2708 | | | | escript | 2709 | | | | ion | 2710 +---------------+----------------------------+------------+---------+ 2711 | @type | String | JSEvent, | Section | 2712 | | | JSTask, | 4.1.1, | 2713 | | | JSGroup, A | Section | 2714 | | | bsoluteTri | 4.5.2, | 2715 | | | gger, | Section | 2716 | | | Alert, | 4.2.7, | 2717 | | | Link, | Section | 2718 | | | Location, | 4.2.5, | 2719 | | | OffsetTrig | Section | 2720 | | | ger, Parti | 4.4.5, | 2721 | | | cipant, Re | Section | 2722 | | | currenceRu | 4.3.2, | 2723 | | | le, | Section | 2724 | | | Relation, | 4.1.3, | 2725 | | | TimeZone, | Section | 2726 | | | VirtualLoc | 4.7.2, | 2727 | | | ation | Section | 2728 | | | | 4.2.6 | 2729 | | | | | 2730 | acknowledged | UTCDateTime | Alert | Section | 2731 | | | | 4.5.2 | 2732 | | | | | 2733 | action | String | Alert | Section | 2734 | | | | 4.5.2 | 2735 | | | | | 2736 | alerts | Id[Alert] | JSEvent, | Section | 2737 | | | JSTask | 4.5.2 | 2738 | | | | | 2739 | byDay | NDay[] | Recurrence | Section | 2740 | | | Rule | 4.3.2 | 2741 | | | | | 2742 | byHour | UnsignedInt[] | Recurrence | Section | 2743 | | | Rule | 4.3.2 | 2744 | | | | | 2745 | byMinute | UnsignedInt[] | Recurrence | Section | 2746 | | | Rule | 4.3.2 | 2747 | | | | | 2748 | byMonth | String[] | Recurrence | Section | 2749 | | | Rule | 4.3.2 | 2750 | | | | | 2751 | byMonthDay | Int[] | Recurrence | Section | 2752 | | | Rule | 4.3.2 | 2753 | | | | | 2754 | bySecond | UnsignedInt[] | Recurrence | Section | 2755 | | | Rule | 4.3.2 | 2756 | | | | | 2757 | bySetPosition | Int[] | Recurrence | Section | 2758 | | | Rule | 4.3.2 | 2759 | | | | | 2760 | byWeekNo | Int[] | Recurrence | Section | 2761 | | | Rule | 4.3.2 | 2762 | | | | | 2763 | byYearDay | Int[] | Recurrence | Section | 2764 | | | Rule | 4.3.2 | 2765 | | | | | 2766 | categories | String[Boolean] | JSEvent, | Section | 2767 | | | JSTask, | 4.2.10 | 2768 | | | JSGroup | | 2769 | | | | | 2770 | cid | String | Link | Section | 2771 | | | | 4.2.7 | 2772 | | | | | 2773 | color | String | JSEvent, | Section | 2774 | | | JSTask, | 4.2.11 | 2775 | | | JSGroup | | 2776 | | | | | 2777 | contentType | String | Link | Section | 2778 | | | | 4.2.7 | 2779 | | | | | 2780 | coordinates | String | Location | Section | 2781 | | | | 4.2.5 | 2782 | | | | | 2783 | count | UnsignedInt | Recurrence | Section | 2784 | | | Rule | 4.3.2 | 2785 | | | | | 2786 | created | UTCDateTime | JSEvent, | Section | 2787 | | | JSTask, | 4.1.5 | 2788 | | | JSGroup | | 2789 | | | | | 2790 | delegatedFrom | String[Boolean] | Participan | Section | 2791 | | | t | 4.4.5 | 2792 | | | | | 2793 | delegatedTo | String[Boolean] | Participan | Section | 2794 | | | t | 4.4.5 | 2795 | | | | | 2796 | description | String | JSEvent, | Section | 2797 | | | JSTask, | 4.2.2, | 2798 | | | Location, | Section | 2799 | | | VirtualLoc | 4.2.5, | 2800 | | | ation | Section | 2801 | | | | 4.2.6 | 2802 | | | | | 2803 | descriptionCo | String | JSEvent, | Section | 2804 | ntentType | | JSTask | 4.2.3 | 2805 | | | | | 2806 | display | String | Link | Section | 2807 | | | | 4.2.7 | 2808 | | | | | 2809 | due | LocalDateTime | JSTask | Section | 2810 | | | | 5.2.1 | 2811 | | | | | 2812 | duration | Duration | JSEvent | Section | 2813 | | | | 5.1.2 | 2814 | | | | | 2815 | email | String | Participan | Section | 2816 | | | t | 4.4.5 | 2817 | | | | | 2818 | entries | String[JSTask|JSEvent] | JSGroup | Section | 2819 | | | | 5.3.1 | 2820 | | | | | 2821 | estimatedDura | Duration | JSTask | Section | 2822 | tion | | | 5.2.3 | 2823 | | | | | 2824 | excluded | Boolean | JSEvent, | Section | 2825 | | | JSTask | 4.3.4 | 2826 | | | | | 2827 | expectReply | Boolean | Participan | Section | 2828 | | | t | 4.4.5 | 2829 | | | | | 2830 | firstDayOfWee | String | Recurrence | Section | 2831 | k | | Rule | 4.3.2 | 2832 | | | | | 2833 | freeBusyStatu | String | JSEvent, | Section | 2834 | s | | JSTask | 4.4.2 | 2835 | | | | | 2836 | frequency | String | Recurrence | Section | 2837 | | | Rule | 4.3.2 | 2838 | | | | | 2839 | href | String | Link | Section | 2840 | | | | 4.2.7 | 2841 | | | | | 2842 | interval | UnsignedInt | Recurrence | Section | 2843 | | | Rule | 4.3.2 | 2844 | | | | | 2845 | invitedBy | String | Participan | Section | 2846 | | | t | 4.4.5 | 2847 | | | | | 2848 | keywords | String[Boolean] | JSEvent, | Section | 2849 | | | JSTask, | 4.2.9 | 2850 | | | JSGroup | | 2851 | | | | | 2852 | kind | String | Participan | Section | 2853 | | | t | 4.4.5 | 2854 | | | | | 2855 | language | String | Participan | Section | 2856 | | | t | 4.4.5 | 2857 | | | | | 2858 | linkIds | Id[Boolean] | Location, | Section | 2859 | | | Participan | 4.2.5, | 2860 | | | t | Section | 2861 | | | | 4.4.5 | 2862 | | | | | 2863 | links | Id[Link] | JSGroup, | Section | 2864 | | | JSEvent, | 4.2.7 | 2865 | | | JSTask | | 2866 | | | | | 2867 | locale | String | JSGroup, | Section | 2868 | | | JSEvent, | 4.2.7 | 2869 | | | JSTask | | 2870 | | | | | 2871 | localizations | String[PatchObject] | JSEvent, | Section | 2872 | | | JSTask | 4.6.1 | 2873 | | | | | 2874 | locationId | String | Participan | Section | 2875 | | | t | 4.4.5 | 2876 | | | | | 2877 | locations | Id[Location] | JSEvent, | Section | 2878 | | | JSTask | 4.2.5 | 2879 | | | | | 2880 | locationTypes | String[Boolean] | Location | Section | 2881 | | | | 4.2.5 | 2882 | | | | | 2883 | memberOf | String[Boolean] | Participan | Section | 2884 | | | t | 4.4.5 | 2885 | | | | | 2886 | method | String | JSEvent, | Section | 2887 | | | JSTask | 4.1.8 | 2888 | | | | | 2889 | name | String | Location, | Section | 2890 | | | VirtualLoc | 4.2.5, | 2891 | | | ation, Par | Section | 2892 | | | ticipant | 4.2.6, | 2893 | | | | Section | 2894 | | | | 4.4.5 | 2895 | | | | | 2896 | offset | SignedDuration | OffsetTrig | Section | 2897 | | | ger | 4.5.2 | 2898 | | | | | 2899 | participants | Id[Participant] | JSEvent, | Section | 2900 | | | JSTask | 4.4.5 | 2901 | | | | | 2902 | participation | String | Participan | Section | 2903 | Comment | | t | 4.4.5 | 2904 | | | | | 2905 | participation | String | Participan | Section | 2906 | Status | | t | 4.4.5 | 2907 | | | | | 2908 | priority | Int | JSEvent, | Section | 2909 | | | JSTask | 4.4.1 | 2910 | | | | | 2911 | privacy | String | JSEvent, | Section | 2912 | | | JSTask | 4.4.3 | 2913 | | | | | 2914 | prodId | String | JSEvent, | Section | 2915 | | | JSTask, | 4.1.4 | 2916 | | | JSGroup | | 2917 | | | | | 2918 | progress | String | JSTask, Pa | Section | 2919 | | | rticipant | 5.2.4 | 2920 | | | | | 2921 | progressUpdat | UTCDateTime | JSTask, Pa | Section | 2922 | ed | | rticipant | 5.2.5 | 2923 | | | | | 2924 | recurrenceId | LocalDateTime | JSEvent, | Section | 2925 | | | JSTask | 4.3.1 | 2926 | | | | | 2927 | recurrenceOve | LocalDateTime[PatchObject] | JSEvent, | Section | 2928 | rrides | | JSTask | 4.3.3 | 2929 | | | | | 2930 | recurrenceRul | RecurrenceRule[] | JSEvent, | Section | 2931 | es | | JSTask | 4.3.2 | 2932 | | | | | 2933 | rel | String | Link | Section | 2934 | | | | 4.2.7 | 2935 | | | | | 2936 | relatedTo | String[Relation] | JSEvent, | Section | 2937 | | | JSTask, | 4.1.3, | 2938 | | | Alert | Section | 2939 | | | | 4.5.2 | 2940 | | | | | 2941 | relation | String[Boolean] | Relation | Section | 2942 | | | | 1.4.10 | 2943 | | | | | 2944 | relativeTo | String | OffsetTrig | Section | 2945 | | | ger, | 4.5.2, | 2946 | | | Location | Section | 2947 | | | | 4.2.5 | 2948 | | | | | 2949 | replyTo | String[String] | JSEvent, | Section | 2950 | | | JSTask | 4.4.4 | 2951 | | | | | 2952 | roles | String[Boolean] | Participan | Section | 2953 | | | t | 4.4.5 | 2954 | | | | | 2955 | rscale | String | Recurrence | Section | 2956 | | | Rule | 4.3.2 | 2957 | | | | | 2958 | scheduleAgent | String | Participan | Section | 2959 | | | t | 4.4.5 | 2960 | | | | | 2961 | scheduleSeque | UnsignedInt | Participan | Section | 2962 | nce | | t | 4.4.5 | 2963 | | | | | 2964 | scheduleUpdat | UTCDateTime | Participan | Section | 2965 | ed | | t | 4.4.5 | 2966 | | | | | 2967 | sendTo | String[String] | Participan | Section | 2968 | | | t | 4.4.5 | 2969 | | | | | 2970 | sequence | UnsignedInt | JSEvent, | Section | 2971 | | | JSTask | 4.1.7 | 2972 | | | | | 2973 | showWithoutTi | Boolean | JSEvent, | Section | 2974 | me | | JSTask | 4.2.4 | 2975 | | | | | 2976 | size | UnsignedInt | Link | Section | 2977 | | | | 4.2.7 | 2978 | | | | | 2979 | skip | String | Recurrence | Section | 2980 | | | Rule | 4.3.2 | 2981 | | | | | 2982 | source | String | JSGroup | Section | 2983 | | | | 5.3.2 | 2984 | | | | | 2985 | start | LocalDateTime | JSEvent, | Section | 2986 | | | JSTask | 5.1.1, | 2987 | | | | Section | 2988 | | | | 5.2.2 | 2989 | | | | | 2990 | status | String | JSEvent | Section | 2991 | | | | 5.1.3 | 2992 | | | | | 2993 | timeZone | String|null | JSEvent, | Section | 2994 | | | JSTask, | 4.7.1, | 2995 | | | Location | Section | 2996 | | | | 4.2.5 | 2997 | | | | | 2998 | timeZones | String[TimeZone] | JSEvent, | Section | 2999 | | | JSTask | 4.7.2 | 3000 | | | | | 3001 | title | String | JSEvent, | Section | 3002 | | | JSTask, | 4.2.1 | 3003 | | | JSGroup, | | 3004 | | | Link | | 3005 | | | | | 3006 | trigger | OffsetTrigger|AbsoluteTrig | Alert | Section | 3007 | | ger|UnknownTrigger | | 4.5.2 | 3008 | | | | | 3009 | uid | String | JSEvent, | Section | 3010 | | | JSTask, | 4.1.2 | 3011 | | | JSGroup | | 3012 | | | | | 3013 | until | LocalDateTime | Recurrence | Section | 3014 | | | Rule | 4.3.2 | 3015 | | | | | 3016 | updated | UTCDateTime | JSEvent, | Section | 3017 | | | JSTask, | 4.1.6 | 3018 | | | JSGroup | | 3019 | | | | | 3020 | uri | String | VirtualLoc | Section | 3021 | | | ation | 4.2.6 | 3022 | | | | | 3023 | useDefaultAle | Boolean | JSEvent, | Section | 3024 | rts | | JSTask | 4.5.1 | 3025 | | | | | 3026 | virtualLocati | Id[VirtualLocation] | JSEvent, | Section | 3027 | ons | | JSTask | 4.2.6 | 3028 | | | | | 3029 | when | UTCDateTime | AbsoluteTr | Section | 3030 | | | igger | 4.5.2 | 3031 +---------------+----------------------------+------------+---------+ 3033 Table 1 3035 8.3. Creation of "JSCalendar Types" Registry 3037 The IANA will create the "JSCalendar Types" registry to avoid name 3038 collisions and provide a complete reference for all data types used 3039 for JSCalendar property values. The registration process is the same 3040 as for the JSCalendar Properties registry, as defined in Section 8.2. 3042 8.3.1. JMAP Types Registry Template 3044 o Type Name: The name of the type. 3046 o Reference or Description: A brief description or RFC number and 3047 section reference where the Type is specified (may be omitted for 3048 "reserved" type names). 3050 o Intended Use: Common, reserved, or obsolete. 3052 o Change Controller: ("IETF" for IETF-stream RFCs). 3054 8.3.2. Initial Contents for the JSCalendar Types Registry 3056 The following table lists the initial entries of the JSCalendar Types 3057 registry. All properties are for common-use. All RFC section 3058 references are for this document. The change controller for all 3059 these properties is "IETF". 3061 +-----------------+--------------------------+ 3062 | Type Name | Reference or Description | 3063 +-----------------+--------------------------+ 3064 | Alert | Section 4.5.2 | 3065 | | | 3066 | Boolean | Section 1.3 | 3067 | | | 3068 | Duration | Section 1.4.5 | 3069 | | | 3070 | Id | Section 1.4.7 | 3071 | | | 3072 | Int | Section 1.4.1 | 3073 | | | 3074 | LocalDateTime | Section 1.4.4 | 3075 | | | 3076 | Link | Section 4.2.7 | 3077 | | | 3078 | Location | Section 4.2.5 | 3079 | | | 3080 | Number | Section 1.3 | 3081 | | | 3082 | Participant | Section 4.4.5 | 3083 | | | 3084 | PatchObject | Section 1.4.8 | 3085 | | | 3086 | RecurrenceRule | Section 4.3.2 | 3087 | | | 3088 | Relation | Section 1.4.10 | 3089 | | | 3090 | SignedDuration | Section 1.4.6 | 3091 | | | 3092 | String | Section 1.3 | 3093 | | | 3094 | TimeZone | Section 4.7.2 | 3095 | | | 3096 | TimeZoneRule | Section 4.7.2 | 3097 | | | 3098 | UnsignedInt | Section 1.4.2 | 3099 | | | 3100 | UTCDateTime | Section 1.4.3 | 3101 | | | 3102 | VirtualLocation | Section 4.2.6 | 3103 +-----------------+--------------------------+ 3105 Table 2 3107 8.4. Creation of "JSCalendar Enum Values" Registry 3109 The IANA will create the "JSCalendar Enum Values" registry to allow 3110 interoperable extension of semantics for properties with enumerable 3111 values. Each such property will have a subregistry of allowed 3112 values. The registration process for creating a new subregistry is 3113 the same as for the JSCalendar Properties registry. The registration 3114 process for a new enum value is the same but is only subject to 3115 Expert Review; a specification is not required for a new allowed 3116 value in an existing enum property where a simple description will 3117 suffice. 3119 8.4.1. JMAP Enum Subregistry Creation Template 3121 This template is for adding a new subregistry to the JMAP Enum 3122 registry. 3124 o Registry Name: This MUST be of the form "Enum Values for 3125 {property-name} (Context: {context})" where: 3127 {property-name} is the name(s) of the property or properties where 3128 these values may be used. This MUST be registered in the 3129 JSCalendar Properties registry. 3131 {context} is the list of allowed object types where the property 3132 or properties may appear, as registered in the JSCalendar 3133 Properties registry. This disambiguates where there may be two 3134 distinct properties with the same name in different contexts. 3136 o Change Controller: ("IETF" for IETF-stream RFCs). 3138 o Experts: The initial list of experts for Expert Review of updates 3139 to the subregistry. 3141 o Initial Contents: The initial list of defined values for this 3142 enum, using the template defined in Section 8.4.2. 3144 8.4.2. JMAP Enum Subregistry Template 3146 This template is for adding a new enum value to a subregistry in the 3147 JMAP Enum registry. 3149 o Enum Value: The verbatim value of the enum. 3151 o Reference or Description: A brief description or RFC number and 3152 section reference for the semantics of this value. 3154 8.4.3. Initial Contents for the JSCalendar Enum Registry 3156 For each subregistry created in this section, all RFC section 3157 references are for this document, the change controller is IETF and 3158 the experts are Neil Jenkins and Robert Stepanek. 3160 ------------------------------------------------------------ 3162 Enum Values for action (Context: Alert) 3164 +------------+--------------------------+ 3165 | Enum Value | Reference or Description | 3166 +------------+--------------------------+ 3167 | display | Section 4.5.2 | 3168 | | | 3169 | email | Section 4.5.2 | 3170 +------------+--------------------------+ 3172 Table 3 3174 ------------------------------------------------------------ 3176 Enum Values for display (Context: Link) 3178 +------------+--------------------------+ 3179 | Enum Value | Reference or Description | 3180 +------------+--------------------------+ 3181 | badge | Section 4.2.7 | 3182 | | | 3183 | graphic | Section 4.2.7 | 3184 | | | 3185 | fullsize | Section 4.2.7 | 3186 | | | 3187 | thumbnail | Section 4.2.7 | 3188 +------------+--------------------------+ 3190 Table 4 3192 ------------------------------------------------------------ 3194 Enum Values for freeBusyStatus (Context: JSEvent, JSTask) 3195 +------------+--------------------------+ 3196 | Enum Value | Reference or Description | 3197 +------------+--------------------------+ 3198 | free | Section 4.4.2 | 3199 | | | 3200 | busy | Section 4.4.2 | 3201 +------------+--------------------------+ 3203 Table 5 3205 ------------------------------------------------------------ 3207 Enum Values for kind (Context: Participant) 3209 +------------+--------------------------+ 3210 | Enum Value | Reference or Description | 3211 +------------+--------------------------+ 3212 | individual | Section 4.4.5 | 3213 | | | 3214 | group | Section 4.4.5 | 3215 | | | 3216 | resource | Section 4.4.5 | 3217 | | | 3218 | location | Section 4.4.5 | 3219 +------------+--------------------------+ 3221 Table 6 3223 ------------------------------------------------------------ 3225 Enum Values for participationStatus (Context: Participant) 3227 +--------------+--------------------------+ 3228 | Enum Value | Reference or Description | 3229 +--------------+--------------------------+ 3230 | needs-action | Section 4.4.5 | 3231 | | | 3232 | accepted | Section 4.4.5 | 3233 | | | 3234 | declined | Section 4.4.5 | 3235 | | | 3236 | tenative | Section 4.4.5 | 3237 | | | 3238 | delegated | Section 4.4.5 | 3239 +--------------+--------------------------+ 3241 Table 7 3243 ------------------------------------------------------------ 3245 Enum Values for privacy (Context: JSEvent, JSTask) 3247 +------------+--------------------------+ 3248 | Enum Value | Reference or Description | 3249 +------------+--------------------------+ 3250 | public | Section 4.4.3 | 3251 | | | 3252 | private | Section 4.4.3 | 3253 | | | 3254 | secret | Section 4.4.3 | 3255 +------------+--------------------------+ 3257 Table 8 3259 ------------------------------------------------------------ 3261 Enum Values for progress (Context: JSTask, Participant) 3263 +--------------+--------------------------+ 3264 | Enum Value | Reference or Description | 3265 +--------------+--------------------------+ 3266 | needs-action | Section 5.2.4 | 3267 | | | 3268 | in-process | Section 5.2.4 | 3269 | | | 3270 | completed | Section 5.2.4 | 3271 | | | 3272 | failed | Section 5.2.4 | 3273 | | | 3274 | cancelled | Section 5.2.4 | 3275 +--------------+--------------------------+ 3277 Table 9 3279 ------------------------------------------------------------ 3281 Enum Values for relation (Context: Relation) 3282 +------------+--------------------------+ 3283 | Enum Value | Reference or Description | 3284 +------------+--------------------------+ 3285 | first | Section 1.4.10 | 3286 | | | 3287 | next | Section 1.4.10 | 3288 | | | 3289 | child | Section 1.4.10 | 3290 | | | 3291 | parent | Section 1.4.10 | 3292 +------------+--------------------------+ 3294 Table 10 3296 ------------------------------------------------------------ 3298 Enum Values for relativeTo (Context: OffsetTrigger, Location) 3300 +------------+--------------------------+ 3301 | Enum Value | Reference or Description | 3302 +------------+--------------------------+ 3303 | start | Section 4.5.2 | 3304 | | | 3305 | end | Section 4.5.2 | 3306 +------------+--------------------------+ 3308 Table 11 3310 ------------------------------------------------------------ 3312 Enum Values for roles (Context: Participant) 3314 +---------------+--------------------------+ 3315 | Enum Value | Reference or Description | 3316 +---------------+--------------------------+ 3317 | owner | Section 4.4.5 | 3318 | | | 3319 | attendee | Section 4.4.5 | 3320 | | | 3321 | optional | Section 4.4.5 | 3322 | | | 3323 | informational | Section 4.4.5 | 3324 | | | 3325 | chair | Section 4.4.5 | 3326 +---------------+--------------------------+ 3328 Table 12 3330 ------------------------------------------------------------ 3332 Enum Values for scheduleAgent (Context: Participant) 3334 +------------+--------------------------+ 3335 | Enum Value | Reference or Description | 3336 +------------+--------------------------+ 3337 | server | Section 4.4.5 | 3338 | | | 3339 | client | Section 4.4.5 | 3340 | | | 3341 | none | Section 4.4.5 | 3342 +------------+--------------------------+ 3344 Table 13 3346 ------------------------------------------------------------ 3348 Enum Values for status (Context: JSEvent) 3350 +------------+--------------------------+ 3351 | Enum Value | Reference or Description | 3352 +------------+--------------------------+ 3353 | confirmed | Section 5.1.3 | 3354 | | | 3355 | cancelled | Section 5.1.3 | 3356 | | | 3357 | tentative | Section 5.1.3 | 3358 +------------+--------------------------+ 3360 Table 14 3362 9. Acknowledgments 3364 The authors would like to thank the members of CalConnect for their 3365 valuable contributions. This specification originated from the work 3366 of the API technical committee of CalConnect, the Calendaring and 3367 Scheduling Consortium. 3369 10. Informative References 3371 [COLORS] "CSS Color Module", . 3373 [LINKRELS] 3374 "IANA Link Relation Types", 3375 . 3378 [MIME] "IANA Media Types", . 3381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3382 Requirement Levels", BCP 14, RFC 2119, 3383 DOI 10.17487/RFC2119, March 1997, 3384 . 3386 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3387 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 3388 . 3390 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3391 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3392 . 3394 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3395 Resource Identifier (URI): Generic Syntax", STD 66, 3396 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3397 . 3399 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3400 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3401 DOI 10.17487/RFC4122, July 2005, 3402 . 3404 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 3405 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 3406 . 3408 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3409 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3410 . 3412 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 3413 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 3414 DOI 10.17487/RFC4791, March 2007, 3415 . 3417 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 3418 Scheduling Core Object Specification (iCalendar)", 3419 RFC 5545, DOI 10.17487/RFC5545, September 2009, 3420 . 3422 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 3423 Interoperability Protocol (iTIP)", RFC 5546, 3424 DOI 10.17487/RFC5546, December 2009, 3425 . 3427 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3428 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3429 September 2009, . 3431 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 3432 Identifier for Geographic Locations ('geo' URI)", 3433 RFC 5870, DOI 10.17487/RFC5870, June 2010, 3434 . 3436 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 3437 Interoperability Protocol (iMIP)", RFC 6047, 3438 DOI 10.17487/RFC6047, December 2010, 3439 . 3441 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3442 Specifications and Registration Procedures", BCP 13, 3443 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3444 . 3446 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 3447 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 3448 DOI 10.17487/RFC6901, April 2013, 3449 . 3451 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 3452 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 3453 2014, . 3455 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 3456 DOI 10.17487/RFC7493, March 2015, 3457 . 3459 [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules 3460 in the Internet Calendaring and Scheduling Core Object 3461 Specification (iCalendar)", RFC 7529, 3462 DOI 10.17487/RFC7529, May 2015, 3463 . 3465 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 3466 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 3467 . 3469 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 3470 DOI 10.17487/RFC7986, October 2016, 3471 . 3473 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3474 Writing an IANA Considerations Section in RFCs", BCP 26, 3475 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3476 . 3478 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3479 Interchange Format", STD 90, RFC 8259, 3480 DOI 10.17487/RFC8259, December 2017, 3481 . 3483 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 3484 DOI 10.17487/RFC8288, October 2017, 3485 . 3487 [TZDB] "IANA Time Zone Database", 3488 . 3490 Authors' Addresses 3492 Neil Jenkins 3493 Fastmail 3494 PO Box 234 3495 Collins St West 3496 Melbourne VIC 8007 3497 Australia 3499 Email: neilj@fastmailteam.com 3500 URI: https://www.fastmail.com 3502 Robert Stepanek 3503 Fastmail 3504 PO Box 234 3505 Collins St West 3506 Melbourne VIC 8007 3507 Australia 3509 Email: rsto@fastmailteam.com 3510 URI: https://www.fastmail.com