idnits 2.17.1 draft-ietf-calext-jscalendar-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2019) is 1871 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 2677 -- Looks like a reference, but probably isn't: '2' on line 2679 -- Looks like a reference, but probably isn't: '3' on line 2682 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Calendaring extensions N. Jenkins 3 Internet-Draft R. Stepanek 4 Intended status: Standards Track FastMail 5 Expires: September 6, 2019 March 5, 2019 7 JSCalendar: A JSON representation of calendar data 8 draft-ietf-calext-jscalendar-12 10 Abstract 12 This specification defines a data model and JSON representation of 13 calendar data that can be used for storage and data exchange in a 14 calendaring and scheduling environment. It aims to be an alternative 15 to the widely deployed iCalendar data format and to be unambiguous, 16 extendable and simple to process. In contrast to the JSON-based jCal 17 format, it is not a direct mapping from iCalendar and expands 18 semantics where appropriate. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 6, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Relation to the iCalendar format . . . . . . . . . . . . 5 56 1.2. Relation to the jCal format . . . . . . . . . . . . . . . 5 57 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 5 58 2. JSCalendar objects . . . . . . . . . . . . . . . . . . . . . 6 59 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Structure of JSCalendar objects . . . . . . . . . . . . . . . 6 63 3.1. Type signatures . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. UTCDate . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.2. LocalDate . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2.3. Duration . . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.4. PatchObject . . . . . . . . . . . . . . . . . . . . . 8 69 3.2.5. Identifiers . . . . . . . . . . . . . . . . . . . . . 9 70 3.2.6. Time Zones . . . . . . . . . . . . . . . . . . . . . 9 71 3.2.7. Normalization and equivalence . . . . . . . . . . . . 10 72 3.3. Custom property extensions and values . . . . . . . . . . 10 73 4. Common JSCalendar properties . . . . . . . . . . . . . . . . 10 74 4.1. Metadata properties . . . . . . . . . . . . . . . . . . . 11 75 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 13 82 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 13 83 4.2. What and where properties . . . . . . . . . . . . . . . . 13 84 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 13 86 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 13 87 4.2.4. locations . . . . . . . . . . . . . . . . . . . . . . 14 88 4.2.5. virtualLocations . . . . . . . . . . . . . . . . . . 15 89 4.2.6. links . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.2.7. locale . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.2.8. keywords . . . . . . . . . . . . . . . . . . . . . . 16 92 4.2.9. categories . . . . . . . . . . . . . . . . . . . . . 17 93 4.2.10. color . . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.3. Recurrence properties . . . . . . . . . . . . . . . . . . 17 95 4.3.1. recurrenceRule . . . . . . . . . . . . . . . . . . . 17 96 4.3.2. recurrenceOverrides . . . . . . . . . . . . . . . . . 23 97 4.3.3. excluded . . . . . . . . . . . . . . . . . . . . . . 24 98 4.4. Sharing and scheduling properties . . . . . . . . . . . . 24 99 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 24 100 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 25 101 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 25 102 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 26 103 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 26 104 4.5. Alerts properties . . . . . . . . . . . . . . . . . . . . 30 105 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 30 106 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 30 107 4.6. Multilingual properties . . . . . . . . . . . . . . . . . 31 108 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 31 109 4.7. Time zone properties . . . . . . . . . . . . . . . . . . 33 110 4.7.1. timeZones . . . . . . . . . . . . . . . . . . . . . . 33 111 5. Type-specific JSCalendar properties . . . . . . . . . . . . . 34 112 5.1. JSEvent properties . . . . . . . . . . . . . . . . . . . 34 113 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 34 114 5.1.2. timeZone . . . . . . . . . . . . . . . . . . . . . . 34 115 5.1.3. duration . . . . . . . . . . . . . . . . . . . . . . 35 116 5.1.4. isAllDay . . . . . . . . . . . . . . . . . . . . . . 35 117 5.1.5. status . . . . . . . . . . . . . . . . . . . . . . . 35 118 5.2. JSTask properties . . . . . . . . . . . . . . . . . . . . 36 119 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 36 120 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 36 121 5.2.3. timeZone . . . . . . . . . . . . . . . . . . . . . . 36 122 5.2.4. estimatedDuration . . . . . . . . . . . . . . . . . . 36 123 5.2.5. statusUpdatedAt . . . . . . . . . . . . . . . . . . . 36 124 5.2.6. isAllDay . . . . . . . . . . . . . . . . . . . . . . 37 125 5.2.7. progress . . . . . . . . . . . . . . . . . . . . . . 37 126 5.2.8. status . . . . . . . . . . . . . . . . . . . . . . . 38 127 5.3. JSGroup properties . . . . . . . . . . . . . . . . . . . 38 128 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 39 129 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 39 130 6. Conversion from and to iCalendar . . . . . . . . . . . . . . 39 131 6.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 39 132 6.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 40 133 6.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 41 134 6.4. Common properties . . . . . . . . . . . . . . . . . . . . 42 135 6.5. Locations and participants . . . . . . . . . . . . . . . 44 136 6.6. Unknown properties . . . . . . . . . . . . . . . . . . . 47 137 7. JSCalendar object examples . . . . . . . . . . . . . . . . . 47 138 7.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 47 139 7.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 48 140 7.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 48 141 7.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 48 142 7.5. Task with a due date . . . . . . . . . . . . . . . . . . 49 143 7.6. Event with end time-zone . . . . . . . . . . . . . . . . 49 144 7.7. Floating-time event (with recurrence) . . . . . . . . . . 50 145 7.8. Event with multiple locations and localization . . . . . 50 146 7.9. Recurring event with overrides . . . . . . . . . . . . . 51 147 7.10. Recurring event with participants . . . . . . . . . . . . 52 148 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 149 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 150 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 151 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 152 11.1. Normative References . . . . . . . . . . . . . . . . . . 55 153 11.2. Informative References . . . . . . . . . . . . . . . . . 57 154 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 58 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 157 1. Introduction 159 This document defines a data model for calendar event and task 160 objects, or groups of such objects, in electronic calendar 161 applications and systems. It aims to be unambiguous, extendable and 162 simple to process. 164 The key design considerations for this data model are as follows: 166 o The attributes of the calendar entry represented must be described 167 as a simple key-value pair, reducing complexity of its 168 representation. 170 o The data model should avoid all ambiguities and make it difficult 171 to make mistakes during implementation. 173 o Most of the initial set of attributes should be taken from the 174 iCalendar data format ([RFC5545], also see Section 1.1), but the 175 specification should add new attributes or value types, or not 176 support existing ones, where appropriate. Conversion between the 177 data formats need not fully preserve semantic meaning. 179 o Extensions, such as new properties and components, MUST NOT lead 180 to requiring an update to this document. 182 The representation of this data model is defined in the I-JSON format 183 [RFC7493], which is a strict subset of the JavaScript Object Notation 184 (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a 185 pragmatic choice: its widespread use makes JSCalendar easier to 186 adopt, and the ready availability of production-ready JSON 187 implementations eliminates a whole category of parser-related 188 interoperability issues. 190 1.1. Relation to the iCalendar format 192 The iCalendar data format [RFC5545], a widely deployed interchange 193 format for calendaring and scheduling data, has served calendaring 194 vendors for a long while, but contains some ambiguities and pitfalls 195 that can not be overcome without backward-incompatible changes. 197 For example, iCalendar defines various formats for local times, UTC 198 time and dates, which confuses new users. Other sources for errors 199 are the requirement for custom time zone definitions within a single 200 calendar component, as well as the iCalendar format itself; the 201 latter causing interoperability issues due to misuse of CR LF 202 terminated strings, line continuations and subtle differences between 203 iCalendar parsers. Lastly, up until recently the iCalendar format 204 did not have a way to express a concise difference between two 205 calendar components, which results in verbose exchanges during 206 scheduling. 208 1.2. Relation to the jCal format 210 The JSON format for iCalendar data, jCal [RFC7265], is a direct 211 mapping between iCalendar and JSON. It does not attempt to extend or 212 update iCalendar semantics, and consequently does not address the 213 issues outlined in Section 1.1. 215 Since the standardization of jCal, the majority of implementations 216 and service providers either kept using iCalendar, or came up with 217 their own proprietary JSON representation, which often are 218 incompatible with each other. JSCalendar is intended to meet this 219 demand for JSON formatted calendar data, and to provide a standard 220 representation as an alternative to new proprietary formats. 222 1.3. Notational Conventions 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in [RFC2119]. 228 The underlying format used for this specification is JSON. 229 Consequently, the terms "object" and "array" as well as the four 230 primitive types (strings, numbers, booleans, and null) are to be 231 interpreted as described in Section 1 of [RFC8259]. 233 Some examples in this document contain "partial" JSON documents used 234 for illustrative purposes. In these examples, three periods "..." 235 are used to indicate a portion of the document that has been removed 236 for compactness. In this document, property and object definitions 237 are formatted like *this* and are referred to in other sections like 238 _this_. Verbatim text is formatted like "this". 240 2. JSCalendar objects 242 This section describes the calendar object types specified by 243 JSCalendar. 245 2.1. JSEvent 247 MIME type: "application/jscalendar+json;type=jsevent" 249 A JSEvent represents a scheduled amount of time on a calendar, 250 typically a meeting, appointment, reminder or anniversary. Multiple 251 participants may partake in the event at multiple locations. 253 The @type (Section 4.1.1) property value MUST be "jsevent". 255 2.2. JSTask 257 MIME type: "application/jscalendar+json;type=jstask" 259 A JSTask represents an action-item, assignment, to-do or work item . 261 The @type (Section 4.1.1) property value MUST be "jstask". 263 A JSTask may start and be due at certain points in time, may take 264 some estimated time to complete and may recur; none of which is 265 required. This notably differs from JSEvent (Section 2.1) which is 266 required to start at a certain point in time and typically takes some 267 non-zero duration to complete. 269 2.3. JSGroup 271 MIME type: "application/jscalendar+json;type=jsgroup" 273 A JSGroup is a collection of JSEvent (Section 2.1) and JSTask 274 (Section 2.2) objects. Typically, objects are grouped by topic (e.g. 275 by keywords) or calendar membership. 277 The @type (Section 4.1.1) property value MUST be "jsgroup". 279 3. Structure of JSCalendar objects 281 A JSCalendar object is a JSON object, which MUST be valid I-JSON (a 282 stricter subset of JSON), as specified in [RFC8259]. Property names 283 and values are case-sensitive. 285 The object has a collection of properties, as specified in the 286 following sections. Unless otherwise specified, all properties are 287 mandatory. Optional properties may have a default value, if 288 explicitly specified in the property definition. 290 3.1. Type signatures 292 Types signatures are given for all JSON objects in this document. 293 The following conventions are used: 295 o "Boolean|String": The value is either a JSON "Boolean" value, or a 296 JSON "String" value. 298 o "Foo": Any name that is not a native JSON type means an object for 299 which the properties (and their types) are defined elsewhere 300 within this document. 302 o "Foo[]": An array of objects of type "Foo". 304 o "String[Foo]": A JSON "Object" being used as a map (associative 305 array), where all the values are of type "Foo". 307 3.2. Data Types 309 In addition to the standard JSON data types, the following data types 310 are used in this specification: 312 3.2.1. UTCDate 314 This is a string in [RFC3339] "date-time" format, with the further 315 restrictions that any letters MUST be in upper-case, the time 316 component MUST be included and the time MUST be in UTC. Fractional 317 second values MUST NOT be included unless non-zero and MUST NOT have 318 trailing zeros, to ensure there is only a single representation for 319 each date-time. 321 For example "2010-10-10T10:10:10.003Z" is OK, but 322 "2010-10-10T10:10:10.000Z" is invalid and MUST be encoded as 323 "2010-10-10T10:10:10Z". 325 In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". 327 3.2.2. LocalDate 329 This is a date-time string _with no time zone/offset information_. 330 It is otherwise in the same format as UTCDate: "YYYY-MM-DDTHH:MM:SS". 331 The time zone to associate the LocalDate with comes from an 332 associated property, or if no time zone is associated it defines 333 _floating time_. Floating date-times are not tied to any specific 334 time zone. Instead, they occur in every time zone at the same _wall- 335 clock_ time (as opposed to the same instant point in time). 337 3.2.3. Duration 339 A *Duration* is represented by a subset of ISO8601 duration format, 340 as specified by the following ABNF: 342 dur-secfrac = "." 1*DIGIT 343 dur-second = 1*DIGIT [dur-secfrac] "S" 344 dur-minute = 1*DIGIT "M" [dur-second] 345 dur-hour = 1*DIGIT "H" [dur-minute] 346 dur-time = "T" (dur-hour / dur-minute / dur-second) 347 dur-day = 1*DIGIT "D" 348 dur-week = 1*DIGIT "W" 350 duration = "P" (dur-day [dur-time] / dur-time / dur-week) 352 In addition, the duration MUST NOT include fractional second values 353 unless the fraction is non-zero. 355 A *SignedDuration* is represented as a duration, optionally preceeded 356 by a sign character. It typically is used to express the offset of a 357 point in time relative to an associated time. It is specified by the 358 following ABNF: 360 signed-duration = (["+"] / "-") duration 362 A negative sign indicates a point in time at or _before_ the 363 associated time, a positive or no sign a time at or _after_ the 364 associated time. 366 3.2.4. PatchObject 368 A *PatchObject* is of type "String[*|null]", and represents an 369 unordered set of patches on a JSON object. The keys are a path in a 370 subset of [RFC6901] JSON pointer format, with an implicit leading "/" 371 (i.e. prefix each key with "/" before applying the JSON pointer 372 evaluation algorithm). 374 A patch within a PatchObject is only valid, if all of the following 375 conditions apply: 377 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT 378 insert/delete from an array; the array MUST be replaced in its 379 entirety instead). 381 2. When evaluating a path, all parts prior to the last (i.e. the 382 value after the final slash) MUST exist. 384 3. There MUST NOT be two patches in the PatchObject where the 385 pointer of one is the prefix of the pointer of the other, e.g. 386 "alerts/foo/offset" and "alerts". 388 The value associated with each pointer is either: 390 o "null": Remove the property from the patched object. If not 391 present in the parent, this a no-op. 393 o Anything else: The value to replace the inherited property on the 394 patch object with (if present) or add to the property (if not 395 present). 397 Implementations MUST reject a PatchObject if any of its patches are 398 invalid. 400 3.2.5. Identifiers 402 If not stated otherwise in the respective property definition, 403 properties and object keys that define identifiers MUST be string 404 values, MUST be at least 1 character and maximum 256 characters in 405 size, and MUST only contain characters from the "URL and Filename 406 safe" Base 64 Alphabet, as defined in section 5 of [RFC4648]. This 407 is the ASCII alphanumeric characters (A-Za-z0-9), hyphen (-), and 408 underscore (_). Note that [RFC7493] requires string values be 409 encoded in UTF-8, so the maximum size of an identifier according to 410 this definition is 256 octets. 412 . Identifiers in object maps need not be universally unique, e.g. two 413 calendar objects MAY use the same identifiers in their respective 414 _links_ properties. 416 Nevertheless, a UUID typically is a good choice. 418 3.2.6. Time Zones 420 By default, time zones in JSCalendar are identified by their name in 421 the IANA Time Zone Database [1], and the zone rules of the respective 422 zone record apply. 424 Implementations MAY embed the definition of custom time zones in the 425 _timeZones_ property (see Section 4.7.1). 427 3.2.7. Normalization and equivalence 429 JSCalendar aims to provide unambiguous definitions for value types 430 and properties, but does not define a general normalization or 431 equivalence method for JSCalendar objects and types. This is because 432 the notion of equivalence might range from byte-level equivalence to 433 semantic equivalence, depending on the respective use case (for 434 example, the CalDAV protocol [RFC4791] requires octet equivalence of 435 the encoded calendar object to determine ETag equivalence). 437 Normalization of JSCalendar objects is hindered because of the 438 following reasons: 440 o Custom JSCalendar properties may contain arbitrary JSON values, 441 including arrays. However, equivalence of arrays might or might 442 not depend on the order of elements, depending on the respective 443 property definition. 445 o Several JSCalendar property values are defined as URIs and MIME 446 types, but normalization of these types is inherently protocol and 447 scheme-specific, depending on the use-case of the equivalence 448 definition (see section 6 of [RFC3986]). 450 Considering this, the definition of equivalence and normalization is 451 left to client and server implementations and to be negotiated by a 452 calendar exchange protocol or defined by another RFC. 454 3.3. Custom property extensions and values 456 Vendors MAY add additional properties to the calendar object to 457 support their custom features. The names of these properties MUST be 458 prefixed with a domain name controlled by the vendor to avoid 459 conflict, e.g. "example.com/customprop". 461 Some JSCalendar properties allow vendor-specific value extensions. 462 If so, vendor specific values MUST be prefixed with a domain name 463 controlled by the vendor, e.g. "example.com/customrel", unless 464 otherwise noted. 466 4. Common JSCalendar properties 468 This section describes the properties that are common to the various 469 JSCalendar object types. Specific JSCalendar object types may only 470 support a subset of these properties. The object type definitions in 471 Section 5 describe the set of supported properties per type. 473 4.1. Metadata properties 475 4.1.1. @type 477 Type: "String" 479 Specifies the type which this object represents. This MUST be one of 480 the following values, registered in a future RFC, or a vendor- 481 specific value: 483 o "jsevent": a JSCalendar event (Section 2.1). 485 o "jstask": a JSCalendar task (Section 2.2). 487 o "jsgroup": a JSCalendar group (Section 2.3). 489 A valid JSCalendar object MUST include this property. 491 4.1.2. uid 493 Type: "String" 495 A globally unique identifier, used to associate the object as the 496 same across different systems, calendars and views. The value of 497 this property MUST be unique across _all_ JSCalendar objects, even if 498 they are of different type. [RFC4122] describes a range of 499 established algorithms to generate universally unique identifiers 500 (UUID), and the random or pseudo-random version is recommended. 502 For compatibility with [RFC5545] UIDs, implementations MUST be able 503 to receive and persist values of at least 255 octets for this 504 property, but they MUST NOT truncate values in the middle of a UTF-8 505 multi-octet sequence. 507 A valid JSCalendar object MUST include this property. 509 4.1.3. relatedTo 511 Type: "String[Relation]" (optional) 513 Relates the object to other JSCalendar objects. This is represented 514 as a map of the UIDs of the related objects to information about the 515 relation. 517 A *Relation* object has the following properties: 519 o *relation*: "String[Boolean]" (optional) Describes how the linked 520 object is related to this object as a set of relation types. If 521 not null, the set MUST NOT be empty. 523 Keys in the set MUST be one of the following values, defined in a 524 future specification or a vendor-specific value: 526 * "first": The linked object is the first in the series this 527 object is part of. 529 * "next": The linked object is the next in the series this object 530 is part of. 532 * "child": The linked object is a subpart of this object. 534 * "parent": This object is part of the overall linked object. 536 The value for each key in the set MUST be "true". 538 If an object is split to make a "this and future" change to a 539 recurrence, the original object MUST be truncated to end at the 540 previous occurrence before this split, and a new object created to 541 represent all the objects after the split. A "next" relation MUST be 542 set on the original object's relatedTo property for the UID of the 543 new object. A "first" relation for the UID of the first object in 544 the series MUST be set on the new object. Clients can then follow 545 these UIDs to get the complete set of objects if the user wishes to 546 modify them all at once. 548 4.1.4. prodId 550 Type: "String" (optional) 552 The identifier for the product that created the JSCalendar object. 554 The vendor of the implementation SHOULD ensure that this is a 555 globally unique identifier, using some technique such as an FPI 556 value, as defined in [ISO.9070.1991]. It MUST only use characters of 557 an iCalendar TEXT data value (see section 3.3.11 in [RFC5545]). 559 This property SHOULD NOT be used to alter the interpretation of an 560 JSCalendar object beyond the semantics specified in this document. 561 For example, it is not to be used to further the understanding of 562 non-standard properties. 564 4.1.5. created 566 Type: "UTCDate" (optional) 568 The date and time this object was initially created. 570 4.1.6. updated 572 Type: "UTCDate" 574 The date and time the data in this object was last modified. 576 4.1.7. sequence 578 Type: "Number" (optional, default:"0") 580 Initially zero, this MUST be a non-negative integer that is 581 monotonically incremented each time a change is made to the object. 583 4.1.8. method 585 Type: "String" (optional) 587 The iTIP ([RFC5546]) method, in lower-case. Used for scheduling. 589 4.2. What and where properties 591 4.2.1. title 593 Type: "String" (optional, default:"") 595 A short summary of the object. 597 4.2.2. description 599 Type: "String" (optional, default:"") 601 A longer-form text description of the object. The content is 602 formatted according to the _descriptionContentType_ property. 604 4.2.3. descriptionContentType 606 Type: "String" (optional, default:"text/plain") 608 Describes the media type ([RFC6838]) of the contents of the 609 "description" property. Media types MUST be sub-types of type 610 "text", and SHOULD be "text/plain" or "text/html" ([MIME]). They MAY 611 define parameters and the "charset" parameter MUST be "utf-8", if 612 specified. Descriptions of type "text/html" MAY contain "cid" URLs 613 ([RFC2392]) to reference links in the calendar object by use of the 614 _cid_ property of the _Link_ object. 616 4.2.4. locations 618 Type: "String[Location]" (optional) 620 A map of location identifiers to Location objects, representing 621 locations associated with the object. 623 A *Location* object has the following properties. It must define at 624 least one other property than _rel_. 626 o *name*: "String" (optional, default:"") The human-readable name of 627 the location. 629 o *description*: "String" (optional) Human-readable, plain-text 630 instructions for accessing this location. This may be an address, 631 set of directions, door access code, etc. 633 o *rel*: "String" (optional) The relation type of this location to 634 the JSCalendar object. 636 This MUST be either one of the following values, registered in a 637 future RFC, or a vendor-specific value. Any value the client or 638 server doesn't understand should be treated the same as if this 639 property is omitted. 641 * "start": The JSCalendar object starts at this location. 643 * "end": The JSCalendar object ends at this location. 645 o *timeZone*: "String" (optional) A time zone for this location. 646 Also see Section 3.2.6. 648 o *coordinates*: "String" (optional) An [RFC5870] "geo:" URI for the 649 location. 651 o *linkIds*: "String[Boolean]" (optional) A set of link ids for 652 links to alternate representations of this location. Each key in 653 the set MUST be the identifier of a Link object defined in the 654 _links_ property of this calendar object. The value for each key 655 in the set MUST be "true". This MUST be omitted if none (rather 656 than an empty set). 658 For example, an alternative representation could be in vCard 659 format. 661 4.2.5. virtualLocations 663 Type: "String[VirtualLocation]" (optional) 665 A map of identifiers to VirtualLocation objects, representing virtual 666 locations, such as video conferences or chat rooms, associated with 667 the object. 669 A *VirtualLocation* object has the following properties. 671 o *name*: "String" (optional, default:"") The human-readable name of 672 the virtual location. 674 o *description*: "String" (optional) Human-readable plain-text 675 instructions for accessing this location. This may be an address, 676 set of directions, door access code, etc. 678 o *uri*: "String" A URI that represents how to connect to this 679 virtual location. 681 This may be a telephone number (represented as 682 "tel:+1-555-555-555") for a teleconference, a web address for 683 online chat, or any custom URI. 685 4.2.6. links 687 Type: "String[Link]" (optional) 689 A map of link identifiers to Link objects, representing external 690 resources associated with the object. 692 A *Link* object has the following properties: 694 o *href*: "String" A URI from which the resource may be fetched. 696 This MAY be a "data:" URL, but it is recommended that the file be 697 hosted on a server to avoid embedding arbitrarily large data in 698 JSCalendar object instances. 700 o *cid* "String" (optional) This MUST be a valid "content-id" value 701 according to the definition of section 2 in [RFC2392]. The 702 identifier MUST be unique within this JSCalendar object Link 703 objects but has no meaning beyond that. Specifically, it MAY be 704 different from the link identifier in the enclosing _links_ 705 property. 707 o *type*: "String" (optional) The content-type [RFC6838] of the 708 resource, if known. 710 o *size*: "Number" (optional) The size, in bytes, of the resource 711 when fully decoded (i.e. the number of bytes in the file the user 712 would download), if known. 714 o *rel*: "String" (optional) Identifies the relation of the linked 715 resource to the object. If set, the value MUST be a registered 716 relation type (see [RFC8288] and IANA Link Relations [2]). 718 Links with a rel of "enclosure" SHOULD be considered by the client 719 as attachments for download. 721 Links with a rel of "describedby" SHOULD be considered by the 722 client to be an alternate representation of the description. 724 Links with a rel of "icon" SHOULD be considered by the client to 725 be an image that it MAY use when presenting the calendar data to a 726 user. The _display_ property MAY be set to indicate the purpose 727 of this image. 729 o *display*: "String" (optional) Describes the intended purpose of a 730 link to an image. If set, the _rel_ property MUST be set to 731 "icon". The value MUST be either one of the following values, 732 registered in a future RFC, or a vendor-specific value: 734 * "badge": an image inline with the title of the object 736 * "graphic": a full image replacement for the object itself 738 * "fullsize": an image that is used to enhance the object 740 * "thumbnail": a smaller variant of "fullsize " to be used when 741 space for the image is constrained 743 o *title*: "String" (optional) A human-readable plain-text 744 description of the resource. 746 4.2.7. locale 748 Type: "String" (optional) 750 The [RFC5646] language tag that best describes the locale used for 751 the calendar object, if known. 753 4.2.8. keywords 755 Type: "String[Boolean]" (optional) 756 A set of keywords or tags that relate to the object. The set is 757 represented as a map, with the keys being the keywords. The value 758 for each key in the map MUST be "true". 760 4.2.9. categories 762 Type: "String[Boolean]" (optional) 764 A set of categories that relate to the calendar object. The set is 765 represented as a map, with the keys being the categories specified as 766 URIs. The value for each key in the map MUST be "true". 768 In contrast to _keywords_, categories typically are structured. For 769 example, a vendor owning the domain "example.com" might define the 770 categories "http://example.com/categories/sports/american-football"" 771 and "http://example.com/categories/music/r-b". 773 4.2.10. color 775 Type: "String" (optional) 777 Specifies a color clients MAY use when displaying this calendar 778 object. The value is a case-insensitive color name taken from the 779 CSS3 set of names, defined in Section 4.3 of W3C.REC- 780 css3-color-20110607 [3] or a CSS3 RGB color hex value. 782 4.3. Recurrence properties 784 4.3.1. recurrenceRule 786 Type: "Recurrence" 788 Defines a recurrence rule (repeating pattern) for recurring calendar 789 objects. 791 A *Recurrence* object is a JSON object mapping of a RECUR value type 792 in iCalendar, see [RFC5545] and[RFC7529]. A JSEvent recurs by 793 applying the recurrence rule (and _recurrenceOverrides_) to the 794 _start_ date/time. A JSTask recurs by applying the recurrence rule 795 (and _recurrenceOverrides_) to its _start_ date/time, if defined. If 796 the task does not define a start date-time, it recurs by its _due_ 797 date-time. If it neither defines a start or due date-time, it MUST 798 NOT define a _recurrenceRule_. 800 A Recurrence object has the following properties: 802 o *frequency*: "String" This MUST be one of the following values: 804 * "yearly" 806 * "monthly" 808 * "weekly" 810 * "daily" 812 * "hourly" 814 * "minutely" 816 * "secondly" 818 To convert from iCalendar, simply lower-case the FREQ part. 820 o *interval*: "Number" (optional, default:"1") The INTERVAL part 821 from iCalendar. If included, it MUST be an integer "x >= 1". 823 o *rscale*: "String" (optional, default:""gregorian"") The RSCALE 824 part from iCalendar RSCALE [RFC7529], converted to lower-case. 826 o *skip*: "String" (optional, default:""omit"") The SKIP part from 827 iCalendar RSCALE [RFC7529], converted to lower-case. 829 o *firstDayOfWeek*: "String" (optional, default:""mo"") The WKST 830 part from iCalendar, represented as a lower-case abbreviated two- 831 letter English day of the week. If included, it MUST be one of 832 the following values: ""mo"|"tu"|"we"|"th"|"fr"|"sa"|"su"". 834 o *byDay*: "NDay[]" (optional) An *NDay* object has the following 835 properties: 837 * *day*: "String" The day-of-the-week part of the BYDAY value in 838 iCalendar, lower-cased. MUST be one of the following values: 839 ""mo"|"tu"|"we"|"th"|"fr"|"sa"|"su"". 841 * *nthOfPeriod*: "Number" (optional) The ordinal part of the 842 BYDAY value in iCalendar (e.g. ""+1"" or ""-3""). If present, 843 rather than representing every occurrence of the weekday 844 defined in the _day_ property of this _NDay_, it represents 845 only a specific instance within the recurrence period. The 846 value can be positive or negative, but MUST NOT be zero. A 847 negative integer means nth-last of period. 849 o *byMonthDay*: "Number[]" (optional) The BYMONTHDAY part from 850 iCalendar. The array MUST have at least one entry if included. 852 o *byMonth*: "String[]" (optional) The BYMONTH part from iCalendar. 853 Each entry is a string representation of a number, starting from 854 "1" for the first month in the calendar (e.g. ""1" " means 855 ""January"" with Gregorian calendar), with an optional ""L"" 856 suffix (see [RFC7529]) for leap months (this MUST be upper-case, 857 e.g. ""3L""). The array MUST have at least one entry if included. 859 o *byYearDay*: "Number[]" (optional) The BYYEARDAY part from 860 iCalendar. The array MUST have at least one entry if included. 862 o *byWeekNo*: "Number[]" (optional) The BYWEEKNO part from 863 iCalendar. The array MUST have at least one entry if included. 865 o *byHour*: "Number[]" (optional) The BYHOUR part from iCalendar. 866 The array MUST have at least one entry if included. 868 o *byMinute*: "Number[]" (optional) The BYMINUTE part from 869 iCalendar. The array MUST have at least one entry if included. 871 o *bySecond*: "Number[]" (optional) The BYSECOND part from 872 iCalendar. The array MUST have at least one entry if included. 874 o *bySetPosition*: "Number[]" (optional) The BYSETPOS part from 875 iCalendar. The array MUST have at least one entry if included. 877 o *count*: "Number" (optional) The COUNT part from iCalendar. This 878 MUST NOT be included if an _until_ property is specified. 880 o *until*: "LocalDate" (optional) The UNTIL part from iCalendar. 881 This MUST NOT be included if a _count_ property is specified. 882 Note: if not specified otherwise for a specific JSCalendar object, 883 this date is presumed to be in the time zone specified in 884 _timeZone_. As in iCalendar, the until value bounds the 885 recurrence rule inclusively. To allow for using the same bound 886 regardless of the value of the _isAllDay_ property, the _until_ 887 date time MAY include non-zero time components even for all-day 888 calendar objects. 890 A recurrence rule specifies a set of set of date-times for recurring 891 calendar objects. A recurrence rule has the following semantics. 892 Note, wherever "year", "month" or "day of month" is used, this is 893 within the calendar system given by the "rscale" property, which 894 defaults to gregorian if omitted. 896 1. A set of candidates is generated. This is every second within a 897 period defined by the frequency property: 899 * *yearly*: every second from midnight on the 1st day of a year 900 (inclusive) to midnight the 1st day of the following year 901 (exclusive). 903 If skip is not "omit", the calendar system has leap months and 904 there is a byMonth property, generate candidates for the leap 905 months even if they don't occur in this year. 907 If skip is not "omit" and there is a byMonthDay property, 908 presume each month has the maximum number of days any month 909 may have in this calendar system when generating candidates, 910 even if it's more than this month actually has. 912 * *monthly*: every second from midnight on the 1st day of a 913 month (inclusive) to midnight on the 1st of the following 914 month (exclusive). 916 If skip is not "omit" and there is a byMonthDay property, 917 presume the month has the maximum number of days any month may 918 have in this calendar system when generating candidates, even 919 if it's more than this month actually has. 921 * *weekly*: every second from midnight (inclusive) on the first 922 day of the week (as defined by the firstDayOfWeek property, or 923 Monday if omitted), to midnight 7 days later (exclusive). 925 * *daily*: every second from midnight at the start of the day 926 (inclusive) to midnight at the end of the day (exclusive). 928 * *hourly*: every second from the beginning of the hour 929 (inclusive) to the beginning of the next hour (exclusive). 931 * *minutely*: every second from the beginning of the minute 932 (inclusive) to the beginning of the next minute (exclusive). 934 * *secondly*: the second itself, only. 936 2. Each date-time candidate is compared against all of the byX 937 properties of the rule except bySetPosition. If any property in 938 the rule does not match the date-time, it is eliminated. Each 939 byX property is an array; the date-time matches the property if 940 it matches any of the values in the array. The properties have 941 the following semantics: 943 * *byMonth*: the date-time is in the given month. 945 * *byWeekNo*: the date-time is in the nth week of the year. 946 Negative numbers mean the nth last week of the year. This 947 corresponds to weeks according to week numbering as defined in 948 ISO.8601.2004, with a week defined as a seven day period, 949 starting on the firstDayOfWeek property value or Monday if 950 omitted. Week number one of the calendar year is the first 951 week that contains at least four days in that calendar year. 953 If the date-time is not valid (this may happen when generating 954 candidates with a skip property in effect), it is always 955 eliminated by this property. 957 * *byYearDay*: the date-time is on the nth day of year. 958 Negative numbers mean the nth last day of the year. 960 If the date-time is not valid (this may happen when generating 961 candidates with a skip property in effect), it is always 962 eliminated by this property. 964 * *byMonthDay*: the date-time is on the given day of the month. 965 Negative numbers mean the nth last day of the month. 967 * *byDay*: the date-time is on the given day of the week. If 968 the day is prefixed by a number, it is the nth occurrence of 969 that day of the week within the month (if frequency is 970 monthly) or year (if frequency is yearly). Negative numbers 971 means nth last occurrence within that period. 973 * *byHour*: the date-time has the given hour value. 975 * *byMinute*: the date-time has the given minute value. 977 * *bySecond*: the date-time has the given second value. 979 If a skip property is defined and is not "omit", there may be 980 candidates that do not correspond to valid dates (e.g. 31st 981 Februrary in the gregorian calendar). In this case, the 982 properties MUST be considered in the order above and: 984 1. After applying the byMonth filter, if the candidate's month 985 is invalid for the given year increment it (if skip is 986 "forward") or decrement it (if skip is "backward") until a 987 valid month is found, incrementing/decrementing the year as 988 well if you pass through the beginning/end of the year. This 989 only applies to calendar systems with leap months. 991 2. After applying the byMonthDay filter, if the day of the month 992 is invalid for the given month and year, change the date to 993 the first day of the next month (if skip == "forward") or the 994 last day of the current month (if skip == "backward"). 996 3. If any valid date produced after applying the skip is already 997 a candidate, eliminate the duplicate. (For example after 998 adjusting, 30th Februrary and 31st February would both become 999 the same "real" date, so one is eliminated as a duplicate.) 1001 3. If a bySetPosition property is included, this is now applied to 1002 the ordered list of remaining dates (this property specifies the 1003 indexes of date-times to keep; all others should be eliminated. 1004 Negative numbers are indexes from the end of the list, with -1 1005 being the last item). 1007 4. Any date-times before the start date of the event are eliminated 1008 (see below for why this might be needed). 1010 5. If a skip property is included and is not "omit", eliminate any 1011 date-times that have already been produced by previous iterations 1012 of the algorithm. (This is not possible if skip == "omit".) 1014 6. If further dates are required (we have not reached the until 1015 date, or count limit) skip the next (interval - 1) sets of 1016 candidates, then continue from step 1. 1018 When determining the set of occurrence dates for an event or task, 1019 the following extra rules must be applied: 1021 1. The start date-time is always the first occurrence in the 1022 expansion (and is counted if the recurrence is limited by a 1023 "count" property), even if it would normally not match the rule. 1025 2. The first set of candidates to consider is that which would 1026 contain the start date-time. This means the first set may 1027 include candidates before the start; such candidates are 1028 eliminated from the results in step (4) as outlined before. 1030 3. The following properties MUST be implicitly added to the rule 1031 under the given conditions: 1033 * If frequency > "secondly" and no bySecond property: Add a 1034 bySecond property with the sole value being the seconds value 1035 of the start date-time. 1037 * If frequency > "minutely" and no byMinute property: Add a 1038 byMinute property with the sole value being the minutes value 1039 of the start date-time. 1041 * If frequency > "hourly" and no byHour property: Add a byHour 1042 property with the sole value being the hours value of the 1043 start date-time. 1045 * If frequency is "weekly" and no byDay property: Add a byDay 1046 property with the sole value being the day-of-the-week of the 1047 start date-time. 1049 * If frequency is "monthly" and no byDay property and no 1050 byMonthDay property: Add a byMonthDay property with the sole 1051 value being the day-of-the-month of the start date-time. 1053 * If frequency is "yearly" and no byYearDay property: 1055 + if there are no byMonth or byWeekNo properties, and either 1056 there is a byMonthDay property or there is no byDay 1057 property: Add a byMonth property with the sole value being 1058 the month of the start date-time. 1060 + if there is no byMonthDay, byWeekNo or byDay properties: 1061 Add a byMonthDay property with the sole value being the 1062 day-of-the-month of the start date-time. 1064 + if there is a byWeekNo property and no byMonthDay or byDay 1065 properties: Add a byDay property with the sole value being 1066 the day-of-the-week of the start date-time. 1068 4.3.2. recurrenceOverrides 1070 Type: "LocalDate[PatchObject]" (optional) 1072 A map of the recurrence-ids (the date-time of the start of the 1073 occurrence) to an object of patches to apply to the generated 1074 occurrence object. 1076 If the recurrence-id does not match an expanded start date from a 1077 recurrence rule, it is to be treated as an additional occurrence 1078 (like an RDATE from iCalendar). The patch object may often be empty 1079 in this case. 1081 If the patch object defines the _excluded_ property to be "true", 1082 then the recurring calendar object does not occur at the recurrence- 1083 id date-time (like an EXDATE from iCalendar). Such a patch object 1084 MUST NOT patch any other property. 1086 By default, an occurrence inherits all properties from the main 1087 object except the start (or due) date-time, which is shifted to the 1088 new start time of the LocalDate key. However, individual properties 1089 of the occurrence can be modified by a patch, or multiple patches. 1090 It is valid to patch the start property value, and this patch takes 1091 precedence over the LocalDate key. Both the LocalDate key as well as 1092 the patched start date-time may occur before the original JSCalendar 1093 object's start or due date. 1095 A pointer in the PatchObject MUST NOT start with one of the following 1096 prefixes; any patch with such a key MUST be ignored: 1098 o @type 1100 o uid 1102 o relatedTo 1104 o prodId 1106 o method 1108 o isAllDay 1110 o recurrenceRule 1112 o recurrenceOverrides 1114 o replyTo 1116 4.3.3. excluded 1118 Type: "Boolean" (optional, default:"false") 1120 Defines if this object is an overridden, excluded instance of a 1121 recurring JSCalendar object (also see Section 4.3.2). If this 1122 property value is "true", this calendar object instance MUST be 1123 removed from the occurrence expansion. 1125 4.4. Sharing and scheduling properties 1127 4.4.1. priority 1129 Type: "Number" (optional, default:"0") 1131 Specifies a priority for the calendar object. This may be used as 1132 part of scheduling systems to help resolve conflicts for a time 1133 period. 1135 The priority is specified as an integer in the range 0 to 9. A value 1136 of 0 specifies an undefined priority. A value of 1 is the highest 1137 priority. A value of 2 is the second highest priority. Subsequent 1138 numbers specify a decreasing ordinal priority. A value of 9 is the 1139 lowest priority. Other integer values are reserved for future use. 1141 4.4.2. freeBusyStatus 1143 Type: "String" (optional, default:"busy") 1145 Specifies how this property should be treated when calculating free- 1146 busy state. The value MUST be one of: 1148 o ""free"": The object should be ignored when calculating whether 1149 the user is busy. 1151 o ""busy"": The object should be included when calculating whether 1152 the user is busy. 1154 4.4.3. privacy 1156 Type: "String" (optional, default:"public") 1158 Calendar objects are normally collected together and may be shared 1159 with other users. The privacy property allows the object owner to 1160 indicate that it should not be shared, or should only have the time 1161 information shared but the details withheld. Enforcement of the 1162 restrictions indicated by this property are up to the 1163 implementations. 1165 This property MUST NOT affect the information sent to scheduled 1166 participants; it is only interpreted when the object is shared as 1167 part of a shared calendar. 1169 The value MUST be either one of the following values, registered in a 1170 future RFC, or a vendor-specific value. Vendor specific values MUST 1171 be prefixed with a domain name controlled by the vendor, e.g. 1172 "example.com/topsecret". Any value the client or server doesn't 1173 understand should be preserved but treated as equivalent to 1174 "private". 1176 o "public": The full details of the object are visible to those whom 1177 the object's calendar is shared with. 1179 o "private": The details of the object are hidden; only the basic 1180 time and metadata is shared. Implementations MUST ensure the 1181 following properties are stripped when the object is accessed by a 1182 sharee: 1184 * title 1186 * description 1188 * locations 1189 * links 1191 * locale 1193 * localizations 1195 * participants 1197 * replyTo 1199 In addition, any patches in "recurrenceOverrides" whose key is 1200 prefixed with one of the above properties MUST be stripped. 1202 o "secret": The object is hidden completely (as though it did not 1203 exist) when the calendar is shared. 1205 4.4.4. replyTo 1207 Type: "String[String]" (optional) 1209 Represents methods by which participants may submit their RSVP 1210 response to the organizer of the calendar object. The keys in the 1211 property value are the available methods and MUST only contain ASCII 1212 alphanumeric characters (A-Za-z0-9). The value is a URI to use that 1213 method. Future methods may be defined in future specifications; a 1214 calendar client MUST ignore any method it does not understand, but 1215 MUST preserve the method key and URI. This property MUST be omitted 1216 if no method is defined (rather than an empty object). If this 1217 property is set, the _participants_ property of this calendar object 1218 MUST contain at least one participant. 1220 The following methods are defined: 1222 o "imip": The organizer accepts an iMIP [RFC6047] response at this 1223 email address. The value MUST be a "mailto:" URI. 1225 o "web": Opening this URI in a web browser will provide the user 1226 with a page where they can submit a reply to the organizer. 1228 o "other": The organizer is identified by this URI but the method 1229 how to submit the RSVP is undefined. 1231 4.4.5. participants 1233 Type: "String[Participant]" (optional) 1234 A map of participant identifiers to participants, describing their 1235 participation in the calendar object. A UUID or the base-64 encoded 1236 email address of the participant is a good choice for the identifier. 1238 If this property is set, then the _replyTo_ property of this calendar 1239 object MUST define at least one reply method. 1241 A *Participant* object has the following properties: 1243 o *name*: "String" (optional) The display name of the participant 1244 (e.g. "Joe Bloggs"). 1246 o *email*: "String" (optional) The email address for the 1247 participant. 1249 o *sendTo*: "String[String]" Represents methods by which the 1250 participant may receive the invitation and updates to the calendar 1251 object. 1253 The keys in the property value are the available methods and MUST 1254 only contain ASCII alphanumeric characters (A-Za-z0-9). The value 1255 is a URI to use that method. Future methods may be defined in 1256 future specifications; a calendar client MUST ignore any method it 1257 does not understand, but MUST preserve the method key and URI. 1258 This property MUST be omitted if no method is defined (rather than 1259 an empty object). 1261 The following methods are defined: 1263 * "imip": The participant accepts an iMIP [RFC6047] request at 1264 this email address. The value MUST be a "mailto:" URI. It MAY 1265 be different from the value of the participant's _email_ 1266 property. 1268 * "other": The participant is identified by this URI but the 1269 method how to submit the invitation or update is undefined. 1271 o *kind*: "String" (optional) What kind of entity this participant 1272 is, if known. 1274 This MUST be either one of the following values, registered in a 1275 future RFC, or a vendor-specific value. Any value the client or 1276 server doesn't understand should be treated the same as if this 1277 property is omitted. 1279 * "individual": a single person 1281 * "group": a collection of people invited as a whole 1282 * "resource": a non-human resource, e.g. a projector 1284 * "location": a physical location involved in the calendar object 1285 that needs to be scheduled, e.g. a conference room. 1287 o *roles*: "String[Boolean]" A set of roles that this participant 1288 fulfills. 1290 At least one role MUST be specified for the participant. The keys 1291 in the set MUST be either one of the following values, registered 1292 in a future RFC, or a vendor-specific value: 1294 * "owner": The participant is an owner of the object. 1296 * "attendee": The participant is an attendee of the calendar 1297 object. 1299 * "chair": The participant is in charge of the calendar object 1300 when it occurs. 1302 The value for each key in the set MUST be "true". Roles that are 1303 unknown to the implementation MUST be preserved and MAY be 1304 ignored. 1306 o *locationId*: "String" (optional) The location at which this 1307 participant is expected to be attending. 1309 If the value does not correspond to any location id in the 1310 _locations_ property of the instance, this MUST be treated the 1311 same as if the participant's locationId were omitted. 1313 o *participationStatus*: "String" (optional, default:"needs-action") 1314 The participation status, if any, of this participant. 1316 The value MUST be either one of the following values, registered 1317 in a future RFC, or a vendor-specific value: 1319 * "needs-action": No status yet set by the participant. 1321 * "accepted": The invited participant will participate. 1323 * "declined": The invited participant will not participate. 1325 * "tentative": The invited participant may participate. 1327 o *attendance*: "String" (optional, default:"required") The required 1328 attendance of this participant. 1330 The value MUST be either one of the following values, registered 1331 in a future RFC, or a vendor-specific value. Any value the client 1332 or server doesn't understand should be treated the same as 1333 "required". 1335 * "none": Indicates a participant who is copied for information 1336 purposes only. 1338 * "optional": Indicates a participant whose attendance is 1339 optional. 1341 * "required": Indicates a participant whose attendance is 1342 required. 1344 o *expectReply*: "Boolean" (optional, default:"false") If true, the 1345 organizer is expecting the participant to notify them of their 1346 status. 1348 o *scheduleSequence*: "Number" (optional, default:"0") The sequence 1349 number of the last response from the participant. If defined, 1350 this MUST be a non-negative integer. 1352 This can be used to determine whether the participant has sent a 1353 new RSVP following significant changes to the calendar object, and 1354 to determine if future responses are responding to a current or 1355 older view of the data. 1357 o *scheduleUpdated*: "UTCDate" (optional) The _updated_ property of 1358 the last iMIP response from the participant. 1360 This can be compared to the _updated_ timestamp in future iMIP 1361 responses to determine if the response is older or newer than the 1362 current data. 1364 o *invitedBy*: "String" (optional) The participant id of the 1365 participant who invited this one, if known. 1367 o *delegatedTo*: "String[Boolean]" (optional) A set of participant 1368 ids that this participant has delegated their participation to. 1369 Each key in the set MUST be the identifier of a participant. The 1370 value for each key in the set MUST be "true". This MUST be 1371 omitted if none (rather than an empty set). 1373 o *delegatedFrom*: "String[Boolean]" (optional) A set of participant 1374 ids that this participant is acting as a delegate for. Each key 1375 in the set MUST be the identifier of a participant. The value for 1376 each key in the set MUST be "true". This MUST be omitted if none 1377 (rather than an empty set). 1379 o *memberOf*: "String[Boolean]" (optional) A set of group 1380 participants that were invited to this calendar object, which 1381 caused this participant to be invited due to their membership of 1382 the group(s). Each key in the set MUST be the identifier of a 1383 participant. The value for each key in the set MUST be "true". 1384 This MUST be omitted if none (rather than an empty set). 1386 o *linkIds*: "String[Boolean]" (optional) A set of links to more 1387 information about this participant, for example in vCard format. 1388 The keys in the set MUST be the identifier of a Link object in the 1389 calendar object's _links_ property. The value for each key in the 1390 set MUST be "true". This MUST be omitted if none (rather than an 1391 empty set). 1393 4.5. Alerts properties 1395 4.5.1. useDefaultAlerts 1397 Type: "Boolean" (optional, default:"false") 1399 If "true", use the user's default alerts and ignore the value of the 1400 _alerts_ property. Fetching user defaults is dependent on the API 1401 from which this JSCalendar object is being fetched, and is not 1402 defined in this specification. If an implementation cannot determine 1403 the user's default alerts, or none are set, it MUST process the 1404 alerts property as if useDefaultAlerts is set to "false". 1406 4.5.2. alerts 1408 Type: "String[Alert]" (optional) 1410 A map of alert identifiers to Alert objects, representing alerts/ 1411 reminders to display or send the user for this calendar object. 1413 An *Alert* Object has the following properties: 1415 o *offset*: "SignedDuration" Defines when to trigger the alert, 1416 relative to the time property defined in the _relativeTo_ 1417 property. If the calendar object does not define a time zone, the 1418 user's default time zone SHOULD be used when determining the 1419 offset, if known. Otherwise, the time zone to use is 1420 implementation specific. 1422 o *relativeTo*: "String" (optional, default:"start") Specifies the 1423 time property which the alert _offset_ is relative to. The value 1424 MUST be one of: 1426 * "start": triggers the alert relative to the start of the 1427 calendar object 1429 * "end": triggers the alert relative to the end/due time of the 1430 calendar object 1432 o *acknowledged*: "UTCDate" (optional) 1434 When the user has permanently dismissed the alert the client MUST 1435 set this to the current time in UTC. Other clients which sync 1436 this property can then automatically dismiss or suppress duplicate 1437 alerts (alerts with the same alert id that triggered on or before 1438 this date-time). 1440 For a recurring calendar object, the _acknowledged_ property of 1441 the parent object MUST be updated, unless the alert is already 1442 overridden in _recurrenceOverrides_. 1444 o *snoozed*: "UTCDate" (optional) 1446 If the user temporarily dismisses the alert, this is the UTC date- 1447 time after which it should trigger again. Setting this property 1448 on an instance of a recurring calendar object MUST update the 1449 alarm on the master object, unless the respective instance already 1450 is defined in "recurrenceOverrides". It MUST NOT generate an 1451 override for the sole use of snoozing an alarm. 1453 o *action*: "String" (optional, default:"display") Describes how to 1454 alert the user. 1456 The value MUST be at most one of the following values, registered 1457 in a future RFC, or a vendor-specific value: 1459 * "display": The alert should be displayed as appropriate for the 1460 current device and user context. 1462 * "email": The alert should trigger an email sent out to the 1463 user, notifying about the alert. This action is typically only 1464 appropriate for server implementations. 1466 4.6. Multilingual properties 1468 4.6.1. localizations 1470 Type: "String[PatchObject]" (optional) 1472 A map of [RFC5646] language tags to patch objects, which localize the 1473 calendar object into the locale of the respective language tag. 1475 See the description of PatchObject (Section 3.2.4) for the structure 1476 of the PatchObject. The patches are applied to the top-level object. 1477 In addition to all the restrictions on patches specified there, the 1478 pointer also MUST NOT start with one of the following prefixes; any 1479 patch with a such a key MUST be ignored: 1481 o @type 1483 o due 1485 o duration 1487 o freeBusyStatus 1489 o localization 1491 o method 1493 o participants 1495 o prodId 1497 o progress 1499 o relatedTo 1501 o sequence 1503 o start 1505 o status 1507 o timeZone 1509 o uid 1511 o useDefaultAlerts 1513 Note that this specification does not define how to maintain validity 1514 of localized content. For example, a client application changing a 1515 JSCalendar object's title property might also need to update any 1516 localizations of this property. Client implementations SHOULD 1517 provide the means to manage localizations, but how to achieve this is 1518 specific to the application's workflow and requirements. 1520 4.7. Time zone properties 1522 4.7.1. timeZones 1524 Type: "String[TimeZone]" (optional) 1526 Maps identifiers of custom time zones to their time zone definition. 1527 The following restrictions apply for each key in the map: 1529 o It MUST start with the "/" character (ASCII decimal 47; also see 1530 sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion 1531 of the forward slash character in time zone identifiers). 1533 o It MUST be a valid _paramtext_ value as specified in section 3.1. 1534 of [RFC5545]. 1536 o At least one other property in the same JSCalendar object MUST 1537 reference a time zone using this identifier (i.e. orphaned time 1538 zones are not allowed). 1540 An identifier need only be unique to this JSCalendar object. 1542 A *TimeZone* object maps a VTIMEZONE component from iCalendar 1543 ([RFC5545]). A valid time zone MUST define at least one transition 1544 rule in the _standard_ or _daylight_ property. Its properties are: 1546 o *tzId*: "String" The TZID property from iCalendar. 1548 o *lastModified*: "UTCDate" (optional) The LAST-MODIFIED property 1549 from iCalendar. 1551 o *url*: "String" (optional) The TZURL property from iCalendar. 1553 o *validUntil*: "UTCDate" (optional) The TZUNTIL property from 1554 iCalendar specified in [RFC7808]. 1556 o *aliases*: "String[Boolean]" Maps the TZID-ALIAS-OF properties 1557 from iCalendar specified in [RFC7808] to a JSON set of aliases. 1558 The set is represented as an object, with the keys being the 1559 aliases. The value for each key in the set MUST be "true". 1561 o *standard*: "TimeZoneRule[]" (optional) The STANDARD sub- 1562 components from iCalendar. The order MUST be preserved during 1563 conversion. 1565 o *daylight*: "TimeZoneRule[]" (optional) The DAYLIGHT sub- 1566 components from iCalendar. The order MUST be preserved during 1567 conversion. 1569 A *TimeZoneRule* object maps a STANDARD or DAYLIGHT sub-component 1570 from iCalendar, with the restriction that _at most one_ recurrence 1571 rule is allowed per rule. It has the following properties: 1573 o *start*: "LocalDate" The DTSTART property from iCalendar. 1575 o *offsetTo*: "String" The TZOFFSETTO property from iCalendar. 1577 o *offsetFrom*: "String" The TZOFFSETFROM property from iCalendar. 1579 o *recurrenceRule*: "RecurrenceRule" (optional) The RRULE property 1580 mapped as specified in Section 4.3.1. During recurrence rule 1581 evaluation, the _until_ property value MUST be interpreted as a 1582 local time in the UTC time zone. 1584 o *recurrenceDates*: "LocalDate[Boolean]" (optional) Maps the RDATE 1585 properties from iCalendar to a JSON set. The set is represented 1586 as an object, with the keys being the recurrence dates. The value 1587 for each key in the set MUST be "true". 1589 o *names*: "String[Boolean]" (optional) Maps the TZNAME properties 1590 from iCalendar to a JSON set. The set is represented as an 1591 object, with the keys being the names. The value for each key in 1592 the set MUST be "true". 1594 o *comments*: "String[]" (optional) Maps the COMMENT properties from 1595 iCalendar. The order MUST be preserved during conversion. 1597 5. Type-specific JSCalendar properties 1599 5.1. JSEvent properties 1601 In addition to the common JSCalendar object properties (Section 4) a 1602 JSEvent has the following properties: 1604 5.1.1. start 1606 Type: "LocalDate" e.g. "2015-09-02T00:00:00" 1608 The date/time the event would start in the event's time zone. 1610 A valid JSEvent MUST include this property. 1612 5.1.2. timeZone 1614 Type: "String|null" (optional, default:"null") 1615 Identifies the time zone the event is scheduled in, or "null" for 1616 floating time. If omitted, this MUST be presumed to be "null" (i.e. 1617 floating time). Also see Section 3.2.6. 1619 5.1.3. duration 1621 Type: "Duration", e.g. "P2DT3H" (optional, default: "PT0S") 1623 The zero or positive duration of the event in the event's start time 1624 zone. The same rules as for the iCalendar DURATION value type 1625 ([RFC5545]) apply: The duration of a week or a day in hours/minutes/ 1626 seconds may vary if it overlaps a period of discontinuity in the 1627 event's time zone, for example a change from standard time to 1628 daylight-savings time. Leap seconds MUST NOT be considered when 1629 computing an exact duration. When computing an exact duration, the 1630 greatest order time components MUST be added first, that is, the 1631 number of days MUST be added first, followed by the number of hours, 1632 number of minutes, and number of seconds. Fractional seconds MUST be 1633 added last. 1635 A JSEvent MAY involve start and end locations that are in different 1636 time zones (e.g. a trans-continental flight). This can be expressed 1637 using the _rel_ and _timeZone_ properties of the JSEvent's _location_ 1638 objects. 1640 5.1.4. isAllDay 1642 Type: "Boolean" (optional, default:"false") 1644 Specifies if the event is an all day event, such as a birthday or 1645 public holiday. 1647 If _isAllDay_ is true, then the following restrictions apply: 1649 o the _start_ property MUST have a time component of "T00:00:00". 1651 o the _timeZone_ property MUST be "null" 1653 o the _duration_ property MUST NOT include non-zero time components 1654 (hours, minutes, or seconds) 1656 o the _freeBusyStatus_ property MUST NOT be "busy" 1658 5.1.5. status 1660 Type: "String" (optional, default:"confirmed") 1661 The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be 1662 one of: 1664 o "confirmed": Indicates the event is definite. 1666 o "cancelled": Indicates the event is cancelled. 1668 o "tentative": Indicates the event is tentative. 1670 5.2. JSTask properties 1672 In addition to the common JSCalendar object properties (Section 4) a 1673 JSTask has the following properties: 1675 5.2.1. due 1677 Type: "LocalDate" (optional) e.g. "2015-09-02T00:00:00" 1679 The date/time the task is due in the task's time zone. 1681 5.2.2. start 1683 Type: "LocalDate" (optional) e.g. "2015-09-02T00:00:00" 1685 The date/time the task should start in the task's time zone. 1687 5.2.3. timeZone 1689 Type: "String|null" (optional, default:"null") 1691 Identifies the time zone the task is scheduled in, or "null" for 1692 floating time. If omitted, this MUST be presumed to be "null" (i.e. 1693 floating time). Also see Section 3.2.6. 1695 5.2.4. estimatedDuration 1697 Type: "Duration" (optional), e.g. "P2DT3H" 1699 Specifies the estimated positive duration of time the task takes to 1700 complete. 1702 5.2.5. statusUpdatedAt 1704 Type: "UTCDate" (optional), e.g. "2016-06-13T12:00:00Z" 1706 Specifies the date/time the task status properties was last updated. 1708 If the task is recurring and has future instances, a client may want 1709 to keep track of the last status update timestamp of a specific task 1710 recurrence, but leave other instances unchanged. One way to achieve 1711 this is by overriding the statusUpdatedAt property in the task 1712 _recurrenceOverrides_. However, this could produce a long list of 1713 timestamps for regularly recurring tasks. An alternative approach is 1714 to split the JSTask into a current, single instance of JSTask with 1715 this instance status update time and a future recurring instance. 1716 Also see the definition of the _relatedTo_ on splitting. 1718 5.2.6. isAllDay 1720 Type: "Boolean" (optional, default:"false") 1722 Specifies if the task is an all day task. 1724 If _isAllDay_ is true, then the following restrictions apply: 1726 o the _start_ and _due_ properties MUST have a time component of 1727 "T00:00:00", or not be set 1729 o the _timeZone_ property MUST be "null" 1731 o the _freeBusyStatus_ property MUST NOT be "busy" 1733 5.2.7. progress 1735 In addition to the common properties of a _Participant_ object 1736 (Section 4.4.5), a Participant within a JSTask supports the following 1737 property: 1739 o *progress*: "ParticipantProgress" (optional) The progress of the 1740 participant for this task, if known. This property MUST NOT be 1741 set if the _participationStatus_ of this participant is any other 1742 value but "accepted". 1744 A *ParticipantProgress* object has the following properties: 1746 o *status*: "String" Describes the completion status of the 1747 participant's progress. 1749 The value MUST be at most one of the following values, registered 1750 in a future RFC, or a vendor-specific value: 1752 * "completed": The participant completed their task. 1754 * "in-process": The participant has started this task. 1756 * "failed": The participant failed to complete their task. 1758 o *timestamp*: "UTCDate" Describes the last time when the 1759 participant progress got updated. 1761 5.2.8. status 1763 Type: "String" 1765 Defines the overall status of this task. If omitted, the default 1766 status (Section 4.4) of a JSTask is defined as follows (in order of 1767 evaluation): 1769 o "completed": if all the _ParticipantProgress_ status of the task 1770 participants is "completed". 1772 o "failed": if at least one _ParticipantProgress_ status of the task 1773 participants is "failed". 1775 o "in-process": if at least one _ParticipantProgress_ status of the 1776 task participants is "in-process". 1778 o "needs-action": If none of the other criteria match. 1780 If set, it MUST be one of: 1782 o "needs-action": Indicates the task needs action. 1784 o "completed": Indicates the task is completed. 1786 o "in-process": Indicates the task is in process. 1788 o "cancelled": Indicates the task is cancelled. 1790 o "pending": Indicates the task has been created and accepted for 1791 processing, but not yet started. 1793 o "failed": Indicates the task failed. 1795 5.3. JSGroup properties 1797 JSGroup supports the following JSCalendar properties (Section 4): 1799 o @type 1801 o uid 1803 o created 1804 o updated 1806 o categories 1808 o keywords 1810 o name 1812 o description 1814 o color 1816 o links 1818 as well as the following JSGroup-specific properties: 1820 5.3.1. entries 1822 Type: "String[JSTask|JSEvent]" 1824 A collection of group members. This is represented as a map of the 1825 _uid_ property value to the JSCalendar object member having that uid. 1826 Implementations MUST ignore entries of unknown type. 1828 5.3.2. source 1830 Type: "String" (optional) 1832 The source from which updated versions of this group may be retrieved 1833 from. The value MUST be a URI. 1835 6. Conversion from and to iCalendar 1837 This section specifies which JSCalendar properties can be mapped from 1838 and to iCalendar format. Implementations SHOULD follow these 1839 conversion guidelines. Still, JSCalendar does not restrict itself to 1840 iCalendar and conversion between these two formats MAY be lossy. 1842 6.1. JSEvent 1844 The iCalendar counterpart to _JSEvent_ is the VEVENT component type 1845 [RFC5545]. A VEVENT component that is a direct child of a VCALENDAR 1846 component is equivalent to a standalone JSEvent. A VEVENT component 1847 within a VEVENT maps to the entries of the JSEvent 1848 _recurrenceOverrides_ property. 1850 +----------+--------------------------------------------------------+ 1851 | Property | iCalendar counterpart | 1852 +----------+--------------------------------------------------------+ 1853 | isAllDay | True, if the type of the DTSTART property in iCalendar | 1854 | | is DATE. | 1855 | | | 1856 | start | Corresponds to the DTSTART property in iCalendar. Note | 1857 | | that time zone information is stored separately in | 1858 | | JSEvent. | 1859 | | | 1860 | timeZone | Corresponds to the TZID part of the DTSTART property | 1861 | | in iCalendar. If the event has a different end time | 1862 | | zone to start time zone, this should be added as a | 1863 | | JSCalendar _location_ with just a _timeZone_ property | 1864 | | and "rel="end"". | 1865 | | | 1866 | duration | Corresponds to the DURATION or DSTART+DTEND properties | 1867 | | in iCalendar. | 1868 +----------+--------------------------------------------------------+ 1870 Table 1: Translation between JSEvent and iCalendar 1872 6.2. JSTask 1874 The iCalendar counterpart to _JSTask_ is the VTODO component type 1875 [RFC5545]. A VTODO component that is a direct child of a VCALENDAR 1876 component is equivalent to a standalone JSTask. A VTODO component 1877 within a master VTODO maps to the entries of the JSTask 1878 _recurrenceOverrides_ property. 1880 +-------------------+-----------------------------------------------+ 1881 | Property | iCalendar counterpart | 1882 +-------------------+-----------------------------------------------+ 1883 | isAllDay | True, if the type of the DTSTART property in | 1884 | | iCalendar is DATE. | 1885 | | | 1886 | due | Corresponds to the DUE and DTSTART+DURATION | 1887 | | properties in iCalendar. When mapping | 1888 | | iCalendar VTODOs with DTSTART+DURATION, the | 1889 | | due date is the result of adding DURATION to | 1890 | | DTSTART in the DTSTART time zone. | 1891 | | | 1892 | start | Corresponds to the DTSTART property in | 1893 | | iCalendar. | 1894 | | | 1895 | timeZone | Corresponds to the TZID part of the | 1896 | | DTSTART/DUE properties in iCalendar. If the | 1897 | | task has a different end time zone to start | 1898 | | or due time zone, this should be added as a | 1899 | | JSCalendar _location_ with just a _timeZone_ | 1900 | | property and "rel="end"". | 1901 | | | 1902 | estimatedDuration | Corresponds to the ESTIMATED-DURATION | 1903 | | iCalendar property in the RFC draft | 1904 | | [draft-apthorp-ical-tasks]. | 1905 | | | 1906 | statusUpdatedAt | Maps to the COMPLETED iCalendar property. The | 1907 | | JSTask status property MUST have value | 1908 | | "completed". | 1909 | | | 1910 | progress | Corresponds to the PARTSTAT and COMPLETED | 1911 | | properties in iCalendar, including the | 1912 | | definitions in the RFC draft | 1913 | | [draft-apthorp-ical-tasks]. | 1914 | | | 1915 | status | Corresponds to the STATUS property in | 1916 | | iCalendar, including the definitions in the | 1917 | | RFC draft [draft-apthorp-ical-tasks]. | 1918 +-------------------+-----------------------------------------------+ 1920 Table 2: Translation between JSTask and iCalendar 1922 6.3. JSGroup 1924 A JSGroup converts to a iCalendar VCALENDAR containing VEVENT or 1925 VTODO components. 1927 +----------+--------------------------------------------------------+ 1928 | Property | iCalendar counterpart | 1929 +----------+--------------------------------------------------------+ 1930 | entries | The VEVENT and VTODO components within a top-level | 1931 | | VCALENDAR component. | 1932 | | | 1933 | source | Corresponds to the SOURCE property in iCalendar. | 1934 +----------+--------------------------------------------------------+ 1936 Table 3: Translation between JSGroup and iCalendar 1938 6.4. Common properties 1940 +------------------------+------------------------------------------+ 1941 | Property | iCalendar counterpart | 1942 +------------------------+------------------------------------------+ 1943 | alerts | An _Alert_ corresponds to the VALARM | 1944 | | component in iCalendar, where the | 1945 | | _action_ is determined by the iCalendar | 1946 | | ACTION property value (e.g., both | 1947 | | "DISPLAY" and "AUDIO" actions map to a | 1948 | | JSCalendar _display_ action, and | 1949 | | similarly for "EMAIL"). The | 1950 | | _relativeTo_ and _offset_ properties | 1951 | | corresponds to the iCalendar TRIGGER | 1952 | | property. | 1953 | | | 1954 | categories | Corresponds to the CONCEPT property in | 1955 | | iCalendar, see in the RFC draft | 1956 | | [draft-ietf-calext-ical-relations]. | 1957 | | | 1958 | color | Corresponds to the COLOR property in | 1959 | | iCalendar, as specified in [RFC7986]. | 1960 | | | 1961 | created | Corresponds to the CREATED property in | 1962 | | iCalendar. | 1963 | | | 1964 | description | Corresponds to the DESCRIPTION property | 1965 | | and its ALTREP parameters in iCalendar. | 1966 | | | 1967 | descriptionContentType | Implementation-specific. | 1968 | | | 1969 | freeBusyStatus | Corresponds to the TRANSP property in | 1970 | | iCalendar. | 1971 | | | 1972 | keywords | Corresponds to the CATEGORIES property | 1973 | | in iCalendar, as specified in [RFC7986]. | 1974 | | | 1975 | links | Use the ATTACH ([RFC5545]), URL or IMAGE | 1976 | | ([RFC7986]) property values of URI value | 1977 | | type as the Link _href_. The Link | 1978 | | _type_ property corresponds to the | 1979 | | FMTTYPE parameter, the _size_ property | 1980 | | to the SIZE parameter. Mapping all | 1981 | | other properties is implementation- | 1982 | | specific. | 1983 | | | 1984 | locale | Corresponds to the LANGUAGE parameter in | 1985 | | iCalendar, which is added to individual | 1986 | | properties. When converting from | 1987 | | iCalendar, one language must be picked | 1988 | | as the main locale for the object, and | 1989 | | all properties in other languages moved | 1990 | | to the localizations JSEvent property. | 1991 | | | 1992 | localizations | Implementation-specific. | 1993 | | | 1994 | locations | See Section 6.5. | 1995 | | | 1996 | method | Corresponds to the METHOD property of | 1997 | | the embedding VCALENDAR in iCalendar. | 1998 | | | 1999 | participants | See Section 6.5. | 2000 | | | 2001 | priority | Corresponds to the PRIORITY property in | 2002 | | iCalendar. | 2003 | | | 2004 | privacy | Corresponds to the CLASS property in | 2005 | | iCalendar. | 2006 | | | 2007 | prodId | Corresponds to the PRODID property in | 2008 | | iCalendar. | 2009 | | | 2010 | recurrenceOverrides | Corresponds to the RDATE and EXDATE | 2011 | | properties in iCalendar, plus VEVENT | 2012 | | (for JSEvent) or VTODO (for JSTask) | 2013 | | instances with a recurrence-id. | 2014 | | | 2015 | recurrenceRule | Corresponds to the RRULE property in | 2016 | | iCalendar. For all-day calendar objects, | 2017 | | convert the _until_ property value to an | 2018 | | iCalendar DATE (effectively removing the | 2019 | | time component). To convert a DATE-typed | 2020 | | UNTIL from iCalendar, set the time | 2021 | | components of the LocalDate value to | 2022 | | "23:59:59". If the iCalendar UNTIL value | 2023 | | is a UTC date time, convert to the local | 2024 | | time in the calendar object time zone. | 2025 | | | 2026 | relatedTo | Corresponds to the RELATED-TO property | 2027 | | in iCalendar. | 2028 | | | 2029 | replyTo | An iCalendar ORGANIZER with a mailto: | 2030 | | URI mapped to the "imip" method, or any | 2031 | | other URI mapped to the "other" method. | 2032 | | Mapping multiple methods is | 2033 | | implementation-specific. | 2034 | | | 2035 | sequence | Corresponds to the SEQUENCE property in | 2036 | | iCalendar. | 2037 | | | 2038 | status | Corresponds to the STATUS property in | 2039 | | iCalendar (converted to lower-case). | 2040 | | | 2041 | title | Corresponds to the SUMMARY property in | 2042 | | iCalendar. | 2043 | | | 2044 | uid | Corresponds to the UID property in | 2045 | | iCalendar. | 2046 | | | 2047 | updated | Corresponds to the DTSTAMP and LAST- | 2048 | | MODIFIED properties in iCalendar. (These | 2049 | | are only different in the iTIP case, and | 2050 | | the difference is not actually useful.) | 2051 +------------------------+------------------------------------------+ 2053 Table 4: Translation between JSCalendar and iCalendar 2055 6.5. Locations and participants 2057 Both JSCalendar participants and locations have counterparts in 2058 iCalendar but provide richer representation. 2060 The following table outlines translation of JSCalendar participants. 2061 Where iCalendar has distinct properties for ORGANIZER and ATTENDEE, 2062 these are merged in JSCalendar into the Participant object type. 2064 +---------------------+---------------------------------------------+ 2065 | Property | iCalendar counterpart | 2066 +---------------------+---------------------------------------------+ 2067 | delegatedFrom | the DELEGATED-FROM parameter | 2068 | | | 2069 | delegatedTo | the DELEGATED-TO parameter | 2070 | | | 2071 | expectReply | the RSVP parameter | 2072 | | | 2073 | email | The value of the EMAIL parameter of the | 2074 | | ORGANIZER or ATTENDEE property, if defined. | 2075 | | Otherwise the property value, if it is a | 2076 | | mailto: URI. | 2077 | | | 2078 | sendTo | An iCalendar ATTENDEE with a mailto: URI | 2079 | | mapped to the "imip" method, or any other | 2080 | | URI mapped to the "other" method. Mapping | 2081 | | multiple methods is implementation- | 2082 | | specific. | 2083 | | | 2084 | kind | the CUTYPE parameter | 2085 | | | 2086 | linkIds | Implementation-specific. | 2087 | | | 2088 | locationId | Implementation-specific. When mapping from | 2089 | | iCalendar to JSCalendar this may be the | 2090 | | JSCalendar identifier of a CONFERENCE | 2091 | | property that has the MODERATOR feature | 2092 | | defined in its FEATURE parameter values. If | 2093 | | multiple such CONFERENCE properties are | 2094 | | defined in iCalendar, then the one with the | 2095 | | most interactive features is chosen. | 2096 | | | 2097 | memberOf | the MEMBER parameter | 2098 | | | 2099 | name | the CN parameter | 2100 | | | 2101 | attendance | Maps to the standard iCalendar ROLE | 2102 | | parameter values REQ-PARTICIPANT, OPT- | 2103 | | PARTICIPANT and NON-PARTICIPANT. | 2104 | | | 2105 | roles | The "chair" role maps to the standard | 2106 | | iCalendar ROLE parameter value "chair", | 2107 | | with an implicit participant of value | 2108 | | "required". The mapping of non-required | 2109 | | chairs and other roles is implementation- | 2110 | | specific, but using "x-name" parameter | 2111 | | values is recommended. | 2112 | | | 2113 | participationStatus | the PARTSTAT parameter | 2114 | | | 2115 | scheduleSequence | the SEQUENCE property of the participant's | 2116 | | latest iMIP message | 2117 | | | 2118 | scheduleUpdated | the DTSTAMP property of the participant's | 2119 | | latest iMIP message | 2120 +---------------------+---------------------------------------------+ 2122 Table 5: Translation of Participant between JSCalendar and iCalendar 2124 The iCalendar counterpart for JSCalendar Location objects is the 2125 iCalendar [RFC5545] LOCATION property, or implementation-specific. 2127 +-------------+-----------------------------------------------------+ 2128 | Property | iCalendar counterpart | 2129 +-------------+-----------------------------------------------------+ 2130 | name | Corresponds to the LOCATION property value. | 2131 | | | 2132 | description | Implementation-specific. | 2133 | | | 2134 | rel | Implementation-specific. | 2135 | | | 2136 | timeZone | Implementation-specific. | 2137 | | | 2138 | coordinates | Implementation-specific. Consider using a GEO | 2139 | | iCalendar property, along with one LOCATION. | 2140 | | | 2141 | uri | Corresponds to the LOCATION ALTREP parameter. | 2142 | | | 2143 | linkIds | Implementation-specific. | 2144 +-------------+-----------------------------------------------------+ 2146 Table 6: Translation of Location between JSCalendar and iCalendar 2148 The iCalendar counterpart for JSCalendar VirtualLocation objects is 2149 the iCalendar [RFC7986] CONFERENCE property, or implementation- 2150 specific. 2152 +--------------+--------------------------------------------------+ 2153 | Property | iCalendar counterpart | 2154 +--------------+--------------------------------------------------+ 2155 | name | Corresponds to the CONFERENCE LABEL parameter. | 2156 | | | 2157 | description | Implementation-specific. | 2158 | | | 2159 | uri | Corresponds to the CONFERENCE property value. | 2160 +--------------+--------------------------------------------------+ 2162 Table 7: Translation of VirtualLocation between JSCalendar and 2163 iCalendar 2165 6.6. Unknown properties 2167 Both JSCalendar and iCalendar calendar objects may contain properties 2168 that are not expressible in the other format. This specification 2169 does not mandate how to preserve these properties. Instead, it 2170 leaves negotiation on how to treat unknown properties to client and 2171 server implementations and their protocol used to exchange calendar 2172 objects. 2174 Two notable options to represent and preserve arbitrary iCalendar 2175 object properties in JSCalendar are: 2177 o _JCal_: Define iCalendar properties in JCal format ([RFC7265]) in 2178 a vendor-specific property of the JCalendar object. The JCal- 2179 formatted value may either only contain iCalendar properties that 2180 were not mapped to JSCalendar properties, or contain the complete 2181 iCalendar object representation. 2183 o _Alternate link_: Define an alternate link (Section 4.2.6) value 2184 pointing to the iCalendar representation of the JSCalendar object. 2185 E.g. the alternative representation of a VEVENT would be 2186 represented as a link with rel "alternate" and type "text/ 2187 calendar;component=VEVENT". 2189 7. JSCalendar object examples 2191 The following examples illustrate several aspects of the JSCalendar 2192 data model and format. The examples may omit mandatory or additional 2193 properties, which is indicated by a placeholder property with key 2194 "...". While most of the examples use calendar event objects, they 2195 are also illustrative for tasks. 2197 7.1. Simple event 2199 This example illustrates a simple one-time event. It specifies a 2200 one-time event that begins on January 15, 2018 at 1pm New York local 2201 time and ends after 1 hour. 2203 { 2204 "@type": "jsevent", 2205 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2206 "updated": "2018-01-15T18:00:00Z", 2207 "title": "Some event", 2208 "start": "2018-01-15T13:00:00", 2209 "timeZone": "America/New_York", 2210 "duration": "PT1H" 2211 } 2213 7.2. Simple task 2215 This example illustrates a simple task for a plain to-do item. 2217 { 2218 "@type": "jstask", 2219 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2220 "updated": "2018-01-15T18:00:00Z", 2221 "title": "Do something" 2222 } 2224 7.3. Simple group 2226 This example illustrates a simple calendar object group that contains 2227 an event and a task. 2229 { 2230 "@type": "jsgroup", 2231 "uid": "2a358cee-6489-4f14-a57f-c104db4dc343", 2232 "updated": "2018-01-15T18:00:00Z", 2233 "name": "A simple group", 2234 "entries": [ 2235 { 2236 "@type": "jsevent", 2237 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f1", 2238 "updated": "2018-01-15T18:00:00Z", 2239 "title": "Some event", 2240 "start": "2018-01-15T13:00:00", 2241 "timeZone": "America/New_York", 2242 "duration": "PT1H" 2243 }, 2244 { 2245 "@type": "jstask", 2246 "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", 2247 "updated": "2018-01-15T18:00:00Z", 2248 "title": "Do something" 2249 } 2250 ] 2251 } 2253 7.4. All-day event 2255 This example illustrates an event for an international holiday. It 2256 specifies an all-day event on April 1 that occurs every year since 2257 the year 1900. 2259 { 2260 "...": "", 2261 "title": "April Fool's Day", 2262 "isAllDay": true, 2263 "start": "1900-04-01T00:00:00", 2264 "duration": "P1D", 2265 "recurrenceRule": { 2266 "frequency": "yearly" 2267 } 2268 } 2270 7.5. Task with a due date 2272 This example illustrates a task with a due date. It is a reminder to 2273 buy groceries before 6pm Vienna local time on January 19, 2018. The 2274 calendar user expects to need 1 hour for shopping. 2276 { 2277 "...": "", 2278 "title": "Buy groceries", 2279 "due": "2018-01-19T18:00:00", 2280 "timeZone": "Europe/Vienna", 2281 "estimatedDuration": "PT1H" 2282 } 2284 7.6. Event with end time-zone 2286 This example illustrates the use of end time-zones by use of an 2287 international flight. The flight starts on April 1, 2018 at 9am in 2288 Berlin local time. The duration of the flight is scheduled at 10 2289 hours 30 minutes. The time at the flights destination is in the same 2290 time-zone as Tokyo. Calendar clients could use the end time-zone to 2291 display the arrival time in Tokyo local time and highlight the time- 2292 zone difference of the flight. The location names can serve as input 2293 for navigation systems. 2295 { 2296 "...": "", 2297 "title": "Flight XY51 to Tokyo", 2298 "start": "2018-04-01T09:00:00", 2299 "timeZone": "Europe/Berlin", 2300 "duration": "PT10H30M", 2301 "locations": { 2302 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2303 "rel": "start", 2304 "name": "Frankfurt Airport (FRA)" 2305 }, 2306 "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { 2307 "rel": "end", 2308 "name": "Narita International Airport (NRT)", 2309 "timeZone": "Asia/Tokyo" 2310 } 2311 } 2312 } 2314 7.7. Floating-time event (with recurrence) 2316 This example illustrates the use of floating-time. Since January 1, 2317 2018, a calendar user blocks 30 minutes every day to practice Yoga at 2318 7am local time, in whatever time-zone the user is located on that 2319 date. 2321 { 2322 "...": "", 2323 "title": "Yoga", 2324 "start": "2018-01-01T07:00:00", 2325 "duration": "PT30M", 2326 "recurrenceRule": { 2327 "frequency": "daily" 2328 } 2329 } 2331 7.8. Event with multiple locations and localization 2333 This example illustrates an event that happens at both a physical and 2334 a virtual location. Fans can see a live convert on premises or 2335 online. The event title and descriptions are localized. 2337 { 2338 "...": "", 2339 "title": "Live from Music Bowl: The Band", 2340 "description": "Go see the biggest music event ever!", 2341 "locale": "en", 2342 "start": "2018-07-04T17:00:00", 2343 "timeZone": "America/New_York", 2344 "duration": "PT3H", 2345 "locations": { 2346 "c0503d30-8c50-4372-87b5-7657e8e0fedd": { 2347 "name": "The Music Bowl", 2348 "description": "Music Bowl, Central Park, New York", 2349 "coordinates": "geo:40.7829,73.9654" 2350 } 2351 }, 2352 "virtualLocations": { 2353 "6f3696c6-1e07-47d0-9ce1-f50014b0041a": { 2354 "name": "Free live Stream from Music Bowl", 2355 "uri": "https://stream.example.com/the_band_2018" 2356 } 2357 }, 2358 "localizations": { 2359 "de": { 2360 "title": "Live von der Music Bowl: The Band!", 2361 "description": "Schau dir das groesste Musikereignis an!", 2362 "virtualLocations/6f3696c6-1e07-47d0-9ce1-f50014b0041a/name": 2363 "Gratis Live-Stream aus der Music Bowl" 2364 } 2365 } 2366 } 2368 7.9. Recurring event with overrides 2370 This example illustrates the use of recurrence overrides. A math 2371 course at a University is held for the first time on January 8, 2018 2372 at 9am London time and occurs every week until June 25, 2018. Each 2373 lecture lasts for one hour and 30 minutes and is located at the 2374 Mathematics department. This event has exceptional occurrences: at 2375 the last occurrence of the course is an exam, which lasts for 2 hours 2376 and starts at 10am. Also, the location of the exam differs from the 2377 usual location. On April 2 no course is held. On January 5 at 2pm 2378 is an optional introduction course, that occurs before the first 2379 regular lecture. 2381 { 2382 "...": "", 2383 "title": "Calculus I", 2384 "start": "2018-01-08T09:00:00", 2385 "timeZone": "Europe/London", 2386 "duration": "PT1H30M", 2387 "locations": { 2388 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2389 "title": "Math lab room 1", 2390 "description": "Math Lab I, Department of Mathematics" 2391 } 2392 }, 2393 "recurrenceRule": { 2394 "frequency": "weekly", 2395 "until": "2018-06-25T09:00:00" 2396 }, 2397 "recurrenceOverrides": { 2398 "2018-01-05T14:00:00": { 2399 "title": "Introduction to Calculus I (optional)" 2400 }, 2401 "2018-04-02T09:00:00": { 2402 "excluded": "true" 2403 }, 2404 "2018-06-25T09:00:00": { 2405 "title": "Calculus I Exam", 2406 "start": "2018-06-25T10:00:00", 2407 "duration": "PT2H", 2408 "locations": { 2409 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2410 "title": "Big Auditorium", 2411 "description": "Big Auditorium, Other Road" 2412 } 2413 } 2414 } 2415 } 2416 } 2418 7.10. Recurring event with participants 2420 This example illustrates scheduled events. A team meeting occurs 2421 every week since January 8, 2018 at 9am Johannesburg time. The event 2422 owner also chairs the event. Participants meet in a virtual meeting 2423 room. An attendee has accepted the invitation, but on March 8, 2018 2424 he is unavailable and declined participation for this occurrence. 2426 { 2427 "...": "", 2428 "title": "FooBar team meeting", 2429 "start": "2018-01-08T09:00:00", 2430 "timeZone": "Africa/Johannesburg", 2431 "duration": "PT1H", 2432 "virtualLocations": { 2433 "2a358cee-6489-4f14-a57f-c104db4dc2f1": { 2434 "name": "ChatMe meeting room", 2435 "uri": "https://chatme.example.com?id=1234567" 2436 } 2437 }, 2438 "recurrenceRule": { 2439 "frequency": "weekly" 2440 }, 2441 "replyTo": { 2442 "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com" 2443 }, 2444 "participants": { 2445 "dG9tQGZvb2Jhci5leGFtcGxlLmNvbQ": { 2446 "name": "Tom Tool", 2447 "email": "tom@foobar.example.com", 2448 "sendTo": { 2449 "imip": "mailto:6489-4f14-a57f-c1@calendar.example.com" 2450 }, 2451 "participationStatus": "accepted", 2452 "roles": { 2453 "attendee": true 2454 } 2455 }, 2456 "em9lQGZvb2Jhci5leGFtcGxlLmNvbQ": { 2457 "name": "Zoe Zelda", 2458 "email": "zoe@foobar.example.com", 2459 "sendTo": { 2460 "imip": "mailto:zoe@foobar.example.com" 2461 }, 2462 "participationStatus": "accepted", 2463 "roles": { 2464 "owner": true, 2465 "attendee": true, 2466 "chair": true 2467 } 2468 }, 2469 "...": "" 2470 }, 2471 "recurrenceOverrides": { 2472 "2018-03-08T09:00:00": { 2473 "participants/dG9tQGZvb2Jhci5leGFtcGxlLmNvbQ/participationStatus": 2474 "declined" 2475 } 2476 } 2478 } 2480 8. Security Considerations 2482 The use of JSON as a format does have its own inherent security risks 2483 as discussed in Section 12 of [RFC8259]. Even though JSON is 2484 considered a safe subset of JavaScript, it should be kept in mind 2485 that a flaw in the parser processing JSON could still impose a 2486 threat, which doesn't arise with conventional iCalendar data. 2488 With this in mind, a parser for JSON data aware of the security 2489 implications should be used for the format described in this 2490 document. For example, the use of JavaScript's "eval()" function is 2491 considered an unacceptable security risk, as described in Section 12 2492 of[RFC8259]. A native parser with full awareness of the JSON format 2493 should be preferred. 2495 9. IANA Considerations 2497 This document defines a MIME media type for use with JSCalendar data 2498 formatted in JSON. 2500 Type name: application 2502 Subtype name: jscalendar+json 2504 Required parameters: type 2506 The "type" parameter conveys the type of the JSCalendar data in 2507 the body part, with the value being one of "jsevent", "jstask", or 2508 "jsgroup". The parameter MUST NOT occur more than once. It MUST 2509 match the value of the "@type" property of the JSON-formatted 2510 JSCalendar object in the body. 2512 Optional parameters: none 2514 Encoding considerations: Same as encoding considerations of 2515 application/json as specified in RFC8529, Section 11 [RFC8259]. 2517 Security considerations: See Section 8 of this document. 2519 Interoperability considerations: This media type provides an 2520 alternative to iCalendar, jCal and proprietary JSON-based 2521 calendaring data formats. 2523 Published specification: This specification. 2525 Applications that use this media type: Applications that currently 2526 make use of the text/calendar and application/calendar+json media 2527 types can use this as an alternative. Similarily, applications 2528 that use the application/json media type to transfer calendaring 2529 data can use this to further specify the content. 2531 Fragment identifier considerations: N/A 2533 Additional information: 2535 Magic number(s): N/A 2537 File extensions(s): N/A 2539 Macintosh file type code(s): N/A 2541 Person & email address to contact for further 2542 information: 2543 calext@ietf.org 2545 Intended usage: COMMON 2547 Restrictions on usage: N/A 2549 Author: See the "Author's Address" section of this document. 2551 Change controller: IETF 2553 10. Acknowledgments 2555 The authors would like to thank the members of CalConnect for their 2556 valuable contributions. This specification originated from the work 2557 of the API technical committee of CalConnect, the Calendaring and 2558 Scheduling Consortium. 2560 11. References 2562 11.1. Normative References 2564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2565 Requirement Levels", BCP 14, RFC 2119, 2566 DOI 10.17487/RFC2119, March 1997, 2567 . 2569 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 2570 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 2571 . 2573 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2574 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2575 . 2577 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2578 Resource Identifier (URI): Generic Syntax", STD 66, 2579 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2580 . 2582 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2583 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2584 DOI 10.17487/RFC4122, July 2005, 2585 . 2587 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2588 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2589 . 2591 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 2592 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 2593 DOI 10.17487/RFC4791, March 2007, 2594 . 2596 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 2597 Scheduling Core Object Specification (iCalendar)", 2598 RFC 5545, DOI 10.17487/RFC5545, September 2009, 2599 . 2601 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 2602 Interoperability Protocol (iTIP)", RFC 5546, 2603 DOI 10.17487/RFC5546, December 2009, 2604 . 2606 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 2607 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 2608 September 2009, . 2610 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource 2611 Identifier for Geographic Locations ('geo' URI)", 2612 RFC 5870, DOI 10.17487/RFC5870, June 2010, 2613 . 2615 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 2616 Interoperability Protocol (iMIP)", RFC 6047, 2617 DOI 10.17487/RFC6047, December 2010, 2618 . 2620 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2621 Specifications and Registration Procedures", BCP 13, 2622 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2623 . 2625 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 2626 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 2627 DOI 10.17487/RFC6901, April 2013, 2628 . 2630 [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON 2631 Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2632 2014, . 2634 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 2635 DOI 10.17487/RFC7493, March 2015, 2636 . 2638 [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules 2639 in the Internet Calendaring and Scheduling Core Object 2640 Specification (iCalendar)", RFC 7529, 2641 DOI 10.17487/RFC7529, May 2015, 2642 . 2644 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 2645 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 2646 . 2648 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, 2649 DOI 10.17487/RFC7986, October 2016, 2650 . 2652 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2653 Interchange Format", STD 90, RFC 8259, 2654 DOI 10.17487/RFC8259, December 2017, 2655 . 2657 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 2658 DOI 10.17487/RFC8288, October 2017, 2659 . 2661 11.2. Informative References 2663 [draft-apthorp-ical-tasks] 2664 "Task Extensions to iCalendar", 2665 . 2667 [draft-ietf-calext-ical-relations] 2668 "Support for iCalendar Relationships", 2669 . 2672 [MIME] "IANA Media Types", . 2675 11.3. URIs 2677 [1] https://www.iana.org/time-zones 2679 [2] https://www.iana.org/assignments/link-relations/link- 2680 relations.xhtml 2682 [3] https://www.w3.org/TR/2011/REC-css3-color-20110607/#svg-color 2684 Authors' Addresses 2686 Neil Jenkins 2687 FastMail 2688 PO Box 234 2689 Collins St West 2690 Melbourne VIC 8007 2691 Australia 2693 Email: neilj@fastmailteam.com 2694 URI: https://www.fastmail.com 2696 Robert Stepanek 2697 FastMail 2698 PO Box 234 2699 Collins St West 2700 Melbourne VIC 8007 2701 Australia 2703 Email: rsto@fastmailteam.com 2704 URI: https://www.fastmail.com