idnits 2.17.1 draft-ietf-calext-jscalendar-19.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 (October 3, 2019) is 1660 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) -- Looks like a reference, but probably isn't: '1' on line 3531 -- Looks like a reference, but probably isn't: '2' on line 3533 -- Looks like a reference, but probably isn't: '3' on line 3536 -- Looks like a reference, but probably isn't: '4' on line 3538 == Missing Reference: 'Alert' is mentioned on line 2723, but not defined == Missing Reference: 'Boolean' is mentioned on line 2929, but not defined == Missing Reference: 'PatchObject' is mentioned on line 2895, but not defined == Missing Reference: 'Location' is mentioned on line 2844, but not defined == Missing Reference: 'Participant' is mentioned on line 2867, but not defined == Missing Reference: 'Relation' is mentioned on line 2907, but not defined == Missing Reference: 'String' is mentioned on line 2941, but not defined == Missing Reference: 'TimeZone' is mentioned on line 2994, but not defined == Missing Reference: 'VirtualLocation' is mentioned on line 3019, but not defined Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 5 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: April 5, 2020 October 3, 2019 7 JSCalendar: A JSON representation of calendar data 8 draft-ietf-calext-jscalendar-19 10 Abstract 12 This specification defines a data model and JSON representation of 13 calendar data that can be used for storage and data exchange in a 14 calendaring and scheduling environment. It aims to be an 15 alternative, and over time successor to, the widely deployed 16 iCalendar data format and to be unambiguous, extendable and simple to 17 process. In contrast to the JSON-based jCal format, it is not a 18 direct mapping from iCalendar and expands semantics where 19 appropriate. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 5, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Motivation and Relation to iCalendar and jCal . . . . . . 5 57 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 6 58 1.3. Type Signatures . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.4.1. Int . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.4.2. UnsignedInt . . . . . . . . . . . . . . . . . . . . . 7 62 1.4.3. UTCDateTime . . . . . . . . . . . . . . . . . . . . . 7 63 1.4.4. LocalDateTime . . . . . . . . . . . . . . . . . . . . 7 64 1.4.5. Duration . . . . . . . . . . . . . . . . . . . . . . 7 65 1.4.6. SignedDuration . . . . . . . . . . . . . . . . . . . 8 66 1.4.7. Id . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1.4.8. PatchObject . . . . . . . . . . . . . . . . . . . . . 9 68 1.4.9. Time Zones . . . . . . . . . . . . . . . . . . . . . 9 69 1.4.10. Relation . . . . . . . . . . . . . . . . . . . . . . 9 70 2. JSCalendar Objects . . . . . . . . . . . . . . . . . . . . . 10 71 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3. Structure of JSCalendar Objects . . . . . . . . . . . . . . . 11 75 3.1. Normalization and Equivalence . . . . . . . . . . . . . . 11 76 3.2. Vendor-specific Property Extensions and Values . . . . . 12 77 4. Common JSCalendar Properties . . . . . . . . . . . . . . . . 12 78 4.1. Metadata Properties . . . . . . . . . . . . . . . . . . . 12 79 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 13 82 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 14 86 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.2. What and Where Properties . . . . . . . . . . . . . . . . 14 88 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 14 90 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 15 91 4.2.4. showWithoutTime . . . . . . . . . . . . . . . . . . . 15 92 4.2.5. locations . . . . . . . . . . . . . . . . . . . . . . 15 93 4.2.6. virtualLocations . . . . . . . . . . . . . . . . . . 16 94 4.2.7. links . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.2.8. locale . . . . . . . . . . . . . . . . . . . . . . . 19 96 4.2.9. keywords . . . . . . . . . . . . . . . . . . . . . . 19 97 4.2.10. categories . . . . . . . . . . . . . . . . . . . . . 19 98 4.2.11. color . . . . . . . . . . . . . . . . . . . . . . . . 19 99 4.3. Recurrence Properties . . . . . . . . . . . . . . . . . . 19 100 4.3.1. recurrenceId . . . . . . . . . . . . . . . . . . . . 20 101 4.3.2. recurrenceRule . . . . . . . . . . . . . . . . . . . 20 102 4.3.3. recurrenceOverrides . . . . . . . . . . . . . . . . . 28 103 4.3.4. excluded . . . . . . . . . . . . . . . . . . . . . . 29 104 4.4. Sharing and Scheduling Properties . . . . . . . . . . . . 29 105 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 29 106 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 29 107 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 30 108 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 31 109 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 31 110 4.5. Alerts Properties . . . . . . . . . . . . . . . . . . . . 35 111 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 35 112 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 36 113 4.6. Multilingual Properties . . . . . . . . . . . . . . . . . 38 114 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 38 115 4.7. Time Zone Properties . . . . . . . . . . . . . . . . . . 38 116 4.7.1. timeZone . . . . . . . . . . . . . . . . . . . . . . 39 117 4.7.2. timeZones . . . . . . . . . . . . . . . . . . . . . . 39 118 5. Type-specific JSCalendar Properties . . . . . . . . . . . . . 41 119 5.1. JSEvent Properties . . . . . . . . . . . . . . . . . . . 41 120 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 41 121 5.1.2. duration . . . . . . . . . . . . . . . . . . . . . . 41 122 5.1.3. status . . . . . . . . . . . . . . . . . . . . . . . 42 123 5.2. JSTask Properties . . . . . . . . . . . . . . . . . . . . 42 124 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 42 125 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 42 126 5.2.3. estimatedDuration . . . . . . . . . . . . . . . . . . 42 127 5.2.4. statusUpdatedAt . . . . . . . . . . . . . . . . . . . 42 128 5.2.5. progress . . . . . . . . . . . . . . . . . . . . . . 43 129 5.2.6. status . . . . . . . . . . . . . . . . . . . . . . . 44 130 5.3. JSGroup Properties . . . . . . . . . . . . . . . . . . . 44 131 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 45 132 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 45 133 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 45 134 6.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 45 135 6.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 46 136 6.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 46 137 6.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 47 138 6.5. Task with a due date . . . . . . . . . . . . . . . . . . 47 139 6.6. Event with end time-zone . . . . . . . . . . . . . . . . 48 140 6.7. Floating-time event (with recurrence) . . . . . . . . . . 48 141 6.8. Event with multiple locations and localization . . . . . 49 142 6.9. Recurring event with overrides . . . . . . . . . . . . . 50 143 6.10. Recurring event with participants . . . . . . . . . . . . 51 144 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 145 7.1. Expanding Recurrences . . . . . . . . . . . . . . . . . . 53 146 7.2. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 53 147 7.3. URI Values . . . . . . . . . . . . . . . . . . . . . . . 54 148 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 149 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 54 150 8.2. Creation of "JSCalendar Properties" Registry . . . . . . 55 151 8.2.1. Preliminary Community Review . . . . . . . . . . . . 56 152 8.2.2. Submit Request to IANA . . . . . . . . . . . . . . . 56 153 8.2.3. Designated Expert Review . . . . . . . . . . . . . . 56 154 8.2.4. Change Procedures . . . . . . . . . . . . . . . . . . 57 155 8.2.5. JMAP Properties Registry Template . . . . . . . . . . 57 156 8.2.6. Initial Contents for the JSCalendar Properties 157 Registry . . . . . . . . . . . . . . . . . . . . . . 58 158 8.3. Creation of "JSCalendar Types" Registry . . . . . . . . . 65 159 8.3.1. JMAP Types Registry Template . . . . . . . . . . . . 65 160 8.3.2. Initial Contents for the JSCalendar Properties 161 Registry . . . . . . . . . . . . . . . . . . . . . . 65 162 8.4. Creation of "JSCalendar Enum Values" Registry . . . . . . 67 163 8.4.1. JMAP Enum Subregistry Creation Template . . . . . . . 67 164 8.4.2. JMAP Enum Subregistry Creation Template . . . . . . . 67 165 8.4.3. Initial Contents for the JSCalendar Enum Registry . . 67 166 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74 167 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 168 10.1. Normative References . . . . . . . . . . . . . . . . . . 74 169 10.2. Informative References . . . . . . . . . . . . . . . . . 76 170 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 76 171 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 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. It aims to be unambiguous, extendable and 178 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 a simple key-value pair. Simple events are simple to 184 represent, 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 and make it difficult to 190 make mistakes during implementation. 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 widely unused, obsolete or redundant 196 properties. This means translation with no loss of semantics 197 should be easy with most common iCalendar files but is not 198 guaranteed with the full specification. 200 o Extensions, such as new properties and components, MUST NOT lead 201 to requiring an update to this document. 203 The representation of this data model is defined in the I-JSON format 204 [RFC7493], which is a strict subset of the JavaScript Object Notation 205 (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a 206 pragmatic choice: its widespread use makes JSCalendar easier to 207 adopt, and the ready availability of production-ready JSON 208 implementations eliminates a whole category of parser-related 209 interoperability issues, which iCalendar has often suffered from. 211 1.1. Motivation and Relation to iCalendar and jCal 213 The iCalendar data format [RFC5545], a widely deployed interchange 214 format for calendaring and scheduling data, has served calendaring 215 vendors for a long while, but contains some ambiguities and pitfalls 216 that can not be overcome without backward-incompatible changes. 218 For example, iCalendar defines various formats for local times, UTC 219 time and dates, which confuses new users and often leads to 220 implementation errors. Other sources for errors are the requirement 221 for custom time zone definitions within a single calendar component, 222 as well as the iCalendar format itself; the latter causing 223 interoperability issues due to misuse of CR LF terminated strings, 224 line continuations and subtle differences between iCalendar parsers. 225 The definition of recurrence rules is ambiguous and has resulted in 226 differing understandings even between experienced calendar 227 developers. 229 In recent years, many new products and services have appeared that 230 wish to use a JSON representation of calendar data within their API. 231 The JSON format for iCalendar data, jCal [RFC7265], is a direct 232 mapping between iCalendar and JSON. In its effort to represent full 233 iCalendar semantics, it inherits all the same pitfalls and uses a 234 complicated JSON structure unlike most common JSON data 235 representations. 237 As a consequence, since the standardization of jCal, the majority of 238 implementations and service providers either kept using iCalendar, or 239 came up with their own proprietary JSON representations, which are 240 incompatible with each other and often suffer from common pitfalls, 241 such as storing event start times in UTC (which become incorrect if 242 the timezone's rules change in the future). JSCalendar is intended 243 to meet this demand for JSON-formatted calendar data, and to provide 244 a standard, elegant representation as an alternative to new 245 proprietary formats. 247 1.2. Notational Conventions 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in [RFC2119]. 253 The underlying format used for this specification is JSON. 254 Consequently, the terms "object" and "array" as well as the four 255 primitive types (strings, numbers, booleans, and null) are to be 256 interpreted as described in Section 1 of [RFC8259]. 258 Some examples in this document contain "partial" JSON documents used 259 for illustrative purposes. In these examples, three periods "..." 260 are used to indicate a portion of the document that has been removed 261 for compactness. 263 1.3. Type Signatures 265 Type signatures are given for all JSON values in this document. The 266 following conventions are used: 268 o "*" - The type is undefined (the value could be any type, although 269 permitted values may be constrained by the context of this value). 271 o "String" - The JSON string type. 273 o "Number" - The JSON number type. 275 o "Boolean" - The JSON boolean type. 277 o "A[B]" - A JSON object where the keys are all of type "A", and the 278 values are all of type "B". 280 o "A[]" - An array of values of type "A". 282 o "A|B" - The value is either of type "A" or of type "B". 284 Other types may also be given, with their representation defined 285 elsewhere in this document. 287 1.4. Data Types 289 In addition to the standard JSON data types, the following data types 290 are used in this specification: 292 1.4.1. Int 294 Where "Int" is given as a data type, it means an integer in the range 295 -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a 296 floating-point double, represented as a JSON "Number". 298 1.4.2. UnsignedInt 300 Where "UnsignedInt" is given as a data type, it means an "Int" where 301 the value MUST be in the range 0 <= value <= 2^53-1. 303 1.4.3. UTCDateTime 305 This is a string in [RFC3339] "date-time" format, with the further 306 restrictions that any letters MUST be in uppercase, the time 307 component MUST be included and the time offset MUST be the character 308 "Z". Fractional second values MUST NOT be included unless non-zero 309 and MUST NOT have trailing zeros, to ensure there is only a single 310 representation for each date-time. 312 For example "2010-10-10T10:10:10.003Z" is OK, but 313 "2010-10-10T10:10:10.000Z" is invalid and MUST be encoded as 314 "2010-10-10T10:10:10Z". 316 In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". 318 1.4.4. LocalDateTime 320 This is a date-time string with no time zone/offset information. It 321 is otherwise in the same format as UTCDateTime, including fractional 322 seconds. For example "2006-01-02T15:04:05" and 323 "2006-01-02T15:04:05.003" are both valid. The time zone to associate 324 the LocalDateTime with comes from an associated property, or if no 325 time zone is associated it defines *floating time*. Floating date- 326 times are not tied to any specific time zone. Instead, they occur in 327 every time zone at the same wall-clock time (as opposed to the same 328 instant point in time). 330 1.4.5. Duration 332 Where Duration is given as a type, it means a length of time 333 represented by a subset of ISO8601 duration format, as specified by 334 the following ABNF: 336 dur-secfrac = "." 1*DIGIT 337 dur-second = 1*DIGIT [dur-secfrac] "S" 338 dur-minute = 1*DIGIT "M" [dur-second] 339 dur-hour = 1*DIGIT "H" [dur-minute] 340 dur-time = "T" (dur-hour / dur-minute / dur-second) 341 dur-day = 1*DIGIT "D" 342 dur-week = 1*DIGIT "W" 344 duration = "P" (dur-day [dur-time] / dur-time / dur-week) 346 In addition, the duration MUST NOT include fractional second values 347 unless the fraction is non-zero. 349 1.4.6. SignedDuration 351 A SignedDuration represents a length of time that may be positive or 352 negative and is typically used to express the offset of a point in 353 time relative to an associated time. It is represented as a 354 Duration, optionally preceded by a sign character. It is specified 355 by the following ABNF: 357 signed-duration = (["+"] / "-") duration 359 A negative sign indicates a point in time at or before the associated 360 time, a positive or no sign a time at or after the associated time. 362 1.4.7. Id 364 Where "Id" is given as a data type, it means a "String" of at least 1 365 and a maximum of 255 octets in size, and it MUST only contain 366 characters from the "URL and Filename Safe" base64 alphabet, as 367 defined in Section 5 of [RFC4648], excluding the pad character ("="). 368 This means the allowed characters are the ASCII alphanumeric 369 characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). 371 Unless otherwise specified, Ids are arbitrary and only have meaning 372 within the object where they are being used. Ids need not be unique 373 between different objects. For example, two JSEvent objects MAY use 374 the same ids in their respective "links" properties. Or within the 375 same JSEvent object the same Id could appear in the "participants" 376 and "alerts" properties. This does not imply any semantic connection 377 between the two. 379 Nevertheless, a UUID is typically a good choice. 381 1.4.8. PatchObject 383 A PatchObject is of type "String[*]", and represents an unordered set 384 of patches on a JSON object. The keys are a path in a subset of 385 [RFC6901] JSON pointer format, with an implicit leading "/" (i.e. 386 prefix each key with "/" before applying the JSON pointer evaluation 387 algorithm). 389 A patch within a PatchObject is only valid if all of the following 390 conditions apply: 392 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT 393 insert/delete from an array; the array MUST be replaced in its 394 entirety instead). 396 2. When evaluating a path, all parts prior to the last (i.e. the 397 value after the final slash) MUST exist. 399 3. There MUST NOT be two patches in the PatchObject where the 400 pointer of one is the prefix of the pointer of the other, e.g. 401 "alerts/foo/offset" and "alerts". 403 The value associated with each pointer is either: 405 o null: Remove the property from the patched object. If not present 406 in the parent, this a no-op. 408 o Anything else: The value to set for this property (this may be a 409 replacement or addition to the object being patched). 411 Implementations MUST reject a PatchObject if any of its patches are 412 invalid. 414 1.4.9. Time Zones 416 By default, time zones in JSCalendar are identified by their name in 417 the IANA Time Zone Database [1], and the zone rules of the respective 418 zone record apply. 420 Implementations MAY embed the definition of custom time zones in the 421 "timeZones" property (see Section 4.7.2). 423 1.4.10. Relation 425 A Relation object defines the relation to other objects, using a 426 possibly empty set of relation types. The object that defines this 427 relation is the linking object, the other object is the linked 428 object. The Relation object has the following property: 430 o @type: "String" (mandatory) 432 Specifies the type of this object. This MUST be "Relation". 434 o relation: "String[Boolean]" (optional, default: empty Object) 436 Describes how the linked object is related to the linking object. 437 The relation is defined as a set of relation types. If empty, the 438 relationship between the two objects is unspecified. 440 Keys in the set MUST be one of the following values, or specified 441 in the property definition where the Relation object is used, or 442 an IANA-registered value, or a vendor-specific value: 444 * "first": The linked object is the first in a series the linking 445 object is part of. 447 * "next": The linked object is the next in a series the linking 448 object is part of. 450 * "child": The linked object is a subpart of the linking object. 452 * "parent": The linking object is part of the overall linked 453 object. 455 The value for each key in the set MUST be true. 457 Note, the Relation object only has one property (except @type); it is 458 specified as an object with a single property to allow for extension 459 in the future. 461 2. JSCalendar Objects 463 This section describes the calendar object types specified by 464 JSCalendar. 466 2.1. JSEvent 468 MIME type: "application/jscalendar+json;type=jsevent" 470 A JSEvent represents a scheduled amount of time on a calendar, 471 typically a meeting, appointment, reminder or anniversary. Multiple 472 participants may partake in the event at multiple locations. 474 The @type (Section 4.1.1) property value MUST be "jsevent". 476 2.2. JSTask 478 MIME type: "application/jscalendar+json;type=jstask" 480 A JSTask represents an action-item, assignment, to-do or work item. 482 The @type (Section 4.1.1) property value MUST be "jstask". 484 A JSTask may start and be due at certain points in time, may take 485 some estimated time to complete and may recur; none of which is 486 required. This notably differs from JSEvent (Section 2.1) which is 487 required to start at a certain point in time and typically takes some 488 non-zero duration to complete. 490 2.3. JSGroup 492 MIME type: "application/jscalendar+json;type=jsgroup" 494 A JSGroup is a collection of JSEvent (Section 2.1) and/or JSTask 495 (Section 2.2) objects. Typically, objects are grouped by topic (e.g. 496 by keywords) or calendar membership. 498 The @type (Section 4.1.1) property value MUST be "jsgroup". 500 3. Structure of JSCalendar Objects 502 A JSCalendar object is a JSON object, which MUST be valid I-JSON (a 503 stricter subset of JSON), as specified in [RFC8259]. Property names 504 and values are case-sensitive. 506 The object has a collection of properties, as specified in the 507 following sections. Properties are specified as being either 508 mandatory or optional. Optional properties may have a default value, 509 if explicitly specified in the property definition. 511 3.1. Normalization and Equivalence 513 JSCalendar aims to provide unambiguous definitions for value types 514 and properties, but does not define a general normalization or 515 equivalence method for JSCalendar objects and types. This is because 516 the notion of equivalence might range from byte-level equivalence to 517 semantic equivalence, depending on the respective use case (for 518 example, the CalDAV protocol [RFC4791] requires octet equivalence of 519 the encoded calendar object to determine ETag equivalence). 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 MIME 530 types, but normalization of these types is inherently protocol and 531 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 by another RFC. 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 If so, 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, an IANA-registered value, or a vendor-specific 568 value: 570 o "jsevent": a JSCalendar event (Section 2.1). 572 o "jstask": a JSCalendar task (Section 2.2). 574 o "jsgroup": a JSCalendar group (Section 2.3). 576 4.1.2. uid 578 Type: "String" (mandatory). 580 A globally unique identifier, used to associate the object as the 581 same across different systems, calendars and views. The value of 582 this property MUST be unique across all JSCalendar objects, even if 583 they are of different type. [RFC4122] describes a range of 584 established algorithms to generate universally unique identifiers 585 (UUID), and the random or pseudo-random version is 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 created the JSCalendar object. 616 The vendor of the implementation SHOULD ensure that this is a 617 globally unique identifier, using some technique such as an FPI 618 value, as defined in [ISO.9070.1991]. It MUST only use characters of 619 an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]). 621 This property SHOULD NOT be used to alter the interpretation of a 622 JSCalendar object beyond the semantics specified in this document. 623 For example, it is not to be used to further the understanding of 624 non-standard properties. 626 4.1.5. created 628 Type: "UTCDateTime" (optional). 630 The date and time this object was initially created. 632 4.1.6. updated 634 Type: "UTCDateTime" (mandatory). 636 The date and time the data in this object was last modified. 638 4.1.7. sequence 640 Type: "UnsignedInt" (optional, default: 0). 642 Initially zero, this MUST be incremented by one every time a change 643 is made to the object, except if the change only modifies the 644 "participants" property (see Section 4.4.5). 646 This is used as part of iTIP [RFC5546] to know which version of the 647 object a scheduling message relates to. 649 4.1.8. method 651 Type: "String" (optional). 653 The iTIP [RFC5546] method, in lowercase. This MUST only be present 654 if the JSCalendar object represents an iTIP scheduling message. 656 4.2. What and Where Properties 658 4.2.1. title 660 Type: "String" (optional, default: empty String). 662 A short summary of the object. 664 4.2.2. description 666 Type: "String" (optional, default: empty String). 668 A longer-form text description of the object. The content is 669 formatted according to the "descriptionContentType" property. 671 4.2.3. descriptionContentType 673 Type: "String" (optional, default: "text/plain"). 675 Describes the media type [RFC6838] of the contents of the 676 "description" property. Media types MUST be sub-types of type 677 "text", and SHOULD be "text/plain" or "text/html" [MIME]. They MAY 678 define parameters and the "charset" parameter value MUST be "utf-8", 679 if specified. Descriptions of type "text/html" MAY contain "cid" 680 URLs [RFC2392] to reference links in the calendar object by use of 681 the "cid" property of the Link object. 683 4.2.4. showWithoutTime 685 Type: "Boolean" (optional, default: false). 687 Indicates the time is not important to display to the user when 688 rendering this calendar object, for example an event that 689 conceptually occurs all day or across multiple days, such as "New 690 Year's Day" or "Italy Vacation". While the time component is 691 important for free-busy calculations and checking for scheduling 692 clashes, calendars may choose to omit displaying it and/or display 693 the object separately to other objects to enhance the user's view of 694 their schedule. 696 Such events are also commonly known as "all-day" events. 698 4.2.5. locations 700 Type: "Id[Location]" (optional). 702 A map of location ids to Location objects, representing locations 703 associated with the object. 705 A Location object has the following properties. It MUST have at 706 least one property other than the "relativeTo" property. 708 o @type: "String" (mandatory) 710 Specifies the type of this object. This MUST be "Location". 712 o name: "String" (optional) 714 The human-readable name of the location. 716 o description: "String" (optional) 718 Human-readable, plain-text instructions for accessing this 719 location. This may be an address, set of directions, door access 720 code, etc. 722 o relativeTo: "String" (optional) 724 The relation type of this location to the JSCalendar object. 726 This MUST be either one of the following values, an IANA- 727 registered value, or a vendor-specific value. Any value the 728 client or server doesn't understand should be treated the same as 729 if this property is omitted. 731 * "start": The JSCalendar object starts at this location. 733 * "end": The JSCalendar object ends at this location. 735 o timeZone: "String" (optional) 737 A time zone for this location. See also Section 1.4.9. 739 o coordinates: "String" (optional) 741 A "geo:" URI [RFC5870] for the location. 743 o linkIds: "Id[Boolean]" (optional) 745 A set of link ids for links to alternate representations of this 746 location. Each key in the set MUST be the id of a Link object 747 defined in the "links" property of this calendar object. The 748 value for each key in the set MUST be true. This MUST be omitted 749 if none (rather than an empty set). 751 For example, an alternative representation could be in vCard 752 format. 754 4.2.6. virtualLocations 756 Type: "Id[VirtualLocation]" (optional). 758 A map of ids to VirtualLocation objects, representing virtual 759 locations, such as video conferences or chat rooms, associated with 760 the object. 762 A VirtualLocation object has the following properties. 764 o @type: "String" (mandatory) 766 Specifies the type of this object. This MUST be 767 "VirtualLocation". 769 o name: "String" (optional, default: empty String) 771 The human-readable name of the virtual location. 773 o description: "String" (optional) 775 Human-readable plain-text instructions for accessing this 776 location. This may be an address, set of directions, door access 777 code, etc. 779 o uri: "String" (mandatory) 781 A URI that represents how to connect to this virtual location. 783 This may be a telephone number (represented using the "tel:" 784 scheme, e.g., "tel:+1-555-555-555") for a teleconference, a web 785 address for online chat, or any custom URI. 787 4.2.7. links 789 Type: "Id[Link]" (optional). 791 A map of link ids to Link objects, representing external resources 792 associated with the object. 794 A Link object has the following properties: 796 o @type: "String" (mandatory) 798 Specifies the type of this object. This MUST be "Link". 800 o href: "String" (mandatory) 802 A URI from which the resource may be fetched. 804 This MAY be a "data:" URL, but it is recommended that the file be 805 hosted on a server to avoid embedding arbitrarily large data in 806 JSCalendar object instances. 808 o cid: "String" (optional) 810 This MUST be a valid "content-id" value according to the 811 definition of Section 2 in [RFC2392]. The value MUST be unique 812 within this Link object but has no meaning beyond that. It MAY be 813 different from the link id for this Link object. 815 o contentType: "String" (optional) 817 The content-type [RFC6838] of the resource, if known. 819 o size: "UnsignedInt" (optional) 821 The size, in octets, of the resource when fully decoded (i.e. the 822 number of octets in the file the user would download), if known. 824 o rel: "String" (optional) 826 Identifies the relation of the linked resource to the object. If 827 set, the value MUST be a registered relation type (see [RFC8288] 828 and IANA Link Relations [2]). 830 Links with a rel of "enclosure" SHOULD be considered by the client 831 as attachments for download. 833 Links with a rel of "describedby" SHOULD be considered by the 834 client to be an alternate representation of the description. 836 Links with a rel of "icon" SHOULD be considered by the client to 837 be an image that it MAY use when presenting the calendar data to a 838 user. The "display" property MAY be set to indicate the purpose 839 of this image. 841 o display: "String" (optional) 843 Describes the intended purpose of a link to an image. If set, the 844 "rel" property MUST be set to "icon". The value MUST be either 845 one of the following values, an IANA-registered value, or a 846 vendor-specific value: 848 * "badge": an image inline with the title of the object. 850 * "graphic": a full image replacement for the object itself. 852 * "fullsize": an image that is used to enhance the object. 854 * "thumbnail": a smaller variant of "fullsize" to be used when 855 space for the image is constrained. 857 o title: "String" (optional) 859 A human-readable plain-text description of the resource. 861 4.2.8. locale 863 Type: "String" (optional). 865 The language tag as defined in [RFC5646] that best describes the 866 locale used for the text in the calendar object, if known. 868 4.2.9. keywords 870 Type: "String[Boolean]" (optional). 872 A set of keywords or tags that relate to the object. The set is 873 represented as a map, with the keys being the keywords. The value 874 for each key in the map MUST be true. 876 4.2.10. categories 878 Type: "String[Boolean]" (optional). 880 A set of categories that relate to the calendar object. The set is 881 represented as a map, with the keys being the categories specified as 882 URIs. The value for each key in the map MUST be true. 884 In contrast to keywords, categories typically are structured. For 885 example, a vendor owning the domain "example.com" might define the 886 categories "http://example.com/categories/sports/american-football"" 887 and "http://example.com/categories/music/r-b". 889 4.2.11. color 891 Type: "String" (optional). 893 A color clients MAY use when displaying this calendar object. The 894 value is a case-insensitive color name taken from the CSS3 set of 895 names, defined in Section 4.3 of W3C.REC-css3-color-20110607 [3] or a 896 CSS3 RGB color hex value. 898 4.3. Recurrence Properties 900 Some events and tasks occur at regular, or indeed irregular, 901 intervals. Rather than having to copy the data for every occurrence, 902 you can instead have a master event with a recurrence rule generating 903 the occurrences, and/or overrides that add extra dates or exceptions 904 to the rule. 906 4.3.1. recurrenceId 908 Type: "LocalDateTime" (optional). 910 If present, this JSCalendar object represents one occurrence of a 911 recurring JSCalendar object. If present the "recurrenceRule" and 912 "recurrenceOverrides" properties MUST NOT be present. 914 The value is a date-time either produced by the "recurrenceRule" of 915 the master event, or added as a key to the "recurrenceOverrides" 916 property of the master event. 918 4.3.2. recurrenceRule 920 Type: "RecurrenceRule" (optional). 922 Defines a recurrence rule (repeating pattern) for recurring calendar 923 objects. 925 A JSEvent recurs by applying the recurrence rule to the "start" date- 926 time. 928 A JSTask recurs by applying the recurrence rule to the "start" date- 929 time, if defined, otherwise it recurs by the "due" date-time, if 930 defined. If the task defines neither a "start" nor "due" date-time, 931 its "recurrenceRule" property value MUST be null. 933 A RecurrenceRule object is a JSON object mapping of a RECUR value 934 type in iCalendar [RFC5545] [RFC7529] and has the same semantics. It 935 has the following properties: 937 o @type: "String" (mandatory) 939 Specifies the type of this object. This MUST be "RecurrenceRule". 941 o frequency: "String" (mandatory) 943 The time span covered by each iteration of this recurrence rule 944 (see Section 4.3.2.1 for full semantics). This MUST be one of the 945 following values: 947 * "yearly" 949 * "monthly" 951 * "weekly" 953 * "daily" 954 * "hourly" 956 * "minutely" 958 * "secondly" 960 This is the FREQ part from iCalendar, converted to lowercase. 962 o interval: "UnsignedInt" (optional, default: 1) 964 The interval of iteration periods at which the recurrence repeats. 965 If included, it MUST be an integer >= 1. 967 This is the INTERVAL part from iCalendar. 969 o rscale: "String" (optional, default: "gregorian") 971 The calendar system in which this recurrence rule operates, in 972 lowercase. This MUST be either a CLDR-registered calendar system 973 name, or a non-standard, experimental calendar system name 974 prefixed with the characters "x-". 976 This is the RSCALE part from iCalendar RSCALE [RFC7529], converted 977 to lowercase. 979 o skip: "String" (optional, default: "omit") 981 The behaviour to use when the expansion of the recurrence produces 982 invalid dates. This MUST be one of the following values: 984 * "omit" 986 * "backward" 988 * "forward" 990 This is the SKIP part from iCalendar RSCALE [RFC7529], converted 991 to lowercase. 993 o firstDayOfWeek: "String" (optional, default: "mo") 995 The day on which the week is considered to start, represented as a 996 lowercase abbreviated two-letter English day of the week. If 997 included, it MUST be one of the following values: 999 * "mo" 1001 * "tu" 1002 * "we" 1004 * "th" 1006 * "fr" 1008 * "sa" 1010 * "su" 1012 This is the WKST part from iCalendar. 1014 o byDay: "NDay[]" (optional) 1016 Days of the week on which to repeat. An *NDay* object has the 1017 following properties: 1019 * day: "String" (mandatory) 1021 A day of the week on which to repeat; the allowed values are 1022 the same as for the "firstDayOfWeek" RecurrenceRule property. 1024 This is the day-of-the-week of the BYDAY part in iCalendar, 1025 converted to lowercase. 1027 * nthOfPeriod: "Int" (optional) 1029 If present, rather than representing every occurrence of the 1030 weekday defined in the "day" property, it represents only a 1031 specific instance within the recurrence period. The value can 1032 be positive or negative, but MUST NOT be zero. A negative 1033 integer means nth-last of period. 1035 This is the ordinal part of the BYDAY value in iCalendar (e.g. 1036 1 or -3). 1038 o byMonthDay: "Int[]" (optional) 1040 Days of the month on which to repeat. Valid values are 1 to 31 or 1041 -31 to -1. Negative values offset from the end of the month. The 1042 array MUST have at least one entry if included. 1044 This is the BYMONTHDAY part in iCalendar. 1046 o byMonth: "String[]" (optional) 1048 The months in which to repeat. Each entry is a string 1049 representation of a number, starting from "1" for the first month 1050 in the calendar (e.g. "1" means January with the Gregorian 1051 calendar), with an optional "L" suffix (see [RFC7529]) for leap 1052 months (this MUST be uppercase, e.g. "3L"). The array MUST have 1053 at least one entry if included. 1055 This is the BYMONTH part from iCalendar. 1057 o byYearDay: "Int[]" (optional) 1059 The days of the year on which to repeat. Valid values are 1 to 1060 366 or -366 to -1. Negative values offset from the end of the 1061 year. The array MUST have at least one entry if included. 1063 This is the BYYEARDAY part from iCalendar. 1065 o byWeekNo: "Int[]" (optional) 1067 Weeks of the year in which to repeat. Valid values are 1 to 53 or 1068 -53 to -1. The array MUST have at least one entry if included. 1070 This is the BYWEEKNO part from iCalendar. 1072 o byHour: "UnsignedInt[]" (optional) 1074 The hours of the day in which to repeat. Valid values are 0 to 1075 23. The array MUST have at least one entry if included. This is 1076 the BYHOUR part from iCalendar. 1078 o byMinute: "UnsignedInt[]" (optional) 1080 The minutes of the hour in which to repeat. Valid values are 0 to 1081 59. The array MUST have at least one entry if included. 1083 This is the BYMINUTE part from iCalendar. 1085 o bySecond: "UnsignedInt[]" (optional) 1087 The seconds of the minute in which to repeat. Valid values are 0 1088 to 60. The array MUST have at least one entry if included. 1090 This is the BYSECOND part from iCalendar. 1092 o bySetPosition: "Int[]" (optional) 1094 The occurrences within the recurrence interval to include in the 1095 final results. Negative values offset from the end of the list of 1096 occurrences. The array MUST have at least one entry if included. 1097 This is the BYSETPOS part from iCalendar. 1099 o count: "UnsignedInt" (optional) 1101 The number of occurrences at which to range-bound the recurrence. 1102 This MUST NOT be included if an "until" property is specified. 1104 This is the COUNT part from iCalendar. 1106 o until: "LocalDateTime" (optional) 1108 The date-time at which to finish recurring. The last occurrence 1109 is on or before this date-time. This MUST NOT be included if a 1110 "count" property is specified. Note: if not specified otherwise 1111 for a specific JSCalendar object, this date is to be interpreted 1112 in the time zone specified in the JSCalendar object's "timeZone" 1113 property. 1115 This is the UNTIL part from iCalendar. 1117 4.3.2.1. Interpreting recurrence rules 1119 A recurrence rule specifies a set of date-times for recurring 1120 calendar objects. A recurrence rule has the following semantics. 1121 Note, wherever "year", "month" or "day of month" is used, this is 1122 within the calendar system given by the "rscale" property, which 1123 defaults to gregorian if omitted. 1125 1. A set of candidates is generated. This is every second within a 1126 period defined by the frequency property value: 1128 * "yearly": every second from midnight on the 1st day of a year 1129 (inclusive) to midnight the 1st day of the following year 1130 (exclusive). 1132 If skip is not "omit", the calendar system has leap months and 1133 there is a byMonth property, generate candidates for the leap 1134 months even if they don't occur in this year. 1136 If skip is not "omit" and there is a byMonthDay property, 1137 presume each month has the maximum number of days any month 1138 may have in this calendar system when generating candidates, 1139 even if it's more than this month actually has. 1141 * "monthly": every second from midnight on the 1st day of a 1142 month (inclusive) to midnight on the 1st of the following 1143 month (exclusive). 1145 If skip is not "omit" and there is a byMonthDay property, 1146 presume the month has the maximum number of days any month may 1147 have in this calendar system when generating candidates, even 1148 if it's more than this month actually has. 1150 * "weekly": every second from midnight (inclusive) on the first 1151 day of the week (as defined by the firstDayOfWeek property, or 1152 Monday if omitted), to midnight 7 days later (exclusive). 1154 * "daily": every second from midnight at the start of the day 1155 (inclusive) to midnight at the end of the day (exclusive). 1157 * "hourly": every second from the beginning of the hour 1158 (inclusive) to the beginning of the next hour (exclusive). 1160 * "minutely": every second from the beginning of the minute 1161 (inclusive) to the beginning of the next minute (exclusive). 1163 * "secondly": the second itself, only. 1165 2. Each date-time candidate is compared against all of the byX 1166 properties of the rule except bySetPosition. If any property in 1167 the rule does not match the date-time, it is eliminated. Each 1168 byX property is an array; the date-time matches the property if 1169 it matches any of the values in the array. The properties have 1170 the following semantics: 1172 * byMonth: the date-time is in the given month. 1174 * byWeekNo: the date-time is in the nth week of the year. 1175 Negative numbers mean the nth last week of the year. This 1176 corresponds to weeks according to week numbering as defined in 1177 ISO.8601.2004, with a week defined as a seven day period, 1178 starting on the firstDayOfWeek property value or Monday if 1179 omitted. Week number one of the calendar year is the first 1180 week that contains at least four days in that calendar year. 1182 If the date-time is not valid (this may happen when generating 1183 candidates with a skip property in effect), it is always 1184 eliminated by this property. 1186 * byYearDay: the date-time is on the nth day of year. Negative 1187 numbers mean the nth last day of the year. 1189 If the date-time is not valid (this may happen when generating 1190 candidates with a skip property in effect), it is always 1191 eliminated by this property. 1193 * byMonthDay: the date-time is on the given day of the month. 1194 Negative numbers mean the nth last day of the month. 1196 * byDay: the date-time is on the given day of the week. If the 1197 day is prefixed by a number, it is the nth occurrence of that 1198 day of the week within the month (if frequency is monthly) or 1199 year (if frequency is yearly). Negative numbers means nth 1200 last occurrence within that period. 1202 * byHour: the date-time has the given hour value. 1204 * byMinute: the date-time has the given minute value. 1206 * bySecond: the date-time has the given second value. 1208 If a skip property is defined and is not "omit", there may be 1209 candidates that do not correspond to valid dates (e.g. 31st 1210 February in the gregorian calendar). In this case, the 1211 properties MUST be considered in the order above and: 1213 1. After applying the byMonth filter, if the candidate's month 1214 is invalid for the given year increment it (if skip is 1215 "forward") or decrement it (if skip is "backward") until a 1216 valid month is found, incrementing/decrementing the year as 1217 well if you pass through the beginning/end of the year. This 1218 only applies to calendar systems with leap months. 1220 2. After applying the byMonthDay filter, if the day of the month 1221 is invalid for the given month and year, change the date to 1222 the first day of the next month (if skip == "forward") or the 1223 last day of the current month (if skip == "backward"). 1225 3. If any valid date produced after applying the skip is already 1226 a candidate, eliminate the duplicate. (For example after 1227 adjusting, 30th February and 31st February would both become 1228 the same "real" date, so one is eliminated as a duplicate.) 1230 3. If a bySetPosition property is included, this is now applied to 1231 the ordered list of remaining dates. This property specifies the 1232 indexes of date-times to keep; all others should be eliminated. 1233 Negative numbers are indexes from the end of the list, with -1 1234 being the last item. 1236 4. Any date-times before the start date of the event are eliminated 1237 (see below for why this might be needed). 1239 5. If a skip property is included and is not "omit", eliminate any 1240 date-times that have already been produced by previous iterations 1241 of the algorithm. (This is not possible if skip == "omit".) 1243 6. If further dates are required (we have not reached the until 1244 date, or count limit) skip the next (interval - 1) sets of 1245 candidates, then continue from step 1. 1247 When determining the set of occurrence dates for an event or task, 1248 the following extra rules must be applied: 1250 1. The initial date-time to which the rule is applied (the "start" 1251 date-time for events; the "start" or "due" date-time for tasks) 1252 is always the first occurrence in the expansion (and is counted 1253 if the recurrence is limited by a "count" property), even if it 1254 would normally not match the rule. 1256 2. The first set of candidates to consider is that which would 1257 contain the initial date-time. This means the first set may 1258 include candidates before the initial date-time; such candidates 1259 are eliminated from the results in step (4) as outlined before. 1261 3. The following properties MUST be implicitly added to the rule 1262 under the given conditions: 1264 * If frequency is not "secondly" and no bySecond property: Add a 1265 bySecond property with the sole value being the seconds value 1266 of the initial date-time. 1268 * If frequency is not "secondly" or "minutely", and no byMinute 1269 property: Add a byMinute property with the sole value being 1270 the minutes value of the initial date-time. 1272 * If frequency is not "secondly", "minutely" or "hourly" and no 1273 byHour property: Add a byHour property with the sole value 1274 being the hours value of the initial date-time. 1276 * If frequency is "weekly" and no byDay property: Add a byDay 1277 property with the sole value being the day-of-the-week of the 1278 initial date-time. 1280 * If frequency is "monthly" and no byDay property and no 1281 byMonthDay property: Add a byMonthDay property with the sole 1282 value being the day-of-the-month of the initial date-time. 1284 * If frequency is "yearly" and no byYearDay property: 1286 + If there are no byMonth or byWeekNo properties, and either 1287 there is a byMonthDay property or there is no byDay 1288 property: Add a byMonth property with the sole value being 1289 the month of the initial date-time. 1291 + If there is no byMonthDay, byWeekNo or byDay properties: 1292 Add a byMonthDay property with the sole value being the 1293 day-of-the-month of the initial date-time. 1295 + If there is a byWeekNo property and no byMonthDay or byDay 1296 properties: Add a byDay property with the sole value being 1297 the day-of-the-week of the initial date-time. 1299 4.3.3. recurrenceOverrides 1301 Type: "LocalDateTime[PatchObject]" (optional). 1303 A map of the recurrence ids (the date-time produced by the recurrence 1304 rule) to an object of patches to apply to the generated occurrence 1305 object. 1307 If the recurrence id does not match a date-time from the recurrence 1308 rule (or no rule is specified), it is to be treated as an additional 1309 occurrence (like an RDATE from iCalendar). The patch object may 1310 often be empty in this case. 1312 If the patch object defines the "excluded" property value to be true, 1313 then the recurring calendar object does not occur at the recurrence 1314 id date-time (like an EXDATE from iCalendar). Such a patch object 1315 MUST NOT patch any other property. 1317 By default, an occurrence inherits all properties from the main 1318 object except the start (or due) date-time, which is shifted to match 1319 the recurrence id LocalDateTime. However, individual properties of 1320 the occurrence can be modified by a patch, or multiple patches. It 1321 is valid to patch the "start" property value, and this patch takes 1322 precedence over the value generated from the recurrence id. Both the 1323 recurrence id as well as the patched "start" date-time may occur 1324 before the original JSCalendar object's "start" or "due" date. 1326 A pointer in the PatchObject MUST be ignored if it starts with one of 1327 the following prefixes: 1329 o @type 1331 o method 1333 o prodId 1335 o recurrenceId 1337 o recurrenceOverrides 1338 o recurrenceRule 1340 o relatedTo 1342 o replyTo 1344 o uid 1346 4.3.4. excluded 1348 Type: "Boolean" (optional, default: false). 1350 Defines if this object is an overridden, excluded instance of a 1351 recurring JSCalendar object (see Section 4.3.3). If this property 1352 value is true, this calendar object instance MUST be removed from the 1353 occurrence expansion. The absence of this property or its default 1354 value false indicates that this instance MUST be included in the 1355 occurrence expansion. 1357 4.4. Sharing and Scheduling Properties 1359 4.4.1. priority 1361 Type: "Int" (optional, default: 0). 1363 Specifies a priority for the calendar object. This may be used as 1364 part of scheduling systems to help resolve conflicts for a time 1365 period. 1367 The priority is specified as an integer in the range 0 to 9. A value 1368 of 0 specifies an undefined priority. A value of 1 is the highest 1369 priority. A value of 2 is the second highest priority. Subsequent 1370 numbers specify a decreasing ordinal priority. A value of 9 is the 1371 lowest priority. Other integer values are reserved for future use. 1373 4.4.2. freeBusyStatus 1375 Type: "String" (optional, default: "busy"). 1377 Specifies how this property should be treated when calculating free- 1378 busy state. This MUST be one of the following values, an IANA- 1379 registered value, or a vendor-specific value: 1381 o "free": The object should be ignored when calculating whether the 1382 user is busy. 1384 o "busy": The object should be included when calculating whether the 1385 user is busy. 1387 4.4.3. privacy 1389 Type: "String" (optional, default: "public"). 1391 Calendar objects are normally collected together and may be shared 1392 with other users. The privacy property allows the object owner to 1393 indicate that it should not be shared, or should only have the time 1394 information shared but the details withheld. Enforcement of the 1395 restrictions indicated by this property are up to the API via which 1396 this object is accessed. 1398 This property MUST NOT affect the information sent to scheduled 1399 participants; it is only interpreted when the object is shared as 1400 part of a shared calendar. 1402 The value MUST be either one of the following values, an IANA- 1403 registered value, or a vendor-specific value. Any value the client 1404 or server doesn't understand should be preserved but treated as 1405 equivalent to "private". 1407 o "public": The full details of the object are visible to those whom 1408 the object's calendar is shared with. 1410 o "private": The details of the object are hidden; only the basic 1411 time and metadata is shared. The following properties MAY be 1412 shared, any other properties MUST NOT be shared: 1414 * @type 1416 * created 1418 * due 1420 * duration 1422 * estimatedDuration 1424 * freeBusyStatus 1426 * privacy 1428 * recurrenceOverrides. Only patches which apply to another 1429 permissible property are allowed to be shared. 1431 * sequence 1433 * showWithoutTime 1434 * start 1436 * timeZone 1438 * timeZones 1440 * uid 1442 * updated 1444 o "secret": The object is hidden completely (as though it did not 1445 exist) when the calendar this object is in is shared. 1447 4.4.4. replyTo 1449 Type: "String[String]" (optional). 1451 Represents methods by which participants may submit their RSVP 1452 response to the organizer of the calendar object. The keys in the 1453 property value are the available methods and MUST only contain ASCII 1454 alphanumeric characters (A-Za-z0-9). The value is a URI to use that 1455 method. Future methods may be defined in future specifications and 1456 registered with IANA; a calendar client MUST ignore any method it 1457 does not understand, but MUST preserve the method key and URI. This 1458 property MUST be omitted if no method is defined (rather than an 1459 empty object). If this property is set, the "participants" property 1460 of this calendar object MUST contain at least one participant. 1462 The following methods are defined: 1464 o "imip": The organizer accepts an iMIP [RFC6047] response at this 1465 email address. The value MUST be a "mailto:" URI. 1467 o "web": Opening this URI in a web browser will provide the user 1468 with a page where they can submit a reply to the organizer. 1470 o "other": The organizer is identified by this URI but the method 1471 how to submit the RSVP is undefined. 1473 4.4.5. participants 1475 Type: "Id[Participant]" (optional). 1477 A map of participant ids to participants, describing their 1478 participation in the calendar object. 1480 If this property is set, then the "replyTo" property of this calendar 1481 object MUST define at least one reply method. 1483 A Participant object has the following properties: 1485 o @type: "String" (mandatory) 1487 Specifies the type of this object. This MUST be "Participant". 1489 o name: "String" (optional) 1491 The display name of the participant (e.g. "Joe Bloggs"). 1493 o email: "String" (optional) 1495 The email address for the participant. 1497 o sendTo: "String[String]" (mandatory) 1499 Represents methods by which the participant may receive the 1500 invitation and updates to the calendar object. 1502 The keys in the property value are the available methods and MUST 1503 only contain ASCII alphanumeric characters (A-Za-z0-9). The value 1504 is a URI to use that method. Future methods may be defined in 1505 future specifications and registered with IANA; a calendar client 1506 MUST ignore any method it does not understand, but MUST preserve 1507 the method key and URI. This property MUST be omitted if no 1508 method is defined (rather than an empty object). 1510 The following methods are defined: 1512 * "imip": The participant accepts an iMIP [RFC6047] request at 1513 this email address. The value MUST be a "mailto:" URI. It MAY 1514 be different from the value of the participant's "email" 1515 property. 1517 * "other": The participant is identified by this URI but the 1518 method how to submit the invitation or update is undefined. 1520 o kind: "String" (optional) 1522 What kind of entity this participant is, if known. 1524 This MUST be either one of the following values, an IANA- 1525 registered value, or a vendor-specific value. Any value the 1526 client or server doesn't understand should be treated the same as 1527 if this property is omitted. 1529 * "individual": a single person 1530 * "group": a collection of people invited as a whole 1532 * "resource": a non-human resource, e.g. a projector 1534 * "location": a physical location involved in the calendar object 1535 that needs to be scheduled, e.g. a conference room. 1537 o roles: "String[Boolean]" (mandatory) 1539 A set of roles that this participant fulfills. 1541 At least one role MUST be specified for the participant. The keys 1542 in the set MUST be either one of the following values, an IANA- 1543 registered value, or a vendor-specific value: 1545 * "owner": The participant is an owner of the object. This 1546 signifies they have permission to make changes to it that 1547 affect the other participants. Non-owner participants may only 1548 change properties that just affect themself (for example 1549 setting their own alerts). 1551 * "attendee": The participant is an attendee of the calendar 1552 object. 1554 * "chair": The participant is in charge of the calendar object 1555 when it occurs. 1557 The value for each key in the set MUST be true. Roles that are 1558 unknown to the implementation MUST be preserved. 1560 o locationId: "String" (optional) 1562 The location at which this participant is expected to be 1563 attending. 1565 If the value does not correspond to any location id in the 1566 "locations" property of the JSCalendar object, this MUST be 1567 treated the same as if the participant's locationId were omitted. 1569 o participationStatus: "String" (optional, default: "needs-action") 1571 The participation status, if any, of this participant. 1573 The value MUST be either one of the following values, an IANA- 1574 registered value, or a vendor-specific value: 1576 * "needs-action": No status yet set by the participant. 1578 * "accepted": The invited participant will participate. 1580 * "declined": The invited participant will not participate. 1582 * "tentative": The invited participant may participate. 1584 o participationComment: "String" (optional) 1586 A note from the participant to explain their participation status. 1588 o attendance: "String" (optional, default: "required") 1590 The required attendance of this participant. 1592 The value MUST be either one of the following values, an IANA- 1593 registered value, or a vendor-specific value. Any value the 1594 client or server doesn't understand should be treated the same as 1595 "required". 1597 * "none": Indicates a participant who is copied for information 1598 purposes only. 1600 * "optional": Indicates a participant whose attendance is 1601 optional. 1603 * "required": Indicates a participant whose attendance is 1604 required. 1606 o expectReply: "Boolean" (optional, default: false) 1608 If true, the organizer is expecting the participant to notify them 1609 of their participation status. 1611 o scheduleSequence: "UnsignedInt" (optional, default: 0) 1613 The sequence number of the last response from the participant. If 1614 defined, this MUST be a non-negative integer. 1616 This can be used to determine whether the participant has sent a 1617 new RSVP following significant changes to the calendar object, and 1618 to determine if future responses are responding to a current or 1619 older view of the data. 1621 o scheduleUpdated: "UTCDateTime" (optional) 1623 The "updated" property of the last iTIP response from the 1624 participant. 1626 This can be compared to the "updated" property timestamp in future 1627 iTIP responses to determine if the response is older or newer than 1628 the current data. 1630 o invitedBy: "String" (optional) 1632 The participant id of the participant who invited this one, if 1633 known. 1635 o delegatedTo: "String[Boolean]" (optional) 1637 A set of participant ids that this participant has delegated their 1638 participation to. Each key in the set MUST be the id of a 1639 participant. The value for each key in the set MUST be true. 1640 This MUST be omitted if none (rather than an empty set). 1642 o delegatedFrom: "String[Boolean]" (optional) 1644 A set of participant ids that this participant is acting as a 1645 delegate for. Each key in the set MUST be the id of a 1646 participant. The value for each key in the set MUST be true. 1647 This MUST be omitted if none (rather than an empty set). 1649 o memberOf: "String[Boolean]" (optional) 1651 A set of group participants that were invited to this calendar 1652 object, which caused this participant to be invited due to their 1653 membership of the group(s). Each key in the set MUST be the id of 1654 a participant. The value for each key in the set MUST be true. 1655 This MUST be omitted if none (rather than an empty set). 1657 o linkIds: "String[Boolean]" (optional) 1659 A set of links to more information about this participant, for 1660 example in vCard format. The keys in the set MUST be the id of a 1661 Link object in the calendar object's "links" property. The value 1662 for each key in the set MUST be true. This MUST be omitted if 1663 none (rather than an empty set). 1665 4.5. Alerts Properties 1667 4.5.1. useDefaultAlerts 1669 Type: "Boolean" (optional, default: false). 1671 If true, use the user's default alerts and ignore the value of the 1672 "alerts" property. Fetching user defaults is dependent on the API 1673 from which this JSCalendar object is being fetched, and is not 1674 defined in this specification. If an implementation cannot determine 1675 the user's default alerts, or none are set, it MUST process the 1676 alerts property as if "useDefaultAlerts" is set to false. 1678 4.5.2. alerts 1680 Type: "Id[Alert]" (optional). 1682 A map of alert ids to Alert objects, representing alerts/reminders to 1683 display or send to the user for this calendar object. 1685 An Alert Object has the following properties: 1687 o @type: "String" (mandatory) 1689 Specifies the type of this object. This MUST be "Alert". 1691 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" 1693 Defines when to trigger the alert. New types may be defined in 1694 future RFCs. 1696 An *OffsetTrigger* object has the following properties: 1698 * @type: "String" (mandatory) 1700 Specifies the type of this object. This MUST be 1701 "OffsetTrigger". 1703 * offset: "SignedDuration" (mandatory). 1705 Defines the offset at which to trigger the alert relative to 1706 the time property defined in the "relativeTo" property of the 1707 alert. If the calendar object does not define a time zone, the 1708 user's default time zone SHOULD be used when determining the 1709 offset, if known. Otherwise, the time zone to use is 1710 implementation specific. 1712 * relativeTo: "String" (optional, default: "start") 1714 Specifies the time property that the alert offset is relative 1715 to. The value MUST be one of: 1717 + "start": triggers the alert relative to the start of the 1718 calendar object 1720 + "end": triggers the alert relative to the end/due time of 1721 the calendar object 1723 An *AbsoluteTrigger* object has the following properties: 1725 * @type: "String" (mandatory) 1727 Specifies the type of this object. This MUST be 1728 "AbsoluteTrigger". 1730 * when: "UTCDateTime" (mandatory). 1732 Defines a specific UTC date-time when the alert is triggered. 1734 An *UnknownTrigger* object is an object that contains a *@type* 1735 property whose value is not recognized (i.e., not "OffsetTrigger" 1736 or "AbsoluteTrigger"), plus zero or more other properties. This 1737 is for compatibility with client extensions and future RFCs. 1738 Implementations SHOULD NOT trigger for trigger types they do not 1739 understand, but MUST preserve them. 1741 o acknowledged: "UTCDateTime" (optional) 1743 This records when an alert was last acknowledged. This is set 1744 when the user has dismissed the alert; other clients that sync 1745 this property SHOULD automatically dismiss or suppress duplicate 1746 alerts (alerts with the same alert id that triggered on or before 1747 this date-time). 1749 For a recurring calendar object, the "acknowledged" property of 1750 the parent object MUST be updated, unless the alert is already 1751 overridden in the "recurrenceOverrides" property. 1753 Certain kinds of alert action may not provide feedback as to when 1754 the user sees them, for example email based alerts. For those 1755 kinds of alerts, this property SHOULD be set immediately when the 1756 alert is triggered and the action successfully carried out. 1758 o relatedTo: "String[Relation]" (optional) 1760 Relates this alert to other alerts in the same JSCalendar object. 1761 If the user wishes to snooze an alert, the application SHOULD 1762 create an alert to trigger after snoozing. All snooze alerts 1763 SHOULD set a relation to the identifier of the original alert. 1764 The Relation object SHOULD set the "parent" relation type, but MAY 1765 be empty. 1767 o action: "String" (optional, default: "display") 1769 Describes how to alert the user. 1771 The value MUST be at most one of the following values, an IANA- 1772 registered value, or a vendor-specific value: 1774 * "display": The alert should be displayed as appropriate for the 1775 current device and user context. 1777 * "email": The alert should trigger an email sent out to the 1778 user, notifying about the alert. This action is typically only 1779 appropriate for server implementations. 1781 4.6. Multilingual Properties 1783 4.6.1. localizations 1785 Type: "String[PatchObject]" (optional). 1787 A map of [RFC5646] language tags to patch objects, which localize the 1788 calendar object into the locale of the respective language tag. 1790 See the description of PatchObject (Section 1.4.8) for the structure 1791 of the PatchObject. The patches are applied to the top-level 1792 calendar object. In addition, the "locale" property of the patched 1793 object is set to the language tag. All pointers for patches MUST end 1794 with one of the following suffixes; any patch that does not follow 1795 this MUST be ignored unless otherwise specified in a future RFC: 1797 o title 1799 o description 1801 o name 1803 For example, a patch to "recurrenceOverrides/2018-01- 1804 05T14:00:00/locations/abcd1234/title" is permissible, but a patch to 1805 "uid" is not. 1807 Note that this specification does not define how to maintain validity 1808 of localized content. For example, a client application changing a 1809 JSCalendar object's title property might also need to update any 1810 localizations of this property. Client implementations SHOULD 1811 provide the means to manage localizations, but how to achieve this is 1812 specific to the application's workflow and requirements. 1814 4.7. Time Zone Properties 1815 4.7.1. timeZone 1817 Type: "String|null" (optional, default: null). 1819 Identifies the time zone the object is scheduled in, or null for 1820 floating time. This is either a name from the IANA Time Zone 1821 Database [4] or the id of a custom time zone from the "timeZones" 1822 property (see Section 1.4.9). If omitted, this MUST be presumed to 1823 be null (i.e., floating time). 1825 4.7.2. timeZones 1827 Type: "String[TimeZone]" (optional). 1829 Maps identifiers of custom time zones to their time zone definition. 1830 The following restrictions apply for each key in the map: 1832 o It MUST start with the "/" character (ASCII decimal 47; also see 1833 Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion 1834 of the forward slash character in time zone identifiers). 1836 o It MUST be a valid "paramtext" value as specified in Section 3.1. 1837 of [RFC5545]. 1839 o At least one other property in the same JSCalendar object MUST 1840 reference a time zone using this identifier (i.e. orphaned time 1841 zones are not allowed). 1843 An identifier need only be unique to this JSCalendar object. 1845 A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545] 1846 and the semantics are as defined there. A valid time zone MUST 1847 define at least one transition rule in the "standard" or "daylight" 1848 property. Its properties are: 1850 o @type: "String" (mandatory) 1852 Specifies the type of this object. This MUST be "TimeZone". 1854 o tzId: "String" (mandatory). 1856 The TZID property from iCalendar. 1858 o lastModified: "UTCDateTime" (optional) 1860 The LAST-MODIFIED property from iCalendar. 1862 o url: "String" (optional) 1863 The TZURL property from iCalendar. 1865 o validUntil: "UTCDateTime" (optional) 1867 The TZUNTIL property from iCalendar specified in [RFC7808]. 1869 o aliases: "String[Boolean]" (optional) 1871 Maps the TZID-ALIAS-OF properties from iCalendar specified in 1872 [RFC7808] to a JSON set of aliases. The set is represented as an 1873 object, with the keys being the aliases. The value for each key 1874 in the set MUST be true. 1876 o standard: "TimeZoneRule[]" (optional) 1878 The STANDARD sub-components from iCalendar. The order MUST be 1879 preserved during conversion. 1881 o daylight: "TimeZoneRule[]" (optional). 1883 The DAYLIGHT sub-components from iCalendar. The order MUST be 1884 preserved during conversion. 1886 A TimeZoneRule object maps a STANDARD or DAYLIGHT sub-component from 1887 iCalendar, with the restriction that at most one recurrence rule is 1888 allowed per rule. It has the following properties: 1890 o @type: "String" (mandatory) 1892 Specifies the type of this object. This MUST be "TimeZoneRule". 1894 o start: "LocalDateTime" (mandatory) 1896 The DTSTART property from iCalendar. 1898 o offsetTo: "String" (mandatory) 1900 The TZOFFSETTO property from iCalendar. 1902 o offsetFrom: "String" (mandatory) 1904 The TZOFFSETFROM property from iCalendar. 1906 o recurrenceRule: "RecurrenceRule" (optional) 1908 The RRULE property mapped as specified in Section 4.3.2. During 1909 recurrence rule evaluation, the "until" property value MUST be 1910 interpreted as a local time in the UTC time zone. 1912 o recurrenceDates: "LocalDateTime[Boolean]" (optional) 1914 Maps the RDATE properties from iCalendar to a JSON set. The set 1915 is represented as an object, with the keys being the recurrence 1916 dates. The value for each key in the set MUST be true. 1918 o names: "String[Boolean]" (optional) 1920 Maps the TZNAME properties from iCalendar to a JSON set. The set 1921 is represented as an object, with the keys being the names. The 1922 value for each key in the set MUST be true. 1924 o comments: "String[]" (optional). Maps the COMMENT properties from 1925 iCalendar. The order MUST be preserved during conversion. 1927 5. Type-specific JSCalendar Properties 1929 5.1. JSEvent Properties 1931 In addition to the common JSCalendar object properties (Section 4) a 1932 JSEvent has the following properties: 1934 5.1.1. start 1936 Type: "LocalDateTime" (mandatory). 1938 The date/time the event starts in the event's time zone (as specified 1939 in the "timeZone" property, see Section 4.7.1). 1941 5.1.2. duration 1943 Type: "Duration" (optional, default: "PT0S"). 1945 The zero or positive duration of the event in the event's start time 1946 zone. 1948 Note that a duration specified using weeks or days does not always 1949 correspond to an exact multiple of 24 hours. The number of 1950 hours/minutes/seconds may vary if it overlaps a period of 1951 discontinuity in the event's time zone, for example a change from 1952 standard time to daylight-savings time. Leap seconds MUST NOT be 1953 considered when computing an exact duration. When computing an exact 1954 duration, the greatest order time components MUST be added first, 1955 that is, the number of days MUST be added first, followed by the 1956 number of hours, number of minutes, and number of seconds. 1957 Fractional seconds MUST be added last. These semantics match the 1958 iCalendar DURATION value type ([RFC5545], Section 3.3.6). 1960 A JSEvent MAY involve start and end locations that are in different 1961 time zones (e.g. a trans-continental flight). This can be expressed 1962 using the "relativeTo" and "timeZone" properties of the JSEvent's 1963 Location objects (see Section 4.2.5). 1965 5.1.3. status 1967 Type: "String" (optional, default: "confirmed"). 1969 The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be 1970 one of the following values, an IANA-registered value, or a vendor- 1971 specific value: 1973 o "confirmed": Indicates the event is definitely happening. 1975 o "cancelled": Indicates the event has been cancelled. 1977 o "tentative": Indicates the event may happen. 1979 5.2. JSTask Properties 1981 In addition to the common JSCalendar object properties (Section 4) a 1982 JSTask has the following properties: 1984 5.2.1. due 1986 Type: "LocalDateTime" (optional). 1988 The date/time the task is due in the task's time zone. 1990 5.2.2. start 1992 Type: "LocalDateTime" (optional). 1994 The date/time the task should start in the task's time zone. 1996 5.2.3. estimatedDuration 1998 Type: "Duration" (optional). 2000 Specifies the estimated positive duration of time the task takes to 2001 complete. 2003 5.2.4. statusUpdatedAt 2005 Type: "UTCDateTime" (optional). 2007 Specifies the date/time the "status" property of either the task 2008 overall (Section 5.2.6) or a specific participant (Section 5.2.5) was 2009 last updated. 2011 If the task is recurring and has future instances, a client may want 2012 to keep track of the last status update timestamp of a specific task 2013 recurrence, but leave other instances unchanged. One way to achieve 2014 this is by overriding the statusUpdatedAt property in the task 2015 "recurrenceOverrides" property. However, this could produce a long 2016 list of timestamps for regularly recurring tasks. An alternative 2017 approach is to split the JSTask into a current, single instance of 2018 JSTask with this instance status update time and a future recurring 2019 instance. See also Section 4.1.3 on splitting. 2021 5.2.5. progress 2023 In addition to the common properties of a Participant object 2024 (Section 4.4.5), a Participant within a JSTask supports the following 2025 property: 2027 o progress: ParticipantProgress (optional). The progress of the 2028 participant for this task, if known. This property MUST NOT be 2029 set if the "participationStatus" of this participant is any other 2030 value but "accepted". 2032 A ParticipantProgress object has the following properties: 2034 o @type: "String" (mandatory) 2036 Specifies the type of this object. This MUST be 2037 "ParticipantProgress". 2039 o status: "String" (mandatory) 2041 Describes the completion status of the participant's progress. 2043 The value MUST be at most one of the following values, an IANA- 2044 registered value, or a vendor-specific value: 2046 * "completed": The participant completed this task. 2048 * "in-process": The participant has started this task. 2050 * "failed": The participant failed to complete this task. 2052 o timestamp: "UTCDateTime" (mandatory) 2053 Represents the last time the participant progress was updated. 2055 5.2.6. status 2057 Type: "String" (optional). 2059 Defines the overall status of this task. If omitted, the default 2060 status (Section 4.4) of a JSTask is defined as follows (in order of 2061 evaluation): 2063 o "completed": if the "status" property value of all participant 2064 progresses is "completed". 2066 o "failed": if at least one "status" property value of the 2067 participant progresses is "failed". 2069 o "in-process": if at least one "status" property value of the 2070 participant progresses is "in-process". 2072 o "needs-action": If none of the other criteria match. 2074 If set, it MUST be one of the following values, an IANA-registered 2075 value, or a vendor-specific value: 2077 o "needs-action": Indicates the task needs action. 2079 o "completed": Indicates the task is completed. 2081 o "in-process": Indicates the task is in process. 2083 o "cancelled": Indicates the task is cancelled. 2085 o "pending": Indicates the task has been created and accepted for 2086 processing, but not yet started. 2088 o "failed": Indicates the task failed. 2090 5.3. JSGroup Properties 2092 JSGroup supports the following common JSCalendar properties 2093 (Section 4): 2095 o @type 2097 o categories 2099 o color 2100 o created 2102 o description 2104 o descriptionContentType 2106 o keywords 2108 o links 2110 o prodId 2112 o title 2114 o updated 2116 o uid 2118 In addition, the following JSGroup-specific properties are supported: 2120 5.3.1. entries 2122 Type: "String[JSTask|JSEvent]" (mandatory). 2124 A collection of group members. This is represented as a map of the 2125 "uid" property value to the JSCalendar object member having that uid. 2126 Implementations MUST ignore entries of unknown type. 2128 5.3.2. source 2130 Type: "String" (optional). 2132 The source from which updated versions of this group may be retrieved 2133 from. The value MUST be a URI. 2135 6. Examples 2137 The following examples illustrate several aspects of the JSCalendar 2138 data model and format. The examples may omit mandatory or additional 2139 properties, which is indicated by a placeholder property with key 2140 "...". While most of the examples use calendar event objects, they 2141 are also illustrative for tasks. 2143 6.1. Simple event 2145 This example illustrates a simple one-time event. It specifies a 2146 one-time event that begins on January 15, 2018 at 1pm New York local 2147 time and ends after 1 hour. 2149 { 2150 "@type": "jsevent", 2151 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2152 "updated": "2018-01-15T18:00:00Z", 2153 "title": "Some event", 2154 "start": "2018-01-15T13:00:00", 2155 "timeZone": "America/New_York", 2156 "duration": "PT1H" 2157 } 2159 6.2. Simple task 2161 This example illustrates a simple task for a plain to-do item. 2163 { 2164 "@type": "jstask", 2165 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2166 "updated": "2018-01-15T18:00:00Z", 2167 "title": "Do something" 2168 } 2170 6.3. Simple group 2172 This example illustrates a simple calendar object group that contains 2173 an event and a task. 2175 { 2176 "@type": "jsgroup", 2177 "uid": "2a358cee-6489-4f14-a57f-c104db4dc343", 2178 "updated": "2018-01-15T18:00:00Z", 2179 "name": "A simple group", 2180 "entries": [ 2181 { 2182 "@type": "jsevent", 2183 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2184 "updated": "2018-01-15T18:00:00Z", 2185 "title": "Some event", 2186 "start": "2018-01-15T13:00:00", 2187 "timeZone": "America/New_York", 2188 "duration": "PT1H" 2189 }, 2190 { 2191 "@type": "jstask", 2192 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2193 "updated": "2018-01-15T18:00:00Z", 2194 "title": "Do something" 2195 } 2196 ] 2197 } 2199 6.4. All-day event 2201 This example illustrates an event for an international holiday. It 2202 specifies an all-day event on April 1 that occurs every year since 2203 the year 1900. 2205 { 2206 "...": "", 2207 "title": "April Fool's Day", 2208 "showWithoutTime": true, 2209 "start": "1900-04-01T00:00:00", 2210 "duration": "P1D", 2211 "recurrenceRule": { 2212 "@type": "RecurrenceRule", 2213 "frequency": "yearly" 2214 } 2215 } 2217 6.5. Task with a due date 2219 This example illustrates a task with a due date. It is a reminder to 2220 buy groceries before 6pm Vienna local time on January 19, 2018. The 2221 calendar user expects to need 1 hour for shopping. 2223 { 2224 "...": "", 2225 "title": "Buy groceries", 2226 "due": "2018-01-19T18:00:00", 2227 "timeZone": "Europe/Vienna", 2228 "estimatedDuration": "PT1H" 2229 } 2231 6.6. Event with end time-zone 2233 This example illustrates the use of end time-zones by use of an 2234 international flight. The flight starts on April 1, 2018 at 9am in 2235 Berlin local time. The duration of the flight is scheduled at 10 2236 hours 30 minutes. The time at the flights destination is in the same 2237 time-zone as Tokyo. Calendar clients could use the end time-zone to 2238 display the arrival time in Tokyo local time and highlight the time- 2239 zone difference of the flight. The location names can serve as input 2240 for navigation systems. 2242 { 2243 "...": "", 2244 "title": "Flight XY51 to Tokyo", 2245 "start": "2018-04-01T09:00:00", 2246 "timeZone": "Europe/Berlin", 2247 "duration": "PT10H30M", 2248 "locations": { 2249 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2250 "@type": "Location", 2251 "rel": "start", 2252 "name": "Frankfurt Airport (FRA)" 2253 }, 2254 "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { 2255 "@type": "Location", 2256 "rel": "end", 2257 "name": "Narita International Airport (NRT)", 2258 "timeZone": "Asia/Tokyo" 2259 } 2260 } 2261 } 2263 6.7. Floating-time event (with recurrence) 2265 This example illustrates the use of floating-time. Since January 1, 2266 2018, a calendar user blocks 30 minutes every day to practice Yoga at 2267 7am local time, in whatever time-zone the user is located on that 2268 date. 2270 { 2271 "...": "", 2272 "title": "Yoga", 2273 "start": "2018-01-01T07:00:00", 2274 "duration": "PT30M", 2275 "recurrenceRule": { 2276 "@type": "RecurrenceRule", 2277 "frequency": "daily" 2278 } 2279 } 2281 6.8. Event with multiple locations and localization 2283 This example illustrates an event that happens at both a physical and 2284 a virtual location. Fans can see a live convert on premises or 2285 online. The event title and descriptions are localized. 2287 { 2288 "...": "", 2289 "title": "Live from Music Bowl: The Band", 2290 "description": "Go see the biggest music event ever!", 2291 "locale": "en", 2292 "start": "2018-07-04T17:00:00", 2293 "timeZone": "America/New_York", 2294 "duration": "PT3H", 2295 "locations": { 2296 "c0503d30-8c50-4372-87b5-7657e8e0fedd": { 2297 "@type": "Location", 2298 "name": "The Music Bowl", 2299 "description": "Music Bowl, Central Park, New York", 2300 "coordinates": "geo:40.7829,73.9654" 2301 } 2302 }, 2303 "virtualLocations": { 2304 "6f3696c6-1e07-47d0-9ce1-f50014b0041a": { 2305 "@type": "VirtualLocation", 2306 "name": "Free live Stream from Music Bowl", 2307 "uri": "https://stream.example.com/the_band_2018" 2308 } 2309 }, 2310 "localizations": { 2311 "de": { 2312 "title": "Live von der Music Bowl: The Band!", 2313 "description": "Schau dir das groesste Musikereignis an!", 2314 "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name": 2315 "Gratis Live-Stream aus der Music Bowl" 2316 } 2317 } 2318 } 2320 6.9. Recurring event with overrides 2322 This example illustrates the use of recurrence overrides. A math 2323 course at a University is held for the first time on January 8, 2018 2324 at 9am London time and occurs every week until June 25, 2018. Each 2325 lecture lasts for one hour and 30 minutes and is located at the 2326 Mathematics department. This event has exceptional occurrences: at 2327 the last occurrence of the course is an exam, which lasts for 2 hours 2328 and starts at 10am. Also, the location of the exam differs from the 2329 usual location. On April 2 no course is held. On January 5 at 2pm 2330 is an optional introduction course, that occurs before the first 2331 regular lecture. 2333 { 2334 "...": "", 2335 "title": "Calculus I", 2336 "start": "2018-01-08T09:00:00", 2337 "timeZone": "Europe/London", 2338 "duration": "PT1H30M", 2339 "locations": { 2340 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2341 "@type": "Location", 2342 "title": "Math lab room 1", 2343 "description": "Math Lab I, Department of Mathematics" 2344 } 2345 }, 2346 "recurrenceRule": { 2347 "@type": "RecurrenceRule", 2348 "frequency": "weekly", 2349 "until": "2018-06-25T09:00:00" 2350 }, 2351 "recurrenceOverrides": { 2352 "2018-01-05T14:00:00": { 2353 "title": "Introduction to Calculus I (optional)" 2354 }, 2355 "2018-04-02T09:00:00": { 2356 "excluded": "true" 2357 }, 2358 "2018-06-25T09:00:00": { 2359 "title": "Calculus I Exam", 2360 "start": "2018-06-25T10:00:00", 2361 "duration": "PT2H", 2362 "locations": { 2363 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2364 "@type": "Location", 2365 "title": "Big Auditorium", 2366 "description": "Big Auditorium, Other Road" 2367 } 2368 } 2369 } 2370 } 2371 } 2373 6.10. Recurring event with participants 2375 This example illustrates scheduled events. A team meeting occurs 2376 every week since January 8, 2018 at 9am Johannesburg time. The event 2377 owner also chairs the event. Participants meet in a virtual meeting 2378 room. An attendee has accepted the invitation, but on March 8, 2018 2379 he is unavailable and declined participation for this occurrence. 2381 { 2382 "...": "", 2383 "title": "FooBar team meeting", 2384 "start": "2018-01-08T09:00:00", 2385 "timeZone": "Africa/Johannesburg", 2386 "duration": "PT1H", 2387 "virtualLocations": { 2388 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2389 "@type": "VirtualLocation", 2390 "name": "ChatMe meeting room", 2391 "uri": "https://chatme.example.com?id=1234567" 2392 } 2393 }, 2394 "recurrenceRule": { 2395 "@type": "RecurrenceRule", 2396 "frequency": "weekly" 2397 }, 2398 "replyTo": { 2399 "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com" 2400 }, 2401 "participants": { 2402 "dG9tQGZvb2Jhci5xlLmNvbQ": { 2403 "@type": "Participant", 2404 "name": "Tom Tool", 2405 "email": "tom@foobar.example.com", 2406 "sendTo": { 2407 "imip": "mailto:6489-4f14-a57f-c1@calendar.example.com" 2408 }, 2409 "participationStatus": "accepted", 2410 "roles": { 2411 "attendee": true 2412 } 2413 }, 2414 "em9lQGZvb2GFtcGxlLmNvbQ": { 2415 "@type": "Participant", 2416 "name": "Zoe Zelda", 2417 "email": "zoe@foobar.example.com", 2418 "sendTo": { 2419 "imip": "mailto:zoe@foobar.example.com" 2420 }, 2421 "participationStatus": "accepted", 2422 "roles": { 2423 "owner": true, 2424 "attendee": true, 2425 "chair": true 2426 } 2427 }, 2428 "...": "" 2430 }, 2431 "recurrenceOverrides": { 2432 "2018-03-08T09:00:00": { 2433 "participants/dG9tQGZvb2Jhci5xlLmNvbQ/participationStatus": 2434 "declined" 2435 } 2436 } 2437 } 2439 7. Security Considerations 2441 Calendaring and scheduling information is very privacy-sensitive. 2442 The transmission of such information must be careful to protect it 2443 from possible threats, such as eavesdropping, replay, message 2444 insertion, deletion, modification, and man-in-the-middle attacks. 2445 This document just defines the data format; such considerations are 2446 primarily the concern of the API or method of storage and 2447 transmission of such files. 2449 7.1. Expanding Recurrences 2451 A recurrence rule may produce infinite occurrences of an event. 2452 Implementations MUST handle expansions carefully to prevent 2453 accidental or deliberate resource exhaustion. 2455 Conversely, a recurrence rule may be specified that does not expand 2456 to anything. It is not always possible to tell this through static 2457 analysis of the rule, so implementations MUST be careful to avoid 2458 getting stuck in an infinite loop, or otherwise exhausting resources, 2459 searching for the next occurrence. 2461 7.2. JSON Parsing 2463 The Security Considerations of [RFC8259] apply to the use of JSON as 2464 the data interchange format. 2466 As for any serialization format, parsers need to thoroughly check the 2467 syntax of the supplied data. JSON uses opening and closing tags for 2468 several types and structures, and it is possible that the end of the 2469 supplied data will be reached when scanning for a matching closing 2470 tag; this is an error condition, and implementations need to stop 2471 scanning at the end of the supplied data. 2473 JSON also uses a string encoding with some escape sequences to encode 2474 special characters within a string. Care is needed when processing 2475 these escape sequences to ensure that they are fully formed before 2476 the special processing is triggered, with special care taken when the 2477 escape sequences appear adjacent to other (non-escaped) special 2478 characters or adjacent to the end of data (as in the previous 2479 paragraph). 2481 If parsing JSON into a non-textual structured data format, 2482 implementations may need to allocate storage to hold JSON string 2483 elements. Since JSON does not use explicit string lengths, the risk 2484 of denial of service due to resource exhaustion is small, but 2485 implementations may still wish to place limits on the size of 2486 allocations they are willing to make in any given context, to avoid 2487 untrusted data causing excessive memory allocation. 2489 7.3. URI Values 2491 Several JSCalendar properties contain URIs as values, and processing 2492 these properties requires extra care. Section 7 of [RFC3986] 2493 discusses security risk related to URIs. 2495 8. IANA Considerations 2497 8.1. Media Type Registration 2499 This document defines a MIME media type for use with JSCalendar data 2500 formatted in JSON. 2502 Type name: application 2504 Subtype name: jscalendar+json 2506 Required parameters: type 2508 The "type" parameter conveys the type of the JSCalendar data in 2509 the body part, with the value being one of "jsevent", "jstask", or 2510 "jsgroup". The parameter MUST NOT occur more than once. It MUST 2511 match the value of the "@type" property of the JSON-formatted 2512 JSCalendar object in the body. 2514 Optional parameters: none 2516 Encoding considerations: Same as encoding considerations of 2517 application/json as specified in RFC8529, Section 11 [RFC8259]. 2519 Security considerations: See Section 7 of this document. 2521 Interoperability considerations: This media type provides an 2522 alternative to iCalendar, jCal and proprietary JSON-based 2523 calendaring data formats. 2525 Published specification: This specification. 2527 Applications that use this media type: Applications that currently 2528 make use of the text/calendar and application/calendar+json media 2529 types can use this as an alternative. Similarly, applications 2530 that use the application/json media type to transfer calendaring 2531 data can use this to further specify the content. 2533 Fragment identifier considerations: N/A 2535 Additional information: 2537 Magic number(s): N/A 2539 File extensions(s): N/A 2541 Macintosh file type code(s): N/A 2543 Person & email address to contact for further information: 2544 calext@ietf.org 2546 Intended usage: COMMON 2548 Restrictions on usage: N/A 2550 Author: See the "Author's Address" section of this document. 2552 Change controller: IETF 2554 8.2. Creation of "JSCalendar Properties" Registry 2556 The IANA will create the "JSCalendar Properties" registry to allow 2557 interoperability of extensions to JSCalendar objects. 2559 This registry follows the expert review process unless the "intended 2560 use" field is "common", in which case registration follows the 2561 specification required process. Preliminary community review for 2562 this registry is optional but strongly encouraged. 2564 A registration can have an intended use of "common", "reserved", or 2565 "obsolete". The IANA will list common-use registrations prominently 2566 and separately from those with other intended use values. 2568 A "reserved" registration reserves a property name without assigning 2569 semantics to avoid name collisions with future extensions or protocol 2570 use. 2572 An "obsolete" registration denotes a property that is no longer 2573 expected to be added by up-to-date systems. A new property has 2574 probably been defined covering the obsolete property's semantics. 2576 The JSCalendar property registration procedure is not a formal 2577 standards process but rather an administrative procedure intended to 2578 allow community comment and sanity checking without excessive time 2579 delay. 2581 8.2.1. Preliminary Community Review 2583 Notice of a potential new registration SHOULD be sent to the Calext 2584 mailing list for review. This mailing list is 2585 appropriate to solicit community feedback on a proposed new property. 2587 Properties registrations must be marked with their intended use: 2588 "common", "reserved" or "obsolete". 2590 The intent of the public posting to this list is to solicit comments 2591 and feedback on the choice of the property name, the unambiguity of 2592 the specification document, and a review of any interoperability or 2593 security considerations. The submitter may submit a revised 2594 registration proposal or abandon the registration completely at any 2595 time. 2597 8.2.2. Submit Request to IANA 2599 Registration requests can be sent to . 2601 8.2.3. Designated Expert Review 2603 The primary concern of the designated expert (DE) is preventing name 2604 collisions and encouraging the submitter to document security and 2605 privacy considerations; a published specification is not required. 2606 For a common-use registration, the DE is expected to confirm that 2607 suitable documentation, as described in Section 4.6 of [RFC8126], is 2608 available. The DE should also verify that the property name does not 2609 conflict with work that is active or already published within the 2610 IETF. 2612 Before a period of 30 days has passed, the DE will either approve or 2613 deny the registration request and publish a notice of the decision to 2614 the Calext WG mailing list or its successor, as well as inform IANA. 2615 A denial notice must be justified by an explanation, and, in the 2616 cases where it is possible, concrete suggestions on how the request 2617 can be modified so as to become acceptable should be provided. 2619 If the DE does not respond within 30 days, the registrant may request 2620 the IESG take action to process the request in a timely manner. 2622 8.2.4. Change Procedures 2624 Once a JSCalendar property has been published by the IANA, the change 2625 controller may request a change to its definition. The same 2626 procedure that would be appropriate for the original registration 2627 request is used to process a change request. 2629 JSCalendar property registrations may not be deleted; properties that 2630 are no longer believed appropriate for use can be declared obsolete 2631 by a change to their "intended use" field; such properties will be 2632 clearly marked in the lists published by the IANA. 2634 Significant changes to a JSCalendar property's definition should be 2635 requested only when there are serious omissions or errors in the 2636 published specification, as such changes may cause interoperability 2637 issues. When review is required, a change request may be denied if 2638 it renders entities that were valid under the previous definition 2639 invalid under the new definition. 2641 The owner of a JSCalendar property may pass responsibility to another 2642 person or agency by informing the IANA; this can be done without 2643 discussion or review. 2645 The IESG may reassign responsibility for a JSCalendar property. The 2646 most common case of this will be to enable changes to be made to a 2647 registration where the author of the registration has died, moved out 2648 of contact, or is otherwise unable to make changes that are important 2649 to the community. 2651 8.2.5. JMAP Properties Registry Template 2653 o Property Name: The name of the property. The property name MUST 2654 NOT already be registered for any of the objects listed in 2655 Context. Objects not listed in Context MAY already have 2656 registered a different property with the same name. 2658 o Property Type: The type of this property, using type signatures as 2659 specified in Section 1.3. The property type MUST be registed in 2660 the Type Registry. 2662 o Property Context: A comma-separated list of JSCalendar object 2663 types this property is allowed on. 2665 o RFC Reference: The RFC and section where the property is specified 2666 (omitted for "reserved" property names). 2668 o Intended Use: Common, reserved, or obsolete. 2670 o Change Controller: ("IETF" for Standards Track / BCP RFCs). 2672 8.2.6. Initial Contents for the JSCalendar Properties Registry 2674 The following table lists the initial entries of the JSCalendar 2675 Properties registry. All properties are for common-use. All RFC 2676 section references are for this document. The change controller for 2677 all these properties is "IETF". 2679 +--------------+----------------------------+--------------+--------+ 2680 | Property | Property Type | Property | RFC Re | 2681 | Name | | Context | ferenc | 2682 | | | | e | 2683 +--------------+----------------------------+--------------+--------+ 2684 | @type | String | JSEvent, | Sectio | 2685 | | | JSTask, | n | 2686 | | | JSGroup, Abs | 4.1.1, | 2687 | | | oluteTrigger | Sectio | 2688 | | | , Alert, | n | 2689 | | | Link, | 4.5.2, | 2690 | | | Location, Of | Sectio | 2691 | | | fsetTrigger, | n | 2692 | | | Participant, | 4.2.7, | 2693 | | | ParticipantP | Sectio | 2694 | | | rogress, Rec | n | 2695 | | | urrenceRule, | 4.2.5, | 2696 | | | Relation, | Sectio | 2697 | | | TimeZone, Vi | n | 2698 | | | rtualLocatio | 4.4.5, | 2699 | | | n | Sectio | 2700 | | | | n | 2701 | | | | 5.2.5, | 2702 | | | | Sectio | 2703 | | | | n | 2704 | | | | 4.3.2, | 2705 | | | | Sectio | 2706 | | | | n | 2707 | | | | 4.1.3, | 2708 | | | | Sectio | 2709 | | | | n | 2710 | | | | 4.7.2, | 2711 | | | | Sectio | 2712 | | | | n | 2713 | | | | 4.2.6 | 2714 | | | | | 2715 | acknowledged | UTCDateTime | Alert | Sectio | 2716 | | | | n | 2717 | | | | 4.5.2 | 2718 | | | | | 2719 | action | String | Alert | Sectio | 2720 | | | | n | 2721 | | | | 4.5.2 | 2722 | | | | | 2723 | alerts | Id[Alert] | JSEvent, | Sectio | 2724 | | | JSTask | n | 2725 | | | | 4.5.2 | 2726 | | | | | 2727 | attendance | String | Participant | Sectio | 2728 | | | | n | 2729 | | | | 4.4.5 | 2730 | | | | | 2731 | categories | String[Boolean] | JSEvent, | Sectio | 2732 | | | JSTask, | n | 2733 | | | JSGroup | 4.2.10 | 2734 | | | | | 2735 | cid | String | Link | Sectio | 2736 | | | | n | 2737 | | | | 4.2.7 | 2738 | | | | | 2739 | color | String | JSEvent, | Sectio | 2740 | | | JSTask, | n | 2741 | | | JSGroup | 4.2.11 | 2742 | | | | | 2743 | contentType | String | Link | Sectio | 2744 | | | | n | 2745 | | | | 4.2.7 | 2746 | | | | | 2747 | coordinates | String | Location | Sectio | 2748 | | | | n | 2749 | | | | 4.2.5 | 2750 | | | | | 2751 | created | UTCDateTime | JSEvent, | Sectio | 2752 | | | JSTask, | n | 2753 | | | JSGroup | 4.1.5 | 2754 | | | | | 2755 | delegatedFro | String[Boolean] | Participant | Sectio | 2756 | m | | | n | 2757 | | | | 4.4.5 | 2758 | | | | | 2759 | delegatedTo | String[Boolean] | Participant | Sectio | 2760 | | | | n | 2761 | | | | 4.4.5 | 2762 | | | | | 2763 | description | String | JSEvent, | Sectio | 2764 | | | JSTask, | n | 2765 | | | Location, Vi | 4.2.2, | 2766 | | | rtualLocatio | Sectio | 2767 | | | n | n | 2768 | | | | 4.2.5, | 2769 | | | | Sectio | 2770 | | | | n | 2771 | | | | 4.2.6 | 2772 | | | | | 2773 | descriptionC | String | JSEvent, | Sectio | 2774 | ontentType | | JSTask | n | 2775 | | | | 4.2.3 | 2776 | | | | | 2777 | display | String | Link | Sectio | 2778 | | | | n | 2779 | | | | 4.2.7 | 2780 | | | | | 2781 | due | LocalDateTime | JSTask | Sectio | 2782 | | | | n | 2783 | | | | 5.2.1 | 2784 | | | | | 2785 | duration | Duration | JSEvent | Sectio | 2786 | | | | n | 2787 | | | | 5.1.2 | 2788 | | | | | 2789 | email | String | Participant | Sectio | 2790 | | | | n | 2791 | | | | 4.4.5 | 2792 | | | | | 2793 | entries | String[JSTask|JSEvent] | JSGroup | Sectio | 2794 | | | | n | 2795 | | | | 5.3.1 | 2796 | | | | | 2797 | estimatedDur | Duration | JSTask | Sectio | 2798 | ation | | | n | 2799 | | | | 5.2.3 | 2800 | | | | | 2801 | excluded | Boolean | JSEvent, | Sectio | 2802 | | | JSTask | n | 2803 | | | | 4.3.4 | 2804 | | | | | 2805 | expectReply | Boolean | Participant | Sectio | 2806 | | | | n | 2807 | | | | 4.4.5 | 2808 | | | | | 2809 | freeBusyStat | String | JSEvent, | Sectio | 2810 | us | | JSTask | n | 2811 | | | | 4.4.2 | 2812 | | | | | 2813 | href | String | Link | Sectio | 2814 | | | | n | 2815 | | | | 4.2.7 | 2816 | | | | | 2817 | invitedBy | String | Participant | Sectio | 2818 | | | | n | 2819 | | | | 4.4.5 | 2820 | | | | | 2821 | keywords | String[Boolean] | JSEvent, | Sectio | 2822 | | | JSTask, | n | 2823 | | | JSGroup | 4.2.9 | 2824 | | | | | 2825 | kind | String | Participant | Sectio | 2826 | | | | n | 2827 | | | | 4.4.5 | 2828 | | | | | 2829 | linkIds | Id[Boolean] | Location, | Sectio | 2830 | | | Participant | n | 2831 | | | | 4.2.5, | 2832 | | | | Sectio | 2833 | | | | n | 2834 | | | | 4.4.5 | 2835 | | | | | 2836 | localization | String[PatchObject] | JSEvent, | Sectio | 2837 | s | | JSTask | n | 2838 | | | | 4.6.1 | 2839 | | | | | 2840 | locationId | String | Participant | Sectio | 2841 | | | | n | 2842 | | | | 4.4.5 | 2843 | | | | | 2844 | locations | Id[Location] | JSEvent, | Sectio | 2845 | | | JSTask | n | 2846 | | | | 4.2.5 | 2847 | | | | | 2848 | memberOf | String[Boolean] | Participant | Sectio | 2849 | | | | n | 2850 | | | | 4.4.5 | 2851 | | | | | 2852 | method | String | JSEvent, | Sectio | 2853 | | | JSTask | n | 2854 | | | | 4.1.8 | 2855 | | | | | 2856 | name | String | Location, | Sectio | 2857 | | | Participant | n | 2858 | | | | 4.2.5, | 2859 | | | | Sectio | 2860 | | | | n | 2861 | | | | 4.4.5 | 2862 | | | | | 2863 | offset | SignedDuration | OffsetTrigge | Sectio | 2864 | | | r | n | 2865 | | | | 4.5.2 | 2866 | | | | | 2867 | participants | Id[Participant] | JSEvent, | Sectio | 2868 | | | JSTask | n | 2869 | | | | 4.4.5 | 2870 | | | | | 2871 | participatio | String | Participant | Sectio | 2872 | nComment | | | n | 2873 | | | | 4.4.5 | 2874 | | | | | 2875 | participatio | String | Participant | Sectio | 2876 | nStatus | | | n | 2877 | | | | 4.4.5 | 2878 | | | | | 2879 | priority | Int | JSEvent, | Sectio | 2880 | | | JSTask | n | 2881 | | | | 4.4.1 | 2882 | | | | | 2883 | privacy | String | JSEvent, | Sectio | 2884 | | | JSTask | n | 2885 | | | | 4.4.3 | 2886 | | | | | 2887 | prodId | String | JSEvent, | Sectio | 2888 | | | JSTask, | n | 2889 | | | JSGroup | 4.1.4 | 2890 | | | | | 2891 | recurrenceId | LocalDateTime | JSEvent, | Sectio | 2892 | | | JSTask | n | 2893 | | | | 4.3.1 | 2894 | | | | | 2895 | recurrenceOv | LocalDateTime[PatchObject] | JSEvent, | Sectio | 2896 | errides | | JSTask | n | 2897 | | | | 4.3.3 | 2898 | | | | | 2899 | recurrenceRu | RecurrenceRule | JSEvent, | Sectio | 2900 | le | | JSTask | n | 2901 | | | | 4.3.2 | 2902 | | | | | 2903 | rel | String | Link | Sectio | 2904 | | | | n | 2905 | | | | 4.2.7 | 2906 | | | | | 2907 | relatedTo | String[Relation] | JSEvent, | Sectio | 2908 | | | JSTask, | n | 2909 | | | Alert | 4.1.3, | 2910 | | | | Sectio | 2911 | | | | n | 2912 | | | | 4.5.2 | 2913 | | | | | 2914 | relation | String[Boolean] | Relation | Sectio | 2915 | | | | n | 2916 | | | | 1.4.10 | 2917 | | | | | 2918 | relativeTo | String | OffsetTrigge | Sectio | 2919 | | | r, Location | n | 2920 | | | | 4.5.2, | 2921 | | | | Sectio | 2922 | | | | n | 2923 | | | | 4.2.5 | 2924 | | | | | 2925 | replyTo | String[String] | JSEvent, | Sectio | 2926 | | | JSTask | n | 2927 | | | | 4.4.4 | 2928 | | | | | 2929 | roles | String[Boolean] | Participant | Sectio | 2930 | | | | n | 2931 | | | | 4.4.5 | 2932 | | | | | 2933 | scheduleSequ | UnsignedInt | Participant | Sectio | 2934 | ence | | | n | 2935 | | | | 4.4.5 | 2936 | | | | | 2937 | scheduleUpda | UTCDateTime | Participant | Sectio | 2938 | ted | | | n | 2939 | | | | 4.4.5 | 2940 | | | | | 2941 | sendTo | String[String] | Participant | Sectio | 2942 | | | | n | 2943 | | | | 4.4.5 | 2944 | | | | | 2945 | sequence | UnsignedInt | JSEvent, | Sectio | 2946 | | | JSTask | n | 2947 | | | | 4.1.7 | 2948 | | | | | 2949 | showWithoutT | Boolean | JSEvent, | Sectio | 2950 | ime | | JSTask | n | 2951 | | | | 4.2.4 | 2952 | | | | | 2953 | size | UnsignedInt | Link | Sectio | 2954 | | | | n | 2955 | | | | 4.2.7 | 2956 | | | | | 2957 | start | LocalDateTime | JSEvent, | Sectio | 2958 | | | JSTask | n | 2959 | | | | 5.1.1, | 2960 | | | | Sectio | 2961 | | | | n | 2962 | | | | 5.2.2 | 2963 | | | | | 2964 | status | String | ParticipantP | Sectio | 2965 | | | rogress | n | 2966 | | | | 5.2.5 | 2967 | | | | | 2968 | statusUpdate | UTCDateTime | JSTask | Sectio | 2969 | dAt | | | n | 2970 | | | | 5.2.4 | 2971 | | | | | 2972 | source | String | JSGroup | Sectio | 2973 | | | | n | 2974 | | | | 5.3.2 | 2975 | | | | | 2976 | status | String | JSEvent, | Sectio | 2977 | | | JSTask | n | 2978 | | | | 5.1.3, | 2979 | | | | Sectio | 2980 | | | | n | 2981 | | | | 5.2.6 | 2982 | | | | | 2983 | timestamp | UTCDateTime | ParticipantP | Sectio | 2984 | | | rogress | n | 2985 | | | | 5.2.5 | 2986 | | | | | 2987 | timeZone | String|null | JSEvent, | Sectio | 2988 | | | JSTask, | n | 2989 | | | Location | 4.7.1, | 2990 | | | | Sectio | 2991 | | | | n | 2992 | | | | 4.2.5 | 2993 | | | | | 2994 | timeZones | String[TimeZone] | JSEvent, | Sectio | 2995 | | | JSTask | n | 2996 | | | | 4.7.2 | 2997 | | | | | 2998 | title | String | JSEvent, | Sectio | 2999 | | | JSTask, | n | 3000 | | | JSGroup, | 4.2.1 | 3001 | | | Link | | 3002 | | | | | 3003 | trigger | OffsetTrigger|AbsoluteTrig | Alert | Sectio | 3004 | | ger|UnknownTrigger | | n | 3005 | | | | 4.5.2 | 3006 | | | | | 3007 | uid | String | JSEvent, | Sectio | 3008 | | | JSTask, | n | 3009 | | | JSGroup | 4.1.2 | 3010 | | | | | 3011 | updated | UTCDateTime | JSEvent, | Sectio | 3012 | | | JSTask, | n | 3013 | | | JSGroup | 4.1.6 | 3014 | | | | | 3015 | useDefaultAl | Boolean | JSEvent, | Sectio | 3016 | erts | | JSTask | n | 3017 | | | | 4.5.1 | 3018 | | | | | 3019 | virtualLocat | Id[VirtualLocation] | JSEvent, | Sectio | 3020 | ions | | JSTask | n | 3021 | | | | 4.2.6 | 3022 | | | | | 3023 | when | UTCDateTime | AbsoluteTrig | Sectio | 3024 | | | ger | n | 3025 | | | | 4.5.2 | 3026 +--------------+----------------------------+--------------+--------+ 3028 Table 1 3030 8.3. Creation of "JSCalendar Types" Registry 3032 The IANA will create the "JSCalendar Types" registry to avoid name 3033 collisions and provide a complete reference for all data types used 3034 for JSCalendar property values. The registration process is the same 3035 as for the JSCalendar Properties registry, as defined in Section 8.2. 3037 8.3.1. JMAP Types Registry Template 3039 o Type Name: The name of the type. 3041 o RFC Reference: The RFC and section where the Type is specified 3042 (may be omitted for "reserved" type names). 3044 o Intended Use: Common, reserved, or obsolete. 3046 o Change Controller: ("IETF" for Standards Track / BCP RFCs). 3048 8.3.2. Initial Contents for the JSCalendar Properties Registry 3050 The following table lists the initial entries of the JSCalendar Types 3051 registry. All properties are for common-use. All RFC section 3052 references are for this document. The change controller for all 3053 these properties is "IETF". 3055 +---------------------+----------------+ 3056 | Type Name | RFC Reference | 3057 +---------------------+----------------+ 3058 | Alert | Section 4.5.2 | 3059 | | | 3060 | Boolean | Section 1.3 | 3061 | | | 3062 | Duration | Section 1.4.5 | 3063 | | | 3064 | Id | Section 1.4.7 | 3065 | | | 3066 | Int | Section 1.4.1 | 3067 | | | 3068 | LocalDateTime | Section 1.4.4 | 3069 | | | 3070 | Link | Section 4.2.7 | 3071 | | | 3072 | Location | Section 4.2.5 | 3073 | | | 3074 | Number | Section 1.3 | 3075 | | | 3076 | Participant | Section 4.4.5 | 3077 | | | 3078 | ParticipantProgress | Section 5.2.5 | 3079 | | | 3080 | PatchObject | Section 1.4.8 | 3081 | | | 3082 | RecurrenceRule | Section 4.3.2 | 3083 | | | 3084 | Relation | Section 1.4.10 | 3085 | | | 3086 | SignedDuration | Section 1.4.6 | 3087 | | | 3088 | String | Section 1.3 | 3089 | | | 3090 | TimeZone | Section 4.7.2 | 3091 | | | 3092 | TimeZoneRule | Section 4.7.2 | 3093 | | | 3094 | UnsignedInt | Section 1.4.2 | 3095 | | | 3096 | UTCDateTime | Section 1.4.3 | 3097 | | | 3098 | VirtualLocation | Section 4.2.6 | 3099 +---------------------+----------------+ 3101 Table 2 3103 8.4. Creation of "JSCalendar Enum Values" Registry 3105 The IANA will create the "JSCalendar Enum Values" registry to allow 3106 interoperable extension of semantics for properties with enumerable 3107 values. Each such property will have a subregistry of allowed 3108 values. The registration process for creating a new subregistry is 3109 the same as for the JSCalendar Properties registry. The registration 3110 process for a new enum value is the same but is only subject to 3111 expert review; a specification is not required for a new allowed 3112 value in an existing enum property where a simple description will 3113 suffice. 3115 8.4.1. JMAP Enum Subregistry Creation Template 3117 This template is for adding a new subregistry to the JMAP Enum 3118 registry. 3120 o Property Name: The name(s) of the property or properties where 3121 these values may be used. This MUST be registered in the 3122 JSCalendar Properties registry. 3124 o Property Context: The allowed object types where the property or 3125 properties may appear, as registered in the JSCalendar Properties 3126 registry. This disambiguates where there may be two distinct 3127 properties with the same name in different contexts. 3129 o Change Controller: ("IETF" for Standards Track / BCP RFCs). 3131 o Values: The list of defined values for this enum, using the 3132 template defined in Section 8.4.2. 3134 8.4.2. JMAP Enum Subregistry Creation Template 3136 This template is for adding a new enum value to a subregistry in the 3137 JMAP Enum registry. When registering a new value for an existing 3138 enum, the property name and context MUST be submitted with the 3139 registration to identify the appropriate subregistry. 3141 o Enum Value: The verbatim value of the enum. 3143 o Description: A brief description or RFC and section reference for 3144 the semantics of this value. 3146 8.4.3. Initial Contents for the JSCalendar Enum Registry 3148 All RFC section references are for this document. 3150 ------------------------------------------------------------ 3151 Property Name: action 3153 Property Context: Alert 3155 Change Controller: IETF 3157 +------------+---------------+ 3158 | Enum Value | Description | 3159 +------------+---------------+ 3160 | display | Section 4.5.2 | 3161 | | | 3162 | email | Section 4.5.2 | 3163 +------------+---------------+ 3165 Table 3 3167 ------------------------------------------------------------ 3169 Property Name: attendance 3171 Property Context: Participant 3173 Change Controller: IETF 3175 +------------+---------------+ 3176 | Enum Value | Description | 3177 +------------+---------------+ 3178 | none | Section 4.4.5 | 3179 | | | 3180 | optional | Section 4.4.5 | 3181 | | | 3182 | required | Section 4.4.5 | 3183 +------------+---------------+ 3185 Table 4 3187 ------------------------------------------------------------ 3189 Property Name: display 3191 Property Context: Link 3193 Change Controller: IETF 3194 +------------+---------------+ 3195 | Enum Value | Description | 3196 +------------+---------------+ 3197 | badge | Section 4.2.7 | 3198 | | | 3199 | graphic | Section 4.2.7 | 3200 | | | 3201 | fullsize | Section 4.2.7 | 3202 | | | 3203 | thumbnail | Section 4.2.7 | 3204 +------------+---------------+ 3206 Table 5 3208 ------------------------------------------------------------ 3210 Property Name: freeBusyStatus 3212 Property Context: JSEvent, JSTask 3214 Change Controller: IETF 3216 +------------+---------------+ 3217 | Enum Value | Description | 3218 +------------+---------------+ 3219 | free | Section 4.4.2 | 3220 | | | 3221 | busy | Section 4.4.2 | 3222 +------------+---------------+ 3224 Table 6 3226 ------------------------------------------------------------ 3228 Property Name: kind 3230 Property Context: Participant 3232 Change Controller: IETF 3233 +------------+---------------+ 3234 | Enum Value | Description | 3235 +------------+---------------+ 3236 | individual | Section 4.4.5 | 3237 | | | 3238 | group | Section 4.4.5 | 3239 | | | 3240 | resource | Section 4.4.5 | 3241 | | | 3242 | location | Section 4.4.5 | 3243 +------------+---------------+ 3245 Table 7 3247 ------------------------------------------------------------ 3249 Property Name: participationStatus 3251 Property Context: Participant 3253 Change Controller: IETF 3255 +--------------+---------------+ 3256 | Enum Value | Description | 3257 +--------------+---------------+ 3258 | needs-action | Section 4.4.5 | 3259 | | | 3260 | accepted | Section 4.4.5 | 3261 | | | 3262 | declined | Section 4.4.5 | 3263 | | | 3264 | tenative | Section 4.4.5 | 3265 +--------------+---------------+ 3267 Table 8 3269 ------------------------------------------------------------ 3271 Property Name: privacy 3273 Property Context: JSEvent, JSTask 3275 Change Controller: IETF 3276 +------------+---------------+ 3277 | Enum Value | Description | 3278 +------------+---------------+ 3279 | public | Section 4.4.3 | 3280 | | | 3281 | private | Section 4.4.3 | 3282 | | | 3283 | secret | Section 4.4.3 | 3284 +------------+---------------+ 3286 Table 9 3288 ------------------------------------------------------------ 3290 Property Name: progress 3292 Property Context: ParticipantProgress 3294 Change Controller: IETF 3296 +------------+---------------+ 3297 | Enum Value | Description | 3298 +------------+---------------+ 3299 | completed | Section 5.2.5 | 3300 | | | 3301 | in-process | Section 5.2.5 | 3302 | | | 3303 | failed | Section 5.2.5 | 3304 +------------+---------------+ 3306 Table 10 3308 ------------------------------------------------------------ 3310 Property Name: relation 3312 Property Context: Relation 3314 Change Controller: IETF 3315 +------------+----------------+ 3316 | Enum Value | Description | 3317 +------------+----------------+ 3318 | first | Section 1.4.10 | 3319 | | | 3320 | next | Section 1.4.10 | 3321 | | | 3322 | child | Section 1.4.10 | 3323 | | | 3324 | parent | Section 1.4.10 | 3325 +------------+----------------+ 3327 Table 11 3329 ------------------------------------------------------------ 3331 Property Name: relativeTo 3333 Property Context: OffsetTrigger, Location 3335 Change Controller: IETF 3337 +------------+---------------+ 3338 | Enum Value | Description | 3339 +------------+---------------+ 3340 | start | Section 4.5.2 | 3341 | | | 3342 | end | Section 4.5.2 | 3343 +------------+---------------+ 3345 Table 12 3347 ------------------------------------------------------------ 3349 Property Name: roles 3351 Property Context: Participant 3353 Change Controller: IETF 3354 +------------+---------------+ 3355 | Enum Value | Description | 3356 +------------+---------------+ 3357 | owner | Section 4.4.5 | 3358 | | | 3359 | attendee | Section 4.4.5 | 3360 | | | 3361 | chair | Section 4.4.5 | 3362 +------------+---------------+ 3364 Table 13 3366 ------------------------------------------------------------ 3368 Property Name: status 3370 Property Context: JSEvent 3372 Change Controller: IETF 3374 +------------+---------------+ 3375 | Enum Value | Description | 3376 +------------+---------------+ 3377 | confirmed | Section 5.1.3 | 3378 | | | 3379 | cancelled | Section 5.1.3 | 3380 | | | 3381 | tentative | Section 5.1.3 | 3382 +------------+---------------+ 3384 Table 14 3386 ------------------------------------------------------------ 3388 Property Name: status 3390 Property Context: JSTask 3392 Change Controller: IETF 3393 +------------+---------------+ 3394 | Enum Value | Description | 3395 +------------+---------------+ 3396 | completed | Section 5.2.6 | 3397 | | | 3398 | failed | Section 5.2.6 | 3399 | | | 3400 | in-process | Section 5.2.6 | 3401 | | | 3402 | cancelled | Section 5.2.6 | 3403 | | | 3404 | pending | Section 5.2.6 | 3405 | | | 3406 | failed | Section 5.2.6 | 3407 +------------+---------------+ 3409 Table 15 3411 9. Acknowledgments 3413 The authors would like to thank the members of CalConnect for their 3414 valuable contributions. This specification originated from the work 3415 of the API technical committee of CalConnect, the Calendaring and 3416 Scheduling Consortium. 3418 10. References 3420 10.1. Normative References 3422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3423 Requirement Levels", BCP 14, RFC 2119, 3424 DOI 10.17487/RFC2119, March 1997, 3425 . 3427 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 3428 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 3429 . 3431 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 3432 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 3433 . 3435 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3436 Resource Identifier (URI): Generic Syntax", STD 66, 3437 RFC 3986, DOI 10.17487/RFC3986, January 2005, 3438 . 3440 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 3441 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3442 DOI 10.17487/RFC4122, July 2005, 3443 . 3445 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3446 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3447 . 3449 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 3450 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 3451 DOI 10.17487/RFC4791, March 2007, 3452 . 3454 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 3455 Scheduling Core Object Specification (iCalendar)", 3456 RFC 5545, DOI 10.17487/RFC5545, September 2009, 3457 . 3459 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 3460 Interoperability Protocol (iTIP)", RFC 5546, 3461 DOI 10.17487/RFC5546, December 2009, 3462 . 3464 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 3465 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 3466 September 2009, . 3468 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 3469 Identifier for Geographic Locations ('geo' URI)", 3470 RFC 5870, DOI 10.17487/RFC5870, June 2010, 3471 . 3473 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 3474 Interoperability Protocol (iMIP)", RFC 6047, 3475 DOI 10.17487/RFC6047, December 2010, 3476 . 3478 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 3479 Specifications and Registration Procedures", BCP 13, 3480 RFC 6838, DOI 10.17487/RFC6838, January 2013, 3481 . 3483 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 3484 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 3485 DOI 10.17487/RFC6901, April 2013, 3486 . 3488 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 3489 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 3490 2014, . 3492 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 3493 DOI 10.17487/RFC7493, March 2015, 3494 . 3496 [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules 3497 in the Internet Calendaring and Scheduling Core Object 3498 Specification (iCalendar)", RFC 7529, 3499 DOI 10.17487/RFC7529, May 2015, 3500 . 3502 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 3503 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 3504 . 3506 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 3507 DOI 10.17487/RFC7986, October 2016, 3508 . 3510 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3511 Writing an IANA Considerations Section in RFCs", BCP 26, 3512 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3513 . 3515 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3516 Interchange Format", STD 90, RFC 8259, 3517 DOI 10.17487/RFC8259, December 2017, 3518 . 3520 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 3521 DOI 10.17487/RFC8288, October 2017, 3522 . 3524 10.2. Informative References 3526 [MIME] "IANA Media Types", . 3529 10.3. URIs 3531 [1] https://www.iana.org/time-zones 3533 [2] https://www.iana.org/assignments/link-relations/link- 3534 relations.xhtml 3536 [3] https://www.w3.org/TR/2011/REC-css3-color-20110607/#svg-color 3538 [4] https://www.iana.org/time-zones 3540 Authors' Addresses 3542 Neil Jenkins 3543 Fastmail 3544 PO Box 234 3545 Collins St West 3546 Melbourne VIC 8007 3547 Australia 3549 Email: neilj@fastmailteam.com 3550 URI: https://www.fastmail.com 3552 Robert Stepanek 3553 Fastmail 3554 PO Box 234 3555 Collins St West 3556 Melbourne VIC 8007 3557 Australia 3559 Email: rsto@fastmailteam.com 3560 URI: https://www.fastmail.com