idnits 2.17.1 draft-ietf-calext-jscalendar-27.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 (June 15, 2020) is 1411 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 2828, but not defined == Missing Reference: 'Boolean' is mentioned on line 3046, but not defined == Missing Reference: 'Link' is mentioned on line 2957, but not defined == Missing Reference: 'PatchObject' is mentioned on line 3021, but not defined == Missing Reference: 'Location' is mentioned on line 2971, but not defined == Missing Reference: 'Participant' is mentioned on line 2993, but not defined == Missing Reference: 'Relation' is mentioned on line 3030, but not defined == Missing Reference: 'String' is mentioned on line 3061, but not defined == Missing Reference: 'TimeZone' is mentioned on line 3092, but not defined == Missing Reference: 'VirtualLocation' is mentioned on line 3120, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CLDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'COLORS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TZDB' Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring extensions N. Jenkins 3 Internet-Draft R. Stepanek 4 Intended status: Standards Track Fastmail 5 Expires: December 17, 2020 June 15, 2020 7 JSCalendar: A JSON representation of calendar data 8 draft-ietf-calext-jscalendar-27 10 Abstract 12 This specification defines a data model and JSON representation of 13 calendar data that can be used for storage and data exchange in a 14 calendaring and scheduling environment. It aims to be an alternative 15 and, over time, successor to the widely deployed iCalendar data 16 format, and to be unambiguous, extendable, and simple to process. In 17 contrast to the jCal format, which is also JSON-based, JSCalendar is 18 not a direct mapping from iCalendar, but defines the data model 19 independently and expands semantics where appropriate. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 17, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Motivation and Relation to iCalendar and jCal . . . . . . 5 57 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 6 58 1.3. Type Signatures . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.4.1. Int . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.4.2. UnsignedInt . . . . . . . . . . . . . . . . . . . . . 7 62 1.4.3. UTCDateTime . . . . . . . . . . . . . . . . . . . . . 7 63 1.4.4. LocalDateTime . . . . . . . . . . . . . . . . . . . . 7 64 1.4.5. Duration . . . . . . . . . . . . . . . . . . . . . . 8 65 1.4.6. SignedDuration . . . . . . . . . . . . . . . . . . . 8 66 1.4.7. Id . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1.4.8. PatchObject . . . . . . . . . . . . . . . . . . . . . 9 68 1.4.9. Time Zones . . . . . . . . . . . . . . . . . . . . . 9 69 1.4.10. Relation . . . . . . . . . . . . . . . . . . . . . . 10 70 2. JSCalendar Objects . . . . . . . . . . . . . . . . . . . . . 10 71 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3. Structure of JSCalendar Objects . . . . . . . . . . . . . . . 11 75 3.1. Normalization and Equivalence . . . . . . . . . . . . . . 11 76 3.2. Vendor-specific Property Extensions and Values . . . . . 12 77 4. Common JSCalendar Properties . . . . . . . . . . . . . . . . 12 78 4.1. Metadata Properties . . . . . . . . . . . . . . . . . . . 12 79 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 13 82 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 14 86 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.2. What and Where Properties . . . . . . . . . . . . . . . . 14 88 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 15 90 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 15 91 4.2.4. showWithoutTime . . . . . . . . . . . . . . . . . . . 15 92 4.2.5. locations . . . . . . . . . . . . . . . . . . . . . . 15 93 4.2.6. virtualLocations . . . . . . . . . . . . . . . . . . 17 94 4.2.7. links . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.2.8. locale . . . . . . . . . . . . . . . . . . . . . . . 19 96 4.2.9. keywords . . . . . . . . . . . . . . . . . . . . . . 19 97 4.2.10. categories . . . . . . . . . . . . . . . . . . . . . 19 98 4.2.11. color . . . . . . . . . . . . . . . . . . . . . . . . 20 99 4.3. Recurrence Properties . . . . . . . . . . . . . . . . . . 20 100 4.3.1. recurrenceId . . . . . . . . . . . . . . . . . . . . 20 101 4.3.2. recurrenceRules . . . . . . . . . . . . . . . . . . . 20 102 4.3.3. recurrenceOverrides . . . . . . . . . . . . . . . . . 28 103 4.3.4. excluded . . . . . . . . . . . . . . . . . . . . . . 30 104 4.4. Sharing and Scheduling Properties . . . . . . . . . . . . 30 105 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 30 106 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 30 107 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 30 108 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 32 109 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 32 110 4.5. Alerts Properties . . . . . . . . . . . . . . . . . . . . 37 111 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 37 112 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 38 113 4.6. Multilingual Properties . . . . . . . . . . . . . . . . . 40 114 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 40 115 4.7. Time Zone Properties . . . . . . . . . . . . . . . . . . 40 116 4.7.1. timeZone . . . . . . . . . . . . . . . . . . . . . . 41 117 4.7.2. timeZones . . . . . . . . . . . . . . . . . . . . . . 41 118 5. Type-specific JSCalendar Properties . . . . . . . . . . . . . 43 119 5.1. JSEvent Properties . . . . . . . . . . . . . . . . . . . 43 120 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 43 121 5.1.2. duration . . . . . . . . . . . . . . . . . . . . . . 43 122 5.1.3. status . . . . . . . . . . . . . . . . . . . . . . . 44 123 5.2. JSTask Properties . . . . . . . . . . . . . . . . . . . . 44 124 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 44 125 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 44 126 5.2.3. estimatedDuration . . . . . . . . . . . . . . . . . . 45 127 5.2.4. progress . . . . . . . . . . . . . . . . . . . . . . 45 128 5.2.5. progressUpdated . . . . . . . . . . . . . . . . . . . 45 129 5.3. JSGroup Properties . . . . . . . . . . . . . . . . . . . 46 130 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 47 131 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 47 132 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 47 133 6.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 47 134 6.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 47 135 6.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 48 136 6.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 48 137 6.5. Task with a due date . . . . . . . . . . . . . . . . . . 49 138 6.6. Event with end time-zone . . . . . . . . . . . . . . . . 49 139 6.7. Floating-time event (with recurrence) . . . . . . . . . . 50 140 6.8. Event with multiple locations and localization . . . . . 50 141 6.9. Recurring event with overrides . . . . . . . . . . . . . 51 142 6.10. Recurring event with participants . . . . . . . . . . . . 52 143 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 144 7.1. Expanding Recurrences . . . . . . . . . . . . . . . . . . 54 145 7.2. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 54 146 7.3. URI Values . . . . . . . . . . . . . . . . . . . . . . . 55 147 7.4. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . 55 148 7.5. Duplication . . . . . . . . . . . . . . . . . . . . . . . 56 149 7.6. Time Zones . . . . . . . . . . . . . . . . . . . . . . . 56 150 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 151 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 56 152 8.2. Creation of "JSCalendar Properties" Registry . . . . . . 57 153 8.2.1. Preliminary Community Review . . . . . . . . . . . . 58 154 8.2.2. Submit Request to IANA . . . . . . . . . . . . . . . 58 155 8.2.3. Designated Expert Review . . . . . . . . . . . . . . 58 156 8.2.4. Change Procedures . . . . . . . . . . . . . . . . . . 59 157 8.2.5. JSCalendar Properties Registry Template . . . . . . . 59 158 8.2.6. Initial Contents for the JSCalendar Properties 159 Registry . . . . . . . . . . . . . . . . . . . . . . 60 160 8.3. Creation of "JSCalendar Types" Registry . . . . . . . . . 67 161 8.3.1. JSCalendar Types Registry Template . . . . . . . . . 67 162 8.3.2. Initial Contents for the JSCalendar Types Registry . 67 163 8.4. Creation of "JSCalendar Enum Values" Registry . . . . . . 69 164 8.4.1. JSCalendar Enum Property Template . . . . . . . . . . 69 165 8.4.2. JSCalendar Enum Value Template . . . . . . . . . . . 69 166 8.4.3. Initial Contents for the JSCalendar Enum Registry . . 69 167 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 75 168 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 169 10.1. Normative References . . . . . . . . . . . . . . . . . . 75 170 10.2. Informative References . . . . . . . . . . . . . . . . . 77 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 173 1. Introduction 175 This document defines a data model for calendar event and task 176 objects, or groups of such objects, in electronic calendar 177 applications and systems. The format aims to be unambiguous, 178 extendable and simple to process. 180 The key design considerations for this data model are as follows: 182 o The attributes of the calendar entry represented must be described 183 as simple key-value pairs. Simple events are simple to represent; 184 complex events can be modelled accurately. 186 o Wherever possible, there should be only one way to express the 187 desired semantics, reducing complexity. 189 o The data model should avoid ambiguities, which often lead to 190 interoperability issues between implementations. 192 o The data model should be compatible with the iCalendar data format 193 [RFC5545] [RFC7986] and extensions, but the specification should 194 add new attributes where the iCalendar format currently lacks 195 expressivity, and drop seldom-used, obsolete, or redundant 196 properties. This means translation with no loss of semantics 197 should be easy with most common iCalendar files. 199 o Extensions, such as new properties and components, should not 200 require updates to this document. 202 The representation of this data model is defined in the I-JSON format 203 [RFC7493], which is a strict subset of the JavaScript Object Notation 204 (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a 205 pragmatic choice: its widespread use makes JSCalendar easier to 206 adopt, and the ready availability of production-ready JSON 207 implementations eliminates a whole category of parser-related 208 interoperability issues, which iCalendar has often suffered from. 210 1.1. Motivation and Relation to iCalendar and jCal 212 The iCalendar data format [RFC5545], a widely deployed interchange 213 format for calendaring and scheduling data, has served calendaring 214 vendors for a long while, but contains some ambiguities and pitfalls 215 that can not be overcome without backward-incompatible changes. 217 Sources of implementation errors include the following: 219 o iCalendar defines various formats for local times, UTC time, and 220 dates. 222 o iCalendar requires custom time zone definitions within a single 223 calendar component. 225 o iCalendar's definition of recurrence rules is ambiguous and has 226 resulted in differing understandings even between experienced 227 calendar developers. 229 o The iCalendar format itself causes interoperability issues due to 230 misuse of CRLF-terminated strings, line continuations, and subtle 231 differences among iCalendar parsers. 233 In recent years, many new products and services have appeared that 234 wish to use a JSON representation of calendar data within their APIs. 235 The JSON format for iCalendar data, jCal [RFC7265], is a direct 236 mapping between iCalendar and JSON. In its effort to represent full 237 iCalendar semantics, it inherits all the same pitfalls and uses a 238 complicated JSON structure. 240 As a consequence, since the standardization of jCal, the majority of 241 implementations and service providers either kept using iCalendar, or 242 came up with their own proprietary JSON representations, which are 243 incompatible with each other and often suffer from common pitfalls, 244 such as storing event start times in UTC (which become incorrect if 245 the timezone's rules change in the future). JSCalendar meets the 246 demand for JSON-formatted calendar data that is free of such known 247 problems and provides a standard representation as an alternative to 248 the proprietary formats. 250 1.2. Notational Conventions 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in BCP 255 14 [RFC2119] [RFC8174] when, and only when, they appear in all 256 capitals, as shown here. 258 The underlying format used for this specification is JSON. 259 Consequently, the terms "object" and "array" as well as the four 260 primitive types (strings, numbers, booleans, and null) are to be 261 interpreted as described in Section 1 of [RFC8259]. 263 Some examples in this document contain "partial" JSON documents used 264 for illustrative purposes. In these examples, three periods "..." 265 are used to indicate a portion of the document that has been removed 266 for compactness. 268 1.3. Type Signatures 270 Type signatures are given for all JSON values in this document. The 271 following conventions are used: 273 o "*" - The type is undefined (the value could be any type, although 274 permitted values may be constrained by the context of this value). 276 o "String" - The JSON string type. 278 o "Number" - The JSON number type. 280 o "Boolean" - The JSON boolean type. 282 o "A[B]" - A JSON object where the keys are all of type "A", and the 283 values are all of type "B". 285 o "A[]" - An array of values of type "A". 287 o "A|B" - The value is either of type "A" or of type "B". 289 Other types may also be given, with their representations defined 290 elsewhere in this document. 292 1.4. Data Types 294 In addition to the standard JSON data types, the following data types 295 are used in this specification: 297 1.4.1. Int 299 Where "Int" is given as a data type, it means an integer in the range 300 -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a 301 floating-point double, represented as a JSON "Number". 303 1.4.2. UnsignedInt 305 Where "UnsignedInt" is given as a data type, it means an integer in 306 the range 0 <= value <= 2^53-1, represented as a JSON "Number". 308 1.4.3. UTCDateTime 310 This is a string in [RFC3339] "date-time" format, with the further 311 restrictions that any letters MUST be in uppercase, the time 312 component MUST be included and the time offset MUST be the character 313 "Z". Fractional second values MUST NOT be included unless non-zero 314 and MUST NOT have trailing zeros, to ensure there is only a single 315 representation for each date-time. 317 For example "2010-10-10T10:10:10.003Z" is OK, but 318 "2010-10-10T10:10:10.000Z" is invalid and is correctly encoded as 319 "2010-10-10T10:10:10Z". 321 1.4.4. LocalDateTime 323 This is a date-time string with no time zone/offset information. It 324 is otherwise in the same format as UTCDateTime, including fractional 325 seconds. For example "2006-01-02T15:04:05" and 326 "2006-01-02T15:04:05.003" are both valid. The time zone to associate 327 the LocalDateTime with comes from an associated property, or if no 328 time zone is associated it defines "floating time". Floating date- 329 times are not tied to any specific time zone. Instead, they occur in 330 each time zone at the given wall-clock time (as opposed to the same 331 instant point in time). 333 1.4.5. Duration 335 Where Duration is given as a type, it means a length of time 336 represented by a subset of ISO8601 duration format, as specified by 337 the following ABNF [RFC5234]: 339 dur-secfrac = "." 1*DIGIT 340 dur-second = 1*DIGIT [dur-secfrac] "S" 341 dur-minute = 1*DIGIT "M" [dur-second] 342 dur-hour = 1*DIGIT "H" [dur-minute] 343 dur-time = "T" (dur-hour / dur-minute / dur-second) 344 dur-day = 1*DIGIT "D" 345 dur-week = 1*DIGIT "W" 347 duration = "P" (dur-day [dur-time] / dur-time / dur-week) 349 In addition, the duration MUST NOT include fractional second values 350 unless the fraction is non-zero. 352 1.4.6. SignedDuration 354 A SignedDuration represents a length of time that may be positive or 355 negative and is typically used to express the offset of a point in 356 time relative to an associated time. It is represented as a 357 Duration, optionally preceded by a sign character. It is specified 358 by the following ABNF: 360 signed-duration = ["+" / "-"] duration 362 A negative sign indicates a point in time at or before the associated 363 time, a positive or no sign a time at or after the associated time. 365 1.4.7. Id 367 Where "Id" is given as a data type, it means a "String" of at least 1 368 and a maximum of 255 octets in size, and it MUST only contain 369 characters from the "URL and Filename Safe" base64url alphabet, as 370 defined in Section 5 of [RFC4648], excluding the pad character ("="). 371 This means the allowed characters are the ASCII alphanumeric 372 characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). 374 Unless otherwise specified, Ids are arbitrary and only have meaning 375 within the object where they are being used. Ids need not be unique 376 among different objects. For example, two JSEvent objects might use 377 the same ids in their respective "links" properties. Or within the 378 same JSEvent object the same Id could appear in the "participants" 379 and "alerts" properties. These situations do not imply any semantic 380 connections among the objects. 382 Nevertheless, a UUID is typically a good choice. 384 1.4.8. PatchObject 386 A PatchObject is of type "String[*]", and represents an unordered set 387 of patches on a JSON object. Each key is a path represented in a 388 subset of JSON pointer format [RFC6901]. The paths have an implicit 389 leading "/", so each key is prefixed with "/" before applying the 390 JSON pointer evaluation algorithm. 392 A patch within a PatchObject is only valid if all of the following 393 conditions apply: 395 1. The pointer MUST NOT insert/delete from an array; the array MUST 396 be replaced in its entirety instead. 398 2. When evaluating a path, all parts prior to the last (i.e., the 399 value after the final slash) MUST exist. 401 3. There MUST NOT be two patches in the PatchObject where the 402 pointer of one is a prefix of the pointer of the other, e.g., 403 "alerts/foo/offset" and "alerts". 405 4. The value for the patch MUST be valid for the property being set 406 (of the correct type and obeying any other applicable 407 restrictions), or if null the property MUST be optional. 409 The value associated with each pointer is either: 411 o null: Remove the property at the given path from the patched 412 object. If the property is not present in the object, this a no- 413 op. 415 o Anything else: Set the value for the property to this value (this 416 may be a replacement or addition to the object being patched). 418 Implementations MUST reject in its entirety a PatchObject if any of 419 its patches is invalid. Implementations MUST NOT apply partial 420 patches. 422 1.4.9. Time Zones 424 By default, time zones in JSCalendar are identified by their names in 425 the IANA Time Zone Database [TZDB], and the zone rules of the 426 respective zone records apply. 428 Implementations MAY embed the definitions of custom time zones in the 429 "timeZones" property (see Section 4.7.2). 431 1.4.10. Relation 433 A Relation object defines the relation to other objects, using a 434 possibly empty set of relation types. The object that defines this 435 relation is the linking object, while the other object is the linked 436 object. The Relation object has the following properties: 438 o @type: "String" (mandatory) 440 Specifies the type of this object. This MUST be "Relation". 442 o relation: "String[Boolean]" (optional, default: empty Object) 444 Describes how the linked object is related to the linking object. 445 The relation is defined as a set of relation types. If empty, the 446 relationship between the two objects is unspecified. 448 Keys in the set MUST be one of the following values, or specified 449 in the property definition where the Relation object is used, or a 450 value registered in the IANA JSCalendar Enum Registry, or a 451 vendor-specific value: 453 * "first": The linked object is the first in a series the linking 454 object is part of. 456 * "next": The linked object is the next in a series the linking 457 object is part of. 459 * "child": The linked object is a subpart of the linking object. 461 * "parent": The linking object is a subpart of the linked object. 463 The value for each key in the set MUST be true. 465 2. JSCalendar Objects 467 This section describes the calendar object types specified by 468 JSCalendar. 470 2.1. JSEvent 472 Media type: "application/jscalendar+json;type=jsevent" 474 A JSEvent represents a scheduled amount of time on a calendar, 475 typically a meeting, appointment, reminder or anniversary. It is 476 required to start at a certain point in time and typically has a non- 477 zero duration. Multiple participants may partake in the event at 478 multiple locations. 480 The @type (Section 4.1.1) property value MUST be "jsevent". 482 2.2. JSTask 484 Media type: "application/jscalendar+json;type=jstask" 486 A JSTask represents an action-item, assignment, to-do or work item. 487 It may start and be due at certain points in time, may take some 488 estimated time to complete, and may recur, none of which is required. 490 The @type (Section 4.1.1) property value MUST be "jstask". 492 2.3. JSGroup 494 Media type: "application/jscalendar+json;type=jsgroup" 496 A JSGroup is a collection of JSEvent (Section 2.1) and/or JSTask 497 (Section 2.2) objects. Typically, objects are grouped by topic 498 (e.g., by keywords) or calendar membership. 500 The @type (Section 4.1.1) property value MUST be "jsgroup". 502 3. Structure of JSCalendar Objects 504 A JSCalendar object is a JSON object, which MUST be valid I-JSON (a 505 stricter subset of JSON), as specified in [RFC8259]. Property names 506 and values are case-sensitive. 508 The object has a collection of properties, as specified in the 509 following sections. Properties are specified as being either 510 mandatory or optional. Optional properties may have a default value, 511 if explicitly specified in the property definition. 513 3.1. Normalization and Equivalence 515 JSCalendar aims to provide unambiguous definitions for value types 516 and properties, but does not define a general normalization or 517 equivalence method for JSCalendar objects and types. This is because 518 the notion of equivalence might range from byte-level equivalence to 519 semantic equivalence, depending on the respective use case. 521 Normalization of JSCalendar objects is hindered because of the 522 following reasons: 524 o Custom JSCalendar properties may contain arbitrary JSON values, 525 including arrays. However, equivalence of arrays might or might 526 not depend on the order of elements, depending on the respective 527 property definition. 529 o Several JSCalendar property values are defined as URIs and media 530 types, but normalization of these types is inherently protocol- 531 and scheme-specific, depending on the use-case of the equivalence 532 definition (see Section 6 of [RFC3986]). 534 Considering this, the definition of equivalence and normalization is 535 left to client and server implementations and to be negotiated by a 536 calendar exchange protocol or defined elsewhere. 538 3.2. Vendor-specific Property Extensions and Values 540 Vendors MAY add additional properties to the calendar object to 541 support their custom features. The names of these properties MUST be 542 prefixed with a domain name controlled by the vendor to avoid 543 conflict, e.g., "example.com/customprop". 545 Some JSCalendar properties allow vendor-specific value extensions. 546 Such vendor-specific values MUST be prefixed with a domain name 547 controlled by the vendor, e.g., "example.com/customrel". 549 Vendors are strongly encouraged to register any new property values 550 or extensions that are useful to other systems as well, rather than 551 use a vendor-specific prefix. 553 4. Common JSCalendar Properties 555 This section describes the properties that are common to the various 556 JSCalendar object types. Specific JSCalendar object types may only 557 support a subset of these properties. The object type definitions in 558 Section 5 describe the set of supported properties per type. 560 4.1. Metadata Properties 562 4.1.1. @type 564 Type: "String" (mandatory). 566 Specifies the type which this object represents. This MUST be one of 567 the following values: 569 o "jsevent": a JSCalendar event (Section 2.1). 571 o "jstask": a JSCalendar task (Section 2.2). 573 o "jsgroup": a JSCalendar group (Section 2.3). 575 4.1.2. uid 577 Type: "String" (mandatory). 579 A globally unique identifier, used to associate the object as the 580 same across different systems, calendars and views. The value of 581 this property MUST be unique across all JSCalendar objects, even if 582 they are of different type. [RFC4122] describes a range of 583 established algorithms to generate universally unique identifiers 584 (UUID). UUID version 4, described in Section 4.4 of [RFC4122], is 585 RECOMMENDED. 587 For compatibility with [RFC5545] UIDs, implementations MUST be able 588 to receive and persist values of at least 255 octets for this 589 property, but they MUST NOT truncate values in the middle of a UTF-8 590 multi-octet sequence. 592 4.1.3. relatedTo 594 Type: "String[Relation]" (optional). 596 Relates the object to other JSCalendar objects. This is represented 597 as a map of the UIDs of the related objects to information about the 598 relation. 600 If an object is split to make a "this and future" change to a 601 recurrence, the original object MUST be truncated to end at the 602 previous occurrence before this split, and a new object created to 603 represent all the occurrences after the split. A "next" relation 604 MUST be set on the original object's relatedTo property for the UID 605 of the new object. A "first" relation for the UID of the first 606 object in the series MUST be set on the new object. Clients can then 607 follow these UIDs to get the complete set of objects if the user 608 wishes to modify them all at once. 610 4.1.4. prodId 612 Type: "String" (optional). 614 The identifier for the product that last updated the JSCalendar 615 object. This should be set whenever the data in the object is 616 modified (i.e., whenever the "updated" property is set). 618 The vendor of the implementation SHOULD ensure that this is a 619 globally unique identifier, using some technique such as an FPI 620 value, as defined in [ISO.9070.1991]. It MUST only use characters of 621 an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]). 623 This property SHOULD NOT be used to alter the interpretation of a 624 JSCalendar object beyond the semantics specified in this document. 625 For example, it is not to be used to further the understanding of 626 non-standard properties, a practice that is knows to cause long-term 627 interoperability problems. 629 4.1.5. created 631 Type: "UTCDateTime" (optional). 633 The date and time this object was initially created. 635 4.1.6. updated 637 Type: "UTCDateTime" (mandatory). 639 The date and time the data in this object was last modified (or its 640 creation date/time if not modified since). 642 4.1.7. sequence 644 Type: "UnsignedInt" (optional, default: 0). 646 Initially zero, this MUST be incremented by one every time a change 647 is made to the object, except if the change only modifies the 648 "participants" property (see Section 4.4.5). 650 This is used as part of iTIP [RFC5546] to know which version of the 651 object a scheduling message relates to. 653 4.1.8. method 655 Type: "String" (optional). 657 The iTIP [RFC5546] method, in lowercase. This MUST only be present 658 if the JSCalendar object represents an iTIP scheduling message. 660 4.2. What and Where Properties 662 4.2.1. title 664 Type: "String" (optional, default: empty String). 666 A short summary of the object. 668 4.2.2. description 670 Type: "String" (optional, default: empty String). 672 A longer-form text description of the object. The content is 673 formatted according to the "descriptionContentType" property. 675 4.2.3. descriptionContentType 677 Type: "String" (optional, default: "text/plain"). 679 Describes the media type [RFC6838] of the contents of the 680 "description" property. Media types MUST be sub-types of type 681 "text", and SHOULD be "text/plain" or "text/html" [MIME]. They MAY 682 include parameters and the "charset" parameter value MUST be "utf-8", 683 if specified. Descriptions of type "text/html" MAY contain "cid" 684 URLs [RFC2392] to reference links in the calendar object by use of 685 the "cid" property of the Link object. 687 4.2.4. showWithoutTime 689 Type: "Boolean" (optional, default: false). 691 Indicates that the time is not important to display to the user when 692 rendering this calendar object. An example of this is an event that 693 conceptually occurs all day or across multiple days, such as "New 694 Year's Day" or "Italy Vacation". While the time component is 695 important for free-busy calculations and checking for scheduling 696 clashes, calendars may choose to omit displaying it and/or display 697 the object separately to other objects to enhance the user's view of 698 their schedule. 700 Such events are also commonly known as "all-day" events. 702 4.2.5. locations 704 Type: "Id[Location]" (optional). 706 A map of location ids to Location objects, representing locations 707 associated with the object. 709 A Location object has the following properties. It MUST have at 710 least one property other than the "relativeTo" property. 712 o @type: "String" (mandatory) 714 Specifies the type of this object. This MUST be "Location". 716 o name: "String" (optional) 718 The human-readable name of the location. 720 o description: "String" (optional) 722 Human-readable, plain-text instructions for accessing this 723 location. This may be an address, set of directions, door access 724 code, etc. 726 o locationTypes: "String[Boolean]" (optional) 728 A set of one or more location types that describe this location. 729 All types MUST be from the Location Types Registry [LOCATIONTYPES] 730 as defined in [RFC4589]. The set is represented as a map, with 731 the keys being the location types. The value for each key in the 732 map MUST be true. 734 o relativeTo: "String" (optional) 736 Specifies the relation between this location and the time of the 737 JSCalendar object. This is primarily to allow events representing 738 travel to specify the location of departure (at the start of the 739 event) and location of arrival (at the end); this is particularly 740 important if these locations are in different time zones, as a 741 client may wish to highlight this information for the user. 743 This MUST be one of the following values, a value registered in 744 the IANA JSCalendar Enum Registry, or a vendor-specific value. 745 Any value the client or server doesn't understand should be 746 treated the same as if this property is omitted. 748 * "start": The event/task described by this JSCalendar object 749 occurs at this location at the time the event/task starts. 751 * "end": The event/task described by this JSCalendar object 752 occurs at this location at the time the event/task ends. 754 o timeZone: "String" (optional) 756 A time zone for this location. See also Section 1.4.9. 758 o coordinates: "String" (optional) 760 A "geo:" URI [RFC5870] for the location. 762 o linkIds: "Id[Boolean]" (optional) 763 A set of link ids for links to alternative representations of this 764 location. Each key in the set MUST be the id of a Link object 765 defined in the "links" property of this calendar object. The 766 value for each key in the set MUST be true. If there are no 767 links, this MUST be omitted (rather than specified as an empty 768 set). 770 For example, an alternative representation could be in vCard 771 format. 773 4.2.6. virtualLocations 775 Type: "Id[VirtualLocation]" (optional). 777 A map of ids to VirtualLocation objects, representing virtual 778 locations, such as video conferences or chat rooms, associated with 779 the object. 781 A VirtualLocation object has the following properties. 783 o @type: "String" (mandatory) 785 Specifies the type of this object. This MUST be 786 "VirtualLocation". 788 o name: "String" (optional, default: empty String) 790 The human-readable name of the virtual location. 792 o description: "String" (optional) 794 Human-readable plain-text instructions for accessing this 795 location. This may be an address, set of directions, door access 796 code, etc. 798 o uri: "String" (mandatory) 800 A URI that represents how to connect to this virtual location. 802 This may be a telephone number (represented using the "tel:" 803 scheme, e.g., "tel:+1-555-555-555") for a teleconference, a web 804 address for online chat, or any custom URI. 806 4.2.7. links 808 Type: "Id[Link]" (optional). 810 A map of link ids to Link objects, representing external resources 811 associated with the object. 813 A Link object has the following properties: 815 o @type: "String" (mandatory) 817 Specifies the type of this object. This MUST be "Link". 819 o href: "String" (mandatory) 821 A URI from which the resource may be fetched. 823 This MAY be a "data:" URL [RFC2397], but it is recommended that 824 the file be hosted on a server to avoid embedding arbitrarily 825 large data in JSCalendar object instances. 827 o cid: "String" (optional) 829 This MUST be a valid "content-id" value according to the 830 definition of Section 2 in [RFC2392]. The value MUST be unique 831 within this Link object but has no meaning beyond that. It MAY be 832 different from the link id for this Link object. 834 o contentType: "String" (optional) 836 The media type [RFC6838] of the resource, if known. 838 o size: "UnsignedInt" (optional) 840 The size, in octets, of the resource when fully decoded (i.e., the 841 number of octets in the file the user would download), if known. 842 Note that this is an informational estimate, and implementations 843 must be prepared to handle the actual size being quite different 844 when the resource is fetched. 846 o rel: "String" (optional) 848 Identifies the relation of the linked resource to the object. If 849 set, the value MUST be a relation type from the IANA registry 850 [LINKRELS], as established in [RFC8288]. 852 Links with a rel of "enclosure" MUST be considered by the client 853 as attachments for download. 855 Links with a rel of "describedby" MUST be considered by the client 856 to be an alternative representation of the description. 858 Links with a rel of "icon" MUST be considered by the client to be 859 an image that it may use when presenting the calendar data to a 860 user. The "display" property may be set to indicate the purpose 861 of this image. 863 o display: "String" (optional) 865 Describes the intended purpose of a link to an image. If set, the 866 "rel" property MUST be set to "icon". The value MUST be one of 867 the following values, a value registered in the IANA JSCalendar 868 Enum Registry, or a vendor-specific value: 870 * "badge": an image meant to be displayed alongside the title of 871 the object. 873 * "graphic": a full image replacement for the object itself. 875 * "fullsize": an image that is used to enhance the object. 877 * "thumbnail": a smaller variant of "fullsize" to be used when 878 space for the image is constrained. 880 o title: "String" (optional) 882 A human-readable plain-text description of the resource. 884 4.2.8. locale 886 Type: "String" (optional). 888 The language tag as defined in [RFC5646] that best describes the 889 locale used for the text in the calendar object, if known. 891 4.2.9. keywords 893 Type: "String[Boolean]" (optional). 895 A set of keywords or tags that relate to the object. The set is 896 represented as a map, with the keys being the keywords. The value 897 for each key in the map MUST be true. 899 4.2.10. categories 901 Type: "String[Boolean]" (optional). 903 A set of categories that relate to the calendar object. The set is 904 represented as a map, with the keys being the categories specified as 905 URIs. The value for each key in the map MUST be true. 907 In contrast to keywords, categories typically are structured. For 908 example, a vendor owning the domain "example.com" might define the 909 categories "http://example.com/categories/sports/american-football" 910 and "http://example.com/categories/music/r-b". 912 4.2.11. color 914 Type: "String" (optional). 916 A color clients MAY use when displaying this calendar object. The 917 value is a color name taken from the set of names defined in 918 Section 4.3 of CSS Color Module Level 3 [COLORS], or an RGB value in 919 hexadecimal notation, as defined in Section 4.2.1 of CSS Color Module 920 Level 3. 922 4.3. Recurrence Properties 924 Some events and tasks occur at regular or irregular intervals. 925 Rather than having to copy the data for every occurrence there can be 926 a master event with a recurrence rule, and/or overrides that add 927 extra dates or exceptions to the rule. 929 4.3.1. recurrenceId 931 Type: "LocalDateTime" (optional). 933 If present, this JSCalendar object represents one occurrence of a 934 recurring JSCalendar object. If present the "recurrenceRules" and 935 "recurrenceOverrides" properties MUST NOT be present. 937 The value is a date-time either produced by the "recurrenceRules" of 938 the master event, or added as a key to the "recurrenceOverrides" 939 property of the master event. 941 4.3.2. recurrenceRules 943 Type: "RecurrenceRule[]" (optional). 945 Defines a set of recurrence rules (repeating patterns) for recurring 946 calendar objects. 948 A JSEvent recurs by applying the recurrence rules to the "start" 949 date-time. 951 A JSTask recurs by applying the recurrence rules to the "start" date- 952 time, if defined, otherwise it recurs by the "due" date-time, if 953 defined. If the task defines neither a "start" nor "due" date-time, 954 it MUST NOT define a "recurrenceRules" property. 956 If multiple recurrence rules are given, each rule is to be applied 957 and then the union of the results used, ignoring any duplicates. 959 A RecurrenceRule object is a JSON object mapping of a RECUR value 960 type in iCalendar [RFC5545] [RFC7529] and has the same semantics. It 961 has the following properties: 963 o @type: "String" (mandatory) 965 Specifies the type of this object. This MUST be "RecurrenceRule". 967 o frequency: "String" (mandatory) 969 The time span covered by each iteration of this recurrence rule 970 (see Section 4.3.2.1 for full semantics). This MUST be one of the 971 following values: 973 * "yearly" 975 * "monthly" 977 * "weekly" 979 * "daily" 981 * "hourly" 983 * "minutely" 985 * "secondly" 987 This is the FREQ part from iCalendar, converted to lowercase. 989 o interval: "UnsignedInt" (optional, default: 1) 991 The interval of iteration periods at which the recurrence repeats. 992 If included, it MUST be an integer >= 1. 994 This is the INTERVAL part from iCalendar. 996 o rscale: "String" (optional, default: "gregorian") 998 The calendar system in which this recurrence rule operates, in 999 lowercase. This MUST be either a CLDR-registered calendar system 1000 name [CLDR], or a vendor-specific value. 1002 This is the RSCALE part from iCalendar RSCALE [RFC7529], converted 1003 to lowercase. 1005 o skip: "String" (optional, default: "omit") 1007 The behaviour to use when the expansion of the recurrence produces 1008 invalid dates. This property only has an effect if the frequency 1009 is "yearly" or "monthly". It MUST be one of the following values: 1011 * "omit" 1013 * "backward" 1015 * "forward" 1017 This is the SKIP part from iCalendar RSCALE [RFC7529], converted 1018 to lowercase. 1020 o firstDayOfWeek: "String" (optional, default: "mo") 1022 The day on which the week is considered to start, represented as a 1023 lowercase abbreviated two-letter English day of the week. If 1024 included, it MUST be one of the following values: 1026 * "mo" 1028 * "tu" 1030 * "we" 1032 * "th" 1034 * "fr" 1036 * "sa" 1038 * "su" 1040 This is the WKST part from iCalendar. 1042 o byDay: "NDay[]" (optional) 1044 Days of the week on which to repeat. An "NDay" object has the 1045 following properties: 1047 * day: "String" (mandatory) 1049 A day of the week on which to repeat; the allowed values are 1050 the same as for the "firstDayOfWeek" RecurrenceRule property. 1052 This is the day-of-the-week of the BYDAY part in iCalendar, 1053 converted to lowercase. 1055 * nthOfPeriod: "Int" (optional) 1057 If present, rather than representing every occurrence of the 1058 weekday defined in the "day" property, it represents only a 1059 specific instance within the recurrence period. The value can 1060 be positive or negative, but MUST NOT be zero. A negative 1061 integer means nth-last of period. 1063 This is the ordinal part of the BYDAY value in iCalendar (e.g., 1064 1 or -3). 1066 o byMonthDay: "Int[]" (optional) 1068 Days of the month on which to repeat. Valid values are between 1 1069 and the maximum number of days any month may have in the calendar 1070 given by the "rscale" property, and the negative values of these 1071 numbers. For example, in the Gregorian calendar valid values are 1072 1 to 31 and -31 to -1. Negative values offset from the end of the 1073 month. The array MUST have at least one entry if included. 1075 This is the BYMONTHDAY part in iCalendar. 1077 o byMonth: "String[]" (optional) 1079 The months in which to repeat. Each entry is a string 1080 representation of a number, starting from "1" for the first month 1081 in the calendar (e.g., "1" means January with the Gregorian 1082 calendar), with an optional "L" suffix (see [RFC7529]) for leap 1083 months (this MUST be uppercase, e.g., "3L"). The array MUST have 1084 at least one entry if included. 1086 This is the BYMONTH part from iCalendar. 1088 o byYearDay: "Int[]" (optional) 1090 The days of the year on which to repeat. Valid values are between 1091 1 and the maximum number of days any year may have in the calendar 1092 given by the "rscale" property, and the negative values of these 1093 numbers. For example, in the Gregorian calendar valid values are 1094 1 to 366 and -366 to -1. Negative values offset from the end of 1095 the year. The array MUST have at least one entry if included. 1097 This is the BYYEARDAY part from iCalendar. 1099 o byWeekNo: "Int[]" (optional) 1100 Weeks of the year in which to repeat. Valid values are between 1 1101 and the maximum number of weeks any year may have in the calendar 1102 given by the "rscale" property, and the negative values of these 1103 numbers. For example, in the Gregorian calendar valid values are 1104 1 to 53 and -53 to -1. The array MUST have at least one entry if 1105 included. 1107 This is the BYWEEKNO part from iCalendar. 1109 o byHour: "UnsignedInt[]" (optional) 1111 The hours of the day in which to repeat. Valid values are 0 to 1112 23. The array MUST have at least one entry if included. This is 1113 the BYHOUR part from iCalendar. 1115 o byMinute: "UnsignedInt[]" (optional) 1117 The minutes of the hour in which to repeat. Valid values are 0 to 1118 59. The array MUST have at least one entry if included. 1120 This is the BYMINUTE part from iCalendar. 1122 o bySecond: "UnsignedInt[]" (optional) 1124 The seconds of the minute in which to repeat. Valid values are 0 1125 to 60. The array MUST have at least one entry if included. 1127 This is the BYSECOND part from iCalendar. 1129 o bySetPosition: "Int[]" (optional) 1131 The occurrences within the recurrence interval to include in the 1132 final results. Negative values offset from the end of the list of 1133 occurrences. The array MUST have at least one entry if included. 1134 This is the BYSETPOS part from iCalendar. 1136 o count: "UnsignedInt" (optional) 1138 The number of occurrences at which to range-bound the recurrence. 1139 This MUST NOT be included if an "until" property is specified. 1141 This is the COUNT part from iCalendar. 1143 o until: "LocalDateTime" (optional) 1145 The date-time at which to finish recurring. The last occurrence 1146 is on or before this date-time. This MUST NOT be included if a 1147 "count" property is specified. Note: if not specified otherwise 1148 for a specific JSCalendar object, this date is to be interpreted 1149 in the time zone specified in the JSCalendar object's "timeZone" 1150 property. 1152 This is the UNTIL part from iCalendar. 1154 4.3.2.1. Interpreting recurrence rules 1156 A recurrence rule specifies a set of date-times for recurring 1157 calendar objects. A recurrence rule has the following semantics. 1158 Note, wherever "year", "month" or "day of month" is used, this is 1159 within the calendar system given by the "rscale" property, which 1160 defaults to "gregorian" if omitted. 1162 1. A set of candidates is generated. This is every second within a 1163 period defined by the frequency property value: 1165 * "yearly": every second from midnight on the 1st day of a year 1166 (inclusive) to midnight the 1st day of the following year 1167 (exclusive). 1169 If skip is not "omit", the calendar system has leap months and 1170 there is a byMonth property, generate candidates for the leap 1171 months even if they don't occur in this year. 1173 If skip is not "omit" and there is a byMonthDay property, 1174 presume each month has the maximum number of days any month 1175 may have in this calendar system when generating candidates, 1176 even if it's more than this month actually has. 1178 * "monthly": every second from midnight on the 1st day of a 1179 month (inclusive) to midnight on the 1st of the following 1180 month (exclusive). 1182 If skip is not "omit" and there is a byMonthDay property, 1183 presume the month has the maximum number of days any month may 1184 have in this calendar system when generating candidates, even 1185 if it's more than this month actually has. 1187 * "weekly": every second from midnight (inclusive) on the first 1188 day of the week (as defined by the firstDayOfWeek property, or 1189 Monday if omitted), to midnight 7 days later (exclusive). 1191 * "daily": every second from midnight at the start of the day 1192 (inclusive) to midnight at the end of the day (exclusive). 1194 * "hourly": every second from the beginning of the hour 1195 (inclusive) to the beginning of the next hour (exclusive). 1197 * "minutely": every second from the beginning of the minute 1198 (inclusive) to the beginning of the next minute (exclusive). 1200 * "secondly": the second itself, only. 1202 2. Each date-time candidate is compared against all of the byX 1203 properties of the rule except bySetPosition. If any property in 1204 the rule does not match the date-time, it is eliminated. Each 1205 byX property is an array; the date-time matches the property if 1206 it matches any of the values in the array. The properties have 1207 the following semantics: 1209 * byMonth: the date-time is in the given month. 1211 * byWeekNo: the date-time is in the nth week of the year. 1212 Negative numbers mean the nth last week of the year. This 1213 corresponds to weeks according to week numbering as defined in 1214 ISO.8601.2004, with a week defined as a seven day period, 1215 starting on the firstDayOfWeek property value or Monday if 1216 omitted. Week number one of the calendar year is the first 1217 week that contains at least four days in that calendar year. 1219 If the date-time is not valid (this may happen when generating 1220 candidates with a skip property in effect), it is always 1221 eliminated by this property. 1223 * byYearDay: the date-time is on the nth day of year. Negative 1224 numbers mean the nth last day of the year. 1226 If the date-time is not valid (this may happen when generating 1227 candidates with a skip property in effect), it is always 1228 eliminated by this property. 1230 * byMonthDay: the date-time is on the given day of the month. 1231 Negative numbers mean the nth last day of the month. 1233 * byDay: the date-time is on the given day of the week. If the 1234 day is prefixed by a number, it is the nth occurrence of that 1235 day of the week within the month (if frequency is monthly) or 1236 year (if frequency is yearly). Negative numbers means nth 1237 last occurrence within that period. 1239 * byHour: the date-time has the given hour value. 1241 * byMinute: the date-time has the given minute value. 1243 * bySecond: the date-time has the given second value. 1245 If a skip property is defined and is not "omit", there may be 1246 candidates that do not correspond to valid dates (e.g., 31st 1247 February in the Gregorian calendar). In this case, the 1248 properties MUST be considered in the order above and: 1250 1. After applying the byMonth filter, if the candidate's month 1251 is invalid for the given year, increment it (if skip is 1252 "forward") or decrement it (if skip is "backward") until a 1253 valid month is found, incrementing/decrementing the year as 1254 well if passing through the beginning/end of the year. This 1255 only applies to calendar systems with leap months. 1257 2. After applying the byMonthDay filter, if the day of the month 1258 is invalid for the given month and year, change the date to 1259 the first day of the next month (if skip is "forward") or the 1260 last day of the current month (if skip is "backward"). 1262 3. If any valid date produced after applying the skip is already 1263 a candidate, eliminate the duplicate. (For example after 1264 adjusting, 30th February and 31st February would both become 1265 the same "real" date, so one is eliminated as a duplicate.) 1267 3. If a bySetPosition property is included, this is now applied to 1268 the ordered list of remaining dates. This property specifies the 1269 indexes of date-times to keep; all others should be eliminated. 1270 Negative numbers are indexes from the end of the list, with -1 1271 being the last item. 1273 4. Any date-times before the start date of the event are eliminated 1274 (see below for why this might be needed). 1276 5. If a skip property is included and is not "omit", eliminate any 1277 date-times that have already been produced by previous iterations 1278 of the algorithm. (This is not possible if skip is "omit".) 1280 6. If further dates are required (we have not reached the until 1281 date, or count limit) skip the next (interval - 1) sets of 1282 candidates, then continue from step 1. 1284 When determining the set of occurrence dates for an event or task, 1285 the following extra rules must be applied: 1287 1. The initial date-time to which the rule is applied (the "start" 1288 date-time for events; the "start" or "due" date-time for tasks) 1289 is always the first occurrence in the expansion (and is counted 1290 if the recurrence is limited by a "count" property), even if it 1291 would normally not match the rule. 1293 2. The first set of candidates to consider is that which would 1294 contain the initial date-time. This means the first set may 1295 include candidates before the initial date-time; such candidates 1296 are eliminated from the results in step (4) as outlined before. 1298 3. The following properties MUST be implicitly added to the rule 1299 under the given conditions: 1301 * If frequency is not "secondly" and no bySecond property: Add a 1302 bySecond property with the sole value being the seconds value 1303 of the initial date-time. 1305 * If frequency is not "secondly" or "minutely", and no byMinute 1306 property: Add a byMinute property with the sole value being 1307 the minutes value of the initial date-time. 1309 * If frequency is not "secondly", "minutely" or "hourly" and no 1310 byHour property: Add a byHour property with the sole value 1311 being the hours value of the initial date-time. 1313 * If frequency is "weekly" and no byDay property: Add a byDay 1314 property with the sole value being the day-of-the-week of the 1315 initial date-time. 1317 * If frequency is "monthly" and no byDay property and no 1318 byMonthDay property: Add a byMonthDay property with the sole 1319 value being the day-of-the-month of the initial date-time. 1321 * If frequency is "yearly" and no byYearDay property: 1323 + If there are no byMonth or byWeekNo properties, and either 1324 there is a byMonthDay property or there is no byDay 1325 property: Add a byMonth property with the sole value being 1326 the month of the initial date-time. 1328 + If there is no byMonthDay, byWeekNo or byDay properties: 1329 Add a byMonthDay property with the sole value being the 1330 day-of-the-month of the initial date-time. 1332 + If there is a byWeekNo property and no byMonthDay or byDay 1333 properties: Add a byDay property with the sole value being 1334 the day-of-the-week of the initial date-time. 1336 4.3.3. recurrenceOverrides 1338 Type: "LocalDateTime[PatchObject]" (optional). 1340 A map of the recurrence ids (the date-time produced by the recurrence 1341 rule) to an object of patches to apply to the generated occurrence 1342 object. 1344 If the recurrence id does not match a date-time from the recurrence 1345 rule (or no rule is specified), it is to be treated as an additional 1346 occurrence (like an RDATE from iCalendar). The patch object may 1347 often be empty in this case. 1349 If the patch object defines the "excluded" property value to be true, 1350 then the recurring calendar object does not occur at the recurrence 1351 id date-time (like an EXDATE from iCalendar). Such a patch object 1352 MUST NOT patch any other property. 1354 By default, an occurrence inherits all properties from the main 1355 object except the start (or due) date-time, which is shifted to match 1356 the recurrence id LocalDateTime. However, individual properties of 1357 the occurrence can be modified by a patch, or multiple patches. It 1358 is valid to patch the "start" property value, and this patch takes 1359 precedence over the value generated from the recurrence id. Both the 1360 recurrence id as well as the patched "start" date-time may occur 1361 before the original JSCalendar object's "start" or "due" date. 1363 A pointer in the PatchObject MUST be ignored if it starts with one of 1364 the following prefixes: 1366 o @type 1368 o method 1370 o privacy 1372 o prodId 1374 o recurrenceId 1376 o recurrenceOverrides 1378 o recurrenceRules 1380 o relatedTo 1382 o replyTo 1384 o uid 1386 4.3.4. excluded 1388 Type: "Boolean" (optional, default: false). 1390 Defines if this object is an overridden, excluded instance of a 1391 recurring JSCalendar object (see Section 4.3.3). If this property 1392 value is true, this calendar object instance MUST be removed from the 1393 occurrence expansion. The absence of this property or its default 1394 value false indicates that this instance MUST be included in the 1395 occurrence expansion. 1397 4.4. Sharing and Scheduling Properties 1399 4.4.1. priority 1401 Type: "Int" (optional, default: 0). 1403 Specifies a priority for the calendar object. This may be used as 1404 part of scheduling systems to help resolve conflicts for a time 1405 period. 1407 The priority is specified as an integer in the range 0 to 9. A value 1408 of 0 specifies an undefined priority, for which the treatment will 1409 vary by situation. A value of 1 is the highest priority. A value of 1410 2 is the second highest priority. Subsequent numbers specify a 1411 decreasing ordinal priority. A value of 9 is the lowest priority. 1412 Other integer values are reserved for future use. 1414 4.4.2. freeBusyStatus 1416 Type: "String" (optional, default: "busy"). 1418 Specifies how this calendar object should be treated when calculating 1419 free-busy state. This MUST be one of the following values, a value 1420 registered in the IANA JSCalendar Enum Registry, or a vendor-specific 1421 value: 1423 o "free": The object should be ignored when calculating whether the 1424 user is busy. 1426 o "busy": The object should be included when calculating whether the 1427 user is busy. 1429 4.4.3. privacy 1431 Type: "String" (optional, default: "public"). 1433 Calendar objects are normally collected together and may be shared 1434 with other users. The privacy property allows the object owner to 1435 indicate that it should not be shared, or should only have the time 1436 information shared but the details withheld. Enforcement of the 1437 restrictions indicated by this property are up to the API via which 1438 this object is accessed. 1440 This property MUST NOT affect the information sent to scheduled 1441 participants; it is only interpreted when the object is shared as 1442 part of a shared calendar. 1444 The value MUST be one of the following values, a value registered in 1445 the IANA JSCalendar Enum Registry, or a vendor-specific value. Any 1446 value the client or server doesn't understand should be preserved but 1447 treated as equivalent to "private". 1449 o "public": The full details of the object are visible to those whom 1450 the object's calendar is shared with. 1452 o "private": The details of the object are hidden; only the basic 1453 time and metadata is shared. The following properties MAY be 1454 shared, any other properties MUST NOT be shared: 1456 * @type 1458 * created 1460 * due 1462 * duration 1464 * estimatedDuration 1466 * freeBusyStatus 1468 * privacy 1470 * recurrenceOverrides. Only patches which apply to another 1471 permissible property are allowed to be shared. 1473 * sequence 1475 * showWithoutTime 1477 * start 1479 * timeZone 1480 * timeZones 1482 * uid 1484 * updated 1486 o "secret": The object is hidden completely (as though it did not 1487 exist) when the calendar this object is in is shared. 1489 4.4.4. replyTo 1491 Type: "String[String]" (optional). 1493 Represents methods by which participants may submit their RSVP 1494 response to the organizer of the calendar object. The keys in the 1495 property value are the available methods and MUST only contain ASCII 1496 alphanumeric characters (A-Za-z0-9). The value is a URI for the 1497 method specified in the key. Future methods may be defined in future 1498 specifications and registered with IANA; a calendar client MUST 1499 ignore any method it does not understand, but MUST preserve the 1500 method key and URI. This property MUST be omitted if no method is 1501 defined (rather than being specified as an empty object). If this 1502 property is set, the "participants" property of this calendar object 1503 MUST contain at least one participant. 1505 The following methods are defined: 1507 o "imip": The organizer accepts an iMIP [RFC6047] response at this 1508 email address. The value MUST be a "mailto:" URI. 1510 o "web": Opening this URI in a web browser will provide the user 1511 with a page where they can submit a reply to the organizer. 1513 o "other": The organizer is identified by this URI but the method 1514 for submitting the response is undefined. 1516 4.4.5. participants 1518 Type: "Id[Participant]" (optional). 1520 A map of participant ids to participants, describing their 1521 participation in the calendar object. 1523 If this property is set, then the "replyTo" property of this calendar 1524 object MUST define at least one reply method. 1526 A Participant object has the following properties: 1528 o @type: "String" (mandatory) 1530 Specifies the type of this object. This MUST be "Participant". 1532 o name: "String" (optional) 1534 The display name of the participant (e.g., "Joe Bloggs"). 1536 o email: "String" (optional) 1538 The email address for the participant. 1540 o description: "String" (optional). 1542 A plain text description of this participant. For example, this 1543 may include more information about their role in the event or how 1544 best to contact them. 1546 o sendTo: "String[String]" (optional) 1548 Represents methods by which the participant may receive the 1549 invitation and updates to the calendar object. 1551 The keys in the property value are the available methods and MUST 1552 only contain ASCII alphanumeric characters (A-Za-z0-9). The value 1553 is a URI for the method specified in the key. Future methods may 1554 be defined in future specifications and registered with IANA; a 1555 calendar client MUST ignore any method it does not understand, but 1556 MUST preserve the method key and URI. This property MUST be 1557 omitted if no method is defined (rather than being specified as an 1558 empty object). 1560 The following methods are defined: 1562 * "imip": The participant accepts an iMIP [RFC6047] request at 1563 this email address. The value MUST be a "mailto:" URI. It MAY 1564 be different from the value of the participant's "email" 1565 property. 1567 * "other": The participant is identified by this URI but the 1568 method for submitting the invitation is undefined. 1570 o kind: "String" (optional) 1572 What kind of entity this participant is, if known. 1574 This MUST be one of the following values, a value registered in 1575 the IANA JSCalendar Enum Registry, or a vendor-specific value. 1577 Any value the client or server doesn't understand should be 1578 treated the same as if this property is omitted. 1580 * "individual": a single person 1582 * "group": a collection of people invited as a whole 1584 * "location": a physical location that needs to be scheduled, 1585 e.g., a conference room 1587 * "resource": a non-human resource other than a location, such as 1588 a projector 1590 o roles: "String[Boolean]" (mandatory) 1592 A set of roles that this participant fulfills. 1594 At least one role MUST be specified for the participant. The keys 1595 in the set MUST be one of the following values, a value registered 1596 in the IANA JSCalendar Enum Registry, or a vendor-specific value: 1598 * "owner": The participant is an owner of the object. This 1599 signifies they have permission to make changes to it that 1600 affect the other participants. Non-owner participants may only 1601 change properties that just affect themself (for example 1602 setting their own alerts or changing their rsvp status). 1604 * "attendee": The participant is expected to attend. 1606 * "optional": The participant is invited but not required. 1608 * "informational": The participant is copied for informational 1609 reasons, and is not expected to attend. 1611 * "chair": The participant is in charge of the event/task when it 1612 occurs. 1614 * "contact": The participant is someone that may be contacted for 1615 information about the event. 1617 The value for each key in the set MUST be true. It is expected 1618 that no more than one of the roles "attendee", "optional", or 1619 "informational" be present; if more than one are given, "optional" 1620 takes precedence over "informational", and "attendee" takes 1621 precedence over both. Roles that are unknown to the 1622 implementation MUST be preserved. 1624 o locationId: "String" (optional) 1625 The location at which this participant is expected to be 1626 attending. 1628 If the value does not correspond to any location id in the 1629 "locations" property of the JSCalendar object, this MUST be 1630 treated the same as if the participant's locationId were omitted. 1632 o language: "String" (optional) 1634 The language tag as defined in [RFC5646] that best describes the 1635 participant's preferred language, if known. 1637 o participationStatus: "String" (optional, default: "needs-action") 1639 The participation status, if any, of this participant. 1641 The value MUST be one of the following values, a value registered 1642 in the IANA JSCalendar Enum Registry, or a vendor-specific value: 1644 * "needs-action": No status yet set by the participant. 1646 * "accepted": The invited participant will participate. 1648 * "declined": The invited participant will not participate. 1650 * "tentative": The invited participant may participate. 1652 * "delegated": The invited participant has delegated their 1653 attendance to another participant, as specified in the 1654 delegatedTo property. 1656 o participationComment: "String" (optional) 1658 A note from the participant to explain their participation status. 1660 o expectReply: "Boolean" (optional, default: false) 1662 If true, the organizer is expecting the participant to notify them 1663 of their participation status. 1665 o scheduleAgent: "String" (optional, default: "server") 1667 Who is responsible for sending scheduling messages with this 1668 calendar object to the participant. 1670 The value MUST be one of the following values, a value registered 1671 in the IANA JSCalendar Enum Registry, or a vendor-specific value: 1673 * "server": The calendar server will send the scheduling 1674 messages. 1676 * "client": The calendar client will send the scheduling 1677 messages. 1679 * "none": No scheduling messages are to be sent to this 1680 participant. 1682 o scheduleSequence: "UnsignedInt" (optional, default: 0) 1684 The sequence number of the last response from the participant. If 1685 defined, this MUST be a non-negative integer. 1687 This can be used to determine whether the participant has sent a 1688 new RSVP following significant changes to the calendar object, and 1689 to determine if future responses are responding to a current or 1690 older view of the data. 1692 o scheduleUpdated: "UTCDateTime" (optional) 1694 The timestamp for the most recent response from this participant. 1696 This is the "updated" property of the last response when using 1697 iTIP. It can be compared to the "updated" property in future 1698 responses to detect and discard older responses delivered out of 1699 order. 1701 o invitedBy: "String" (optional) 1703 The participant id of the participant who invited this one, if 1704 known. 1706 o delegatedTo: "String[Boolean]" (optional) 1708 A set of participant ids that this participant has delegated their 1709 participation to. Each key in the set MUST be the id of a 1710 participant. The value for each key in the set MUST be true. If 1711 there are no delegates, this MUST be omitted (rather than 1712 specified as an empty set). 1714 o delegatedFrom: "String[Boolean]" (optional) 1716 A set of participant ids that this participant is acting as a 1717 delegate for. Each key in the set MUST be the id of a 1718 participant. The value for each key in the set MUST be true. If 1719 there are no delegators, this MUST be omitted (rather than 1720 specified as an empty set). 1722 o memberOf: "String[Boolean]" (optional) 1724 A set of group participants that were invited to this calendar 1725 object, which caused this participant to be invited due to their 1726 membership in the group(s). Each key in the set MUST be the id of 1727 a participant. The value for each key in the set MUST be true. 1728 If there are no groups, this MUST be omitted (rather than 1729 specified as an empty set). 1731 o linkIds: "String[Boolean]" (optional) 1733 A set of links to more information about this participant, for 1734 example in vCard format. The keys in the set MUST be the id of a 1735 Link object in the calendar object's "links" property. The value 1736 for each key in the set MUST be true. If there are no links, this 1737 MUST be omitted (rather than specified as an empty set). 1739 o progress: "String" (optional; only allowed for participants of a 1740 JSTask). Represents the progress of the participant for this 1741 task. It MUST NOT be set if the "participationStatus" of this 1742 participant is any value other than "accepted". See Section 5.2.4 1743 for allowed values and semantics. 1745 o progressUpdated: "UTCDateTime" (optional; only allowed for 1746 participants of a JSTask). Specifies the date-time the progress 1747 property was last set on this participant. See Section 5.2.5 for 1748 allowed values and semantics. 1750 o percentComplete: "Number" (optional; only allowed for participants 1751 of a JSTask). Represents the percent completion of the 1752 participant for this task. The property value MUST be a positive 1753 integer between 0 and 100. 1755 4.5. Alerts Properties 1757 4.5.1. useDefaultAlerts 1759 Type: "Boolean" (optional, default: false). 1761 If true, use the user's default alerts and ignore the value of the 1762 "alerts" property. Fetching user defaults is dependent on the API 1763 from which this JSCalendar object is being fetched, and is not 1764 defined in this specification. If an implementation cannot determine 1765 the user's default alerts, or none are set, it MUST process the 1766 alerts property as if "useDefaultAlerts" is set to false. 1768 4.5.2. alerts 1770 Type: "Id[Alert]" (optional). 1772 A map of alert ids to Alert objects, representing alerts/reminders to 1773 display or send to the user for this calendar object. 1775 An Alert Object has the following properties: 1777 o @type: "String" (mandatory) 1779 Specifies the type of this object. This MUST be "Alert". 1781 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" 1782 (mandatory) 1784 Defines when to trigger the alert. New types may be defined in 1785 future documents. 1787 An "OffsetTrigger" object has the following properties: 1789 * @type: "String" (mandatory) 1791 Specifies the type of this object. This MUST be 1792 "OffsetTrigger". 1794 * offset: "SignedDuration" (mandatory). 1796 Defines the offset at which to trigger the alert relative to 1797 the time property defined in the "relativeTo" property of the 1798 alert. Negative durations signify alerts before the time 1799 property, positive durations signify alerts after. If the 1800 calendar object does not define a time zone, the user's default 1801 time zone SHOULD be used when determining the offset, if known. 1802 Otherwise, the time zone to use is implementation specific. 1804 * relativeTo: "String" (optional, default: "start") 1806 Specifies the time property that the alert offset is relative 1807 to. The value MUST be one of: 1809 + "start": triggers the alert relative to the start of the 1810 calendar object 1812 + "end": triggers the alert relative to the end/due time of 1813 the calendar object 1815 An "AbsoluteTrigger" object has the following properties: 1817 * @type: "String" (mandatory) 1819 Specifies the type of this object. This MUST be 1820 "AbsoluteTrigger". 1822 * when: "UTCDateTime" (mandatory). 1824 Defines a specific UTC date-time when the alert is triggered. 1826 An "UnknownTrigger" object is an object that contains a "@type" 1827 property whose value is not recognized (i.e., not "OffsetTrigger" 1828 or "AbsoluteTrigger"), plus zero or more other properties. This 1829 is for compatibility with client extensions and future 1830 specifications. Implementations SHOULD NOT trigger for trigger 1831 types they do not understand, but MUST preserve them. 1833 o acknowledged: "UTCDateTime" (optional) 1835 This records when an alert was last acknowledged. This is set 1836 when the user has dismissed the alert; other clients that sync 1837 this property SHOULD automatically dismiss or suppress duplicate 1838 alerts (alerts with the same alert id that triggered on or before 1839 this date-time). 1841 For a recurring calendar object, the "acknowledged" property of 1842 the parent object MUST be updated, unless the alert is already 1843 overridden in the "recurrenceOverrides" property. 1845 Certain kinds of alert action may not provide feedback as to when 1846 the user sees them, for example email based alerts. For those 1847 kinds of alerts, this property SHOULD be set immediately when the 1848 alert is triggered and the action successfully carried out. 1850 o relatedTo: "String[Relation]" (optional) 1852 Relates this alert to other alerts in the same JSCalendar object. 1853 If the user wishes to snooze an alert, the application SHOULD 1854 create an alert to trigger after snoozing. All snooze alerts 1855 SHOULD set a relation to the identifier of the original alert. 1856 The Relation object SHOULD set the "parent" relation type. 1858 o action: "String" (optional, default: "display") 1860 Describes how to alert the user. 1862 The value MUST be at most one of the following values, a value 1863 registered in the IANA JSCalendar Enum Registry, or a vendor- 1864 specific value: 1866 * "display": The alert should be displayed as appropriate for the 1867 current device and user context. 1869 * "email": The alert should trigger an email sent out to the 1870 user, notifying about the alert. This action is typically only 1871 appropriate for server implementations. 1873 4.6. Multilingual Properties 1875 4.6.1. localizations 1877 Type: "String[PatchObject]" (optional). 1879 A map of language tags [RFC5646] to patch objects, which localize the 1880 calendar object into the locale of the respective language tag. 1882 See the description of PatchObject (Section 1.4.8) for the structure 1883 of the PatchObject. The patches are applied to the top-level 1884 calendar object. In addition, the "locale" property of the patched 1885 object is set to the language tag. All pointers for patches MUST end 1886 with one of the following suffixes; any patch that does not follow 1887 this MUST be ignored unless otherwise specified in a future RFC: 1889 o title 1891 o description 1893 o name 1895 A patch MUST NOT have the prefix "recurrenceOverrides"; any 1896 localization of the override MUST be a patch to the localizations 1897 property inside the override instead. For example, a patch to 1898 "locations/abcd1234/title" is permissible, but a patch to "uid" or 1899 "recurrenceOverrides/2018-01-05T14:00:00/title" is not. 1901 Note that this specification does not define how to maintain validity 1902 of localized content. For example, a client application changing a 1903 JSCalendar object's title property might also need to update any 1904 localizations of this property. Client implementations SHOULD 1905 provide the means to manage localizations, but how to achieve this is 1906 specific to the application's workflow and requirements. 1908 4.7. Time Zone Properties 1909 4.7.1. timeZone 1911 Type: "String|null" (optional, default: null). 1913 Identifies the time zone the object is scheduled in, or null for 1914 floating time. This is either a name from the IANA Time Zone 1915 Database [TZDB] or the id of a custom time zone from the "timeZones" 1916 property (see Section 1.4.9). If omitted, this MUST be presumed to 1917 be null (i.e., floating time). 1919 4.7.2. timeZones 1921 Type: "String[TimeZone]" (optional). 1923 Maps identifiers of custom time zones to their time zone definitions. 1924 The following restrictions apply for each key in the map: 1926 o It MUST start with the "/" character (ASCII decimal 47; also see 1927 Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion 1928 of the forward slash character in time zone identifiers). 1930 o It MUST be a valid "paramtext" value as specified in Section 3.1. 1931 of [RFC5545]. 1933 o At least one other property in the same JSCalendar object MUST 1934 reference a time zone using this identifier (i.e., orphaned time 1935 zones are not allowed). 1937 An identifier need only be unique to this JSCalendar object. A 1938 JSCalendar object may be part in a hierarchy of other JSCalendar 1939 objects (say, a JSEvent is an entry in a JSGroup). In this case, the 1940 set of time zones is the sum of the time zone definitions of this 1941 object and its parent objects. If multiple time zones with the same 1942 identifier exist, then the definition closest to the calendar object 1943 in relation to its parents MUST be used. (In context of JSEvent, a 1944 time zone definition in its timeZones property has precedence over a 1945 definition of the same id in the JSGroup). Time zone definitions in 1946 any children of the calendar object MUST be ignored. 1948 A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545] 1949 and the semantics are as defined there. A valid time zone MUST 1950 define at least one transition rule in the "standard" or "daylight" 1951 property. Its properties are: 1953 o @type: "String" (mandatory) 1955 Specifies the type of this object. This MUST be "TimeZone". 1957 o tzId: "String" (mandatory). 1959 The TZID property from iCalendar. 1961 o lastModified: "UTCDateTime" (optional) 1963 The LAST-MODIFIED property from iCalendar. 1965 o url: "String" (optional) 1967 The TZURL property from iCalendar. 1969 o validUntil: "UTCDateTime" (optional) 1971 The TZUNTIL property from iCalendar specified in [RFC7808]. 1973 o aliases: "String[Boolean]" (optional) 1975 Maps the TZID-ALIAS-OF properties from iCalendar specified in 1976 [RFC7808] to a JSON set of aliases. The set is represented as an 1977 object, with the keys being the aliases. The value for each key 1978 in the set MUST be true. 1980 o standard: "TimeZoneRule[]" (optional) 1982 The STANDARD sub-components from iCalendar. The order MUST be 1983 preserved during conversion. 1985 o daylight: "TimeZoneRule[]" (optional). 1987 The DAYLIGHT sub-components from iCalendar. The order MUST be 1988 preserved during conversion. 1990 A TimeZoneRule object maps a STANDARD or DAYLIGHT sub-component from 1991 iCalendar, with the restriction that at most one recurrence rule is 1992 allowed per rule. It has the following properties: 1994 o @type: "String" (mandatory) 1996 Specifies the type of this object. This MUST be "TimeZoneRule". 1998 o start: "LocalDateTime" (mandatory) 2000 The DTSTART property from iCalendar. 2002 o offsetTo: "String" (mandatory) 2004 The TZOFFSETTO property from iCalendar. 2006 o offsetFrom: "String" (mandatory) 2008 The TZOFFSETFROM property from iCalendar. 2010 o recurrenceRule: "RecurrenceRule" (optional) 2012 The RRULE property mapped as specified in Section 4.3.2. During 2013 recurrence rule evaluation, the "until" property value MUST be 2014 interpreted as a local time in the UTC time zone. 2016 o recurrenceDates: "LocalDateTime[Boolean]" (optional) 2018 Maps the RDATE properties from iCalendar to a JSON set. The set 2019 is represented as an object, with the keys being the recurrence 2020 dates. The value for each key in the set MUST be true. 2022 o names: "String[Boolean]" (optional) 2024 Maps the TZNAME properties from iCalendar to a JSON set. The set 2025 is represented as an object, with the keys being the names. The 2026 value for each key in the set MUST be true. 2028 o comments: "String[]" (optional). Maps the COMMENT properties from 2029 iCalendar. The order MUST be preserved during conversion. 2031 5. Type-specific JSCalendar Properties 2033 5.1. JSEvent Properties 2035 In addition to the common JSCalendar object properties (Section 4) a 2036 JSEvent has the following properties: 2038 5.1.1. start 2040 Type: "LocalDateTime" (mandatory). 2042 The date/time the event starts in the event's time zone (as specified 2043 in the "timeZone" property, see Section 4.7.1). 2045 5.1.2. duration 2047 Type: "Duration" (optional, default: "PT0S"). 2049 The zero or positive duration of the event in the event's start time 2050 zone. 2052 Note that a duration specified using weeks or days does not always 2053 correspond to an exact multiple of 24 hours. The number of 2054 hours/minutes/seconds may vary if it overlaps a period of 2055 discontinuity in the event's time zone, for example a change from 2056 standard time to daylight-savings time. Leap seconds MUST NOT be 2057 considered when computing an exact duration. When computing an exact 2058 duration, the greatest order time components MUST be added first, 2059 that is, the number of days MUST be added first, followed by the 2060 number of hours, number of minutes, and number of seconds. 2061 Fractional seconds MUST be added last. These semantics match the 2062 iCalendar DURATION value type ([RFC5545], Section 3.3.6). 2064 A JSEvent MAY involve start and end locations that are in different 2065 time zones (e.g., a trans-continental flight). This can be expressed 2066 using the "relativeTo" and "timeZone" properties of the JSEvent's 2067 Location objects (see Section 4.2.5). 2069 5.1.3. status 2071 Type: "String" (optional, default: "confirmed"). 2073 The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be 2074 one of the following values, a value registered in the IANA 2075 JSCalendar Enum Registry, or a vendor-specific value: 2077 o "confirmed": Indicates the event is definitely happening. 2079 o "cancelled": Indicates the event has been cancelled. 2081 o "tentative": Indicates the event may happen. 2083 5.2. JSTask Properties 2085 In addition to the common JSCalendar object properties (Section 4) a 2086 JSTask has the following properties: 2088 5.2.1. due 2090 Type: "LocalDateTime" (optional). 2092 The date/time the task is due in the task's time zone. 2094 5.2.2. start 2096 Type: "LocalDateTime" (optional). 2098 The date/time the task should start in the task's time zone. 2100 5.2.3. estimatedDuration 2102 Type: "Duration" (optional). 2104 Specifies the estimated positive duration of time the task takes to 2105 complete. 2107 5.2.4. progress 2109 Type: "String" (optional). 2111 Defines the progress of this task. If omitted, the default progress 2112 (Section 4.4) of a JSTask is defined as follows (in order of 2113 evaluation): 2115 o "completed": if the "progress" property value of all participants 2116 is "completed". 2118 o "failed": if at least one "progress" property value of a 2119 participant is "failed". 2121 o "in-process": if at least one "progress" property value of a 2122 participant is "in-process". 2124 o "needs-action": If none of the other criteria match. 2126 If set, it MUST be one of the following values, a value registered in 2127 the IANA JSCalendar Enum Registry, or a vendor-specific value: 2129 o "needs-action": Indicates the task needs action. 2131 o "in-process": Indicates the task is in process. 2133 o "completed": Indicates the task is completed. 2135 o "failed": Indicates the task failed. 2137 o "cancelled": Indicates the task was cancelled. 2139 5.2.5. progressUpdated 2141 Type: "UTCDateTime" (optional). 2143 Specifies the date/time the "progress" property of either the task 2144 overall (Section 5.2.4) or a specific participant (Section 4.4.5) was 2145 last updated. 2147 If the task is recurring and has future instances, a client may want 2148 to keep track of the last progress update timestamp of a specific 2149 task recurrence, but leave other instances unchanged. One way to 2150 achieve this is by overriding the progressUpdated property in the 2151 task "recurrenceOverrides" property. However, this could produce a 2152 long list of timestamps for regularly recurring tasks. An 2153 alternative approach is to split the JSTask into a current, single 2154 instance of JSTask with this instance progress update time and a 2155 future recurring instance. See also Section 4.1.3 on splitting. 2157 5.3. JSGroup Properties 2159 JSGroup supports the following common JSCalendar properties 2160 (Section 4): 2162 o @type 2164 o categories 2166 o color 2168 o created 2170 o description 2172 o descriptionContentType 2174 o keywords 2176 o links 2178 o locale 2180 o prodId 2182 o timeZones 2184 o title 2186 o updated 2188 o uid 2190 In addition, the following JSGroup-specific properties are supported: 2192 5.3.1. entries 2194 Type: "(JSTask|JSEvent)[]" (mandatory). 2196 A collection of group members. Implementations MUST ignore entries 2197 of unknown type. 2199 5.3.2. source 2201 Type: "String" (optional). 2203 The source from which updated versions of this group may be retrieved 2204 from. The value MUST be a URI. 2206 6. Examples 2208 The following examples illustrate several aspects of the JSCalendar 2209 data model and format. The examples may omit mandatory or additional 2210 properties, which is indicated by a placeholder property with key 2211 "...". While most of the examples use calendar event objects, they 2212 are also illustrative for tasks. 2214 6.1. Simple event 2216 This example illustrates a simple one-time event. It specifies a 2217 one-time event that begins on January 15, 2018 at 1pm New York local 2218 time and ends after 1 hour. 2220 { 2221 "@type": "jsevent", 2222 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2223 "updated": "2018-01-15T18:00:00Z", 2224 "title": "Some event", 2225 "start": "2018-01-15T13:00:00", 2226 "timeZone": "America/New_York", 2227 "duration": "PT1H" 2228 } 2230 6.2. Simple task 2232 This example illustrates a simple task for a plain to-do item. 2234 { 2235 "@type": "jstask", 2236 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2237 "updated": "2018-01-15T18:00:00Z", 2238 "title": "Do something" 2239 } 2241 6.3. Simple group 2243 This example illustrates a simple calendar object group that contains 2244 an event and a task. 2246 { 2247 "@type": "jsgroup", 2248 "uid": "2a358cee-6489-4f14-a57f-c104db4dc343", 2249 "updated": "2018-01-15T18:00:00Z", 2250 "name": "A simple group", 2251 "entries": [{ 2252 "@type": "jsevent", 2253 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2254 "updated": "2018-01-15T18:00:00Z", 2255 "title": "Some event", 2256 "start": "2018-01-15T13:00:00", 2257 "timeZone": "America/New_York", 2258 "duration": "PT1H" 2259 }, 2260 "2a358cee-6489-4f14-a57f-c104db4dc2f2": { 2261 "@type": "jstask", 2262 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2263 "updated": "2018-01-15T18:00:00Z", 2264 "title": "Do something" 2265 }] 2266 } 2268 6.4. All-day event 2270 This example illustrates an event for an international holiday. It 2271 specifies an all-day event on April 1 that occurs every year since 2272 the year 1900. 2274 { 2275 "...": "", 2276 "title": "April Fool's Day", 2277 "showWithoutTime": true, 2278 "start": "1900-04-01T00:00:00", 2279 "duration": "P1D", 2280 "recurrenceRules": [{ 2281 "@type": "RecurrenceRule", 2282 "frequency": "yearly" 2283 }] 2284 } 2286 6.5. Task with a due date 2288 This example illustrates a task with a due date. It is a reminder to 2289 buy groceries before 6pm Vienna local time on January 19, 2018. The 2290 calendar user expects to need 1 hour for shopping. 2292 { 2293 "...": "", 2294 "title": "Buy groceries", 2295 "due": "2018-01-19T18:00:00", 2296 "timeZone": "Europe/Vienna", 2297 "estimatedDuration": "PT1H" 2298 } 2300 6.6. Event with end time-zone 2302 This example illustrates the use of end time-zones by use of an 2303 international flight. The flight starts on April 1, 2018 at 9am in 2304 Berlin local time. The duration of the flight is scheduled at 10 2305 hours 30 minutes. The time at the flights destination is in the same 2306 time-zone as Tokyo. Calendar clients could use the end time-zone to 2307 display the arrival time in Tokyo local time and highlight the time- 2308 zone difference of the flight. The location names can serve as input 2309 for navigation systems. 2311 { 2312 "...": "", 2313 "title": "Flight XY51 to Tokyo", 2314 "start": "2018-04-01T09:00:00", 2315 "timeZone": "Europe/Berlin", 2316 "duration": "PT10H30M", 2317 "locations": { 2318 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2319 "@type": "Location", 2320 "rel": "start", 2321 "name": "Frankfurt Airport (FRA)" 2322 }, 2323 "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { 2324 "@type": "Location", 2325 "rel": "end", 2326 "name": "Narita International Airport (NRT)", 2327 "timeZone": "Asia/Tokyo" 2328 } 2329 } 2330 } 2332 6.7. Floating-time event (with recurrence) 2334 This example illustrates the use of floating-time. Since January 1, 2335 2018, a calendar user blocks 30 minutes every day to practice Yoga at 2336 7am local time, in whatever time-zone the user is located on that 2337 date. 2339 { 2340 "...": "", 2341 "title": "Yoga", 2342 "start": "2018-01-01T07:00:00", 2343 "duration": "PT30M", 2344 "recurrenceRules": [{ 2345 "@type": "RecurrenceRule", 2346 "frequency": "daily" 2347 }] 2348 } 2350 6.8. Event with multiple locations and localization 2352 This example illustrates an event that happens at both a physical and 2353 a virtual location. Fans can see a live concert on premises or 2354 online. The event title and descriptions are localized. 2356 { 2357 "...": "", 2358 "title": "Live from Music Bowl: The Band", 2359 "description": "Go see the biggest music event ever!", 2360 "locale": "en", 2361 "start": "2018-07-04T17:00:00", 2362 "timeZone": "America/New_York", 2363 "duration": "PT3H", 2364 "locations": { 2365 "c0503d30-8c50-4372-87b5-7657e8e0fedd": { 2366 "@type": "Location", 2367 "name": "The Music Bowl", 2368 "description": "Music Bowl, Central Park, New York", 2369 "coordinates": "geo:40.7829,-73.9654" 2370 } 2371 }, 2372 "virtualLocations": { 2373 "6f3696c6-1e07-47d0-9ce1-f50014b0041a": { 2374 "@type": "VirtualLocation", 2375 "name": "Free live Stream from Music Bowl", 2376 "uri": "https://stream.example.com/the_band_2018" 2377 } 2378 }, 2379 "localizations": { 2380 "de": { 2381 "title": "Live von der Music Bowl: The Band!", 2382 "description": "Schau dir das groesste Musikereignis an!", 2383 "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name": 2384 "Gratis Live-Stream aus der Music Bowl" 2385 } 2386 } 2387 } 2389 6.9. Recurring event with overrides 2391 This example illustrates the use of recurrence overrides. A math 2392 course at a University is held for the first time on January 8, 2018 2393 at 9am London time and occurs every week until June 25, 2018. Each 2394 lecture lasts for one hour and 30 minutes and is located at the 2395 Mathematics department. This event has exceptional occurrences: at 2396 the last occurrence of the course is an exam, which lasts for 2 hours 2397 and starts at 10am. Also, the location of the exam differs from the 2398 usual location. On April 2 no course is held. On January 5 at 2pm 2399 is an optional introduction course, that occurs before the first 2400 regular lecture. 2402 { 2403 "...": "", 2404 "title": "Calculus I", 2405 "start": "2018-01-08T09:00:00", 2406 "timeZone": "Europe/London", 2407 "duration": "PT1H30M", 2408 "locations": { 2409 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2410 "@type": "Location", 2411 "title": "Math lab room 1", 2412 "description": "Math Lab I, Department of Mathematics" 2413 } 2414 }, 2415 "recurrenceRules": [{ 2416 "@type": "RecurrenceRule", 2417 "frequency": "weekly", 2418 "until": "2018-06-25T09:00:00" 2419 }], 2420 "recurrenceOverrides": { 2421 "2018-01-05T14:00:00": { 2422 "title": "Introduction to Calculus I (optional)" 2423 }, 2424 "2018-04-02T09:00:00": { 2425 "excluded": "true" 2426 }, 2427 "2018-06-25T09:00:00": { 2428 "title": "Calculus I Exam", 2429 "start": "2018-06-25T10:00:00", 2430 "duration": "PT2H", 2431 "locations": { 2432 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2433 "@type": "Location", 2434 "title": "Big Auditorium", 2435 "description": "Big Auditorium, Other Road" 2436 } 2437 } 2438 } 2439 } 2440 } 2442 6.10. Recurring event with participants 2444 This example illustrates scheduled events. A team meeting occurs 2445 every week since January 8, 2018 at 9am Johannesburg time. The event 2446 owner also chairs the event. Participants meet in a virtual meeting 2447 room. An attendee has accepted the invitation, but on March 8, 2018 2448 he is unavailable and declined participation for this occurrence. 2450 { 2451 "...": "", 2452 "title": "FooBar team meeting", 2453 "start": "2018-01-08T09:00:00", 2454 "timeZone": "Africa/Johannesburg", 2455 "duration": "PT1H", 2456 "virtualLocations": { 2457 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2458 "@type": "VirtualLocation", 2459 "name": "ChatMe meeting room", 2460 "uri": "https://chatme.example.com?id=1234567" 2461 } 2462 }, 2463 "recurrenceRules": [{ 2464 "@type": "RecurrenceRule", 2465 "frequency": "weekly" 2466 }], 2467 "replyTo": { 2468 "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com" 2469 }, 2470 "participants": { 2471 "dG9tQGZvb2Jhci5xlLmNvbQ": { 2472 "@type": "Participant", 2473 "name": "Tom Tool", 2474 "email": "tom@foobar.example.com", 2475 "sendTo": { 2476 "imip": "mailto:6489-4f14-a57f-c1@calendar.example.com" 2477 }, 2478 "participationStatus": "accepted", 2479 "roles": { 2480 "attendee": true 2481 } 2482 }, 2483 "em9lQGZvb2GFtcGxlLmNvbQ": { 2484 "@type": "Participant", 2485 "name": "Zoe Zelda", 2486 "email": "zoe@foobar.example.com", 2487 "sendTo": { 2488 "imip": "mailto:zoe@foobar.example.com" 2489 }, 2490 "participationStatus": "accepted", 2491 "roles": { 2492 "owner": true, 2493 "attendee": true, 2494 "chair": true 2495 } 2496 }, 2497 "...": "" 2499 }, 2500 "recurrenceOverrides": { 2501 "2018-03-08T09:00:00": { 2502 "participants/dG9tQGZvb2Jhci5xlLmNvbQ/participationStatus": 2503 "declined" 2504 } 2505 } 2506 } 2508 7. Security Considerations 2510 Calendaring and scheduling information is very privacy-sensitive. 2511 Its transmission must be done carefully to protect it from possible 2512 threats, such as eavesdropping, replay, message insertion, deletion, 2513 modification, and man-in-the-middle attacks. 2515 The data being stored and transmitted may be used in systems with 2516 real world consequences. For example, a home automation system may 2517 turn an alarm on and off. Or a coworking space may charge money to 2518 the organiser of an event that books one of their meeting rooms. 2519 Such systems must be careful to authenticate all data they receive to 2520 prevent them from being subverted. 2522 This document just defines the data format; such considerations are 2523 primarily the concern of the API or method of storage and 2524 transmission of such files. 2526 7.1. Expanding Recurrences 2528 A recurrence rule may produce infinite occurrences of an event. 2529 Implementations MUST handle expansions carefully to prevent 2530 accidental or deliberate resource exhaustion. 2532 Conversely, a recurrence rule may be specified that does not expand 2533 to anything. It is not always possible to tell this through static 2534 analysis of the rule, so implementations MUST be careful to avoid 2535 getting stuck in infinite loops, or otherwise exhausting resources 2536 while searching for the next occurrence. 2538 7.2. JSON Parsing 2540 The Security Considerations of [RFC8259] apply to the use of JSON as 2541 the data interchange format. 2543 As for any serialization format, parsers need to thoroughly check the 2544 syntax of the supplied data. JSON uses opening and closing tags for 2545 several types and structures, and it is possible that the end of the 2546 supplied data will be reached when scanning for a matching closing 2547 tag; this is an error condition, and implementations need to stop 2548 scanning at the end of the supplied data. 2550 JSON also uses a string encoding with some escape sequences to encode 2551 special characters within a string. Care is needed when processing 2552 these escape sequences to ensure that they are fully formed before 2553 the special processing is triggered, with special care taken when the 2554 escape sequences appear adjacent to other (non-escaped) special 2555 characters or adjacent to the end of data (as in the previous 2556 paragraph). 2558 If parsing JSON into a non-textual structured data format, 2559 implementations may need to allocate storage to hold JSON string 2560 elements. Since JSON does not use explicit string lengths, the risk 2561 of denial of service due to resource exhaustion is small, but 2562 implementations may still wish to place limits on the size of 2563 allocations they are willing to make in any given context, to avoid 2564 untrusted data causing excessive memory allocation. 2566 7.3. URI Values 2568 Several JSCalendar properties contain URIs as values, and processing 2569 these properties requires extra care. Section 7 of [RFC3986] 2570 discusses security risks related to URIs. 2572 A maliciously constructed JSCalendar object may contain a very large 2573 number of URIs. In the case of published calendars with a large 2574 number of subscribers, such objects could be widely distributed. 2575 Implementations should be careful to limit the automatic fetching of 2576 linked resources to reduce the risk of this being an amplification 2577 vector for a denial-of-service attack. 2579 7.4. Spam 2581 Calendar systems may receive JSCalendar files from untrusted sources, 2582 in particular as attachments to emails. This can be a vector for an 2583 attacker to inject spam into a user's calendar. This may confuse, 2584 annoy, and mislead users, or overwhelm their calendar with bogus 2585 events, preventing them from seeing legitimate ones. 2587 Heuristic, statistical or machine-learning-based filters can be 2588 effective in filtering out spam. Authentication mechanisms such as 2589 DKIM [RFC6376] can help establish the source of messages and 2590 associate the data with existing relationships (such as an address 2591 book contact). Misclassifications are always possible however, and 2592 providing a feedback mechanism for users to quickly correct this is 2593 advised. 2595 7.5. Duplication 2597 It is important for calendar systems to maintain the UID of an event 2598 when updating it to avoid unexpected duplication of events. When the 2599 UID changes, consumers of the data may not remove the previous 2600 version of the event if it has a different UID. This can lead to a 2601 confusing situation for the user, with many variations of the event 2602 and no indication of which one is correct. Care must be taken by 2603 consumers of the data to remove old events where possible to avoid an 2604 accidental denial-of-service attack due to the volume of data. 2606 7.6. Time Zones 2608 Events recur in a particular time zone. When this differs from the 2609 user's current time zone, it may unexpectedly cause an occurrence to 2610 shift in time for that user due to a daylight savings change in the 2611 event's time zone. A maliciously crafted event could attempt to 2612 confuse users with such an event to ensure a meeting is missed. 2614 8. IANA Considerations 2616 8.1. Media Type Registration 2618 This document defines a media type for use with JSCalendar data 2619 formatted in JSON. 2621 Type name: application 2623 Subtype name: jscalendar+json 2625 Required parameters: type 2627 The "type" parameter conveys the type of the JSCalendar data in 2628 the body part, with the value being one of "jsevent", "jstask", or 2629 "jsgroup". The parameter MUST NOT occur more than once. It MUST 2630 match the value of the "@type" property of the JSON-formatted 2631 JSCalendar object in the body. 2633 Optional parameters: none 2635 Encoding considerations: Same as encoding considerations of 2636 application/json as specified in RFC8529, Section 11 [RFC8259]. 2638 Security considerations: See Section 7 of this document. 2640 Interoperability considerations: This media type provides an 2641 alternative to iCalendar, jCal and proprietary JSON-based 2642 calendaring data formats. 2644 Published specification: This specification. 2646 Applications that use this media type: Applications that currently 2647 make use of the text/calendar and application/calendar+json media 2648 types can use this as an alternative. Similarly, applications 2649 that use the application/json media type to transfer calendaring 2650 data can use this to further specify the content. 2652 Fragment identifier considerations: N/A 2654 Additional information: 2656 Magic number(s): N/A 2658 File extensions(s): N/A 2660 Macintosh file type code(s): N/A 2662 Person & email address to contact for further information: 2663 calsify@ietf.org 2665 Intended usage: COMMON 2667 Restrictions on usage: N/A 2669 Author: See the "Author's Address" section of this document. 2671 Change controller: IETF 2673 8.2. Creation of "JSCalendar Properties" Registry 2675 The IANA will create the "JSCalendar Properties" registry to allow 2676 interoperability of extensions to JSCalendar objects. 2678 This registry follows the Expert Review process ([RFC8126], 2679 Section 4.5). If the "intended use" field is "common", sufficient 2680 documentation is required to enable interoperability. Preliminary 2681 community review for this registry is optional but strongly 2682 encouraged. 2684 A registration can have an intended use of "common", "reserved", or 2685 "obsolete". The IANA will list common-use registrations prominently 2686 and separately from those with other intended use values. 2688 A "reserved" registration reserves a property name without assigning 2689 semantics to avoid name collisions with future extensions or protocol 2690 use. 2692 An "obsolete" registration denotes a property that is no longer 2693 expected to be added by up-to-date systems. A new property has 2694 probably been defined covering the obsolete property's semantics. 2696 The JSCalendar property registration procedure is not a formal 2697 standards process but rather an administrative procedure intended to 2698 allow community comment and sanity checking without excessive time 2699 delay. It is designed to encourage vendors to document and register 2700 new properties they add for use cases not covered by the original 2701 standard, leading to increased interoperability. 2703 8.2.1. Preliminary Community Review 2705 Notice of a potential new registration SHOULD be sent to the Calext 2706 mailing list for review. This mailing list is 2707 appropriate to solicit community feedback on a proposed new property. 2709 Properties registrations must be marked with their intended use: 2710 "common", "reserved" or "obsolete". 2712 The intent of the public posting to this list is to solicit comments 2713 and feedback on the choice of the property name, the unambiguity of 2714 the specification document, and a review of any interoperability or 2715 security considerations. The submitter may submit a revised 2716 registration proposal or abandon the registration completely at any 2717 time. 2719 8.2.2. Submit Request to IANA 2721 Registration requests can be sent to . 2723 8.2.3. Designated Expert Review 2725 The primary concern of the designated expert (DE) is preventing name 2726 collisions and encouraging the submitter to document security and 2727 privacy considerations. For a common-use registration, the DE is 2728 expected to confirm that suitable documentation, as described in 2729 Section 4.6 of [RFC8126], is available to ensure interoperability. 2730 That documentation will usually be in an RFC, but simple definitions 2731 are likely to use a web/wiki page, and if a sentence or two is deemed 2732 sufficient it could be described in the registry itself. The DE 2733 should also verify that the property name does not conflict with work 2734 that is active or already published within the IETF. A published 2735 specification is not required for reserved or obsolete registrations. 2737 The DE will either approve or deny the registration request and 2738 publish a notice of the decision to the Calext WG mailing list or its 2739 successor, as well as inform IANA. A denial notice must be justified 2740 by an explanation, and, in the cases where it is possible, concrete 2741 suggestions on how the request can be modified so as to become 2742 acceptable should be provided. 2744 8.2.4. Change Procedures 2746 Once a JSCalendar property has been published by the IANA, the change 2747 controller may request a change to its definition. The same 2748 procedure that would be appropriate for the original registration 2749 request is used to process a change request. 2751 JSCalendar property registrations may not be deleted; properties that 2752 are no longer believed appropriate for use can be declared obsolete 2753 by a change to their "intended use" field; such properties will be 2754 clearly marked in the lists published by the IANA. 2756 Significant changes to a JSCalendar property's definition should be 2757 requested only when there are serious omissions or errors in the 2758 published specification, as such changes may cause interoperability 2759 issues. When review is required, a change request may be denied if 2760 it renders entities that were valid under the previous definition 2761 invalid under the new definition. 2763 The owner of a JSCalendar property may pass responsibility to another 2764 person or agency by informing the IANA; this can be done without 2765 discussion or review. 2767 8.2.5. JSCalendar Properties Registry Template 2769 o Property Name: The name of the property. The property name MUST 2770 NOT already be registered for any of the object types listed in 2771 the "Property Context" field of this registration. Other object 2772 types MAY already have registered a different property with the 2773 same name. 2775 o Property Type: The type of this property, using type signatures as 2776 specified in Section 1.3. The property type MUST be registed in 2777 the Type Registry. 2779 o Property Context: A comma-separated list of JSCalendar object 2780 types this property is allowed on. 2782 o Reference or Description: A brief description or RFC number and 2783 section reference where the property is specified (omitted for 2784 "reserved" property names). 2786 o Intended Use: Common, reserved, or obsolete. 2788 o Change Controller: ("IETF" for IETF-stream RFCs). 2790 8.2.6. Initial Contents for the JSCalendar Properties Registry 2792 The following table lists the initial entries of the JSCalendar 2793 Properties registry. All properties are for common-use. All RFC 2794 section references are for this document. The change controller for 2795 all these properties is "IETF". 2797 +---------------+----------------------------+------------+---------+ 2798 | Property Name | Property Type | Property | Referen | 2799 | | | Context | ce or D | 2800 | | | | escript | 2801 | | | | ion | 2802 +---------------+----------------------------+------------+---------+ 2803 | @type | String | JSEvent, | Section | 2804 | | | JSTask, | 4.1.1, | 2805 | | | JSGroup, A | Section | 2806 | | | bsoluteTri | 4.5.2, | 2807 | | | gger, | Section | 2808 | | | Alert, | 4.2.7, | 2809 | | | Link, | Section | 2810 | | | Location, | 4.2.5, | 2811 | | | OffsetTrig | Section | 2812 | | | ger, Parti | 4.4.5, | 2813 | | | cipant, Re | Section | 2814 | | | currenceRu | 4.3.2, | 2815 | | | le, | Section | 2816 | | | Relation, | 4.1.3, | 2817 | | | TimeZone, | Section | 2818 | | | VirtualLoc | 4.7.2, | 2819 | | | ation | Section | 2820 | | | | 4.2.6 | 2821 | | | | | 2822 | acknowledged | UTCDateTime | Alert | Section | 2823 | | | | 4.5.2 | 2824 | | | | | 2825 | action | String | Alert | Section | 2826 | | | | 4.5.2 | 2827 | | | | | 2828 | alerts | Id[Alert] | JSEvent, | Section | 2829 | | | JSTask | 4.5.2 | 2830 | | | | | 2831 | byDay | NDay[] | Recurrence | Section | 2832 | | | Rule | 4.3.2 | 2833 | | | | | 2834 | byHour | UnsignedInt[] | Recurrence | Section | 2835 | | | Rule | 4.3.2 | 2836 | | | | | 2837 | byMinute | UnsignedInt[] | Recurrence | Section | 2838 | | | Rule | 4.3.2 | 2839 | | | | | 2840 | byMonth | String[] | Recurrence | Section | 2841 | | | Rule | 4.3.2 | 2842 | | | | | 2843 | byMonthDay | Int[] | Recurrence | Section | 2844 | | | Rule | 4.3.2 | 2845 | | | | | 2846 | bySecond | UnsignedInt[] | Recurrence | Section | 2847 | | | Rule | 4.3.2 | 2848 | | | | | 2849 | bySetPosition | Int[] | Recurrence | Section | 2850 | | | Rule | 4.3.2 | 2851 | | | | | 2852 | byWeekNo | Int[] | Recurrence | Section | 2853 | | | Rule | 4.3.2 | 2854 | | | | | 2855 | byYearDay | Int[] | Recurrence | Section | 2856 | | | Rule | 4.3.2 | 2857 | | | | | 2858 | categories | String[Boolean] | JSEvent, | Section | 2859 | | | JSTask, | 4.2.10 | 2860 | | | JSGroup | | 2861 | | | | | 2862 | cid | String | Link | Section | 2863 | | | | 4.2.7 | 2864 | | | | | 2865 | color | String | JSEvent, | Section | 2866 | | | JSTask, | 4.2.11 | 2867 | | | JSGroup | | 2868 | | | | | 2869 | contentType | String | Link | Section | 2870 | | | | 4.2.7 | 2871 | | | | | 2872 | coordinates | String | Location | Section | 2873 | | | | 4.2.5 | 2874 | | | | | 2875 | count | UnsignedInt | Recurrence | Section | 2876 | | | Rule | 4.3.2 | 2877 | | | | | 2878 | created | UTCDateTime | JSEvent, | Section | 2879 | | | JSTask, | 4.1.5 | 2880 | | | JSGroup | | 2881 | | | | | 2882 | delegatedFrom | String[Boolean] | Participan | Section | 2883 | | | t | 4.4.5 | 2884 | | | | | 2885 | delegatedTo | String[Boolean] | Participan | Section | 2886 | | | t | 4.4.5 | 2887 | | | | | 2888 | description | String | JSEvent, | Section | 2889 | | | JSTask, | 4.2.2, | 2890 | | | Location, | Section | 2891 | | | Participan | 4.2.5, | 2892 | | | t, Virtual | Section | 2893 | | | Location | 4.4.5, | 2894 | | | | Section | 2895 | | | | 4.2.6 | 2896 | | | | | 2897 | descriptionCo | String | JSEvent, | Section | 2898 | ntentType | | JSTask | 4.2.3 | 2899 | | | | | 2900 | display | String | Link | Section | 2901 | | | | 4.2.7 | 2902 | | | | | 2903 | due | LocalDateTime | JSTask | Section | 2904 | | | | 5.2.1 | 2905 | | | | | 2906 | duration | Duration | JSEvent | Section | 2907 | | | | 5.1.2 | 2908 | | | | | 2909 | email | String | Participan | Section | 2910 | | | t | 4.4.5 | 2911 | | | | | 2912 | entries | (JSTask|JSEvent)[] | JSGroup | Section | 2913 | | | | 5.3.1 | 2914 | | | | | 2915 | estimatedDura | Duration | JSTask | Section | 2916 | tion | | | 5.2.3 | 2917 | | | | | 2918 | excluded | Boolean | JSEvent, | Section | 2919 | | | JSTask | 4.3.4 | 2920 | | | | | 2921 | expectReply | Boolean | Participan | Section | 2922 | | | t | 4.4.5 | 2923 | | | | | 2924 | firstDayOfWee | String | Recurrence | Section | 2925 | k | | Rule | 4.3.2 | 2926 | | | | | 2927 | freeBusyStatu | String | JSEvent, | Section | 2928 | s | | JSTask | 4.4.2 | 2929 | | | | | 2930 | frequency | String | Recurrence | Section | 2931 | | | Rule | 4.3.2 | 2932 | | | | | 2933 | href | String | Link | Section | 2934 | | | | 4.2.7 | 2935 | | | | | 2936 | interval | UnsignedInt | Recurrence | Section | 2937 | | | Rule | 4.3.2 | 2938 | | | | | 2939 | invitedBy | String | Participan | Section | 2940 | | | t | 4.4.5 | 2941 | | | | | 2942 | keywords | String[Boolean] | JSEvent, | Section | 2943 | | | JSTask, | 4.2.9 | 2944 | | | JSGroup | | 2945 | | | | | 2946 | kind | String | Participan | Section | 2947 | | | t | 4.4.5 | 2948 | | | | | 2949 | language | String | Participan | Section | 2950 | | | t | 4.4.5 | 2951 | | | | | 2952 | linkIds | Id[Boolean] | Location, | Section | 2953 | | | Participan | 4.2.5, | 2954 | | | t | Section | 2955 | | | | 4.4.5 | 2956 | | | | | 2957 | links | Id[Link] | JSGroup, | Section | 2958 | | | JSEvent, | 4.2.7 | 2959 | | | JSTask | | 2960 | | | | | 2961 | locale | String | JSGroup, | Section | 2962 | | | JSEvent, | 4.2.7 | 2963 | | | JSTask | | 2964 | | | | | 2965 | localizations | String[PatchObject] | JSEvent, | Section | 2966 | | | JSTask | 4.6.1 | 2967 | | | | | 2968 | locationId | String | Participan | Section | 2969 | | | t | 4.4.5 | 2970 | | | | | 2971 | locations | Id[Location] | JSEvent, | Section | 2972 | | | JSTask | 4.2.5 | 2973 | | | | | 2974 | locationTypes | String[Boolean] | Location | Section | 2975 | | | | 4.2.5 | 2976 | | | | | 2977 | memberOf | String[Boolean] | Participan | Section | 2978 | | | t | 4.4.5 | 2979 | | | | | 2980 | method | String | JSEvent, | Section | 2981 | | | JSTask | 4.1.8 | 2982 | | | | | 2983 | name | String | Location, | Section | 2984 | | | VirtualLoc | 4.2.5, | 2985 | | | ation, Par | Section | 2986 | | | ticipant | 4.2.6, | 2987 | | | | Section | 2988 | | | | 4.4.5 | 2989 | | | | | 2990 | offset | SignedDuration | OffsetTrig | Section | 2991 | | | ger | 4.5.2 | 2992 | | | | | 2993 | participants | Id[Participant] | JSEvent, | Section | 2994 | | | JSTask | 4.4.5 | 2995 | | | | | 2996 | participation | String | Participan | Section | 2997 | Comment | | t | 4.4.5 | 2998 | | | | | 2999 | participation | String | Participan | Section | 3000 | Status | | t | 4.4.5 | 3001 | | | | | 3002 | priority | Int | JSEvent, | Section | 3003 | | | JSTask | 4.4.1 | 3004 | | | | | 3005 | privacy | String | JSEvent, | Section | 3006 | | | JSTask | 4.4.3 | 3007 | | | | | 3008 | prodId | String | JSEvent, | Section | 3009 | | | JSTask, | 4.1.4 | 3010 | | | JSGroup | | 3011 | | | | | 3012 | progress | String | JSTask, Pa | Section | 3013 | | | rticipant | 5.2.4 | 3014 | | | | | 3015 | progressUpdat | UTCDateTime | JSTask, Pa | Section | 3016 | ed | | rticipant | 5.2.5 | 3017 | | | | | 3018 | recurrenceId | LocalDateTime | JSEvent, | Section | 3019 | | | JSTask | 4.3.1 | 3020 | | | | | 3021 | recurrenceOve | LocalDateTime[PatchObject] | JSEvent, | Section | 3022 | rrides | | JSTask | 4.3.3 | 3023 | | | | | 3024 | recurrenceRul | RecurrenceRule[] | JSEvent, | Section | 3025 | es | | JSTask | 4.3.2 | 3026 | | | | | 3027 | rel | String | Link | Section | 3028 | | | | 4.2.7 | 3029 | | | | | 3030 | relatedTo | String[Relation] | JSEvent, | Section | 3031 | | | JSTask, | 4.1.3, | 3032 | | | Alert | Section | 3033 | | | | 4.5.2 | 3034 | | | | | 3035 | relation | String[Boolean] | Relation | Section | 3036 | | | | 1.4.10 | 3037 | | | | | 3038 | relativeTo | String | OffsetTrig | Section | 3039 | | | ger, | 4.5.2, | 3040 | | | Location | Section | 3041 | | | | 4.2.5 | 3042 | | | | | 3043 | replyTo | String[String] | JSEvent, | Section | 3044 | | | JSTask | 4.4.4 | 3045 | | | | | 3046 | roles | String[Boolean] | Participan | Section | 3047 | | | t | 4.4.5 | 3048 | | | | | 3049 | rscale | String | Recurrence | Section | 3050 | | | Rule | 4.3.2 | 3051 | | | | | 3052 | scheduleAgent | String | Participan | Section | 3053 | | | t | 4.4.5 | 3054 | | | | | 3055 | scheduleSeque | UnsignedInt | Participan | Section | 3056 | nce | | t | 4.4.5 | 3057 | | | | | 3058 | scheduleUpdat | UTCDateTime | Participan | Section | 3059 | ed | | t | 4.4.5 | 3060 | | | | | 3061 | sendTo | String[String] | Participan | Section | 3062 | | | t | 4.4.5 | 3063 | | | | | 3064 | sequence | UnsignedInt | JSEvent, | Section | 3065 | | | JSTask | 4.1.7 | 3066 | | | | | 3067 | showWithoutTi | Boolean | JSEvent, | Section | 3068 | me | | JSTask | 4.2.4 | 3069 | | | | | 3070 | size | UnsignedInt | Link | Section | 3071 | | | | 4.2.7 | 3072 | | | | | 3073 | skip | String | Recurrence | Section | 3074 | | | Rule | 4.3.2 | 3075 | | | | | 3076 | source | String | JSGroup | Section | 3077 | | | | 5.3.2 | 3078 | | | | | 3079 | start | LocalDateTime | JSEvent, | Section | 3080 | | | JSTask | 5.1.1, | 3081 | | | | Section | 3082 | | | | 5.2.2 | 3083 | | | | | 3084 | status | String | JSEvent | Section | 3085 | | | | 5.1.3 | 3086 | | | | | 3087 | timeZone | String|null | JSEvent, | Section | 3088 | | | JSTask, | 4.7.1, | 3089 | | | Location | Section | 3090 | | | | 4.2.5 | 3091 | | | | | 3092 | timeZones | String[TimeZone] | JSEvent, | Section | 3093 | | | JSTask | 4.7.2 | 3094 | | | | | 3095 | title | String | JSEvent, | Section | 3096 | | | JSTask, | 4.2.1 | 3097 | | | JSGroup, | | 3098 | | | Link | | 3099 | | | | | 3100 | trigger | OffsetTrigger|AbsoluteTrig | Alert | Section | 3101 | | ger|UnknownTrigger | | 4.5.2 | 3102 | | | | | 3103 | uid | String | JSEvent, | Section | 3104 | | | JSTask, | 4.1.2 | 3105 | | | JSGroup | | 3106 | | | | | 3107 | until | LocalDateTime | Recurrence | Section | 3108 | | | Rule | 4.3.2 | 3109 | | | | | 3110 | updated | UTCDateTime | JSEvent, | Section | 3111 | | | JSTask, | 4.1.6 | 3112 | | | JSGroup | | 3113 | | | | | 3114 | uri | String | VirtualLoc | Section | 3115 | | | ation | 4.2.6 | 3116 | | | | | 3117 | useDefaultAle | Boolean | JSEvent, | Section | 3118 | rts | | JSTask | 4.5.1 | 3119 | | | | | 3120 | virtualLocati | Id[VirtualLocation] | JSEvent, | Section | 3121 | ons | | JSTask | 4.2.6 | 3122 | | | | | 3123 | when | UTCDateTime | AbsoluteTr | Section | 3124 | | | igger | 4.5.2 | 3125 +---------------+----------------------------+------------+---------+ 3127 Table 1 3129 8.3. Creation of "JSCalendar Types" Registry 3131 The IANA will create the "JSCalendar Types" registry to avoid name 3132 collisions and provide a complete reference for all data types used 3133 for JSCalendar property values. The registration process is the same 3134 as for the JSCalendar Properties registry, as defined in Section 8.2. 3136 8.3.1. JSCalendar Types Registry Template 3138 o Type Name: The name of the type. 3140 o Reference or Description: A brief description or RFC number and 3141 section reference where the Type is specified (may be omitted for 3142 "reserved" type names). 3144 o Intended Use: Common, reserved, or obsolete. 3146 o Change Controller: ("IETF" for IETF-stream RFCs). 3148 8.3.2. Initial Contents for the JSCalendar Types Registry 3150 The following table lists the initial entries of the JSCalendar Types 3151 registry. All properties are for common-use. All RFC section 3152 references are for this document. The change controller for all 3153 these properties is "IETF". 3155 +-----------------+--------------------------+ 3156 | Type Name | Reference or Description | 3157 +-----------------+--------------------------+ 3158 | Alert | Section 4.5.2 | 3159 | | | 3160 | Boolean | Section 1.3 | 3161 | | | 3162 | Duration | Section 1.4.5 | 3163 | | | 3164 | Id | Section 1.4.7 | 3165 | | | 3166 | Int | Section 1.4.1 | 3167 | | | 3168 | LocalDateTime | Section 1.4.4 | 3169 | | | 3170 | Link | Section 4.2.7 | 3171 | | | 3172 | Location | Section 4.2.5 | 3173 | | | 3174 | Number | Section 1.3 | 3175 | | | 3176 | Participant | Section 4.4.5 | 3177 | | | 3178 | PatchObject | Section 1.4.8 | 3179 | | | 3180 | RecurrenceRule | Section 4.3.2 | 3181 | | | 3182 | Relation | Section 1.4.10 | 3183 | | | 3184 | SignedDuration | Section 1.4.6 | 3185 | | | 3186 | String | Section 1.3 | 3187 | | | 3188 | TimeZone | Section 4.7.2 | 3189 | | | 3190 | TimeZoneRule | Section 4.7.2 | 3191 | | | 3192 | UnsignedInt | Section 1.4.2 | 3193 | | | 3194 | UTCDateTime | Section 1.4.3 | 3195 | | | 3196 | VirtualLocation | Section 4.2.6 | 3197 +-----------------+--------------------------+ 3199 Table 2 3201 8.4. Creation of "JSCalendar Enum Values" Registry 3203 The IANA will create the "JSCalendar Enum Values" registry to allow 3204 interoperable extension of semantics for properties with enumerable 3205 values. Each such property will have a subregistry of allowed 3206 values. The registration process for a new enum value or adding a 3207 new enumerable property is the same as for the JSCalendar Properties 3208 registry, as defined in Section 8.2. 3210 8.4.1. JSCalendar Enum Property Template 3212 This template is for adding a subregistry for a new enumerable 3213 property to the JSCalendar Enum registry. 3215 o Registry Name: This MUST be of the form "Enum Values for 3216 {property-name} (Context: {context})" where: 3218 {property-name} is the name(s) of the property or properties where 3219 these values may be used. This MUST be registered in the 3220 JSCalendar Properties registry. 3222 {context} is the list of allowed object types where the property 3223 or properties may appear, as registered in the JSCalendar 3224 Properties registry. This disambiguates where there may be two 3225 distinct properties with the same name in different contexts. 3227 o Change Controller: ("IETF" for properties defined in IETF-stream 3228 RFCs). 3230 o Initial Contents: The initial list of defined values for this 3231 enum, using the template defined in Section 8.4.2. 3233 8.4.2. JSCalendar Enum Value Template 3235 This template is for adding a new enum value to a subregistry in the 3236 JSCalendar Enum registry. 3238 o Enum Value: The verbatim value of the enum. 3240 o Reference or Description: A brief description or RFC number and 3241 section reference for the semantics of this value. 3243 8.4.3. Initial Contents for the JSCalendar Enum Registry 3245 For each subregistry created in this section, all RFC section 3246 references are for this document and the change controller is IETF. 3248 ------------------------------------------------------------ 3249 Enum Values for action (Context: Alert) 3251 +------------+--------------------------+ 3252 | Enum Value | Reference or Description | 3253 +------------+--------------------------+ 3254 | display | Section 4.5.2 | 3255 | | | 3256 | email | Section 4.5.2 | 3257 +------------+--------------------------+ 3259 Table 3 3261 ------------------------------------------------------------ 3263 Enum Values for display (Context: Link) 3265 +------------+--------------------------+ 3266 | Enum Value | Reference or Description | 3267 +------------+--------------------------+ 3268 | badge | Section 4.2.7 | 3269 | | | 3270 | graphic | Section 4.2.7 | 3271 | | | 3272 | fullsize | Section 4.2.7 | 3273 | | | 3274 | thumbnail | Section 4.2.7 | 3275 +------------+--------------------------+ 3277 Table 4 3279 ------------------------------------------------------------ 3281 Enum Values for freeBusyStatus (Context: JSEvent, JSTask) 3283 +------------+--------------------------+ 3284 | Enum Value | Reference or Description | 3285 +------------+--------------------------+ 3286 | free | Section 4.4.2 | 3287 | | | 3288 | busy | Section 4.4.2 | 3289 +------------+--------------------------+ 3291 Table 5 3293 ------------------------------------------------------------ 3295 Enum Values for kind (Context: Participant) 3296 +------------+--------------------------+ 3297 | Enum Value | Reference or Description | 3298 +------------+--------------------------+ 3299 | individual | Section 4.4.5 | 3300 | | | 3301 | group | Section 4.4.5 | 3302 | | | 3303 | resource | Section 4.4.5 | 3304 | | | 3305 | location | Section 4.4.5 | 3306 +------------+--------------------------+ 3308 Table 6 3310 ------------------------------------------------------------ 3312 Enum Values for participationStatus (Context: Participant) 3314 +--------------+--------------------------+ 3315 | Enum Value | Reference or Description | 3316 +--------------+--------------------------+ 3317 | needs-action | Section 4.4.5 | 3318 | | | 3319 | accepted | Section 4.4.5 | 3320 | | | 3321 | declined | Section 4.4.5 | 3322 | | | 3323 | tenative | Section 4.4.5 | 3324 | | | 3325 | delegated | Section 4.4.5 | 3326 +--------------+--------------------------+ 3328 Table 7 3330 ------------------------------------------------------------ 3332 Enum Values for privacy (Context: JSEvent, JSTask) 3333 +------------+--------------------------+ 3334 | Enum Value | Reference or Description | 3335 +------------+--------------------------+ 3336 | public | Section 4.4.3 | 3337 | | | 3338 | private | Section 4.4.3 | 3339 | | | 3340 | secret | Section 4.4.3 | 3341 +------------+--------------------------+ 3343 Table 8 3345 ------------------------------------------------------------ 3347 Enum Values for progress (Context: JSTask, Participant) 3349 +--------------+--------------------------+ 3350 | Enum Value | Reference or Description | 3351 +--------------+--------------------------+ 3352 | needs-action | Section 5.2.4 | 3353 | | | 3354 | in-process | Section 5.2.4 | 3355 | | | 3356 | completed | Section 5.2.4 | 3357 | | | 3358 | failed | Section 5.2.4 | 3359 | | | 3360 | cancelled | Section 5.2.4 | 3361 +--------------+--------------------------+ 3363 Table 9 3365 ------------------------------------------------------------ 3367 Enum Values for relation (Context: Relation) 3368 +------------+--------------------------+ 3369 | Enum Value | Reference or Description | 3370 +------------+--------------------------+ 3371 | first | Section 1.4.10 | 3372 | | | 3373 | next | Section 1.4.10 | 3374 | | | 3375 | child | Section 1.4.10 | 3376 | | | 3377 | parent | Section 1.4.10 | 3378 +------------+--------------------------+ 3380 Table 10 3382 ------------------------------------------------------------ 3384 Enum Values for relativeTo (Context: OffsetTrigger, Location) 3386 +------------+--------------------------+ 3387 | Enum Value | Reference or Description | 3388 +------------+--------------------------+ 3389 | start | Section 4.5.2 | 3390 | | | 3391 | end | Section 4.5.2 | 3392 +------------+--------------------------+ 3394 Table 11 3396 ------------------------------------------------------------ 3398 Enum Values for roles (Context: Participant) 3399 +---------------+--------------------------+ 3400 | Enum Value | Reference or Description | 3401 +---------------+--------------------------+ 3402 | owner | Section 4.4.5 | 3403 | | | 3404 | attendee | Section 4.4.5 | 3405 | | | 3406 | optional | Section 4.4.5 | 3407 | | | 3408 | informational | Section 4.4.5 | 3409 | | | 3410 | chair | Section 4.4.5 | 3411 | | | 3412 | contact | Section 4.4.5 | 3413 +---------------+--------------------------+ 3415 Table 12 3417 ------------------------------------------------------------ 3419 Enum Values for scheduleAgent (Context: Participant) 3421 +------------+--------------------------+ 3422 | Enum Value | Reference or Description | 3423 +------------+--------------------------+ 3424 | server | Section 4.4.5 | 3425 | | | 3426 | client | Section 4.4.5 | 3427 | | | 3428 | none | Section 4.4.5 | 3429 +------------+--------------------------+ 3431 Table 13 3433 ------------------------------------------------------------ 3435 Enum Values for status (Context: JSEvent) 3436 +------------+--------------------------+ 3437 | Enum Value | Reference or Description | 3438 +------------+--------------------------+ 3439 | confirmed | Section 5.1.3 | 3440 | | | 3441 | cancelled | Section 5.1.3 | 3442 | | | 3443 | tentative | Section 5.1.3 | 3444 +------------+--------------------------+ 3446 Table 14 3448 9. Acknowledgments 3450 The authors would like to thank the members of CalConnect for their 3451 valuable contributions. This specification originated from the work 3452 of the API technical committee of CalConnect, the Calendaring and 3453 Scheduling Consortium. 3455 10. References 3457 10.1. Normative References 3459 [CLDR] "Unicode Common Locale Data Repository", 3460 . 3462 [COLORS] "CSS Color Module", . 3464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3465 Requirement Levels", BCP 14, RFC 2119, 3466 DOI 10.17487/RFC2119, March 1997, 3467 . 3469 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3470 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 3471 . 3473 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 3474 DOI 10.17487/RFC2397, August 1998, 3475 . 3477 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3478 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3479 . 3481 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 3482 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 3483 . 3485 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3486 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3487 . 3489 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3490 Specifications: ABNF", STD 68, RFC 5234, 3491 DOI 10.17487/RFC5234, January 2008, 3492 . 3494 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 3495 Scheduling Core Object Specification (iCalendar)", 3496 RFC 5545, DOI 10.17487/RFC5545, September 2009, 3497 . 3499 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3500 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3501 September 2009, . 3503 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 3504 Identifier for Geographic Locations ('geo' URI)", 3505 RFC 5870, DOI 10.17487/RFC5870, June 2010, 3506 . 3508 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3509 Specifications and Registration Procedures", BCP 13, 3510 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3511 . 3513 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 3514 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 3515 DOI 10.17487/RFC6901, April 2013, 3516 . 3518 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 3519 DOI 10.17487/RFC7493, March 2015, 3520 . 3522 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3523 Writing an IANA Considerations Section in RFCs", BCP 26, 3524 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3525 . 3527 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3528 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3529 May 2017, . 3531 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3532 Interchange Format", STD 90, RFC 8259, 3533 DOI 10.17487/RFC8259, December 2017, 3534 . 3536 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 3537 DOI 10.17487/RFC8288, October 2017, 3538 . 3540 [TZDB] "IANA Time Zone Database", 3541 . 3543 10.2. Informative References 3545 [LINKRELS] 3546 "IANA Link Relation Types", 3547 . 3550 [LOCATIONTYPES] 3551 "IANA Location Types Registry", 3552 . 3555 [MIME] "IANA Media Types", . 3558 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3559 Resource Identifier (URI): Generic Syntax", STD 66, 3560 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3561 . 3563 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3564 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3565 DOI 10.17487/RFC4122, July 2005, 3566 . 3568 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 3569 Interoperability Protocol (iTIP)", RFC 5546, 3570 DOI 10.17487/RFC5546, December 2009, 3571 . 3573 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 3574 Interoperability Protocol (iMIP)", RFC 6047, 3575 DOI 10.17487/RFC6047, December 2010, 3576 . 3578 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 3579 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 3580 RFC 6376, DOI 10.17487/RFC6376, September 2011, 3581 . 3583 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 3584 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 3585 2014, . 3587 [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules 3588 in the Internet Calendaring and Scheduling Core Object 3589 Specification (iCalendar)", RFC 7529, 3590 DOI 10.17487/RFC7529, May 2015, 3591 . 3593 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 3594 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 3595 . 3597 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 3598 DOI 10.17487/RFC7986, October 2016, 3599 . 3601 Authors' Addresses 3603 Neil Jenkins 3604 Fastmail 3605 PO Box 234 3606 Collins St West 3607 Melbourne VIC 8007 3608 Australia 3610 Email: neilj@fastmailteam.com 3611 URI: https://www.fastmail.com 3613 Robert Stepanek 3614 Fastmail 3615 PO Box 234 3616 Collins St West 3617 Melbourne VIC 8007 3618 Australia 3620 Email: rsto@fastmailteam.com 3621 URI: https://www.fastmail.com